Middleware: modelos de comunicación Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento de Ingeniería.

Presentación del tema: "Middleware: modelos de comunicación Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento de Ingeniería."— Transcripción de la presentación:

1 Middleware: modelos de comunicación Marisol García Valls Arquitecturas Distribuidas 2º Ingeniero de Telecomunicación (Telemática) Departamento de Ingeniería Telemática Universidad Carlos III de Madrid mvalls@it.uc3m.es

2 Arquitecturas Distribuidas ©2008 Marisol García Valls 2 Índice Modelos de middleware para mensajería Modelo punto a punto Modelo cliente-servidor Modelo de publicación-subscripción Java Message Service (JMS)

3 Arquitecturas Distribuidas ©2008 Marisol García Valls 3 Introducción Hardware (Ethernet, etc.) Network Stack (IP) Middleware Aplicación Hardware (Ethernet, etc.) Network Stack (IP) Middleware Aplicación Otro HW Sistema Operativo El middleware es una capa de software entre la aplicaicón y el sistema operativo. El middleware de red –aísla a la aplicación de los detalles de la arquitectura de la máquina subyacente, del SO y de la pila de red. –simplifica el desarrollo de sistemas distribuidos permitiendo a las aplicaciones que envíen y reciban información sin tener que programar usando protocolos de más bajo nivel (como sockets y TCP o UDP/IP).

4 Arquitecturas Distribuidas ©2008 Marisol García Valls 4 Modelos de comunicación de red Cliente-servidor (client-server). Muchos a uno. Punto a punto (point-to-point). Uno a uno. Publicador-suscriptor (publish-subscribe). Centrado en los datos, eventos, etc. El modelo de comunicación tiene impacto en: –el rendimiento, –la facilidad para satisfacer distintas transacciones de comunicación, –la naturaleza de la detección de errores, y –la robustez frente a diferentes condiciones de error. No se cumple que un modelo sea bueno para todos (NOT one size fits all).

5 Arquitecturas Distribuidas ©2008 Marisol García Valls 5 Algunos de los principales modelos de middleware Mensajería –JMS (Java Messaging Service) –Comunicación entre aplicaciones Java a través de mensajes Publicador-subscriptor –DDS (Real-Time Data Distribution Service) –Comunicación entre aplicaciones (interfaz C y Java) –Permite establecer otros parámetros de “rendimiento” en la comunicación –Sirve para crear aplicaciones distribuidas de tiempo real

6 Arquitecturas Distribuidas ©2008 Marisol García Valls 6 Características del middleware para mensajería La mensajería es un método de comunicación entre componentes software o aplicaciones. Un mensaje (a nivel del middleware) es una facilidad P2P (entre procesos iguales). Un cliente de mensajería puede enviar y recibir mensajes de otros clientes. Cada cliente conecta a un agente de mensajería que ofrece facilidades para crear, enviar, recibir y leer mensajes. La mensajería permite comunicación distribuida débilmente acoplada. –Un componente envía un mensaje a una destinación. –El receptor puede coger el mensaje de la destinación. –Sin embargo, emisor y receptor no tienen por qué estar disponibles a la vez. –El emisor puede no saber nada acerca del receptor y viceversa. –Sólo deben conocer qué formato de mensaje y qué destinación deben usar.

7 Arquitecturas Distribuidas ©2008 Marisol García Valls 7 Mensajería vs. Invocación remota La invocación remota (p.ej., RMI en el caso de Java) es una tecnología fuertemente acoplada. RMI fuerza que una aplicación conozca los métodos remotos que va a invocar. La mensajería también difiere del correo electrónico que es un método de comunicación entre personas o entre aplicaciones software y personas. La mensajería se usa para comunicar entre aplicaciones software o componentes software.

8 Arquitecturas Distribuidas ©2008 Marisol García Valls 8 Comparación de invocación remota con mensajería Servidor Cliente Invocación Recibe invocación Procesa invocación y genera respuesta Devuelve respuesta Sigue Envía datos Le envían datos del tipo subscrito Procesa datos Sigue Ejecuta Decide recibir datos/conecta a un tipo de datos A través de un servidor o directamente a los que están subscritos Le envían datos del tipo subscrito Procesa datos Ejecuta Decide recibir datos/conecta a un tipo de datos

