Diferencia entre revisiones de «JMS»

De Dos Ideas.
Saltar a: navegación, buscar
(Ver también)
 
(No se muestran 4 ediciones intermedias de 4 usuarios)
Línea 5: Línea 5:
 
Supongamos que existen 2 aplicaciones, Dib y Gaz. Dib sabe comer, y Gaz sabe hacer tostadas.  
 
Supongamos que existen 2 aplicaciones, Dib y Gaz. Dib sabe comer, y Gaz sabe hacer tostadas.  
  
Cuando Dib tiene hambre, necesita realizarle un pedido a Gaz ("haceme 3 tostadas"). Usualmente, cuando Dib se levanta a la mañana le pide a Gaz las tostadas, y espera hasta que estén listas. Y este es el comportamiento que usamos generalmente en nuestras aplicaciones: al invocar a otra aplicacion nuestra, lo hacemos via un EJB, y esperamos una respuesta "en el momento" (sincrónica) de la operación.  
+
Cuando Dib tiene hambre, necesita realizarle un pedido a Gaz ("hazme 3 tostadas"). Usualmente, cuando Dib se levanta por la mañana le pide a Gaz las tostadas, y espera hasta que estén listas. Y este es el comportamiento que usamos generalmente en nuestras aplicaciones: al invocar a otra aplicación nuestra, lo hacemos via un EJB, y esperamos una respuesta "en el momento" (sincrónica) de la operación.  
  
 
Ahora bien, hace unas semanas que Gaz consiguió un trabajo, así que no está durante toda la mañana. Y Dib estudia de noche y vuelve tarde, cuando Gaz ya está durmiendo. ¿Cómo comunicar entonces a estas dos aplicaciones, si ambas pueden no estar online en el mismo momento?  
 
Ahora bien, hace unas semanas que Gaz consiguió un trabajo, así que no está durante toda la mañana. Y Dib estudia de noche y vuelve tarde, cuando Gaz ya está durmiendo. ¿Cómo comunicar entonces a estas dos aplicaciones, si ambas pueden no estar online en el mismo momento?  
Línea 11: Línea 11:
 
La solución a esto sería que Dib dejara una "petición" en algún lado (¿un papelito en la heladera?), y Gaz lo leyera cuando tenga tiempo y pueda cocinar las tostadas para Dib.  
 
La solución a esto sería que Dib dejara una "petición" en algún lado (¿un papelito en la heladera?), y Gaz lo leyera cuando tenga tiempo y pueda cocinar las tostadas para Dib.  
  
Justamente, esta comunicación asincrónica es el principio de la cola de mensajes.  
+
Justamente, esta comunicación asincrónica es el principio de la cola de mensajes.
  
 
== La cola de mensajes ==
 
== La cola de mensajes ==
Línea 40: Línea 40:
 
==== Otros tipos de mensaje  ====
 
==== Otros tipos de mensaje  ====
  
En el ejemplo, utilizamos un objeto !TextMessage para enviar el mensaje, pero existen otros tipos de mensaje muy útiles. Uno en particular es !MapMessage, que parmite al mensaje agregarle varios pares de "clave-valor" para luego recuperarlos. Además, existe otro mensaje de tipo !ObjectMessage que permite enviar un objeto completo (serializable) dentro del mensaje.  
+
En el ejemplo, utilizamos un objeto !TextMessage para enviar el mensaje, pero existen otros tipos de mensaje muy útiles. Uno en particular es !MapMessage, que permite al mensaje agregarle varios pares de "clave-valor" para luego recuperarlos. Además, existe otro mensaje de tipo !ObjectMessage que permite enviar un objeto completo (serializable) dentro del mensaje..
  
 
== Ver también ==
 
== Ver también ==
Línea 51: Línea 51:
 
*[[Mensajeria Con Spring]]  
 
*[[Mensajeria Con Spring]]  
 
*[[SAF en WebLogic]]
 
*[[SAF en WebLogic]]
 +
*[[Apache ActiveMQ]]
 
*[http://www.programacion.com/java/articulo/jms/ Tutorial sobre JMS ]  
 
*[http://www.programacion.com/java/articulo/jms/ Tutorial sobre JMS ]  
 
 
'''Texto en negrita'''
 
  
 
[[Category:JMS]]
 
[[Category:JMS]]

Revisión actual del 14:09 8 jul 2011

Java Messaging Service es un API de Java que permite interactuar con colas de mensajes.

Qué son las colas de mensajes

Supongamos que existen 2 aplicaciones, Dib y Gaz. Dib sabe comer, y Gaz sabe hacer tostadas.

Cuando Dib tiene hambre, necesita realizarle un pedido a Gaz ("hazme 3 tostadas"). Usualmente, cuando Dib se levanta por la mañana le pide a Gaz las tostadas, y espera hasta que estén listas. Y este es el comportamiento que usamos generalmente en nuestras aplicaciones: al invocar a otra aplicación nuestra, lo hacemos via un EJB, y esperamos una respuesta "en el momento" (sincrónica) de la operación.

Ahora bien, hace unas semanas que Gaz consiguió un trabajo, así que no está durante toda la mañana. Y Dib estudia de noche y vuelve tarde, cuando Gaz ya está durmiendo. ¿Cómo comunicar entonces a estas dos aplicaciones, si ambas pueden no estar online en el mismo momento?

La solución a esto sería que Dib dejara una "petición" en algún lado (¿un papelito en la heladera?), y Gaz lo leyera cuando tenga tiempo y pueda cocinar las tostadas para Dib.

Justamente, esta comunicación asincrónica es el principio de la cola de mensajes.

La cola de mensajes

Una cola de mensajes es un lugar común (la heladera) donde algunas aplicaciones publican mensajes, que son consumidos por otras. Existen así 4 componentes principales en un sistema de mensajería:

  • publicador, es decir, quien publica un Mensaje en una Cola
  • consumidor, quien consume Mensajes de una Cola
  • mensaje, que tiene algún formato que tanto publicador como consumidor conocen.
  • cola, que es el lugar donde publicadores y consumidores se conectan y comunican a través de mensajes.

Es importante destacar que es un sistema asíncrono: el publicador y el consumidor no necesitan estar disponibles a la vez, ya que la cola actúa de intermediario, guardando y distribuyendo los mensajes a medida que el consumidor pueda atenderlos.

El API de JMS

Tipos de destinos

En JMS existen dos tipos de destinos: Queue (colas) y Topic.

Queue

En las Queue, existen uno o varios publicadores, y un consumidor. Los publicadores van dejando sus mensajes en la cola, y son tomados en orden por el consumidor (y luego se van descartando). Si el consumidor no está disponible, la cola va guardando ("encolando") los mensajes, de manera que el consumidor pueda retomar su procesamiento cuando vuelva a estar online.

Topic

Los Topic siguen el modelo "publicador/subscriptor". Uno o varios consumidores se "suscriben" al Topic, y van recibendo los mensajes que se publican. Cuando se desconectan dejan de recibir esos mensajes, y los pierden.

Otros tipos de mensaje

En el ejemplo, utilizamos un objeto !TextMessage para enviar el mensaje, pero existen otros tipos de mensaje muy útiles. Uno en particular es !MapMessage, que permite al mensaje agregarle varios pares de "clave-valor" para luego recuperarlos. Además, existe otro mensaje de tipo !ObjectMessage que permite enviar un objeto completo (serializable) dentro del mensaje..

Ver también