RFID Service Bus

Our main goal in this context was to build the infrastructure on the top of standardized technologies around WS-*, which gives us ability to easy build workflow driven RFID applications between heterogeneous systems.

I’m proud to announce that we are done. DAENET has implemented the Service Bus based on .NET 3.0 and WCF, which is smoothly integrated in Visual Studio 2008 and BizTalk RFID. Previously we called it RFID SErvice Bus. Because we focus idea of exposing of devices as services, we will use the name "Sensor Service Bus".

This post briefly describes the solution which has been presented at Nov.2007 in Redmond (Seattle) at the SOA and Business Process conference and in Barcelona at the TechEd.

Before we dig deeper in the idea behind Service Bus, the scenario at the picture below should be considered.

 

Assume there is a WCF client called TagEventProducer and a WCF service called TagEventConsumer. Usually, in a typical Web Service scenario the client is in the role of consumer and the service in the role of provider. Because we focus on RFID, the scenario is about to publish tag-read-events (event fired when one tag has been scanned) and to consume them. In this specific case the client  (producer) should send one-way messages to the service (consumer), which will consume all of them and perform some operation.

In the system where participants (consumer and provider) are connected directly to each other (P2P), both require semantically the same binding. For example, both could use wsHttpBinding for communication.

However, different systems will usually require different bindings. For example, the provider could use wsHttpBinding with Kerberos security, and the consumer could require the same binding, but with certificate based security. Moreover, imagine there is a requirement which specifies that more than one application should receive the event. In the reality it is to expect that such kinds of scenarios are common and we need to provide the architecture and system which target that problem.
The architecture of RFID Service Bus is in theory based on service bus described in this post (it is highly recommended to read this first).

Based on the Service Bus described in the post above, following service (consumer) can be implemented:

By definition, participants who implements this interface constitute the RFID Service Bus. Each participant is connected through RFID ServiceBus binding, which is consisted of two bindings. First one is the custom binding based on scheme “dsb://” which catches all messages before they are sent to the service-consumer and sends them instead to the service bus service. The second binding specifies how to communicate with the service bus itself.
That means that the service bus receives message (m2) which contains originally sent message (m1). The message m1 corresponds to contract IRfidServiceBus and message m2 corresponds to contract IBusService (see this post). This is illustrated on following picture.

 

Last but not least, one producer can be hosted within BizTalk RFID EventHandler. In this case each tag-read-event is immediately published to RFID Service Bus, because the EventHandler acts as producer for Service Bus. Next picture show the architecture of this solution: