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 servidoresParadigma 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 siguiente |