Asunto: Re: Modelo de componentes CORBA
Fecha: Fri Dec 10 18:17:51 1999
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Bueno, hoy estoy hablador (o escritor ;-)
Pedro Garcia Lopez wrote:
> Buenas again ...
>
> > One thing is for sure: It will definitely not be the "near" future, as
> > all commercial ORB vendors are still working on their CORBA 2.3
> > implementation.
> >
>
> OK.A mi me dijeron otra cosa antes.
>
> >
> >
> > Efectivamente, es lo que creo yo. La ventaja de Java con respecto a C++ es la posibilidad de serialización
> > estándar, utilizado en EJB para proporcionar balanceo de carga, etc. Además, los componentes del servidor son
> > muy propicios para realizar este tipo de gestión. En cuanto a C++, la cosa cambia.
> >
>
> Diego, ya se que te tira mucho lo del codigo movil ;-), pero para hacer balanceo de carga entre servidores no
> necesitas la serializacion de Java. Con un servicio de eventos que rediriga las peticiones en base a la carga entre
> componentes de servidores distintos es suficiente. Leete por ejemplo la documentacion que paso en el link anterior.
>
¡Que malo es conocerse! Se que la serialización no es necesaria, pero lo que dices del servicio de eventos (también he
visto que se utiliza el de nombres para eso) obliga a que todos los hosts tengan todos los componentes. Al menos de
alguna manera tendrás que pasarlos de un servidor a otro. Mi visión en cuanto a C++ es más amplia en el sentido de que
un modelo de componentes algo más serio que EJB (que contemple varios lenguajes y varias plataformas) debe definir un
formato binario de intercambio. Con él, los componentes pueden "viajar" físicamente para realizar el balanceo o por
cuestiones de eficiencia. Esto es lo que pretende el CM de CORBA.
Además, un servidor de aplicaciones está limitado a un conjunto (pool) de servidores de una empresa que están
conectados y dedicados. Así, es sencillo que todos ellos contengan el mismo software o el software que necesiten. Sin
embargo, el ámbito CORBA, tal como yo lo veo es más amplio, y no puedes "redirigir" peticiones a hosts artbitrarios si
no tienen el componente que necesitas, por lo que éste tiene que viajar.
>
> >
> > Por otro lado, EJB especifica un conjunto de servicios que se ofrecen a los objetos que participan. ¿Cómo se
> > ofrecen los servicios a los objetos C++? ¿Se ofrecen a través de servicios CORBA estándar? Si es así, ¿cómo se
> > hacen compatibles los servicios EJB con los CORBA? Si no, ¿los servicios que se ofrecen muestran un interfaz y
> > diseño distinto a los del estándar CORBA? (Perdonad todas las preguntas. Quizá sean muy ingénuas, pero me salen
> > del alma ;-)
> >
>
> Yo tambien tengo que ponerme mas al dia, pero en general la idea es poner capas de abstraccion encima de estos
> servicios.Por ejemplo con EJB no te tienes que preocupar de como es el API de transacciones (de eso se encarga el
> servidor), tampoco JDBC (de la persistencia se encarga el contenedor de EJB, tu le dices los campos). Yo creo que la
> idea en muchos casos es simplificar el acceso a los servicios. Igualmente tu no vas a controlar el servicio de
> seguridad CORBA a tope, pero el servidor de aplicaciones si. A ti te ofrecera un API sencilla y potente. El acceso
> al servicio de directorio en Java es con JNDI, con C++ imagino que habran creado un API sencilla, me lo mirare.
> Pero al final un EJB que es: un componente remoto con su idl (si, hay que meterle los metodos ejbActivate y
> ejbPassivate para el tema de activacion de objetos pero tampoco es el invento del siglo).
> En cuanto a que ofrezcan transacciones, seguridad, balanceo de carga para C++ (eso es lo que venden, no se si sera
> verdad o vaporware).
OK.
>
> Saludos a todos.
>
Saludos. diego.
>
> >
> > >
> > > Gabriel
> > >
> > > PD: Perdonad por los largos "pies" de mis mensajes, pero no tengo
> > > control
> > > sobre ellos :-S
> >
> > No problemo.
> >
> > Saludos
> > diego.
> >
> > --
> > Diego Sevilla Ruiz
> > Departamento de Ingeniería y Tecnología de Computadores
> > Facultad de Informática. Universidad de Murcia
> > Campus de Espinardo - 30080 Murcia (SPAIN)
> > Tel.: +34-968-367570
> > E-mail: dsevilla@ditec.um.es
> >
> > $_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
> > "\@". "\007f". "DDq". "DD5". "\204".
> > "\@". "DT4CE". "D54E". "DD". "\244".
> > "\021". "dBDTC". "\010DD". "\200\$FD\024".
> > "GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
> > (/./g) {$q= ord$q; for(a, b){$z[$c]
> > =$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;
--
Diego Sevilla Ruiz
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es
$_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
"\@". "\007f". "DDq". "DD5". "\204".
"\@". "DT4CE". "D54E". "DD". "\244".
"\021". "dBDTC". "\010DD". "\200\$FD\024".
"GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
(/./g) {$q= ord$q; for(a, b){$z[$c]
=$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;