queue - informatica - mqseries manual español
Mensajería, colas y ESB: sé dónde quiero estar pero no cómo llegar allí (6)
He trabajado con mensajería JMS en varios sistemas de software desde 2003. Tengo una aplicación web donde los clientes son suscriptores de temas de JMS. Con el mero hecho de publicar un mensaje en un tema, el mensaje se envía al servidor y se disemina a todos los clientes web suscriptores.
El cliente web está basado en Flex. Nuestra pila de nivel medio consiste en:
- Java 6
- Tomcat 6
- BlazeDS
- Spring-Framework
- ActiveMQ (intermediario de mensajes JMS)
BlazeDS tiene la capacidad de configurarse como un puente a JMS. Es un servlet de Tomcat que responde a llamadas remotas de clientes Flex pero también puede enviar mensajes a los clientes cuando aparecen nuevos mensajes en el tema JMS en el que está configurado.
BlazeDS implementa el Comet Pattern para hacer push de mensaje del lado del servidor:
Farata Systems ha anunciado que han modificado BlazeDS para que funcione con el enfoque de continuación de Jetty para implementar el Comet Pattern. Esto permite escalar miles de conexiones de Comet contra un solo servidor físico.
Farata Systems logra un gran avance con Adobe BlazeDS
Estamos esperando que Adobe implemente el soporte de Servlet 3.0 en BlazeDS, ya que básicamente estamos bastante comprometidos con el uso de Tomcat y Spring en combo.
La clave de la técnica de hacer un patrón Comet masivamente escalable es utilizar oyentes HTTP de Java NIO junto con un grupo de subprocesos (como la clase Executor en la biblioteca de Concurrencia de Java 5). El Servlet 3.0 es un modelo impulsado por eventos asíncronos para servlets que pueden vincularse con dicho oyente HTTP. Miles (números como de 10,000 a 20,000) conexiones de Comet concurrentes se pueden mantener contra un solo servidor físico.
Aunque en nuestro caso estamos utilizando la tecnología Adobe Flex para convertir a los clientes web en suscriptores de mensajería orientados a eventos, lo mismo podría hacerse con cualquier aplicación web genérica de AJAX. En círculos AJAX, la técnica de hacer push de mensaje en el lado del servidor a menudo se denomina AJAX inverso . Puede haber captado que Comet es un juego de palabras, como en la contraparte de Ajax (ambos limpiadores domésticos). Lo bueno para nosotros, sin embargo, es que simplemente conectamos nuestras piezas y nos vamos. Los codificadores genéricos de AJAX tendrán mucho más trabajo de programación por hacer. (Incluso una aplicación web genérica podría jugar con BlazeDS, sin embargo, simplemente no tendría ningún uso para la clasificación de AMF que BlazeDS es capaz de).
Finalmente, Adobe y SpringSource están cooperando para establecer una integración más fluida y fuera de lo común de BlazeDS junto con Spring-Framework:
Para abreviar, estoy trabajando en un proyecto en el que estamos reescribiendo una gran aplicación web por todos los motivos habituales. El objetivo principal de la reescritura es separar esta gran aplicación única que se ejecuta en un solo servidor en muchas aplicaciones desacopladas más pequeñas, que se pueden ejecutar en muchos servidores.
Ok, esto es lo que me gustaría:
Me gustaría que HTTP sea el principal mecanismo de transporte. Cuando una aplicación, por ejemplo, el CMS se haya actualizado, se pondrá en contacto con el intermediario a través de http y dirá "I''ve changed" , y luego el intermediario enviará un "thanks I got the message" 200 OK para decir "thanks I got the message" .
Luego, el intermediario buscará en la lista de otras aplicaciones que deseaba escuchar acerca de los cambios del CMS y pasaría el mensaje a la url que dejó la aplicación cuando le dijo al agente que deseaba escuchar sobre el mensaje.
Las otras aplicaciones devolverán 200 OK cuando reciban el mensaje; de lo contrario, el intermediario conservará el mensaje y lo pondrá en cola la próxima vez que alguien intente contactar esa aplicación.
El problema es que ni siquiera sé por dónde empezar o qué necesito para que ocurra. He estado buscando en XMPP , ActiveMQ , RabbitMQ , Mule ESB, etc. y puedo ver que podría pasar el próximo año dando vueltas en círculos con estas cosas.
¿Alguien podría ofrecer algún consejo de la experiencia personal ya que me gustaría evitar aprender lecciones de la manera difícil?
Antes que nada, no te preocupes por los ESB. La situación que ha descrito se encuentra dentro de los límites del middleware directo orientado a mensajes. Solo "necesita" un ESB si está haciendo cosas como mediaciones, enrutamiento basado en contenido, transformaciones de protocolo; cosas donde el middleware hace cosas para el mensaje, además de enrutarlo al lugar correcto.
Si tiene un conjunto diverso de aplicaciones de destino que necesitan hablar entre sí, y suena como lo hace, tiene razón en que la mensajería sobre un protocolo independiente del idioma (como XMPP, STOMP o HTTP) es una solución ordenada. Básicamente, significa que no tiene que escribir y ejecutar muchos daemons de Java para traducir mensajes en su sabor favorito de JMS.
STOMP es cada vez más compatible con los intermediarios de mensajes, especialmente por los de código abierto, y hay varias bibliotecas de clientes diferentes. Es un protocolo liviano, diseñado específicamente para enviar mensajes, de modo que obtienes una función mucho más rica que la que obtendrías con HTTP.
Para mí, XMPP es una opción un poco débil ya que no está tan bien respaldada por el lado del servidor, aunque es divertido poder enviar mensajes instantáneos a su agente de bolsa :)
Si está configurado en HTTP, OpenMQ es muy bueno, y he utilizado personalmente su Servicio Universal de Mensajes , básicamente un envoltorio de aplicaciones web para los destinos JMS. Proporciona una interfaz REST-ful, con un conjunto de verbos similar a los de STOMP.
Realmente está hablando de publicar y suscribirse con una entrega segura. La mayoría del software MOM debería ser compatible con su caso de uso.
Como alguien ya ha dicho, lo que describes es básicamente el modelo de editor / suscripción. Esto se logra muy fácilmente utilizando un ESB o una cola de mensajes. He tenido algo de experiencia con RabbitMQ. Es muy bueno. No se pierde nada y se trata muy bien del modelo de suscripción de publicación. En el pasado, he ido por la ruta en sistemas de pequeña escala para desarrollar mi propio agente de mensajes con un protocolo personalizado a través de http. No aconsejaría esto, porque la razón es que a medida que comienzas a desarrollarla, sigues pensando en formas de ampliarla.
RabbitMQ se desarrolla en Erlang pero tiene clientes java, net, python, etc. que pueden engancharse fácilmente. He usado los clientes .net y python, funciona bien. Lo elegí para la reputación de Erlangs por crear sistemas sólidos que pueden hacer frente a muchas cosas al mismo tiempo, muy bien. Yo los llamaría hilos, pero creo que es más inteligente que solo los hilos, creo que recuerdo los murmullos del Actor Model y los buzones de correo, que recuerdo fueron bastante prolijos.
Estaba en una posición similar a la tuya pero con muy malas experiencias de otros sistemas de mensajería (Biztalk et al.) Que eran demasiado decentes como para conectarte con una solución. Si puede mantener los mensajes separados de los mecanismos de transporte y entrega, puede desarrollar su sistema de acuerdo con su contenido. Usé JSON al final ya que los tamaños de paquete son pequeños. Puedes usar lo que quieras, algunos optan por los mensajes SOAP, pero creo que son demasiado pesados para la mayoría de las cosas, aunque te permiten dar esquemas XSD a personas externas para que puedan / puedan desarrollar sistemas que interactúen con tu sistema en el futuro.
http://www.rabbitmq.com/tutorials/tutorial-three-java.html , este es un enlace al tutorial sobre el modelo Publish / Subscribe y cómo lo lograría usando un sistema de cola de mensajes. Es para rabbitMQ, pero para ser honesto, funcionará con ESB y cualquier otro sistema de cola de mensajes.
Como ya se dijo antes, tener un ESB para usted en el caso actual me parece romper una mosca con un martillo.
El software ESB en sí requerirá mucho tiempo y requerirá mantenimiento. Si va a la solución de código abierto, puede llevar más tiempo que usar una solución con licencia (IBM, ORACLE, ...).
Por supuesto, un ESB haría el trabajo, y sería muy fácil desarrollar una solución, pero establecer un ESB sería mucho más difícil que hacer la solución en sí.
Si su problema está limitado al caso descrito, le recomendaría encarecidamente que construya una arquitectura simple sobre OpenMQ (o similar) y que la use a través de JMS.
ESB (Enterprise Serial Bus): considere esto cuando su aplicación tenga mucha interacción con dos o más aplicaciones externas / separadas donde cada una de ellas no se comunicará en un formato de datos similar. Ejemplo: algunos sistemas pueden aceptar objetos, XML, JSON, SMTP, TCP / IP, HTTP, HTTPS, etc.
ESB tiene muchas características como: enrutamiento, direccionamiento, estilos de mensajería, protocolos de transporte, modelo de mensajería de servicio.
Considere el sistema de cola si las aplicaciones productor - consumidor siguen el mismo tipo de formato de datos.
Los servicios web (SOAP / REST) son mejores si una aplicación necesita la otra aplicación para completar el flujo de trabajo. Use Colas si la aplicación necesita transferencia de datos asincrónica.