BizTalk RFID’s primary mission is pretty straightforward: to make it easy to build RFID applications on the Microsoft Windows platform. In this chapter, we will explore what an RFID application looks like, and get started on the journey of understanding the mental model of a BizTalk RFID application. Once you have a grasp of this, we will look at the system architecture of BizTalk RFID and the BizTalk RFID device model. Next, different configurations and approaches to installing the application will be outlined.

The key objectives of this chapter are as follows:

• Understanding what a BizTalk RFID application is
• Understanding the process architecture and the BizTalk RFID device model
• Working through installation
• Understanding system architecture and configuration

The BizTalk RFID Process Architecture

As you saw in the previous chapter, the fundamental technology behind RFID is not really new. The technology has been around for a few decades, and has been used with success on several large-scale deployments in military and commercial contexts. Also, there is really no such thing as a single RFID technology. The moniker applies to a collection of protocols, frequencies, power levels, capabilities, form factors, and packaging. The commonality between them is really in the application of the technology—all of them are aimed at automatic object identification. Imagine if you could assign IP addresses to every object in the real world. From a hardware perspective, that is the fundamental promise of RFID. From a solution perspective, that is the just the beginning.

Let’s look at the entire analogy and wind back to 1993: imagine that all the computers in the world had network cards with IP addresses. Imagine that you could have a federated collection of servers that could assign names to these IP addresses to make them friendly. This is where we were at the start of the Internet revolution. If we had stopped there, it would have been a really interesting technology that made certain kinds of information sharing possible, but it would not have changed the world. What changed the world was the killer application for IP: the Internet in its full glory of the World Wide Web—ubiquitous, rich, copious, full of searchable content, employing completely new business models like eBay and Amazon, containing rich self-service and collaborative applications, enabling peer-to-peer social networking—the list goes on. And all of them had almost nothing to do with network cards and IP addresses, and everything to do with unlocking the value of the Internet through the power of software.

And that is the role of the RFID application: IP addresses for objects in the real world open the doors to a variety of possibilities, all of which have to be eventually realized in software. The applications for RFID are broad, varied, and rich. We have to confess, one of the amazing things about working on this project was the chance to work fairly closely with partners and customers worldwide, and learn from their descriptions of the scenarios firsthand. The list includes everything from asset tracking (cattle, baggage, people, railway wagons, aircraft components, defense equipment, hospital equipment, office stationery, library books, and fish, to name just a few), to access control, to conventional supply chain visibility, to work-in-progress visibility, to e-pedigree, and everything in between. Phew! RFID scenarios are truly applicable in the vast majority of domains and verticals, and the interest in RFID is truly global: usage of RFID spans manufactures from China; retailers in the United States, Europe, and India; logistics providers in the United States, Europe, Japan, Australia, and South America; and so on. Some analysts and industry experts have started calling this entire class of applications the “extended Internet,” or the “physical Internet,” which is an apt analogy given the broad promise of RFID applications.

That was the big picture, so to speak. With those scenarios in mind, let us now look at the little picture: as the architects, designers, and developers who have to build out the solutions at the end of the day, the devil (or the fun) is really in the details. What does an RFID application look like? It has the following key requirements:

• It must work well with the hardware layer of readers and tags. Given the diversity of RFID technologies, this is actually a significant task.
• It must be able to interpret the information stored on the tags and reported through the reader. Typically, for a variety of reasons, the information stored on the RFID tag is really an identification code (or a GUID in developer terms, or a license plate number in layman’s terms). It rarely has human-readable information directly stored on the tag itself. Understanding this machine-readable binary quantity is the first step to interacting with the physical entity. Note that if you really need the extra storage, certain types of tags (typically HF tags) offer the capability to store 64 Kb or more of data on the tag.
• It must be able to correlate this information with the rest of the contextual information associated with the entity to make real-world sense of the binary ID. Think of this as going from the code to a human-readable description, or from a license plate number to a “vehicle database information record.”
• It must be able to use the RFID information to enable better business decision-making for the company. Think of this as the way to leverage the RFID investment to impact the top and/or bottom line for the company. This is a crucial point in the relevance of the solution that you are developing and will typically involve integration with the back-end line-of-business (LOB) system, or the centralized business analytics infrastructure of your enterprise. RFID provides the real-time information stream, but that really needs to be complemented with real-time decision-making to truly utilize the benefits of deploying RFID.

