Can an NServiceBus endpoint subscribe to multiple publishers of the same message?

Question

I am developing a system to support receipt of status information from a variety of hardware types. Each piece of hardware is reporting the same status information (Latitude, Longitude), but each hardware type uses a unique protocol for reporting this information. For this reason I have multiple services, one for each device type, that listen for and parse the protocol of that device. I would like for each of these services to publish the status information using a common message:

public interface IPositionMessage : IMessage
{
   string UnitName { get; set; }
   double Latitude { get; set; }
   double Longitude { get; set; }
}

I had no trouble setting up my first service, but now that I am setting up my second service I'm finding that my subscribers are unable to subscribe to the same message from multiple publishers.

In a similar question on the NServiceBus yahoo group, the recommended solution is to convert the common message to a command and use Bus.Send rather than Bus.Publish. I don't feel that makes sense in this scenario since what is really happening is an event (the unit has already arrived at a position and is reporting the new position). If I were to convert this to a command I would need to know in advance all of the potential subscribers to this event, which I don't. Another possible solution would be to create an aggregation/re-publisher that each service would Bus.Send to, and then the message would be republished from a single publisher. This seems like an unnecessary bottleneck.

Is there any method to allow for subscribers to subscribe to the same message from multiple publishers?

Tantalus

AFAIK, it's bad practice to publish from more than one LOGICAL publisher. – Banditry

In my view, each service is a physical node participating as part of one logical publisher. My scenario would be no different if I had one service implementation and I needed to scale to installing it on a second machine. – Tantalus

Answer 1

This is one of those SOA "pit of success" things that Udi tries to make it very hard for you to escape from.

The basic duality is this:

• Commands should be sent by many clients and received by a single authoritative source.
• Events should be published by a single authoritative source and received by many clients.

But this single authoritative source is a LOGICAL authoritative source. The important point is that if I am interested in all IPositionMessage data, there should be only one logical point (queuename@servername) where I send my subscription requests.

That doesn't mean that multiple physical processors within the same logical service can't all publish the same event type, as long as what they publish is authoritative.

The key is that all your physical processors must share the same subscription storage. In fact, you may want to have one physical endpoint handle only the subscription requests and do no processing at all. It just receives subscription requests (QueueX@ServerY is interested in IPositionMessage) and updates the subscription storage.

Then, each processor, tied to the same subscription storage, goes to publish IPositionMessage and will find that QueueX@ServerY is interested, and send a copy of the event to that location.

This will be a little bit hard to swallow in a dev environment with the NServiceBus.Lite profile running, because the subscription storage is in-memory by default, so obviously it will not be shared and will not appear to run correctly, so be ready for that.

Freytag

You've hit directly on my struggle, which is that I was hoping to find a way for each physical node to use an independent input queue (so that each protocol implementation could receive unique configuration commands) and at the same time have each of these nodes act as a physical node of a logical publisher (each node is the authoritative publisher of that event). I created a very simple "republisher" that handles the message to be published and publishes it for all subscribers. At first blush, it still feels like a hack, but I can see how this separates concerns and can still scale. – Tantalus

Is there an example of how to configure things this way? I am a bit confused as to how to go about this. – Garrick

Never mind:p Pretty straight forward. It just needs to be set up so that all relevant endpoints are looking at the same Raven DB database. I would assume that in the case of MSMQ storage it woul dneed to point to the same queue. – Garrick

Answer 2

While it's possible to subscribe to more than one publisher (this can be configured in the <unicastBusConifg />), I agree with the user group in that this should then become a logical send rather than a publish.

I don't quite know why I think this though.

Visser