El paradigma cliente servidor es esencialmente un patrón arquitectural
También es una abstracción sobre el modelo de paso de mensajes
Se basa en establecer roles asimétricos a los procesos que colaboran
Un proceso es el Servidor:
Espera de manera pasiva peticiones de los clientes
Responde a esas peticiones según un servicio predefinido
Otro proceso es el Cliente (puede haber varios):
Invoca peticiones al servidor
Espera la respuesta de los clientes
¿Qué simplifica esta abstracción?
Simplifica la sincronización en los procesos (se sabe quién espera y actúa)
Simplifica la implementación de servicios compartidos por múltiples clientes
¿Qué restringe esta abstracción?
Establece a priori el papel de cada proceso (¿Qué sucede si quiero que un cliente se convierta en servidor?)
Ejemplos de implementación
La mayoría de las aplicaciones más populares en Internet (HTTP, FTP, DNS, etc.)
El mecanismo de servlets de Java está concebido para implementar servidores
Paradigma cliente-servidor
El paradigma peer-to-peer es un patrón arquitectural
No ofrece una abstracción notable con respecto al modelo de paso de mensajes
Elimina la asimetría del modelo cliente-servidor
Todos los procesos son equivalentes desde el punto de vista de su habilidad para solicitar o proveer servicios a otros procesos
Lo que simplifica y restringe este paradigma es muy dependiente de las facilidades que soporten las APIs que se utilicen para el desarrollo
La comunicación suele basarse en mecanismos de petición-respuesta síncronos similar al del modelo cliente-servidor
Ejemplos de implementación
Todo tipo de aplicaciones de mensajería instantánea, intercambio de ficheros, vídeo-conferencia, etc.
El proyecto JXTA o el proyecto Jabber ofrecen APIs y estándares para el desarrollo de sistemas basados en el paradigma peer-to-peer
Paradigma peer-to-peer (igual-a-igual)
P1
P2
P3
MOM (Message Oriented Middleware): Middleware Orientado a Mensajes
Patrón arquitectural + abstracción similar a la del modelo cliente-servidor
Middleware: un software que está “en medio”
El modelo MOM propone la introducción de un middlerware que actúa de intermediario entre un sistema proveedor de servicios (servidor) y un sistema consumidor de servicios (cliente) desacoplándolos
El emisor (cliente) deposita una petición en el sistema de gestión de mensajes
El emisor queda “libre” para seguir con sus tareas
El sistema de gestión de mensajes actúa como un conmutador dirigiendo la petición hacia el receptor (servidor) más apropiado para procesarla
Los receptores almacenan las peticiones en una cola y las van procesando de manera asíncrona siguiendo una política predefinida (FIFO, LIFO, etc.)
Cuando una petición se procesa, la respuesta es entregada al proceso emisor (quizás con la intermediación del sistema de mensajes)
El proceso emisor puede recuperar la respuesta utilizando polling o a través de un mecanismo de retrollamadas
Paradigma MOM
¿Qué simplifica esta abstracción?
Proporciona una abstracción adicional para operaciones asíncronas con respecto al modelo de paso de mensajes que simplifica su desarrollo y comprensión
Permite desacoplar el emisor del receptor (mejora manteniblidad)
¿Qué restringe esta abstracción?
El modelo asíncrono elimina cualquier tipo de control que se pueda tener sobre las temporizaciones y la sincronización del emisor y el receptor
Ejemplos de implementación
Microsoft Message Queue (MSMQ), Java Message Service (JMS), etc.
Paradigma MOM Cont.
MOM
Emisor
Emisor
Emisor
Receptor
Receptor
Es paradigma de publicación/suscripción es un patrón arquitectural
También es una abstracción sobre el modelo de paso de mensajes
Como en el modelo cliente-servidor, hay dos roles asimétricos
El publisher (editor)
Recibe o produce eventos de diferentes tipos
Los subscritores (subscribers)
Se suscriben a eventos de determinado tipo
Cuando en el servidor se produce un evento, todos los suscriptores que hayan declarado su interés por ese tipo de evento son informados a través del envío de un mensaje, que contiene la información relevante sobre el evento
El modelo de programación del suscriptor está basado en retrollamadas
Este esquema se utiliza también para el desarrollo de aplicaciones monolíticas (p.e. en desarrollo de interfaces de usuario)
Paradigma de publicación/suscripción
¿Qué simplifica esta abstracción?
Facilita la implementación de servicios de multidifusión
Facilita el desarrollo de aplicaciones que gestionan eventos asíncronos (pe. control)
¿Qué restringe esta abstracción?
El propio modelo restringe el ámbito de aplicación
Ejemplos de implementación
Paradigma de publicación/suscripción
Publisher
Suscriptor
Suscriptor
Suscriptor
Evento
Evento
Suscripciones
Publicación de eventos
Evento
RPC (Remote Procedure Call): Llamadas a procedimientos remotos
Es una abstracción notable sobre todos los modelos basados en paso de mensajes
No es un patrón arquitectural
La idea es la de lograr que, desde el punto de vista del programador, el desarrollo de aplicaciones distribuidas sea idéntico al desarrollo de aplicaciones monolíticas
Es decir, la idea es la de ofrecer abstracciones que eliminen todo lo que “tenga que ver” con comunicaciones, redes, mensajes, protocolos, etc.
Las RPC se basa en el mimetismo del modelo de programación procedimental
Existe un modelo análogo que mimetiza la filosofía orientada a objetos: el RMI
¿Qué simplifica este paradigma?
Permite que desarrollar aplicaciones distribuidas sea “tan fácil” como desarrollar aplicaciones monolíticas (… lo matizaremos)
El desarrollador no tiene por qué saber nada de protocolos, mensajes, formatos …
¿Qué restringe este paradigma?
Hace invisibles (e intocables) todo lo que tiene que ver con protocolos, mensajes, formatos, etc. (¿Qué pasa si quiero saber si un mensaje se ha recibido duplicado?, ¿si quiero comprimir los datos de un mensaje?¿si quiero ralentizar el envío de mensajes?, etc.
Está adaptado para comportamientos síncronos (petición-respuesta bloqueante)
Ejemplos de implementación
Java RMI, Sun RPC, DCE, etc.
Paradigmas RPC y RMI
Paradigmas RPC y RMI Cont.
…
int x = 10
int y = 20
int z = sumar(x+y)
…
int sumar(int a, int b){
return a + b
}
Ejecución de llamada
monolítica
…
int x = 10
int y = 20
int z = sumar(x+y)
…
int sumar(int a, int b){
return a + b
}
Ejecución de llamada RPC
Mensaje
Mensaje
Proceso
Proceso
Proceso
Es una extensión del modelo RPC-RMI en la que se predefinen ciertos servicios
Los proveedores de servicios se registran en un directorio en tiempo de ejecución
Los consumidores pueden localizar los servicios consultando el directorio
La estandarización es imprescindible para lograr interoperabilidad
¿Qué simplifica este paradigma?
Permite mejorar la interoperabilidad
Simplifica el problema de la localización del interlocutor
Incentiva el uso directo de servicios estandarizados
¿Qué restringe este paradigma?
Requiere mecanismos de definición de interfaces
Restricciones similares a las del modelo RPC-RMI
Depende del a implementación
Ejemplos de implementación
La tecnología Jini de Java se basa en este modelo
Los Web Services (Servicios Web) se basan en este modelo
Paradigma de servicios de red
ORB (Object Request Broker): Intermediario de peticiones a objetos
El paradigma ORB es esencialmente un patrón arquitectural sobre el modelo RMI
Se añaden también funcionalidades adicionales que abstraen ciertos servicios
El ORB es un middleware que actúa como mediador en la petición a un objeto
El ORB puede realizar multitud de labores entre las que se incluyen:
Mediación entre objetos heterogéneos
Localización de objetos
Creación y activación de objetos bajo demanda
Etc.
Este paradigma es la base de la arquitectura CORBA
¿Qué simplifica este paradigma?
Al leer el estándar CORBA uno diría que este paradigma no simplifica nada …
… la realidad es que se elimina gran parte del trabajo tedioso, permitiendo que el desarrollador se centre en la lógica de negocio. Próximo a la filosofía orientada a componentes (el contenedor ofrece los servicios, el desarrollador la log. de negocio)
Mejora enormemente la interoperabilidad de las aplicaciones
¿Qué restringe este paradigma?
En general, las restricciones son similares a las del modelo RMI
Implementaciones concretas pueden añadir restricciones adicionales
Ejemplos de implementaciones
Cualquier implementación de un ORB CORBA (Orbix, TidORB, OpenORB, etc.)
Paradigma basado en ORB
Paradigma basado en ORB
Comentarios y referencias
Comentarios y reflexiones
¿Por qué la utilización de un patrón arquitectural en una aplicación distribuida restringe las capacidades de la aplicación?
Intenta imaginar qué tipo de mecanismo puede transformar una llamada a un procedimiento local (a un proceso) en una ejecución de un procedimiento remoto (en otro proceso). ¿Requiere este mecanismo el intercambio de mensajes?
¿Por qué crees que hay tantas abstracciones, patrones arquitecturales, toolkits, frameworks y APIs en el ámbito del desarrollo de aplicaciones distribuidas?
La compilación JIT del bytecode de Java ha mejorado las prestaciones de los programas escritos en este lenguaje. ¿Puedes encontrar información relativa al respecto?
Referencias
M.L. Liu, Computación Distribuida: Fundamentos y Aplicaciones, Pearson Addison Wesley, 2004. Capítulos 1,2 y 3
Bruce Eckel, Piensa en Java, Prentice Hall, 2003
Nunca desprecies el poder Wikipedia (www.wikipedia.org)
Resumen
Contenidos
Computación Distribuida: Conceptos básicos
Definición
Ventajas/Inconvenientes
Falacias de la Computación Distribuida
Rudimentos de programación en Java
Disciplinas relacionadas con la computación distribuida
Sistemas operativos:
Procesos
Programación Concurrente
Ingeniería del software
Abstracción
Comunicación entre procesos (IPC)
Invocaciones bloqueantes/no-bloqueantes
Envío y recepción síncronos y asíncronos
Paradigmas de la computación distribuida
Paso de mensajes
Cliente/Servidor, P2P
RPC-RMI
ORB
 Página anterior | Volver al principio del trabajo | Página siguiente  |