9 Arquitecturas Distribuidas ©2008 Marisol García Valls 9 Ventajas del middleware de mensajería Mayor independencia (desacoplamiento). Puede manejar complejos patrones de flujos de información. Permite obtener aplicaciones distribuidas más simples y modulares. Puede manejar automáticamente todo tipo de tareas de red (conexiones, fallos, cambios de red) eliminando tener que programar todos estos casos especiales. El tratamiento de casos especiales lleva más del 80% del trabajo y del código. Ejemplos: televisión, revistas y periódicos. Sockets O. O invocación recepción respuesta

10 Arquitecturas Distribuidas ©2008 Marisol García Valls 10 JMS: Java Message Service Es un middleware de mensajería de SUN con API Java para que las aplicaciones creen, envíen, reciban y lean mensajes. La primera versión data de 1998. La última es la v1.0.2b de agosto de 2001 http://www.java.sun.com/products/jms Características principales Características principales: Comunicación débilmente acoplada (loosely coupled). Comunicación asíncrona: –Un proveedor de mensajes los entrega a un cliente tal como llegan. –Un cliente no tiene que pedir los mensajes para recibirlos. Comunicación fiable: –JMS garantiza que los mensajes son entregados una vez (y sólo una). –JMS puede ofrecer menores niveles de fiabilidad para aplicaciones que puedan permitirse perder mensajes o recibir duplicados.

11 Arquitecturas Distribuidas ©2008 Marisol García Valls 11 Ejemplo de aplicación con mensajería Componente Inventario Producto Componente ensamblado producto Componente fabricación piezas Fabrica producto x, n unidades Piezas requeridas a,…,n Componente inventario piezas Inventariar piezas fabricadas a,…,n Componente contabilidad Piezas a,…,x Producto x Unidades n Componente Catálogo

12 Arquitecturas Distribuidas ©2008 Marisol García Valls 12 Conceptos básicos del API JMS Arquitectura del API de JMS Dominios de mensajería Consumo de mensajes

13 Arquitecturas Distribuidas ©2008 Marisol García Valls 13 Arquitectura del API de JMS Una aplicación con JMS tiene 5 componentes principales. Proveedor JMS: un sistema de mensajería que implementa las interfaces JMS y ofrece características para su control y administración. Clientes JMS: programas o componentes SW escritos en Java que producen y consumen mensajes. Mensajes: objetos que comunican información entre clientes JMS. Objetos administrados: objetos JMS preconfigurados que se crean por un administrador para ser utilizados por los clientes. Hay dos tipos: –Destinaciones (destinations) –Factorías de conexiones (connection factories) Clientes nativos: son programas que utilizan un producto de mensajería con API para clientes nativos en lugar del API JMS.

14 Arquitecturas Distribuidas ©2008 Marisol García Valls 14 Arquitectura del API de JMS Herramienta de administración Cliente JMS Espacio de nombres JNDI CFD Proveedor JMS Vincular (bind) Buscar (Lookup) Conexión lógica Las herramientas de administración permiten vincular destinaciones y factorías de conexiones dentro del espacio de nombres JNDI (Java Naming Directory Interface). Los clientes JMS pueden entonces: –buscar los objetos administrados en el espacio de nombres, y –establecer la conexión lógica a dicho objeto mediante el proveedor JMS.

15 Arquitecturas Distribuidas ©2008 Marisol García Valls 15 Dominios de mensajería La mayoría de implementaciones del API de JMS soportan los dominios: –Punto a punto –Publicador – subscriptor Algunos clientes JMS combinan el uso de ambos dominios en la misma aplicación.

16 Arquitecturas Distribuidas ©2008 Marisol García Valls 16 Esquema del dominio de mensajería punto a punto El middleware punto a punto (PTP) se sustenta en el concepto de: –Colas de mensajes –Emisores –Receptores Cada mensaje se envía y dirige a una cola específica. Los clientes receptores extraen mensajes de la cola/-s establecida/-s para mantener sus mensajes. Las colas retienen todos los mensajes que les son enviados hasta que: –Son consumidos, o –Expiran Cliente 1ColaCliente 2 Msj. Asiente Consume Envía Cada mensaje sólo tiene un consumidor. No hay dependencias temporales entre emisor y receptor (pueden funcionar indepen.) El receptor asiente al procesar un mensaje satisfactoriamente. Se usa PTP cuando cada mensaje que se envía sólo debe ser procesado por un consumidor.

