Estamos tratando de encontrar una solución elegante para reportar excepciones generadas a partir de sistemas en toda nuestra infraestructura que sean más fáciles de operar que ver correo electrónico o verificar archivos de registro. El modelo de publicación/suscripción a través de un bus de servicio resolvería este problema bastante bien. Los servicios publicarían errores/eventos y una suscripción subsiguiente podría filtrar estos mensajes mediante la coincidencia de patrones simples.NServiceBus Publish/Subscribe
Hemos estado investigando el proyecto NServiceBus y se preguntó si sería lograr nuestros requerimientos, mirando a la muestra PubSub (http://docs.particular.net/samples/pubsub/) nos dimos cuenta que no resolvió los siguientes dos escenarios:
- Todos los editores publican la mismo tipo de mensaje
- el suscriptor no debería requerir el conocimiento de los puntos finales editor
hemos logrado alcanzar estos requisitos, pero estamos seguros de si la configuración es cor rect. Los siguientes son nuestras soluciones:
Todos los editores comparten la misma configuración de almacenamiento de suscripción (DBSubscriptionStorage), que es una base de datos compartida como se describe en la sección de suscripción de almacenamiento de la documentación http://docs.particular.net/nservicebus/messaging/publish-subscribe/
Todos los editoriales/suscriptores están configurados para usar un distribuidor como se describe en la documentación en el sitio web nservicebus.
Nos gustaría saber si esta es la aplicación correcta de la NServiceBus publicación/suscripción modelo, o si puede haber otra solución que acheive nuestros objetivos?
Gracias por su respuesta, ¿cuál es la diferencia subyacente entre IBus.Publish e IBus.Send? – Matt
Ignorando nuestro escenario de error por un minuto, tal vez consideremos un sistema de procesamiento de pedidos, donde un grupo de servicios está publicando notificaciones de pedidos que han procesado. Si íbamos a publicar el mismo mensaje de notificación de pedido de varios editores a múltiples suscriptores, sería la implementación correcta compartir el almacenamiento de la suscripción. Cuando los suscriptores se suscriben a nuestro mensaje, las suscripciones se agregan al almacenamiento compartido y todos los editores de ese mensaje en particular comienzan a publicarlo en nuestros suscriptores. Esto parece funcionar, pero ¿es correcto? – Matt
Matt: creo que está combinando la idea de múltiples nodos de publicación * físicos * con múltiples servicios de publicación * logical *.NServiceBus impone un solo servicio de publicación lógica pero, en ese servicio, permite tantos nodos físicos como desee (se establece automáticamente en el perfil de producción, haga esto manualmente, usaría DbSubscriptionStorage). Además, IBus.Publish se usa para comunicar eventos que * ya * pasaron, mientras que Send se utiliza para solicitar algo que queremos que suceda (pero puede ser rechazado). Los eventos no pueden ser rechazados (como ya ocurrieron). –