Mensajería, colas y ESB's - Sé dónde quiero estar pero no cómo llegar

Question

Para resumir, 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.

autorización aquí es lo que me gustaría:

me gustaría HTTP ser el principal mecanismo de transporte. Cuando una aplicación, por ejemplo, el CMS se ha actualizado entrará en contacto con el agente a través de http y decir "I've changed", entonces el agente devolverá un 200 OK 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 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, si no es así, el intermediario conservará el mensaje y lo pondrá en cola la próxima vez que alguien intente ponerse en contacto con esa aplicación.

El problema es que ni siquiera sé por dónde empezar o qué necesito para que suceda. He estado buscando en XMPP, ActiveMQ, RabbitMQ, Mule ESB etc., y puedo ver que podía pasar el año que viene dando vueltas en círculos con esta materia.

¿Alguien podría ofrecer algún consejo de la experiencia personal ya que me gustaría evitar aprender las lecciones de la manera difícil?

Answer 1

He trabajado con la mensajería JMS en varios sistemas de software desde alrededor de 2003. Tengo una aplicación web donde los clientes son efectivamente suscriptores del tema 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 consisten en:

• Java 6
• Tomcat 6
• BlazeDS
• Primavera-marco
• ActiveMQ (intermediario de mensajes JMS)

BlazeDS tiene capacidad para ser configurado 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 patrón Comet para hacer del lado del servidor de mensajes push:

Asynchronous HTTP and Comet architectures An introduction to asynchronous, non-blocking HTTP programming

Sistemas Farata ha anunciado que han modificado BlazeDS para trabajar con el enfoque continuaciones embarcadero para la implementación del modelo de cometa.Esto permite escalar miles de conexiones de Comet contra un solo servidor físico.

Farata Systems Achieves Performance Breakthrough with Adobe BlazeDS

Estamos a la espera de Adobe para implementar el soporte de Servlet 3.0 en BlazeDS a sí mismos como básicamente estamos bastante aferrados a la utilización de Tomcat y primavera en el combo.

La clave de la técnica de hacer un patrón Comet masivamente escalable es utilizar oyentes HTTP de Java NIO en conjunto con un grupo de subprocesos (como la clase Ejecutor 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 utilizamos la tecnología de Adobe Flex para convertir clientes web en suscriptores de mensajes basados ​​en 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 del lado del servidor a menudo se conoce como Reverse AJAX. 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 AMF que BlazeDS es capaz de).

Finalmente, Adobe y SpringSource están cooperando para establecer un integración de la caja de BlazeDS junto a la colección primavera-marco:

Adobe Collaborates with SpringSource for Enhanced Integration Between Flash and SpringSource Platforms

Answer 2

en primer lugar, no se preocupe 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 al mensaje, además de enrutarlo al lugar correcto.

Si tiene un conjunto diverso de aplicaciones de destino que necesitan comunicarse entre sí, y suena como lo hace, tiene razón en que enviar mensajes a través de un protocolo independiente del idioma (como XMPP, STOMP o HTTP) es limpio solución. 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 un poco de una opción débil, ya que no está tan bien apoyado en el lado del servidor, aunque es divertido ser capaz de enviar mensajes instantáneos a su corredor :)

Si se fijan en HTTP, OpenMQ es muy bueno, y he usado personalmente su Universal Message Service, 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.

Answer 3

Realmente está hablando de publicar y suscribirse con una entrega garantizada. La mayoría del software MOM debería ser compatible con su caso de uso.

Answer 4

Como alguien ya ha dicho, lo que usted describe básicamente es el Modelo de Publicador/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 está desarrollado en Erlang pero tiene clientes de java, net, python etc. que se pueden enganchar 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 adecuados como para conectarte a 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 de afuera 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 de publicación/suscripción y cómo lo lograría utilizando un sistema de cola de mensajes. Es para rabbitMQ, pero para ser honesto, funcionará con ESB y cualquier otro sistema de cola de mensajes.

Answer 5

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 estas no se comunicará en un formato de datos similar. Ej .: Algunos sistemas pueden aceptar objetos, XML, JSON, SMTP, TCP/IP, HTTP, HTTPS, etc.

ESB tiene muchas características como: Direccionamiento, 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.

Answer 6

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 configurar un ESB sería mucho más difícil que hacer la solución en sí.

Si el problema se limita al caso descrito, te sugeriría altamente que usted construya una arquitectura sencilla sobre OpenMQ (o similar), y su uso a través de JMS