BizTalk RFID addresses the needs of such applications with the following components:

• The Device Service Provider Interface (DSPI), a brand-new device abstraction framework that lets you interact with devices in a uniform, consistent fashion across a rich, diverse set of devices. This is similar to the Windows driver model, but enables a much richer device experience within the familiar .NET programming paradigm.
• A rich object model for retrieving tag information that includes support for the EPCglobal Class 1 Gen 2 protocol.
• A new event-oriented programming application model called the RFID business process. RFID business processes provide a declarative experience for authoring an event processing tree that can be deployed and hosted by BizTalk RFID.
• Connectivity components to integrate back into BizTalk Server, SQL Server, and LOB systems.

BizTalk RFID has a layered system architecture (see Figure 2-1). In this section, we will look at the various elements of the architecture, and how they relate to each other.

Figure 2-1. BizTalk RFID process architecture

The Physical Layer

This is the lowest layer of the system, and it represents the various entities in the physical world that you want to interact with. Typically, it includes RFID tags, bar codes, sensors, and so on. This layer of the system communicates directly with the device above, using RF waves and some over-the-air protocol, most commonly EPCglobal Class 1 Gen 2 these days.

The Device Layer

The next layer up is the device layer: readers, printers, bar code scanners, sensor processors, and everything in between. This layer performs two key tasks: communicating with the physical layer below using the over-the-air protocol, and communicating with the software layer above using some network-based or bus-attached protocol.

The Device Provider Layer

This layer is responsible for communicating with devices and presenting the device using a uniform abstraction to the higher layers of the software. BizTalk RFID introduces a new device abstraction framework called DSPI. You can think of DSPI as a managed device driver model designed with RFID devices in mind. For each kind of device, someone has to write a plug-in that implements this interface on the top end and the device wire protocol at the bottom end. This plug-in is called a device provider in BizTalk RFID terminology. Typically, the hardware vendor writes the provider for a device—analogous to how they would be responsible for writing the Windows device driver for a device. While the device provider layer has good support for RFID readers and printers, it was designed to support a wide variety of device types and near-real-time event streams. This, coupled with the application support for events, makes BizTalk RFID a platform to build real-time applications that can interact with a very diverse set of devices.

Application-Level Services

The next layer in the architecture is comprised of the edge application-level services, intended to be directly callable by end user code. It includes three main kinds of services:

A set of client APIs for executing commands on devices and getting responses back from them, similar to the ADO.NET model for databases: This layer is intended to run in-process with your application, and is the easiest way to RFID-enable an existing Windows Forms, ASP.NET, or COM+ application. Note that even though the client library is in-process with your application, the actual device interaction happens in the BizTalk RFID process.

A brand-new hosted application model for event processing, called the RFID business process: This involves designing a process with a set of event handlers, or custom code for handling events, stitched together using an XML definition, similar to how Windows Workflow Foundation (WF) workflows are defined. The process must be deployed into BizTalk RFID and then executed within it. BizTalk RFID as the application host provides a certain level of fault tolerance and reliability, especially on Windows Server.

A way to execute business rules authored using the BizTalk Rule Engine (BRE): BizTalk RFID includes the same rule engine that ships with BizTalk Server 2006 R2. This is great from a BizTalk developer perspective. All the knowledge that you have about authoring rules using the Business Rule Composer and deployment tools will translate directly to BizTalk RFID. The integration between RFID business processes and the BRE is done through the out-ofthe-box event handler RuleEnginePolicyExecutor.

LOB and Back-End Connectivity

This is the topmost layer in the architecture, and is responsible for collecting, analyzing, and taking actions based on the activity on the edge. Typically, this piece runs in the data center of your enterprise. It includes artifacts such as BizTalk orchestrations that consume RFID data, and Business Activity Monitoring (BAM) reports that depict real-time information derived from the RFID event stream. Other common back-end scenarios for RFID applications include LOB connectivity using the BizTalk WCF LOB Adapter Pack, and analytics using SQL Server Analysis Services.

The BizTalk RFID Device Model

BizTalk RFID has an abstract model for a physical device. Understanding this model is fundamental to how you interact with devices from within BizTalk RFID. In this section, we will cover the basic elements of the model, and how you can interact with them from with RFID Manager and the API. An illustration of this model is shown in Figure 2-2.

Figure 2-2. BizTalk RFID physical device model

Identity

Every device is required to have a unique identity called the device ID, which is the basis for identifying devices from BizTalk RFID. Typically, this looks a lot like a MAC ID on a network card, and is not expected to change during the life of the device. Uniquely identifying a device helps BizTalk RFID take actions when the device communicates with it. A device can also have a friendly name, which is used to identify the device both by administrators and applications that want to use the device. If the device does not support a friendly name, the name is managed at the BizTalk RFID layer.

Endpoint

The device is assumed to have a single connection endpoint, through which remote clients such as BizTalk RFID can connect to the device. BizTalk RFID is agnostic to the nature of the endpoint; the device may support TCP/IP, HTTP, Serial Bus, Bluetooth, or some proprietary mechanism. However, the model assumes that the device shall be connectable only through one of these protocols at one time.

Connection Initiation

The device model assumes that connections are initiated and terminated from BizTalk RFID as and when necessary. For devices that support asynchronous tag notifications, these connections tend to be long-lived. The model assumes that physical connections can be dropped intermittently, and the responsibility for detecting that the connection is down and needs to be reestablished lies with BizTalk RFID. You can use the device statistics tab in RFID Manager to check the number of times the physical connection was opened and the number of failed connections. Note that the true status of the connection really depends on the transport protocol used and that the device provider implements the IsConnectionAlive method correctly.

Authentication

The model assumes that the device may support some form of authentication when clients attempt to connect to it. This is typically username/password-based, but you can use other forms of authentication and secure communications by using the vendor extensions mechanism.

Discovery

The model assumes that the device has some way of advertising itself when it is booted up. This could be something along the lines of PnP for bus-attached devices, UPnP, mDNS, or any device-discovery mechanism, including the newer Web Services for Devices (WSD) protocols. On device discovery, the provider is responsible for raising a discovery event. BizTalk RFID uses the information in the event to determine if the device is managed by that particular server. If it is not, the administrator is flagged that an unconfigured device was discovered. This explicit model gives administrators control over which devices are owned and operated by a particular server.

Knobs

The model assumes that devices have a rich set of settings that control all aspects of the operation of the device, including overall configuration, network configuration, and radio configuration. All of these knobs are exposed as properties by the device. A device can indicate a number of facets about the property, including a logical group that the property belongs to, the type of the property, default values, whether the property is mandatory for operation, and whether it requires restarting the device when the property is changed. The property model also distinguishes between transient properties that will revert to their default values after a device restart, and properties that are persisted across device restarts. The DSPI has a rich model for properties and property metadata, but your mileage may vary based on the extent to which the specific provider that you are using has implemented support for all the configuration settings and options on the device.

Management

The model assumes that devices have interfaces through which common management tasks such as firmware updating, rebooting, and resetting can be performed.

Sources

At this point, you should be asking yourself where the RFID functionality on the device is, and how you can use it. All of the previously mentioned parts of the model are agnostic to RFID and apply equally to readers, writers, printers, and lots of devices like bar code scanners and sensors that have nothing to do with RFID. In keeping with the protocol-agnostic theme, a device is modeled as having zero or more sources. The source in the name refers to a source of events on the device, typically an antenna or a read point for an RFID reader. However, BizTalk RFID also uses this same source concept to interact with the GPIO ports of a device. If your device has other sources that raise events, such as motion sensors, location detectors, or bar code scanners, consider exposing them as sources. Each source has a set of knobs that can be configured, as well as a switch that lets you enable and disable a source from an application using the BizTalk RFID APIs.

The BizTalk RFID Device Model for Applications

