SISTEMAS DISTRIBUIDOS RMI (Invocacin Remota de Mtodos) 1. Introduccin.

RMI (Remote Method Invocation) es un mecanismo que permite realizar llamadas a mtodos de objetos remotos situados en distintas (o la misma) mquinas virtuales de Java, compartiendo as recursos y carga de procesamiento a travs de varios sistemas. RMI proporciona comunicacin remota entre programas escritos en Java. Si unos de nuestros programas estn escritos en otro lenguaje, deberemos considerar la utilizacin de IDL en su lugar. Las aplicaciones RMI normalmente comprenden dos programas separados: un servidor y un cliente. Una aplicacin servidor tpica crea un montn de objetos remotos, hace accesibles unas referencias a dichos objetos remotos, y espera a que los clientes llamen a estos mtodos u objetos remotos. Una aplicacin cliente tpica obtiene una referencia remota de uno o ms objetos remotos en el servidor y llama a sus mtodos. RMI proporciona el mecanismo por el que se comunican y se pasan informacin del cliente al servidor y viceversa. Cuando es una aplicacin alguna veces nos referimos a ella como Aplicacin de Objetos Distribuidos. 2. Las aplicaciones de objetos distribuidos necesitan. Localizar Objetos Remotos Las aplicaciones pueden utilizar uno de los dos mecanismos para obtener referencias a objetos remotos. Puede registrar sus objetos remotos con la facilidad de nombrado de RMI rmiregistry. O puede pasar y devolver referencias de objetos remotos como parte de su operacin normal. Comunicar con Objetos Remotos Los detalles de la comunicacin entre objetos remotos son manejados por el RMI; para el programador, la comunicacin remota se parecer a una llmada estndard a un mtodo Java. Cargar Bytecodes para objetos que son enviados. Como RMI permite al llamador pasar objetos Java a objetos remotos, RMI proporciona el mecanismo necesario para cargar el cdigo del objeto, as como la transmisin de sus datos. La siguiente ilustracin muestra una aplicacin RMI distribuida que utiliza el registro para obtener referencias a objetos remotos. El servidor llama al registro para asociar un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y luego llama a un mtodo. Esta ilustracin tambin muestra que el sistema RMI utiliza un servidor Web existente para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor, para los objetos que necesita.

El sistema RMI utiliza un servidor Web para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor. 3. Ventajas de la Carga Dinmica de Cdigo Una de las principales y nicas caractersticas de RMI es la habilidad de descargar los bytecodes (o simplemente, cdigo) de una clase de un objeto si la clase no est definida en la mquina virtual del recibidor. Los tipos y comportamientos de un objeto, anteriormente slo disponibles en una sola mquina virtual, ahora pueden ser transmitidos a otra mquina virtual, posiblemente remota. RMI pasa los objetos por su tipo verdadero, por eso el comportamiento de dichos objetos no cambia cuando son enviados a otra mquina virtual. Esto permite que los nuevos tipos sean introducidos en mquinas virtuales remotas, y as extender el comportamiento de una aplicacin dinmicamente. El ejemplo del motor de clculo de este captulo utiliza la capacidad de RMI para introducir un nuevo comportamiento en un programa distribuido. 4. Interfaces, Objetos y Mtodos Remotos Una aplicacin distribuida construida utilizando RMI de Java, al igual que otras aplicaciones Java, est compuesta por interfaces y clases. Los interfaces definen mtodos, mientras que las clases implementan los mtodos definidos en los interfaces y, quizs, tambin definen algunos mtodos adicionales. En una aplicacin distribuida, se asume que algunas implementaciones residen en diferentes mquinas virtuales. Los objetos que tienen mtodos que pueden llamarse por distintas mquinas virtuales son los objetos remotos. Un objeto se convierte en remoto implementando un interface remoto, que tenga estas caractersticas. Un interface remoto desciende del interface java.rmi.Remote. Cada mtodo del interface declara que lanza una java.rmi.RemoteException adems de cualquier excepcin especfica de la aplicacin. El RMI trata a un objeto remoto de forma diferente a como lo hace con los objetos noremotos cuando el objeto es pasado desde una mquina virtual a otra. En vez de hacer una copia de la implementacin del objeto en la mquina virtual que lo recibe, RMI pasa un stub para un objeto remoto. El stub acta como la representacin local o proxy del objeto remoto y bsicamente, para el llamador, es la referencia remota. El llamador invoca un mtodo en el stub local que es responsable de llevar a cabo la llamada al objeto remoto.

Un stub para un objeto remoto implementa el mismo conjunto de interfaces remotos que el objeto remoto. Esto permite que el stub sea tipado a cualquiera de los interfaces que el objeto remoto implementa. Sin embargo, esto tambin significa que slo aquellos mtodos definidos en un interface remoto estn disponibles para ser llamados en la mquina virtual que lo recibe. La arquitectura RMI puede verse como un modelo de cuatro capas:

La primera capa es la de aplicacin y se corresponde con la implementacin real de las aplicaciones cliente y servidor. Aqu tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicacin que quiera que sus mtodos estn disponibles para su acceso por clientes remotos debe declarar dichos mtodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa bsicamente para "marcar" un objeto como remotamente accesible. Una vez que los mtodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implcita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explcita con una llamada al mtodo exportObject() del mismo paquete. La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interacta directamente con la capa de aplicacin. Todas las llamadas a objetos remotos y acciones junto con sus parmetros y retorno de objetos tienen lugar en esta capa. La capa 3 es la de referencia remota, y es responsable del manejo de la parte semntica de las invocaciones remotas. Tambin es responsable de la gestin de la replicacin de objetos y realizacin de tareas especficas de la implementacin con los objetos remotos, como el establecimiento de las persistencias semnticas y estrategias adecuadas para la recuperacin de conexiones perdidas. En esta capa se espera una conexin de tipo stream (stream-oriented connection) desde la capa de transporte. La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una mquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java. Toda aplicacin RMI normalmente se descompone en 2 partes:

Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque. Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

5. Estructura en capas RMI se compone de una arquitectura de tres capas:

Capa de stubs/skeletons.- Dota a clientes y servidores de una interfaz que les permite localizar objetos remotos para invocar sus mtodos como si fueran locales. Capa de referencias remotas.- Esta capa se encarga de la creacin y gestin de las referencias a objetos remotos, manteniendo para ello una tabla de objetos distribuidos. Adems, convierte las llamadas remotas en peticiones hacia la capa de transporte. Capa de transporte.- Capa de transporte del conjunto de protocolos TCP/IP. RMI por defecto usa TCP, aunque admite otros.

En las figura se muestra esquematizada la arquitectura de RMI.

Tpicamente, una aplicacin RMI est compuesta de un cliente y un servidor. El servidor se encarga de crear los objetos remotos, hacerlos accesibles y permanecer a la espera de llamadas para esos objetos remotos. El cliente debe conseguir referencias para esos objetos remotos y, en ese momento, puede hacer uso de ellas para realizar llamadas remotas. Las aplicaciones con objetos distribuidos necesitan:

Localizar los objetos remotos.- Para ello pueden hacer uso de la utilidad de bsqueda por nombres propia de RMI, rmiregistry. Comunicar con los objetos remotos.- Los detalles de la comunicacin entre objetos remotos quedan a cargo de RMI. Para el programador, la invocacin remota de mtodos es como la estndar. Cargar el cdigo de las clases para los objetos remotos.- RMI permite no slo el paso de objetos completos hacia y desde los procesos remotos sino, adems, la descarga de las clases que implementan dichos objetos desde ubicaciones remotas.

En la prctica, la comunicacin entre clientes y servidores no es directa, siempre media entre ambos unos elementos suplentes que se conocen como stub y skeleton.

Un stub acta como un proxy local de un objeto remoto. Debe implementar las mismas interfaces remotas que implementa el objeto al que representa. Cuando un objeto local llama a un mtodo de la interfaz remota de un objeto, esta llamada se realiza en realidad sobre los mtodos del stub local, desde donde se transmite hasta el objeto remoto. Por lo tanto, no hay comunicacin directa entre objetos locales y remotos sino que se realiza a travs de los elementos suplentes. El stub se encarga de realizar la conexin con la mquina virtual remota, enviar los argumentos para el mtodo especificado, esperar la respuesta y pasrsela al objeto local. El skeleton es la contrapartida del stub, es decir, acta como proxy del objeto remoto en el lado servidor. Se encarga de recibir las peticiones dirigidas al objeto servidor y devolver los resultados a quien hizo la peticin. En las versiones actuales del JDK (Java Development Kit) no es necesaria la utilizacin de los elementos skeleton.

