Universidad Mexiquense del Bicentenario

Unidad La Paz


Alumno. Torres Prez Jos Eduardo


Grupo. LI 181


Materia. Tpicos Avanzados de BDD

Profesor. Leonardo Corts Vergara









Llamada a procedimientos remotos (RPC)

Concepto y objetivos.

Idea: Ocultar/abstraer los detalles relativos a la comunicacin que son comunes a
diversas aplicaciones.

Gestin de los dilogos peticin-respuesta
Aplanamiento y formateo de datos (enteros, reales, cadenas, estructuras,...)
[marshaling, serializacin]
Aplanar: organizar datos complejos en un mensaje
Desaplanar: extraer datos complejos de un mensaje aplanado
Gestionar: representacin info. (Orden de bytes, tipos complejos, alineado en
memoria), diferencias de hardware y S.O.
Gestin de la interfaz de comunicacin (crear y configurar sockets, Conectar,
escribir, leer,...)

Aproximacin: llamada a procedimientos remotos (RPC: Remote Procedure Call)
generar automticamente el cdigo usado en esas tareas comunes
Ofrecer el entorno y los componentes de apoyo necesarios para dar soporte a esa
infraestructura

Procedimiento llamante y procedimiento llamado se ejecutan en mquinas distintas
Ofrecer la ilusin de que la llamada remota parezca idntica a una llamada local
(transparencia).

Objetivo: Proporcionar un middelware que simplifique el desarrollo de aplicaciones
distribuidas.
Evitar que programador tenga que interactuar directamente con el interfaz de
Sockets.

Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos
locales.

Se busca ofrecer un entorno de programacin lo ms similar posible a un entorno
no distribuido.

El sistema RPC oculta los detalles de implementacin de esas llamadas remotas.





Implementa la llamada remota mediante un dilogo peticin respuesta; mensaje
de peticin:
Identifica procedimiento llamado
Contiene parmetros 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).

Funcionamiento general
Proceso llamador (cliente):
Proceso realiza la llamada a una funcin.
Llamada empaqueta id. De funcin y argumentos en mensaje
Enva mensaje a otro proceso.
Queda a la espera del resultado.
Al recibirlo, lo desempaqueta y retorna el valor

Proceso llamado (servidor):
Recibe mensaje con id. De funcin y argumentos.
Se invoca funcin en el servidor.
Resultado de la funcin se empaqueta en mensaje
Se transmite mensaje de respuesta al cliente.


Ejemplos de entornos RPC
Sun-RPC (ONC-RPC: Open Network Computing-RPC): RPC muy extendido en
entornos Unix, infraestructura sobre la que se ejecuta NFS (servicio de sistema de
ficheros en red), NIS (servicio de directorio).

DCE/RPC (Distributed Computing Environmen RPC): RPC definido por la Open
Software Foundation.

Java-RMI. Invocacin de mtodos remotos en Java.

CORBA (Common Object Requesting Broker Architecture): Soporta la invocacin de
mtodos remotos bajo un paradigma orientado a objetos en diversos lenguajes.

SOAP (Simple Object Access Protocol): protocolo RPC basado en el intercambio de
datos (parametos+resultados) en formato XML.

DCOM (Distributed Component Object Model): Modelo de Objetos de
Componentes
Distribuidos de Microsoft, con elementos de DCE/RPC.

.NET Remoting: Infraestructura de invocacion remota de .NET

Diferencias con llamadas locales (LPC)
Punto clave: manejo de errores
Con RPC pueden existir fallos en servidor remoto o en la red
Deben detectarse y notificarse al llamador (cliente)

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.
RPC impone un mayor nivel de encapsulamiento.

Los parmetros para la llamada remota no pueden pasarse por referencia (solo por
valor).
Generalmente se usan mecanismos de copia y restauracin para Simular el
paso por valor.

Rendimiento de llamadas RPC mucho menor que en llamadas locales
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 mtodos de aplanado/desaplanado.

Aspectos a considerar en entornos RPC
1. Emular la semntica de las llamadas locales:
Hasta qu punto el comportamiento de una llamada remota es equivalente al de
una llamada local?
Est determinado por el entorno RPC
Punto relevante: modo de gestionar los fallos en las llamadas remotas.

2. Emular sintaxis de las llamadas locales:
Hasta qu punto la forma en que se realizan llamadas remotas desde el cdigo de
los programas clientes es idntica a la de las llamadas locales?
Punto relevante: garantizar transparencia.

