Download Presentación de PowerPoint - Departamento de Ingeniería Telemática

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
Índice
•
Modelos de middleware para mensajería
•
Modelo punto a punto
•
Modelo cliente-servidor
•
Modelo de publicación-subscripción
•
Java Message Service (JMS)
©2008 Marisol García Valls
Arquitecturas Distribuidas
Introducción
3
Aplicación
Middleware
Aplicación
Middleware
Network Stack (IP)
Hardware (Ethernet, etc.)
Sistema Operativo
Network Stack
(IP)
Hardware
(Ethernet, etc.)
Otro HW
•
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).
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
la
la
la
rendimiento,
facilidad para satisfacer distintas transacciones de comunicación,
naturaleza de la detección de errores, y
robustez frente a diferentes condiciones de error.
No se cumple que un modelo sea bueno para todos (NOT one size fits all).
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
©2008 Marisol García Valls
Arquitecturas Distribuidas
Características del middleware para mensajería
6
•
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
Mensajería vs. Invocación remota
7
•
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
8
Comparación de invocación remota con mensajería
Cliente
Servidor
Invocación
Recibe invocación
Procesa invocación y genera respuesta
Devuelve respuesta
Sigue
Ejecuta
Decide recibir datos/conecta a un tipo de datos
Procesa datos
Le envían datos del tipo subscrito
Envía datos
Sigue
A través de un
servidor o
directamente a
los que están
subscritos
©2008 Marisol García Valls
Ejecuta
Decide recibir datos/conecta a un tipo de datos
Le envían datos del tipo subscrito
Procesa datos
Arquitecturas Distribuidas
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.
O. O
invocación
recepción
respuesta
Sockets
•
El tratamiento de casos especiales lleva más del 80% del trabajo y del código.
•
Ejemplos: televisión, revistas y periódicos.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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:
•
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
11
Ejemplo de aplicación con mensajería
Fabrica
producto x, n
unidades
Componente
Inventario
Producto
Componente
ensamblado
producto
Piezas
requeridas
a,…,n
Producto x
Unidades n
Componente
Catálogo
Componente
fabricación
piezas
Inventariar
piezas
fabricadas a,…,n
Componente
contabilidad
©2008 Marisol García Valls
Piezas a,…,x
Componente
inventario
piezas
Arquitecturas Distribuidas
12
Conceptos básicos del API JMS
•
Arquitectura del API de JMS
•
Dominios de mensajería
•
Consumo de mensajes
©2008 Marisol García Valls
Arquitecturas Distribuidas
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
14
Arquitectura del API de JMS
•
Las herramientas de administración permiten vincular destinaciones y factorías de
•
Los clientes JMS pueden entonces:
conexiones dentro del espacio de nombres JNDI (Java Naming Directory Interface).
– buscar los objetos administrados en el espacio de nombres, y
– establecer la conexión lógica a dicho objeto mediante el proveedor JMS.
Herramienta de
administración
Vincular (bind)
Espacio de nombres
JNDI
CF
D
Buscar (Lookup)
Cliente JMS
©2008 Marisol García Valls
Conexión
lógica
Proveedor
JMS
Arquitecturas Distribuidas
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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 1
Msj.
Msj.
Envía
Cola
Consume
Cliente 2
Asiente
•
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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)
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
Se subscribe
Entrega
Cliente 1
Publica
Tópico
Msj.
Cliente 2
Msj.
Se subscribe
Entrega
Cliente 3
Msj.
•
Se usa en situaciones en las que cada mensaje pueda ser procesado por cero, uno o muchos
consumidores.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
20
El modelo de programación del API de JMS
Sus bloques básicos son:
•
•
Factoría de
conexiones
Objetos administrados:
factorías de conexiones y
destinaciones
Crea
Conexión
Conexiones
Crea
•
Sesiones
•
Productores de mensajes
Productor
mensaje
Envía a
Crea
Crea
Consumidor
mensaje
Recibe de
Mensajes
©2008 Marisol García Valls
Msj.
Destinación
•
Sesión
Consumidores de mensajes
Destinación
•
Crea
Arquitecturas Distribuidas
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).
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
TopicConnectionFactory.
•
Se pueden crear nuevas factorías de conexiones:
o
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();
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
QueueConnectionFactory queueConnectionFactory =
(QueueConnectionFactory) ctx.lookup(“QueueConnectionFactory”);
TopicConnectionFactory topicConnectionFactory =
(TopicConnectionFactory) ctx.lookup(“TopicConnectionFactory”);
©2008 Marisol García Valls
Arquitecturas Distribuidas
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”);
©2008 Marisol García Valls
Arquitecturas Distribuidas
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.createTopicConnection();
QueueConnection queueConnection =
queueConnectionFactory.createQueueConnection();
•
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();
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
©2008 Marisol García Valls
El asentimiento a los mensajes no es especifica
para sesiones transaccionadas
Arquitecturas Distribuidas
26
Productores de mensajes
•
Un productor de mensajes es un objeto creado por una sesión para enviar mensaje
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);
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
©2008 Marisol García Valls
Arquitecturas Distribuidas
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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 field
Set 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
JMSCorrelationID
Client
JMSReplyTo
Client
JMSType
Client
JMSRedelivered
JMS 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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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 Type
Body 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.
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
}
©2008 Marisol García Valls
Arquitecturas Distribuidas
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
©2008 Marisol García Valls
Arquitecturas Distribuidas