Confusión sobre los patrones de Bus de Mensajes / Despachador de Comandos
Recientemente he estado leyendo mucho sobre la mensajería distribuida y los patrones asociados. Usé algunas de ellas soportadas por las herramientas como for exemple NServiceBus.
Muchos de esos patrones se describen en Internet. Algunos de ellos que leí recientemente fue :
- Agente de mensajes: http://msdn.microsoft.com/en-us/library/ff648849.aspx
- Bus de mensajes: http://msdn.microsoft.com/en-us/library/ms978583.aspx
- Patrones de mensajería en SOA: http://msdn.microsoft.com/en-us/library/aa480027.aspx
- El post de Udi Dahan sobre las diferencias: http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences /
Si el uso de herramientas como el bus NService permite hacer mucho sin pensar mucho en problemas de infraestructura, algunas preguntas han surgido cuando intenté implementar un Bus de mensajes básico y un controlador de comandos. De hecho, cuando se trata de estos patrones no puedo ver muchas diferencias entre ellos.
No voy a pegar código porque es demasiado largo, pero encontré dos entradas de blog que describen bastante la idea de implementación de la que me gustaría hablar.
- Bus de mensajes: http://brentedwards.net/2010/04/13/roll-your-own-simple-message-bus-event-aggregator /
La idea es simple, el bus de mensajes rastrea a los suscriptores y envía los mensajes a diferentes suscriptores si están interesados.
- Controlador de comandos : http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx
Es bastante similar al bus de mensajes. El bus de comandos invoca los controladores de comandos para un tipo de comando dado.
Así que en ambos casos hay similitudes.
Cuáles son las diferencias y beneficios reales usando un patrón que otro (no estoy hablando de herramientas de apoyo). ¿Qué me estoy perdiendo ?
La segunda pregunta es. ¿El bus de mensajes es valioso sin las herramientas de soporte ? No me veo a mí mismo para impulsar el apoyo para todos los tenents por mi cuenta.
Lamento una pregunta larga y confusa, pero no dude en pedir más detalles.
2 answers
Woah, va a ser difícil dar una respuesta más completa o más creíble que el MSDN que ha vinculado, así que vamos para más conciso.
Un Bus de mensajes se refiere a la comunicación. Ni siquiera requiere que la comunicación sea entregada sea una orden o no. Tampoco le importa cuál es la carga útil. Es "agnóstico tipo". La principal preocupación del bus de mensajes es simplemente hacer un seguimiento de quién debe obtener cada pieza de comunicación (pub/sub). Un beneficio de este modelo es que será compatible con la expansión futura que aún no tiene las especificaciones para. Puede agregar un nuevo tipo de mensaje en el futuro y este modelo estará encantado de entregarlo. Es más probable que un bus de mensajes se distribuya fuera de su aplicación e incluso fuera de su máquina (por ejemplo, distribuido entre un clúster de 10 servidores).
Un modelo de manejador de comandos se ocupa de separar las acciones de la ejecución de un comando. Tradicionalmente (al menos en los idiomas que uso) comandos estaban muy estrechamente asociados con los controles de la interfaz de usuario y sus eventos y el subproceso de la interfaz de usuario. Con este viejo modelo, también era difícil personalizar o ampliar el rango de comandos disponibles en su aplicación (por ejemplo, con una extensión DLL). El modelo de controlador de comandos separa las preocupaciones de la IU y la ejecución de comandos. Ahora tiene la flexibilidad para agregar fácilmente más manejadores de comandos y ejecutar comandos sin un evento de interfaz de usuario (Unit test-able). Esto hace que sea más limpio, más modular y comprobable codificar. Es más probable que el controlador de comandos sea parte de su aplicación internamente. Es probable que cualquier extensión de su colección de comandos tenga la intención de afectar a una aplicación y no a varias aplicaciones.
Un Agente de Mensajes/Comandos se ocupa de conectar sistemas independientes incompatibles o de diseño diferente. Este es el caso de uso en el que desea que una aplicación interactúe con otra y no tenga el código fuente de una o ambas aplicaciones. Así que usted crea un corredor que recibe información de un lado y proporciona esta información del otro lado teniendo en cuenta las transformaciones necesarias para que estas dos aplicaciones se comuniquen. El ejemplo en MSDN es un sitio web de comercio electrónico que podría necesitar hablar con un procesador de pagos, una compañía de envío y un sistema de contabilidad. Es posible que no tenga la capacidad de cambiar el código fuente de ninguna de estas aplicaciones (incluido el sistema de comercio electrónico). Tal vez el sistema de comercio electrónico requiere una interfaz IExamplePaymentGateway y su el proveedor de pagos requiere una interfaz IDifferentPaymentAPI. Tal vez una API se implementa en XML y el otro en JSON? Sean cuales sean las diferencias, su corredor es responsable de hacer posible la conexión.
Como puedes ver, todas implican comunicarse de una manera u otra. Las líneas entre ellos pueden ser borrosas e incluso puede usar una combinación de varios de estos patrones para lograr su caso de uso particular.
Aunque nunca he usado NServiceBus, la mayoría de estos tipos de las bibliotecas simplemente tratan de envolver los modelos abstractos/académicos en implementaciones específicas de lenguaje más concretas. A veces esto le ahorra tiempo, a veces se queda atascado con una implementación deficiente de un colaborador de código abierto desconocido. Tendrá que evaluar su propio caso de uso y la idoneidad de las herramientas disponibles en su idioma de desarrollo preferido.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-12-08 16:54:27
Generalmente, un bus de mensajes (o un despachador de eventos estándar) puede tener muchos suscriptores para diferentes tipos de mensajes / eventos.
Un bus de comandos normalmente envía comandos a exactamente 1 controlador, similar a un enrutador que resuelve rutas a controladores.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-07-18 09:42:18