Tema 2 - Paradigmas de Computación Distribuida

Tema 2 – Paradigmas de
Computación Distribuida
Departamento de
Matemáticas y Grado en Ingeniería
Computación Informática Sistemas distribuidos
Objetivos
 Presentar una clasificación de varios
paradigmas de programación para sistemas
distribuidos. Compararlos.
 Conocer la arquitectura en capas de las
aplicaciones servidoras, analizando cada
capa
 Conocer las arquitecturas físicas de los
sistemas de información (1, 2, 3 y n niveles)
 Conocer los mecanismos de comunicación
síncrono y asíncrono.
 Presentar el concepto de middleware y los
tipos de middleware
Grado en Ingeniería Informática – Sistemas Distribuidos 2 Jose Divasón

Bibliografía
 Sistemas distribuidos: conceptos y diseño. G. Coulouris, J.
Dollimore, T. Kindberg. Addison Wesley (2001). ISBN: 84-7829-049-
4
 Computación distribuida: conceptos y aplicaciones. M.L. Liu.

Addison Wesley (2004). ISBN: 84-7829-066-4
 Web services : concept, architectures and applications.

Gustavo Alonso et al. Springer, 2004. ISBN 3-540-44008-9

Agenda
Paradigmas de aplicaciones distribuidas

Comparativa
División en capas de una aplicación
Arquitectura de los Sistemas de
Información
Esquemas de comunicación
Middleware

¡Aviso!
Hablaremos de procesos, no de hosts ni

de nodos:
 Un SD puede residir en un mismo host,
aglutinando varios procesos del mismo

Agenda

Comparativa
Información
Middleware

Paradigmas de aplicaciones
distribuidas
 Roles:
 Cliente/Servidor
 P2P
 Paradigmas de comunicación
 Paso de mensajes
 MOM
 MOM P2P
 MOM P/S
 RPC
 Objetos distribuidos
 Invocación de métodos remotos (RMI)
 Basado en Broker (ORB)
 Espacio de objetos
 Agentes Móviles
 Servicios en Red
 Blockchain

Arquitectura cliente/servidor
 Asigna dos roles diferentes a los procesos que
colaboran
 Rol Servidor:
 Interpreta el papel de proveedor del servicio
 Espera de forma pasiva la llegada de peticiones
 Puede ser utilizados por varios clientes a la vez.
 Rol Cliente:
 Inicia la comunicación
 Invoca determinados servicios
 Espera las respuestas
 Puede haber varios clientes para un mismo servidor
 El pegamento (/):
 Maneja la comunicación entre Cliente y Servidor.
 Es el middleware.

 Middleware:
 Capa de abstracción que se sitúa entre los
participantes y facilita en mayor o menor medida que
estos se encuentren, se comuniquen, colaboren…
 … de forma segura, insegura, síncrona, asíncrona…
 El middleware tiene múltiples objetivos y formas.
 Un ejemplo: un servidor web inteligente (servidor de
aplicaciones)
 Se sitúa entre los navegadores y las aplicaciones CGI
alojadas en ese servidor.
 Esta middleware hace: entender las peticiones HTTP,
encontrar el programa invocado, pasarle los parámetros,
ejecutarlo y devolver la respuesta del CGI al cliente.

 Conceptualmente la interacción entre clientes y
servidor puede usar cualquier paradigma:
 Paso de mensajes:
 Básico: sockets + protocolo ad hoc
 Protocolos estándar, ej. HTTP
 Sistemas de mensajes (MOM)
 RPC / RMI
 Arquitectura orientada a servicios (SOA)
 Es la “/” (el middleware) la que establece las
diferencias
 Más adelante analizaremos este paradigma desde

otra óptica

Peer-to-peer (P2P)
 De igual a igual
 En C/S, dos roles:
 El servidor espera peticiones (pasivo)
 El cliente inicia la comunicación (la petición de servicio)
 En P2P todos los procesos participantes interpretan
los mismos papeles
 con idénticas capacidades y responsabilidades
 Todo participante puede solicitar una petición a cualquier
otro y recibir una respuesta
 Los nodos colaboran tanto en el procesamiento como en
el enrutamiento de los mensajes entre nodos.

Peer-to-peer (P2P)
 Utilidades: compartición de ficheros, mensajería
instantánea, detectores de presencia, …
 Ejemplos: eMule, Bittorrent, Skype…
 Suelen ser combinación de P2P y C/S (el
directorio)
 Las operaciones necesarias son las mismas que
las del anterior paradigma y otras para descubrir
y/o anunciarse al resto de peers
 Cada aplicación tendrá sus operaciones
particulares (listar recursos, búsqueda,
establecer contacto …)

Paso de mensajes
 Es el mecanismo más básico, el paradigma fundamental en los sistemas
distribuidos
 Los datos son intercambiados entre dos procesos: un emisor y un receptor
 Cada proceso puede hacer los dos roles
 Un proceso envía un mensaje que supone una petición
 El otro procesa la petición y (eventualmente) elabora otro mensaje de respuesta
 Este esquema se repite
Proceso 1 Proceso 2
Mensaje 1
Respuesta 1
Mensaje 2

Paso de mensajes (II)
 Las operaciones básicas para dar soporte a este
esquema son
 Enviar y recibir
 Si la comunicación es orientada a la conexión también son
necesarias conectar y desconectar.
 Es deseable proporcionar un grado de abstracción
suficiente para que las operaciones de envío y recepción
sean similares a operaciones de E/S habituales
 Soporte en Java:
 Sockets (TCP o UDP)
 PipedInputStream y PipedOutputStream si la comunicación
se realiza entre threads de una misma aplicación
 Este paradigma es la base de gran parte del resto de
paradigmas

Paradigma de sistema de mensajes
 Se trata de una evolución del paradigma
básico de mensajes
 Hay toda una familia de productos que se
recogen bajo el termino de Message
Oriented Middleware (MOM)
 Existe un sistema intermediario entre los
emisores y receptores de mensajes (el
sistema MOM)
 Actúa como conmutador entre los procesos que
intercambian mensajes
 El intercambio (dependiendo del MOM concreto)
puede ser síncrono o asíncrono
(primordialmente)

Paradigma de sistema de mensajes
Java tiene una especificación (JMS) que
cumplen los sistemas de MOM más
habituales: MQSeries (IBM), Oracle,
BEA…
Existen a su vez dos submodelos MOM
 El modelo de mensajes punto a punto
 El modelo de mensajes
publicación/suscripción

MOM punto a punto (MOM P2P)
 Símil: el email
 Cada receptor dispone de una cola (un almacén) de
mensajes en el sistema MOM
 El emisor dirige el mensaje al sistema MOM que lo enruta
a la cola adecuada
 El receptor recoge los mensajes de la cola cuando desea
 Es esencialmente asíncrono
 De esta forma el emisor y el receptor se desacoplan
 El middleware MOM puede guardar los mensajes si
el receptor no está activo en un determinado
momento

MOM P2P
Emisor 1
Receptor 1
Emisor 2
Middleware MOM
Cola Rcpt. 1
Receptor 2
Cola Rcpt. 2
Emisor 3
Grado en Informática – Sistemas Distribuidos 18 Jose Divasón

MOM publicación/suscripción (MOM P/S)
 El middleware MOM dispone de unos cuantos temas (topics)

 Los receptores están interesados en temas y se suscriben a ellos
 Los emisores envían mensajes hacia un determinado tema
(publican)
 El MOM reenvía a todos los suscriptores el nuevo mensaje
 También se pueden almacenar los mensajes como pendientes
para un determinado suscriptor que no esté activo en un momento
determinado
 La recepción del mensaje puede ser síncrono o asíncrono
 Ventajas
 los sistema conectados no tienen que saber a quien deben
notificar.
 Un sistema publicador no conoce a sus suscriptores.
 De hecho estos pueden cambiar dinámicamente en función de las
horas, periodos anuales, circunstancias del sistema, etc.
 Es decir, gracias al MOM, los sistemas se desacoplan.

MOM P/S
Suscriptor 1
suscribe
Middleware MOM
Emisor 1 Topic 1 entrega Suscriptor 2
publica entrega
suscribe
Otros topics Suscriptor 3
Los suscriptores se suscriben

sólo una vez y reciben n veces

Paradigma de llamada a procedimiento
remoto
 RPC: remote procedure call
 Supone un salto de nivel en la abstracción con respecto a los
anteriores
 Los paradigmas anteriores usaban APIs de intercambio de mensajes
 Tenían programados los envíos de los mensajes
 Interesa un mecanismo de más alto nivel que enmascare ese envío
(mayor abstracción)
 Sería muy útil tener un mecanismo que permitiera que las
aplicaciones distribuidas se programasen igual que si fuesen
aplicaciones monolíticas
 Conjunto de llamadas a procedimientos y funciones
 El modelo que permite hacer esto es RPC:
 La comunicación entre procesos se realiza de la misma manera que se
