RMI sobre IIOP

¿Qué es RMI sobre IIOP?

RMI sobre IIOP (RMI-IIOP en adelante), desarrollado conjuntamente por IBM y Sun, es una nueva versión de RMI (Remote Method Invocation) para IIOP (Internet Inter-ORB Protocol) que combina las funciones de programación sencilla de RMI con la interoperabilidad de CORBA. Esta nueva versión de RMI se lanzó oficialmente en junio y se puso a disposición de forma gratuita en el sitio web de Sun (consulte la sección Recursos a continuación para obtener información sobre dónde puede descargarla). La implementación de referencia de Sun se ejecuta en Windows 9x / NT y Solaris. Es una extensión estándar que admite tanto JDK 1.1.6 como la plataforma Java 2.

RMI y CORBA se han desarrollado de forma independiente como modelos de programación de objetos distribuidos. RMI, una base de las tecnologías EJB y Jini, se introdujo como un modelo de programación fácil de usar basado en Java para objetos distribuidos. CORBA (Common Object Request Broker Architecture), definida por OMG (Object Management Group), es un conocido modelo de programación de objetos distribuidos que admite varios lenguajes. El protocolo IIOP conecta productos CORBA de diferentes proveedores, lo que garantiza la interoperabilidad entre ellos. RMI-IIOP es, en cierto sentido, un matrimonio de RMI y CORBA.

A los efectos de este artículo, asumimos que ya está familiarizado con los conceptos básicos de CORBA. Si necesita más ayuda para ponerse al día, hay un enlace útil en la sección de Recursos a continuación.

Antes de RMI-IIOP

Mire la Figura 1 a continuación. El espacio sobre la línea horizontal central representa el dominio original de RMI; la región inferior representa el mundo de CORBA e IIOP. Estos dos mundos separados, habiéndose desarrollado de forma independiente, históricamente no han sido capaces de comunicarse entre sí. Por ejemplo, el protocolo nativo de RMI, JRMP (Protocolo de método remoto de Java), no se puede conectar con otros protocolos.

Si el único lenguaje de programación que necesita en un nuevo proyecto es Java, el uso de RMI y JRMP, una combinación denominada RMI (JRMP) en el resto de este artículo, ha sido tradicionalmente la mejor opción. A diferencia de CORBA, que requiere el uso del lenguaje de definición de interfaz bastante complicado (IDL), RMI (JRMP) ofrece una programación sencilla para los amantes de Java. CORBA, por otro lado, permite la programación de objetos distribuidos en diferentes plataformas y diferentes lenguajes de programación. Los desarrolladores necesitan programación de objetos distribuidos no solo para nuevos proyectos, sino también para utilizar recursos de software heredados. Por supuesto, el software heredado se programa en la mayoría de los casos en lenguajes distintos de Java; en tales situaciones, los desarrolladores necesitan CORBA, no RMI (JRMP).

Por lo tanto, tenemos nuestro dilema central: RMI (JRMP) tiene la ventaja de una programación fácil, mientras que CORBA proporciona interoperabilidad entre múltiples lenguajes de programación en varias plataformas. Desafortunadamente, sin embargo, tradicionalmente no ha habido una forma de utilizar estas dos excelentes tecnologías. Esto se muestra en el gráfico de la Figura 2, en el que un círculo representa una situación en la que un cliente puede llamar a un servidor, y una X representa un caso en el que esto no es posible.

Lo mejor de ambos mundos

Solía ​​ser difícil elegir entre RMI (JRMP) y CORBA al iniciar un nuevo proyecto. Si seleccionó RMI (JRMP), obtuvo una programación fácil, pero perdió la interoperabilidad en varios idiomas. Si seleccionó CORBA, obtuvo interoperabilidad, pero se enfrentó a una tarea de programación más desalentadora. Tanto los usuarios de RMI (JRMP) como de CORBA, cansados ​​de tomar esta decisión, han dicho con una sola voz: "Por favor, conecte los dos".

En la Figura 3 a continuación, la sección superior representa el modelo RMI (JRMP), la sección central el modelo RMI-IIOP y la sección inferior el modelo CORBA. Una flecha representa una situación en la que un cliente puede llamar a un servidor. RMI-IIOP pertenece al mundo IIOP por debajo de la línea horizontal. Lo que puede parecer extraño son las flechas diagonales que cruzan la frontera entre el mundo JRMP y el mundo IIOP, lo que implica que un cliente RMI (JRMP) puede llamar a un servidor RMI-IIOP y viceversa. Es natural que los lectores piensen que estas flechas diagonales están equivocadas; después de todo, los diferentes protocolos nunca pueden comunicarse entre sí, ¿verdad? Sin embargo, estas flechas están en el lugar correcto. RMI-IIOP es compatible con los protocolos JRMP y IIOP.