17 Arquitecturas Distribuidas ©2008 Marisol García Valls 17 Dominio de mensajería publicador-suscriptor Las aplicaciones (nodos) se suscriben a los datos que necesitan. Las aplicaciones publican los datos que quieren compartir. Los clientes envían un mensaje a un tópico o tema (topic). Generalmente los publicadores (P) y los subscriptores (S) son anónimos. Publicadores y subscriptores pueden publicar o subscribirse a la jerarquía de contenidos de forma dinámica. El sistema se encarga de distribuir los mensajes que llegan desde los múltiples publicadores de un tópico a los múltiples subscriptores de ese tópico. Los tópicos retienen los mensajes sólo durante el tiempo que se tarda en distribuirlos a los subscriptores actuales. Implementaciones de PS: –A través de un servidor central (JMS) –Los datos pasan directamente entre los publicadores y los suscriptores (DDS)

18 Arquitecturas Distribuidas ©2008 Marisol García Valls 18 Esquema del dominio de mensajería publicador-suscriptor Cada mensaje puede tener múltiples consumidores. Publicadores y subscriptores tienen dependencias temporales. –Un cliente que se subscribe a un tópico sólo puede consumir mensajes publicados después de que el cliente haya creado la subscripción, –El subscriptor debe estar activo para poder consumir mensajes Cliente 1 Tópico Cliente 2 Msj. Entrega Se subscribe Publica Msj. Cliente 3 Entrega Se subscribe Msj. Se usa en situaciones en las que cada mensaje pueda ser procesado por cero, uno o muchos consumidores.

19 Arquitecturas Distribuidas ©2008 Marisol García Valls 19 Consumo de mensajes Los middleware de mensajería son inherentemente asíncronos. Fundamentalmente no existe dependencia temporal entre la producción y la consumición de un mensaje. Sin embargo, JMS utiliza este término en un sentido más preciso diciendo que los mensajes puede ser consumidos de forma síncrona y asíncrona. Síncrona: –Un subscriptor o receptor coge un mensaje de forma explícita desde la destinación invocando un método receive. –El método receive puede bloquearse hasta que un mensaje llega o puede expirar su tiempo de espera si un mensaje no llega dentro de un tiempo especificado. Asíncrona: –Un cliente puede registrar un escuchador de mensajes (message listener), que es similar a un escuchador de eventos (event listener) –Cuando el mensaje llega a la destinación, el proveedor JMS entrega el mensaje llamando al método del escuchador onMessage. –El método onMessage actúa según el contenido del mensaje.

20 Arquitecturas Distribuidas ©2008 Marisol García Valls 20 El modelo de programación del API de JMS Sus bloques básicos son: Objetos administrados: factorías de conexiones y destinaciones Conexiones Sesiones Productores de mensajes Consumidores de mensajes Mensajes Productor mensaje Msj. Sesión Consumidor mensaje Conexión Envía a Destinación Recibe de Crea Factoría de conexiones Crea

21 Arquitecturas Distribuidas ©2008 Marisol García Valls 21 Objetos administrados Son los bloques: destinaciones y factorías de conexiones. Nota: ambos se mantienen mejor de forma administrativa que programática. Los clientes JMS acceden a estos objetos a través de interfaces portables. Los administradores configuran los objetos administrados en un espacio de nombres JNDI. Entonces, los clientes buscan los objetos administrados utilizando el API de JNDI. Notas: en la plataforma J2EE (Java para aplicaciones empresariales) las tareas de administración se realizan mediante j2eeadmin (sin argumentos).

22 Arquitecturas Distribuidas ©2008 Marisol García Valls 22 Factorías de conexiones Una factoría de conexiones es un objeto utilizado por un cliente para crear una conexión con un proveedor. Encapsula parámetros de configuración definidos por un administrador. Hay dos factorías de conexiones que vienen preconfiguradas en el J2EE SDK y son accesibles al arrancar el servicio. Cada factoría de conexión es una instancia de una interfaz QueueConnectionFactory o TopicConnectionFactory. Se pueden crear nuevas factorías de conexiones: j2eeadmin –addJmsFactory jndi_name queue j2eeadmin –addJmsFactory jndi_name topic Un cliente al inicio realiza una búsqueda de una factoría de conexión con el API JNDI: Context ctx = new InitialContext(); QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup(“QueueConnectionFactory”); TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) ctx.lookup(“TopicConnectionFactory”); Resulta en una búsqueda en el classpath actual por un fichero específico (vendor-specific) llamada jndi.properties, que indica qué implementación del API y qué espacio de nombres utilizar