El stub constituye la referencia al objeto remoto que representa. Evidentemente, no puede ser una referencia de memoria o un puntero, ya que los objetos local y remoto se encuentran en espacios de memoria diferentes. Al ser imposible la comunicacin directa entre objetos que residen en mquinas virtuales diferentes, se necesitan suplentes que lo permitan, y estos suplentes son el stub y skeleton. La referencia remota contendr la direccin IP del servidor, un puerto, un identificador del objeto remoto y una interfaz remota. Ambos, stub y skeleton, debern implementar las interfaces remotas de los objetos a los que estn asociados. Tanto el stub como el skeleton utilizan el mecanismo de serializacin para comunicarse con el objeto remoto. Mediante la serializacin, toda la informacin que es necesaria intercambiar (objetos pasados como argumentos, ubicacin de las clases de dichos objetos, etc.) es intercambiada como un flujo de bytes. RMI puede cargar dinmicamente nuevas clases basndose en la informacin recibida por la red. Esta informacin tiene forma de URL, puesto que hace referencia a recursos disponibles en distintas mquinas. Con este mecanismo se pueden localizar, en ubicaciones remotas, las clases necesarias para instanciar nuevos objetos en tiempo de ejecucin. Para poder cargar dinmicamente clases de mquinas remotas, RMI obliga a crear e instalar un gestor de seguridad. ste protege los accesos a los recursos del sistema por parte de cdigo ``no firmado'' que se ejecute dentro de la mquina virtual. El gestor de seguridad determina si el cdigo descargado tiene acceso al sistema de ficheros local o puede realizar cualquier otra operacin privilegiada.

Todos los programas que utilicen RMI deben instalar un gestor de seguridad o RMI no descargar las clases (concretamente las que no se encuentren en el path local) para los objetos que se reciban como parmetros. Estas restricciones aseguran que las operaciones realizadas por el cdigo descargado cumplen ciertos requisitos de seguridad. RMI proporciona un gestor de seguridad propio, RMISecurityManager. Una aplicacin RMI tambin puede definir y utilizar otra clase SecurityManager que permita un acceso menos restrictivo a los recursos del sistema, o, a partir del JDK 1.2, utilizar un fichero de privilegios que ofrezca permisos ms especficos. Estos ficheros suelen nombrarse como java.policy y, para ser utilizados como gestores de seguridad, se utiliza la propiedad java.rmi.security.policy=security.policy (suponiendo que ese es el nombre del archivo que especifica los permisos y que se encuentra en el directorio actual). La figura 3.3 muestra la operacin completa de una llamada RMI.

6. Crear Aplicaciones Distribuidas utilizando RMI Un objeto remoto en Java debe implementar la interfaz java.rmi.Remote que acta como flag para que la mquina virtual lo reconozca como tal. El paso de argumentos y los valores de retorno que admiten los mtodos remotos tiene las siguientes caractersticas:

Los tipos de datos primitivos y los objetos predefinidos de Java que implementen la interfaz java.io.Serializable se pasan por valor. Es decir, se copian del espacio de direcciones de una mquina virtual a otra. Los objetos (no remotos) cuyas clases implementen la interfaz java.io.Serializable se pasan por valor. Los objetos remotos que estn a la espera de peticiones llegadas desde los clientes no se transmiten sino que, en su lugar, se envan las referencias remotas a los mismos (instancias de un stub). Por lo tanto, puede concluirse que se envan por referencia. Los objetos (no remotos) que no implementan java.io.Serializable no pueden enviarse a un objeto remoto.

Aclarar que, en el lenguaje de programacin Java, el paso de argumentos es slo por valor, sean tipos primitivos u objetos. Cuando se utiliza la expresin paso por referencia se refiere al paso por valor de referencias remotas, es decir, el paso de los stubs.

La copia por valor se realiza mediante la serializacin de objetos. De esta forma, los objetos pueden ser enviados por los clientes en forma de flujo de bytes y pueden ser reconstruidos por los servidores en sus espacios de direcciones. Adems, se asegura que si un objeto contiene referencias a otros objetos, stas se incluyen en sus copias. 7. Servicio de Registro Remoto RMI necesita un servicio de registro de nombres para permitir que los clientes encuentren los objetos remotos. Para ello proporciona un servicio de registro propio, implementado por la aplicacin rmiregistry. El servicio de registro de RMI, debe estar en funcionamiento antes que los clientes y servidores. Si no es as, los clientes no pueden encontrar los objetos remotos ni los servidores pueden atender sus peticiones. Destacar que el servicio de registro de RMI no admite persistencia, es decir, la informacin de registro se pierde al reiniciar la aplicacin rmiregistry. Al ejecutar rmiregistry, se activa un proceso que escucha en un puerto TCP especfico. Para que un cliente pueda acceder a los servicios remotos ofrecidos por un servidor, ste deber registrarlos previamente en el rmiregistry, asocindoles un nombre lgico. El rmiregistry acta, en consecuencia, como un servidor DNS, de manera que a las bsquedas por nombre de los clientes, devuelva los stubs asociados al servicio. La figura 3.5 muestra cmo se realiza una llamada remota en RMI utilizando el servicio de registro. Por otro lado, en la figura se muestra en detalle el proceso de una llamada RMI. La secuencia completa es la siguiente: 1. Se ejecuta el servidor de registro RMI, rmiregistry, en la mquina que contendr al objeto servidor. Una vez activo, permanece a la espera de peticiones utilizando un socket de servidor. 2. Se crea un objeto en el servidor, se exporta (es decir, se deja preparado para admitir llamadas a sus mtodos por un determinado puerto) y se registra en el servicio de registro RMI con un nombre. Al registrarse se crea una instancia del skeleton, que permanece a la escucha usando un socket de servidor asociado al puerto por el que el objeto se ha hecho accesible. 3. Se crea el objeto cliente, que llamar a un mtodo de la interfaz del objeto remoto. 4. El servidor de registro enva al proceso cliente una referencia remota al objeto (stub) como un flujo de bytes serializado que el cliente utiliza para crear una instancia de ste. Este stub contiene la direccin IP del host donde reside el objeto remoto, el nmero de puerto por el que escucha y un identificador del objeto. 5. El stub serializa los argumentos y enva a la capa de referencias remotas una peticin de conexin, delegando en ella su envo. 6. La capa de referencias remotas indica a la capa de transporte que necesita abrir una conexin para enviarle el flujo de datos resultante de la serializacin. 7. La capa de transporte crea un socket de cliente para enviar dicho flujo.

8. En el host remoto, los datos llegan a la capa de transporte y el socket servidor asociado los lee. 9. La capa de referencias remotas pasa los datos al skeleton. 10. El skeleton extrae del flujo de datos serializado los objetos incluidos y pasa la llamada al objeto remoto. 11. El objeto remoto ejecuta el mtodo invocado con los argumentos proporcionados y, si corresponde, devuelve un valor al objeto skeleton. 12. El skeleton enva una peticin de conexin a la capa de referencias remotas y delega en ella el envo de la respuesta. 13. La capa de referencias remotas serializa la respuesta y enva el flujo de bytes resultante a la capa de transporte, indicndole que necesita una conexin. 14. La capa de transporte remota abre un socket de cliente y enva la respuesta al host local. 15. sta llega a la capa de transporte del host local y all un socket servidor lo transmite a la capa de referencias remotas. 16. La capa de referencias remotas extrae la informacin serializada y la enva al stub. 17. Finalmente, el stub enva el valor devuelto al objeto local.

Conjunto de paquetes de RMI La API RMI est formada por un conjunto de clases que se encuentran agrupadas en los siguientes paquetes:

java.rmi java.rmi.registry java.rmi.server

java.rmi.activation java.rmi.dgc

La figura muestra un esquema simplificado de la jerarqua de clases e interfaces del paquete java.rmi.

El paquete java.rmi Este paquete proporciona la interfaz Remote y las clases MarshalledObject, Naming y RmiSecurityManager, junto con una serie de excepciones. La interfaz Remote, que carece de mtodos, debe ser implementada por toda clase remota para que sus mtodos sean accesibles. Si no es as, Java no la reconocer como tal. Mediante una instancia de la clase MarshalledObject se puede manejar el flujo de bytes serializados de un objeto. Sus mtodos son usados internamente por RMI. La clase Naming proporciona mtodos para obtener y almacenar referencias de los objetos remotos mediante URLs. Sus mtodos ms habituales son:

