Sistemas distribuidos

SISTEMAS DISTRIBUIDOS

UPMFI

© Fco. Javier Yágüez García1

SISTEMAS DISTRIBUIDOS: ARQUITECTURAS DE COMUNICACIONES

RESUMENJavier Yágüez

mayo 2009


UPMFI


Objetivos del resumenMiddleware de comunicaciones en el modelo tradicional cliente y servidor: Arquitecturas de niveles y protocolos intermedios de comunicaciones entre el nivel de transporte y aplicación TCP/IP

Modelos de desarrollo de sistemas distribuidos• Tecnologías asociadas

Sistemas Distribuidos: Introducción y Generalidades


UPMFI


APLICACIÓN

TRANSPORTE

INTERNET

INTERFAZ DERED

HARDWARE

RED DE

ACCESO

Sockets

MODELO TRADICIONAL CLIENTE Y SERVIDOR

INTERFAZ ENTRE EL NIVEL DE TRANSPORTE Y APLICACIÓN

NIVELES INTERMEDIOSNIVELES INTERMEDIOS == Middleware de comunicacionesMiddleware de comunicaciones

Por encima del interfaz de sockets,pueden existir 1 o más niveles intermedios de comunicacionesy, por tanto, 1 o más protocolos intermedios de comunicaciones

(p. ej., protocolo entre el stub del cliente y stub del servidor

en un sistema RPC, o elprotocolo IIOP entre el ORB

cliente y el ORB servidor más el protocolo entre el stub

cliente y skeleton servidor en un sistema CORBA, etc.)

(Stubs, Skeletons, ORBs = Entidades intermedias de comunicaciones)

TCP/IP


UPMFI


ARQUITECTURA DE CLIENTE/SERVIDOR EN DOS NIVELES

Sin middleware de comunicaciones

ARQUITECTURA DE CLIENTE/SERVIDOR EN TRES NIVELES

Middleware: Software de 1 o mMiddleware: Software de 1 o máás niveles s niveles intermedios de comunicaciones entre el cliente y intermedios de comunicaciones entre el cliente y el servidorel servidor: RPC, RMI, CORBA (ORB), ..., JDBC, …Facilitar las tareas al programador y que éste, por ejemplo, se olvide de las comunicaciones

MODELO TRADICIONAL CLIENTE/SERVIDORTipos de Arquitecturas Cliente/Servidor

- El modelo tradicional cliente y servidor divide una aplicación entre 2 o más componentes especializados distribuyendo la ejecución entre 1 o más máquinas mediante:


UPMFI


Aplicación de Usuario

RPCRPC

Interfaz de sockets

TCP UDP

IP

Interfaz de Accesoy Hardware

RedRed

SISTEMA ORIENTADOA LLAMADAS A FUNCIONES REMOTAS:

RPC de Sun: Sistema RPC más extendido (Unix)

Añade un nivel intermedio de comunicaciones

y, por tanto un protocolointermedio de comunicaciones

El sistema hace las llamadasdirectamente al API de sockets

RPC es la filosofRPC es la filosofíía operativaa operativade la mayorde la mayoríía de tecnologa de tecnologíías para el as para el desarrollo de sistemas distribuidos desarrollo de sistemas distribuidos

en el modelo cliente y servidoren el modelo cliente y servidor


UPMFI


SISTEMA A

FÍSICO FÍSICO

RED

SISTEMA B

TCP/UDP

ENLACE

IP

TCP/UDP

ENLACE

IP

Proceso Cliente

STUB CLIENTESTUB CLIENTE

Proceso Servidor

STUB STUB SERVIDORSERVIDOR

Protocolo stub cliente-stub servidor

SISTEMA RPC

Interpretay gestiona

las referencias remotas hechas

por el cliente

Interpreta ygestiona

las referencias remotas en referencias

locales

Interceptalas llamadas

a funciones remotas

Prog ver proc xid parm parm

xid parm parm

SOLICITUD

RESPUESTA

encapsula

Generado por el compilador IDL, define el modo en que se

debe llamar a un procedimiento del interfaz

de acceso del proceso servidor


UPMFI


Programación en RPCFichero fuente IDL

Compilador IDL

CabeceraStub cliente Stub servidor

Fuente cliente Fuente servidor

Compilador Compilador

Objetos clientey stub

Objetos servidory stub

Montador Montador

Ejecutable cliente Ejecutable servidor

