C H A P T E R 1 - Introduction to Sun Java System RFID Software Programming Platform

C H A P T E R 1

Introduction to Sun Java System RFID Software Programming Platform

This chapter describes the architecture of the Sun Java System RFID Software 3.0 (RFID Software) and introduces the programming mechanisms that are available for using the information generated by the physical devices that comprise your RFID network. Subsequent chapters contain more details. The following topics are covered in this chapter:

RFID Software Architecture Overview

Structure of a Configuration Object

RFID Event Processing Basics

Processing RFID Event Manager Information

Managing RFID Event Manager Devices

RFID Software Architecture Overview

The RFID Software consists of the following four major modules:

RFID Event Manager

RFID Configuration Manager (a component of the RFID Event Manager)

RFID Management Console

RFID Information Server

The RFID Event Manager communicates with RFID sensor devices to gather information from the physical world. This information can be stored in the RFID Information Server for future analysis. The information can also be sent continuously to third-party applications as it arrives at the RFID Event Manager.

The RFID Configuration Manager is a graphical user interface (GUI) application that is used to specify the set of devices connected to the RFID Event Manager. You also use the RFID Configuration Manager to statically define how to process the information within the RFID Event Manager and where to send the information after this processing.

You can also use the RFID Event Manager to dynamically specify how to process the incoming information and define the subsequent consumers of the processed information. This guide describes the programming mechanisms that developers can use to dynamically control sensor devices and to define rules for processing the information collected by the devices.

You use the RFID Management Console to monitor and manage the status of the devices that are connected to the RFID Event Manager. The RFID Management Console enables system administrators to monitor statistics and change runtime parameters for each of these devices.

The RFID Event Manager is a distributed platform consisting of a single Control Station and one or more Execution Agents. In the simplest and most common scenario, the Execution Agent and Control Station are installed on the same computer. The Execution Agent is responsible for communicating with the physical devices, processing the information, and posting the information to the consumers of the information. The system administrator uses the RFID Configuration Manager, which is installed as part of the Control Station component, to create one or more Configuration Objects. A Configuration Object specifies one or more devices to control and specifies a set of components that process the device information. The set of information-processing components is called a Business Processing Semantic Unit (BPS).

In the simplest scenario, each Configuration Object is executed by a single Execution Agent. In a large RFID network with many deployed devices, the RFID Event Manager functionality is scaled by installing multiple Execution Agents on separate computers. In this more complex deployment, the Control Station provisions each of the Configuration Objects to a separate Execution Agent in round-robin fashion. The Control Station continuously monitors the status of the Execution Agents. To provide high processing availability, if an Execution Agent fails, the Configuration Object is provisioned to another Execution Agent.

The following illustration shows the overall components and communication flows comprising the RFID Software.

Flow diagram illustrating the basic functions and structure of the RFID Software.

Structure of a Configuration Object

A Configuration Object consists of a collection of components called adapters, filters, and connectors. The components are linked in a chain to process events arriving from the RFID devices. Typically, an adapter component begins the chain by receiving information from the device and sending information to the device. Filters are used in the middle of the chain to remove noise, such as excessive read events, or to perform other data manipulation. Connectors (also called loggers) are at the end of the chain to collect data for back-end processes or listeners (also called consumers). A back-end process might be the RFID Information Server or a third-party software application. The following figure shows an example of a Configuration Object receiving information from an RFID reader and posting the processed information to the RFID Information Server.

FIGURE 1-1 Structure of the RFID Event Manager Configuration Object.

Figure shows the RFID reader communicating to the adapter, which passes information to the filters and connectors in the BPS and then to the RFID Information Server.

The components of the Configuration Object are defined as follows:

Adapter - This component implements the communication protocol for a specific type of device. The adapter is equivalent to an operating system driver. The adapter handles the details of communicating with the hardware devices. Each adapter collects and transmits information to a specific manufacturer and model of RFID device. The adapter then transmits the collected information to the next component in the BPS.

Filter - A filter component might modify the information flowing from an adapter to a connector in the following ways:

The filter can reduce the amount of information in a meaningful way. For example, a filter can prevent duplicate events from passing through to the connector.

The filter can add metadata to the information going to the connector. This metadata can add meaning to the event. For example, you might locate and configure multiple readers in a doorway. Then you might use a filter to indicate to the connector when an event represents a tag coming in or going out of the doorway. Using this method reduces the quantity of data needing to be processed by the RFID application. By sending only clean, complete information to the application, the application code can focus on business-oriented functionality, rather than on sifting through raw, unprocessed event data.

Connector - A connector sends the information originating from the RFID readers to applications that use the information. Connectors bind the RFID Event Manager to RFID or sensor-based applications. A connector puts the information into an acceptable format for the application. Many of the connectors provided with the RFID Software 3.0 release package the data in XML messages that conform to the Auto-ID Center PMLCore specification. See Chapter 7 for details on using the Java library included in the RFID Event Manager installation.

Note - These RFID Event Manager components are subclasses of com.sun.autoid.ems.AbstractComponent, a class that follows the Composite design pattern (described in the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). This pattern enables the RFID Event Manager to work with filters, connectors, and adapters using the same interface at a basic level. The AbstractComponent class also provides various services required by these three class types.

RFID Event Processing Basics

As the name implies, the RFID Event Manager is an event-driven platform. Components (adapters, filters, and connectors) generate events to communicate with each other. Every component is an event producer, and every component can register itself with other components to consume their events. Typically, an adapter listens and/or queries the physical device for information. The information is then packaged inside an event object, and this event object is posted to the listeners that were previously registered with the adapter. As shown in FIGURE 1-1, the adapter receives Electronic Product Code (EPC) information from the RFID device, packages the information as an Identifier object and posts the event to the two filters that have previously registered themselves as consumers of the adapter events. The filters, in turn, manipulate the information and post the events to the respective connector, which consumes the events from a particular reader. The connector then packages the event in a manner that is understood by the application that consumes the event.