invoca un procedimiento en local
 Por debajo los procesos se intercambian los mensajes adecuados, que
permanecen ocultos al programador

RPC
Cualquier programa  En un programa con funciones en

local, la llamada a una función
supone un salto en el flujo del
factorial(12)
programa
 Se ejecuta la función …
 … y el resultado se devuelve al
punto de llamada
factorial(n)  … desde donde prosigue el
programa principal
...

RPC
Por qué ha
Cualquier programa Proceso remoto de estar
factorial en
el mismo
factorial(12) proceso que
el programa
Mensaje RPC
principal?
factorial(12)
¿No puede
estar
479001600 remota?
factorial(n)
...

RPC
 Una llamada RPC
 Implica dos procesos distintos (posiblemente en máquinas distintas)
 El proceso A realiza una petición al proceso B, invocando uno de sus
procedimientos y pasando junto con la llamada los argumentos
necesarios
 El proceso B ejecuta el procedimiento y al terminar devuelve a A el
resultado
 Y lo deseable (si no, no tiene gracia) es que el impacto en el
programa invocador sea mínimo
 Por debajo habrá conexiones, sockets, mensajes, …
 Pero al programador no le importa
 Ventajas:
 Compartir funcionalidad entre aplicaciones
 Evitar la repetición de código
 Se reducen las posibilidades de error
 Se facilita el mantenimiento

Paradigmas de objetos distribuidos
Permite que los objetos que componen

una aplicación sean distribuidos, usados y
compartidos.
Podemos considerar los siguientes:
 Invocación de métodos remotos
 Paradigma basado en broker
 Espacio de objetos
 Agentes móviles

Invocación de métodos remotos
 RMI: Remote Method Invocation

 Java-RMI es un ejemplo; .Net-Remoting, otro.
 La idea es similar a RPC, pero orientada a objetos
 Si en RPC se puede invocar un procedimiento residente
en otro proceso, con RMI se puede hacer uso de objetos
situados remotamente, usar sus métodos, atributos, …
 Los objetos remotos proporcionan métodos a través de
los cuales se tiene acceso a los servicios
 Para implementar este paradigma se deben procurar
mecanismos de
 localización de objetos
 referencia remota
 invocación
 envío de parámetros, que pueden ser a su vez objetos
(marshalling), …

Intentemos hacernos una idea con un

ejemplo
 Un chat orientado a objetos:
Pensarlo primero en local
Distribuirlo

Nodo 2
ClienteChat
escribe()
Nodo 1 muestra(Mensaje)
ClienteChat
escribe() Nodo 3
muestra(Mensaje) ClienteChat
Mensaje
escribe()
Mensaje Mensaje muestra(Mensaje)
Nodo 4
Mensaje
Room
publica(Mensaje)

Stubs y Skeletons (II)
JVM 1 JVM JVM 2
ClienteChat Room
Room r; r
Registro
Invocación: RMI
parámetros
r.publica(mensaje)
publica
r
Respuesta: valor retorno

Invocación: parámetros
Invocación: parámetros
Siempre hace
invocaciones locales
Misma interface

Stub (Room) Skeleton (Room)
publica Invocación: parámetros
Más

Paradigma basado en broker
 En RMI la invocación se realiza directamente entre los nodos
 Un proceso solicita una petición a un ORB (Object Request Broker)
 Este redirige la petición al objeto adecuado (que debe estar registrado)
 El ORB funciona como intermediario (es un middleware)
 Además el ORB puede realizar acciones de mediación entre objetos
heterogéneos (escritos en distintos lenguajes)
 Ejemplo: CORBA (Common Object Request Broker Architecture)
ClienteChat Room
escribe() publica(Mensaje)
muestra(Mensaje)
Mensaje Mensaje
O.R.B

Espacio de objetos
 En lugar de enviarse mensajes, los procesos se
comunican a través de un espacio de objetos
 Un espacio de objetos es una entidad lógica en la que
los distintos nodos que forman el sistema:
 Para comunicarse, los
procesos emisores
depositan objetos en el
espacio
 Los receptores esperan
esos objetos en el
espacio, y cuando éstos
aparecen, los procesan.
 Un ejemplo: JavaSpaces

Espacio de objetos
 Los procesos depositan o toman objetos del espacio.
 Los objetos pueden ser de cualquier tipo (que tengan
propiedades públicas por las cuales poder buscar)
 Buscan objetos de su interés
 Para ello especifican una serie de características que se
