Comunicación de objetos distribuidos

En un entorno de computación distribuida , la comunicación entre objetos distribuidos permite la comunicación entre ellos . Su función principal es permitir que los objetos accedan a datos e invoquen métodos en objetos remotos (objetos que residen en memoria no local). La invocación de un método en un objeto remoto se conoce como invocación de método remoto ( RMI ) o invocación remota , y es el equivalente en programación orientada a objetos de una llamada a procedimiento remoto (RPC).

El método más utilizado para implementar el canal de comunicación consiste en emplear stubs y skeletons . Estos son objetos generados cuya estructura y comportamiento dependen del protocolo de comunicación elegido , pero que, en general, proporcionan funcionalidades adicionales que garantizan una comunicación fiable a través de la red.

En RMI, el programador define un stub (que es el bit en el cliente) como una interfaz . El compilador RMI (rmic) utiliza esto para crear el stub de clase. El stub realiza la verificación de tipos. El esqueleto se define en una clase que implementa el stub de interfaz. ^{[ 1 ]}

Cuando un emisor desea realizar una llamada remota al objeto llamado, delega las solicitudes a su stub , que inicia la comunicación con el esqueleto remoto . En consecuencia, el stub transmite los argumentos del emisor a través de la red al esqueleto del servidor. El esqueleto, a su vez, transmite los datos recibidos al objeto llamado, espera una respuesta y devuelve el resultado al stub del cliente. Cabe destacar que no existe comunicación directa entre el emisor y el objeto llamado.

En detalle, la comunicación consta de varios pasos:

1. El llamador invoca un procedimiento local implementado por el stub.
2. El stub serializa el tipo de llamada y los argumentos de entrada en un mensaje de solicitud.
3. El stub del cliente envía el mensaje a través de la red al servidor y bloquea el hilo de ejecución actual.
4. El esqueleto del servidor recibe el mensaje de solicitud de la red.
5. El esqueleto extrae el tipo de llamada del mensaje de solicitud y busca el procedimiento en el objeto llamado.
6. Argumentos del procedimiento de desorganización del esqueleto
7. El esqueleto ejecuta el procedimiento en el objeto llamado.
8. El objeto llamado realiza un cálculo y devuelve el resultado.
9. El esqueleto empaqueta los argumentos de salida en un mensaje de respuesta.
10. El esqueleto envía el mensaje a través de la red de vuelta al cliente.
11. El cliente stub recibe el mensaje de respuesta de la red.
12. El stub desempaqueta los argumentos de salida del mensaje.
13. El stub pasa los argumentos de salida al llamador, libera el hilo de ejecución y el llamador continúa con la ejecución.

La ventaja de esta arquitectura radica en que ni el objeto que realiza la llamada ni el objeto llamado tienen que implementar lógica relacionada con la red. Esta funcionalidad, que garantiza un canal de comunicación fiable a través de la red, se ha trasladado a la capa de stub y a la capa de esqueleto .

El objeto del lado del cliente que participa en la comunicación de objetos distribuidos se conoce como stub o proxy , y es un ejemplo de objeto proxy .

El stub actúa como puerta de enlace para los objetos del cliente y todas las solicitudes salientes a los objetos del servidor que se enrutan a través de él. El stub encapsula la funcionalidad de los objetos del cliente y, al añadir la lógica de red, garantiza un canal de comunicación fiable entre el cliente y el servidor. El stub puede escribirse manualmente o generarse automáticamente, según el protocolo de comunicación elegido.

El stub es responsable de:

• iniciando la comunicación hacia el esqueleto del servidor
• traducir llamadas del objeto que realiza la llamada
• organización de los parámetros
• informando al esqueleto que se debe invocar la llamada
• pasar argumentos al esqueleto a través de la red
• desorganización de la respuesta del esqueleto
• informar a la persona que llama que la llamada ha finalizado.

El objeto del lado del servidor que participa en la comunicación de objetos distribuidos se conoce como esqueleto (o stub; término que se evita aquí).

Un esqueleto actúa como puerta de enlace para los objetos del servidor, y todas las solicitudes de los clientes se enrutan a través de él. El esqueleto encapsula la funcionalidad de los objetos del servidor y la expone a los clientes; además, al añadir la lógica de red, garantiza un canal de comunicación fiable entre clientes y servidor. Los esqueletos pueden escribirse manualmente o generarse automáticamente, según el protocolo de comunicación elegido.

El esqueleto es responsable de:

• Traduciendo los datos entrantes del stub a las llamadas ascendentes correctas a los objetos del servidor.
• deserialización de los argumentos de los datos recibidos
• pasar argumentos a objetos del servidor
• serialización de los valores devueltos por los objetos del servidor
• enviar valores de vuelta al cliente stub a través de la red

• Objetos Distribuidos Portátiles (PDO) - Objective-C
• Arquitectura de agente de solicitud de objetos comunes (CORBA) – interlenguaje
• Invocación remota de métodos en Java (Java RMI) – Java
• Modelo de objetos de componentes distribuidos (DCOM) – Microsoft, interlenguaje

  (nótese que el stub se llama "proxy" y el esqueleto se llama "stub" ^{[ 2 ]} )

• .NET Remoting – Microsoft, interlenguaje
• DDObjects – Borland Delphi
• Ruby distribuido (DRb) – Ruby

• agente de solicitud de objetos
• Objeto distribuido

• Plášil, František y Stal, Michael. "Una visión arquitectónica de objetos y componentes distribuidos en CORBA, Java RMI y COM/DCOM". Archivado el 24 de junio de 2007 en Wayback Machine , Software Concepts & Tools (vol. 19, n.º 1) , enero de 1998.
• Druschel, Peter "Construcción de programas distribuidos" Archivado el 4 de marzo de 2016 en Wayback Machine
• Farley, Jim. Java Distributed Computing , O'Reilly, enero de 1998.
• Documentos de investigación archivados el 12 de febrero de 2008 en Wayback Machine , Grupo de Investigación de Sistemas Distribuidos, Universidad Carolina de Praga