| (Anterior) CMP ("Container Managed Persistence") |
| Otros Conceptos (Siguiente) |
|
Sistemas Messaging.
Para entender como es utilizado y porque surgió un "Messaging Bean" es necesario entrar en detalle sobre lo que es un "Messaging System" en sí.
Un "Messaging System" permite una conexión flexible entre un Cliente y un Servidor en un Sistema, esta flexibilidad denominada en Inglés "Loosley Coupled" permite que la comunicación entre el Cliente y el Servidor sea llevada de una manera asincrónica también llamada "Non-Blocking", observe:
 |
El diagrama izquierdo es como típicamente se lleva acabo la comunicación entre un cliente y servidor, sin embargo, esta comunicación implica que el servidor debe interactuar directamente con el cliente, lo que ocurre en este tipo de circunstancias es que el cliente se bloquea hasta que el servidor envía una respuesta; la importancia de una comunicación asincrónica o "Non-Blocking" se hace evidente en sistemas de proceso duraderos o distribuidos, tal sería el caso de un sistema de reservaciones o autorización de tarjetas de crédito; imagínese que cuando realizara una compra vía Internet tuviera que esperar a que su tarjeta de crédito fuera autorizada por el sistema bancario en ese instante, esto pudiera durar minutos u horas, es aquí donde los "Sistemas Messaging" juegan un papel importante.
Además de esta funcionalidad asincrónica ("Non-Blocking") los sistemas "Messaging" ofrecen otras funcionalidades como:
- Prioridad de mensajes: Esto permite que la información sea enviada al servidor en base a ciertos lineamientos.
- Publicar/Subscribir : Este mecanismo permite que el mensaje enviado por el cliente pueda ser consumido por más de un servidor.
Obviamente existen otro tipo de detalles pero estos conciernen a un "Messaging System" y no al tema central de "Enterprise Java Beans"; algunos "Messaging Systems" (MOM's) del mercado son: Rendezvous de Tibco, MQSeries de IBM , MSMQ de Microsoft, SmartSockets de Talarian, SonicMQ de Progress y FioranoMQ de Fiorano.
JMS: Integración de "Sistemas Messaging" a Java.
Todos los Sistemas "Messaging" mencionados anteriormente emplean diversas metodologías propietarias para establecer la comunicación entre el Cliente y el Servidor, desde luego esto no fue aceptable a la promesa Java de "Write Once-Run Everywhere" (Escribalo una vez ejecutelo en todos lados) y debido a esto surgió JMS ("Java Messaging Service"), es a través de este API que es posible escribir Clientes y Servidores en Java y que éstos interactúen con cualquier "Sistema Messaging"; el principio de JMS es el mismo utilizado para JDBC en Bases de Datos: un Driver que permita interoperabilidad Java.
En su concepción JMS solo fue diseñado para integrar a un "Sistema Messaging" el lenguaje Java, sin embargo, hoy en día ya han sido agregadas las funcionalidades necesarias para integrar JMS a un "Application Server/EJB Container", las cuales son llevadas a través de un "Enterprise Java Bean" denominado "Messaging Bean".
Diferencias entre Session y Entity EJB's, "Point-to-Point" y "Publish/Subscribe".
La primera y gran diferencia comparado con un "Session y Entity EJB's" es:
- Un "Messaging EJB" no utiliza ninguna interfase ("Home" o "Remote" ).
La razón por la cual no posee interfases es que un "Messaging Bean" simplemente procesa mensajes, los cuales no solamente pueden provenir de clientes Java (JSP/Servlets/Applet) sino también de un sistema messaging como los mencionados anteriormente; la segunda diferencia es:
- Un "Messaging Bean" solo contiene un método de negocios llamado
onMessage().
Esto se debe a que el "Messaging Bean" sólo consume mensajes, no ejecuta ningún tipo de lógica a diferencia de un "Session EJB" o "Entity EJB" que puede ejecutar diversas operaciones sobre determinada información; otra diferencia es:
- Un "Messaging Bean" no posee ningún tipo de estado.
Lo anterior es parte central del funcionamiento "Messaging/Non-Blocking", el mismo principio de "No Bloqueo" hace que el "Messaging EJB" no sea capaz de re-establecer comunicación posterior con el cliente, por ende no posee ningún estado.
"Point-to-Point" y "Publish/Subscribe".
Al igual que otros EJB's, para un "Messaging EJB" existen dos modalidades las cuales están basadas en las mismas facilidades ofrecidas por un "Sistema Messaging" una es "Point-to-Point" y la otra "Publish/Subscribe".
"Point-to-Point" como su nombre implica (punto a punto) ofrece una metodología sencilla para la transmisión de mensajes, su funcionamiento es similar a los buzones de voz utilizados hoy en día, se envía un mensaje el cual es recibido independientemente del estado del destinatario final, posteriormente el destinatario final consume el mensaje una vez; el lugar donde es colocado el mensaje es llamado queue, note el énfasis que el mensaje es consumido una vez.
A diferencia de "Point-to-Point", "Publish-Subcsribe" permite que el mensaje sea consumido en diversas ocasiones, esta metodología puede ser comparada con los sistemas de televisión por cable, existen diversas señales ("mensajes") publicados los cuales pueden ser consumidos por diversos subscriptores ; la ubicación donde son colocados estos mensajes es denominada tópico.
Diseño de un Messaging EJB.
El siguiente "Messaging Bean" es del tipo "Publish-Subscribe", dicho EJB recibe mensajes de un Cliente Java y los coloca bajo un topic, posteriormente un subscriptor ya sea un EJB("Session","Entity","Messaging") o JSP/Servlet puede tomar el mensaje del topic.
Como todo otro "EJB" es necesario definir su respectivo "Deployment Descriptor" mencionado a continuación.
Además del "Deployment Descriptor" es necesario definir valores que están directamente relacionados con el ambiente de ejecución, en JBoss estos se realizan a través del archivo jboss.xml:
Una vez activado ("deployed") el "Messaging EJB", es posible enviar mensajes a éste, a continuación se describe un cliente que realiza esta tarea:
En el cliente anterior notaría que al ser definido InitialContext no se incluyeron los parámetros del servidor JNDI. Debido a que los parámetros de este servidor JNDI son ampliamente utilizados en EJB's, es posible definirlos a través de un archivo especial, lo anteriro evita que todo EJB y sus respectivos clientes definan estos valores manualmente.
Este mecanismo es definido por Java y no depende del "Application Server/EJB Container"; al no definirse ningún parámetro en InitialContext se realiza una búsqueda por un archivo llamado jndi.properties, dicho archivo debe encontrarse en la variable CLASSPATH del sistema.
Una vez ejecutados todos los pasos anteriores es posible crear subscriptores que consuman el mensaje del EJB, estos pueden ser diez,cien o mil y también pueden variar desde paginas web, aparatos inalámbricos, "tickers" en piso de remates y otros más.
Para fines de este curso no será diseñado ningún subscriptor ya que esto concierne a un "Sistema Messaging"; para continuar con el tema central de "EJB's" en la siguiente sección se definen otros conceptos que son de suma importancia para EJB's.