Note - The Javadoc documentation for the RFID Software is available as part of the Sun Java System RFID Software Toolkit. See To Download and Install the RFID Software Toolkit for information on getting the toolkit.

`Identifier` Objects

RFID data captured by adapters is packaged in Identifier objects. See the API specifications (Javadoc documentation) for the com.sun.autoid.identity package - rfid-toolkit-dir/docs/api/index.html.

Identifier Objects include the following:

Numeric identifier - A general purpose Identifier object consisting of a number.

EPC identifier - The Electronic Product Code (EPC) assigned to a physical item. Several subcategories are defined as follows:

EPC_GIAI - Global individual asset identifier

EPC_GID - General identifier

EPC_GRAI - Global reusable asset identifier

EPC_SGLN - Serialized global location number

EPC_SGTIN - Serialized global trade identification number

EPC_SSCC - Serialized shipping container code

DoD - U. S. Department of Defense construct

In addition to the unique ID, the Identifier object might contain a set of generic properties. The properties can be interpreted by the filters in an application-dependent manner. See the Javadoc documentation for the RfidTag object.

`Event` Objects

The RFID Event Manager components, adapters, filters, and connectors, can generate and consume event objects from other components. See the API specifications for the com.sun.autoid.event package - rfid-toolkit-dir/docs/api/index.html. The base class is Event.

Event objects include the following:

Identifier events as follows:

a. IdentifierEvent - This object carries a single Identifier object, which represents the EPC (Electronic Product Code) or other type of identifier detected by the device, and any other properties that are specific to the adapter and application.

b. IdentifierListEvent - This object is similar to IdentifierEvent, but carries multiple Identifier objects that were detected by the same device.

c. DeltaEvent - This object carries multiple Identifier objects, but separates the information into two categories:

i. Objects coming into the device's field of view

ii. Objects moving out of the device's field of view

MiscEvent - The MiscEvent object carries an event containing a generic set of properties defined by the adapter or filter implementer. The properties are application dependent.

StatusEvent - The StatusEvent object carries a message describing the status of the device.

This guide provides details on how to create custom filters and connectors. You can create custom event types, provided they are sub-classed from com.sun.autoid.event.Event. If you create your own event types, then your filter cannot feed other filters and connectors that do not know how to handle the new event type. The best practice is to support the IdentifierEvent, IdentifierListEvent, DeltaEvent, StatusEvent, and MiscEvent types in your filters and connectors and refrain from creating new event types unless absolutely necessary.

Processing RFID Event Manager Information

There are four main mechanisms for consuming information generated by the devices connected to the RFID Event Manager.

RFID Configuration Manager - Use the RFID Configuration Manager to statically define one or more connectors that post information to an application. This requires the least amount of programming by an application developer, but is restricted to one-way notifications initiated by the RFID Event Manager. See the Sun Java System RFID Software 3.0 Administration Guide for details on using the RFID Configuration Manager.

EPCglobal Application Level Events (ALE) - Use ALE to specify the type of events the application consumes. When using ALE, the application generates XML messages that define the events of interest. The application needs to be programmed to handle the XML messages that are received containing the requested information. To facilitate development, the Sun Java System RFID Software Toolkit provides a Java library implementing the necessary APIs to use ALE. See Chapter 5 of this guide for more details.

The EPCglobal Application Level Events (ALE) Specification, Version 1.0 specifies only one-way communication to the device to obtain RFID tag identifier information. The specification does not implement a mechanism for getting tag user data, for programming tags, or for managing the devices. Any Java or non-Java application that complies with the EPCglobal ALE 1.0 specification can communicate with the RFID Event Manager.

At the time of this release, EPCglobal is in the process of defining a new version of the ALE specification that will specify a standard method to obtain user data and program tags, among other things. Sun Microsystems, Inc. is actively participating in the definition of this standard and plans to provide an updated library and implementation as the specification process progresses.

Java APIs - Use the Java ReaderClient APIs to control devices, program RFID tags, read and write user memory and tag identification on RFID transponders (tags) using the Java library bundled with the RFID Software 3.0. Your application communicates directly with the RFID Event Manager by using Java RMI (Java Remote Method Invocation) without the need to convert between protocols and data representation. See Chapter 3 of this guide for more details.

Web services for device access - Use the web services for device access when you need to cross firewalls using SOAP or you need to communicate with the RFID Event Manager from a non-Java application. This mechanism gives you the same functionality as the Java ReaderClient API, but is implemented as a web service. The RFID Event Manager and the client application exchange SOAP messages when using this mechanism. SeeChapter 4 of this guide for more details.

These mechanisms are not mutually exclusive. You can use them in conjunction with each other to achieve a task. You might choose to use ALE to obtain tag information, and then use the device access web services to get user data and program tags. There may be applications where you want to mix and match web service and Java APIs. For example, you might use the Java ReaderClient API to communicate with RFID devices in your local network and use the ALE Java library or the device access web services to communicate with an RFID Event Manager in a remote network across the continent.

Managing RFID Event Manager Devices

Many times an application needs to get device identification or to control the gathering and sending of information. Use the Java ReaderClient APIs or web services for device access APIs to instruct a device when to start gathering data, to stop gathering data, to get device status and to get device identification information.

System administrators can use the RFID Management Console to perform these same tasks from a web interface without any need for programming. See the Sun Java System RFID Software 3.0 Administration Guide for details on using the RFID Management Console.