Arquitectura Mensajeria

DEPARTAMENTO DE SISTEMAS
JMS
Arquitectura de Software
1
Agenda
Introduccin
Message-oriented middleware (MOM)
Modelos de mensajera
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 Caractersticas MDB
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
Patrones de integracin y Apache ActiveMQ
2
Introduccin
Mensajera
o En JEE el trmino mensajera se refiere a la comunicacin
con bajo acoplamiento entre un emisor y un receptor, de
forma asncrona.
o Su comportamiento se puede asimilar a un buzn de voz,
donde un emisor (producer) deja un mensaje en un
destino especfico, para que un receptor (consumer) lo
recoja cuando pueda.
3
Introduccin
Comunicacin sncrona
o Invocacin de mtodos
! Java RMI
o Quien invoca y quien es invocado deben estar
presentes para que la comunicacin se realice.
o El emisor debe esperar respuesta del receptor, para
realizar otra peticin.
o Ejemplo: llamada telefnica
4 Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
Introduccin
Comunicacin asncrona
o No se necesita la presencia del emisor y el receptor
para realizar la comunicacin
o El receptor responde en el momento que pueda
o Se requiere de un Sistema de mensajera
(Message-oriented middleware - MOM)
o Ejemplo: Buzn de voz, en este se almacenan los
mensajes y el receptor puede recibir los mensajes y
revisarlos en otro momento.
5
Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
Agenda
Introduccin
o Point to point
o Arquitectura JMS
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
6
Este sistema de mensajera coordina y administra el
envo y recepcin de mensajes. Su principal propsito
es mover los mensajes del computador de un emisor al
computador del receptor. Transmisin esencial de envo
de mensajes:
El sender
crea el
mensaje
El sender
adiciona el
mensaje
al canal
El sistema de
mensajera
mueve los
mensajes del
computador del
sender al receiver
El receiver
lee el
mensaje
del canal
El receiver
procesa el
mensaje
7
Tomado de: Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf
Es un software que permite la comunicacin asncrona entre
componentes.
Cuando un mensaje es enviado, el MOM lo almacena en una ubicacin
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 informacin
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
Introduccin
o Point to point
o Arquitectura JMS
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
10
Un modelo de mensajera es un camino de
mensajera utilizado, en el cual se involucra un
nmero 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 ms 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
Introduccin
o Point to point
o Arquitectura JMS
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
15
JMS es un estndar de mensajera (Java)
Diseado para aplicaciones basadas en componentes
J2EE / JEE
Provee un API para manipular mensajes
o Crear
o Enviar
o Recibir
o Leer
16
Caractersticas
Permite comunicacin distribuida con bajo
acoplamiento, confiable y asncrona.
Provee un modelo estndar en Java para acceder a
MOM.
Permite crear aplicaciones de mensajera portables.
Los clientes JMS pueden usar el API JDBC
17
Caractersticas
El API JMS no incluye:
o Balanceo de carga y tolerancia a fallos
o Administracin, JMS no especifica un API para
administracin de mensajera
o Seguridad, JMS no especifica un API para controlar
la privacidad y la integridad de los mensajes
18
Arquitectura JMS
Partes de una aplicacin JMS
o JMS Clients: Programas en Java que envan 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 aplicacin para
comunicar informacin entre sus clientes.
o JMS Provider: Sistema de mensajera que implementa un producto de
mensajera.
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 conexin
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 conexin.
o Connection: es una conexin 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 ms objetos Destination
3. Usa el ConnectionFactory para crear una Connection
4. Usa el Connection para crear una o ms 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 conexin a
MOM
Crea sesin JMS.
Contexto orientado a
tareas para enviar y
recibir mensajes
Transaccional. Las solicitudes para
enviar mensajes no sern realizadas
hasta que se llame el mtodo commit
o la sesin sea cerrada. Si no es
transaccional el mensaje se enva
cuando se invoca el mtodo send.
Modo acknowledge
Crea objeto de conexin. Conexin origen
Emisor
Mensaje que se
enva
Envo de
mensaje y cierre
de conexin
Crea objeto de
conexin.
Conexin de
destino (cola)
24
Arquitectura JMS
Envo de mensajes
Recepcin de mensajes (sncrono).
Recibir mensajes
en la cola. Llama
bloques indefinidos
Limitar la cantidad
de tiempo de
recepcin, en
milisegundos
Recepcin de mensajes (asncrono).
El cliente debe
crear un message
listener que
implementa la
interfaz
MessageListener
25
El cdigo fu tomado de: Java Message Service API Version 1.1
Arquitectura JMS
El programa cliente registra
el objeto MessageListener
con el objeto
MessageConsumer
La conexin debe empezar para el envo de mensajes
El MessageListener es notificado asncronamente cuando un mensaje es publicado en la
cola
Esto se hace a travs del mtodo onMessage de la interfaz MessageListener
26
El cdigo fu tomado de: Java Message Service API Version 1.1
Modelo de mensajes JMS
Estructura modelo de mensajes JMS
Cabecera: contiene
informacin 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 informacin 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 informacin revisar la especificacin JMS Versin 1.1
29
Propiedades definidas en JMS
Para mayor informacin revisar la especificacin JMS Versin 1.1
30
JMS provee 5 formas para el cuerpo de un mensaje, cada
una definida por una interfaz de mensaje
Forma de mensaje Descripcin
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 insercin
de propiedades puede afectar el formato.
31
Ejemplos de definicin de tipos de mensaje:
o TextMessage
o BytesMessage
32 El cdigo fu tomado de: Java Message Service API Version 1.1
o MapMessage
33 El cdigo fu tomado de: Java Message Service API Version 1.1
Agenda
Introduccin
o Point to point
o Arquitectura JMS
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
34
Es un enterprise bean que permite a las aplicaciones JEE
procesar mensajes de forma asncrona
35
Caractersticas MDB
Acta como un listener de mensajes JMS
Los mensajes pueden ser enviados por cualquier componente
JEE (aplicacin cliente, otro enterprise bean) o por una
aplicacin JMS o un sistema que no utilice la tecnologa JEE
Puede procesar mensajes de JMS u otro tipo de mensajes
Comnmente son implementados con tecnologa JMS.
Las conversaciones no mantienen el estado conversacional
de las instancias de un cliente especfico.
36
Caractersticas 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 annimos, no son identificados por el
cliente
Los componentes cliente no localiza los message-driven beans ni
invocan directamente los mtodos del mismo
Son invocados de forma asncrona
Un message-driven bean puede procesar mensajes de mltiples
clientes.
37
Beneficios MDB
Maneja un sistema de pooling que facilita el proceso
de mensajes en paralelo al usar mltiples instancias
de MDB
Gestionan el proceso de lectura de mensajes
Automatizan el proceso de conectarse al almacn 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 inyeccin de dependencia, el contenedor inyecta esta referencia
antes de la instanciarlo
2. El contenedor llama al mtodo 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 mtodo 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 enva mensaje
41
Ej: Procesador de mensaje MDB
Recibe el mensaje
enviado
Provee informacin
de configuracin de
un sistema
especfico de
mensajera
42
El cdigo 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 declaracin de la clase
o Indirectamente: A travs 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 pblica
Debe tener un constructor sin argumentos
No se pueden definir mtodos final en la clase
Debe implementar todos los mtodos de la interfaz y estos deben
ser pblicos
No debe generar excepciones javax.rmi.RemoteException o alguna
excepcin de tiempo de ejecucin, si se genera la instancia del
MDB es terminada
43
Ejemplo 2
44
Desarrollo MDB
Anotaciones
o @MessageDriven
o @ActivationConfigProperty
Definicin 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 cdigo 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
mtodos implementados
Usando messageListenerInterface como parmetro de la anotacin
@MessageDriven :
@MessageDriven(
name="ShippingRequestJMSProcessor",
messageListenerInterface="javax.jms.MessageListener")
public class ShippingRequestProcessorMDB {
Realizando la implementacin directamente:
public class ShippingRequestProcessorMDB implements MessageListener {
46
Desarrollo MDB
Uso de ActivationConfigProperty
Provee informacin para la configuracin de un sistema de
mensaje especfico a travs 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 fbrica
de conexin 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
Desarrollo MDB
Acknowledge Mode
o Hay muchos modos para hacer acuse de recibido de los mensajes.
Por defecto para una sesin JMS se usa el modo
AUTO_ACKNOWLEDGE.
o Se implementa a travs de un @ActivationConfigProperty
48
Desarrollo MDB
Enviando mensaje de
confirmacin al cliente
49
El cdigo fue tomado de: EJB 3 Developer Guide
Desarrollo MDB
subscriptionDurability
o Slo aplica para PUB/SUB
o Se puede definir si el Topic de subscripcin es durable o no
o Una vez que el consumidor obtiene una suscripcin duradera
sobre un Topic, se garantiza que todos los mensajes
enviados al Topic se entregarn 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 sern
durables para el
suscriptor ID
JoeOgler
Remover suscripcin
50
Desarrollo MDB
Suscripcin 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
especficas 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
lgicos, aritmticos y de comparacin
52
Buenas Prcticas MDB
Escoja su modelo de mensajera cuidadosamente: PTP
o PUB/SUS
Recuerde modularizar: es necesario modularizar y
desacoplar teniendo presente el concern de mensajera
Escoja los tipos de mensajes cuidadosamente
Configure el tamao del pool de MDB
53
Agenda
Introduccin
o Point to point
o Arquitectura JMS
o Proceso MDB
o Ciclo de vida MDB
o Desarrollo MDB
54
Patrones de integracin
Desafos de la comunicacin Asncrona
o Modelo complejo de programacin
! Requiere un modelo de programacin orientado por eventos.
o Sensible al orden de ocurrencia de los eventos
! Los canales garantizan el envo de mensajes
! No garantizan cuando el mensaje ser entrega
! Esto puede causar envo de mensajes con o sin secuencia
! Se debe revisar el re-establecimiento de secuencia de mensajes
o Desempeo
o Soporte limitado a algunas plataformas
55
Patrn Caso Solucin Ventajas
Pipes and
Filters
Se requeire
procesar mensajes
complejos
manteniendo
independencia y
flexibilidad
1. Una primera solucin podra ser
definir un mdulo de mensajera
con las funciones requeridas, pero
esto puede ser inflexible y difcil de
probar. Adems al crear todo en
solo mdulo se presentan
problemas para reutilizarlo.
2. La solucin est en implementar
todas las funciones distribuidas en
distintos componentes. Estos
componentes deben ofrecer
interfaces genricas y permitir el
intercambio de informacin.
1. Componentes desacoplados
2. El Pipe permite a un
componente enviar un mensaje
por medio de l, que puede ser
consumido despus por otro
componente.
3. El pipe se comporta como un
canal de mensajes.
4. Provee independencia entre los
filtros de lenguaje, plataforma y
localizacin.
5. Manejo de mltiples canales
6. Permite realizar pruebas
El uso del estilo arquitectural de Pipes and Filters divide la tarea de procesamiento en una
secuencia de pasos pequeos 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 mltiple
57
Patrn Caso Solucin Ventajas
Message
Translator
Se requiere
comunicar diferentes
sistemas que
manipulan datos en
diferentes formatos
Esto se presenta en
sistemas de
integracin, p.e.
comuniacin con
sistemas Legado
1. Se podran modificar las aplicaciones
existentes con el riesgo de generar
fallas en las funcionalidades actuales.
2. Incorporar transformacin directamente
en el endpoint de cada mensaje, esto
requiere acceso al cdigo del
endpoint ,lo cual no es fcil 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
Patrn Caso Solucin
Message
Translator
Muchas aplicaciones deben
usar notificacin 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 enva por un canal. El
observer*, recibir el mensaje de enveto, tomar el
evento y lo procesar. El sistema de mensajera no
enva mensaje de notificacin, slo asegura que la
notificacin llega al observador . En Java, un evento
puede ser un objeto como un XML, esto puede ser
transmitido a travs de un ObjectMessage de JMS.
El patrn Observer [GoF], describe como disear un sujeto que anuncie eventos y los observadores que consumen eventos.
59
Patrn Caso Solucin
Message
Expiration
Si los datos de un mensaje o
solicitud no es recibida por cierto
tiempo, esta debera ser ignorada.
Los datos de un mensaje son tiles
en cierto tiempo, se puede
garantizar la entrega del mensaje,
pero no el tiempo lmite de entrega.
P.e. En la consulta de una cotizacin
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 shouldnt be
processed?
1. Modificar la expiracin 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
mensajera
detecta que el
mensaje expir lo
enva por el Dead
Letter Channel.
En JMS el parmetro Time-To-Live es utilizado, para especificar cuanto tiempo despus de
enviado el mensaje expira.
MessageProducer.setTimeToLive(long) -> Modifica el tiempo de todos los mensajes enviados.
Un emisor puede tambin modificar el time-to-live de un slo mensaje usando el mtodo:
MessageProducer.send(Message message, int deliveryMode, int priority, long timeToLive) .
61
Apache ActiveMQ
Apache ActiveMQ es una aplicacin open source
(Apache 2.0 licensed) de mensajera empresarial, la
cual implementa JMS version 1.1
Provee las caractersticas como clustering,
almacenamiento de multiples mensajes.
Est integrado con los patrones de integracin
empresarial
62
Apache ActiveMQ
Soporta diferentes protocolos como: Ajax, REST,
OpenWire, XMPP
Soporta caractersticas avanzadas como:
o Mensajes a grupos
o Consumidores exclusivos
o Composicin de destinos
o Mensajes Advisory
Soporta conexiones con reconexin automtica
Soporte a Spring
Soporta destinos distribudos a travs de la red
63
Bibliografa
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 Mensajeria

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Arquitectura Mensajeria

Caricato da

Copyright:

Formati disponibili

DEPARTAMENTO DE SISTEMAS

Potrebbero piacerti anche