comunicación en sistemas distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... ·...

157
Sistemas Operativos Distribuidos Comunicación en Sistemas Distribuidos Comunicación en Sistemas Distribuidos

Upload: others

Post on 21-Jan-2021

7 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos

Comunicación en Sistemas

Distribuidos

Comunicación en Sistemas

Distribuidos

Page 2: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos2

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Índice

• Introducción• Modelos de interacción

– Arquitectura cliente-servidor• Aspectos de diseño del sistema de comunicaciones• Paso de mensajes

– Sockets• Llamadas a procedimientos remotos (RPC)

– Sun RPC• Invocación de métodos remotos

– Java RMI y CORBA• Servicios web• Arquitecturas orientadas a servicios (SOA)

Page 3: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos3

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comunicación en SD: Alternativas

Sistema de comunicación: Espina dorsal del SDMecanismo de comunicación entre procesos:

– Memoria compartida (Distributed Shared Memory) vs. mensajesParadigmas de comunicación:

– Paso de mensajes– Llamadas a procedimientos remotos (RPC)– Invocación de métodos remotos (RMI)

• Entornos distribuidos basados en objetos– Servicios web

Patrón de comunicación:– unidifusión versus multidifusión

Modelos de interacción:– Cliente/servidor vs. Peer-to-peer

Page 4: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos4

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modelo cliente/servidor

• Dos roles diferentes en la interacción– Cliente: Solicita servicio.– Servidor: Proporciona servicio.

• Reparto de funcionalidad (HW/SW) entre cliente y servidor:– Thick Client versus Thin Client

Cliente Servidor

Interfaz de ServicioPetición (args.)

Respuesta

Resp=Código(args)

Page 5: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos5

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Cliente/servidor con proxy

• Rol adicional: Proxy (puede realizar labor de caché)

Cliente Proxy

Interfaz de Servicio 1Petición (args.)

Respuesta

Servidor

Interfaz de Servicio 2 Petición

Respuesta

Page 6: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos6

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Cliente/servidor con múltiples servidores

• Servicio con múltiples niveles:– Funcionalidad dividida en varios niveles (multi-tier)– Arquitectura típica con 3 capas:

• Presentación• Aplicación: lógica de negocio• Acceso a datos

– Cada nivel puede implementarse como un servidor– Servidores actúan como clientes de otros servidores

• Múltiples servidores cooperan para proporcionar servicio– Ejemplo: Traducir un nombre en SFD– Ejemplo: Actualización de réplicas

Page 7: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos7

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Código móvil

Requiere:– Arquitecturas homogéneas, interpretación de código o máq. virtuales

• Ejemplo: applets

Cliente Servidor

Interfaz de ServicioPetición

Código

Resp=Código(args)

Page 8: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos8

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modelo editor/subscriptor

• Subscriptor (subscriber) informa de su interés por evento– Se subscribe a una clase de mensajes

• Editor (publisher) genera un mensaje de una cierta clase– Se envía a subscriptores interesados

• Paradigma de comunicación asíncrono y desacoplado– Implementado habitualmente con sistemas de colas de mensajes– CORBA: Servicios de eventos y de notificaciones

• Ejemplo de uso: coherencia de caché en SFD– Cliente lee fichero y lo guarda en caché– Cliente queda subscrito a notificaciones para mantener coherencia– Si otro cliente modifica, SFD informa a clientes con copia

Page 9: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos9

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modelo Peer-to-Peer (P2P)

• Un único rol: Entidad• Cliente/servidor:

– Recursos= ∑servidores• P2P:

– Recursos= ∑entidades

Entidad Entidad

Interfaz de Diálogo

Entidad

Entidad

Entidad

Entidad

Entidad

Entidad

Entidad

Page 10: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos10

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Algunos aspectos de P2P

• Uso de red superpuesta (overlay): Red lógica sobre la física– Nodos de proceso como nodos de red

• Tipos de redes P2P:– Desestructuradas:

• Topología de conexión lógica arbitraria• Localización de recursos: “inundación” o servidor central o super-peers

– Estructuradas:• Topología de conexión prefijada (p.e. anillo lógico)• Localización de recursos: función hash distribuida

• Red P2P híbrida: Cliente/servidor + P2P– Pueden usarse servidores dentro de red P2P para localización– Servidor como front-end del servicio proporcionado por red P2P

Page 11: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos11

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aspectos de diseño del S. comunic.

Sistema de comunicaciones: capa sobre protocolo de transporte

Alternativas de diseño (independientes del paradigma usado):– Modo de operación síncrono o asíncrono– Fiabilidad– Comunicación con o sin conexión– Representación de datos– Eficiencia en la comunicación– Aspectos específicos del modelo cliente-servidor– Unidifusión vs. Multidifusión (Comunicación de grupo)

Page 12: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos12

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modo de operación síncrono o asíncrono

Operación asíncrona [1:8]: Emisor no se bloquea– Normalmente info. se copia a buffer

Operación síncrona (Tanenbaum): Emisor se bloquea hasta que:– nodo remoto recibe: síncrono respecto a transmisión [1:2:3:6:7:8]– proceso remoto recibe: respecto a recepción [1:2:3:4:5:6:7:8]– proceso remoto responda: respecto a respuesta [1:2:3:4:serv:5:6:7:8]

EMISOREMISOR

NúcleoEmisor

RED RECEPTORRECEPTOR

NúcleoReceptor

1

2

7

3

6

4

8 5

mensajeACK/resp.

Page 13: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos13

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas de colas de mensajes

Comunicación “convencional”– Servidor debe estar presente cuando se recibe mensaje

Comunicación “persistente”– No es necesario que proceso receptor esté presente– Sistema de comunicación guarda mientras mensaje– Comunicación débilmente acoplada– Suele ofrecer modelos punto-a-punto y editor/subscriptor– Apropiado para aplicaciones con conectividad irregular

Message-oriented middleware (MOM) – MQSeries de IBM, MQ de Microsoft, Java Message Service (JMS)

Page 14: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos14

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Fiabilidad

Servicio de comunicación debe de ser fiable:– Garantía de recepción en destino– Mantenimiento del orden– Control de flujo– Fragmentación de mensajes

Puede garantizarlo: – El protocolo de comunicación subyacente (TCP sí; UDP no)– El propio servicio de comunicación

• timeouts, ACKs, detección de duplicados, control de flujo, fragmentación/compactación de mensajes, etc.

Page 15: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos15

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comunicación con o sin conexión

• Sin conexión– Problemas de fiabilidad y limitaciones de tamaño

• Con conexión– Sobrecarga de conexión (sobretodo, si pocos datos)

• Con paso de mensajes debe elegirlo el programador• Con RPC/RMI se gestiona internamente

– Aunque Sun RPC requiere que programador lo especifique

Page 16: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos16

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Formatos de representación

Emisor y receptor misma interpretación de informaciónProblemática:

– Tamaño de datos numéricos– Orden de bytes– Formatos de texto– “Aplanamiento” (serialize) de estructuras de datos

Arquitecturalittle-endian

Dato a enviar: 5

0 0 0 5Valor: 0x224+0x216+0x28+5

Arquitecturabig-endian

Dato a recibido: 83.886.080

0 0 0 5Valor: 5x224+0x216+0x28+0

0 0 0 5

0123

3210

Page 17: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos17

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Marshalling

• Necesario aplanar y convertir info en emisor: marshalling– Y la operación inversa (unmarshalling) en receptor

• Con paso de mensajes es responsabilidad del programador• RPC/RMI lo realizan automáticamente• Alternativas:

– S. de comunicación en emisor convierte a formato de receptor• transformar a formato de cualquier receptor

– S. de comunicación en receptor convierte a su formato• transformar desde formato de cualquier emisor

– S. de comunicación en emisor convierte a formato externo• Sólo transformar de nativo a externo y viceversa• Ineficiente si formato de emisor = receptor pero ≠ de externo

Page 18: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos18

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Formato de representación externo

• Mejor si es estándar• La información de tipos puede ser implícita o explícita:

– Implícita:• emisor y receptor conocen tipos de parámetros• no viaja info. de tipos con datos• Ejemplos: XDR de Sun (RFC 1832) y CDR de CORBA

– Explícita:• info. explícita de tipos asociada con datos• Ejemplos: Java RMI y XML usado en web services• Permite reflexión

Page 19: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos19

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Protocolos basados en texto vs. binarios

• Marshalling más sencillo con protocolos basados en texto• Además, más fácil de interpretar por usuarios

– Pero menos eficiente• Formato binario:

– XDR, CDR y Java RMI• Formato texto:

– Web services (XML)

• Por ejemplo HTTP:“GET //www.fi.upm.es HTTP/1.1”

Page 20: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos20

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Eficiencia en la comunicación

• Fundamental minimizar copias de información• Ejemplo: transferencia de entero N y string S

– Opción 1: Definir estructura E y copiar N y S en E• Requiere copia

– Opción 2: Usar dos transferencias• Mayor consumo de ancho de banda y nº de llamadas

– Opción 3: Usar primitivas de tipo scatter/gather (readv, writev)• Una sola transferencia sin usar copia

• Con paso de mensajes es responsabilidad del programador• Queda fuera de exposición aspectos de QoS en comunicación

– Garantías en ancho de banda, retardo, pérdidas de mensajes, ...– Requerida en SD multimedia y de tiempo real

Page 21: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos21

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aspectos de diseño de cliente/servidor

Se van a considerar 4 aspectos específicos:

• Identificación del servicio• Esquemas de servicio a múltiples clientes• Servicio con estado o sin estado• Comportamiento del servicio ante fallos

Page 22: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos22

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Identificación del servicio

• Cliente debe especificar identificador de servicio– Localización del servidor (binding)

• Características deseables de ID de un servicio:– Ámbito global– Uso de nombres de texto

• Mejor jerárquicos (como pathnames)– Transparencia de ubicación– Posibilidad de migración de servicio

• Incluso en mitad de un servicio– Convivencia de múltiples versiones del servicio

• Suele estar englobado en un mecanismo más general– Servicio de nombres o de directorio

• Gestiona la identificación de todos los recursos del SD

Page 23: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos23

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Alternativas en la ID del servicio

• Dirección de punto de comunicación del servidor (IP+puerto)– No proporciona transparencia

• Nombre de texto + dir. servidor (p.e. Java RMI con Registry)– Servidor (binder) en cada nodo: nombre de servicio → puerto– Impide cualquier tipo de migración

• Nombre de texto con ámbito global (p.e. CORBA)– Servidor con ubicación conocida en el sistema:

• nombre de servicio → [IP+puerto]– Uso de caché en clientes para evitar repetir traducción– Puede haber nivel adicional para facilitar migración durante servicio

• nombre de servicio → [ID binario interno] → [IP+puerto]• Necesidad de proceso de localización

– Broadcast o Servidor de localización

Page 24: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos24

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Binding

• Modo de operación habitual:– Servidor:

• Elige puerto local (normalmente efímero)• Informa a binder del alta:

– (id. servicio + versión) = (máquina + puerto + protocolo)• Al terminar, notifica la baja a binder :

– Eliminar (id. servicio + versión)– Cliente:

• Consulta a binder– (id. servicio + versión) → (máquina + puerto + protocolo)

Page 25: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos25

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicio a múltiples clientes

• Servidor secuencial– Único flujo de ejecución atiende múltiples peticiones

• Operaciones asíncronas y/o espera por múltiples eventos (select/poll)– Uso de “máquina de estados” para seguimiento de clientes– Solución compleja y que no aprovecha paralelismo HW

• Servidor concurrente– Solución más natural y que aprovecha paralelismo HW– Threads (T) vs. Procesos (P)

• Generalmente threads: Más ligeros y comparten más recursos– Alternativas en diseño de solución concurrente

• Otra opción: construir servidor en núcleo de SO– Más eficiente pero poco flexible y difícil de mantener

Page 26: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos26

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicio concurrente: alternativas

• Creación dinámica de T/P según llegan peticiones– Sobrecarga

• Conjunto de N T/P pre-arrancados:– Al finalizar trabajo, en espera de más peticiones– Poca carga → gasto innecesario– Mucha carga → insuficientes

• Esquema híbrido con mínimo m y máximo M– m pre-arrancados; m ≤ T/P ≤ M– Si petición, ninguno libre y nº < M → se crea– Si inactivo tiempo prefijado y nº > m → se destruye

• Con paso de mensajes es responsabilidad del programador

Page 27: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos27

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicio con/sin estado

• ¿Servidor mantiene información de clientes?• Ventajas de servicio con estado:

– Mensajes de petición más cortos– Mejor rendimiento (se mantiene información en memoria)– Favorece optimización de servicio: estrategias predictivas

• Ventajas de servicio sin estado:– Más tolerantes a fallos (ante rearranque del servidor).

• Peticiones autocontenidas.– Reduce nº de mensajes: no comienzos/finales de sesión.– Más económicos para servidor (no consume memoria)

• Servicios inherentes con estado (cerrojos distribuidos).• Estado sobre servicios sin estado (HTTP+cookies).

Page 28: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos28

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comportamiento del servicio ante fallos

• ¿Qué se garantiza con respecto al servicio ante fallos?– Nada: Servicio puede ejecutar 0 a N veces– Al menos una vez (1 a N veces) – Como mucho una vez (0 ó 1 vez)– Exactamente una vez: Sería lo deseable

• Operaciones repetibles (idempotentes)– Cuenta += cantidad (NO)– Cuenta = cantidad (SÍ)

• Operación idempotente + al menos 1 vez ≈ exactamente 1• Tipos de fallos:

– Pérdida de petición o de respuesta (sólo si comunicación no fiable)– Caída del servidor

Page 29: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos29

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Fallos con comunicación fiable

• Si cae servidor no siempre puede saber si ejecutado servicio• Semántica de como mucho una vez

– Si llega respuesta, se ha ejecutado exactamente una vez– Si no llega (servidor caído), se ha ejecutado 0 ó 1 vez

• Para semántica al menos una vez (con ops. idempotentes)– Retransmitir hasta respuesta (servidor se recupere) o fin de plazo– Usar un sistema de transacciones distribuidas

Page 30: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos30

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Fallos con comunicación no fiable

• Pérdida de petición/respuesta– Si no respuesta, retransmisión cuando se cumple plazo– Nº de secuencia en mensaje– Si pérdida de petición, retransmisión no causa problemas– Si pérdida de respuesta, retransmisión causa re-ejecución

• Si operación idempotente, no es erróneo pero gasta recursos• Si no, es erróneo

– Se puede guardar histórico de respuestas (caché de respuestas):• Si nº de secuencia duplicado, no se ejecuta pero manda respuesta

• Caída del servidor– Si llega finalmente respuesta, semántica de al menos una vez– Si no llega, no hay ninguna garantía (0 a N veces)

Page 31: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos31

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comunicación de grupo

Destino de mensaje → grupo de procesos: multidifusiónPosibles usos en sistemas distribuidos:

– Datos replicados: actualizaciones múltiples.– Servicios replicados.– Operaciones colectivas en cálculo paralelo

Implementación depende de si red tiene multicast (IP-multicast)– Si no, se implementa enviando N mensajes

Un proceso puede pertenecer a varios gruposExiste una dirección de grupoEl grupo suele tener carácter dinámico

– Se pueden incorporar y retirar procesos del grupo– Gestión de pertenencia debe coordinarse con la comunicación

Page 32: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos32

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aspectos de diseño de com. de grupo

• Modelos de grupos:– Abierto. Proceso externo puede mandar mensaje a grupo

• Suele usarse para datos o servicios replicados– Cerrado. Sólo procesos del grupo pueden mandar mensajes

• Suele usarse en procesamiento paralelo• Atomicidad: o reciben el mensaje o ninguno

• Con unidifusión fiable (TCP): en medio, se puede caer emisor• Con multicast IP: pérdida de mensajes

• Orden de recepción de los mensajes– FIFO: mensajes de misma fuente llegan en orden de envío

• No garantía sobre mensajes de distintos emisores– Causal: entrega respeta relación “causa-efecto”

• Si no hay relación, no garantiza ningún orden de entrega – Total: Todos los mensajes recibidos en mismo orden por todos

Page 33: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos

Paso de mensajesPaso de mensajes

•Sockets

Page 34: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos34

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Primitivas de paso de mensajes

Operaciones básicas para envío y recepción.Generalmente, con un modo de operación asíncrono:

– Envío no bloqueante y Recepción bloqueantePueden ser con conexión o sin conexión

– con conexión:• existen primitivas para conectar y desconectar• operaciones de envío y recepción no incluyen direcciones

– sin conexión:• operaciones de envío y recepción incluyen direcciones

Evaluación del paradigma de paso de mensajes:– Programación compleja– Aplicable a cualquier modelo de interacción (clie-serv, peer-to-peer)– Puede ser el único disponible en plataformas con recursos limitados– Puede requerirse por eficiencia o restricciones en uso de recursos

Page 35: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos35

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Cliente-servidor con paso de mensajes

CLIENTEmsj

envío(msj,dir)msj

SERVIDOR msj

recepción(msj,dir)

Mensaje msj,resp;msj.op=OP1;msj.args=ARGS;envío(msj,dir_servidor);recepción(&resp, NULL);...

while (TRUE) {Mensaje msj,resp;recepción(&msj,&dir_clie);switch(msj.op) {case OP1:resp=hacer_OP1(msj.args);

case OP2:resp=hacer_OP2(msj.args);

...}envío(resp,dir_clie);

}

Page 36: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos36

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Cliente-servidor con paso de mensajes

• El programador debe de ocuparse de aspectos tales como:– Elección de formato de representación y marshalling– Si comunicación no fiable, garantizar envío de mensajes– Asegurar semántica de comportamiento ante fallos– Realizar binding– Si limitación en tamaño de mensajes, fragmentación y compactación– Minimizar copias en la transmisión– Gestión de esquema de concurrencia elegido– Gestión de conexiones (si se usa esquema con conexión)

• 1 conexión por cada petición (como HTTP/1.0)– conexión, envío de petición, recepción de respuesta, cierre de conexión– Más sencillo pero mayor sobrecarga (¡9 mensajes con TCP!)

