Subscriptions: Mass Transit vs. NServiceBus vs. Rhino ServiceBus
time to read 2 min | 263 words

For a pub / sub system, managing subscriptions could be classified as important. All three service buses has some notion, subscriptions are important. I find it interesting to trace the way that each of them is handling this scenario differently.

NServiceBus deal with this as a pluggable strategy. NServiceBus tend to do things that way :-)

The two options that come out of the box with it are database backed subscription storage or a queue backed subscription storage. Just to make things interesting, for queue backed subscription storage, you now have several deployment options at your hand (private subscription storage per endpoint, shared subscription queue, etc).

Mass Transit handle this by treating subscriptions as a service. Again, we have the option to chose between either a subscription storage based on distributed cache (memcached) or a local service running it. In both cases, we are talking about having a well known place to go looking for it.

I don't think that I like this very much, mainly because if you miss that, you get into some very strange situations. (Nothing works, and the first time that this happens, you don't know why).

For Rhino Service Bus, I choose to go with a private subscription storage. That is, each end point store its own subscription directly on the queue that it is using to accept messages. That means that I have only a single place to look for in order to understand how this endpoint is behaving. It also means that I literally have to do nothing in order to start getting messages flowing.

Tweet Share Share 10 comments
Tags: