Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · DEPARTAMENTO DE SISTEMAS...

DEPARTAMENTO DE SISTEMAS

JMS

Arquitectura de Software

1


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

•  Patrones de integración y Apache ActiveMQ 2


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.

3


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


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.



Agenda







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 sender al receiver

El receiver lee el mensaje del canal

El receiver procesa el mensaje




•  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

8



9

Tomado de: EJB 3 in action


Agenda







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 o  Publish- suscribe

11


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



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

13



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

14


Agenda







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

16


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.

•  Los clientes JMS pueden usar el API JDBC

17


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

18


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 un administrador para el uso de sus clientes.

19


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


Arquitectura JMS

•  Interfaz JMS

21

Tomado de: Java Message Service API —Version 1.1


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


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

6.  Usa el Connection para iniciar la entrega de mensajes

23


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



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

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


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


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

27




•  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 28



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

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

29


Modelo de mensajes JMS Propiedades definidas en JMS

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

30



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.

31



•  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



o  MapMessage

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


Agenda







Message-Driven Bean (MDB)

Es un enterprise bean que permite a las aplicaciones JEE procesar mensajes de forma asíncrona


35


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.

36


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.

37


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

38


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

39 Tomado de: JSR 220 - Enterprise JavaBeansTM,Version 3.0.


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

40


Ejemplo: Bean que envía mensaje

41



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


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

43


Ejemplo 2

44



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(); }

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


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 {



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 / ShippingRequestQueue



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



Desarrollo MDB

Enviando mensaje de confirmación al cliente

49

El código fue tomado de: EJB 3 Developer Guide


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



Desarrollo MDB

•  Suscripción Durable con ActivationConfigProperty

Para suscripciones no durables el valor de la propiedad subscriptionDurability = NonDurable



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



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

•  Configure el tamaño del pool de MDB

53


Agenda







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

o  Soporte limitado a algunas plataformas

55



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

56



•  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

57



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




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.

• El patrón Observer [GoF], describe como diseñar un sujeto que anuncie eventos y los observadores que consumen eventos.

59 Tomado de: Enterprise Integration Patterns



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.

60




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) .

61


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

62


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 •  Soporta destinos distribuídos a través de la red

63


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. BIRMINGHAM – MUMBAI. 2008

64

Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · DEPARTAMENTO DE SISTEMAS...

Documents

Transcript of Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · DEPARTAMENTO DE SISTEMAS...