Un binario de servidor (es decir, un archivo de clase) creado con las API RMI-IIOP se puede exportar como JRMP o IIOP. No es necesario que reescriba su código fuente de Java o que lo recompile cuando cambie de JRMP a IIOP, o viceversa. Solo necesita cambiar parámetros como las propiedades del sistema Java cuando lo ejecuta. Alternativamente, puede determinar el protocolo utilizado especificándolo en el código fuente de Java. La misma flexibilidad se aplica al código de cliente RMI-IIOP.

Exportación dual

Hay un hecho más importante a tener en cuenta al decidir entre los protocolos JRMP y IIOP. Cuando exporta un objeto RMI-IIOP en su servidor, no necesariamente tiene que elegir entre JRMP y IIOP. Si necesita un único objeto de servidor para admitir clientes JRMP y IIOP, puede exportar su objeto RMI-IIOP a JRMP y IIOP simultáneamente. En la terminología RMI-IIOP, esto se denomina exportación dual.

Las flechas diagonales de la Figura 3 son posibles porque las API de RMI-IIOP admiten los protocolos JRMP y IIOP. Esto significa que, sin reescribir el código fuente de un objeto RMI (JRMP), puede ser llamado por un nuevo cliente RMI-IIOP. De manera similar, sin volver a escribir el código fuente de un cliente RMI (JRMP), puede reemplazar un objeto de servidor RMI (JRMP) con un nuevo objeto RMI-IIOP al que también puede llamar un cliente CORBA. Por lo tanto, RMI-IIOP conserva la inversión existente en binarios RMI (JRMP), porque RMI-IIOP puede comunicarse con ellos sin ningún cambio de código fuente o recompilación.

Esta interoperabilidad con RMI (JRMP) fue uno de los principios de diseño de RMI-IIOP. Los diseñadores de RMI-IIOP evitaron la tentación de desplazar CORBA y RMI con un tercer modelo de programación, ya que esto sólo habría confundido a los programadores de objetos distribuidos y habría dificultado aún más la migración desde RMI (JRMP).

Interoperabilidad con CORBA

Mire la Figura 3 nuevamente. La sección debajo de la línea horizontal es el mundo IIOP, donde un cliente RMI-IIOP llama a un servidor CORBA y un cliente CORBA llama a un servidor RMI-IIOP. Por cliente RMI-IIOP, nos referimos a un programa cliente que fue escrito por un programador RMI que no sabe nada sobre CORBA o IDL. Asimismo, un cliente de CORBAes un programa cliente que fue escrito por un programador CORBA que ignora RMI. La separación de la interfaz de la implementación es una técnica bien establecida que permite a los programadores acceder a diferentes recursos sin necesidad de saber cómo se implementan esos recursos; Si se sigue esta técnica, los usuarios de RMI-IIOP y CORBA pueden utilizar los servicios del otro protocolo, si pueden acceder a su interfaz. Un archivo de interfaz RMI Java es la interfaz para los usuarios de RMI-IIOP, mientras que IDL es la interfaz para los usuarios de CORBA; La interoperabilidad entre RMI-IIOP y CORBA en la Figura 3 se logra proporcionando a cada usuario su interfaz esperada, mientras se mantiene oculta la implementación real.

El último detalle que se explica en la Figura 3 es la flecha punteada que indica un cliente RMI-IIOP que llama a un servidor CORBA. ¿Por qué solo esta flecha tiene puntos? Un cliente RMI-IIOP no puede acceder necesariamente a todos los objetos CORBA existentes. La semántica de los objetos CORBA definidos en IDL es un superconjunto de los de los objetos RMI-IIOP, por lo que el IDL de un objeto CORBA existente no siempre se puede asignar a una interfaz Java RMI-IIOP. Sólo cuando la semántica de un objeto CORBA específico coincide con la de RMI-IIOP es que un cliente RMI-IIOP puede llamar a un objeto CORBA. La flecha punteada indica una conexión que a veces, pero no siempre, es posible.

Sin embargo, la incompatibilidad aquí no debe exagerarse. Las restricciones indicadas por la flecha punteada se aplican solo cuando se trata de objetos CORBA existentes. Suponga que diseña un objeto distribuido completamente nuevo con una interfaz Java RMI-IIOP. En este caso, puede generar automáticamente su IDL correspondiente con elrmicherramienta. Desde este archivo IDL, puede implementarlo como un objeto CORBA, en C ++, por ejemplo. Este objeto C ++ es un objeto CORBA puro que puede ser llamado por un cliente CORBA y también puede ser llamado por un cliente RMI-IIOP sin ninguna limitación. Para el cliente RMI-IIOP, este objeto C ++ CORBA aparece como un objeto RMI-IIOP puro porque está definido por una interfaz Java RMI-IIOP. En resumen, la diferencia entre un objeto CORBA y un objeto RMI-IIOP es solo una cuestión de implementación. Asimismo, si un objeto se implementa en RMI-IIOP, el objeto aparece como un objeto CORBA para un cliente CORBA porque un cliente CORBA accede a él a través de su IDL.

