DEPARTAMENTO DE SISTEMAS JMS. Arquitectura de Software

(1)

DEPARTAMENTO DE SISTEMAS

JMS

(2)

Agenda

•  Introducción

•  Message-oriented middleware (MOM)

•  Modelos de mensajería

o  Point to point

o  Publish-subscribe (pub-sub)

•  Java Message Service (JMS)

o  Arquitectura JMS

o  Modelo de mensajes JMS

•  Message-Driven Bean (MDB)

o  Características MDB o  Proceso MDB

o  Ciclo de vida MDB o  Desarrollo MDB

(3)

Introducción

Mensajería

o  En JEE el término mensajería se refiere a la comunicación

con bajo acoplamiento entre un emisor y un receptor, de forma asíncrona.

o  Su comportamiento se puede asimilar a un buzón de voz,

donde un emisor (producer) deja un mensaje en un destino específico, para que un receptor (consumer) lo recoja cuando pueda.

(4)

Introducción

• Comunicación síncrona

o 

Invocación de métodos

  Java RMI

o 

Quien invoca y quien es invocado deben estar

presentes para que la comunicación se realice.

o 

El emisor debe esperar respuesta del receptor, para

realizar otra petición.

o 

Ejemplo: llamada telefónica

4 Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf

(5)

Introducción

• Comunicación asíncrona

o 

No se necesita la presencia del emisor y el receptor

para realizar la comunicación

o 

El receptor responde en el momento que pueda

o 

Se requiere de un Sistema de mensajería

(Message-oriented middleware - MOM)

o 

Ejemplo: Buzón de voz, en este se almacenan los

mensajes y el receptor puede recibir los mensajes y

revisarlos en otro momento.

(6)

Agenda

•  Introducción

•  Message-oriented middleware (MOM)

o  Point to point

(7)

Message-oriented middleware (MOM)

• Este sistema de mensajería coordina y administra el

envío y recepción de mensajes. Su principal propósito

es mover los mensajes del computador de un emisor al

computador del receptor. Transmisión esencial de envío

de mensajes:

El sender crea el mensaje El sender adiciona el mensaje al canal El sistema de mensajería mueve los mensajes del computador del El receiver lee el mensaje del canal El receiver procesa el mensaje 7 Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf

(8)

Message-oriented middleware (MOM)

•  Es un software que permite la comunicación asíncrona entre componentes.

•  Cuando un mensaje es enviado, el MOM lo almacena en una ubicación especificada por el emisor y reconoce lo recibido.

•  El MOM permite implementar soluciones en las que se requiere un bajo acoplamiento y garantizar confiabilidad en la entrega de información

•  Existen diferentes productos libres y comerciales o  IBM WebSphere MQ

o  TIBCO Rendezvous o  SonicMQ

o  ActiveMQ

o  Oracle Advanced Queuing o  etc

(9)

Message-oriented middleware (MOM)

(10)

Agenda

•  Modelos de mensajería

o  Point to point

(11)

Modelos de mensajería

• Un modelo de mensajería es un camino de

mensajería utilizado, en el cual se involucra un

número de emisores (senders) y receptores

(consumers).

o 

Point to point

(12)

Point to point

• El mensaje va de un emisor A a un receptor B

• El mensaje queda almacenado en una cola

• La cola no garantiza el orden de entrega de los mensajes

• Las colas conservan todos los mensajes, hasta que son

consumidos o expiran

• Si existe más de un receptor potencial se elige uno de forma

aleatoria.

• Una vez entregado el mensaje desaparece de la cola

12 Tomado de: EJB 3 in action

(13)

Publish-subscribe

• El mensaje enviado es recibido por todos los

consumidores suscritos

• Una vez enviado el mensaje no se guarda copia

• Utilizado en sistemas de broadcast

(14)

Publish-subscribe

• Los mensajes se tratan como un Topic, que

funciona como una cola pero puede tener muchos

consumidores.

• Los Topics conservan los mensajes solamente