comparan con las de los objetos contenidos en el espacio
 Y los toman del espacio de objetos
 Es una operación bloqueante
 Suspende al demandante hasta que aparece un objeto que
satisface sus criterios de búsqueda
 Sólo un proceso puede tomar cada vez un objeto
 Garantizada la exclusión mutua

Agentes móviles
 Un agente móvil es un programa en ejecución
(código+datos) que se traslada de un nodo a otro,
siguiendo un itinerario, realizando una tarea para
alguien (ej. recolectando información)
 Cuando termina, retorna con los resultados
 Son una amenaza para la seguridad de los nodos
visitados
 El entorno visitado por el agente debe decidir qué recursos le
deja utilizar
 La identidad del autor del agente debe ser conocida para
permitirle la entrada

Paradigma de servicios de red
 Es la base de la arquitectura SOA (Service Oriented
Architecture), que muchos ligan con los servicios
web
 El proveedor de servicio registra su servicio en un
directorio centralizado
 Un eventual cliente contacta con el directorio para
buscar un servicio
 El directorio le devuelve “una referencia” al servicio
 El cliente accede al servicio
 Es muy parecido a RPC o a la invocación de
métodos remotos (RMI) pero usando otros
protocolos basados en XML (UDDI, WSDL, SOAP)
 Otro: servicios web orientado a objetos (API REST)

Paradigma de servicios de red
Registro de Servicios
Localizar
Publicar
Enlazar
Solicitante Proveedor
Blockchain
 Tecnología que permite almacenar información

en forma de cadenas de bloques
 La información contenida en un bloque solo
puede ser borrada o editada modificando todos
los bloques posteriores
 Es un sistema distribuido descentralizado
 Las decisiones no están centralizadas, sino
distribuido entre muchas partes que deben
llegar a un acuerdo.
 Ejemplo: Bitcoin

Blockchain

Agenda

Comparativa
Información
Middleware

Abstracción
 En cuanto al nivel de abstracción de los

paradigmas (de menor a mayor abstracción)
 Paso de mensajes
 Cliente/Servidor y P2P
 RPC, RMI, Servicios de red, ORB, agentes
 Espacios de objetos
 En principio cuanto más abstracción, mejor.
 Mejor para el desarrollador. Pero …

Abstracción vs. sobrecarga
 El desarrollo de aplicaciones complejas se puede ver
favorecido por un nivel de abstracción alto
 Pero el precio es la sobrecarga
 Como ejemplo considerar RMI
 Sobrecargas
 Localización de objetos remotos
 Descarga de referencias remotas (stubs)
 Niveles de indirección (stubs)
 Más memoria usada (stubs + registros)
 Una aplicación basada en RMI será siempre más lenta y
consumirá más recursos que otra basada en sockets
 Aunque esta última sea mucho más difícil de gestionar
• Imaginar el ejemplo del chat con sockets

Agenda

Comparativa
Información
Middleware

Introducción
 Hemos hablado anteriormente de procesos que
hacen el papel de servicios
 Es hora de entrar a estudiar como debe ser la
arquitectura software de uno de estos servicios
 Esto nos lleva al concepto de capas de una
aplicación

Las tres capas de una aplicación
 Una aplicación típica se articula en torno a tres capas:

 Presentación (o generación de la presentación)
 Lógica de aplicación
 Gestión de los recursos
 A veces estas capas sólo existen como abstracción en la mente del
diseñador de la aplicación
 A veces, por motivos de eficiencia, se mezclan las capas
 Otras veces las capas están muy diferenciadas, e incluso
implementadas con distintas tecnologías y situadas en distintos
equipos
 Proporciona una solución más flexible y dinámica que las
aplicaciones monolíticas
 Cada capa asume una serie de funciones y responsabilidades
aisladas de las otras

Capa de presentación
 Un sistema de información debe interactuar con entidades externas
(humanas o no)
 Gran parte de esta interacción supone la presentación de
información y la aceptación de operaciones y envío de respuestas
 La parte de la aplicación que se encarga de estas tareas es la capa
de presentación
 ¿De dónde saca la información a representar?
 Se la dan el resto de capas
 Se la da el usuario
 La capa de presentación puede tener muchas formas
 Gráfica: Un GUI
 No Gráfica:
 una capa de integración XML
 sonora
 La capa de presentación se llama en ocasiones cliente.
 Pero no es lo mismo

Cliente ≠ Capa de presentación
 Todos los sistemas de información (S.I.) tienen clientes:

 Usuario: son entidades que usan los servicios del sistema
 Cliente: aquello que usa el usuario para interaccionar con el sistema
 Los clientes pueden ser totalmente externos e independientes del
