Arquitecturas de Integración Mensajería JEE Arquitecturas de Integración Mensajería 1

Qué es Mensajería? Forma de comunicación asincrónica entre componentes Usando mensajes Emisor y Receptor desacoplados Estos pueden desconocer la identidad del otro El Receptor puede no estar activo (funcionando) cuando se envía el mensaje Alternativa a las llamadas sincrónicas entre componentes (ej:RMI)‏ El Emisor envía un mensaje a un destino lógico No tiene que esperar una respuesta El Receptor toma el mensaje del destino o este se le reenvía cuando esté activo

Modelo de Comunicación usando Mensajería Receptor Mensaje Contenedor Emisor Destino Consume Envia Destino Emisor Receptor Mensaje Destino

Pros y Contras de usar Mensajería Llamadas asincrónicas Un componente puede llamar a otro sin tener que esperar por una respuesta inmediata el tiempo total de ejecución del Emisor no tiene que incluir el tiempo de ejecución del Receptor Mejor uso de recursos menos tiempo de ejecución por componente uso de memoria y servicios Reduce las dependencias entre componentes Un componente no tiene que conocer la identidad ni la ubicación fisica de otro para poder ejecutarlo Puedo cambiar la identidad, ubicación fisica e implementación interna de un componente sin necesidad de recompilar a sus clientes Permite que una aplicación siga funcionando aún con algun componente fuera de línea Los mensajes quedan en el destino y pueden ser procesados más tarde

Pros y Contras de usar Mensajería Más complicado de codificar que una llamada común sincrónica Más codigo para enviar un mensaje Más codigo para consumir un mensaje Más configuración configuración de Destinos autenticacion para enviar y recibir persistencia de mensajes Recibir respuestas asincrónicas es complicado mecanismo de “enviar y olvidar” (fire and forget)‏ No hay validación en tiempo de compilación del contenido del mensaje un mensaje puede contener cualquier tipo de objeto contrato explícito vs. contrato implícito entre lo que pone el Emisor en el mensaje y lo que saca el Receptor

Mensajería en J2EE: JMS Java Messaging System Permite desde código Java enviar y recibir mensajes Es un estándar, cada Contenedor lo implementa el código se puede migrar a otro Contenedor JMS define dos tipos de Destinos para comunicar: Punto a Punto usando Colas Point to Point, Queues Publicación y Suscripción usando Tópicos Publish and Suscribe, Topics

Mensajería Punto a Punto Los mensajes se envian a Colas El Receptor consume mensajes de la cola a medida que llegan Un mensaje es consumido sólo por un Receptor En una misma Cola pueden recibir varios Receptores El Emisor generalmente no sabe quien va a consumir el mensaje finalmente Receptor Mensaje Emisor m8 m1 Cola m7 m6 m5 m4 m3 Consume Envia m2 Receptor Emisor

Mensajería Publicación y Suscripción Los mensajes se publican en Tópicos Cada mensaje publicado se entrega a todos los Suscriptores de ese Tópico Para garantizar la entrega, un Tópico se puede configurar como durable Los Suscriptores pueden recibir mensajes que fueron publicados mientras estaban inactivos Suscriptor A Mensaje Publicación m1 m1 Recibe Tópico A Suscriptor A y B m1 Publica Mensaje m2 m2 Recibe Publicación Tópico B m2 Suscriptor B

Donde usar JMS Integración entre aplicaciones dispares Inter empresa o intra empresas No controlo ni conozco la implementación de la otra aplicación Aplicaciones de diferentes tecnologías (ej: Java/Cobol)‏ mientras que pueden enviar/recibir mensajes JMS Desacoplar aplicaciones existentes Para lograr indepencia una de la otra facilidad para reemplazar cualquiera de las dos el unico punto de acoplamiento es el nombre del destino Procesamiento en forma asincrónica Procesos o cálculos que toman mucho tiempo me interesa que se ejecute y se grabe un resultado, no capturar ese resultado desde el cliente en el momento de la llamada Eventos que quiero ejecutar y no necesito esperar el resultado envio de mails, alertas

Uso de JMS Connection Factory Destinos Punto de acceso de un cliente con el sistema de JMS Se usa para establecer una conexión/sesión (connection/session)‏ Existen en el Servidor/Contenedor y deben estar previamente configurados El cliente accede a estos vía lookup de JNDI Destinos Colas y Tópicos con nombres lógicos

Un Mensaje JMS Un mensaje JMS consta de 3 partes Cabecera: uso interno para identificación, ruteo, prioridad, etc. Propiedades adicionales: tabla de clave/valor para información complementaria Cuerpo (opcional): contenido a enviar El Cuerpo puede ser de diferentes tipos Todos sub-interfaces de javax.jms.Message TextMessage: un objeto String (ej: XML)‏ MapMessage: tabla de clave/valor ObjectMessage: una clase Java Serializable

Uso de JMS: Enviar un mensaje PaP desde un Cliente Java Hashtable props = new Hashtable(); props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); props.put(InitialContext.PROVIDER_URL, "jnp://127.0.0.1:1099"); Context ctx = new InitialContext(props ); // buscar la Connection Factory en JNDI QueueConnectionFactory qfactory = (QueueConnectionFactory)ctx.lookup(”ConnectionFactory"); // buscar la Cola en JNDI Queue queue = (Queue) ctx.lookup(”queue/testQueue"); // crear la connection y la session a partir de la connection QueueConnection qCon = qfactory.createQueueConnection(); QueueSession qSession = qCon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); // crear un producer para enviar mensajes usando la session QueueSender qSender = qSession.createSender(queue); // crear un mensaje de tipo text y setearle el contenido TextMessage message = qSession.createTextMessage(); message.setText(“Producto21,10"); // enviar el mensaje qSender.send(message); // TODO: recordar cerrar la session y la connection en un bloque “finally”

Uso de JMS: Consumir un mensaje desde un EJB (MDB)‏ MDB: Message Driven Bean Tipo de EJB una forma fácil y rápida para consumir mensajes JMS no pueden ser invocados por un cliente, solo consumen mensajes JMS Permite la ejecución asincrónica de Beans las llamadas normales entre EJBs son siempre sincrónicas el que hace la llamada bloquea mientras se ejecuta la invocación del método los MDBs son asincrónicos, se invocan solo mediante mensajes Los Clientes no tienen acceso directo a un MDB no tienen interfaces home ni remote no tienen estado (como los Stateless Session Beans)‏ el ciclo de vida es controlado completamente por el contenedor La invocación es a través de un solo método, no tipificado onMessage(Message m);

Uso de JMS: Consumir un mensaje desde un EJB (MDB)‏ MDB: Message Driven Bean El contenedor actúa como un consumidor de mensajes de una cola o tópico los clientes envían mensajes a un destino JMS en forma normal no tienen que saber que el que los consume es un MDB Cuando se recibe un mensaje, el contenedor ejecuta el método onMessage() de un MDB disponible existe un pool de MDBs igual que los Stateless Session Beans El Bean procesa dentro del código del método onMessage()‏ el procesamiento entonces es asincrónico y desacoplado del cliente dentro del código puede llamar a otros EJBs (Stateless, Statefull o Entity)‏ No hay valor de retorno Las excepciones no se propagan hacia el Cliente