El modelo de programación orientado a objetos Define el concepto de objeto Un objeto es una abstracción que representa “algo” en la “vida real” El objeto representa un estado (a través de atributos) y unos comportamientos (a través de métodos) Así, es posible “razonar” en términos de objetos que encapsulan la complejidad La abstracción, en este caso, se centra especialmente en los datos (objetos) Ingeniería del software: orientación a objetos
La abstracción recurre frecuente al uso de diagramas de “cajas” y “flechas” para representar sistemas complejos de múltiples elementos que guardan relación El problema es que las “cajas” y las “flechas” pueden significar cosas distintas para personas distintas, por lo que la comprensión de los diagramas se dificulta
UML (Unified Modeling Language): El un lenguaje que proporciona un conjunto de notaciones estándar para representar modelos abstractos de objetos UML define un conjunto estandarizado de “cajas” y “flechas” con significados precisos que permiten representar objetos y algunas de sus relaciones UML está limitado, es decir, hay modelos que se pueden representar mediante UML y hay modelos para los que UML no posee notación estandarizada En esta asignatura, es conveniente conocer la notación de los diagramas de clases definidos en UML UML es útil para representar (y documentar) la arquitectura de una aplicación Siempre que utilicemos UML en los diagramas lo indicaremos de manera explícita Ingeniería del software: UML
Diagramas de clases básicos en UML
Existen algunos términos que aparecen de manera recurrente en el ámbito de los ingenieros de trabajan en computación distribuida
Toolkits y frameworks Los toolkits y frameworks suelen consistir en un conjunto de clases, herramientas, APIs, ejemplos de programación y documentación que algunos fabricantes distribuyen con el fin de facilitar el desarrollo de software distribuido El éxito de una tecnología concreta depende en gran medida de la calidad de las herramientas que se proporcionan al desarrollador en el correspondiente toolkit
Ejemplos de toolkits y frameworks JDK (Java Development Toolkit): Distribuido de manera gratuita por Sun Microsystems para desarrolladores interesados en el lenguaje Java .NET framework: Distribuido por Microsoft para desarrolladores Web en sistema operativo Windows.
Ingeniería del Software: algo de terminología
Componentes El desarrollo de software basado en componentes es una técnica muy habitual para la construcción de sistemas software distribuidos empresariales Los componentes son unidades funcionales independientes accesibles de manera distribuida Un sistema software distribuido se puede construir mediante la unión de componentes preexistentes y bien probados De este modo se minimiza el tiempo y los costes de desarrollo Para que esta filosofía tenga sentido, los componentes deben poder cooperar a través de una red abierta Es necesario definir mecanismos estándar que posibiliten las interacciones entre componentes que, en principio, pueden ser heterogéneos El desarrollo basado en componentes también es un intento de minimizar la complejidad
Ejemplos de estándares para el desarrollo de componentes utilizados en la industria EJB (Enterprise Java Beans): Estándar para el desarrollo de componentes distribuidos basado en tecnologías Java COM (Component Object Model): Estándar para el desarrollo de componentes distribuidos basado en tecnologías Microsoft Ingeniería del Software: algo de terminología
1.1: Definiciones y conceptos básicos
1.2: Algunas nociones (muy) básicas sobre Java
1.3: Disciplinas base de la computación distribuida
1.4: IPC (Inter Process Communications): Comunicación entre procesos
1.5: Paradigmas de la computación distribuida Lección 1.4
Los servicios de comunicación entre procesos son la base de los sistemas distribuidos al permitir que dos procesos colaboren para lograr una tarea Hay dos mecanismos básicos de comunicación entre procesos
1- Comunicación entre procesos a nivel del sistema operativo (sin red) Permiten la comunicación entre dos procesos en el mismo ordenador Ejemplos: Colas de mensajes, semáforos, memoria compartida, etc. No vamos a utilizarlos en este curso
2- Comunicación entre procesos a través de una red Permiten la comunicación entre dos procesos que residan en la misma red En este caso, la comunicación se produce a través del intercambio de mensajes entre un emisor y un receptor El intercambio puede ser uno-a-uno (unicast – unidifusión) o uno-a-grupo (multicast – multidifusión)
IPC – Comunicación entre procesos
Cuando un ordenador tiene soporte de red, ofrece una API que proporciona los servicios de comunicaciones Estas APIs tratan de proporcionar una interfaz abstracta al programador Toda API debe proporcionar, al menos, cuatro tipos de operaciones al desarrollador ENVIAR: Es una primitiva que invoca el proceso emisor con el propósito de transmitir datos a un proceso receptor. Esta primitiva debe permitir identificar al proceso receptor así como especificar los datos a transmitir RECIBIR: Es una primitiva que invoca el proceso receptor con el objetivo de aceptar datos de un proceso emisor. Debe permitir identificar al proceso receptor así como especificar el área de memoria en la que se almacenará la información recibida Inicio de la conexión: Para mecanismos de comunicación orientados a conexión, deben existir primitas que permitan que la conexión se establezca. Lo habitual es que existan dos de ellas: ESPERAR-CONEXIÓN: Es una primitiva invocada por un proceso que está dispuesto a recibir la conexión de otro proceso de forma pasiva. INICIAR-CONEXIÓN: Esta primitiva es invocada por un proceso que quiere iniciar una conexión de manera activa con otro proceso. Es necesario identificar al proceso remoto DESCONECTAR: En comunicaciones orientadas a conexión, cualquiera de los dos extremos de una conexión establecida pueden liberarla invocando esta primitiva Elementos básicos de una API de IPC para redes
Si observamos detenidamente la API básica que hemos definido vemos que
Para que un mensaje pueda transferirse realmente, necesitamos que Toda llamada ENVIAR en un extremo, debe tener una llamada RECIBIR en el otro
Para que una conexión pueda establecerse realmente, necesitamos que Toda llamada INICIAR-CONEXIÓN debe tener un ESPERAR-CONEXIÓN asociada
¿Cómo logran los procesos ponerse de acuerdo para coordinar sus llamadas? Más aún … ¿Qué tenemos que hacer cuando en el código que desarrollamos para que los programas se coordinen al ejecutarse como procesos? Sincronización de los procesos remotos Proceso E Proceso R ENVIAR RECIBIR? Proceso E Proceso R INICIAR ESPERAR?
Definición de Sincronizar: “Hacer que coincidan en el tiempo dos o más fenómenos”
¿Cómo sincronizamos la ejecución de ENVIAR en un proceso con la ejecución de RECIBIR en el otro?
El mecanismo de sincronización más sencillo es el de utilizar comandos bloqueantes
Un comando bloqueante es aquel que bloquea al proceso que lo invoca hasta que se verifica una cierta condición, momento en el que el proceso para a estar Listo
Para el envío de un mensaje, el primer proceso que alcanza el comando ENVIAR/RECIBIR se bloquea hasta que el otro proceso “lo alcanza”
Para el establecimiento de una conexión, el proceso que invoca ESPERAR se bloquea hasta que otro proceso invoca INICIAR Sincronización de los procesos remotos
Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
(Gp:) Bloqueado
(Gp:) Ejecutando
(Gp:) Listo
(Gp:) Bloqueado
(Gp:) Ejecutando
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI (Gp:) Listo
Bloqueado Ejecutando (Gp:) Listo
Bloqueado Mensaje
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI Listo Bloqueado Ejecutando (Gp:) Listo
Bloqueado Mensaje
Ejecutando Ejemplo de comunicación con comandos bloqueantes … int x = leerDato(); int y = leerOtroDato(); int z = x + y; String resultado=“Suma=“+z; enviar(procesoII, resultado); … … llamarYoda(); sacarEspadaLaser(); matarSauron(); int z = recibir(procesoI) pagarImpuestos(z); … ProgramaII ProgramaI Listo Bloqueado Ejecutando (Gp:) Listo
Bloqueado Mensaje
Las operaciones de IPC que bloquean al proceso llamante se llaman síncronas Una operación bloqueante solo se desbloquea cuando sucede el evento esperado en el extremo remoto. Es decir, garantizamos que hay una sincronización Existen multitud de APIs de IPC síncronas y es posible programar con ellas Existen también APIs de IPC asíncronas, en las que las llamadas no se bloquean En estos casos, es responsabilidad del programador lograr la sincronización
¿Por qué puede querer alguien llamadas asíncronas? Para evitar bloqueos indefinidos Para mejorar las prestaciones y no desperdiciar ciclos de reloj Ejemplo: programa que recibe de muchas fuentes y almacena paquetes
while(true){ int resultado = recibir(paquete); if(resultado == -1) continue; else almacena(paquete); }
El programador debe saber si trabaja con llamadas síncronas o asíncronas Envío y recepción síncronas
Al desarrollar programas distribuidos, es necesario codificar tanto la parte receptora como la parte emisora ¿qué modelo hay que usar en cada caso? La sincronía/asincronía de las llamadas depende del servicio subyacente Para comprenderlo, necesitamos realizar diagramas de eventos Llamadas síncronas y asíncronas Evento Tiempo Periodo suspendido Proceso E Proceso R Mensaje Obligatorio
El Proceso R (receptor) se bloquea al invocar RECIBIR El Proceso E (emisor) se bloquea al invocar ENVIAR El Proceso R puede continuar ejecutando cuando ha terminado de recibir el mensaje El Proceso E requiere un acuse de recibo (ACK) confirmando una recepción correcta para poder desbloquearse Enviar síncrono y recibir síncrono Proceso E Proceso R ENVIAR RECIBIR Asentimiento El asentimiento forma parte del protocolo que implementa el servicio ICP (es transparente para el programador) El mecanismo enviar-síncrono/recibir-síncrono es aconsejable cuando la lógica de la aplicación de ambos procesos necesita que los datos enviados se reciban antes de continuar con el procesamiento Este mecanismo es utilizado cuando el servicio IPC es de transporte fiable orientado a conexión (p.e. TCP) La realidad puede ser un poco más complicada (bufferes intermedios de recepción, ACKs perdidos, etc)
El Proceso R (receptor) se bloquea al invocar RECIBIR El Proceso E (emisor) no se bloquea al invocar ENVIAR El Proceso E envía el mensaje y continúa sin esperar El Proceso E no requiere un acuse de recibo (ACK) confirmando la recepción Enviar asíncrono y recibir síncrono Proceso E Proceso R ENVIAR RECIBIR Este esquema es apropiado cuando la lógica de la aplicación emisora no depende de la recepción de los datos en el otro extremo Este esquema suele utilizarse cuando el mecanismo IPC subyacente no garantiza que los datos enviados sean, realmente, entregados al receptor (p.e. UDP)
El Proceso R (receptor) no se bloquea al invocar RECIBIR El Proceso E (emisor) se bloquea al invocar ENVIAR El Proceso E envía el mensaje y se bloquea El Proceso E requiere un acuse de recibo (ACK) para desbloquearse Hay 3 escenarios Enviar síncrono y recibir asíncrono Escenario 1 Los datos ya han llegado al Proceso R cuando se invoca RECIBIR En este caso, los datos se entregan al Proceso R inmediatamente Un ACK desbloquea al Proceso E Proceso E Proceso R ENVIAR RECIBIR Asentimiento
Escenario 2 Cuando el Proceso R invoca RECIBIR, los datos no han llegado El Proceso R no recoge ningún dato Para evitar un bloqueo indefinido del Proceso E, es necesario invocar RECIBIR nuevamente Enviar síncrono y recibir asíncrono Cont En este tipo de escenario el receptor se programa como un bucle en el que, cada cierto tiempo, se chequea si hay nuevos datos recibidos A esta técnica se le denomina polling Cuando los datos son finalmente recibidos, el Proceso E puede desbloquearse Proceso E Proceso R ENVIAR RECIBIR Asentimiento RECIBIR RECIBIR
Escenario 3 Cuando el Proceso R invoca RECIBIR, los datos no han llegado El Proceso R no recoge ningún dato Para evitar un bloqueo indefinido del Proceso E, se eleva un evento en el Proceso R cuando los datos realmente se reciben Enviar síncrono y recibir asíncrono Cont. Este evento tiene asociado un manejador, que ejecuta la recepción real de los datos El manejador es un método (función) que se invoca en el momento de la recepción, normalmente en un hilo diferente Para que este esquema funcione, el mecanismo IPC debe implementar el servio de evento con retrollamada
Los tres escenarios se pueden usar cuando se requiere un transporte fiable de los datos (p.e. TCP) y, al mismo tiempo, se requiere que el receptor no se bloquee Proceso E Proceso R ENVIAR RECIBIR Asentimiento Evento
Ninguno de los dos procesos se bloquea Este mecanismo sólo tiene sentido cuando no se requiere un transporte fiable y, además, se usa un mecanismo de eventos con retrollamadas Este esquema no es muy utilizado Enviar asíncrono y recibir asíncrono Proceso E Proceso R ENVIAR RECIBIR Evento
Ventaja clara: facilita la vida del programador a la hora de sincronizar los procesos Inconvenientes: Puede producir bloqueos indefinidos de un proceso (p.e. RECIBIR sin ENVIAR) Puede producir interbloqueos (p.e. los dos extremos llaman a RECIBIR) Es inaceptable cuando se requieren altas prestaciones (p.e. servidores)
Dos estrategias para minimizar los inconvenientes de llamadas síncronas
Estrategia I: Temporizadores La mayoría de las APIs de IPC de red permiten el uso de temporizadores (timeouts) que se pueden utilizar para fijar el tiempo máximo de bloqueo Ejemplo: RECIBIR(procesoRemoto, bufferDatos, 3000)
Revisión crítica del mecanismo de bloqueo RECIBIR timeout Recepcion correcta Continúa el programa Código error o excepción
Estrategia II: Uso de múltiples hilos de ejecución Esta estrategia se utiliza habitualmente para el desarrollo de servidores Consiste en crear hilos específicos para algunas operaciones bloqueantes La operación bloqueante, sólo detiene su propio hilo sin afectar al resto Este tipo de estrategia suele requerir el uso de control de concurrencia Revisión crítica del mecanismo de bloqueo Cont. Proceso Nuevo hilo RECIBIR Nuevo hilo ENVIAR
1.1: Definiciones y conceptos básicos
1.2: Algunas nociones (muy) básicas sobre Java
1.3: Disciplinas base de la computación distribuida
1.4: IPC (Inter Process Communications): Comunicación entre procesos
1.5: Paradigmas de la computación distribuida Lección 1.5
Definición de Paradigma: “Patrón, ejemplo o modelo” “Estilo o conjunto de prácticas utilizadas para desarrollar un programa” (software) Es decir, identificar los paradigmas de la computación distribuida es identificar los modelos, patrones y prácticas que se utilizan habitualmente para desarrollar programas que funcionan en un sistema distribuido En computación distribuida existen centenares de paradigmas, vamos a identificar los más habituales y populares ordenándolos según su nivel de abstracción Paradigmas de computación distribuida Hardware Cliente–servidor, peer-to-peer RPC y RMI Servicios de red, ORB Espacios de objetos, aplicaciones colaborativas Modelo OSI, modelo TCP/IP Paso de mensajes Nivel de abstracción creciente Estudiado en cursos anteriores Estudiado en este curso No se ve en este curso
El paradigma de paso de mensajes es una abstracción para lograr IPC ¿Qué simplifica esta abstracción? Abstrae todas las complejidades del modelo en capas (es decir, de la red) Servicio con primitivas ENVIAR, RECIBIR, ESPERAR-CONEXIÓN, INICIAR-CONEXIÓN Se logra que la E/S por red sea similar a la E/S típica de ficheros ¿Qué restringe esta abstracción? Hace invisibles (e intocables) los detalles de las capas inferiores (¿Qué pasa si quiero crear un paquete IP falsificando la dirección de origen?) Ejemplo de implementación La API Sockets implementa este modelo
Paradigma de paso de mensajes Proceso E Proceso R Mensaje I Mensaje II
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
Tema I: 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)
Tema I: 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 |