• Varias peticiones de cliente usan misma conexión (como HTTP/1.1)– Más complejo pero menor sobrecarga

Page 37: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos37

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sockets

Aparecieron en 1981 en UNIX BSD 4.2– Intento de incluir TCP/IP en UNIX.– Diseño independiente del protocolo de comunicación.

Un socket es punto final de comunicación (dir. IP y puerto).Abstracción que:

– Ofrece interfaz de acceso a servicios de red en nivel de transporte– Representa extremo de comunicación bidireccional.

Actualmente:– Disponibles en casi todos UNIX y prácticamente todos los SSOO

• WinSock: API de sockets de Windows.– En Java como clase nativa.

Page 38: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos38

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Conceptos básicos sobre sockets

• Dominios de comunicación.• Tipos de sockets.• Creación de un socket.• Direcciones de sockets.• Asignación de direcciones.• Solicitud de conexión.• Preparar para aceptar conexiones.• Aceptar una conexión.• Transferencia de datos.

1.- Creación del socket

2.- Asignación de dirección

913367377

3.- Aceptación de conexión

Page 39: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos39

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Dominios de comunicación

• Un dominio representa una familia de protocolos.• Un socket está asociado a un dominio desde su creación.• Sólo se pueden comunicar sockets del mismo dominio.• Los servicios de sockets son independientes del dominio.

Algunos ejemplos:– PF_UNIX (o PF_LOCAL): comunicación dentro de una máquina.– PF_INET: comunicación usando protocolos TCP/IP.

Page 40: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos40

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Tipos de sockets

• Stream (SOCK_STREAM):– Orientado a conexión.– Fiable, se asegura el orden de entrega de mensajes.– No mantiene separación entre mensajes (stream).– Si PF_INET se corresponde con el protocolo TCP.

• Datagrama (SOCK_DGRAM):– Sin conexión.– No fiable, no se asegura el orden en la entrega.– Mantiene la separación entre mensajes.– Si PF_INET se corresponde con el protocolo UDP.

• Raw (SOCK_RAW):– Permite el acceso a los protocolos internos como IP.

Page 41: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos41

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Creación de un socket

La función socket crea uno nuevo:int socket(int dom,int tipo,int proto)– Devuelve un descriptor de fichero (igual que un open de fichero).– Dominio (dom): PF_XXX– Tipo de socket (tipo): SOCK_XXX– Protocolo (proto): Dependiente del dominio y del tipo:

• 0 elige el más adecuado.• Especificados en /etc/protocols.

El socket creado no tiene dirección asignada.

Page 42: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos42

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Direcciones de sockets

• Cada socket debe tener asignada una dirección única.• Dependientes del dominio.• Las direcciones se usan al:

– Asignar una dirección local a un socket (bind).– Especificar una dirección remota (connect o sendto).

• Se utiliza la estructura genérica de dirección: – struct sockaddr mi_dir;

• Cada dominio usa una estructura específica.– Uso de cast en las llamadas.– Direcciones en PF_INET (struct sockaddr_in).– Direcciones en PF_UNIX (struct sockaddr_un).

Page 43: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos43

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Direcciones de sockets en PF_INET

Una dirección destino viene determinada por:– Dirección del host: 32 bits.– Puerto de servicio: 16 bits (Reservados: 0..1023)

• Espacio de puertos TCP y UDP independientesEstructura struct sockaddr_in:

– Debe iniciarse a 0 (bzero).– sin_family: dominio (AF_INET).– sin_port: puerto.– sin_addr: dirección del host.

Una transmisión está caracterizada por cinco parámetros únicos:– Dirección host y puerto origen.– Dirección host y puerto destino.– Protocolo de transporte (UDP o TCP).

Page 44: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos44

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Obtención de la dirección del host

Usuarios manejan direcciones en forma de texto:– decimal-punto: 138.100.8.100– dominio-punto: laurel.datsi.fi.upm.es

• Conversión a binario desde decimal-punto:int inet_aton(char *str,struct in_addr *dir)

• str: contiene la cadena a convertir.• dir: resultado de la conversión en formato de red.

• Conversión a binario desde dominio-punto:struct hostent *gethostbyname(char *str)

• str: cadena a convertir.• Devuelve la estructura que describe al host.

Page 45: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos45

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Asignación de direcciones

La asignación de una dirección a un socket ya creado:int bind(int s,struct sockaddr* dir,int tam)– Socket (s): Ya debe estar creado.– Dirección a asignar (dir): Estructura dependiendo del dominio.– Tamaño de la dirección (tam): sizeof().

Direcciones en dominio PF_INET– Si se le indica puerto 0, el sistema elige uno (puerto efímero).– Host: una dirección IP de la máquina local.

• INADDR_ANY: elige cualquiera de la máquina.

Si no se asigna dirección (típico en clientes)– automáticamente en primer uso (connect o sendto).

Page 46: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos46

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Solicitud de conexión

Realizada en el cliente por medio de la función:int connect(int s,struct sockaddr* d,int tam) – Socket creado (s).– Dirección del servidor (d).– Tamaño de la dirección (tam).

Un socket stream sólo permite un único connect durante su vida– Para conectarse con el mismo u otro hay que crear un nuevo socket

Normalmente se usa con streams pero también con datagramas– Más adelante se analiza uso con datagrama

Page 47: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos47

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Preparar para aceptar conexiones

• Realizada en servidor stream después de socket y bindint listen(int sd, int baklog)– Socket (sd): Descriptor de uso del socket.– Tamaño del buffer (backlog):

• Nº máximo de peticiones pendientes de aceptar que se encolarán

• Hace que el socket quede preparado para aceptar conexiones• Con un socket se pueden aceptar nº ilimitado de conexiones

Page 48: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos48

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aceptar una conexión

Realizada en el servidor stream después de listen:int accept(int s,struct sockaddr *d,int *tam)– Socket (sd): Descriptor de uso del socket.– Dirección del cliente (d): Dirección del socket del cliente devuelta.– Tamaño de la dirección (tam): Parámetro valor-resultado

• Antes de la llamada: tamaño de dir• Después de la llamada: tamaño de dirección del cliente devuelta

Page 49: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos49

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aceptar una conexión

• Cuando se produce la conexión, el servidor obtiene:– La dirección del socket del cliente.– Un nuevo descriptor (socket) conectado al socket del cliente.

• Después de conexión quedan activos 2 sockets en el servidor:– El original para aceptar nuevas conexiones– El nuevo para enviar/recibir datos por la conexión establecida.

• Facilita construcción de servidores concurrentes– En servidores multithread, cuidado con condición de carrera en:

while (true) {n=accept(s, …);pthread_create(…, &n);}

– Solución: pasar n por valor o usar memoria dinámica• flujo principal realiza malloc y thread el free

Page 50: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos50

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Múltiples clientes con streams

• Con servidor iterativo no concurrente– Si 1 conexión por petición

• Se intercalan peticiones de los clientes (1 por iteración)– Si varias peticiones de cliente usan misma conexión

• No se trata a otro cliente hasta que no termine el actual o bien…• select: espera simultánea de más peticiones de conexión o datos

• Con servidor concurrente– Si 1 conexión por petición

• Cada thr./proc. sirve una petición y termina su labor– Si varias peticiones de cliente usan misma conexión

• Cada thr./proc. sirve peticiones hasta que cliente cierra el socket– En ambos casos también puede usarse conjunto de thr/proc o híbrido

Page 51: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos51

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Otras funcionalidades

Obtener la dirección a partir de un descriptor:– Dirección local: getsockname(). – Dirección del socket en el otro extremo: getpeername().

Transformación de valores:– De formato host a red:

• Enteros largos: htonl().• Enteros cortos: htons().

– De formato de red a host:• Enteros largos: ntohl().• Enteros cortos: ntohs().

Cerrar la conexión:– Para cerrar ambos tipos de sockets: close().

• Si el socket es de tipo stream cierra la conexión en ambos sentidos.– Para cerrar un único extremo: shutdown().

Page 52: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos52

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Transferencia de datos con streams

• Modo de operación asíncrono• Envío:

int send(int s,char *mem,int tam,int flags)• Devuelve el nº de bytes enviados.

– Puede usarse write (o writev) sobre el descriptor de socket.• Recepción:

int recv(int s,char *mem,int tam,int flags)• Devuelve el nº de bytes recibidos (0 si cliente ha cerrado socket)

– Puede usarse read (o readv) sobre el descriptor de socket.– Lectura puede devolver menos bytes de los pedidos

• Si se requiere leer N bytes hay que usar un bucle• No requiere correspondencia entre nº de send y de recv• Los flags implican aspectos avanzados

– como enviar o recibir datos urgentes (out-of-band).

Page 53: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos53

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Escenario de uso de sockets streams

Proceso cliente

Proceso servidor

socket()

socket()

bind()

listen()

accept() PosibleEjecución en Paralelo

accept()

connect()Abrir conexión

close()

Peticiónsend()/write()

Respuesta

close()

recv()/read()

send()/write()recv()/read()

Page 54: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos54

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Transferencia de datos con datagramas

Envío:int sendto(int s,char *mem,int tam,

int flags,struct sockaddr *dir, int *tam)