Runtime library(RTL)

Runtime library(RTL)

-Vía IDL la especificación de un servicio es puramente declarativa y separada de su implementación-Para el cliente es totalmente transparente cómo estáimplementado el servicio

Vía IDL se define el interfaz de acceso al programa servidor:

-Nombre y nº del programa servidor-Nº de versión del programa servidor

-Nombre y nº de las funciones (prototipos)-Nombre y tipos de los parámetros

de la llamada

(De IDL al lenguaje de programación)


UPMFI


RPC: Proceso Cliente Solicita un Servicio

Stubdel clienteCliente

Entidad de

transporte

Servidor

Entidadde

transporte

1

2

3

4

5

67

8

9

10

Stubdel servidor

RED

Sistema RPC = software interno basado en un Sistema RPC = software interno basado en un nivel intermedio de comunicaciones nivel intermedio de comunicaciones estructurado en 2 mestructurado en 2 móódulos de comunicaciones o STUBSdulos de comunicaciones o STUBS que que independizan vindependizan víía IDL a las a IDL a las

implementaciones reales del cliente y servidorimplementaciones reales del cliente y servidor (permitiendo que puedan (permitiendo que puedan ser escritas en diferentes lenguajes) y permite ser escritas en diferentes lenguajes) y permite realizar las llamadas al interfaz de socketsrealizar las llamadas al interfaz de sockets

Protocolo de Comunicaciones entre StubsEncapsula los parámetros de la llamada

en un mensaje en formato de sintaxis común (p. ej., XDR de RPC de Sun)

Representación ficticiadel cliente

Representación ficticiadel servidor

Prog ver proc xid parm parm

xid parm parm


UPMFI


PROGRAMANDO CON UN INTERFAZ DE SOCKETS

Selección destinoConexión TCP

Connect

TCP UDP

EnvíoWrite

EnvíoSendto

Selección protocoloSocket

Selección puerto

Bind

LecturaRecvfrom

LecturaRead

CLIENTE

LiberarClose

Selección protocoloSocket

Selección puerto

Bind

TCPDefinición cola

Listen

Proceso peticiónAccept

LecturaRecvfrom

LecturaRead

UDP

SERVIDOR

EnvíoSend

EnvíoSendto

LiberarClose

NNºº puerto local y dir.IP localpuerto local y dir.IP localBind Bind

descriptor socketdescriptor socket

Descriptor socketDescriptor socket

ConexiConexióón n socket cliente socket cliente y socket servery socket server

mediante mediante establecimiento establecimiento

conexiconexióón TCPn TCP

Libera la conexiLibera la conexióón TCP n TCP previamente establecidapreviamente establecida

por el lado del clientepor el lado del cliente

UDP vUDP víía connect para no indicara connect para no indicarnnºº puerto remoto y dir.IP remotapuerto remoto y dir.IP remota

con write y readcon write y read

Para enviar y recibir datosPara enviar y recibir datosdel socket remoto vdel socket remoto víía UDPa UDP

(Cola de solicitudes de conexiónpendientes de aceptación y proceso)

(De solicitud de conexión)


UPMFI


socket (familia de direccionesfamilia de direcciones, tipo de sockettipo de socket, tipo de protocolo de comunicacionestipo de protocolo de comunicaciones)

AF_INETAF_INET6

SOCK_STREAMSOCK_DGRAM

SOCK_RAW

IP_PROTO_TCPIP_PROTO_UDP

IP_PROTO_IP0

SERVICIO DESEADO DE TRANSPORTE O IP

descriptor = socket(AF_INET, SOCK_STREAM, 0)descriptor = socket(AF_INET, SOCK_STREAM, 0)

connect(descriptor, dir_IP_remota, nº_puerto_remoto)

write(descriptor, puntero_dir_datos_a_transmitir, nº_octetos_a_transmitir)

read(descriptor, puntero_dir_almacenamiento, longitud_buffer)

CÓDIGO DEL CLIENTE

……

……


UPMFI


socket (familia de direccionesfamilia de direcciones, tipo de sockettipo de socket, tipo de protocolo de comunicacionestipo de protocolo de comunicaciones)

AF_INETAF_INET6

SOCK_STREAMSOCK_DGRAM

SOCK_RAW

IP_PROTO_TCPIP_PROTO_UDP

IP_PROTO_IP0

SERVICIO DESEADO DE TRANSPORTE O IP