mientras se recogen para ser distribuidos a los

suscriptores

(15)

Agenda

o  Point to point

•  Java Message Service (JMS)

(16)

Java Message Service (JMS)

• JMS es un estándar de mensajería (Java)

• Diseñado para aplicaciones basadas en componentes

J2EE / JEE

•  Provee un API para manipular mensajes

o  Crear o  Enviar o  Recibir o  Leer

(17)

Características

• Permite

comunicación

distribuida

con

bajo

acoplamiento, confiable y asíncrona.

• Provee un modelo estándar en Java para acceder a

MOM.

• Permite crear aplicaciones de mensajería portables.

(18)

Características

• El API JMS no incluye:

o 

Balanceo de carga y tolerancia a fallos

o 

Administración, JMS no especifica un API para

administración de mensajería

o 

Seguridad, JMS no especifica un API para controlar

la privacidad y la integridad de los mensajes

(19)

Arquitectura JMS

• Partes de una aplicación JMS

o  JMS Clients: Programas en Java que envían y reciben mensajes. o  Non-JMS Clients: Clientes que utilizan un sistema de mensajes

nativo, en lugar de API de JMS.

o  Messages: conjunto de mensajes definidos en cada aplicación para

comunicar información entre sus clientes.

o  JMS Provider: Sistema de mensajería que implementa un producto de

mensajería.

o  Administered Objects : Objetos JMS, pre-configurados, creados por

(20)

Arquitectura JMS

JMS tiene dos tipos de objetos administrados:

•  ConnectionFactory: Este objeto lo usa un cliente para crear una conexión

con un proveedor. (javax.jms.ConnectionFactory)

•  Destination: Este es el objeto que un cliente usa para especificar el destino

y el origen de los mensajes (javax.jms.Destination) Estos objetos son guardados en un namespace de JNDI

20 Tomado de: Java Message Service API —Version 1.1

(21)

Arquitectura JMS

• Interfaz JMS

(22)

Arquitectura JMS

o  ConnectionFactory: es un objeto administrado usado por un cliente para

crear una conexión.

o  Connection: es una conexión activa a un proveedor JMS.

o  Destination: es un objeto administrado que encapsula la identidad del

destino del mensaje

o  Session: un contexto único para enviar y recibir mensajes

o  MessageProducer: un objeto creado por un Session que es usado para

enviar mensajes a un destino.

22 Tomado de JavaEE Tutorial

(23)

Arquitectura JMS

Un cliente JMS ejecuta las siguientes actividades:

1.  Usa JNDI para localizar un objeto ConnectionFactory

2.  Usa JNDI para encontrar uno o más objetos Destination

3.  Usa el ConnectionFactory para crear una Connection

4.  Usa el Connection para crear una o más Sessions

5.  Usa un Session y los Destinations para crear un

MessageProducers y los MessageConsumers necesarios

(24)

Arquitectura JMS

Crea conexión a MOM Crea sesión JMS. Contexto orientado a tareas para enviar y recibir mensajes Transaccional. Las solicitudes para enviar mensajes no serán realizadas hasta que se llame el método commit o la sesión sea cerrada. Si no es transaccional el mensaje se envía cuando se invoca el método send.

Modo acknowledge Crea objeto de conexión. Conexión origen

Emisor Mensaje que se envía Envío de mensaje y cierre de conexión Crea objeto de conexión. Conexión de destino (cola) 24 Tomado de: EJB 3 in action

(25)

Arquitectura JMS

•  Envío de mensajes

•  Recepción de mensajes (síncrono).

Recibir mensajes en la cola. Llama bloques indefinidos Limitar la cantidad de tiempo de recepción, en milisegundos

•  Recepción de mensajes (asíncrono).

El cliente debe crear un message listener que implementa la interfaz MessageListener 25

(26)

Arquitectura JMS

El programa cliente registra el objeto MessageListener con el objeto

MessageConsumer

•  La conexión debe empezar para el envío de mensajes

