In creating a simple message bus, what is a recommended architecture?

Question

I am about to start a project that will serve as a simple message bus. Messages or events will be sent to it just waiting for a subscriber. The messages don't have to be stored, as I just want this as a pass-through for any subscribers for live data. The preferred delivery mechanism is a web request - REST/JSON.

In my recent work with Redis, I thought of this as a good candidate, but since we are predominantly a Microsoft shop am also thinking of WCF Service and Windows Service Bus.

Subscribers may not all be .Net clients, so I would like to keep that as versatile as possible, however out of the gate, .Net client connectivity will be first.

I would like to create the simplest implementation possible - no huge development time, as I want to spend most of that on the subscribers.

Suggestions welcome.

Answer 1

If you want to use Redis, take a look at Redis's publish / subscribe commands.

I'm not a .net person, but it looks like this link might steer you in the right direction: https://github.com/ServiceStack/ServiceStack.Redis/wiki/RedisPubSub

Answer 2

Windows Azure Service Bus supports both messaging and eventing patterns. If you just want to connect service across network boundaries the you can use Relay, but in your case you want different types of clients to communicate with different protocols so messaging may be more appropriate. You can en-queue de-queue messages using any protocol/programing model -> .NET API, WCF Bindings and simple REST clients. From a pattern perspective you can use Queues or Topics and Subscriptions depending if you need a single request/response channel or broadcast etc. The following code samples demonstrate using WCF programing model.

http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-WCF-ed259f73

http://code.msdn.microsoft.com/windowsazure/Windows-Azure-Inter-Role-9935c439

For a REST client the following sample would help: http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-569cff88

More information on Queue/Topics is at: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-queues/ http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-topics/

The REST API reference is available here: http://msdn.microsoft.com/en-us/library/windowsazure/hh780717

Answer 3

We've written a peer-to-peer message bus, Zebus, based on ZeroMq (transport), Cassandra (peer discovery and persistence) and Protobuf (serialisation).

It uses a directory/mesh topology which means that there is no single point of failure and no single bottleneck. This is hugely beneficial when scaling out.

You can read more about it's architecture here: https://github.com/Abc-Arbitrage/Zebus