El procesamiento de un mensaje tal vez

Question

Por favor, considere el escenario como se muestra en la imagen adjunta:

1. El Portal (productor) enviará algún mensaje al bus a la que tiene que ser procesado por múltiples aplicaciones (consumidor) - PAYROLLAPP, HELPDESK etc.
2. múltiples instancias de aplicaciones de consumo puede estar en ejecución, también estos casos pueden añadirse/eliminarse dinámicamente
3. Ahora, es fundamental asegurarse de que el mensaje se procesa solo una vez, por aplicación es decir, si PAYROLLAPP -1 procesa el mensaje, PAYROLLAPP -2 NO debe procesarlo; por supuesto, en el diagrama de arriba , HELPDESK - 1 debe procesarlo. En resumen, en el caso de varias instancias, exactamente uno debe procesar el mensaje, una vez
4. Cuando busqué las respuestas, la mayoría de las cosas se trataba de crear un 'consumidor selectivo' - un consumidor que acepta/rechaza un mensaje basado en algo de lógica: tenga en cuenta que no se pueden hacer cambios/adiciones/envolturas para las aplicaciones que se muestran en el diagrama; la lógica tiene que residir en algún lugar del proveedor que gestiona el bus

Por favor, siga más o menos lo mismo.

La adición de más detalles después de la respuesta de Petter:

1. Los artículos a la a la izquierda de la línea izquierda de puntos son los 'enfoques' - JMS puros, ESB, EAI
2. los artículos a la a la derecha de la línea derecha de puntos son las implementaciones ''

Ahora, la parte grandes - CONSULTAS:

1. Independientemente de la solución (JMS puros, ESB, EAI), no la parte debajo de la línea de puntos (colas específicos de la aplicación) horizontales necesita a ser implementado?
2. ¿Cómo funciona el uso de ESB (JBoss ESB, etc.), en lugar de JMS "puro" (Active MQ, etc.), ayuda/ ? ¿Ofrece ESB alguna ventaja sobre JMS que es 'solo java' (?). Estoy confundido - 'ESB o JMS', incluso después de referirme a hilos como estos: JMS and ESB - how they are related?. Tiene una respuesta que dice "JMS no es muy adecuado para la integración de servicios REST, sistemas de archivos, S/FTP, correo electrónico, Hessian, SOAP, etc. que son mejor manejados con un ESB que admite estos tipos de forma nativa. Por ejemplo, si tiene un proceso que vuelca un archivo CSV de 500MB a medianoche y desea que otro sistema recoja el archivo, parsee CSV e importe en una base de datos, esto puede lograrse fácilmente mediante un ESB - mientras que solución con solo JMS será mala. Del mismo modo, la integración de los servicios REST, con equilibrio de carga/ conmutación por error a múltiples instancias backend se puede hacer mejor con un ESB compatible con HTTP/S de forma nativa. "¡¡¡Solo aumentó mi confusión !!!
3. ¿Es el uso de EAI framework (Apache Camel etc.) un enfoque completamente diferente del enfoque puro JMS o ESB? En caso afirmativo, ¿cómo y cuáles son los pros/contras?
4. Me dijeron que ESB solo no ayudaría, BPM (¿o algo más?) Necesita ser usado para definir y almacenar la lógica de "enrutamiento" - ¿es esto cierto?

Answer 1

Veo el punto. Esto podría ser un poco complicado con JMS "puro".

Lo que esencialmente quieres hacer es dejar que el portal publique mensajes a un tema, pero no dejes que los PAYROLLAPP se suscriban a ese tema (ya que todos obtendrían una copia del mensaje). Entonces, lo que necesitaría es una lógica intermedia que distribuya el mensaje de la suscripción del tema a una cola por tipo de aplicación. Desde esa cola, la carga normal balanceada (el patrón del consumidor competidor) se puede implementar con JMS.

Diferentes proveedores de JMS tienen implementaciones especiales que pueden realizar esta tarea ActiveMQ has its Virtual Destinations, WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue. En el caso de que su proveedor de JMS no tenga ninguna forma de manejar esto, le recomendamos que agregue algún middleware de enrutamiento a su topología. Apache Camel es agradable, liviano, pero hay muchos otros que pueden configurar algunas rutas en el medio sin afectar las aplicaciones reales.

Actualización para preguntas detalladas

1. las colas por debajo de la línea tiene que estar allí seguro (si las aplicaciones de mensajería utiliza). La casilla "Some distrib. Logic" no debería ser necesaria. La casilla "Algunos enrutadores lógicos" podría ser un ESB o, en este caso, implementarse en el servidor de mensajería, por ejemplo ActiveMQ con destinos virtuales (o WebSphere MQ o tal vez RabbitMQ entre otros).

2. Hay muchas palabras en el dominio de la integración. Simplificado (dependiendo de a quién le preguntes, ESB también se puede ver como un patrón arquitectónico, pero vamos a mantenerlo simple), un ESB es una aplicación de servidor (o una topología de varios servidores en práctica) que es una pieza central de un paisaje de integración. El servidor ESB simplemente contiene flujos lógicos y de mensajes pequeños que toman mensajes (archivos o lo que sea) de una aplicación y los enruta a muchas aplicaciones, los transforma en otros formatos, encripta, convierte desde un protocolo de transporte como HTTP/SOAP a archivo, etc.

JMS es una palabra bastante confusa y errónea. Hasta cierto punto, Java ha dominado el dominio de mensajería empresarial en los últimos años, por lo que JMS algunas veces se usa casi como sinónimo de Mensajería. Sin embargo, la mensajería (o la cola de mensajes, la mensajería asincrónica, el middleware MOM = orientado a mensajes, etc.) se debe considerar simplemente como una familia de protocolos de transporte similares que cuenta con un servidor de retransmisión central. No es para nada una cosa de Java. Muchos ESBS exitosas configuraciones con las que trabajé realmente aprovechar en una red troncal de mensajería

1. En su situación, yo no iría demasiado profundo en las diferencias filosóficas entre académicos/ESB y el software EAI. Lo más probable es que hagan las mismas cosas por ti. En su lugar, observe los hechos concretos, como el precio, el soporte, la huella de recursos, el monitoreo y la tecnología. características, curva de aprendizaje, etc. Sea Camel/ServiceMix, Mule, JBoss ESB, Microsoft BizTalk, IBM Message Broker, Tibco, etc.

2. ¡Hah! ¿Fue quizás un vendedor? Un ESB funcionará bien. Un servidor de mensajería también lo hará en su caso, como ActiveMQ como ya se señaló. Los juegos de BPM están bien para orquestar procesos de negocios semiautomatizados o si existe una lógica comercial importante en la capa de integración. De lo contrario, evite esa complejidad añadida.

Answer 2

1. Independientemente de la solución (JMS puros, ESB, EAI), ¿la parte debajo de la línea de puntos horizontal (colas de aplicación específica) necesita ser implementado?

Los consumidores deben implementarse de tal manera que trabaja con usted elegido la solución, pero que no debería tener que preocuparse por la creación de la cola por consumidor o la lógica de distribución (suponiendo que los consumidores pueden consumir directamente de la tecnología elegida)

1. ¿de qué manera el uso de ESB (JBoss ESB, etc.), en lugar de JMS 'puros' (Active MQ, etc.), ayudan/obstaculizar? ¿Ofrece ESB alguna ventaja sobre JMS que es 'solo java' (?). Estoy confundido, 'ESB o JMS', incluso después de referirme a hilos como estos: JMS y ESB, ¿cómo se relacionan? Tiene una respuesta que dice: "JMS no es muy adecuado para la integración de servicios REST, sistemas de archivos, S/FTP, correo electrónico, Hessian, SOAP, etc. que se manejan mejor con un ESB que admite estos tipos de forma nativa. Por ejemplo, si tiene un proceso que descarga un archivo CSV de 500 MB a medianoche y desea que otro sistema recoja el archivo, analice CSV e importe en una base de datos, esto puede lograrse fácilmente mediante un ESB, mientras que una solución con solo JMS será malo. De manera similar, la integración de los servicios REST, con balanceo de carga/conmutación por error a múltiples instancias de backend, se puede hacer mejor con un ESB que soporte HTTP/S nativamente. "¡¡¡¡¡¡¡¡¡¡¡AUMENTÓ MI CONFUSIÓN !!!

Mi opinión es que ESB podría complicar esta solución. Está diseñado (entre otras cosas) para ayudar a la integración con diferentes tecnologías, pero las soluciones más simples también lo hacen, por ejemplo, Apache Camel proporciona una forma muy fácil de comunicarse utilizando una gran variedad de transportes (incluido ActiveMQ).

No todas las implementaciones de JMS dan cabida a la conectividad de otros idiomas, pero ActiveMQ sí lo hace con su conector STOMP.

1. es el uso de un marco de EAI (Apache Camel etc.) un enfoque totalmente diferente de las JMS puros o enfoque ESB? En caso afirmativo, ¿cómo y cuáles son los pros/contras?

Apache Camel y JMS son tecnologías complementarias, como lo son JMS y ESB. Camel (& Spring Integration) es liviano, simple y portátil. Los ESB son mucho más pesados ​​y normalmente conducirán a un mayor acoplamiento con el ESB/servidor de aplicaciones.

1. me dijeron que por sí sola no ayudará a ESB, BPM (? O alguna otra cosa) tiene que ser utilizado para definir y almacenar la lógica ‘enrutamiento’ - ¿es esto cierto?

depende de lo que tu lógica 'enrutamiento' es, que me parece que no requieren lógica de enrutamiento, sólo requieren la entrega garantizada a 1payroll del consumidor y 1 asistencia al consumidor. BPM sería más útil cuando desee seleccionar selectivamente datos públicos/invocar un servicio en función de alguna característica de esos datos.

sugiero encarecidamente la lectura de http://activemq.apache.org/virtual-destinations.html, el uso de éstos usted:

1. enviar mensajes al agente ActiveMQ, en un VirtualTopic, por ejemplo, VirtualTopic.X
2. Registre los consumidores de Nómina y Mesa de ayuda, como consumidores en las colas que ActiveMQ crea dinámicamente sobre el tema, p. Consumer.Payroll.VirtualTopic.X. Ambos consumidores de nómina deben registrarse con la misma cadena.
3. ActiveMQ retendrá automáticamente un marcador que representa lo que cada grupo de consumidores no ha consumido. Esto significa que el 100% de los mensajes serán procesados ​​por un consumidor de nómina, pero nunca se enviará un mensaje a> 1 consumidor de nómina.
4. Agregar/eliminar consumidores a voluntad.

N.B.Creo que otros productos, p. Apache QPID proporciona una funcionalidad similar: estoy más al tanto de ActiveMQ y he tenido éxito con este enfoque