The previous section described how BizTalk RFID “thinks” about devices—similar to the Windows driver model that the operating system uses to interact with other physical devices. However, this does not mean applications need to use this model to communicate with the devices. Just like the Win32 .NET APIs provide higher-level abstractions of devices that are more user-friendly than the Windows driver model, BizTalk RFID has a higher-level model that applications should use to talk to devices. This model has two main components:

The DeviceConnection class: This is a stand-alone API intended to be loaded into your client application. Use this model if you need to add RFID device interaction into your Windows Forms, ASP.NET, COM+, or other .NET applications, including WF applications that are hosted and called through WCF.

The RFID business process: This is a new hosted application model for designing and deploying business processes that react to RFID events. RFID business processes are described in detail in Chapter 5. For the purposes of this discussion, the main difference between them and the DeviceConnection class is that RFID business processes are fully managed by BizTalk RFID and run within its hosting infrastructure.

The two models are mutually exclusive in the capabilities that they present to the user: using a device connection, you can only execute commands and get responses back; you cannot subscribe to event notifications from the device that are available asynchronously. Using RFID business processes, by default, you can only receive asynchronous events from the device, you cannot execute commands or get responses. If you need to execute commands from within an event handler, you can do so, but you must use the DeviceConnection API and manage the connection in the code for the event handler.

The Device Model Assumed by DeviceConnection

To connect to a device, you just need the friendly name of the device. This friendly name is in a “flat” namespace across all the devices in the system. You don’t need any other information to connect to the device from your application, including items like the transport settings or authentication information. All of that is done for you automatically by BizTalk RFID. However, you need to know the name of the machine that the RFID server is running on. This makes the connection model simple to use, while also abstracting out the details of the device transport completely from your application. However, before the connection is permitted, the device security model is used to determine if you have rights to perform the operation—which brings us to the next topic, the device security model.

The Device Security Model

The model is implemented entirely within BizTalk RFID, similar to how the Windows ACL model is implemented completely by Windows, not by the physical storage device. This presents a uniform, consistent view of security for the system across a multitude of devices with different capabilities and requirements. The device security model has two usage patterns that it intends to secure:

Application usage patterns: These typically include executing commands such as an inventory round, or tag manipulation operations such as reading tag data, writing the tag ID, writing tag data, and locking the tag. The user invoking the application must be part of the RFID_USER local Windows group that is created as part of the BizTalk RFID installation. This implies that if you have a user in the RFID_USER group, the user has access to all the devices on the server!

Administrative usage patterns: These include operations such as renaming a device, moving a device from one device group to another, and changing settings on the device, including the RF properties and network settings. Administrative access can be granted in a fine-grained manner. BizTalk RFID has the notion of a device group, which is a security container for devices, as well as a container to bind groups of appropriate devices to processes. Devices can belong to exactly one device group, but groups can contain other groups, similar to the Windows folder model. You can add specific local and domain Windows users to a device group and grant them administrative rights on all the devices in the group. The device group security is inheritable down the tree, so you can grant access on the granularity that is appropriate for your scenario.

Figure 2-3. The Device Groups view

Figure 2-4. The Devices view

No device security is applied when BizTalk RFID routes events from devices to RFID business processes. This is because all processes must be deployed and started by an administrator, who implicitly has access to all devices. From a deployment perspective, this feature removes the need to have custom security settings for RFID business processes.

The Concurrency Model for the DeviceConnection Class

Since an application using a device connection is primarily expected to execute commands and receive responses from it using the synchronous command model, BizTalk RFID does not support multiple applications accessing the device at the same instant. This is a good thing. You don’t want one application locking a tag and another killing it at the same time. In fact, most devices do not currently even support such an interaction pattern. However, you can have an application and a business process both using the device at the same time. BizTalk RFID takes care of the sharing of the connection for this scenario and the management of the underlying provider objects.

The one exception to this simple model is the usage of device connections by administrators. Administrators may need immediate access to a device, even if another application is using it, perhaps just to browse the settings on the device. To perform such operations in an unobtrusive way, BizTalk RFID exposes an API to open administrative connections. You can have as many such connections open to a device as needed, but the responsibility of ensuring that the device state is modified in a consistent way is also yours.

