LLAMADA A PROCEDIMIENTO REMOTO

LLAMADA A PROCEDIMIENTO REMOTO

RPC es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos.

El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los socketsusados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.

RPC

RPC es la transferencia sincrónica de datos y control entre dos partes de un programa distribuido a través de espacios de direcciones disjuntas. “La manera en que RPC logra hacer esto, es por medio de lo que se conoce como STUB. En el caso del STUBservidor, se conoce como SKELETON. Estos Stubs y Skeletons permiten que al momento de ser invocada la función remota esta pueda ser quot; simulada localmente quot .

Objetivos de RPC

·       Proporcionar un middelware que simplifique el desarrollo de aplicaciones distribuidas

·       Evitar que programador tenga que interactuar directamente con el interfaz de Sockets

·       Abstraer (ocultar) los detalles relativos a la red

·       El Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales

·       Se busca ofrecer un entorno de programación lo más similar posible a un entorno no distribuido.

·       El sistema RPC oculta los detalles de implementación de esas llamadas remotas Implementa la llamada remota mediante un dialogo petición respuesta -- Mensaje de petición: identifica procedimiento llamado, contiene parámetros de la llamada -- Mensaje de respuesta: contiene valor/es devuelto/s se encarga de enviar/recibir mensajes para comunicar ambas partes se encarga de gestionar los contenidos de esos mensajes (empaquetado y formateado de datos)

Diferencias con llamadas locales(LPC)

·       Punto clave: manejo de errores.

·       Con RPC pueden existir fallos en servidor remoto o en la red.

·       Acceso a variables globales y efectos laterales en el cliente no son posible

·       Procedimiento. Remoto (servidor) no tiene acceso al espacio de direcciones del cliente / imposibilidad de usar punteros.

·       RPC impone un mayor nivel de encapsulamiento

·       Los parámetros para la llamada remota no pueden pasarse por referencia (solo por valor).

·       Mayor sobrecarga en llamadas RPC (transferencia por red, aplanamiento de datos, etc.)

·       En algunos entornos se limita el intercambio de estructuras complejas, en otros se usan métodos de aplanado/desaplanado

El mecanismo de RPC

·       El stub del cliente: se encarga de empaquetar los parámetros y la solicitud, enviarlos al intermediario en el servidor, y luego esperar la respuesta, desempaquetarla y entregarla a la aplicación.

·       El programa principal del servidor (que incluye el stub y el dispatcher). se encarga de recibir peticiones, desempaquetar los parámetros, invocar la función solicitada, pasarle los parámetros, luego obtener el resultado, empaquetarlo y enviarlo al cliente.

·       Las rutinas de serialización de datos: Se debe tomar en cuenta que las máquinas cliente y servidor puedan ser de arquitectura diferente (y no compatible).

·       Servicio de binding: Responsable de la transparencia de localización, gestiona la asociación entre el nombre del procedimiento remoto (y su versión) con su localización en la maquina servidor (dirección, puertos, skeleton, etc). Realiza la búsqueda del skeleton de la implementación concreta del procedimiento remoto llamado por un cliente.

·        

Ejemplos:

·       portmapper en Sun-RPC

·       protocolo UDDI en servicios web

·       rmiregistry en Java-RMI.

Características del Stub

La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si” fuesen el cliente/servidor

·       En el lado cliente, el representante del servidor se denomina Stub (o Proxy)

·       El stub es quien proporciona transparencia en la invocación del cliente

·       El stub debe poseer llamadas con la misma declaración (forma) que el servidor

·       El cliente invoca las llamadas del stub “como si” fuese el servidor

·       El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto solicitando la “ejecución real” de la llamada

·       El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto y recupera el “resultado” de la invocación.

·       El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué dirección IP y en qué puerto hay que contactar con el extremo remoto

·       Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub

Características del Skeleton

En el lado servidor, el representante del cliente se llama Skeleton

·       El skeleton es quien proporciona transparencia en el lado del servidor

·       El skeleton debe conocer las llamadas ofrecidas por el servidor

·       El skeleton, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto solicitando la “ejecución real” de la llamada

·       El skeleton invoca la llamada del servidor “como si” fuese el cliente

·       El skeleton, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto indicando el “resultado” de la invocación. Cada procedimiento que el servidor exporte a través de RPCs requiere su propio skeleton

La Interface

La interfaz que proporciona el servidor se refiere a la “forma” de las llamadas exportadas por el servidor Una interface es el principal acuerdo entre el componente de software y el cliente. El lenguaje de definición de interfaces (IDL) fue desarrollado para que los objetos en lenguajes diferentes puedan invocarse entre sí. Corba usa CORBA IDL, Sun propone XDR para su RPC, DCE usa su IDL para RPC, Microsoft usa DCOM IDL. Un punto interesante. Es si estos IDLs exponen las interfaces de manera tal que sean comprendidos por cualquier objeto invocante.

Funcionamiento del compilador de interfaces

La Interface de RPC Para la comunicación entre el servidor y el cliente, se trabaja con interfaces, que deben ser implementadas por el servidor y/o cliente, para que los STUBs puedan realizar la transparencia para ambos. Además esto evita que deba existir una definición local real de la clase remota, es decir, en el cliente solo debe estar definida la interface, no la clase remota