public static void bind(String name, Remote object) throws AlreadyBoundException,MalformedURLException,RemoteException public static void rebind(String name, Remote object) throws RemoteException, MalformedURLException

public static void lookup(String name) throws NotBoundException,MalformedURLException,RemoteException

El mtodo bind() asocia un nombre a un objeto remoto mediante una URL, es decir, lo registra. En consecuencia, ese nombre se utiliza para localizar el objeto. Las URL's son de la forma: rmi://host:port/remote_object_name Si la especificacin dada en la URL no es correcta, se producir una excepcin del tipo MalformedURLException. El host y el puerto son opcionales, de manera que si no se incluyen se toma el host local y el puerto por defecto asociados al servicio de registro RMI. El cdigo que registra un objeto remoto en el rmiregistry, tpicamente, tiene la forma siguiente: myClass myInstance=new myClass(); Naming.bind("rmi://host:port/name,myInstance"); Este cdigo registra una instancia de la clase myClass en el rmiregistry mediante la URL especificada. La diferencia entre rebind() y bind() radica en el hecho de que el primero permite asociar un nuevo nombre a un objeto ya registrado, cambiando el actual, mientras que el segundo ocasionara una excepcin del tipo AlreadyBoundException. Por otro lado, el mtodo lookup() devuelve una referencia al objeto remoto especificado en la URL. De esta forma un proceso local puede determinar qu host est proporcionando el servicio buscado y dnde se ubica el objeto remoto. Esta referencia remota se obtiene en forma de stub, de manera que se podrn abrir conexiones hacia el host y puerto que especifica el stub y llamar a los mtodos remotos del objeto. Una llamada tpica a lookup() sera de la forma: myClass myInstance= (myClass)Naming.lookup("rmi://host:port/remote_object_name"); Por ltimo, la clase RMISecurityManager proporciona un gestor de seguridad para las aplicaciones que utilizan cdigo descargado desde un servidor. El paquete java.rmi.registry Este paquete proporciona las interfaces Registry y RegistryHandler, as como la clase LocateRegistry. La interfaz Registry define los mtodos bind(), rebind(), y lookup() (as como otros que no hemos comentado como son unbind() y list()) de la clase Naming.

Por ltimo, la clase LocateRegistry permite recuperar y, por tanto, manejar objetos Registry, que representan a los procesos que ejecutan el servicio de registro RMI, a partir de un par host-puerto. Tambin permite crear estos objetos a partir de un puerto o puertos y, si se desea, factoras de sockets RMI. Las factoras de sockets permiten establecer caractersticas comunes a los sockets que se quieren crear en una aplicacin determinada. El paquete java.rmi.server Este paquete proporciona una serie de clases, interfaces y excepciones para el lado servidor de las aplicaciones RMI. Algunas de sus clases principales son:

Clase ObjID.- Genera identificadores de objetos que los hosts declaran como remotos, proporcionando mtodos para la creacin de los mismos, lectura de stos desde flujos de bytes e insercin en ellos. Estos identificadores son los propios de un objeto remoto en una referencia remota. Clase RemoteObject.- Implementa la clase java.lang.Object (clase raz de todas las clases Java) para objetos remotos y la interfaz java.rmi.Remote. Clase RemoteServer.- Hereda de RemoteObject. Es la clase raz de la que heredan todas las implementaciones de objetos cuyos mtodos son accesibles remotamente, y proporciona la semntica bsica para el manejo de referencias remotas. Clase RemoteStub.- Hereda de RemoteObject. Es la clase raz de la que heredan todos los stubs de los clientes. Clase RMIClassLoader.- Incluye mtodos estticos para permitir la carga dinmica de clases remotas. Si un cliente o servidor de una aplicacin RMI necesita cargar una clase desde un host remoto, llama a esta clase. Clase RMISocketFatory.- Usada por RMI para obtener sockets cliente y servidor para las llamadas RMI. Clase UnicastRemoteObject.- Subclase de RemoteServer. Incluye la implementacin por defecto de los objetos remotos. Permite llamar a los mtodos remotos mediante conexiones TCP por el puerto especificado. Si se necesitan objetos remotos con un funcionamiento ms especfico, se puede extender esta clase para lograrlo. Una clase que herede de UnicastRemoteObject debe incluir un constructor que soporte excepciones del tipo RemoteException.

