Implementing your own Service Bus

The idea around Service Bus technology seems to become a hot topic soon. Because of this, I will describe in this post how one Service Bus can be build on the top of WCF. If you are familiar with WCF after you read this you should know how the Service Bus could be build. Because this topic is very sophisticated, please do not expect that this short post will help you to build your bus from the scratch. But, if you are very familiar with extending of WCF, this will for sure help you to build your own service bus. Anyhow, I will try to keep things as simple as possible.

Imagine you build the WCF based service which implements following contract:

interface IBusService
{
  void Send(string topic, Message msg);
  Message Receive(string topic);
}

The operation Send has argument which is a typical ServiceModel message. After the message is received it is immediately persisted in the database. On the other hand there should be some process which invoke the operation Receive() and waits that the message is retrieved. For the case of simplicity assume there is a thread in the service which reads all messages and just returns them. Following pseudo code illustrate the implementation of the service:

void Send(string topic, Message msg)
{
   WriteToDb(topic, msg);
}

Message Receive(string topic)
{
  ManualResetEvent.WaitOne();
  return Message PopMessage(topic);
}

The operation Receive is a blocking call (with high time-out value) which just wait that some message appears in the database. The string "topic" is for now just a logical description of the message exchange. Think about it as:

   select Message from TMessages where topic = @topic;

That means the WaitOne() blocks until one message appears in the table TMessage with the specified topic. This string (topic) allows some kind of virtual private channel between participants. Only participants who send/recive to the same topic can exchange messages. The idea is that multiple participants share the same bus, by sharing of the same topic.
The exact implementation of this is out of scope. As you see this service is very simple one. It just receives one message from one "requestor" and returns it back to some other. Following code snippets shows the pseudo implementation of two participants (two executables). The first one who invokes Send() is called producer and second one who waits on the message is called consumer.

void Main1()
{
  BusServiceClient proxy = new BusServiceCLient();
  proxy.Send(http://daenet.eu/vpnchannel,
  Message.CreateMessage(…));
}

void Main2()
{
  BusServiceClient proxy = new BusServiceCLient();
  Message msg = proxy.Receive(http://daenet.eu/vpnchannel);

  //do something with the message
  . . .
}

You believe or not, but this is theoretically all. The only thing you should do now is to take a care about dispatching of messages. This means you should integrate it in the Service Model layer. This is the moment when everything is getting more complicated J.

Imagine now there is a binding called ServiceBusBinding which by sending of messages invokes the method Main1 and by receiving method Main2(). In fact every binding at the end of stack sends the message or receive it. In this particular case this would work as shown above.

Next example shows how to create the client's proxy of some service (MyService) by using of such service bus binding, which is custom WCF channel.

ServiceBusBinding svcBusBinding =
new ServiceBusBinding("http://daenet.eu/vpnchannel");
MyServiceClient proxy =
new BusServiceCLient(svcBusBinding,
                     new EndpointAddress("dsb://someaddress"));

The binding is created by specifying of the topic to be used. The interesting is, that the remote address of the service has scheme "dsb". This can be any scheme, which binding support. In this case we use Daenet Service Bus scheme, which is the scheme of Daenet Service Bus, which can be purchased at DAENET (www.daenet.eu)

What happens exactly when some operation on this proxy is invoked? The message is routed internally to the channel implemented by Service Bus Binding. This channel would invoke the method Main1 (see example above), which invokes the Send() operation of the Service Bus. Depending on what shape the channel supports, the response can be differently covered. For example, if the message is oneway (channel can obtain this information) no response is expected. But if the channel implements RequestReply pattern the sending of the message would be implemented as combination of Method1 and Method2 as shown below:

void Main3()
{
  BusServiceClient proxy = new BusServiceCLient();
  proxy.Send(http://daenet.eu/vpnchannel,
  Message.CreateMessage(…));

  Message msg = proxy.Receive(http://daenet.eu/vpnchannel,
  Message.CreateMessage(…));

  //do something with the message
  . . .
}

Note that this code is pseudo code. As we see, the service bus is nothing else (in this case) than the usual and even very simple service. By using of custom channel messages can be routed to that service and received from it. This is exactly the way how all works.

Think about consumer (Main2), which makes outbound call to the service bus. That means that such calls are mostly not blocked by firewall. In other words, the message producer (Main1) is able to invoke the service which is behind firewall. But, this is not all. Imagine the ServiceBus webservice is exposed over multiple endpoints. That means participants could chose which endpoint to use.

Isn't that all a new paradigm? I'm sure that such technology offers huge number of completely new innovative scenarios.

Hope this helps to more understand the idea of Service Bus technology. Note that this is for sure not all about this topic. Just think about securityJ.