Cuestionario sobre Invocación Remota

1. ¿Qué es la Invocación Remota?

La invocación remota es un modelo de interacción petición/respuesta común en muchas aplicaciones. Un cliente envía una petición a un servidor, especificando el método y los argumentos, y espera la respuesta. El servidor procesa la petición y devuelve una respuesta. Este modelo es la base del protocolo HTTP. Aunque similar a una llamada a subrutina local, difiere en aspectos clave:

• La red entre cliente y servidor puede fallar, perder, retrasar o desordenar mensajes.
• Cliente y servidor pueden fallar independientemente.
• Puede ser difícil determinar si un fallo ocurrió antes, durante o después de la ejecución de la operación.
• Las máquinas pueden tener arquitecturas y formatos de datos diferentes.

2. Diseño de la Invocación Remota

La Invocación Remota se modela a partir de la Invocación Local (IL), pero se ejecuta en un proceso diferente. A diferencia de la IL, donde el tiempo de espera puede ser ilimitado, en la Invocación Remota esto es inaceptable. Se basa en una semántica de protocolo petición-respuesta.

3. Alternativas para Tratar Errores en la Invocación Remota

Existen varias alternativas para manejar errores:

• Temporizadores y Reenvíos (en origen): Para evitar la pérdida de mensajes de petición.
• Reejecución (en destino): Para manejar la pérdida de mensajes de petición, aplicable a operaciones idempotentes (aquellas que no alteran el resultado si se ejecutan múltiples veces).
• Historial de Peticiones, Filtrado y Retransmisión (en destino): Para evitar la reejecución de operaciones no idempotentes.

4. Tipos de Semánticas en la Invocación Remota

Existen tres tipos principales de semántica:

• Tal vez (Maybe): El cliente espera un tiempo y continúa sin saber qué ocurrió (fallo del servidor, pérdida de solicitud o respuesta).
• Al menos una vez (At-least-once): El cliente reintenta después de un tiempo de espera. El servidor no filtra duplicados. El cliente puede recibir múltiples respuestas. Solo es válido para operaciones idempotentes.
  • Ejemplo de operaciones idempotentes: Sumar(a,b), UniónConjuntos(A,B)
  • Ejemplo de operaciones no idempotentes: Concatenar(lista1, lista2)
• Como mucho una vez (At-most-once): El cliente reintenta. El servidor filtra duplicados usando un historial de servicios. El proceso en el servidor se ejecuta una vez o ninguna.
  • Una vez: El servidor no falló y el cliente recibió una respuesta.
  • Cero veces: El cliente recibe un informe de error.

5. Modelos de Programación en la Invocación Remota

• Llamada a Procedimiento Remoto (RPC): Un programa cliente llama a procedimientos en programas servidores.
• Invocación a un Método Remoto (RMI): Un objeto en un proceso invoca métodos de otro proceso.

6. ¿Qué es RMI?

Remote Method Invocation (RMI) es una tecnología de Sun Microsystems (ahora Oracle) que permite la colaboración entre objetos ubicados en diferentes máquinas. Facilita la comunicación entre Objetos Remotos sin necesidad de que el programador gestione protocolos de red de bajo nivel. La idea es que un objeto cliente pueda realizar una solicitud de datos a un objeto remoto.

7. Invocación Remota de Objetos

RMI permite a un objeto en una máquina llamar a métodos de un objeto en otra máquina. RMI se encarga de los detalles del envío de parámetros, la activación del objeto remoto para ejecutar el método y la devolución de los valores al llamador.

8. Roles Cliente-Servidor en RMI

• Marshalling: Proceso de codificación de los parámetros para su transmisión.
• Stub: Objeto en el lado del cliente que encapsula el método remoto. Hace que la llamada remota parezca una llamada local. Prepara la información: identificación del objeto remoto, método a invocar y codificación de parámetros (Marshalling).
• Skeleton: Objeto en el lado del servidor que decodifica los parámetros, localiza el objeto, llama al método, codifica el valor de retorno y envía la información de vuelta al stub.

9. Configuración Remota de Objetos

El cliente necesita saber qué puede hacer con los objetos del servidor. Esto se define mediante una interfaz que reside tanto en el cliente como en el servidor. Por ejemplo, para consultar la descripción de un producto remoto, ambos lados deben implementar la interfaz Product.java.

10. Invocación de Procedimiento Remoto (RPC)

En RPC, los procesos servidores ofrecen procedimientos públicos (entry) que otros procesos pueden invocar.

11. Diferencia entre un Procedimiento Remoto (entry) y un Procedimiento Público

• Un procedimiento público se ejecuta incondicionalmente usando el hilo del proceso invocante.
• Un entry se ejecuta solo cuando se sincronizan el hilo del proceso invocante y el hilo del proceso propietario. El proceso propietario puede aceptar o no la invocación.

12. Relación entre un Procedimiento Ordinario y el Proceso Invocante

• Un mismo procedimiento puede ser llamado desde cualquier punto de un programa que tenga visibilidad sobre su nombre.
• En la llamada a un procedimiento, hay intercambio de información bidireccional (argumentos de entrada y salida).

13. Componentes de la Invocación Remota

• En el proceso propietario (Servicio) del procedimiento remoto: Sentencias para declarar el procedimiento remoto y aceptar su invocación.
• En el proceso invocante (Cliente): Sentencias de invocación del procedimiento.

14. Invocación Remota y Programación Orientada a Objetos

• El formalismo de sincronización por procedimientos remotos está diseñado para implementar objetos que se comunican según el paradigma cliente-servidor.
• Objetos activos: Se implementan como procesos que no ofrecen procedimientos remotos. Invocan procedimientos remotos de otros objetos.
• Objetos pasivos: Se implementan como procesos que ofrecen sus servicios como procedimientos remotos.
• Objetos neutros: Estructuras de datos a las que se accede mediante una interfaz de procedimientos públicos ordinarios.