S.I. En este caso no son parte de la capa de presentación
 Ejemplo1: La Web
 El navegador es un cliente que solo muestra la información generada
en el servidor
 La capa de presentación es en este caso el servidor web (estático) y
todos los módulos que generan el contenido y las interfaces web
(dinámico)
 Ejemplo2: C/S con interface gráfico de ventanas
 El cliente y la capa de presentación están juntos:
 La capa de presentación fabrica el propio interface que usa el usuario
 Es tan habitual que ha provocado la confusión entre cliente y
presentación
 Suele ser un GUI, diseñado ex profeso, que interactúa con el usuario

Capa de lógica de aplicación
 … o de lógica de negocio
 Es el corazón de la aplicación
 Implementará cualquier proceso que realice nuestra
aplicación
 Dos tipos de entidades:
 Los entidades de negocio: entidades propias del dominio de la
aplicación
 Servicios: implementan la lógica de la aplicación, atendiendo a las
reglas de negocio
 ¿De dónde saca los objetos de negocio?
 O de la capa de recursos, que la obtiene de BD, servidores externos…
 O de la capa de presentación, que la recoge del usuario
 ¿A dónde manda los objetos de negocio?
 A la capa de presentación para que el usuario la reciba
 A la de gestión de recursos, para, p.ej., persistirla en una BD

Capa de lógica de aplicación
Lo más importante de todo:
 No debe contener ningún detalle sobre cómo
Se almacenan los datos
Se representan los datos
De ser así, la capa de lógica solo serviría
para ese tipo de almacenamiento de datos
o esa presentación
La capa de lógica debe ser independiente
de las demás

Capa de gestión de recursos
 Todo S.I. necesita datos con los que trabajar
 Estos datos pueden residir en BD, sistemas de
ficheros u otros repositorios de información
 Independiza a la aplicación del sistema de
persistencia usado (BD, ficheros, otros sistemas ...)
 Su implementación contiene los detalles referentes
al dispositivo o sistema donde residen los datos
 las consultas/modificaciones en la BD
 consultas a servicios de directorio (como LDAP)
 las operaciones con ficheros
 la relación con otros S.I. (con sus propias capas de
presentación, lógica y recursos)
 Es decir la relación con la capa de presentación de ese S.I.

Capas - Gráfico
SGBD
Servidor de aplicaciones
Presentación Presentación Presentación
HTML
Lógica de negocio Gestión de

Recursos
Servicio Servicio
HTML2
LDAP
...
...
Objetos de
negocio
Servicio
HTML3
XML / Web Services

Servidor
correo
Capas - Ejemplo
Servidor de aplicaciones
Lógica de negocio Capa de
Presentación
encontrar Persistencia
HTML
grupos getGrupos(Titulacion)
SGBD
apuntar insertar (Alumno al,
Grupo g)
getGrupo(idGrupo)

Ventajas de esta arquitectura
 Cada capa se construye independiente de las otras,
facilitando el mantenimiento
 Los programadores pueden centrarse en su
especialidad/capa
 Es posible separar las capas físicamente (facilita la
escalabilidad)
 Simplifica la reutilización
 Permite disponer de variantes de una misma capa (ej.
distintas presentaciones o sistemas de persistencia)
 Diferenciación clara entre presentación y lógica de negocio.
Accesos a la aplicación desde diferentes interfaces
 La re-codificación de una capa no influirá en la aplicación, si
se mantiene la interfaz

Agenda

Comparativa
Información
Middleware

Arquitectura de los Sistemas de Información
 Las tres capas antes mencionadas son construcciones

conceptuales que organizan lógicamente la funcionalidad de los
sistemas de información
 Además tenemos que tener en cuenta “los entes terminales”, x.ej.,
el terminal de cliente o el servidor donde se ejecuta el SGBD
 Al implementar sistemas reales, las capas se pueden combinar y/o
distribuir de diferentes maneras.
 Al hacerlo ya no nos debemos referir a ellas como capas
conceptuales sino como niveles
 Hay fundamentalmente 4 tipos de sistemas de información
atendiendo a la organización de sus niveles:
 de 1 nivel (1-tier)
 de 2 niveles (2-tier)
 de 3 niveles (3-tier)
 de n niveles (n-tier)

Arquitectura de 1-nivel
 Centralización: las capas de presentación, lógica de la aplicación y