Funcionamiento y principios bsicos
(a) Comportamiento ante fallos
Aspecto clave que determina la equivalencia semntica entre llamadas remotas y
llamadas locales.
Llamadas locales ofrecen una semntica exactamente una vez (ejecucin fiable).
El entorno de ejecucin de las llamadas locales garantiza que el procedimiento
llamado se ejecuta exactamente una vez.
Llamada termina devolviendo un valor de retorno si tuvo xito o una indicacin del
error (excepcin, cdigo de error) en caso de fallo.
Llamador se queda en espera indefinidamente hasta que finalice la llamada.
En RPC no es posible espera indefinida (posibilidad de fallos)
En llamadas remotas las posibles fuentes de fallos son mltiples.

1. Fallos en los procedimientos llamados.
La ejecucin del proceso llamado se detiene por errores del hardware o del sistema
operativo que lo ejecuta (ejemplo: cada del sistema).
Tambin por errores internos del propio procedimiento (divisiones por 0, ndices de
arrays fuera de rango, etc.).

2. Fallos en la comunicacin.
Perdida de la conexin: la red deja de enviar paquetes (cada de la red, perdida
de un enlace, etc.).
Corrupcin del contenido de alguno de los mensajes enviados.
Perdida de paquetes: algn mensaje/s no llega a su destino.
Recepcin fuera de orden: paquetes retrasados recibidos de forma desordenada.

3. Otros fallos: bugs en el proceso llamado, ataques, etc.
En general el proceso cliente no tiene capacidad para distinguir los diferentes tipos
de errores.
Cliente solo percibe que una o ms de sus peticiones no reciben respuesta, pero no
llega a saber por qu:
La peticin (llamada) no lleg al proceso remoto.
El servidor est cado o no ha llegado a procesar la peticin.
La peticin lleg y el servidor la proces, pero la respuesta no lleg al cliente.
Otros...

Dependiendo de los mecanismos definidos y de la semntica se puede volver a
pedir la ejecucin del procedimiento remoto o no.
La forma de gestionar los fallos por parte del entorno RPC determina la semntica
efectiva de las llamadas remotas.

Herramientas para controlar los fallos
Uso de mensajes de asentimiento (ACKs) con o sin temporizadores
(time-out):
permiten confirmar la recepcin de cada mensaje y detectar la prdida de
mensajes.
Uso de nm. de secuencia y control de duplicados:
Cliente y servidor asocian un identificador a sus mensajes.
El otro extremo mantiene lista con los IDs de los mensajes recibidos
Se mantiene una copia de los mensajes enviados ms recientemente junto
con sus IDs.



Semntica de las llamadas RPC
Dependiendo del modelo de gestin de fallos por parte del entorno RPC se pueden
soportar distintas aproximaciones a la semntica exactamente una vez de las
llamadas locales (LPC).
No es posible garantizar la semntica exactamente una vez debido a la posibilidad
de fallos de comunicacin.

Tipos de semntica en llamadas RPC (de menor a mayor complejidad):
Semntica tal-vez
Semntica al-menos-una-vez
Semntica como-mximo-una-vez

Semntica tal vez:
Procedimiento remoto puede ejecutarse una vez o ninguna.
Cliente puede recibir una respuesta o ninguna.
Funcionamiento:
Cliente enva peticin y queda a la espera un tiempo.
Si no llega respuesta dentro del tiempo de espera, continua su ejecucin.
Cliente no tiene realimentacin en caso de fallo (no sabe qu pas).
Solo admisible en aplicaciones donde se tolere la perdida de peticiones y la
recepcin de respuestas con retaso (fuera de orden).

Semntica al menos una vez.
Procedimiento remoto se ejecuta una o ms veces.
Cliente puede recibir una o ms respuestas.

Funcionamiento:
Cliente enva peticin y queda a la espera un tiempo.
Si no llega respuesta o ACK dentro del tiempo de espera, repite la peticin.
Servidor no filtra peticiones duplicadas) procedimiento remoto puede ejecutarse
repetidas veces.
Cliente puede recibir varias respuestas

Solo es aplicable cuando se usan exclusivamente operaciones idempotentes
(repetibles)
Una operacin es idempotente si se puede ejecutar varias veces resultando el
mismo efecto que si se hubiera ejecutado solo una.

Secuencia de operaciones idempotentes
Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin
afectar a su funcionamiento.



Semntica como mximo una vez.
El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse
ninguna.
Cliente recibe una respuesta o una indicacin de que no se ha ejecutado el
procedimiento remoto.
Funcionamiento:
Cliente enva peticin y queda a la espera un tiempo.
Si no llega respuesta o ACK dentro del tiempo de espera, repite la peticin.
Servidor filtra las peticiones duplicadas y guarda historial con las respuestas
enviadas (servidor con memoria) procedimiento remoto solo se ejecuta una vez.
Cliente solo recibe una respuesta si la peticin lleg y se ejecut el procedimiento,
si no recibe informe del error.

