Download Modelos de mensajería

DEPARTAMENTO DE SISTEMAS
JMS
Arquitectura de Software
1
Agenda
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
DEPARTAMENTO DE SISTEMAS
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
DEPARTAMENTO DE SISTEMAS
•  Comunicación síncrona
o 
Invocación de métodos
 
o 
o 
o 
Java RMI
Quien invoca y quien es invocado deben estar
presentes para que la comunicación se realice.
El emisor debe esperar respuesta del receptor, para
realizar otra petición.
Ejemplo: llamada telefónica
Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
4
Introducción
DEPARTAMENTO DE SISTEMAS
•  Comunicación asíncrona
o 
o 
o 
o 
No se necesita la presencia del emisor y el receptor
para realizar la comunicación
El receptor responde en el momento que pueda
Se requiere de un Sistema de mensajería
(Message-oriented middleware - MOM)
Ejemplo: Buzón de voz, en este se almacenan los
mensajes y el receptor puede recibir los mensajes y
revisarlos en otro momento.
Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
5
Agenda
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
6
Message-oriented middleware (MOM)
DEPARTAMENTO DE SISTEMAS
•  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 receiver
procesa el
mensaje
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
Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
El receiver
lee el
mensaje
del canal
7
Message-oriented middleware (MOM)
DEPARTAMENTO DE SISTEMAS
• 
Es un software
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 
o 
o 
o 
o 
o 
que
permite
la
comunicación
asíncrona
entre
IBM WebSphere MQ
TIBCO Rendezvous
SonicMQ
ActiveMQ
Oracle Advanced Queuing
etc
8
Message-oriented middleware (MOM)
DEPARTAMENTO DE SISTEMAS
Tomado de: EJB 3 in action
9
Agenda
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
10
Modelos de mensajería
DEPARTAMENTO DE SISTEMAS
•  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 
o 
Point to point
Publish- suscribe
11
Point to point
DEPARTAMENTO DE SISTEMAS
Tomado de: EJB 3 in action
• 
• 
• 
• 
• 
• 
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
DEPARTAMENTO DE SISTEMAS
Tomado de: EJB 3 in action
•  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
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
15
Java Message Service (JMS)
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
•  Permite comunicación distribuida
acoplamiento, confiable y asíncrona.
con
bajo
•  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
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
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
Tomado de: Java Message Service API —Version 1.1
20
Arquitectura JMS
DEPARTAMENTO DE SISTEMAS
•  Interfaz JMS
Tomado de: Java Message Service API —Version 1.1
21
Arquitectura JMS
DEPARTAMENTO DE SISTEMAS
Tomado de JavaEE Tutorial
o 
o 
o 
o 
o 
ConnectionFactory: es un objeto administrado usado por un cliente para
crear una conexión.
Connection: es una conexión activa a un proveedor JMS.
Destination: es un objeto administrado que encapsula la identidad del
destino del mensaje
Session: un contexto único para enviar y recibir mensajes
MessageProducer: un objeto creado por un Session que es usado para
enviar mensajes a un destino.
22
Arquitectura JMS
DEPARTAMENTO DE SISTEMAS
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
DEPARTAMENTO DE SISTEMAS
Crea objeto de conexión. Conexión origen
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.
Crea objeto de
conexión.
Conexión de
destino (cola)
Crea sesión JMS.
Contexto orientado a
tareas para enviar y
recibir mensajes
Crea conexión a
MOM
Emisor
Modo acknowledge
Mensaje que se
envía
Envío de
mensaje y cierre
de conexión
24
Tomado de: EJB 3 in action
Arquitectura JMS
DEPARTAMENTO DE SISTEMAS
• 
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
DEPARTAMENTO DE SISTEMAS
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
DEPARTAMENTO DE SISTEMAS
•  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
Tomado de: EJB 3 in action
27
Modelo de mensajes JMS
DEPARTAMENTO DE SISTEMAS
•  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
Modelo de mensajes JMS
DEPARTAMENTO DE SISTEMAS
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
DEPARTAMENTO DE SISTEMAS
Propiedades definidas en JMS
30
Para mayor información revisar la especificación JMS Versión 1.1
Modelo de mensajes JMS
DEPARTAMENTO DE SISTEMAS
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 nombrevalor, 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
Modelo de mensajes JMS
DEPARTAMENTO DE SISTEMAS
•  Ejemplos de definición de tipos de mensaje:
o 
TextMessage
o 
BytesMessage
El código fué tomado de: Java Message Service API —Version 1.1
32
Modelo de mensajes JMS
DEPARTAMENTO DE SISTEMAS
o 
MapMessage
El código fué tomado de: Java Message Service API —Version 1.1
33
Agenda
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
34
Message-Driven Bean (MDB)
DEPARTAMENTO DE SISTEMAS
Es un enterprise bean que permite a las aplicaciones JEE
procesar mensajes de forma asíncrona
Tomado de: EJB 3 in action
35
Características MDB
DEPARTAMENTO DE SISTEMAS
• 
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
DEPARTAMENTO DE SISTEMAS
• 
Todas las instancias de un message-driven bean son equivalentes
o 
El contenedor EJB permite asignar un mensaje a alguna instancia
message-driven bean
de un
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
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
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
endpoint
Contenedor
MDB
MDB
MDB
MDB
Tomado de: JSR 220 - Enterprise JavaBeansTM,Version 3.0.
39
Ciclo de vida MDB
DEPARTAMENTO DE SISTEMAS
• 
El contenedor EJB usualmente crea un pool de instancias de
message-driven bean. Para cada instancia el contenedor ejecuta
las siguientes tareas:
1. 
2. 
3. 
4. 
5. 
Si el MDS usa inyección de dependencia, el contenedor inyecta esta referencia
antes de la instanciarlo
El contenedor llama al método anotado @PostConstruct, si lo hay.
El MDS nunca es pasado a estado passivated. Solamente tiene dos estados:
nonexistent and ready para recibir mensajes.
Al final del ciclo de vida, el contenedor llama el método anotado @PreDestroy,
si lo hay.
La instancia del bean es procesada por el garbage collection.
40
Tomado de Java EE Tutorial
Ejemplo: Bean que envía mensaje
DEPARTAMENTO DE SISTEMAS
41
Tomado de: EJB 3 in action
Ej: Procesador de mensaje MDB
DEPARTAMENTO DE SISTEMAS
Provee información
de configuración de
un sistema
específico de
mensajería
Recibe el mensaje
enviado
42
El código fue tomado de: EJB 3 in action
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
• 
La clase MDB debe implementar una interfaz message listener.
o 
o 
Directamente: usando la palabra implements en la declaración de la clase
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
DEPARTAMENTO DE SISTEMAS
44
El código fue tomado de: EJB 3 in action
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
•  Anotaciones
o 
o 
@MessageDriven
@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();
}
El código fue tomado de: EJB 3 in action
45
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
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 {
El código fue tomado de: EJB 3 in action
46
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
• 
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 /
ShippingRequestQ
ueue
El código fue tomado de: EJB 3 in action
47
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
•  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.
Tomado de: EJB 3 in action
o 
Se implementa a través de un @ActivationConfigProperty
48
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
Enviando mensaje de
confirmación al cliente
49
El código fue tomado de: EJB 3 Developer Guide
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
•  subscriptionDurability
o 
o 
o 
o 
Sólo aplica para PUB/SUB
Se puede definir si el Topic de subscripción es durable o no
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.
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
50
Remover suscripción
El código fue tomado de: EJB 3 in action
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
•  Suscripción Durable con ActivationConfigProperty
Para suscripciones no durables el valor de la propiedad
subscriptionDurability = NonDurable
El código fue tomado de: EJB 3 in action
51
Desarrollo MDB
DEPARTAMENTO DE SISTEMAS
•  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
El código fue tomado de: EJB 3 in action
52
Buenas Prácticas MDB
DEPARTAMENTO DE SISTEMAS
•  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
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
• 
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
54
Patrones de integración
DEPARTAMENTO DE SISTEMAS
•  Desafíos de la comunicación Asíncrona
o 
Modelo complejo de programación
 
o 
Requiere un modelo de programación orientado por eventos.
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
Patrones de integración
DEPARTAMENTO DE SISTEMAS
Patrón
Caso
Pipes and Se requeire
procesar mensajes
Filters
complejos
manteniendo
independencia y
flexibilidad
Solución
Ventajas
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).
56
Tomado de: Enterprise Integration Patterns
Patrones de integración
DEPARTAMENTO DE SISTEMAS
•  Procesamiento de Pipeline
Tomado de: Enterprise Integration Patterns
•  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
Patrones de integración
DEPARTAMENTO DE SISTEMAS
Patrón
Caso
Solución
Ventajas
Message
Translator
Se requiere
comunicar diferentes
sistemas que
manipulan datos en
diferentes formatos
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
Esto se presenta en
sistemas de
integración, p.e.
comuniación con
sistemas Legado
Message Translator
Tomado de: Enterprise Integration Patterns
58
Patrones de integración
DEPARTAMENTO DE SISTEMAS
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
• El patrón Observer [GoF], describe como diseñar un sujeto que anuncie eventos y los observadores que consumen eventos.
Patrones de integración
DEPARTAMENTO DE SISTEMAS
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.
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
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.
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.
How can a sender indicate when a
message should be considered stale
and thus shouldn’t be
processed?
60
Patrones de integración
DEPARTAMENTO DE SISTEMAS
Si el sistema de
mensajería
detecta que el
mensaje expiró lo
envía por el Dead
Letter Channel.
Tomado de: Enterprise Integration Patterns
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
DEPARTAMENTO DE SISTEMAS
•  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
almacenamiento de multiples mensajes.
•  Está integrado
empresarial
con
los
patrones
de
clustering,
integración
62
Apache ActiveMQ
DEPARTAMENTO DE SISTEMAS
• 
• 
• 
• 
• 
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
DEPARTAMENTO DE SISTEMAS
• 
EJB 3 in action. Panda Debu, Rahman Reza, Lane Derek.
Manning. 2007.
• 
JSR
220:
Enterprise
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
JavaBeansTM,Version
3.0.
Sun