views:

440

answers:

2

We are trying to find an elegant solution for reporting exceptions generated from systems across our infrastructure that's easier to operate on than viewing e-mail or checking log files. The publish/subscribe model across a service bus, would solve this problem quite neatly. Services would publish errors/events and a subsriber could filter these messages using simple pattern matching.

We've been investigating the NServiceBus project and wondered whether it would achieve our requirements, looking at the PubSub sample (NServiceBus.2.0.0.1145\samples\PubSub) we noticed it did not solve the following two scenarios:

  1. All publishers publish the same message type
  2. The subscriber should not require knowledge of publisher endpoints

We have managed to achieve these requirements, but we're unsure whether the configuration is correct. The following are our solutions:

  1. All publishers share the same subscription storage configuration (DBSubscriptionStorage), which is a shared database as described in the Subscription Storage section of the documentation http://www.nservicebus.com/PubSubApiAndConfiguration.aspx

  2. All publishers/subscribers are configured to use a distributor as described in the documentation on the nservicebus website.

We would like to know whether this is the correct implementation of the NServiceBus publish/subscribe model, or whether there might be another solution that would acheive our goals?

+2  A: 

This has been discussed on the discussion group here:

http://nservicebus.grouply.com/message/7059

In short, you would have each node send rather than publish to a single endpoint.

Hope that helps.

Udi Dahan
Thank you for your response, what is the underlying difference between IBus.Publish and IBus.Send?
Matt
Ignoring our error scenario for a minute, maybe consider an order processing system, where a group of services are publishing notifications of orders they have processed. If we were going to publish the same order notification message from multiple publishers to multiple subscribers, would sharing subscription storage be the correct implementation. As subscribers subscribe for our message the subscriptions are added to the shared storage and all publishers of that particular message begin publishing to our subscribers. This appears to work, but is it correct?
Matt
Matt - I think you're combining the idea of multiple *physical* publishing nodes with multiple *logical* publishing services. NServiceBus enforces a single logical publishing service but, in that service, allows for as many physical nodes as you want (set automatically in the production profile, do this manually you'd use the DbSubscriptionStorage).Also, IBus.Publish is used to communicate events that have *already* happened, whereas Send is used to request something we want to happen (but may be rejected). Events can't be rejected (as they already occurred).
Udi Dahan
A: 

You could write messages to the windows event log and use a tool like OpManger to monitor for errors / warnings in the logs.

Added benefits are OpManager can monitor processes, network ports so you can detect other failures. It also supports email alerts and has a nice WebUI.

Charlie.Barker