•  El MessageListener es notificado asíncronamente cuando un mensaje es publicado en la cola

•  Esto se hace a través del método onMessage de la interfaz MessageListener

26 El código fué tomado de: Java Message Service API —Version 1.1

(27)

Modelo de mensajes JMS

• Estructura modelo de mensajes JMS

Cabecera: contiene información para identificar y enrutar el mensaje

Propiedades

Cuerpo: datos que deben ser enviados en el mensaje

(28)

Modelo de mensajes JMS

• Header:

todos los mensajes soportan el conjunto de

campos de cabecera. Los campos de cabecera

contienen valores usados por el cliente y el proveedor

• Properties:

se utiliza para información adicional a los

campos de la cabecera

o 

Application-specific properties

o 

Standard properties

o 

Provider-specific properties

• Body:

Define varios tipos de mensajes

(29)

Modelo de mensajes JMS

Header Fields

JMSDestination Send Method JMSDeliveryMode Send Method JMSExpiration Send Method JMSPriority Send Method JMSMessageID Send Method JMSTimestamp Send Method JMSCorrelationID Client JMSReplyTo Client JMSType Client

JMSRedelivered Provider

(30)

Modelo de mensajes JMS

Propiedades definidas en JMS

Para mayor información revisar la especificación JMS Versión 1.1

(31)

Modelo de mensajes JMS

JMS provee 5 formas para el cuerpo de un mensaje, cada

una definida por una interfaz de mensaje

Forma de mensaje Descripción

StreamMessage Un mensaje que contiene un conjunto de valores primitivos de Java. Se llena y lee secuencialmente

MapMessage Contiene un conjunto de pares

nombre-valor, los nombres son String y los valores tipos primitivos Java. Las entradas

pueden ser accedidos secuencialmente o aleatoriamente por el nombre

TextMessage Contiene String

ObjectMessage Contiene un objeto serializable Java. BytesMessage Contiene un flujo de bytes sin interpretar

No son muy usados porque la inserción de propiedades puede afectar el formato.

(32)

Modelo de mensajes JMS

• Ejemplos de definición de tipos de mensaje:

o 

TextMessage

o 

BytesMessage

32 El código fué tomado de: Java Message Service API —Version 1.1

(33)

Modelo de mensajes JMS

(34)

Agenda

o  Point to point

•  Message-Driven Bean (MDB)

(35)

Message-Driven Bean (MDB)

Es un enterprise bean que permite a las aplicaciones JEE

procesar mensajes de forma asíncrona

(36)

Características MDB

• Actúa como un listener de mensajes JMS

• Los mensajes pueden ser enviados por cualquier componente

JEE (aplicación cliente, otro enterprise bean) o por una

aplicación JMS o un sistema que no utilice la tecnología JEE

• Puede procesar mensajes de JMS u otro tipo de mensajes

• Comúnmente son implementados con tecnología JMS.

• Las conversaciones no mantienen el estado conversacional

de las instancias de un cliente específico.

(37)

Características MDB

•  Todas las instancias de un message-driven bean son equivalentes

o  El contenedor EJB permite asignar un mensaje a alguna instancia de un

message-driven bean

o  El contenedor puede tener un pool de estas instancias y permitir el flujo de

mensajes para ser procesados concurrentemente

•  Los Message-driven beans son anónimos, no son identificados por el cliente

•  Los componentes cliente no localiza los message-driven beans ni invocan directamente los métodos del mismo

•  Son invocados de forma asíncrona

•  Un message-driven bean puede procesar mensajes de múltiples clientes.

(38)

Beneficios MDB

• Maneja un sistema de pooling que facilita el proceso

de mensajes en paralelo al usar múltiples instancias

de MDB

• Gestionan el proceso de lectura de mensajes

• Automatizan el proceso de conectarse al almacén de

mensajes y leer los pendientes

(39)

Proceso MDB

•  Un message-driven bean es invocado por el contenedor cuando un mensaje llega al endpoint que es expuesto por el message-driven bean.

•  Un message-driven bean es definido de acuerdo a la interfaz message listener utilizada.

•  Para un cliente un message-driven bean es simplemente un consumidor de mensajes que maneja el procesamiento de mensajes.

Mensaje Contenedor MDB MDB MDB MDB endpoint

(40)

Ciclo de vida MDB

•  El contenedor EJB usualmente crea un pool de instancias de message-driven bean. Para cada instancia el contenedor ejecuta las siguientes tareas:

1.  Si el MDS usa inyección de dependencia, el contenedor inyecta esta referencia

antes de la instanciarlo

2.  El contenedor llama al método anotado @PostConstruct, si lo hay.

3.  El MDS nunca es pasado a estado passivated. Solamente tiene dos estados:

nonexistent and ready para recibir mensajes.

4.  Al final del ciclo de vida, el contenedor llama el método anotado @PreDestroy,

si lo hay.

5.  La instancia del bean es procesada por el garbage collection.

Tomado de Java EE Tutorial

(41)

Ejemplo: Bean que envía mensaje

(42)

Ej: Procesador de mensaje MDB

Recibe el mensaje enviado Provee información de configuración de un sistema específico de mensajería 42 El código fue tomado de: EJB 3 in action

(43)

Desarrollo MDB

•  La clase MDB debe implementar una interfaz message listener.

o  Directamente: usando la palabra implements en la declaración de la clase o  Indirectamente: A través de anotaciones o descriptores

•  No puede ser una clase abstracta o final

•  Debe ser un POJO y no una subclase de otro MDB

•  Debe ser una clase pública

•  Debe tener un constructor sin argumentos

•  No se pueden definir métodos final en la clase

•  Debe implementar todos los métodos de la interfaz y estos deben ser públicos

•  No debe generar excepciones javax.rmi.RemoteException o alguna excepción de tiempo de ejecución, si se genera la instancia del MDB es terminada

(44)

Ejemplo 2

44 El código fue tomado de: EJB 3 in action

(45)

Desarrollo MDB

• Anotaciones

o 

@MessageDriven

o 

@ActivationConfigProperty

Definición de @MessageDriven

@Target(TYPE) @Retention(RUNTIME)

public @interface MessageDriven { String name() default "";

Class messageListenerInterface default Object.class; ActivationConfigProperty[] activationConfig() default {}; String mappedName();

String description(); }

(46)

Desarrollo MDB

Un MDB implementa una interfaz message listener de JMS.

El contenedor usa la interfaz listener para registrar el MDB con el proveedor de mensajes y transmitir los mensajes invocando los métodos implementados

Usando messageListenerInterface como parámetro de la anotación @MessageDriven :

