t4 middle ware rmi corba parte1
Post on 16-Jul-2015
101 Views
Preview:
TRANSCRIPT
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 1/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 2/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 3/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 4/15Sistemas Distribuidos Middleware. RMI. CORBA- 4
Sistemas Distribuidos Middleware. RMI. CORBA - 4
El Modelo de las RPC Cometido de las RPC
Sistemas Distribuidos La Comunicación - 13
El Modelo de las RPC Cometidos de las RPC
TAREAS DE LAS RPC
Interfazdel
Servicio
Búsquedadel
Servidor
Gestiónde
Comunicaciones
Binding
El software que soporta las llamadas a procedimientos remotos debe ocuparse de tresimportantes tareas:
• La Interfaz del Servicio. Es decir, la integración del mecanismo de la RPC con losprogramas del cliente y del servidor, estando éstos escritos en lenguajes deprogramación convencionales. La interfaz del servicio puede estar definida en unlenguaje de programación particular o en un lenguaje de especificación de serviciosque permite la transparencia en el lenguaje de programación. El código necesariopara serializar (marshalling y unmarshalling ) los parámetros que se pasan entre elcliente y el servidor, así como el establecimiento, en el servidor, de un mecanismo(dispatcher ) que reparta las peticiones entre las rutinas de servicio apropiadas sepueden generar automáticamente con los compiladores de interfaz.
• Búsqueda del Servidor. Este proceso es el mecanismo que se describió al hablarde las funciones que ofrecen los servicios de nombres, conocido como binding , queconsiste en asignar el servidor apropiado más conveniente para el servicio que
requiere el cliente.• Gestión de la Comunicación. Esta tarea consiste simplemente en la transmisión y
recepción de los mensajes de petición y de respuesta.
Puesto que la búsqueda del servidor ya se ha tratado en las transparencias previas, enlas siguientes se pasará a ver con cierto detalle la Interfaz del Servicio. En cuanto a lagestión de la comunicación, ésta se basa directamente en servicios de comunicaciónofrecidos por el sistema operativo, por lo que aquí nos centraremos en el tratamiento deerrores, tanto de comunicación como de los fallos en el cliente o servidor.
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 5/15
Sistemas Distribuidos Middleware. RMI. CORBA- 5
Sistemas Distribuidos Middleware. RMI. CORBA - 5
Cometido de las RPC Interfaz del Servicio
Las RPC de un servicio deben construirse a partirde la definición de su interfaz
Usuario
StubCliente
Recibir Enviar
·Aplanar·Paso a XDR
·Paso a form.nativo
Llamadalocal
Retornolocal
RutinasServicio
StubServidor
Recibir Enviar
·Aplanar·Paso a XDR
·Paso a form.nativo
Dispatcher Retorno
CLIENTE SERVIDOR
Módulos de Comunicaciones delS.O.
Interfaz de servicio- Lenguaje de definición- Compilador de stubs
- Represent. externa de datos
La Interfaz del Servicio
La definición de la interfaz de un servicio es la base sobre la que se construye elsoftware que necesitan los programas del cliente y del servidor para permitir la llamada aprocedimientos remotos.
En el sistema completo va a haber un proceso cliente y un proceso servidor, y cada uno
consta de los siguientes elementos:Proceso Cliente:
- Programa del usuario- Stub del cliente
Proceso Servidor:- Stub del servidor (incluye el repartidor de peticiones o dispatcher )- Rutinas de servicio del servidor (las que realizan la operación solicitada).
El programa del usuario y las rutinas de servicio del servidor deben ser escritas por el
programador. Sin embargo, los stubs del cliente y del servidor normalmente se generande manera automática mediante un compilador de interfaces. Dentro de las tareas quese realizan dentro de estos stubs figura el paso de parámetros entre las máquinasinvolucradas. En los stubs también se realizan las llamadas al sistema relativas almódulo de comunicación del sistema operativo subyacente.
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 6/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 7/15
Sistemas Distribuidos Middleware. RMI. CORBA- 7
Sistemas Distribuidos Middleware. RMI. CORBA - 7
Interfaz del Servicio ...Generación de Stubs
CLIENTE
UsuarioProgramador
InterfazGenérica en IDL
UsuarioProgramador
InterfazGenérica en IDL
Programa delUsuario
Generador deInterfaces
Interfaz enLeng. Fuente_C
Stub delCliente
Compilador delLeng. Fuente_C
Compilador delLeng. Fuente_C
Programa Obj_Cdel Usuario
Stub Obj_Cdel Cliente
L i n k e r
Cliente CompletoEjecutable en
Máquina_C
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 8/15
Sistemas Distribuidos Middleware. RMI. CORBA- 8
Sistemas Distribuidos Middleware. RMI. CORBA - 8
Interfaz del Servicio ...Generación de Stubs
SERVIDOR
Programadordel Servidor
InterfazGenérica en IDL
InterfazGenérica en IDL
Cuerpo de lasRutinas de Servicio
Generador deInterfaces
Interfaz enLeng. Fuente_S
Stub Fuente_Sdel Servidor+ Dispatcher
Compilador del
Leng. Fuente_S
Compilador del
Leng. Fuente_S
Programa Obj_S de lasRutinas de Servicio
Stub Obj_Sdel Servidor
L i n k e r
Servidor CompletoEjecutable en
Máquina_S
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 9/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 10/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 11/15
Sistemas Distribuidos Middleware. RMI. CORBA- 11
Sistemas Distribuidos Middleware. RMI. CORBA - 11
Interfaz del Servicio ...Un Ejemplo
procedure Stub_Servidor_Reloj is
Mensaje: string (1..32);
M: system.address;
OK: boolean;
Operación: Operaciones;
t: Tiempos;
begin
loop
Recibir (Mensaje);
M = Mensaje’address;
M = UnMarshall (M, Remitente);
M = UnMarshall (M, Operación);
case Operación is
when SET_TIME =>
M = UnMarshall (M, t);
M = Mensaje’address;
OK = Poner_Hora (t);
Marshall (M, OK);
when GET_TIME =>
/* Codigo para deserializar
datos y llamar a Pedir_Hora
*/
end case;
Envia_Mensaje (Remitente, Mensaje);
end loop;
end Stub_Servidor_Reloj;
Stub delServidor del Reloj
Pasemos ahora a ver el aspecto del stub del servidor. Como veremos, tiene unaestructura muy distinta a la del cliente, pues el stub del servidor es un proceso querecibe peticiones de distinto tipo de todos los clientes.
El stub del servidor debe averiguar el tipo de petición que le envía el cliente, deserializarde los datos del mensaje (o unmarshalling ) y pasárselos, como parámetros de entrada, ala rutina de servicio que ejecutará la operación solicitada por el cliente.
Como se puede apreciar en el código del ejemplo, el stub del servidor consta de unbucle infinito, y en cada iteración del bucle atiende una solicitud de un cliente. Así, nosencontramos con que en primer lugar llama a la primitiva Recibir para recoger unmensaje con la petición de un cliente. Una vez recibido un mensaje, averigua el tipo deoperación solicitada (Operación), y en función de la operación requerida, extrae ydeserializa los datos del mensaje, y los utiliza como parámetros de entrada en lallamada a la rutina de servicio correspondiente.
En el ejemplo se muestra en detalle el código correspondiente a una solicitud de la
operación SET_TIME. Como vemos, extrae y deserializa los datos del mensaje mediantela función UnMarshall, para formar la estructura local de tipo Tiempos. A continuaciónllama a la rutina de servicio Poner_Hora pasándole como parámetro de entrada laestructura t.
La rutina Poner_Hora (que es local) tras su ejecución devuelve un código de resultadoOK, indicando si la operación se pudo realizar o no. El stub del servidor entonces tomaeste código de resultado, lo serializa y lo pone en el mensaje de respuesta.
Lo último que le queda por hacer al stub del servidor es enviar el mensaje de respuesta
al cliente (concretamente al stub del cliente). Hecho esto, se vuelve al principio del bucledonde se espera por un nuevo mensaje de algún cliente.
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 12/15
Sistemas Distribuidos Middleware. RMI. CORBA- 12
Sistemas Distribuidos Middleware. RMI. CORBA - 12
Cometido de las RPC Tratamiento de Errores
TIPOS DE ERRORES EN LA
EJECUCIÓN DE UNA RPC
ERRORES DECOMUNICACIÓN
FALLO EN ELSERVIDOR
FALLO ENEL CLIENTE
- No se puedelocalizar al servidor
- Pérdida de mensajesde petición
- Pérdida de mensajesde respuesta
- Parámetros incorrectos,Op. no permitida,Fin de Fichero.
- Caída del Servidor
- Caída del Cliente
En las RPC se producen errores queno se dan en las llamadas locales
Hay que tratarlos en el Cliente
Puede mantenersele abstraído alusuario de esta diferencia con las
llamadas locales¿ ?
Tratamiento de Errores. El objetivo de las RPC es abstraer al usuario de lacomunicación que implica una llamada a un procedimiento remoto, haciéndola parecerigual que las llamadas locales; y, excepto por el hecho de que no se puede acceder a lasvariables globales, tal abstracción se consigue bastante bien.
Esto es así siempre que el cliente y el servidor funcionen correctamente. Pero losproblemas surgen cuando aparecen los errores; entonces ya no es tan fácil enmascarar
una llamada a procedimiento remoto bajo una llamada local. Veamos a continuación lostipos de errores que pueden surgir y qué se puede hacer con ellos.
En principio puede haber tres tipos principales de problemas:
Errores de Comunicación.- No se puede localizar al servidor- Pérdida de mensajes de petición- Pérdida de mensajes de respuesta.
Fallo en el Servidor
- Error por parámetros incorrectos, operación no permitida, etc.- Caída del Servidor
Fallo en el Cliente.
- Caída del cliente
En las transparencias siguientes veremos con cierto detalle cómo pueden tratarse cadauna de estas situaciones.
Como veremos, debido a estos errores, en las RPC debe incluirse código adicional paratratarlos convenientemente, lo cual hace dudar sobre si las RPC deben ser totalmentetransparentes al usuario o se le deben ofrecer a éste primitivas distintas para que seaconsciente del tratamiento que le debe dar a cada situación de error.
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 13/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 14/15
5/14/2018 T4 Middle Ware RMI CORBA Parte1 - slidepdf.com
http://slidepdf.com/reader/full/t4-middle-ware-rmi-corba-parte1 15/15
top related