gestión de recursos se construyen de forma monolítica.
 Esta era la arquitectura típica de los mainframes
 Los Usuarios/programas acceden al sistema a través de terminales
DEDICADOS. Los terminales son mudos (monitor + teclado).
 Muestran la presentación que prepara el mainframe

Arquitectura de 1-nivel
 Ventajas:
 todo el sistema comparte un único contexto de ejecución (para
cada terminal/usuario)  no hay sobrecarga en llamadas a
otros nodos/niveles
 todo centralizado: el control y la gestión de recursos es más
fácil,
 El cliente es muy simple: un terminal mudo
 Pegas:
 Bloques monolíticos de código, difíciles y caros de mantener
 Problemas de sobrecarga del servidor. Poco escalables
 No hay manera de acceder a la lógica si no es a través de su
interface (técnicas de screen scraping)
 Hoy en día sólo se ocupan de ellos los que tienen la
“desgracia” de tratar con ese tipo de aplicaciones
legadas

Screen scraping

Dos niveles: cliente/servidor
 En cuanto los computadores fueron más potentes, fue posible
mover la capa de presentación al cliente.
 El boom fue gracias a internet
 Reparto de trabajo
 Puestos de trabajo autónomos (Cliente):
 Ambiente mono-usuario.
 Excelente relación potencia/costo.
 Aplicaciones potentes.
 Interfaces amigables.
 Grandes sistemas (Servidor):
 Ambiente multiusuario.
 Gestión centralizada de la BD.
 Compartir información y dispositivos.

Dos niveles: cliente/servidor
 Lo más importante de esta arquitectura es que el
servidor proporciona un API que es usada por los
clientes
 Se evita el problema del screen scraping
 API del servidor
 El servidor proporciona una serie de operaciones y maneja una
serie de estructuras de datos
 Ese API es la que usan los clientes
 El API puede tener múltiples formas:
 HTTP: páginas web + parámetros CGI
 RPC o RMI
 Servicios web (SOAP o REST)
 Podríamos considerar que un protocolo es un tipo de API

Propiedades esperadas de un C/S
 Acceso a recursos
 Un servidor puede atender a varios clientes y controlar el acceso a los recursos.
 Transparencia
 El diálogo entre cliente y servidor debe ser transparente a la ubicación, hardware y
plataforma.
 Encapsulamiento (API)
 Un mensaje de petición indica qué servicio se desea.
 El servidor se encarga de cómo resolverlo.
 Se puede modificar el servidor sin afectar los clientes, siempre que se respete el API.
 Los cambios de API suponen modificación de los clientes
 Escalabilidad
 Se puede escalar sin afectar a otros componentes, tanto horizontal como
verticalmente
 Integridad
 Las funciones y datos del servidor son manejadas de forma centralizada.
 Eso beneficia el mantenimiento e integridad de los datos.

Modelos Fat-Client y Thin-Client
 Las arquitecturas de 2-niveles se han hecho muy populares sobre todo en

forma de arquitecturas cliente/servidor
 Cliente: típicamente la capa de presentación
 Servidor: la parte de lógica y gestión de recursos
 Según el reparto de funciones podemos realizar la clasificación siguiente:
 Fat-Client: El grueso de la aplicación reside en el cliente
 Thin-Client : El grueso de la aplicación reside en el servidor.
 Hacen a cliente más fácil de migrar y mantener
 Requieren de menor potencia en la máquina cliente
 Son modelos complementarios y coexisten con frecuencia en muchas
aplicaciones. Fat client Thin client
GUI Appl Recurs

Reparto de funciones en C/S
Servidor
Gestión de
recursos
Gestión de Lógica de Gestión de

recursos negocio recursos
Lógica de Lógica de
Presentación
negocio negocio
Lógica de Gestión de Gestión de

Presentación Presentación
negocio recursos recursos
Presentación
negocio negocio
Presentación Presentación
Cliente

Arquitecturas de tres niveles
 Las arquitecturas de tres niveles se basan normalmente
en una separación entre las tres capas
 La presentación en el cliente
 La de lógica en el nivel intermedio (middle).
 Por eso al conjunto formado por esta lógica y toda la infraestructura
necesaria para alojarla se le llama middleware
 El de recursos se compone de todos los recursos a integrar
 Lo bueno es que los recursos usados pueden ser a su
vez sistemas de 2 o tres capas.
 En este caso el nivel de gestión de recursos pasa a ser un
cliente de esos sistemas usados
 Ya se habla de n-niveles (los 3 del propio sistema y los n-1 del
sistema accedido como recurso)