Recepción:int recvfrom(int s,char *mem,int tam,

int flags,struct sockaddr *dir, int *tam)

• recv (read) si no necesita conocer dir. de envío (cliente)• No se establece una conexión (connect/accept) previa.• Para usar socket basta con crear socket y reservar dirección

– En el cliente no sería necesario bind

Page 55: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos55

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Más sobre datagramas

• Mismo socket puede usarse para enviar a diferentes sockets• Por un socket puede llegar información de distintos clientes

– En stream por socket conectado llega información de un solo cliente• Se mantiene separación entre mensajes:

– Una lectura consume un mensaje– Si el tamaño leído es menor que mensaje, el resto se pierde– Correspondencia entre nº de sendto y de recv/recvfrom

• Se permite connect en socket datagrama:– No realiza conexión física: sólo especifica destino para send/write– No afecta al servidor pero…– permite que cliente pueda ser idéntico usando stream o datagrama

Page 56: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos56

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Múltiples clientes con datagramas

• Con servidor iterativo no concurrente– Las peticiones de clientes ya llegan intercaladas

• Con servidor concurrente– Después de recibir mensaje, se crea thr/proc que lo trata y responde– Puede usarse modelo dinámico, de bolsa de thr/proc o híbrido

Page 57: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos57

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Escenario de uso de sockets datagrama

Procesosocket()

bind()

close()

Peticiónsendto()

Respuestarecvfrom()

Procesosocket()

bind()

close()

recvfrom()

sendto()

Page 58: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos58

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Uso de datagramas con conexión

Petición

Respuesta

Procesosocket()

bind()

close()

recvfrom()

sendto()

Proceso clientesocket()

connect()

close()

send()/write()

recv()/read()

Page 59: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos59

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Datagramas vs streams

• Uso mayoritario de streams• Datagramas si no tolera sobrecarga y admiten pérdida de info.

– p.ej. transmisión de voz• En cliente/servidor más conveniente stream excepto si:

– Los mensajes de petición y respuesta son pequeños• No se puede tolerar la sobrecarga de la conexión• Además, si son grandes hay que fragmentar y compactar

– Las operaciones son idempotentes• Evita sobrecarga de gestionar caché de respuestas en servidor

– Se quiere dar servicio a un nº muy elevado de clientes• Datagramas no requieren tanta información en S.O. como streams

Page 60: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos60

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Configuración de opciones

Consultar opciones asociadas a un socket: getsockopt()Modificar opciones asociadas a un socket: setsockopt()Varios niveles dependiendo de protocolo afectado:

– SOL_SOCKET: opciones independientes del protocolo.– IPPROTO_TCP: nivel de protocolo TCP.– IPPTOTO_IP: nivel de protocolo IP.

Ejemplos– Nivel SOL_SOCKET. Para reutilizar direcciones:SO_REUSEADDR– Nivel IPPTOTO_IP. Para usar multicast IP: IP_MULTICAST_TTL, IP_MULTICAST_IF, IP_MULTICAST_LOOP, IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP

Page 61: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos61

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Multidifusión IP

• Implementación de comunicación de grupo sobre IP• Emisor envía datagrama a dirección IP de multidifusión

– Empieza por 1110. De 239.0.0.0 a 239.255.255.255 para temporales.• Emisor puede formar parte del grupo o no• Procesos se incorporan y abandonan el grupo• Control del ámbito de propagación mediante time-to-live:

– el host (0), la subred (1), el site (32), ...• No atomicidad.• No garantiza ningún orden de entrega

Page 62: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas Operativos Distribuidos

RPC: Llamada a procedimiento remoto

RPC: Llamada a procedimiento remoto

•RPC de Sun/ONC

Page 63: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos63

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Fundamento de las RPC

...send(msg)...receive(rpy)

...receive(msg)...send(rpy)

Paso de mensajes (visión de bajo nivel)

...

...x=buscar(1556)...

int buscar(int cod){......return val;

}

Llamadas a procedimientos remotos (más alto nivel) Comodidad

Clie

nte

Clie

nte

ServidorServidor

¿?

msg

rpy

¿?

Page 64: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos64

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Historia y evolución de las RPC

• Primeras ideas: White 1975; White se enrola en Xerox.• Desarrollo en Xerox: primer sistema de RPC Courier (1981)• Artículo clásico de Birrel y Nelson en 1984.• Sun: Open Network Computing (1985)

– RPC de Sun/ONC es la base para servicios (NFS o NIS)• Apollo (competidora de Sun) crea NCA: RPC de NCA

– HP compra Apollo; HP miembro de Open Group• Open Group: DCE (Distributed Computing Environment 1990)

– RPC de DCE basada en NCA– RPC de Microsoft basada en RPC de DCE

• RPC de Sun/ONC vs. RPC de DCE– RPC de Sun/ONC menos sofisticada pero más extendida

Page 65: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos65

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Funcionamiento general de las RPC

Cliente:– Proceso realiza la llamada a una función.– Llamada empaqueta id. de función y argumentos en mensaje– Envía mensaje a otro proceso.– Queda a la espera del resultado.

Servidor:– Recibe mensaje con id. de función y argumentos.– Se invoca función en el servidor.– Resultado de la función se empaqueta en mensaje– Se transmite mensaje de respuesta al cliente.

Objetivo: acercar la semántica de las llamadas a procedimiento convencional a un entorno distribuido (transparencia).

Page 66: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos66

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Resguardos (stubs)

• Módulos que se incluyen en cliente y en servidor– ocultan comunicación dando abstracción de llamada a procedimiento

• Generados automáticamente por software de RPC– A partir de la interfaz del servicio: Sólo dependen de ella– Son independientes de la implementación del cliente y del servidor– Heterogeneidad: disponibles para múltiples lenguajes

• Sólo hay que programar bibliotecas de servicio y aplicaciones • Dos tipos de resguardos:

– Resguardo del cliente (también llamado proxy)– Resguardo del servidor (también llamado skeleton)

Page 67: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos67

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Resguardo del cliente

• Conjunto de funciones enlazadas con la aplicación cliente– ofrecen la misma API que el servicio

• Tareas realizadas por una función del resguardo de cliente:– Localiza al servidor usando binder (identificador del servicio)– Empaqueta id. función y parámetros (marshalling) – Envía el mensaje al servidor– Espera la recepción del mensaje– Extrae resultados (unmarshalling) y los devuelve

Page 68: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos68

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Resguardo del servidor

• Programa que se enlaza en servidor con biblioteca de servicio• Tareas realizadas por resguardo de servidor:

– Registra el servicio en binder– Ejecuta bucle de espera de mensajes– Recibe petición– Si servidor concurrente, crea proceso/thread de servicio– Desempaqueta mensaje (unmarshalling)– Determina qué función invocar– Invoca función con argumentos– Empaqueta resultados (marshalling)– Envía mensaje a resguardo del cliente

Page 69: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos69

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Características de las RPC• Orientadas a modelo cliente-servidor

– En algunos sistemas también soporte de modelo editor/subscriptor• Callback RPC (p. ej. en RPC de Sun/ONC)

• Modo de operación síncrono con respecto a la respuesta– también asíncrono o síncrono respecto a recepción

• RPC se encarga automáticamente de:– Marshalling y unmarshalling + localización de servicio– Minimizar copias y control de servicio concurrente– Fiabilidad y fragmentación, si nivel de transporte lo requiere– Control de conexiones, si nivel de transporte orientado a conexión

• Normalmente implican comunicación uno a uno– En algunos sistemas Multicast y Broadcast RPC (p. ej. RPC de Sun)

• Comportamiento ante fallos garantizado por RPC– P.ej. RPC de DCE asegura por defecto como mucho una vez

• Además permite marcar una función de servicio como idempotente

Page 70: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos70

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Lenguajes de definición de interfaces

• Los resguardos se generan a partir de la interfaz de servicio– ¿Cómo se define esta interfaz?

• Deben de poder definirse entidades tales como:– Un tipo interfaz de servicio con un número de versión asociado– Prototipos de funciones, constantes, tipos de datos, …

• Tipo de parámetros: de entrada, de salida o de entrada/salida– Directivas específicas (por ejemplo, si una función es idempotente)– Sólo definiciones; nunca implementación

• Alternativa: Uso de lenguaje específico vs. uno convencional – Permite definición neutral de interfaces– Supera limitaciones en expresividad de lenguajes convencionales– Pero hay que aprenderlo...

• Procesamiento: Compilador IDL (por ejemplo para C)– fichero IDL→ fichero .h + resguardo cliente + resguardo servidor

Page 71: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos71

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de DCE[uuid(C985A380-255B-11C9-A50B-08002B0ECEF1)]interface arithmetic /* interface name is arithmetic */{

const unsigned short ARRAY_SIZE = 10;/* an integer constant */typedef long long_array[ARRAY_SIZE]; /* an array type of long */

void sum_arrays ( /* sum_arrays does not return a value */[in] long_array a, /* 1st parameter is passed in */[in] long_array b, /* 2nd parameter is passed in */[out] long_array c /* 3rd parameter is passed out */

);}

Extraído de Guide to Writing DCE Applications,John Shirley, Wei Hu, David Magid

Page 72: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos72

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Transparencia de las RPC

