1. En el contexto de CORBA, qu significan los siguientes acrnimos?
Para cada
acrnimo, indique el nombre completo y una breve descripcin: CORBA,
ORB, GIOP IIOP IOR, INS, POA.
CORBA (Common Object Request Broker Arquitecture o Arquitectura Comn de
Intermediario de peticin de objetos).
CORBA es un diseo de middleware que permite que los programas de aplicacin se
comunique unos con otros con independencia de sus lenguajes de programacin, sus
plataformas hardware y software, las redes sobre las que se comunican y sus
implementadores.
Las aplicaciones se construyen mediante objetos CORBA, que implementan interfaces
definidas en el lenguaje de definicin de interfaces de CORBA, (IDL). Los clientes acceden
a los mtodos de las interfaces de los objetos de CORBA mediante RMI. (Coulouris, 2001)
ORB (Object Request Broker o intermediario de peticin de objetos).
Como una motivacin importante fue que le permitir que los objetos distribuidos fueran
implementados en cualquier lenguajes de programacin fueran capaces de comunicase con
otro. As, se introdujo una metfora, el intermediario de peticin de objetos (ORB) cuyo
papel es el de ayudar a un cliente a invocar un mtodo de un objeto. Esta funcin conlleva
localizar el objeto, activar el objeto si fuera necesario despus comunicar la peticin del
cliente hacia el objeto, que realiza y responde al cliente. (Coulouris, 2001).
GIOP (General Inter-ORB Protocol o Protocolo General Inter-ORB).
En 1996, la especificacin de CORBA 2.0, que defini estndares para permitir la
comunicacin entre implementaciones realizadas por desarrolladores diferentes estos
entandares se denominan General Inter-ORB Protocol o GIOP. Se pretenda que este
GIOP pudiera ser implementado sobre cualquier capa de transporte con conexiones.
(Coulouris, 2001)
IIOP (Internet Inter-ORB Protocol o Protocolo Inter-ORB para internet).
La implementacin de GIOP para internet utiliza el prcolo TCP/IP y se denomina internet
Inter-ORB Protocol (IIOP)
Segn (Liu, 2004):
Para que dos ORB puedan interoperar, OMG ha especificado un protocolo conocido como
General Inter-ORB Protocol (GIOP), una especificacin que proporciona un marco
general para que se construya protocolos interoperables por encima del nivel de
transporte especfico. Un caso especial de este protocolo es el Inter Inter-ORB Protocol
(IIOP), que se corresponde con el GIP aplicado sobre el nivel de transporte de TCP/IP.
La especificacin del IIOP incluye los siguientes elementos:
1. Requisitos de gestin de transporte: Estos requisitos especifican que se necesita
para conectarse y desconectarse y los papeles que el cliente y el objeto servidor
interpretan en estableces y liberar conexiones.
2. Definicin de la representacin comn de datos: Se necesita definir un esquema
de codificacin para empaquetar y desempaquetar los datos para cada tipo de
datos del IDL.
3. Formatos de los mensajes: Se necesita definir los diferentes formatos de los dos
tipos de mensajes. Los mensajes permiten a los clientes enviar solicitudes al objeto
servidor y recibir sus respuestas. Cada cliente usa un mensaje de peticin para
invocar a un mtodo declarado en la interfaz CORBA de un objeto y recibe un
mensaje de respuesta del servidor.
Un ORB que soporte la especificacin de IIOP puede interoperar con otro ORB compatible
IIOP atreves de internet. De aqu surge la denominacin BUS de Objetos, El internet se
ve como un bus de Objeto de CORBA interconectados
IOR (Interoperable Object Reference o referencia de objeto interoperable)
Tambin como en el caso de JAVA RMI, un objeto distribuido CORBA se localiza por
medio de una referencia a Objeto. Ya que CORBA es independiente de lenguajes, una
referencia a un objeto CORBA es una entidad abstracta traducida a una referencia de objeto
especfica de cada lenguaje por medio de ORB, en una representacin elegida por el
desarrollador del propio ORB
Por interoperabilidad, OMG especifica un protocolo para referencias abstractas de objetos,
conocidos como protocolo Interoperable Object Reference (IOR). Un ORB que sea
compatible con el protocolo IOR permitir que una referencia a objeto se registre y se
obtenga desde un servicio de directorio compatible con IOR. Las referencias a objetos
CORBA representadas en este protocolo.
Una IOR es una cadena de caracteres que se contiene y codifica la informacin siguiente:
El tipo de objeto
El ordenador donde se encuentra el objeto
El nmero de puerto del servidor de objeto
Una clave del objeto, una cadena de bytes que identifica al objeto. La clave de
objeto la utiliza el servidor de objetos para localizar el objeto internamente
La representacin consiste en un prefijo con los caracteres IOR: seguido por una secuencia
hexadecimal de caracteres numricos, cada carcter representa 4 bits de datos binarios en la
IOR. (Liu, 2004)
INS (Interoperable Naming Servicie o Servicio de Nombres Interoperable)
Es un sistema de nombrado basado en el formato URL para el servicio de nombres de
CORBA. Permite que las aplicaciones compartan un contexto inicial de nombrado y que
proporcionen un URL, para acceder a un objeto CORBA. Utilizando este sistema, un URL
del tipo corbaname::acme.com:2050#tienda/ropa/mujer se podra usar para acceder al
objeto tienda/ropa/mujer del servicio de nombres en el puerto 2050 del servidor con
nombre acme.com. (Liu, 2004).
POA (Portable Object Adapter o adaptador de objetos portables)
Hay diferentes tipos de adaptadores de objetos CORBA. El portable object Adapter (POA)
es un tipo particular de adoptador de objetos definidos por una especificacin de CORBA.
Un adaptador de objetos de tipo POA permite que una implementacin de objeto funciones
en carios ORB, de forma que la implementacin del objeto sea portable a travs de varias
plataformas. (Liu, 2004)
2. Describa, por medio de un diagrama de bloques una descripcin que ilustre
arquitectura CORBA. El diagrama debe incluir los siguientes componentes: un
distribuido, un servidor de objetos, un cliente de objetos, el skeleton, el stub, el
el adaptador de objetos.
3. Describa, por medio de otro diagrama de bloques que ilustre la arquitectura
Java RMI, incluyendo los componentes equivalentes: un objeto distribuido, un
servidor de objetos, un cliente de objetos, el skeleton y el stub. Basndose en sus
diagramas, argumente las diferencias principales entre las dos arquitecturas.
Explique dichas diferencias.
Diferencias ente JAVA RMI y CORBA
1. CORBA distingue entre invocaciones dinmicas y estticas. Las invocaciones
estativas se emplean cuando se conoce el tiempo de compilacin de la interfaz
remota del objeto CORBA, lo que permite emplear un resguardo del cliente y un
esqueleto de servidor. Si la interfaz remota no es reconocida en tiempo de
compilacin debe emplearse una invocacin dinmica.
2. En CORBA el adaptador de objetos tiene como objetivo el de es servir de puente
sobre el hueco que media entre los objetos con interfaces IDL y las interfaces del
lenguaje de programacin correspondiente clases sirvientes.
3. De entrada RMI es un mecanismo puramente java y aunque Java tambin es una
representacin de objetos, es un hecho que la gran mayora de sistemas
empresariales emplean algn otro tipo tecnologa orientada a objetos como C+
+ o SmallTalk u otro lenguaje como COBOL o Ada, y es del planteamiento anterior
que surge CORBA: la facilidad de invocar procedimientos en "x" lenguaje a partir
de otro "x" lenguaje, al igual que RMI existen diversos detalles de CORBA que a
continuacin se mencionan.
4. DL es un lenguaje utilizado para crear cualquier desarrollo en CORBA, su nombre
es un indicador de su funcionamiento: definicin de interfaces, esto es, a travs de
IDL se definen las diversas estructuras que sern utilizadas en un ambiente
CORBA.
5. Los respectivos IDL's para el sistema CORBA, es necesario acercarse al lenguaje de
implementacin y esto se basa tambin fuertemente en el concepto de "Stubs" y
"Skeletons".A partir del mismo IDL se pueden generar varios Stubs y Skeletons en
diversos lenguajes, estos Stubs y Skeletons independientemente del lenguaje en que
sean generados sabrn comunicarse e invocar procedimientos/funciones
transparentemente. Cabe mencionarse que la generacin de estos Stubs y Skeletons
se lleva a cabo mediante compiladores IDL's como: IDLJava, IDLC++, IDLAda,
generalmente proporcionados con el ORB ("Object Request Broker").
4. Comparada con Java RMI, cules son los principales puntos fuertes de una
Herramienta CORBA, si hay alguno? Cules son los puntos dbiles, si hay
alguno?
Invocacin de mtodo remoto
Pros
Contras
Porttiles a travs de muchas
plataformas
Atado slo para plataformas con
soporte Java
Puede presentarse a nuevo cdigo
para JVM extranjeros
Las amenazas de seguridad con la
ejecucin remota de cdigo, y
limitaciones en la funcionalidad
impuestas por las restricciones de
seguridad
Curva de aprendizaje para los
desarrolladores que no tienen
experiencia RMI es comparable
con CORBA
Los desarrolladores de Java
pueden tener ya experiencia con
RMI (disponible desde JDK1.02)
Los sistemas existentes pueden ya
utilizan RMI - el costo y el tiempo
para convertir a una nueva
tecnologa puede ser prohibitivo
Slo se puede operar con sistemas
Java - no hay soporte para los
sistemas de legado escrito en C +
+, Ada, Fortran, Cobol, y otros
(incluyendo idiomas futuros).
CORBA
Pros
Contras
Los servicios pueden ser escritos en
muchos idiomas diferentes,
ejecutado en diferentes
plataformas, y acceder a cualquier
idioma con un lenguaje de
definicin de interfaz (IDL) de
mapeo.
Describiendo los servicios
requieren el uso de un lenguaje
de definicin de interfaz (IDL),
que debe ser
aprendida. Ejecucin o
utilizando los servicios
requieren un mapeo IDL a tu
idioma requerido - escribir uno
para un idioma que no es
compatible llevara una gran
cantidad de trabajo.
IDL a lenguaje de herramientas
de mapeo crean trozos de cdigo
basado en la interfaz - algunas
herramientas no podrn
integrar nuevos cambios con el
cdigo existente.
CORBA no admite la
transferencia de objetos o
cdigo.
Con IDL, la interfaz est
claramente separada de la
ejecucin, y los desarrolladores
pueden crear diferentes
implementaciones basadas en la
misma interfaz.
CORBA es compatible con los tipos
primitivos de datos, y una amplia
gama de estructuras de datos,
como parmetros
CORBA es ideal para su uso con
sistemas de legado, y para asegurar
que las aplicaciones escritas ahora
sern accesibles en el futuro.
CORBA es una manera fcil para
vincular objetos y sistemas de
juntas
El futuro es incierto - si CORBA
no logra suficiente la adopcin
por la industria, a continuacin,
las implementaciones de
CORBA se convierten en los
sistemas heredados.
Todava se requiere algn tipo
de formacin, y las
especificaciones CORBA se
encuentran todava en un estado
de flujo.
Sistemas CORBA pueden ofrecer
un mayor rendimiento
No todas las clases de
aplicaciones necesitan
rendimiento en tiempo real, y la
velocidad pueden ser negociados
fuera contra la facilidad de uso
para los sistemas Java puro.
Bibliografa
Andrew S Tanenbaum, M. V. (2008). Sistemas Distribuidos principio y
paradigmas. Mxico : Pearson Educatin.
Coulouris, G. (2001). Sistema Distribuido concepto y Diseo . Madrid: Pearson
Education .
Liu, M. L. (2004). COMPUTACION DISTRIBUIDA. FUNDAMENTOS Y
APLICACIONES. Madrid: Pearson Education.
Reilly, D. (05 de Junio de 2006). www..javacoffeebreak.com. Obtenido de
www.javacoffeebreak.com:
http://www.javacoffeebreak.com/articles/rmi_corba/