23 Arquitecturas Distribuidas ©2008 Marisol García Valls 23 Destinaciones o destinatario Un destinatario es el objeto que utiliza un cliente para especificar el destino de los mensajes que produce y la fuente de los mensajes que consume. En el modelo PTP los destinatarios se llaman colas. Se crean: j2eeadmin –addJmsDestination queue_name queue En el modelo PS los destinatarios se llaman tópicos. Se crean: j2eeadmin –addJmsDestination topic_name topic Una aplicación JMS puede usar múltiples colas y/o tópicos. Búsqueda de tópicos creados: Topic myTopic = (Topic) ctx.lookup(“Topico”); Búsqueda de una cola y su asignación a un objeto Queue : Queue myQueue = (Queue) ctx.lookup(“LaCola”);

24 Arquitecturas Distribuidas ©2008 Marisol García Valls 24 Conexiones Una conexión encapsula una conexión virtual con un proveedor JMS. Puede representar una conexión TCP/IP con un socket entre un cliente y un servidor (residente). Como las factorías de conexiones vienen, las conexiones también pueden usar los dos dominios de mensajería: TopicConnection o QueueConnection. TopicConnection topicConnection = topicConnectionFactory.create TopicConnection (); QueueConnectio n queueConnection = queueConnectionFactory.create QueueConnection (); Al acabar una aplicación se debe cerrar las conexiones creadas. Esto cierra también sus sesiones, productores y consumidores de mensajes: queueConnection.close(); topicConnection.close();

25 Arquitecturas Distribuidas ©2008 Marisol García Valls 25 Sesiones Una sesión es un componente de un único hilo para producir y consumir mensajes. Se usan para crear productores, consumidores y mensajes. Las sesiones gestionan la ejecución de escuchadores de mensajes. Una sesión ofrece un entorno transaccional para agrupar un conjunto de envíos y recepciones en una unidad atómica de trabajo. Al igual que las conexiones, las sesiones pueden implementar las interfaces para utilizar PTP ( QueueSession ) o PS ( TopicSession ): TopicSession topicSession = topicConnection.createTopicSession(false,Session.AUTO_ACKNOWLEDGE); La sesión no es transaccional La sesión automáticamente asiente los mensajes cuando son recibidos satisfactoriamente Para crear la sesión para el modelo PS (con colas): QueueSession = queueConnection.createQueueSession(true, 0); La sesión se transacciona El asentimiento a los mensajes no es especifica para sesiones transaccionadas

26 Arquitecturas Distribuidas ©2008 Marisol García Valls 26 Productores de mensajes Un productor de mensajes es un objeto creado por una sesión para enviar mensajes a una destinación. Para PTP: un productor implementa la interfaz QueueSender. Para PS implementa la interfaz TopicPublisher. Se utiliza una QueueSession para crear un productor para la cola myqueue : QueueSender queueSender = queueSession. createSender (myQueue); Y use usa un TopicSession para crear un publicador para el tópico mytopic : TopicPublisher topicPublishr = topicSession. createPublisher (myTopic); Se puede crear publicadores no identificados con null. Para enviar (primero hay que crear los mensajes): –PTP con método send : queueSender.send(message); –PS con método publish : topicPublishr.publish(message);

27 Arquitecturas Distribuidas ©2008 Marisol García Valls 27 Consumidores de mensajes Un productor de mensajes es un objeto creado por una sesión para recibir mensajes que han sido enviados a una destinación. Un consumidor permite que un cliente JMS registre interés en una destinación con un proveedor JMS. El proveedor JMS gestiona la entrega de mensajes desde una destinación a los consumidores registrados a esa destinación. Para PTP un consumidor implementa la interfaz QueueReceiver. Para PS un consumidor implementa la interfaz TopicSubscriber. Se utiliza una QueueSession para crear un receptor para la cola myqueue : QueueReceiver queueReceiver = queueSession.createReceiver(myQueue); Y usa un TopicSession para crear un publicador para el tópico mytopic : TopicSubscriber topicSubscriber = topicSession.createSubscriber(myTopic); Una vez creado, el consumidor estará activo. Se desactiva con close. La entrega de mensajes no comienza hasta que no se arranca la conexión con start y para consumir tanto para PTP como PS se utiliza el método receive : queueConnection.start(); Message m = queueReceiver.receive(); topicConnection.start(); Message m = topicSubscriber.receive(1000); // time out para recepción

