JMS (Java Message Service) es un API que forma parte de la plataforma J2EE para acceder a Sistemas de mensajería (MOM).
Un MOM es un software de infraestructura que da soporte de envío y recepción de mensajes entre sistemas distribuidos. MOM permite a los módulos de aplicaciones ser distribuidos a través de plataformas heterogéneas y reduce la complejidad del desarrollo de aplicaciones que abarcan múltiples sistemas operativos y protocolos de red. El middleware crea una capa distribuida de comunicaciones que aísla al desarrollador de aplicaciones de los detalles de los diversos sistemas operativos y las interfaces de red. Las API se extiende por diversas plataformas.
MOM proporciona elementos de software que residen en todos los componentes de comunicación de una arquitectura cliente / servidor y por lo general apoyan las llamadas asíncronas entre las aplicaciones cliente y servidor. MOM reduce la participación de los desarrolladores de aplicaciones y la complejidad del mecanismo cliente / servidor.
JMS permite a los componentes de aplicaciones crear, enviar, recibir y leer mensajes. JMS en ese sentido es análogo a JDBC: JMS ofrece un interfaz de acceso común a diferentes MOMs.
JMS es pues un API para mensajería empresarial. Aunque incluido en Java EE, también disponible como un producto Stand Alone o independiente. Como vemos poco acoplado.
La idea general es que clientes y servidores envían mensajes. Estos no se conocen, puesto que JMS se encuentra en medio de ellos.
JMS no es una implementación de un gestor de mensajes (servidor de colas), es simplemente una API.
Como aclaración, por un lado tenemos el cliente que envía mensajes, y mediante la API JMS nos comunicamos con los diferentes productos o proveedores gestores de mensajes.
Ejemplos WMQ provider, ActiveMQ provider, TIBCO provider, SonicMQ provider.
JMS se abstrae a la hora de usar el gestor. Es independiente del provider.
Los mensajes poseen un formato determinado.
Las partes del mensaje son Headers, propiedades y un payload.
Existen 2 tipos de mensajes en JMS
Mensaje Punto a punto.
Existe un sender y una cola, y multiples receptores. La cola determina el receptor.
Suscripción de mensajes de dominio.
El Publisher envía un mensaje que es entregado a múltiples suscriptores. Este tipo de mensajes puede ser colectivo. Este tipo de mensajes es como estar suscrito a una lista de correo. Todos reciben una copia del mensaje.
Comentemos algo sobre ActiveMQ una implementación JMS.
ActiveMQ es un Middleware orientado a mensajes. Entre el cliente y servidor. Se sitúa en medio.
Es un producto de la fundación Apache. Licencia Apache, con todas las ventajas que ello conlleva, modificación, redistribución, etc. Compatible con la API JMS 1.1
La meta es, basado en estándares, integrar aplicaciones orientadas a mensajes a través de multiples lenguajes y plataformas.
Es muy fácil enviar y recibir mensajes
Desde consola de comandos o Shell bash en Linux, arrancamos activemq
./bin/activemq
ant consumer -> ejecutando un script ant. Esperando mensajes
ant producer-> Enviamos mensajes.
No se necesita nada especial, descargar el producto, ejecutamos el producto, el receptor y el emisor. Ejecutamos ejemplos. No requiere una instalación grande ni costosa. Una de las cosas que diferencia a ActiveMQ respecto a otros middeware es la rápida puesta a punto.
Otro de los rasgos que lo diferencian respecto a otras soluciones propietarias del mercado, es la configuración. Esta se realiza en XML en el archivo conf/activemq.xml
El archivo xml de configuración, poseen beans para configurar el framework spring.
Podemos configurar las políticas,el contexto, conexiones de red, adaptadores, persistencia de mensajes,la memoria, los conectores de transporte.
Los conectores de transporte pueden ser via ssl, stomp,xmpp, openwire,etc, bajo determinados puertos.
En pocas líneas de código podemos embeber dentro de nuestra aplicación JAVA, ActiveMQ, fácilmente se puede integrar el broker.
ActiveMQ usa URIs del estilo o sintaxis:
<protocol>://<host>:<port>?<transport-options>
La interrogación nos permite configurar múltiples opciones en el transporte.
Cuando configuramos un cliente para hablar con ActiveMQ, podemos establecer los diferentes transportes establecidos en el fichero xml de configuración.
Ejemplos:
vm://localhost?broker.persistent=false
tcp://localhost:61616?jms.useAsyncSend=true
Stomp://localhost:61613
Failover:(tcp://host1:61616,tcp://host2:61616)?initialReconnectDelay=100
El TCP suele ser muy común en ActiveMQ. Las cadenas superiores son las que se pasan desde el cliente hacia el broker.
El failover permite reconectar con diferentes host en caso de fallo.
ActiveMQ soporta diferentes formatos Wire:
Los formatos Wire o Wire Format se refieren a los diferentes formatos de los mensajes enviados usados como norma empleados por el adaptador
OpenWire: Por defecto en ActiveMQ, protocolo binario, para clientes C++, Java y .NET
STOMP, Simple Text Oriented Messaging Protocol, basado en texto, para clientes C, Javascript,Perl, PHP, Python, Ruby y alguno más
XMPP (Jabber XML protocol).
REST (HTTP Post y GET)
AMQP.
Si quieres indagar sobre estos formatos, a wikipedia 🙂
Por otro lado existen dos tipos de transportes en el protocolo:
Del cliente , hacia el broker (mediante conector de transporte)
Del broker al broker (mediante conector de red). Puedes hacer que los brokers se comuniquen. Y que los mensajes pasen entre ellos.
Respecto a los conectores de transporte:
Se encuentran los client to broker conections, similar en el uso a JDBC con las bases de datos. Los protocolos soportados son: TCP,UDP,NIO, SSL, HTTP/S, SSL, VM, XMPP
Cuando ejecutamos el cliente, podemos conectarnos con el broker con cualquiera de estos protocolos.
Respecto a los protocolos soportados por las conexiones broker to broker:
Static (IP), Failover, multicast, Zeroconf, peer,fanout, discovery
Podemos crear diferentes topologías entre brokers. Estrella, Estrella-Estrella,punto a punto, etc …
Cuando hablamos de JMS una de las cosas que se emplean es la persistencia de mensajes. Existen 3 tipos de persistencias en AMQ.
Transaction message storage solution (por defecto).
Non-Journaled JDBC (no muy rapida)
Journaled JDBC
Los brokers pueden ser configurados como maestros y esclavos.
Existen 3 tipos de Master/slave
– Puros, Pure master/slave.(investigar).
– Shared filesystem master/slave
-JDBC master/slave
Monitorización
Con JMX, ActiveMQ web console, Camel routes, SpringSource AMS, IONA FuseHQ
Esto es una recopilación de una charla que he escuchado sobre ActiveMQ, espero que sirva de resumen.
Saludos.
Enlace del producto:
Libro recomendado sobre EIP (Enterprise Integration Patterns)
http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683