La Figura 4 a continuación muestra la matriz que resume las flechas en la Figura 3. El círculo de puntos significa lo mismo que la flecha de puntos en la Figura 3. La Figura 4 demuestra que, si implementa su servidor en RMI-IIOP, tiene la opción más amplia de clientela. Asimismo, si implementas tu cliente en RMI-IIOP, puedes hablar con la mayor variedad de servidores, aunque existen algunas restricciones en el caso de los objetos CORBA existentes, como lo indica el círculo punteado.

Política de diseño RMI-IIOP

Había dos requisitos previos importantes que dieron forma al diseño del protocolo RMI-IIOP: la semántica de RMI debía dejarse lo más intacta posible y CORBA debía mejorarse para que la semántica de RMI pudiera implementarse utilizando la infraestructura de CORBA. Esto era más fácil decirlo que hacerlo. Si se introdujera un tercer modelo de programación, solo confundiría a los programadores. Para producir un matrimonio feliz de RMI y CORBA, era necesario llegar a un compromiso entre los diferentes orígenes de estos cónyuges: si ambos rechazaban cualquier compromiso, el matrimonio no llegaría a ninguna parte. Afortunadamente, la comunidad de CORBA lo reconoció y aceptó ciertos cambios para que RMI-IIOP pudiera convertirse en una realidad.

Los dos cambios principales que CORBA aceptó fueron las especificaciones de Objects by Value y Java-to-IDL Mapping . La primera, que ya está disponible para los usuarios de RMI en forma de serialización de objetos Java, es una especificación CORBA destinada a hacer que otros lenguajes implementen una capacidad similar. Este último es el mapeo utilizado para convertir las interfaces RMI Java en definiciones CORBA IDL, y no debe confundirse con el mapeo IDL a Java ya definido en CORBA 2.2. (Consulte Recursos para obtener enlaces a estas dos nuevas especificaciones CORBA).

OMG ya ha aceptado oficialmente ambas especificaciones para CORBA 2.3, pero las implementaciones de CORBA tendrán que ponerse al día con esta nueva versión antes de que el nuevo matrimonio de CORBA y RMI descrito aquí se convierta en una realidad generalizada. Por ejemplo, Sun dispone de un compilador IDL-to-Java que se ajusta a CORBA 2.3 para su uso junto con RMI-IIOP ORB (intermediario de solicitud de objetos), pero actualmente es una versión de acceso temprano adecuada solo para explorar la interoperabilidad de CORBA y RMI-IIOP, y no para uso de producción. Además, el compilador IDL-to-Java distribuido por Sun para su uso con Java IDL ORB en Java 1.2 no cumple con CORBA 2.3, por lo que no se puede usar para probar la interoperabilidad con RMI-IIOP. Esta situación se resolverá en los próximos meses a medida que los proveedores de CORBA presenten nuevas versiones de sus productos que admitan CORBA 2.3.Por ejemplo, la próxima versión de la plataforma Java 2, Standard Edition incluirá RMI-IIOP y un compilador IDL a Java de calidad de producción que admite CORBA 2.3.

Procedimiento de desarrollo

La Figura 5 a continuación muestra los procedimientos de desarrollo para servidores y clientes RMI-IIOP. Notarás que son casi iguales a los de RMI (JRMP). Al igual que en RMI (JRMP), la definición de un objeto distribuido es su interfaz RMI Java ( MyObject.javaen la Figura 5). Una diferencia es el -iiopparámetro del rmiccompilador. Esta opción se utiliza para rmicgenerar los stubs y los enlaces que admiten el protocolo IIOP. Sin esta -iiopopción, rmicgenera un stub y un esqueleto para el protocolo JRMP. Aunque el procedimiento de desarrollo para RMI-IIOP es cercano al de RMI (JRMP), el entorno de ejecución es diferente en que la comunicación se realiza a través de un ORB compatible con CORBA 2.3, utilizando IIOP para la comunicación entre servidores y clientes.

Si está considerando convertir el código RMI (JRMP) a RMI-IIOP, debe tener en cuenta que existen algunas diferencias de implementación al ejecutar IIOP. La recolección de basura distribuida no es compatible con CORBA, que utiliza destrucción explícita y referencias de objetos persistentes con pasivación y activación transparentes. El registro RMI se reemplaza por JNDI con el CosNamingproveedor de servicios LDAP o, y la activación de RMI se reemplaza por el adaptador de objeto portátil. Las referencias a objetos remotos deben reducirse mediante un narrow()método programático en lugar de una conversión directa del lenguaje Java. Otras semánticas RMI, como la serialización de objetos, son totalmente compatibles con IIOP.

Procedimiento de interoperabilidad CORBA

La Figura 6 muestra cómo lograr la interoperabilidad entre RMI-IIOP y CORBA. Para simplificar nuestra discusión, consideremos dos aspectos de dicha interoperabilidad: un cliente CORBA que usa un objeto RMI-IIOP, que se muestra en la sección más a la izquierda de la Figura 6, y un cliente RMI-IIOP que usa un objeto CORBA, que se muestra en la sección más a la derecha. En el centro de la figura están aquellos procesos compartidos que permiten que funcionen ambas formas de interoperabilidad.