28 Arquitecturas Distribuidas ©2008 Marisol García Valls 28 Escuchadores de mensajes Es un objeto que actúa como un manejador de eventos asíncronos para mensajes. Implementa la interfaz MessageListener. MessageListener contiene un solo método: onMessage() que define las acciones a tomar cuando llega un mensaje. El escuchador se debe registrarse a una cola de mensajes o a un gestor de tópicos con el método setMessageListener : TopicListener topicListener = new TopicListener(); topicSubscriber. setMessageListener (topicListener); Después de registrar el escuchador se debe arrancar ( start ) la cola o el gestor de tópico para comenzar la entrega de mensajes.

29 Arquitecturas Distribuidas ©2008 Marisol García Valls 29 Mensajes: Cabeceras Un mensaje JMS tiene tres partes: cabecera, propiedades y cuerpo. Sólo la cabecera es obligatoria. La cabecera contiene campos predefinidos con valores utilizados por clientes y proveedores para identificar y redirigir a los mensajes: Header fieldSet By JMSDestination Send or publish method JMSDeliveryMode Send or publish method JMSExpiration Send or publish method JMSPriority Send or publish method JMSMessageID Send or publish method JMSTimestamp Send or publish method JMSCorrelationIDClient JMSReplyToClient JMSTypeClient JMSRedeliveredJMS Provider Cada mensaje tiene un identificador único: JMSMessageID JMSDestination representa la cola o el tópico al que se envía el mensaje. Cada campo de la cabecera tiene métodos get y set (documentados en la interfaz Message ) Algunos campos los debe establecer un cliente, otros son automáticamente establecidos por el método send o publicar, que rescriben cualquier valor establecido por el cliente.

30 Arquitecturas Distribuidas ©2008 Marisol García Valls 30 Propiedades de mensajes Existen dos tipos de propiedades: –Definidas por el usuario –Predefinidas por el API JMS Se pueden crear y establecer propiedades de mensajes si se necesitan otros valores además de los contenidos en los campos de la cabecera. Utilidad de las propiedades: –compabilidad con otros sistemas de mensajería, o –establecer filtros (message selectors) El API de JMS ofrece algunas propiedades predefinidas que un proveedor puede soportar. La utilización de las propiedades predefinidas o de las propiedades definidas por el usuario es opcional.

31 Arquitecturas Distribuidas ©2008 Marisol García Valls 31 Cuerpo de los mensajes El API de JMS define cinco formatos para el cuerpo de los mensajes. Esto permite enviar y recibir datos en diferentes formas y ofrecer compatibilidad con otros formatos de mensajería existentes. Message TypeBody contains TextMessage A java.lang.String object (e.g., the contecnts of an XML file) MapMessage A set of name/value pairs, with names as String objects and values as primitive types in Java. The entries can be accessed sequentially by enumeator or randomly by name. The order of the entries is undefined. BytesMessage A stream of bytes. This message type is for literally encoding a body to match an existing message format. StreamMessage A stream of primitive values in Java, filled and read sequentially. ObjectMessage A serializable object in Java. Message A message composed only of header fiels and properties. This message type is useful when a message body is not required. El API de JMS tiene métodos para crear mensajes de cada tipo y para rellenar su contenido.

32 Arquitecturas Distribuidas ©2008 Marisol García Valls 32 Creación y envío de mensajes. Ejemplos de métodos createTextMessage() se invoca sobre sesiones ( QueueSession o TopicSession ) para crear mensajes. setText(String text) se invoca sobre un mensaje para introducir un contenido. send(Message msg) se invoca para enviar un mensaje sobre una cola Envío de mensaje: TextMessage message = queueSession.createTextMessage(); message.setText(msg_text); queueSender.send(message); Recepción del mensaje: Message m =queueReceiver.receive(); if (m instaceof TextMessage) { TextMessage message = (TextMessage) m; System.out.println(“Leyendo mensaje: “ + message.getText()); } else { // Tratar el error }

33 Arquitecturas Distribuidas ©2008 Marisol García Valls 33 Excepciones La clase raíz de las excepciones de los métodos de JMS es JMSException. Tiene las siguientes subclases: –IllegalStateException –InvalidClientIDException –InvalidDestinationException –InvalidSelectorException –JMSSecurityException –MessageEOFException –MessageFormatException –MessageNotReadableException –MessageNotWriteableException –ResourceallocationException –TransactionInProgressException –TransactionRolledBackException