@MessageDriven(

name="ShippingRequestJMSProcessor",

messageListenerInterface="javax.jms.MessageListener") public class ShippingRequestProcessorMDB {

Realizando la implementación directamente:

public class ShippingRequestProcessorMDB implements MessageListener {

(47)

Desarrollo MDB

•  Uso de ActivationConfigProperty

Provee información para la configuración de un sistema de mensaje específico a través de un arreglo de instancias de ActivationConfigProperty. Comunica al contenedor que este MDB está escuchando por una cola. Si escucha un Topic el valor puede ser javax.jms.Topic Especifica el JNDI

name de la fábrica de conexión que debe ser usada para crear las conexiones JMS para el MDB. Estamos escuchando los mensajes que llegan al destino con el Nombre JNDI jms /

(48)

Desarrollo MDB

• Acknowledge Mode

o  Hay muchos “modos” para hacer acuse de recibido de los mensajes.

Por defecto para una sesión JMS se usa el modo AUTO_ACKNOWLEDGE.

o  Se implementa a través de un @ActivationConfigProperty

48 Tomado de: EJB 3 in action

(49)

Desarrollo MDB

Enviando mensaje de confirmación al cliente

(50)

Desarrollo MDB

• subscriptionDurability

o  Sólo aplica para PUB/SUB

o  Se puede definir si el Topic de subscripción es durable o no o  Una vez que el consumidor obtiene una suscripción duradera

sobre un Topic, se garantiza que todos los mensajes enviados al Topic se entregarán a los consumidores.

o  Si un consumidor no está conectado al Topic cuando se

recibe el mensaje, el MDB mantiene una copia del mensaje hasta que el consumidor se conecte y se entrega el mensaje.

Todos los mensajes del Topic serán durables para el suscriptor ID JoeOgler

Remover suscripción 50

(51)

Desarrollo MDB

• Suscripción Durable con ActivationConfigProperty

Para suscripciones no durables el valor de la propiedad

subscriptionDurability = NonDurable

(52)

Desarrollo MDB

• MessageSelector

•  La propiedad messageSelector es un selector que MDB aplica a un consumidor JMS. Por defecto se reciben todos los mensajes sin filtro. El criterio es aplicado a las cabeceras y las propiedades específicas de los mensajes que el consumidor quiere recibir

•  Ej: si se quiere recibir mensajes de solicitud con la propiedad Fragile = True

•  Se pueden incluir literales, identificadores, expresiones, operadores lógicos, aritméticos y de comparación

(53)

Buenas Prácticas MDB

• Escoja su modelo de mensajería cuidadosamente: PTP

o PUB/SUS

• Recuerde modularizar: es necesario modularizar y

desacoplar teniendo presente el concern de mensajería

• Escoja los tipos de mensajes cuidadosamente

(54)

Agenda

o  Point to point

•  Message-Driven Bean (MDB)

(55)

Patrones de integración

• Desafíos de la comunicación Asíncrona

o  Modelo complejo de programación

  Requiere un modelo de programación orientado por eventos.

o  Sensible al orden de ocurrencia de los eventos

  Los canales garantizan el envío de mensajes   No garantizan cuando el mensaje será entrega

  Esto puede causar envío de mensajes con o sin secuencia

  Se debe revisar el re-establecimiento de secuencia de mensajes

o  Desempeño

(56)

Patrones de integración

Patrón Caso Solución Ventajas

Pipes and Filters Se requeire procesar mensajes complejos manteniendo independencia y flexibilidad

1.  Una primera solución podría ser definir un módulo de mensajería con las funciones requeridas, pero esto puede ser inflexible y difícil de probar. Además al crear todo en solo módulo se presentan problemas para reutilizarlo.

2.  La solución está en implementar todas las funciones distribuidas en distintos componentes. Estos componentes deben ofrecer interfaces genéricas y permitir el intercambio de información.

1.  Componentes desacoplados 2.  El Pipe permite a un

componente enviar un mensaje por medio de él, que puede ser consumido después por otro componente.

3.  El pipe se comporta como un canal de mensajes.

4.  Provee independencia entre los filtros de lenguaje, plataforma y localización.

5.  Manejo de múltiples canales 6.  Permite realizar pruebas

El uso del estilo arquitectural de Pipes and Filters divide la tarea de procesamiento en una

secuencia de pasos pequeños e independientes (Filters) que son conectados por canales (Pipes).

Tomado de: Enterprise Integration Patterns

(57)

Patrones de integración

• Procesamiento de Pipeline

•  Cuando un unidad (Filtro) completa el procesamiento del mensaje, puede enviar el mensaje al canal de salida e inmediatamente empezar el procesamiento de otro mensaje

•  No tiene que esperar que se complete la secuencia para procesar el mensaje •  Esto permite el procesamiento múltiple

(58)

Patrones de integración

Patrón Caso Solución Ventajas

Message Translator Se requiere comunicar diferentes sistemas que manipulan datos en diferentes formatos Esto se presenta en sistemas de integración, p.e. comuniación con sistemas Legado

1.  Se podrían modificar las aplicaciones existentes con el riesgo de generar fallas en las funcionalidades actuales. 2.  Incorporar transformación directamente

en el endpoint de cada mensaje, esto requiere acceso al código del endpoint ,lo cual no es fácil en aplicaciones terminadas.

3.  Implementar un filtro especial Message Translator, entre otros filtros o aplicaciones que traduzcan de un formato a otro.

1.  Componentes desacoplados

Message Translator 58

(59)

Patrones de integración

Patrón Caso Solución

Message Translator

Muchas aplicaciones deben usar notificación de eventos para coordinar sus

acciones.

1.  Utilizar Remote Procedure Invocation, para notificar a las aplicaciones de los eventos, pero requiere que el receiver acepte el evento inmediatamente.

2.  Utilizar un Mensaje de Evento. Cuando un sujeto tiene un evento, creará un objeto de evento y lo empaqueta en un mensaje y lo envía por un canal. El observer*, recibirá el mensaje de enveto, tomará el evento y lo procesará. El sistema de mensajería no envía mensaje de notificación, sólo asegura que la notificación llega al observador . En Java, un evento puede ser un objeto como un XML, esto puede ser transmitido a través de un ObjectMessage de JMS.

59 Tomado de: Enterprise Integration Patterns

(60)

Patrones de integración

Patrón Caso Solución

Message Expiration

Si los datos de un mensaje o solicitud no es recibida por cierto tiempo, esta debería ser ignorada. Los datos de un mensaje son útiles en cierto tiempo, se puede

garantizar la entrega del mensaje, pero no el tiempo límite de entrega. P.e. En la consulta de una cotización si la respuesta dura mas de un minuto, pueda que los datos no sean fiables.

How can a sender indicate when a message should be considered stale and thus shouldn’t be

processed?

1.  Modificar la expiración del mensaje para especificar cuanto tiempo el mensaje es valido. Si el mensaje es enviado y el tiempo ha pasado, el mensaje será marcado como expirado

El Message Expiration es un timestamp que especifica cuanto el mensaje vivirá o cuando expirará

Si el mensaje es enviado por varios canales, se puede dar el caso de recibirlo en unos receptores y no en otros.

(61)

Patrones de integración

Si el sistema de mensajería detecta que el mensaje expiró lo envía por el Dead Letter Channel.

En JMS el parámetro Time-To-Live es utilizado, para especificar cuanto tiempo después de enviado el mensaje expira.

MessageProducer.setTimeToLive(long) -> Modifica el tiempo de todos los mensajes enviados. Un emisor puede también modificar el time-to-live de un sólo mensaje usando el método: MessageProducer.send(Message message, int deliveryMode, int priority, long timeToLive) .

(62)

Apache ActiveMQ

• Apache ActiveMQ es una aplicación open source

(Apache 2.0 licensed) de mensajería empresarial, la

cual implementa JMS version 1.1

• Provee

las

características

como

clustering,

almacenamiento de multiples mensajes.

• Está integrado con los patrones de integración

empresarial

(63)

Apache ActiveMQ

• Soporta diferentes protocolos como: Ajax, REST,

OpenWire, XMPP

• Soporta características avanzadas como:

o 

Mensajes a grupos

o 

Consumidores exclusivos

o 

Composición de destinos

o 

Mensajes Advisory

• Soporta conexiones con reconexión automática

• Soporte a Spring

(64)

Bibliografía

•  EJB 3 in action. Panda Debu, Rahman Reza, Lane Derek. Manning. 2007.

•  JSR 220: Enterprise JavaBeansTM,Version 3.0. Sun Microsystems.

•  The Java™ EE 5 Tutorial Third Edition. For Sun Java System Application Server Platform Edition 9. Eric Jendrock. 2006.

•  JMS API Version 1.1 April 12, 2002

•  Enterprise Integration Patterns. Designing, Building and Deploying Messaging Solutions. Gregor Hohpe, Bobby Woolf. Addison Wesley. 2004

•  EJB 3 Developer Guide. Michael Sikora. Packt Publishing.