• ¿Una invocación remota se comporta igual que una local?• Existen varias diferencias:

– Puede producir un error si no puede comunicarse con servidor.• ¿Cómo notificarlo a la aplicación?• Generalmente, usando excepciones

– No puede haber variables globales en el servicio accesibles al cliente– Los parámetros no pueden pasarse por referencia

• Uso de copia y restauración: tratamiento de parámetro de entrada/salida– Resguardo de cliente envía copia al resguardo servidor– Resguardo de servidor se lo pasa a función real, que lo modifica– Resguardo de servidor envía a resguardo cliente nuevo valor– Resguardo cliente lo establece como nuevo valor

– Problema: parámetro de tipo estructura con punteros internos (listas)• Algunos sistemas las prohíben• Otros, como RPC de Sun, las permiten

– el resguardo del emisor las “aplana” y el del receptor las reconstruye

Page 73: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos73

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

RPC de Sun/ONC

• Estándar (RFC 1831) y disponible en muchas plataformas• Junto con XDR (External Data Representation, RFC 1832)

– Define IDL y formato de representación externo (binario e implícito)• Independiente de nivel de transporte subyacente (TCP o UDP)• Distintos tipos de autenticación de cliente (tema de seguridad)

– Sin autenticación– Modelo UNIX (uid:gid)– Basada en cifrado (DES o Kerberos)

• Secure RPC (base de Secure NFS)• Comportamiento ante fallos:

– Si se implementa sobre TCP: como mucho una vez– Sobre UDP permite activar una caché de respuestas en servidor

Page 74: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos74

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Direccionamiento en RPC de Sun/ONC

• Servicio identificado por nº de programa (32 bits) + versión– De 0 a 1FFFFFFF reservados por Sun

• Id. de servicio no tiene ámbito global– Un binder (portmap) en cada máquina

• Modo de operación:– Resguardo de servidor se da de alta en binder local:

• nº de programa + versión + protocolo + puerto (efímero) – Cliente especifica: máquina + nº de programa + versión + protocolo– Resguardo de cliente contacta con binder de máquina

• nº de programa + versión + protocolo → puerto• Herramienta rpcinfo permite contactar con binder para:

– obtener lista de servicios dados de alta, ejecutar el procedimiento nulo de un servicio para comprobar si servidor arrancado, etc.

Page 75: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos75

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

IDL (XDR) de RPC de Sun/ONC

• Extensión de C. Permite definir:– Un programa (interfaz) y su nº de versión– Constantes, tipos y funciones (hay que asignarles un número)

• Restricción: función con un 1 solo argumento y 1 solo valor de retorno• Compilador rpcgen:

– Además de .h y resguardos, genera fichero de marshalling (.xdr)• Algunos tipos específicos de XDR (además de los de C):

– Vectores de tamaño variable:• tipo_elem vector<>; tipo_elem vector<tam_max>;

– String– Union distinta de la de C: registro variante

union nombre_tipo switch (int discriminante) {case valor1: declaración1;case valor2: declaración2; default: declaraciónN;

}

Page 76: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos76

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de IDL

union respuesta_nombre switch(bool existe){case FALSE: void;case TRUE: string nombre<>;

};program RUSUARIOS_SERVICIO {

version RUSUARIOS_VERSION {int OBTENER_UID(string nombre)=1;respuesta_nombre OBTENER_NOMBRE(int uid)=2;

}=1;}=666666666;

Page 77: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos77

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

rusuarios.xrpcgen

rusuarios_svc.c

rusuariosd.c

rusuarios.h

rusuarios_xdr.c

rusuarios_clnt.c

getname.cArchivos para

el cliente

Archivoscomunes

Archivos parael servidor

Esquema de una aplicación

Page 78: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos78

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de cliente#include "rusuarios.h"int main (int argc, char *argv[]) {

CLIENT *clnt; int *result;

clnt = clnt_create (argv[1], RUSUARIOS_SERVICIO, RUSUARIOS_VERSION, "udp");

if (clnt == NULL) {clnt_pcreateerror (argv[1]); exit (1);}

result = obtener_uid_1(&argv[2], clnt);if (result == NULL) clnt_perror (clnt, "error en la llamada");else if (*result == -1) printf("%s: no existe ese usuario\n", argv[2]);else printf("%s: %d\n", argv[2], *result);

clnt_destroy (clnt); }

Page 79: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos79

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Puntos a resaltar en cliente

• Clnt_create: máquina + nº de programa + versión + protocolo• Nombre de función: NombreOriginal_nºversión

• obtener_uid_1– Argumento con un nivel de indirección

• &argv[2]– Valor de retorno con un nivel de indirección

• *result• Si NULL error en comunicación (no usa excepciones)

Page 80: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos80

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de servidor (1)#include "rusuarios.h"

int * obtener_uid_1_svc(char **argp, struct svc_req *rqstp) {static int result;struct passwd *desc_usuario;

result=-1;desc_usuario=getpwnam(*argp);if (desc_usuario)

result=desc_usuario->pw_uid;

return &result;}

Page 81: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos81

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de servidor (2)respuesta_nombre *obtener_nombre_1_svc(int *argp,struct svc_req *rqstp){

static respuesta_nombre result;struct passwd *desc_usuario;

xdr_free((xdrproc_t)xdr_respuesta_nombre, (char *)&result);desc_usuario=getpwuid(*argp);if (desc_usuario) {

result.existe=TRUE;result.respuesta_nombre_u.nombre=

strdup(desc_usuario->pw_name);}else result.existe=FALSE;

return &result; }

Page 82: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos82

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Puntos a resaltar en servidor

• Nombre de función: NombreOriginal_nºversión_svc– obtener_nombre_1_svc– Primer parámetro con un nivel de indirección

• char **argp, int *argp– Valor de retorno con un nivel de indirección

• int *, respuesta_nombre *– Segundo parámetro: descripción de petición (p.e. autenticación)

• Valor devuelto debe permanecer después de terminar función– Uso de static (static int result)– Si se necesita memoria dinámica: ¿cuándo se libera?

• Uso de xdr_free: libera memoria reservada en anterior invocación• Por omisión, servidor secuencial

– Con rpcgen se puede generar servidor concurrente

Page 83: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas Operativos Distribuidos

RMI: Invocación de método remoto

RMI: Invocación de método remoto

•Java RMI•CORBA

Page 84: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos84

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modelo de objetos en sistemas distribuidos

• Sistemas distribuidos.– Aplicaciones inherentemente distribuidas.– Se caracterizan por su complejidad.

• Sistemas orientados a objetos.– Más cercanos al lenguaje natural.– Facilitan el diseño y la programación.

Page 85: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos85

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Objetos-Distribuidos

Características:– Uso de un Middleware: Nivel de abstracción para la comunicación de

los objetos distribuidos. Oculta:• Localización de objetos.• Protocolos de comunicación.• Hardware de computadora.• Sistemas Operativos.

– Modelo de objetos distribuidos: Describe los aspectos del paradigma de objetos que es aceptado por la tecnología: Herencia, Interfaces, Excepciones, Polimorfismo, ...

– Recogida de basura (Garbage Collection): Determina los objetos que no están siendo usados para liberar recursos.

Page 86: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos86

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ventajas respecto a paso de mensajes

• Paso de mensajes:– Procesos fuertemente acoplados– Paradigma orientado a datos: No adecuado para aplicaciones muy

complejas que impliquen un gran número de peticiones y respuestas entremezcladas.

• Paradigma de objetos distribuidos– Mayor abstracción– Paradigma orientado a acciones:

• Hace hincapié en la invocación de las operaciones• Los datos toman un papel secundario

Page 87: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos87

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ventajas respecto a RPC

• Ventajas derivadas al uso de programación orientada a objetos:– Encapsulación– Reutilización– Modularidad– Dinamismo

Page 88: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos88

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Objetos distribuidos

• Minimizar las diferencias de programación entre las invocaciones de métodos remotos y las llamadas a métodos locales

• Ocultar las diferencias existentes:– Tratamiento del empaquetamiento de los datos (marshalling)– Sincronización de los eventos– Las diferencias deben quedar ocultas en la arquitectura

Page 89: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas Operativos Distribuidos

Java RMIJava RMI

Page 90: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos90

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Java RMI

• Java: Write Once, Run Anywhere• Java RMI extiende el modelo Java para la filosofía “Run

Everywhere”

Page 91: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos91

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Arquitectura de Java RMI

Service Directory

Page 92: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos92

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Arquitectura de Java RMI

• Nivel de resguardo/esqueleto (proxy/skeleton) que se encarga del aplanamiento (serialización) de los parámetros– proxy: resguardo local. Cuando un cliente realiza una invocación

remota, en realidad hace una invocación de un método del resguardo local.

– Esqueleto (skeleton): recibe las peticiones de los clientes, realiza la invocación del método y devuelve los resultados.

• Nivel de gestión de referencias remotas: interpreta y gestiona las referencias a los objetos de servicio remoto

• Nivel de transporte: se encarga de las comunicaciones y de establecer las conexiones necesarias. Basada en TCP (orientada a conexión)

Page 93: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos93

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicio de directorios

• Se pueden utilizar diferentes servicios de directorios para registrar un objeto distribuido– Ejemplo: JNDI (Java Naming and Directory Interface)

