| Artículos | 01 NOV 1998

Objetos distribuidos con Java RMI

Tags: Histórico
RMI ofrece un método simple para crear aplicaciones distribuidas con Java
Francisco Charte.

La computación distribuida cada día tiene una mayor presencia e importancia, fe de ello da el auge de tecnologías como DCOM o CORBA . Java dispone de su propia técnica, conocida como RMI, que facilita la creación y uso de objetos distribuidos

Mediante la computación distribuida es posible realizar un mejor aprovechamiento de los recursos informáticos de los que disponga una empresa o institución, dividiendo las distintas funciones a ejecutar y entregándolas a los equipos más apropiados para ello . La estructura centralizada en la que existe un host u ordenador central con terminales tontos colgados de él, la tan difundida estructura cliente/servidor o la más actual conocida como multi-tier son implementaciones, a un nivel u otro, de computación distribuida .

La mayoría de las técnicas actuales están construidas con algún mecanismo basado o derivado de RPC ( Remote Procedure Call ) . Mediante RPC es posible el envío de mensajes entre varias aplicaciones que se ejecutan en dos o más equipos independientes, usando para ello un protocolo de red . Dichos mensajes, que serían las llamadas a procedimientos remotos, van en muchas ocasiones acompañados de parámetros, lo cual supone un problema añadido . Los parámetros son datos que pertenecen a un determinado tipo, generalmente dependiente del lenguaje que se esté usando .

Es en este punto donde aparece DCE ( Distributed Computing Environment ) como un estándar que establece cuál será la representación de los tipos de datos generales en operaciones RPC, dando lugar a lo que se conoce como DCE RPC . Esa representación, a veces llamada NDR ( Network Data Representation ) , es independiente del lenguaje y el sistema, lo cual garantiza la correcta gestión de los parámetros .

Para adaptarse a DCE RPC, cualquier aplicación que quiera realizar una llamada remota tiene que efectuar una preparación previa de los parámetros, proceso conocido como marshalling . La aplicación que recibe el mensaje efectúa la operación complementaria, el unmarshalling, recuperando los parámetros originales sobre los que tiene que operar . En realidad, de estos procesos generalmente no se ocupa el programador de la aplicación, sino los mecanismos propios del modelo RPC que esté usando .

Implementaciones RPC

Actualmente existen diversas implementaciones RPC para los sistemas operativos más usados, como Windows o Unix . Los contendientes más representativos, por su difusión y respaldo, son DCOM y CORBA . Frente a ellos aparece RMI como una tercera alternativa, íntimamente ligada al lenguaje Java .

DCOM ( Distributed COM ) está basado en el modelo de componentes COM ( Component Object Model ) de Microsoft . Podríamos decir que DCOM es un COM que utiliza mecanismos DCE RPC para permitir el uso remoto de interfaces de objetos . El mayor inconveniente de DCOM es que está fundamentalmente unido a Windows, no existiendo demasiadas implementaciones para otros sistemas operativos . Esto, en un universo distribuido como el que abre Internet, es un serio inconveniente, ya que nos obliga a tener Windows en todos los puestos de trabajo .

CORBA ( Common Object Request Broker Architecture ) es una completa y compleja implementación RPC que facilita la comunicación entre objetos distribuidos con independencia del lenguaje y la plataforma, realmente un sueño hecho realidad . No obstante, siempre tiene que haber un pero, CORBA tiene fama de ser difícil tanto a la hora de crear objetos remotos como a la hora de usar dichos objetos desde otras aplicaciones .

Se podrían escribir cientos de páginas tanto hablando de DCOM como de CORBA, pero el tema que nos interesa en este artículo es RMI ( Remote Method Invocation ) . En contraposición a DCOM, se trata de una implementación independiente de la plataforma, lo que permite que tanto los objetos remotos como las aplicaciones cliente residan en sistemas heterogéneos . No contamos, sin embargo, con una independencia del lenguaje . RMI, como se ha apuntado anteriormente, está ligado estrechamente al lenguaje Java .

A pesar de todas las ventajas y desventajas que podamos deducir de estos modelos, DCOM, CORBA y RMI, seguramente el punto que inclina la balanza a favor de éste último es su facilidad . Crear un objeto remoto RMI no es mucho más complejo que crear cualquier objeto Java . Usar un objeto remoto con RMI es casi como utilizar un objeto local cualquiera .

¿ Cómo funciona RMI ?

Tras esta breve introducción, y antes de adentrarnos en los detalles de la creación de servidores y clientes RMI, veamos cuáles son los puntos fundamentales de este mecanismo . La finalidad es conseguir tener una imagen global para, posteriormente, ir analizando los diversos elementos .

Comencemos imaginando que disponemos de dos ordenadores conectados a una misma red, independientemente del tipo de ésta . Uno de ellos cuenta con un servicio que el otro necesita utilizar . Dicho servicio podría ser desde el acceso a una base de datos hasta las reglas de negocio de una aplicación . Sin embargo, tomemos un ejemplo mucho más sencillo y quizá más accesible: el primer ordenador, al que nos referiremos como servidor, dispone de una batería de lectores de CD-ROM con enormes cantidades de información, como podría ser una biblioteca digital . El otro ordenador, al que llamaremos cliente, no dispone de dicha información pero la precisa .

En lugar de facilitar a cada usuario de la empresa que lo necesite toda la batería de CD-ROM con la biblioteca, algo que resultaría bastante caro, es mucho más lógico que el servidor permita realizar consultas remotas, de tal forma que cualquier cliente pueda usar la biblioteca como si dispusiese de ella localmente . Mediante RMI, el servidor dispondrá de un objeto al que podría accederse remotamente para hacer las consultas . Para el cliente, dicho objeto aparecería como local, obteniéndose los resultados deseados .

La configuración hardware con que contamos podría ser la esbozada en la figura 1 . En este caso son dos clientes conectados al servidor mediante una red, que podría ser local o la propia Internet . El servidor dispone de la biblioteca a la que han de hacerse las consultas . Está claro que un objeto creado en uno de los clientes no puede consultar directamente la biblioteca, sino que tendrá que ejecutar un método del servidor que se encargue de este trabajo . No obstante, tampoco se puede realizar una llamada directa de un ordenador a un método de un objeto que está en otro ordenador, ya que por medio está la red .

Mediante RMI el servidor puede crear y registrar un objeto dejándolo preparado para su uso remoto . Un registro RMI se encarga de controlar las peticiones de objetos por parte de los sistemas remotos . El cliente, al crear el objeto remoto, sirviéndose de una interfaz genérica, lo que obtiene es una clase llamada stub . Las llamadas del cliente a métodos del objeto remoto son recibidas por este stub, que se encarga de preparar los parámetros que puedan existir en la llamada, enviando ésta al ordenador destinatario .

Cuando el registro RMI recibe una solicitud remota busca un esqueleto asociado al objeto servidor . Dicho esqueleto se encarga de descodificar los parámetros que acompañan a la llamada y de invocar realmente al método del objeto destinatario . Éste efectúa el proceso que le corresponda y posiblemente genera un valor de retorno, que será preparado por parte del esqueleto y devuelto por la red al stub del cliente, que a su vez lo descodificará y hará llegar al código que inicialmente realizó la llamada .

Esta es, a grandes rasgos, la idea general del funcionamiento de RMI, representada gráficamente en la figura 2 . En los puntos siguientes se analizará con detalle todo el proceso necesario para la creac

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información