The aim of this paper is to discuss the option of using NServiceBus to do multicast message distribution as part of a BizTalk RFID process.
In this paper I assume that the reader has the following:
Michael Stephenson is a UK based independent Integration consultant and a BizTalk MVP. To find out more about Michael please refer to the following links:
Thanks to the following people for reviewing the content in this paper.
Saravana Kumar is a UK based BizTalk MVP. Saravana is well known for his excellent work on a number of BizTalk community initiatives such as BizTalk 24/7.
As a follow up to my previous whitepaper about BizTalk and NServiceBus last year I wanted to talk about another situation where I feel BizTalk and NServiceBus complement each other very well however this time around the RFID feature in BizTalk.
For those of you familiar with the RFID feature you will be aware that it is a part of BizTalk that does not get as much press as most of the rest of the product, but in my opinion it’s quite a cool feature for anyone who works with RFID solutions. Particular
points to note are around the abstraction of the device hardware from the code to handle events from tag read. There are some similarities in the concepts for RFID development with BizTalk to the development with the core part of the BizTalk product, for example:
The below figure shows the relative comparison between BizTalk and RFID artifacts:
For those less familiar with BizTalk RFID the following diagram gives an overview of the RFID architecture.
The key thing I wanted to discuss in this paper is around the processing of your RFID event in the BizTalk RFID Process and this is really where the integration story kicks in. A normal RFID process would look something like the below:
In the process you may have a number of components which check if the event is something which you want to handle and publish (e.g.: Filtering and validation), then you come to the final stage which is the publishing component. This paper will focus on the
publishing part, explaining how RFID events can be published into NServiceBus.
Before going into the technical discussion let’s take a fictitious example scenario. Acme Distribution Ltd is a company who deal with warehousing and distribution. They have a large warehouse and are about to ship a container with 10000 widgets. As the container
is filled up with the widgets from the warehouse, the location information and the progress of the widgets will be tracked by various tag readers.
Each tag read is collected by the BizTalk RFID processing solution and will execute one or more BizTalk RFID processes.
As the event is processed it will be filtered and validated as shown in the diagram earlier in this paper and eventually the event will be send to two lines of business applications. Application A monitors stock processing and tracking through the warehouse
and Application B provides information for customers so they can see the progress of their orders.
The publisher component is really where the application integration starts. BizTalk 2010 RFID comes with some out of the box publisher components such as:
One of the common scenarios is to hook the RFID process into BizTalk via the MSMQ activated WCF services publishing functionality. Bringing messages into BizTalk opens up lot of integration opportunities offered by BizTalk, on the other hand the high volume
events generated by RFID tag readers could also cause lot of unnecessary traffic passing through the BizTalk message box resulting in resource contention. This is the point where I started to think about the option of using a custom RFID process component
which encapsulates the use of NServiceBus to take advantage of some of the features offered by NServiceBus.
As a positioning statement I think the NServiceBus publisher is really aimed at situations with the following requirements:
The below Diagram illustrates the architecture being used in the walk through.
For those familiar with NServiceBus you will recognize the normal publish/subscribe pattern in the diagram with the parties interest declared in the subscription database, the key difference here is that the publishing component has been embedded in the
RFID process so it can be managed like any other RFID process component. It will do the message publishing from within the RFID process execution.
For those of you who are familiar with BizTalk but not NServiceBus you will recognize the publish subscribe pattern. The difference in implementation is that the publisher component does not know until runtime where messages will be sent to. The publisher
checks the subscription storage (either a database or a queue) to work out where to send messages based on who has declared an interest. The key difference is that in BizTalk pub/sub is driven by the publisher of a message where as in NServiceBus the pub/sub
is driven by the consumer of a message.
For the demo solution, we are going to build the following components
To begin with we have a solution structure like shown in the below picture.
This structure contains projects with the following aims:
This project will contain the interfaces for use in this project. The IRfidMessage interface represents the data of a message from an RFID tag.
This contains the code for the publisher component.
This project is used to simulate a tag read and then subsequent messages
Subscriber A & Subscriber B
These are sample console applications to illustrate the dynamic subscription of NServiceBus
There are three important sections when building the RFID publisher component
One of the core parts to this solution is the NServiceBus message. This would be a shared contract which both the publisher and any subscriber components would be aware of. In this demo I have chosen to implement the message as an interface in C# as shown
Below you can see me implementation of the IRfidMessage interface in the publisher component where I have encapsulated the conversion of the RFID tag read event object into my RFID message.
In the subscriber components you may notice that I have not created concrete classes which implement the interface because NServiceBus will handle the construction of the object and I only need to deal with the fact that I will get an instance of the interface.
My component meets the basic requirements of implementing any custom RFID custom component in BizTalk:
As you can see in the below picture this code snippet has the core method required for the component to do its work. In this method I am accepting the RFIDTag Read and then creating my NServiceBus message from this. I have encapsulated the setup and configuration
of the IBus NServiceBus object which is used to interact with the NServiceBus subsystem in the ServiceBusSingleton class; you can see that I provide a simple generic publish method which will send my NServiceBus message out from this component.
In the below picture you can see the implementation of the Init method. This is where I am accepting the parameters dictionary from the administration component and configuring the component. Note this is where I am setting up the ServiceBusSingleton (my
encapsulation of NServiceBus IBus object).
In the below picture you can see the code from the GetEventHandlerMetaData method. This simply tells the Administration console how to configure the interface to collect the design time properties.
One of the more interesting NServiceBus aspects of this sample is the in code configuration of NServiceBus. Normally in most cases you would configure NServiceBus via the app.config file for your process. This configuration could be done with your RFID process
because it will be created as a WCF service deep down in its deployment model so there will be a configuration file which could be setup, but this does not really fit with the normal RFID process management processes.
With NServiceBus it is also possible to configure the IBus component in code and below you can see how I have configured the setup of the Configuration object to support setting up IBus in code.
In the below picture you can see the Configure method from the ServiceBusSingleton class where I have implemented a basic singleton type pattern around the configuration of the component. You can see that I control which assemblies NServiceBus will look
at to scan for messages and other NServiceBus setup such as how to serialize messages and what type of storage to use. Notice also the .CustomConfigurationSource usage where I pass details to my custom implementation of configuring part of this setup from
data provided by the RFID management console.
In my sample I have the following subscribers:
Each of these subscribers is intended to show how the dynamic publish subscribe scenario works. When they start up they will register the subscriptions for messages they are interested in on the shared subscriptions queue and then the publisher component
will start sending messages to their input queue. One of the great features about NServiceBus is that the subscriber process could stop but the publisher will still send messages to the queue for processing later.
In the below picture you can see I have put together a really simple message handler which will write information to the console.
While creating the RFID process through the RFID management console I could deploy my component to RFID. Note that I have chosen to deal with this as a private component so I don’t need to worry about signing and placing the assemblies in the GAC.
In the BizTalk RFID Manager I have now added my component in my RFID process. In the below diagram you can see how the RFID management console will display the design time properties of the component. An administrator would be able to control the properties
of the component and how it worked.
Once the component is deployed and the RFID process setup I can now start it.
I have created a simple test which will simulate an RFID tag read passing through the process, but before we get into that to simulate the publish subscribe pattern on the end of the process I will run the executable for both of the subscriber console applications
A and B. The below screen shot show both the subscribers are active and waiting for messages:
The next thing to do is run my test. In the below code snippet you can see the test where I have used the usual technique for testing RFID processes from .NET code where you can simulate the input of an RFID tag read using the
As mentioned earlier I have a message handler also in the test so once the message is sent to the RFID process three messages should come out (One to this test and one each to the console applications). In the test project when a message is received I simply
store and the test method will poll this storage as you can see above in the loop until a message is found.
When I run my test and it passes. I know that my test received a message coming of the RFID process and in the below picture you can see the output from both console applications where it has logged the details from the messages received by each subscriber
As you can see from the sample project within this paper, using NServiceBus with BizTalk RFID could be a very effective way to implement a publish/subscribe pattern for your RFID events.
The source code for the sample used in this article and a copy of this article in word format is available on the following CodePlex site.