• El registro RMI, rmiregistry, es un servicio de directorios sencillo proporcionado por SDK (Java Software DevelopmentKit)

Page 94: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos94

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Java RMI

El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes:

– java.rmi– java.rmi.server

Características de Java RMI:– Se basa en una interfaz remota Java (hereda de la clase Java

Remote).– Es necesario tratar mayor número de excepciones que en el caso de

invocación de métodos locales • Errores en la comunicación entre los procesos (fallos de acceso, fallos

de conexión)• Problemas asociados a la invocación de métodos remotos (no

encontrar el objeto, el resguardo o el esqueleto)• Los métodos deben especificar la excepción RemoteException.

Page 95: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos95

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo de interfaz remota Javapublic interface InterfazEj extendsjava.rmi.Remote

{public String metodoEj1()

throws java.rmi.RemoteException;public int metodoEj2(float param)

throws java.rmi.RemoteException;}

Page 96: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos96

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Java RMI

Localización de objetos remotos:– Servidor de nombres: java.rmi.Naming

Ejemplo:Cuenta cnt = new CuentaImpl();String url = “rmi://java.Sun.COM/cuenta”;// enlazamos una url a un objeto remotojava.rmi.Naming.bind(url, cnt);

....// búsqueda de la cuentacnt=(Cuenta)java.rmi.Naming.lookup(url);

Page 97: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos97

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Desarrollo de Aplicaciones RMIDefinición de la interfaz remota

javac

(.java)

1

2

3

4

10

95

6

7

8

(.java)

usaCliente

EjectuarCliente

(.class)

CLIENTE SERVIDOR

(.class)

Esqueleto(.class)

Implementación de la interfaz remota

Esqueleto(.class)

Servidor(.class)

Arrancar RMIRegistry

Crear los objetos

Registrar los objetos

javac

rmic

Page 98: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos98

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Ejemplo

Page 99: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos99

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Modelización de la interfaz remota (Sumador)

public interface Sumador extends java.rmi.Remote{

public int sumar(int a, int b)throws java.rmi.RemoteException;

}

Page 100: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos100

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Clase que implementa la interfaz (SumadorImpl)

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;public class SumadorImpl extends UnicastRemoteObject

implements Sumador {public SumadorImpl(String name) throws RemoteException {

super();try {System.out.println("Rebind Object " + name);

Naming.rebind(name, this);} catch (Exception e){ System.out.println("Exception: " + e.getMessage());

e.printStackTrace();}

}public int sumar (int a, int b) throws RemoteException {

return a + b; }

}

Page 101: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos101

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Código del servidor (SumadorServer)

import java.rmi.*;import java.rmi.server.*;

