1. En el contexto de CORBA, ¿qué significan los siguientes acrónimos? Para cada acrónimo, indique el nombre completo y una breve descripción: CORBA, ORB, GIOP IIOP IOR, INS, POA.

CORBA (Common Object Request Broker Arquitecture o Arquitectura Común de Intermediario de petición de objetos).

CORBA es un diseño de middleware que permite que los programas de aplicación se comunique unos con otros con independencia de sus lenguajes de programación, 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 definición de interfaces de CORBA, (IDL). Los clientes acceden a los métodos de las interfaces de los objetos de CORBA mediante RMI. (Coulouris, 2001)

ORB (Object Request Broker o intermediario de petición de objetos).

Como una motivación importante fue que le permitiré que los objetos distribuidos fueran implementados en cualquier lenguajes de programación fueran capaces de comunicase con otro. Así, se introdujo una metáfora, el intermediario de petición de objetos (ORB) cuyo papel es el de ayudar a un cliente a invocar un método de un objeto. Esta función conlleva localizar el objeto, activar el objeto si fuera necesario después comunicar la petición 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 especificación de CORBA 2.0, que definió estándares para permitir la comunicación entre implementaciones realizadas por desarrolladores diferentes estos entandares se denominan General Inter-ORB Protocol o GIOP. Se pretendía 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 implementación de GIOP para internet utiliza el prcolo TCP/IP y se denomina internet Inter-ORB Protocol (IIOP)

Según (Liu, 2004):

Para que dos ORB puedan interoperar, OMG ha especificado un protocolo conocido como General Inter-ORB Protocol (GIOP), una especificación que proporciona un marco general para que se construya protocolos interoperables por encima del nivel de transporte específico. 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 especificación del IIOP incluye los siguientes elementos:

1. Requisitos de gestión 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. Definición de la representación común de datos: Se necesita definir un esquema de codificación 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 petición para invocar a un método declarado en la interfaz CORBA de un objeto y recibe un mensaje de respuesta del servidor.

Un ORB que soporte la especificación de IIOP puede interoperar con otro ORB compatible IIOP atreves de internet. De aquí surge la denominación BUS de Objetos, “El internet se ve como un bus de Objeto de CORBA interconectados”

IOR (Interoperable Object Reference o referencia de objeto interoperable)

También 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 específica de cada lenguaje por medio de ORB, en una representación 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 información siguiente:

El tipo de objeto El ordenador donde se encuentra el objeto

El número 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 representación consiste en un prefijo con los caracteres IOR: seguido por una secuencia hexadecimal de caracteres numéricos, cada carácter 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 podría 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 especificación de CORBA. Un adaptador de objetos de tipo POA permite que una implementación de objeto funciones en carios ORB, de forma que la implementación del objeto sea portable a través de varias plataformas. (Liu, 2004)

2. Describa, por medio de un diagrama de bloques una descripción 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. Basándose 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 dinámicas y estáticas. Las invocaciones estativas se emplean cuando se conoce el tiempo de compilación 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 compilación debe emplearse una invocación dinámica.

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 programación correspondiente clases sirvientes.

3. De entrada RMI es un mecanismo puramente java y aunque Java también es una representación de objetos, es un hecho que la gran mayoría de sistemas empresariales emplean algún otro tipo tecnología 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 continuación se mencionan.

4. DL es un lenguaje utilizado para crear cualquier desarrollo en CORBA, su nombre es un indicador de su funcionamiento: definición de interfaces, esto es, a través de IDL se definen las diversas estructuras que serán utilizadas en un ambiente CORBA.

5. Los respectivos IDL's para el sistema CORBA, es necesario acercarse al lenguaje de implementación y esto se basa también 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 sabrán comunicarse e invocar procedimientos/funciones transparentemente. Cabe mencionarse que la generación 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, ¿cuáles son los principales puntos fuertes de unaHerramienta CORBA, si hay alguno? ¿Cuáles son los puntos débiles, si hay alguno?

Invocación de método remoto

Pros Contras

Portátiles a través de muchas plataformas

Atado sólo para plataformas con soporte Java

Puede presentarse a nuevo código para JVM extranjeros

Las amenazas de seguridad con la ejecución remota de código, y limitaciones en la funcionalidad impuestas por las restricciones de seguridad

Los desarrolladores de Java pueden tener ya experiencia con RMI (disponible desde JDK1.02)

Curva de aprendizaje para los desarrolladores que no tienen experiencia RMI es comparable con CORBA

Los sistemas existentes pueden ya utilizan RMI - el costo y el tiempo para convertir a una nueva tecnología puede ser prohibitivo

Sólo 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 definición de interfaz (IDL) de mapeo.

Describiendo los servicios requieren el uso de un lenguaje de definición de interfaz (IDL), que debe ser aprendida. Ejecución o utilizando los servicios requieren un mapeo IDL a tu idioma requerido - escribir uno para un idioma que no es compatible llevaría una gran cantidad de trabajo.

Con IDL, la interfaz está IDL a lenguaje de herramientas

claramente separada de la ejecución, y los desarrolladores pueden crear diferentes implementaciones basadas en la misma interfaz.

de mapeo crean trozos de código basado en la interfaz - algunas herramientas no podrán integrar nuevos cambios con el código existente.

CORBA es compatible con los tipos primitivos de datos, y una amplia gama de estructuras de datos, como parámetros

CORBA no admite la transferencia de objetos o código.

CORBA es ideal para su uso con sistemas de legado, y para asegurar que las aplicaciones escritas ahora serán accesibles en el futuro.

El futuro es incierto - si CORBA no logra suficiente la adopción por la industria, a continuación, las implementaciones de CORBA se convierten en los sistemas heredados.

CORBA es una manera fácil para vincular objetos y sistemas de juntas

Todavía se requiere algún tipo de formación, y las especificaciones CORBA se encuentran todavía 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.

BibliografíaAndrew S Tanenbaum, M. V. (2008). Sistemas Distribuidos principio y paradigmas. México :

Pearson Educatión.

Coulouris, G. (2001). Sistema Distribuido concepto y Diseño . 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/