Componentes e implementacin de entornos RPC
Para ofrecer un mecanismo de llamada a procedimientos remotos sintcticamente
equivalente al de llamada local el entorno RPC debe proporcionar y dar soporte a
una infraestructura que ofrezca transparencia en la invocacin remota.

Objetivo: es deseable que el programador del sistema distribuido no perciba la
diferencia entre llamada local y llamada remota (transparencia).

Para las tareas adicionales (empaquetado de datos, comunicacin) un entorno
RPC debe ofrecer:
Cdigo adicional para soportar la llamada remota a un procedimiento concreto:
Normalmente generado de forma automtica.

Libreras y herramientas complementarias (runtime) para soportar la ejecucin del
entorno RPC

Representante del servidor en la maquina cliente (stub).
Realiza el papel de servidor en la maquina cliente.

Representante del cliente en la maquina servidor (skeleton).
Realiza el papel de cliente en la maquina servidor.

Proporcionan transparencia en la llamada remota.
Generados automticamente en base a la interfaz definida para el
procedimiento remoto.
Programador solo debe programar el cdigo del procedimiento remoto
(servidor) y el cdigo que hace la llamada remota (cliente).




Componentes tpicos de los entornos RPC.
Stubs (representante del servidor recibe la llamada del cliente).
Proporciona transparencia en el lado del cliente.
Posee un interfaz idntico al del procedimiento remoto (misma declaracin).

Cada procedimiento remoto que desee llamar el cliente debe tener su propio
stub
El cliente realiza una llamada local al procedimiento del stub como si fuera el
servidor real.
Tareas realizadas por el stub
Localiza al servidor que implemente el procedimiento remoto usando un servicio
de binding.
Empaqueta los parmetros de entrada (aplanado, marshalling) en un formato
comn para cliente y servidor.
Enva el mensaje resultante al servidor.
Espera la recepcin del mensaje de respuesta.
Extrae resultados (desaplanado, unmarshalling) y los devuelve al cliente que hizo
la llamada.
Skeleton (representante del cliente realiza la llamada al servidor).
Proporciona transparencia en el lado del servidor.
Conoce el interfaz ofrecido por el procedimiento remoto.
Cada procedimiento remoto que ofrece el servidor debe tener su propio skeleton.

Realiza llamadas locales al servidor como si fuera el cliente real
Responsable de la invocacin real al procedimiento remoto.

Tareas realizadas por el skeleton.
Registra el procedimiento en el servicio de binding.
Ejecuta bucle de espera de mensajes.
Recibe peticin.
Desempaqueta el mensaje (desaplanado, unmarshalling).
Determina que mtodo concreto invocar.
Invoca el procedimiento con los argumentos recibidos y recupera el valor
devuelto.
Empaqueta el valor devuelto (aplanado, marshalling).
Enva mensaje al stub del cliente.










WebSockets




Los WebSockets son una manera de poder comunicarse va web entre un cliente y
un servidor. A diferencia con otras tecnologas parecidas como los RESTful
WebService, es que esta tecnologa es bidireccional. El RESTful tiene que
constantemente pedir al servidor para ver si hay un cambio, y con algunas tcnicas
"push" se puede simular una comunicacin bidireccional. Con WebSockets, la
comunicacin es nativa.

Ya que estamos cerca del lanzamiento de Java EE 7 implementado en GlassFish 4.0,
veremos un pequeo esbozo de esta tecnologa.



WebSockets no es nuevo. Ya existe una norma en W3C que regula su
implementacin (aunque an est en revisin, creo que su uso ser como el HTML5..
todos lo usan asumiendo que est aprobado). Existen plugins en JQuery para
consumirlos, Dojo Toolkit ya lo tiene implementado en su extensin Dojox; en los
navegadores desde las versiones Chrome 4, Firefox 8, y Safari 5 ya est
implementado (no responder sobre MSIE)... ahora nos falta el lado del servidor, y
esto es lo que veremos en este post. En la versin Java EE 7 vendr como API para
poder montar nuestro servicio WebSockets.







Ciclo de vida de una conexin WebSocket

Las conexiones AJAX con RESTful o SOAP (y toda aplicacin web) tienen esta
particularidad:

1. El cliente se conecta al servidor,
2. se establece la comunicacin,
3. el cliente hace el requerimiento,
4. el servidor responde
5. y termin la conexin.

Si se tiene que hacer otro requerimiento, se vuelve a realizar todos los pasos
anteriores. De ah el uso de sesiones en cookies, variables locales y dems artilugios
para asegurar que la siguiente peticin se refiere al mismo cliente.




Es decir:
1. El cliente inicia la conexin con el servidor
2. Ambos se comunican. El cliente al servidor o el servidor al cliente.
3. Se termina la conexin.