Algunas de sus principales interfaces son:

Interfaz RemoteRef.- Usada por los objetos RemoteStub para referirse a objetos remotos. Incluye mtodos para llamar a los mtodos de objetos remotos. Interfaz RMIClientSocketFactory.- Usada por RMI para obtener sockets clientes para las llamadas RMI. Interfaz RMIFailureHandler.- Especifica los mtodos que se encargan de manejar los fallos derivados de la creacin de ServerSockets.

Interfaz RMIServerSocketFactory.- Usada por RMI para obtener sockets servidores para las llamadas RMI. Interfaz ServerRef.- Extiende la interfaz RemoteRef y es implementada por los objetos remotos para poder acceder a sus objetos RemoteStub. Interfaz Unreferenced.- Usada para que los objetos remotos puedan recibir mensajes de aviso cuando no existan ms clientes con referencias a ellos.

El paquete java.rmi.activation Permite activar remotamente objetos, desactivarlos cuando ya no se trabaje con ellos y reactivarlos cuando sea necesario. Entre activacin y desactivacin, conservan su estado. La figura 3.9 muestra un esquema del funcionamiento de la descarga de clases desde un servidor web.

Los pasos a seguir son los siguientes: 1. Se ejecuta el cliente, indicando con la propiedad java.rmi.server.codebase el servidor web que permite la descarga de las clases 2. Se localizan los objetos remotos 3. El cliente recibe el objeto remoto (el stub) serializado 4. Se busca la definicin de la clase del objeto remoto en el servidor web especificado 5. Se recibe la clase 6. Se ejecutan los mtodos remotos requeridos

8. Conclusin RMI proporciona un mecanismo para la elaboracin de aplicaciones con objetos Java distribuidos. Al estar integrado dentro de la jerarqua de paquetes oficiales del lenguaje de programacin Java, se adapta perfectamente al modelo de programacin del mismo. RMI facilita la elaboracin de aplicaciones que sigan el modelo cliente-servidor. Dada su naturaleza, resulta muy sencillo integrar RMI con la versin empresarial del lenguaje Java (J2EE); con el objetivo de desplegar, por ejemplo, los muy extendidos servicios web. Para concluir, RMI presenta una serie de ventajas e inconvenientes: Entre sus principales ventajas destaca su sencillez, con RMI los objetos remotos se manejan como si fueran locales. Por otro lado, al existir una separacin entre interfaces e implementaciones, en una aplicacin con objetos distribuidos se pueden aprovechar las ventajas de la programacin orientada a objetos. Adems, la carga dinmica de clases permite, por ejemplo, que los clientes se conviertan en applets interpretados en un navegador. RMI proporciona un servicio de registro, rmiregistry, que facilita la localizacin por nombre de los servicios. Por ltimo, existe la posibilidad de aadir a las comunicaciones RMI protocolos de seguridad, como SSL o HTTPS. En contrapartida, uno de sus principales inconvenientes es el uso exclusivo de Java; problema parcialmente resuelto con la posibilidad, incorporada en las ltimas versiones, de trabajar con nuevos protocolos que proporcionan interoperabilidad. Por otro lado, RMI no proporciona meta informacin, es decir, no dispone de un sistema que informe de los servicios disponibles y sus Apis (nombre de mtodos, valores de retorno, etc.). Cierta consideracin merece el hecho de que, al realizar el paso de objetos por valor, cuando se serializa un objeto hay que hacerlo junto con todos aquellos de los que tiene referencias. Cuanto mayor sea el tamao de estos objetos, mayor ser el trfico entre mquinas. Por ltimo, no existe un mecanismo que controle las transacciones realizadas y acte cuando no se completen.

Sistemas Distribuidos RMI (Invocacin Remota de Mtodos)

Indice
1. 2. 3. 4. 5. 6. 7. 8. Introduccin. .......................................................................................................................................... 1 Las aplicaciones de objetos distribuidos necesitan................................................................... 1 Ventajas de la Carga Dinmica de Cdigo..................................................................................... 2 Interfaces, Objetos y Mtodos Remotos ........................................................................................ 2 Estructura en capas ............................................................................................................................. 4 Crear Aplicaciones Distribuidas utilizando RMI ........................................................................... 6 Servicio de Registro Remoto............................................................................................................. 7 Conclusin ............................................................................................................................................. 13