The RFID Business Process Device Model

RFID business processes use the concept of a logical device to denote a device. The logical device concept is different from the friendly name of the physical device, and is a concept that is available to that process definition only. Administrators are responsible for binding logical devices to physical devices as part of deployment. The process’s model of a device is simple: events emanating from these logical devices are delivered to the process—nothing more, nothing less. The process cannot open device connections to the logical device names, nor can it execute commands or perform other administrative operations on the logical devices. This, of course, does not preclude event handlers from using the physical names of the devices to do all of this, but doing so obviates the benefits from the distinction between logical and physical devices, and the automatic connection management that you get from logical devices. More than one process can receive events from the same physical device. The delivery of the same event to multiple processes is again managed automatically by BizTalk RFID for you.

Table 2-1 describes some of the important differences between the two device application models:

Installing BizTalk RFID

This section will outline the steps necessary to install BizTalk RFID. It will also provide an overview of the different installation options and the prerequisites involved. Finally, in this section we will walk through an exercise (Exercise 2-1) where we install BizTalk RFID.

BizTalk RFID is intended to be installed at the edge of the enterprise. In this context, edge means a site outside a typical data center, such as a manufacturing shop floor, retail point of sale, or even a parking garage, if the items being tagged happen to be cars in a parking lot. To facilitate such deployments, BizTalk RFID comes with its own installer package, and can be installed independently of BizTalk Server 2009. There are three installable components, based on your deployment scenario:

RFID Services: This option installs the server components.

RFID Tools and Client Connector: This option installs the components required to manage the BizTalk RFID server remotely, and for client applications that need to connect to devices that are managed by the BizTalk RFID server.

The RFID SDK: This includes a device simulator, and samples and tools for developing device providers and applications. In a production deployment, you will typically not install this component.

BizTalk RFID is a stand-alone product, but it makes use of a number of other Microsoft technologies in its operation, including SQL Server, MSMQ, MS DTC, WMI, Active Directory, the .NET Framework 3.5 SP1, IIS, and MMC 3.0. For the complete list of requirements, check the latest version of the installation guide, at http://go.microsoft.com/fwlink/?LinkID=58568. Here are some notes for the major dependent components:

• BizTalk RFID stores almost all of its configuration information in a SQL Server database (called RFIDSTORE by default). As part of the installation process (see Exercise 2-1), you need to provide the location and connection information for the SQL Server instance that should be used for the configuration store.

Tip If the SQL Server database is not available, BizTalk RFID cannot run and will shut down. We recommend using a local instance of SQL Server for this configuration database, and using the remote SQL Server option only in advanced scenarios, such as failover.

• BizTalk RFID uses MSMQ as the temporary store for persisting in-flight events from devices that have not yet been consumed by the event processing applications. This usage of MSMQ does not require Active Directory integration, since BizTalk RFID only creates private MSMQ queues.

Tip If BizTalk Server 2006 and BizTalk RFID are installed on the same machine, you must disable the BizTalk Message Queuing (MSMQT) adapter that is part of BizTalk Server to ensure that the usage of MSMQ by BizTalk RFID does not conflict with MSMQT.

• On Windows Server, BizTalk RFID uses IIS as the application host for increased reliability and isolation. If you are running into issues configuring IIS 6.0 for BizTalk RFID, start from the troubleshooting section in the installation document for a few of the common configuration problems.

Exercise 2-1. Installing BizTalk RFID 2009

Conclusion

In this chapter, we have taken a tour of the abstract model that BizTalk RFID uses to interact with devices. We covered a number of important topics related to device abstraction, including connection management, device security, configuration management, and support for device behaviors. This was followed by a drill-down into the overall architecture of the product, both from a component-layering perspective and a physical process perspective. Moving speedily from the conceptual to the tangible, we finished off the chapter with a quick look at the installation process for BizTalk RFID. Next up, we shall put the installation that we just created to good use by delving into the nuts and bolts of building your first RFID application.

CASE STUDY: IMPROVING MAINTAINABILITY OF RFID INFRASTRUCTURES