descriptor = socket(AF_INET, SOCK_STREAM, 0)bind(descriptor, nº_puerto_local, dir_IP_local)

read(descriptor, puntero_dir_datos_a_transmitir, nº_octetos_a_transmitir)

send(descriptor, puntero_dir_almacenamiento, longitud_buffer)

CÓDIGO DEL SERVIDOR

listen(descriptor, nº_máximo de solicitudes_conexión)

accept(descriptor, puntero_estructura) dir_IP_remota, Nº_puerto_remoto

……

……


UPMFI


CLIENTE

close( )

socket( )

socket( )

bind( )

listen( )

connect( )

write( )

ESTABLECIMIENTO CONEXIÓN

DATOS (SOLICITUD)

DATOS (RESPUESTA) send( )read( )

close( )

read( )PROCESAMIENTO

SOLICITUD

accept( )

SERVIDOR

LAS FUNCIONES DEL INTERFAZ DE SOCKETSPARA TCP


UPMFI


SERVIDOR

recvfrom( )

sendto( )

DATOS (RESPUESTA)

socket( )

bind( )

sendto( )

DATOS (SOLICITUD)

PROCESAMIENTOSOLICITUD

recvfrom( )

BLOQUEO

socket( )

CLIENTE

LAS FUNCIONES DEL INTERFAZ DE SOCKETSPARA UDP


UPMFI


Aplicación de Usuario

Interfaz de SocketsInterfaz de Sockets

TCP UDP

IP

Interfaz de Accesoy Hardware

RedRed

SISTEMA BÁSICO ORIENTADO A LLAMADAS A FUNCIONES LOCALES (API)

Interfaz de Sockets de la Universidad de Berkeley

No existe middleware de comunicaciones,el programador tiene que trabajar a bajo nivel

y llamar directamentea las funciones de comunicaciones del API de programación proporcionado por un sistema

basado en un interfaz de sockets

Primer Interfaz de Sockets (y base de otros)fue desarrollado por la Universidad de Berkeley (Unix)

como un API basado en unas librerías de funciones<sys/socket.h>, <netdb.h> y <netinet/in.h>

y estructuras escritas en C para facilitar la creación de nuevas aplicaciones TCP/IP


UPMFI


Características de un Sistema RPCModo de operación: SOLICITUDES Y RESPUESTAS POR LA RED

AsimAsiméétrico (semidtrico (semidúúplex): Toda respuesta necesita plex): Toda respuesta necesita previamente de una solicitudpreviamente de una solicitudSSííncrono: ncrono: ““Parada y EsperaParada y Espera”” entre una solicitud y su entre una solicitud y su respuestarespuestaPunto a punto o unicast sobre TCP/UDP

• Opción RPC de Sun: difusión (broadcast) sobre UDP

Servidor RPC:Iterativo: Atiende una operación y no procesa otra hasta que no acaba la primera“Pseudoconcurrente”: Atiende múltiples clientes a la vez pero los va procesando de uno en uno


UPMFI


FÍSICO FÍSICO

RED

TCP

ENLACE

IP

TCP

ENLACE

IP

Proceso Cliente


Proceso Servidor

SKELETON SKELETON SERVIDORSERVIDOR

Protocolo stub-skeleton

SISTEMA JAVA RMI

Referencias locales y remotas segúnformato Java

(Mensajes de solicitud y respuesta)

SOLICITUD

RESPUESTAInterpretay gestiona


por el cliente



locales

SISTEMA A SISTEMA B

Interceptalas invocaciones

a métodos remotos

(RPC en JavaRPC en Java)

Comunicación entre objetos remotos JAVA

y creación de aplicacionesJava distribuidas


UPMFI


Modelo de referencia de una arquitectura común de componentes distribuidos basados en el bus de objetos ORBORB (Object Request Broker) o intermediario de solicitudes entre objetos Dispone de 2 niveles intermedios de comunicaciones (middleware Dispone de 2 niveles intermedios de comunicaciones (middleware de comunicacionesde comunicaciones): ):

Stub cliente y Skeleton servidor Stub cliente y Skeleton servidor ORB cliente y ORB servidor ORB cliente y ORB servidor

EspecificaciEspecificacióón abiertan abierta (grupo OMG: Object Management Group) que define una arquitectura de componentes distribuidos con el objetivo de permitir la comunicación e interoperabilidad entre objetos heterogéneos para la creación de aplicaciones en red mediante llamadas a métodos remotos independientemente del:

Lenguaje de implementación de los objetosLocalización física de los objetosEstado de ejecución de los objetosArquitectura de máquina y sistema operativoProtocolos de comunicacionesetc.

CORBACORBA (Common Object Request Broker Architecture)


UPMFI


SISTEMA A

FÍSICO FÍSICO

RED

SISTEMA B

TCP

ENLACE

IP

TCP

ENLACE

IP

Proceso Cliente

ORB CLIENTEORB CLIENTE


Proceso Servidor

ORB SERVIDORORB SERVIDOR

SKELETON SKELETON SERVIDORSERVIDOR

Protocolo stub-skeleton

IIOP

SISTEMA CORBASOLICITUD

RESPUESTAInterpretay gestiona


por el cliente



locales

Protocolo de comunicaciones Protocolo de comunicaciones a trava travéés del cual se comunican todoss del cual se comunican todos

los componentes CORBAlos componentes CORBAIndependientemente delIndependientemente del

lenguaje de implementacilenguaje de implementacióón,n,localizacilocalizacióón del objeto servidor,n del objeto servidor,estado del objeto servidor, etc.estado del objeto servidor, etc.

Gestión de referenciaslocales y remotas

Interceptalas invocaciones

a métodos remotos


(RPC sobre ORB)

Comunicación entre objetos remotos

heterogéneos y creación de aplicaciones

en red distribuidas


UPMFI


CLIENTE

Stub IDL cliente

ORB localcliente

SERVIDOR

Skeleton IDL servidor

ORB localservidor

IIOPIIOP (Internet Inter(Internet Inter--ORB Protocol)ORB Protocol)

Invocaciónmétodo remoto

Resultados

Implementación real

Implementación real

Implementación ficticia del objeto cliente Implementación

ficticia del objeto servidor

Middleware de CORBA Middleware de CORBA Niveles Intermedios de ComunicacionesNiveles Intermedios de Comunicaciones

A través del protocolo de comunicaciones IIOP se comunican, finalmente, todos los componentes de CORBA incluyendo al que permite (Adaptador de Objetos)

localizar y activar objetos servidores remotos y pasar la solicitud de servicio al skeleton pertinente

Gestión de referenciaslocales y remotas

-Vía IDL la especificación de un servicio es puramente declarativa y separada de su implementación-Para el cliente es totalmente transparente como está implementado el servicio

Vía IDL se define el interfaz de acceso al programa servidor:

Adaptador de Objetos

(POA)



UPMFI


Diagrama de Interacción y Ruta de Invocación de Objetos CORBA

NNúúcleo del ORBcleo del ORB

Stub IDLInterfaz Interfaz del ORBdel ORB

SkeletonIDL

ClienteImplementación

de Objetos

1122

33

44 55

Cliente Stub POAImplementación

del Servidor

44

ORB

Skeleton

Adaptador de objetos

(Interfaz POA)

11

22

33

44

55

registro

IOR (Interoperable Object Reference)

(localiza y activa) Se pone a la escucha

solicitudrespuesta


UPMFI


CORBA: Interoperabilidad Cliente/Servidor

Ada Cobol Java

Intermediario de Solicitudes entre Objetos (ORB)Intermediario de Solicitudes entre Objetos (ORB)

CLIENTE

Stub

C C++ SmallTalk Ada Cobol Java

SERVIDOR

C C++ SmallTalk

… …Stub Stub Stub Stub Stub skeleton skeleton skeleton skeleton skeleton skeleton

Si el producto ORB (CORBA) dispone de los compiladores IDL adecuados, los clientes y servidores se pueden escribir en cualquier lenguaje

CORBA = RPC SOBRE ORBCORBA = RPC SOBRE ORB


UPMFI


Servicios Web DistribuidosEscenario

REGISTRO DEL SERVICIO

CONSUMIDOR DEL SERVICIO

PROVEEDOR DEL SERVICIO

Invocación (o solicitud) del servicio

SOAP (XML)/HTTP

Publicación del servicioDescubrimiento del servicio

Servidor Web

Servidor UDDI(Registro UDDI

público o privado)

Clientes de servicios Web:Aplicación JavaAplicAción C++

…

Respuesta (resultado) del servicio

SOAP (XML)/HTTP

(mensajes XML estandarizados vía SOAP sobre HTTP)

(mensajes XML estandarizados Vía SOAP sobre HTTP)

