2

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.

Community
  • 1
  • 1
ElHaix
  • 12,846
  • 27
  • 115
  • 203

3 Answers3

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

Tyson
  • 6,214
  • 3
  • 32
  • 37
  • Yeah that's the direction I am leaning toward. Would adding a WCF service in front if this (using BookSleeve) simplify the connectivity process or does Redis offer some RESTful connection options? – ElHaix Jan 19 '13 at 16:30
  • Servicestack would provide your RESTFul connections - that's what it does. – MikeT Mar 10 '13 at 20:31
0

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

Abhishek Lal
  • 3,233
  • 1
  • 17
  • 16
  • Those are good suggestions, however what I forgot to mention was that I am limited to SQL Server 2005, as the client has no near-future plans on upgrading their DBMS. Thus, using a WCF client to broker communications to/from a Redis pub/sub scenario may be better. Thoughts? – ElHaix Jan 21 '13 at 16:19
0

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

Slugart
  • 4,535
  • 24
  • 32