RMI y CORBA: Una base para aplicaciones Distribuidas

Procedimientos Remotos

RMI ("Remote Method Invocation") y algunas alternativas como CORBA y COM son mecanismos para invocar | ejecutar procedimientos remotos en computadoras | servidores distribuidos.

Procedimientos Remotos ? Computadoras Distribuidas ? Para que ?

La gran mayoría de los sistemas empresariales hoy en día requieren de esta funcionalidad , esto se debe tanto a distancias geográficas como a requerimientos de computo, ya que seria iluso pensar que las necesidades de computo de TODA una empresa fueran satisfechas por una sola computadora y/o servidor.

Que implica diseñar Procedimientos | Aplicaciones Remotas ?

Diversos detalles con los que comúnmente no se trabaja al diseñar un programa para ejecutarse en una sola computadora y/o servidor. Estos son solo algunos de los detalles con los que se debe trabajar al invocar procedimientos remotos:

Marshalling y Unmarshalling

Si se ejecuta un programa en una sola computadora se tiene la seguridad que la representación de datos esta conforme a esa plataforma, sea SunSolaris,Linux, Windows..etc, sin embargo, Que ocurre si se intentan pasar parámetros a un procedimiento en un servidor AIX de una computadora utilizando Windows NT ?.Marshalling | Unmarshalling es el proceso por el cual debe pasar toda información para que ésta sea utilizable en ambientes heterogéneos.

Inestabilidad de la Red

Debido a que los procedimientos son invocados a través de una Red, Que ocurriría si un Router en la Red o bien el servidor y/o computadora fallara al momento de invocarse el procedimiento ? Este tipo de errores deben ser contemplados al momento de definir el procedimiento.

Seguridad

Deben existir diversos criterios de Seguridad para permitir la ejecución de estos procedimientos remotos ya que pueden estar sujetos a un ambiente hostil, por el hecho de encontrarse en Red.

La razón de ser de RMI así como cualquier otro mecanismo para invocar procedimientos remotos (CORBA), es precisamente aislar al programador de todos estos detalles que deben ser contemplados al diseñar un procedimiento y/o aplicación en Red.

RMI "Remote Method Invocation"

RMI ("Remote Method Invocation") es el mecanismo ofrecido en Java que permite a un procedimiento (método, clase,aplicación o como guste llamarlo) poder ser invocado remotamente. Una de las ventajas al diseñar un procedimiento con RMI es interoperabilidad , ya que RMI forma parte de todo JDK , por ende, cualquier plataforma que tenga acceso a un JDK también tendrá acceso a estos procedimientos (método, clase,aplicación o como guste llamarlo), esto a diferencia del clásico CORBA que requiere de otros criterios.(más sobre esto en CORBA ).

Detalles de RMI

Interfase e Implementación

Uno de los primeros detalles para aislar al programador de los detalles mencionados inicialmente involucra el concepto utilizado en los lenguajes orientados a objetos: la separación entre Interfase e Implementación . La interfase es únicamente una declaración del método(s) definidos en la implementación,esto es, en la implementación se encuentra definida la lógica mientras la interfase funciona como una declaración:

public interface ITransaccionFinanaciera extends java.rmi.Remote { 
   public void deduccion(int mas) throws java.rmi.RemoteException;
   public void abono(int menos) throws java.rmi.RemoteException;
}

La declaración anterior es una interfase que contiene los procedimientos deduccion y abono , sin embargo, nótese que no contienen ningún tipo de código (lógica), a esto se refiere una interfase. La lógica (código) de estos procedimientos se encuentra en la implementación. El definir una interfase para los procedimientos permite que cada vez que se intente accesar el método de una manera remota éste sea realizado a través de la interfase y no directamente en la implementación.A continuación la implementación :

public class TransaccionFinanaciera extends UnicastRemoteObject implements 
   ITransaccionFinanciera { 

   public void deduccion(int mas) throws Exception { 
     if (...) 
      {
      .... 
      } 
  }
   public void abono(int menos) throws Exception { 
    for (...) 
     {
      ....
     } 
  }

}

Nótese que implementa las funciones definidas en la interfase y define la lógica (código) de cada función.

Stubs y Skeletons

Una vez definidas la interfase e implementación de las respectivas funciones es necesario definir otro elemento para ejecutar | invocar funciones remotas: Stubs | Skeletons. Estos Stubs y Skeletons permiten que al momento de ser invocada la función remota esta pueda ser simulada localmente .

En la gráfica anterior el Stub funciona como un simulador para todas las funciones que están siendo invocadas y pertenecen a la implementación de servidor, mientras el Skeleton funciona como simulador para recibir parámetros de la implementación de cliente (NOTA: El uso de cliente-servidor no implica que estos deban ser un navegador y un servidor de páginas , esto bien pudiera ser cualquier combinación imaginable desde un "Servlet Engine" hasta un "Enterprise Java Bean Engine" (Vea "Java Application Servers" ). Otra labor importante que cumplen los Stubs y Skeletons es el Marshalling | Unmarshalling de Información.

Para generar estos "Stubs" y "Skeletons" Java ofrece una herramienta llamada rmic , basta ejecutar rmic sobre la implementación de las funciones correspondientes, basado del ejemplo anterior: rmic Transaccion_Financiera generaría : TransaccionFinanciera_Stub.class y TransaccionFinanciera_Skeleton.class.Posteriormente son colocados los "Stubs" y "Skeletons" en el "Cliente" o "Servidor" correspondiente. NOTA: rmic debe ser ejecutado después que haya sido compilada la clase con javac .

RMI Registry

Hasta este punto no se ha mencionado como se lleva acabo la conectividad entre las funciones remotas, esto al igual que cualquier otra comunicación de Red se lleva acabo mediante un puerto TCP/IP. Esta comunicación requiere definir lo que es denominado RMI Registry, el RMI Registry se establece en un puerto TCP/IP (por default 1099) y mantiene un mapa de las funciones remotas que serán utilizadas, esto es, cuando arriva la requisición para una función remota en el puerto conocido, el RMI Registry será encargado de redireccionar a la implementación apropiada.

La utilización de un puerto TCP/IP implica que de alguna manera la función remota debe ser ubicada a través de un mecanismo, esto generalmente se hace mediante un RMI URL (Universal Resource Locator) como rmi://java.osmosislatina.com/transaccion (Note la similitud con un HTTP URL usado en Páginas Web), sin embargo, la utilización de RMI URL tiene una grave deficiencia: Estos deben ser definidos explícitamente (Hard-Coded) en las funciones remotas , por lo tanto si la función remota cambia de servidor requerirá cambiar el código fuente, la alternativa de RMI URL's es emplear JNDI "Java Naming Directory Interface" lo cual permite utilizar información que resida en un directorio distribuido LDAP el cual resulta más fácil modificar que código fuente.

Finalmente cabe mencionarse que bajo TCP/IP , RMI emplea el protocolo llamado JRMP ("Java Remote Method Protocol") para ejecutar métodos/funciones en los diversos objetos del sistema, esto a diferencia de CORBA que utiliza IIOP.

Serialization - Deserialization

Serialization y Deserialization asisten con el proceso de Marshalling | Unmarshalling

Contenido en Proceso

CORBA (Common Object Request Broker Arquitecture)

CORBA al igual que varias tecnologías aceptadas hoy en día es solo una especificación que fue creada en 1989 por OMG (Object Management Group). Como el nombre de la organización lo implica, CORBA establece estándares para la comunicación de objetos a través de procedimientos/métodos remotos.

"RMI" , "CORBA" - Cual es la diferencia ?

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.

IDL ("Interface Definition Language")

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

module unejemplo { 

   interface Saludos { 
	string decirHola(); 
    };

};

El fragmento anterior es una declaración muy sencilla de IDL, la cual define una interfase llamada Saludos con un método/función llamado decirHola; desde luego en IDL también pueden ser definidos cualquier estructura esperada en un lenguaje de programación: arreglos, funciones con parámetros, secuencias,etc.

IDL's = Stubs y Skeletons

Una vez definidos 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".

Como se observa en el diagrama anterior 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.

Obviamente estos Stubs y Skeletons por si solos no sirven de nada, aún faltaría implementar las funciones en el lenguaje correspondiente, en el caso descrito anterior esto equivaldría a escribir (implementar) una función llamada decirHola del lado del servidor, así como implementar otra que pudiera llamar decirHola del lado del cliente, ambas gozando de la transparencia de poder ser escritas en cualquier lenguaje.

Cabe mencionarse que la generación de estos Stubs y Skeletons se lleva acabo mediante compiladores IDL's como: IDLJava, IDLC++, IDLAda, generalmente proporcionados con el ORB ("Object Request Broker") .

ORB ("Object Request Broker")

El ORB ("Object Request Broker") es la parte medular de un sistema CORBA, ya que es a través de éste que se comunican los diversos "Stubs" y "Skeletons" generados a través de IDL, es el ORB quien ofrece la conectividad en un sistema CORBA.

Y al igual que todo producto que depende de "especificaciones" existen diversos ORB's algunos:

MICO : Una implementación Open-Source de un ORB.
ORBacus de Object Orientated Concepts (hoy en dia fusionado con Iona).
Visibroker de Borland.
OrbixWeb de Iona.
Component Broker de IBM .
Java IDL / ORB de Sun, ya incluido en todo JDK .

Finalmente cabe mencionarse que bajo TCP/IP , CORBA emplea el protocolo llamado IIOP ("Inter Orb Protocol") para ejecutar métodos/funciones en los diversos objetos del sistema.

Links:

XMLRPC : Procedimientos Remotos en XML