CLIENTEDocumentos

WSDLDocumentos

WSDL 12

3

Servidor Web

Servicio Web = RPC basado en WSDL/XML/SOAP


UPMFI


MODELOS DE DESARROLLO DE SISTEMAS DISTRIBUIDOS

1.1. Modelo de igual a igual (peer to peer)Modelo de igual a igual (peer to peer)Redes de igual a igual o de pares o peer to peer (P2P)

• Comunicación entre sistemas finales iguales• Ningún sistema final tiene mayor prioridad que otro• No existen clientes y servidores fijos• Cada proceso participante es cliente (solicitudes) y servidor (respuestas)

simultáneamente– Cliente envía solicitudes de servicio– Servidor escucha de forma pasiva y proporciona servicios como respuestas

• Aplicaciones: Napster, eMule, eDonkey, GNUtella, Kazaa, MSN Messenger, Skype, …

2.2. MODELO TRADICIONAL CLIENTE Y SERVIDORMODELO TRADICIONAL CLIENTE Y SERVIDORRedes de cliente y servidor

• Cada proceso participante es cliente (solicitudes) o servidor (respuestas)

– El proceso servidor puede, a su vez, convertirse en cliente de otro proceso servidor igual• Aplicaciones: DNS, SMTP, …• Tecnologías: API de sockets, Sun RPC, JAVA RMI, producto CORBA (ORB), etc.

3.3. Modelo de eventosModelo de eventosRedes de objetos remotos mediante un mecanismo de publicaciones, suscripciones mecanismo de publicaciones, suscripciones y notificacionesy notificaciones

• Un proceso es cliente y otro servidor pero sin interacciones de mensajes del tipo de solicitud y respuesta

• Tecnología: JINI (Sun Microsystems)


UPMFI


Sistemas cliente y servidor Sistemas cliente y servidor orientados aorientados a:1.1. Llamadas a funciones locales (API)Llamadas a funciones locales (API): Interfaz (API) de socketsInterfaz (API) de sockets

•• No existe un nivel intermedio de comunicaciones (middleware de No existe un nivel intermedio de comunicaciones (middleware de comunicacionescomunicaciones))

•• Trabajar directamente a bajo nivel con las funciones de comunicaTrabajar directamente a bajo nivel con las funciones de comunicaciones del APIciones del API de un sistema basado en un interfaz de socketsinterfaz de sockets:– Interfaz de sockets de la Universidad de Berkeley (Unix)– Interfaz de Windows sockets de Microsoft (Windows)– Interfaz de sockets en Java de Sun Microsystems (entorno Java)

2.2. Llamadas a funciones remotas (del proceso servidor remotoLlamadas a funciones remotas (del proceso servidor remoto)): Sun RPCSun RPC, …•• Sistema hace las llamadas directas al interfaz de sockets = FILOSistema hace las llamadas directas al interfaz de sockets = FILOSOFSOFÍÍA A

OPERATIVA DEL RESTO DE SISTEMASOPERATIVA DEL RESTO DE SISTEMAS (salvo agentes móviles) = IDLIDL +NIVEL NIVEL INTERMEDIO DE COMUNICACIONES (middleware de comunicaciones)INTERMEDIO DE COMUNICACIONES (middleware de comunicaciones)

3.3. Invocaciones a mInvocaciones a méétodos remotostodos remotos (objetos distribuidos): JAVA RMI (RPC en Java), CORBA (RPC sobre ORB), COM + (RPC sobre bus Microsoft para Windows orientado a objetos en la plataforma .NET) y Enterprise Java Beans (Java RMI en la plataforma Java EE de Sun)

4.4. Servicios Web distribuidosServicios Web distribuidos: webservices de Sun (pila Metro), Java EE, .NET (Microsoft), etc.• RPC basado en WSDL/XML/SOAP• Librerías XML, SOAP, WSDL y UDDI

5.5. Agentes mAgentes móóvilesviles: Sin solicitudes y respuestas por la redSin solicitudes y respuestas por la red, sólo en el propio entorno de ejecución en donde se ofrece el servicio. No hay que estar a la espera del servicio y los cálculos se mueven hacia los datos y no al revés (p. ej., Aglets de IBM Tokyo Research Laboratory).

Modelo Tradicional Cliente y Servidor: 5 Tecnologías o Sistemas

Sistemas distribuidos

Documents

Transcript of Sistemas distribuidos