language agnostic - ¿Por qué usarías un sistema basado en mensajes?

language-agnostic messages (6)

El sistema orientado a mensajes generalmente es bueno para ciertas clases de problemas de integración. Otras alternativas son tener un almacén de datos compartido (tal vez un archivo o base de datos) para que las aplicaciones se comuniquen o aplicaciones que se integren a través de RPC.

Las ventajas de enviar mensajes sobre estos patrones de integración son que no está acoplando ambas aplicaciones al mismo esquema de almacenamiento de datos y no está vinculando las aplicaciones a un escenario de integración RPC punto a punto (que se vuelve más complejo cuanto más aplicaciones están involucradas).

También existen los beneficios de la comunicación asincrónica (como el correo electrónico frente al chat en línea) y las posibilidades de enrutamiento y transformación de mensajes.

¿Cuáles son las motivaciones para usar un sistema basado en mensajes?

Estoy viendo mucho sobre los autobuses de servicio como NServiceBus y Mass Transit y me pregunto cuáles son los beneficios de la metodología subyacente.

Ayudé a desarrollar uno para un sistema que usaba C # y Remoting, el cliente (un servicio o GUI) podía enviar un mensaje completo con algunos datos personalizados y los destinatarios lo recibirían, ya sea la próxima vez que se conectaran o al instante). A continuación, podrían procesar el mensaje (al tomar posesión de él en el caso de los servicios de equilibrio de carga). También se usó para actualizar las GUI cuando los procesos de larga ejecución habían terminado.

El sistema de mensajería en sí tenía canalizaciones configurables que procesaban cada mensaje, aquí hay algunos ejemplos de algunas de las canalizaciones que desarrollamos:

Almacenamiento (creó / guardó el mensaje en la base de datos)
Enrutamiento (resuelto donde el mensaje debe ser enviado)
Seguridad (resuelta si el cliente pudo recibirla)
Eliminar (funciona si el mensaje necesita ser eliminado del sistema, lo que significa que los clientes deben ser notificados y el mensaje eliminado de su caché y marcado en el DB).
TakeOwnership (se ocupa de asegurarse de que solo un cliente pueda modificar el estado de un mensaje a la vez, ya que solo se pueden cambiar los mensajes que son de su propiedad)

Entonces, en respuesta a su pregunta, los sistemas de mensajería son un medio brillante de enviar información sobre cuándo no conoce o le importa quién es el cliente.

Un caso de uso es cuando tiene un grupo de recursos que puede trabajar en un elemento determinado y una lista de trabajo que debe distribuirse de manera escalable.

Una vez tuve un proyecto en el que tuve que hacer integración de mainframe con un número de raspadores de pantalla 3270 (todos lentos). Podría tener como máximo 10 de estos procesos abiertos en una caja a la vez. Tenía miles de cuentas para raspar y actualizar la pantalla, así que puse el trabajo en una cola, y mis máquinas (tenía alrededor de 3 de em) simplemente recogían elementos de trabajo de la cola de mensajes (MSMQ) y realizaban su raspado de pantalla, y eso fue todo. Podía fácilmente hacer girar una máquina nueva o desactivar las antiguas sin interrumpir el flujo de trabajo, así que fue agradable.

Una arquitectura basada en mensajes desvincula a los productores y consumidores de mensajes, tanto en tiempo como en espacio. Esto tiene muchos beneficios:

productores y consumidores pueden funcionar en diferentes máquinas
productores y consumidores pueden funcionar en diferentes momentos.
los productores y consumidores pueden ejecutar en diferentes plataformas de hardware / software (solo necesitan entender el mismo protocolo de mensaje)
es fácil coordinar múltiples productores / consumidores (por ejemplo, para trabajos de cálculo intensivo que necesitan múltiples máquinas, como Dave Markle ha descrito)
una mayor estabilidad cuando los servicios no se pueden mantener temporalmente (por ejemplo, cuando se procesa un pedido, el uso de un sistema de mensajería puede ayudar a evitar el abandono de los pedidos)

Usted pierde la mayoría de estos beneficios cuando realiza una comunicación al estilo RPC (es decir, cuando bloquea mientras espera las respuestas del servicio)

los beneficios se reducen a desacoplar las partes de su aplicación. Una vez que haya configurado el bus y se hayan agregado las aplicaciones, puede ampliar fácilmente su aplicación agregando nuevas piezas que puede garantizar que no afectarán a las otras partes. Es una muy buena forma de agregar continuamente un sistema a lo largo del tiempo.

p.ej. tenemos un sistema como este, cada comando se implementa como una parte de la GUI general, si queremos agregar una nueva característica o modificar una existente, simplemente escribimos una nueva y la agregamos al sistema. Cuando se llama, no tiene dependencias del resto. Significa que podemos extender nuestra aplicación muy fácilmente. Además, tenemos un mensaje que pasa entre los nodos de nuestra red: cuando se cambia algo en una computadora, se envía un mensaje a todos los demás para que puedan actualizarse. Tenemos cientos de mensajes diferentes para diferentes eventos, por lo que podemos extender el sistema al eliminar un nuevo servicio que reacciona a los mensajes apropiados.

Las arquitecturas de paso de mensajes generalmente tienen las mismas características que los servicios web, usted tiene servicios discretos a los que puede llamar, puede agregar nuevos fácilmente.

No creo que las arquitecturas de paso de mensajes requieran productos de middleware extravagantes (¡y caros!), Windows se ejecuta en una arquitectura de paso de mensajes: cada mensaje WM_ * pasado a una ventana es ... bueno, un mensaje, y creo que muestra el mejor ejemplo de arquitectura: ninguna parte de un sistema necesita saber acerca de ninguna otra parte, puede ampliarla infinitamente, ya que puede manejar tantos controles como desee en cualquier diálogo, etc., etc.

La transmisión de mensajes es una arquitectura fabulosa, aunque puede ser más lenta que la aplicación de su aplicación, no es una buena razón para no utilizarla hoy en día, especialmente si ya está usando scripting o aplicaciones .net.

El uso de sistemas basados en mensajes presenta múltiples ventajas.

Los mensajes forman una interfaz tecnológica bien definida entre las aplicaciones.
Permite un acoplamiento flexible de las aplicaciones.
Muchas opciones de rendimiento, ajuste y escalado:
- Implementar el proceso de solicitud y servicio en hardware diferente
- Varios solicitantes que comparten un solo servidor
- Varios solicitantes que comparten varios servidores
Los diversos middlewares de mensajería implementan los patrones de mensajería comunes independientemente de su aplicación.
- Solicitud / respuesta
- Incendio y olvídate de las actualizaciones sin conexión
- Publicar / Suscribir
Muchos de los productos de middleware manejan la transformación de mensajes (por ejemplo, SWIFT a SWIFTXML).
Muchos de los productos de middleware pueden descomponer una sola solicitud grande en varias solicitudes más pequeñas.
Casi todos admiten plataformas múltiples.

A propósito, los dos líderes del mercado en esta área son IBM con su Websphere MQ y productos relacionados, y TIBCO con Enterprise Service Bus.