Reparto de funciones en niveles
3 Niveles
2 Niveles
Gestión de Gestión de
Servidor de datos recursos recursos
Gestión de negocio negocio
recursos
Lógica de Presentación Presentación

negocio
Muestro sólo
unas pocas
Servidor de
configuraciones aplicaciones Gestión de
recursos
Gestión de
recursos
Gestión de
recursos
Gestión de
recursos
Gestión de Lógica de Lógica de Lógica de Lógica de

recursos negocio negocio negocio negocio
Lógica de
Presentación Presentación Presentación Presentación
negocio
Lógica de Gestión de
Presentación Presentación Presentación
negocio recursos
Lógica de
Presentación
negocio
Cliente
Presentación
4 Niveles

Agenda

Comparativa
Información
Middleware

Interacción bloqueante o síncrona
 Los sistemas de información utilizan tradicionalmente

llamadas bloqueantes (el cliente envía una petición al
servicio y espera la respuesta antes de continuar su
trabajo).
 La interacción síncrona precisa que ambas partes estén
“en línea”: el llamador realiza una petición, el receptor
recibe la petición, la procesa, envía una respuesta y el
llamador la recibe.
 Es la forma más habitual (y sencilla) de programar las
interacciones:
 El estado del llamador no cambia hasta que no se recibe la
respuesta
 La sincronización del cliente y el servidor tiene
desventajas:
 sobrecarga de la conexión.
 mayor probabilidad de fallos

Interacción bloqueante o síncrona
Hilo
invocador
Hilo
invocado
petición
Periodo de
bloqueo
respuesta

Interacción Asíncrona
 El llamador no tiene que esperar hasta recibir la
respuesta
 Utilizando la interacción asíncrona, el cliente envía un
mensaje que es almacenado en algún lugar hasta que el
servidor lee y envía la respuesta de forma similar. El
llamador debe chequear si ha recibido la respuesta
 Como en el email
 No hay necesidad de que haya una respuesta por cada
petición (se pueden agrupar)
 Puede ocurrir que la respuesta ni siquiera sea necesaria
 Incluso, permiten el diseño modular: el código para
hacer una petición puede hacerse en diferente modulo
(o máquina) que el código que trata la respuesta

Interacción Asíncrona
 La interacción asíncrona puede tomar varias
formas:
 Simple invocación no bloqueante (se invoca un
servicio pero no se espera a la respuesta).
 Petición síncrona gestionada por un hilo que espera
la respuesta
 Servicio, en el cliente, de escucha de la respuesta
 Colas persistentes (las llamadas y las respuestas
son persistentes, almacenándose hasta que son
accedidas por el cliente o el servidor).

Encolar mensajes
Hilo Hilo
invocador invocado
cola
poner sacar
sigue activo
El hilo
sacar poner
cola

Multidifusión - Unidifusión
 Si la comunicación es únicamente entre un proceso y otro proceso
se denomina unidifusión (unicast)
 Si la comunicación se realiza entre un proceso y varios procesos a
la vez se denomina multidifusión (multicast) Receptor 1
Emisor 1 Receptor 1 Receptor 2

Emisor
Receptor 3

Broadcast vs. multicast
 Broadcast: difundir un mensaje a muchos
receptores, estén o no esperándolo (ej: la señal
de TV)
 Multicast: el mensaje que “sale sólo una vez” y
llega sólo a los nodos que han manifestado su
interés en recibirlo (a todos esos, pero
no a los demás).
 El proceso es controlado por los routers
Internet
Router Router
intermediario final

Agenda

Comparativa
Información
Middleware

¿Qué es?
 Es el “pegamento” que ayuda a la conexión entre
programas o sistemas (ej.: bases de datos).
 Capa software que proporciona una abstracción de
programación y de la heterogeneidad subyacente
(redes, S.O., lenguajes de programación)
 Proporciona un modelo computacional uniforme a
disposición de los programadores de aplicaciones
distribuidas:
 Abstrae los protocolos y mecanismos de bajo nivel y
 proporciona una serie de utilidades de alto nivel a los
desarrolladores

¿Para qué usar Middleware?
 Dadas dos aplicaciones que se quieren conectar, hay que resolver la
comunicación entre los procesos.
 Si las aplicaciones se conectan directamente a la red, entonces no se
necesita Middleware.
 Este enlace complica el desarrollo de las aplicaciones:
 Se debe programar módulos de bajo nivel, usando medios de bajo nivel, cercanos al