public class SumadorServer {public static void main (String args[]) {

try {SumadorImpl misuma = new

SumadorImpl(“rmi://localhost:1099”+”/MiSumador");

} catch(Exception e) { System.err.println("System exception" +

e); }

}}

Page 102: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos102

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Registro del servicio

• Antes de arrancar el cliente y el servidor, se debe arrancar el programa rmiregistry en el servidor para el servicio de nombres. El puerto que utiliza el rmiregistry por defecto es el 1099.– rmiregistry [port_number]

• El método rebind es utilizado normalmente en lugar del método bind, porque garantiza que si un objeto remoto se registró previamente con dicho nombre, el nuevo objeto reemplazará al antiguo.

• El método rebind almacena en el registro una referencia al objeto con un URL de la forma:– rmi://<nombre máquina>:<número puerto>/<nombre referencia>

Page 103: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos103

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Código en el cliente (SumadorClient)

import java.rmi.registry.*;import java.rmi.server.*;import java.rmi.*;public class SumadorClient {

public static void main(String args[]){int res = 0;try {

System.out.println("Buscando Objeto ");Sumador misuma = (Sumador)Naming.lookup("rmi://" +

args[0] + "/" +"MiSumador");res = misuma.sumar(5, 2);System.out.println("5 + 2 = " + res);

}catch(Exception e){

System.err.println(" System exception"); }System.exit(0); }

}

Page 104: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos104

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Búsqueda

• Cualquier programa que quiera instanciar un objeto remoto debe realizar una búsqueda de la siguiente forma:Sumador misuma = (Sumador)Naming.lookup("rmi://" + args[0] +

"/" +"MiSumador");• El método lookup devuelve una referencia remota a un objeto

que implementa la interfaz remota.• El método lookup interactúa con rmiregistry.

Page 105: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos105

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Pasos

• Java RMI:– Enlace a un nombre: bind(), rebind()– Encontrar un objeto y obtener su referencia: lookup()– refObj.nombre_met()

Page 106: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos106

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Cuadro general

Cliente Servidor

Stub Skeleton

Red

op1

op2

opN

Page 107: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos107

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

¿Cómo se ejecuta?

• Compilaciónjavac Sumador.javajavac SumadorImpl.javajavac SumadorClient.javajavac SumadorServer.java

• Generación de los esqueletosrmic SumadorImpl

• Ejecución del programa de registro de RMIrmiregistry <número puerto>Por defecto, en número de puerto es el 1099

• Ejecución del servidorjava SumadorServer

• Ejecución del clientejava SumadorCliente <host-del-servidor>

Page 108: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos108

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Callback de cliente

• Hay escenarios en los que los servidores deben notificar a los clientes la ocurrencia de algún evento. Ejemplo: chat.– Problema: llamada a método remoto es unidireccional

• Posibles soluciones:– Sondeo (polling): Cada cliente realiza un sondeo al servidor,

invocando repetidas veces un método, hasta que éste devuelva un valor true.

• Problema: Técnica muy costosa (recursos del sistema)– Callback: Cada cliente interesado en la ocurrencia de un evento se

registra a sí mismo con el servidor, de modo que el servidor inicia una invocación de un método remoto del cliente cuando ocurra dicho evento.

• Las invocaciones de los métodos remotos se convierten en bidireccionales

Page 109: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos109

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Extensión de la parte cliente para callback de cliente

• El cliente debe proporcionar una interfaz remota: Interfaz remota de clientepublic interface CallbackClient extends java.rmi.Remote {

public String notificame (String mensaje) throwsjava.rmi.RemoteException;

}

• Es necesario implementar la interfaz remota de cliente, de forma análoga a la interfaz de servidor (CallbackClientImpl)

• En la clase cliente se debe añadir código para que instancie un objeto de la implementación de la interfaz remota de cliente y que se registre para callback (método implementado por el servidor):CallbackServer cs = (CallbackServer) Naming.lookup(URLregistro);CallbackClient objCallback = new CallbackClientImpl();cs.registrarCallback(objCallback);

Page 110: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos110

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Extensión de la parte servidora para callbackde cliente

• Añadir el método remoto para que el cliente se registre para callback

public void registrarCallback (CallbackClientobjCallbackClient) throws java.rmi.RemoteException;

• Se puede proporcionar un método eliminarRegistroCallbackpara poder cancelar el registro

• Ambos métodos modifican una estructura común (por ejemplo, un objeto Vector) que contiene referencias a los callbacks de clientes. Se utilizan métodos synchronized para acceder a la estructura en exclusión mutua.

Page 111: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos111

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Descarga dinámica de resguardo

• Mecanismo que permite que los clientes obtengan dinámicamente los resguardos necesarios– Elimina la necesidad de copia de la clase del resguardo en la

máquina cliente– Se transmite bajo demanda desde un servidor web a la máquina

cliente (Similar a la descarga de los applets)• El servidor exporta un objeto a través del registro RMI (registro

de una referencia remota al objeto mediante nombre simbólico) e indica el URL donde se almacena la clase resguardo.

• La clase resguardo descargada no es persistente– Se libera cuando la sesión del cliente finaliza

Page 112: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos112

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comparación RMI y Sockets

• Los sockets están más cercanos al sistema operativo, lo que implica una menor sobrecarga de ejecución.

• RMI proporciona mayor abstracción, lo que facilita el desarrollo de software. RMI es un buen candidato para el desarrollo de prototipos.

• Los sockets suelen ser independientes de plataforma y lenguaje.

Page 113: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas Operativos Distribuidos

Entornos de Objetos

Distribuidos

Entornos de Objetos

Distribuidos•CORBA

Page 114: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos114

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

OMG

(Object Management Group)

Conjunto de organizaciones que cooperan en la definición de estándares para la interoperabilidad en entornos heteregéneos.

Fundado en 1989, en la actualidad lo componen más de 700 empresas y otros organismos.

Page 115: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos115

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

OMA

(Object Management Architecture)

Arquitectura de referencia sobre cual se pueden definir aplicaciones distribuidas sobre un entorno heteregéneo. CORBA es la tecnología asociada a esta arquitectura genérica.

Formalmente esta dividida en una serie de modelos:– Modelo de Objetos– Modelo de Interacción– ...

Page 116: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos116

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

ORB

Servicios FacilidadesComúnes

Interfaces de Dominio

Aplicaciones

OMA

Una aplicación definida sobre OMA está compuesta por una serie de objetos distribuidos que cooperan entre sí. Estos objetos se clasifican en los siguientes grupos:

Page 117: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos117

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

OMA

Servicios: – Proporcionan funciones elementales necesarias para cualquier tipo

de entorno distribuido, independientemente del entorno de aplicación.

– Los tipos de funciones proporcionados son cuestiones tales como la resolución de nombres, la notificación asíncrona de eventos o la creación y migración de objetos.

– Concede un valor añadido sobre otras tecnologías (por ejemplo RMI).

– Están pensados para grandes sistemas.

Page 118: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos118

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

OMA

Aplicaciones:– El resto de funciones requeridas por una aplicación en concreto. Es

el único grupo de objetos que OMG no define, pues está compuesto por los objetos propios de cada caso concreto.

– Estos son los objetos que un sistema concreto tiene que desarrollar. El resto (servicios, facilidades) pueden venir dentro del entorno de desarrollo.

Page 119: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos119

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

OMA

ORB:– (Object Request Broker)

– Es el elemento central de la arquitectura. Proporciona las funcionalidades de interconexión entre los objetos distribuidos (servicios, facilidades y objetos de aplicación) que forman una aplicación.

– Representa un bus de comunicación entre objetos.

Page 120: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos120

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servidorvoid ingresar(long){

....

.... }

Clientex.ingresar(30)

ORB

ORB

Para posibilitar la comunicación entre dos objetos cualesquiera de una aplicación se realiza por medio del ORB. El escenario de aplicación elemental es:

Page 121: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos121

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

IDL de CORBA

(Interface Definition Language)Es el lenguaje mediante el cual se describen los métodos que un determinado objeto del entorno proporciona al resto de elementos del mismo.

interface Cuenta{

void ingresar(in long cantidad);void retirar(in long cantidad);long balance();

};

Page 122: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos122

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

IDL de CORBA

Language Mappings:– Traducen la definición IDL a un lenguaje de programación como:

• C++, • Ada, • COBOL, • SmallTalk, • Java,• ...

– Este proceso genera dos fragmentos de código denominados Stub y Skeleton que representan el código de cliente y servidor respectivamente.

Page 123: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos123

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

ORB ORB

DII Stub ORBInterface

ORBInterface

Skel. DSI

Object Adapter (OA)

Cliente Objeto Servidor

Componentes de un ORB

La arquitectura completa de comunicaciones de CORBA es la siguiente:

Page 124: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos124

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Componentes de un ORB

Stub:– Código cliente asociado al objeto remoto con el que se desea

interactuar. Simula para el cliente los métodos del objeto remoto, asociando a cada uno de los métodos una serie de funciones que realizan la comunicación con el objeto servidor.

Skeleton:– Código servidor asociado al objeto. Representa el elemento análogo

al stub del cliente. Se encarga de simular la petición remota del cliente como una petición local a la implementación real del objeto.

Page 125: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos125

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Componentes de un ORB

DII:– (Dynamic Invocation Interface)– Alternativa al uso de stubs estáticos que permite que un cliente

solicite peticiones a servidores cuyos interfaces se desconocían en fase de compilación.

DSI:– (Dynamic Skeleton Interface)– Alternativa dinámica al uso de skeletons estáticos definidos en

tiempo de compilación del objeto. Es usado por servidores que durante su ejecución pueden arrancar diferentes objetos que pueden ser desconocidos cuando se compiló el servidor.

Page 126: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos126

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Componentes de un ORB

ORB/Interface ORB:– Elemento encargado de (entre otras) las tareas asociadas a la

interconexión entre la computadora cliente y servidor, de forma independiente de las arquitecturas hardware y SSOO.

– Debido a que tanto clientes como servidores pueden requerir de ciertas funcionalidades del ORB, ambos son capaces de acceder a las mismas por medio de una interfaz.

Las dos principales responsabilidades del ORB son:– Localización de objetos: El cliente desconoce la computadora donde

se encuentra el objeto remoto.– Comunicación entre cliente y servidor: De forma independiente de

protocolos de comunicación o características de implementación (lenguaje, sistema operativo, ...)

Page 127: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos127

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Componentes de un ORB

Adaptador de Objetos:– En este elemento se registran todos los objetos que sirven en un

determinado nodo. Es el encargado de mantener todas las referencias de los objetos que sirven en una determinada computadora de forma que cuando llega una petición a un método es capaz de redirigirla al código del skeleton adecuado.

Existen dos tipos de Adaptadores de Objetos especificados por OMG:

– BOA: (Basic Object Adapter).– POA: (Portable Object Adapter).

Page 128: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos128

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

ORB ORB

DII Stub ORBInterface

ORBInterface

Skel. DSI

Object Adapter (OA)

Cliente Objeto Servidor

Comunicación vía CORBA

Pasos de una comunicación:1- El cliente invoca el método asociado en el stub que realiza el proceso

de marshalling. (Stub cliente)2- El stub solicita del ORB la transmisión de la petición hacia el objeto

servidor. (ORB cliente)3- El ORB del servidor toma la petición y la transmite el Adaptador de

Objetos asociado, por lo general sólo hay uno. (ORB servidor)

1

2 3

4

5

6

7

Page 129: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos129

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comunicación vía CORBA

4- El Adaptador de Objetos resuelve cuál es el objeto invocado, y dentro de dicho objeto cuál es el método solicitado (Adaptador de Objetos)

5- El skeleton del servidor realiza el proceso de de-marshalling de los argumentos e invoca a la implementación del objeto. (Skeleton servidor)

6- La implementación del objeto se ejecuta y los resultados y/o parámetros de salida se retornan al skeleton. (Implementación del objeto)

7- El proceso de retorno de los resultados es análogo.

ORB ORB

DII Stub ORBInterface

ORBInterface

Skel. DSI

Object Adapter (OA)

Cliente Objeto Servidor

1

2 3

4

5

6

7

Page 130: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos130

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Localización de Objetos

• Los objetos de servicio de una aplicación CORBA se encuentran identificados por medio de una referencia única (Identificador de Objeto).

• Esta referencia es generada al activar un objeto en el Adaptador de Objetos.

• Por medio de esta referencia el ORB es capaz de localizar la computadora y el Adaptador de Objetos donde se encuentra, y éste último es capaz de identificar el objeto concreto dentro del Adaptador.

Page 131: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos131

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Implementación del Servidor

La implementación del objeto se diseña como una subclase de la clase generada por el compilador (el skeleton) de IDL en base a la definición.

Si el lenguaje usado para la implementación no soporta objetos el mecanismo es diferente.

Cuenta.idlCuenta.idl

idl

Cuenta_skel

<DEMARSHALLING>

Cuenta_impl

<implementación>

Clase generadaautomáticamente

Implementación del objeto

Page 132: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos132

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicios CORBA

Conjunto de objetos o grupos de objetos, que proporcionan una serie de funcionalidades elementales. Estos objetos están definidos de forma estándar (interfaces IDL concretas).

– Sus especificaciones se encuentran recogidas en los documentos COSS (Common Object Services Specifications).

– Los servicios definidos son:• Servicio de Nombres• Servicio de Eventos• Servicio de Ciclo de Vida• Servicio de Objetos Persistentes• Servicio de Transacciones• Servicio de Control de Concurrencia• Servicio de Relación• Servicio de Externalización

• Servicio de Consulta• Servicio de Licencias• Servicio de Propiedad• Servicio de Tiempo• Servicio de Seguridad• Servicio de Negociación• Servicio de Colección de Objetos

Page 133: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos133

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Uso del Servicio de Nombres

Permite asociar un nombre a una referencia de objeto. De esta forma los objetos al activarse pueden darse de alta en el servidor, permitiendo que otros objetos los obtengan su referencia en base a dicho nombre.

Los nombres de los objetos se encuentran organizados en una jerarquía de contextos de nombre.

Page 134: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos134

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

NameService

Servicio de Nombres

El Servidos de Nombres, al igual que todo objeto del sistema se encuentra previamente activo.

Page 135: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos135

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

NameService

MiCuenta=IOR:X

Cuenta

bind(“MiCuenta”,IOR:X)

Servicio de Nombres

Un nuevo objeto se arranca y se registra en el servidor de nombres:

Page 136: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos136

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

NameService

MiCuenta=IOR:X

Cuenta

IOR:NS=resolve_initial_references(“NameService”)

Cliente

Servicio de Nombres

Un cliente localiza al servidor de nombres. Suele existir una función interna del ORB para localizar al servidor de nombres (resolve_initial_references) .

Page 137: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos137

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

NameService

MiCuenta=IOR:X

Cuenta

IOR:X=resolve(“MiCuenta”)

Cliente

Servicio de Nombres

El cliente le pide al servidor de nombres que resuelva el nombre. Así obtiene la referencia al objeto buscado.

Page 138: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos138

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicio de Negociación

Este servicio también permite obtener referencias a objetos usando otra información:

– Los objetos se exportan en el servidor con una serie de características del servicio que proporcionan.

– Los clientes consultan con el servidor cuáles son los objetos ofertados con una serie de características.

Un cliente que buscase un servicio de impresión podría construir una consulta del tipo:Service=Printer ANDPrinterType=HP AND OS!=WinNT

A lo cual el servidor le indicará los objetos que existen con dichas características.

Page 139: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos139

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comparativa

CORBA vs DCOM– CORBA es un estándar abierto y no propietario.– CORBA proporciona soporte para diversos SO.– CORBA es más completo y flexible.– CORBA da una salida a los legacy systems

– DCOM esta integrado con la tecnología MicroSoft.– DCOM ha tenido una fuerte penetración en el mercado.

Page 140: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos140

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Comparativa

CORBA vs RMI– CORBA permite una mayor heterogeneidad en el desarrollo de

aplicaciones (RMI sólo se puede desarrollar con Java).– CORBA ademas de las funcionalidades de comunicación,

proporciona servicios.– RMI funciona sobre CORBA (IIOP).

– RMI es mucho más sencillo y cómodo de usar.– RMI permite un desarrollo rápido de prototipos.

Page 141: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Sistemas Operativos Distribuidos

Introducción a los Servicios Web

(Web Services)

Introducción a los Servicios Web

(Web Services)

Page 142: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos142

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Evolución de la Web

• Pasado: Web de documentos– Páginas estáticas– Web como un enorme repositorio de información– Tecnologías: HTTP + HTML

• Presente: Web de aplicaciones– Páginas dinámicamente generadas por aplicaciones web– Aplicaciones exportan su interfaz a los usuarios a través de la Web– Entorno de transacciones comerciales (Business to consumer, B2C)– Tecnologías: CGI, ASP, PHP, JSP, servlets, ...

• Futuro (ya está aquí): Web de servicios (funciones/métodos)– “Bibliotecas” ofrecen servicios a programas (no a usuarios)– Web como una enorme API de servicios (Web de componentes)– Empresas de valor añadido (Business to business, B2B)– Base de Sistemas distribuidos sobre Internet

• Servicio web: RPC sobre la Web usando XML

Page 143: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos143

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Aplicaciones web: Escenario típico

Figura extraída de “Understanding Web Services”: http://www7.software.ibm.com/vad.nsf/Data/Document4362

Page 144: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos144

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicios web: Escenario típico

Figura extraída de “Understanding Web Services”: http://www7.software.ibm.com/vad.nsf/Data/Document4362

Page 145: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos145

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Integración de servicios web

Figura extraída de “Understanding Web Services”: http://www7.software.ibm.com/vad.nsf/Data/Document4362

Page 146: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos146

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Definición de servicio web

• Módulo que exporta un conjunto de funciones (métodos) a aplicaciones a través de la Web proporcionando independencia de plataformas hardware/software

• Similar a RPC o RMI pero integrado en la Web– ¿Reinventando la rueda? → ¿Por qué no usar CORBA?

• Estandarización controlada por un grupo del W3C:– http://www.w3.org/2002/ws/

• Mismas cuestiones que con RPC/RMI:– ¿Qué protocolo de transporte se usa? → HTTP– ¿Qué formato de representación se utiliza? → XML– ¿Qué protocolo de comunicación se usa? → SOAP– ¿Cómo se especifican los servicios exportados (IDL)? → WSDL– ¿Cómo localiza el cliente al servidor (binding)? → UDDI

Page 147: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos147

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Protocolo de transporte: HTTP

• Uso típico de operación POST de HTTP:– datos de formulario y página de respuesta

• Uso de POST para petición y respuesta de RPC– Universalmente disponible– Atraviesa el firewall de la organización

POST /~ssoo/consultaBD.cgi HTTP/1.0Content-length: 76.....................

DNI=87654321&MAT=980000&Asignatura=sod&Curso=2002&Convocatoria=Jun&Tipo=acta

HTTP/1.1 200 OKContent-Type: text/html; charset=iso-8859-1.....................

<HTML>

Page 148: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos148

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Formato de representación: XML

• Información de RPC codificada en XML– Muy flexible y potente– XML Schema permite definir con precisión los tipos de datos

• Ej: float GetLastTradePrice(string symbol);

Petición:<GetLastTradePrice>

<symbol>DIS</symbol> </GetLastTradePrice>

Respuesta:<GetLastTradePriceResponse>

<Price>34.5</Price></GetLastTradePriceResponse>

Esquema:<element name="GetLastTradePrice"><complexType><all>

<element name="symbol" type="string"/></all></complexType></element><element name="GetLastTradePriceResponse"><complexType><all>

<element name="Price" type="float"/></all></complexType></element>

Page 149: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos149

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Protocolo de comunicación: SOAP

• Simple Object Access Protocol (Candidate Recommendation)• SOAP = HTTP + XML

– Especifica cómo mandar mensajes XML sobre HTTP– Define el contenedor del mensaje (tambien en XML)– Protocolo general, no sólo para RPC, también unidireccional

• Estructura de mensaje contenedor SOAP:– Sobre (Envelope): Cabecera (Header) [opcional] + Cuerpo (Body)

• Cabecera : info. complementaria (p.ej. en RPC un ID de transacción)• Cuerpo: contiene el mensaje original

• SOAP para RPC:– En petición: Identificador en POST identifica destino de RPC

• Seguridad:– Usando HTTPS (SSL)– Nueva propuesta: WS-Security

Page 150: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos150

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Un ejemplo de SOAP en RPCPOST /StockQuote HTTP/1.1......................<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="http://example.com/stockquote.xsd"><symbol>DIS</symbol>

</m:GetLastTradePrice></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

HTTP/1.1 200 OK...............<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV:Body>

<m:GetLastTradePriceResponse xmlns:m="http://example.com/stockquote.xsd"><Price>34.5</Price>

</m:GetLastTradePriceResponse></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Petición

Respuesta

Page 151: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos151

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Definición de interfaz de servicio: WSDL

• Web Service Description Language (Working Draft)• IDL para servicios Web basado en XML• Documento WSDL describe servicio web:

– Tipos de datos (XML Schema)– Funciones exportadas y sus mensajes de petición y respuesta– Protocolos usados: típicamente SOAP sobre HTTP– Dirección de servicio → URL con servidor y “componente”

• P. ej. http://www.stockquoteserver.com/StockQuote• Normalmente, generado automáticamente a partir de código

de servicios

Page 152: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos152

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Desarrollo de un servicio Web

• Programación de biblioteca de servicio– En algunos entornos hay que incluir información específica

• En VisualStudio .Net: etiqueta [WebMethod] sobre métodos exportados• Generación automática de fichero WSDL

– Generalmente, dentro de la generación de aplicación de servicio• En VisualStudio .Net: Proyecto de tipo Web Service

• En servidor: fichero WSDL informa sobre cómo activar servicio– Normalmente, lo hace un servidor web con soporte de servicios web

• Desarrollo de cliente:– Obtener fichero WSDL y generar proxy para aplicación cliente

• En VisualStudio .Net: “Add Web Reference”

Page 153: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos153

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Localización del servicio: UDDI

• Universal Description, Discovery, and Integration– No estándar: Propuesta inicial de Microsoft, IBM y Ariba

• Registro distribuido de servicios web ofrecidos por empresas• Información clasificada en 3 categorías (guías):

– Páginas blancas: Datos de la empresa– Páginas amarillas: Clasificación por tipo de actividas– Páginas verdes: Descripción de servicios web (WSDL)

• Se accede a su vez como un servicio web• Puede consultarse en tiempo de desarrollo o incluso

dinámicamente en tiempo de ejecución• Permite búsquedas por distintos criterios

– Tipo de actividad, tipo de servicio, localización geográfica

Page 154: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos154

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Registro de un servicio web

Page 155: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos155

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Extesiones de protocolos

• ASAP (Asynchronous Service Access Protocol): – Solicitudes asíncronas (envío cliente -> servidor). – Extensión de SOAP.– Pensadas para transacciones de larga duración.

• DIME (Direct Internet Message Encapsulation): – Optimización seleccionando la codificación de porciones del

mensaje.– Extensión de SOAP / SOAP MTOM.– Empaquetado más ligero.

Page 156: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos156

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Servicios web vs. RPC/RMI

• Servicio Web similar a RPC/RMI (Corba, DCOM)– ¿Hay un “ganador”? ¿Reinventando la rueda?

• Convivencia: Distintos ámbitos de aplicación • Servicios web

– Entornos de interacción “débilmente acoplados”• Exportar servicios fuera de la organización• Integrar apliaciones de la empresa

– Más estándar y extendido, menos problemas con firewalls• RPC/RMI “tradicionales”

– Aplicación distribuida “fuertemente acoplada”– Más funcionalidad y eficiencia

• Ejemplo de escenario de convivencia:– Exportar un servicio interno CORBA mediante un servicio web

Page 157: Comunicación en Sistemas Distribuidoslaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/... · 2009. 2. 25. · Sistemas Operativos Distribuidos 4 Fernando Pérez Costoya ⎯José

Sistemas Operativos Distribuidos157

Fernando Pérez Costoya ⎯ José Mª Peña SánchezMª de los Santos Pérez Hernández

Entornos de desarrollo de servicios web

• Número creciente de entornos de desarrollo• Algunas implementaciones de interés:

– .Net de Microsoft– Web Services Project de Apache– Java Web Services Developer Pack– IBM WebSphere SDK for Web services (WSDK)– WASP de Systinet

• Cursos sobre SOAP, WSDL y otras tecnologías web:– http://www.w3schools.com/