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.

Assumptions

In this paper I assume that the reader has the following:

• A basic understanding of the BizTalk RFID feature and knows how to setup a BizTalk RFID process through the RFID Manager
• A basic understanding of NServiceBus and how it is used

Author

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:

LinkedIn: http://www.linkedin.com/in/michaelstephensonuk1

MVP Profile: https://mvp.support.microsoft.com/profile=0FCB8BD0-E550-4E33-B0A8-084772434FC9

Reviews

Thanks to the following people for reviewing the content in this paper.

Introduction

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 device plugins are similar to adapters
• The logical devices is similar to a receive port
• The RFID process is similar to a pipeline
• The RFID process contains a series of components which are similar to a set of pipeline components, There are some pre-build RFID components equivalent to the out of the box pipeline components, You can also develop your own RFID process component similar to custom BizTalk pipeline component.
• You can import and export RFID configuration to and from XML like you would a binding file.

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.

The Scenario

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

The publisher component is really where the application integration starts. BizTalk 2010 RFID comes with some out of the box publisher components such as:

• SQL Event Publisher which writes the event to a database
• Event Forwarded which will publish the event to a MSMQ-Activated WCF service

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.

Design Choices

As a positioning statement I think the NServiceBus publisher is really aimed at situations with the following requirements:

• You want to have dynamic subscriptions where application subscribers can control what events they receive rather than this being brokered
• You have a high volume of events but there would be little complexity in processing the event (e.g. No orchestration just loading it into an application)
• You want asynchronous loading of the event into an application but with durability and reliability
• You want to allow .NET developers to create subscribers to process events
• BizTalk could become a subscriber to the messages coming out of NServiceBus using the techniques I described in the previous whitepaper.

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.

Demo Solution:

For the demo solution, we are going to build the following components

1. An NServiceBus RFID Publishing component
2. 2 sample subscription applications (referred to as subscriber A and subscriber B)
3. An MsTest Integration test project

The Solution Structure

To begin with we have a solution structure like shown in the below picture.

This structure contains projects with the following aims:

NServiceBus RFID Publisher Component

There are three important sections when building the RFID publisher component

1. The NServiceBus Message
2. The Publisher Component
3. Configuration of publisher component.

The NServiceBus Message

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.

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.

The NServiceBus Publisher Component

My component meets the basic requirements of implementing any custom RFID custom component in BizTalk:

• Create a class that inherits from RfidEventHandlerBase
• Implement an override of the Init method which will setup your component with information from the design time properties
• Implement the static method to allow the designer to get information about the required design time properties
• Implement a Tag read handler method

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.

Configuring the publisher

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.

Sample Subscriber Applications A and B

In my sample I have the following subscribers:

• Subscriber A is a console application
• Subscriber B is a console application
• Test subscriber is used within the integration test project

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.

The RFID view of the Process

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.

The Test

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 ProcessManagerProxy class.

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 application.

Conclusion

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.

Additional Resources

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.

• http://btsrfidnsb.codeplex.com/

See Also