S.O. y al sistema de red.
 Este desarrollo se repite para cada aplicación a conectar.
Máquina A Máquina B Máquina C
Módulo de Módulo de Módulo de

comunicaciones comunicaciones comunicaciones
S.O. S.O. S.O.

Windows Mac OS X Linux

Esquema de conexión con Middleware
 El Middleware permite realizar esta conexión a través de
interfaces de alto nivel, por ejemplo que permiten ver un
método de un objeto remoto como si fuera local.
 La capa de Middleware permite programar la
comunicación mediante herramientas de alto nivel.
 Por ejemplo: RPC, MOM, acceso a objetos remotos.
Máquina A Máquina B Máquina C
Middleware Middleware Middleware
S.O. S.O. S.O.

Windows Mac OS X Linux

Clasificación
 Básico.
 Data Middleware.
 Remote File Access, Remote DB Access.
 Permite el acceso a datos desde programas u otros BDs.
 Communication Middleware.
 Permiten la comunicación entre programas.
 Ej. RPC, RMI, MOMs.
 Platform Middleware.
 Permiten resolver invocaciones o acceso a datos entre
programas. Proveen un runtime environment, que incluye
tecnologías de Middleware de datos y comunicaciones.
 Ej. Application servers, ORBs.

Fin del tema 2
Departamento de
Matemáticas y Grado en Ingeniería
Computación Informática Sistemas distribuidos

Tema 2 - Paradigmas de Computación Distribuida

Cargado por

Copyright:

Formatos disponibles

Tema 2 - Paradigmas de Computación Distribuida

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 2 - Paradigmas de Computación Distribuida

Cargado por

Copyright:

Formatos disponibles

Tema 2 – Paradigmas de

Grado en Ingeniería Informática – Sistemas Distribuidos 2 Jose Divasón

 Computación distribuida: conceptos y aplicaciones. M.L. Liu.

 Web services : concept, architectures and applications.

Grado en Ingeniería Informática – Sistemas Distribuidos 3 Jose Divasón

Paradigmas de aplicaciones distribuidas

Grado en Ingeniería Informática – Sistemas Distribuidos 4 Jose Divasón

Hablaremos de procesos, no de hosts ni

Grado en Ingeniería Informática – Sistemas Distribuidos 5 Jose Divasón

Paradigmas de aplicaciones distribuidas

Grado en Ingeniería Informática – Sistemas Distribuidos 6 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 7 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 8 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 9 Jose Divasón

 Más adelante analizaremos este paradigma desde

Grado en Ingeniería Informática – Sistemas Distribuidos 10 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 11 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 12 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 13 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 14 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 15 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 16 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 17 Jose Divasón

Grado en Informática – Sistemas Distribuidos 18 Jose Divasón

 El middleware MOM dispone de unos cuantos temas (topics)

Grado en Ingeniería Informática – Sistemas Distribuidos 19 Jose Divasón

Emisor 1 Topic 1 entrega Suscriptor 2

Otros topics Suscriptor 3

Los suscriptores se suscriben

Grado en Informática – Sistemas Distribuidos 20 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 21 Jose Divasón

Cualquier programa  En un programa con funciones en

Grado en Ingeniería Informática – Sistemas Distribuidos 22 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 23 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 24 Jose Divasón

Permite que los objetos que componen

Grado en Ingeniería Informática – Sistemas Distribuidos 25 Jose Divasón

 RMI: Remote Method Invocation

Grado en Ingeniería Informática – Sistemas Distribuidos 26 Jose Divasón

Intentemos hacernos una idea con un

Grado en Ingeniería Informática – Sistemas Distribuidos 27 Jose Divasón

Grado en Informática – Sistemas Distribuidos 28 Jose Divasón

Respuesta: valor retorno

Respuesta: valor retorno

Grado en Informática – Sistemas Distribuidos 29 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 30 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 31 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 32 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 34 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 35 Jose Divasón

 Tecnología que permite almacenar información

Grado en Ingeniería Informática – Sistemas Distribuidos 37 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 38 Jose Divasón

Paradigmas de aplicaciones distribuidas

Grado en Ingeniería Informática – Sistemas Distribuidos 39 Jose Divasón

 En cuanto al nivel de abstracción de los

Grado en Ingeniería Informática – Sistemas Distribuidos 40 Jose Divasón

Grado en Ingeniería Informática – Sistemas Distribuidos 41 Jose Divasón

Paradigmas de aplicaciones distribuidas

Grado en Ingeniería Informática – Sistemas Distribuidos 43 Jose Divasón