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?

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.