Dev2Dev > Articles

---

RFID Technical Challenges and Reference Architecture

by Puneet Agarwal and Ashok Banerjee, Jeffrey Flammer
11/01/2005

Abstract

Radio frequency identification (RFID) is increasingly being used in retail, pharmaceuticals, transportation, and defense. RFID can provide great value in terms of track and trace, pedigree tracking, forecasting, obsolescence reduction, pharmaceuticals recalls, and efficiency in the entire supply chain infrastructure. However, the usual concerns of security, scalability, availability, reliability, distributed management, and performance are as relevant to RFID as they are in other domains.

This article discusses the appropriate architectures for RFID infrastructure to mesh with the greater IT ecosystem of a company. The article highlights several considerations often overlooked by RFID vendors, explains the architectural options to consider when choosing the provider of an RFID infrastructure, and examines in some detail the architectural benefits of these choices.

Introduction

Radio frequency identification (RFID) is becoming a reality as modern supply chains come to require ever greater efficiency, information flow, and flexibility. RFID efforts are already underway in the retail, pharmaceutical, transportation, defense, and consumer packaged-goods industries. The presence of RFID technology can improve forecasting, pedigree tracking, and container security, while reducing problems such as shrinkage, recalls, and out-of-stock goods. The result is billions of dollars in supply-chain savings.

Retailers such as WalMart, Albertson's, and Best Buy already have issued mandates requiring their top suppliers to be RFID-enabled by the end of 2005. As these requirements expand across thousands of suppliers, stores, and distribution centers—each requiring multiple distributed RFID readers—several technology challenges arise. Today, most companies instituting RFID technology focus on small-scale pilots and one-site proofs of concept. To realize the true benefits of RFID, however, the technology must be embraced enterprise-wide with cross-enterprise scale.

Based on its long and successful history working with high-volume distributed transaction environments, BEA has identified seven key technological challenges that must be addressed as organizations move toward full use of RFID technologies. In the next few years, wider adoption of RFID will have enormous IT implications in terms of scalability, availability, security, interoperability, integration, administration, and messaging. BEA offers a reference architecture that can serve as a base for both current and long-term RFID solutions.

This article is intended for audiences with some familiarity with RFID technologies.

RFID Technical Challenges

As RFID technology becomes more pervasive, its distributed nature, combined with heavy transaction volume, will raise several important technological challenges in the seven key areas of scalability, availability, security, interoperability, integration, administration, and messaging. This section examines each of these in turn.

Scalability

As the use of RFID technology grows, companies will be required to handle input from thousands of readers distributed across supply chains worldwide; rapid growth will challenge scalability. The amount of data processed is enormous—readers can capture between 120 and 400 signals per second—and this creates a further challenge.

To handle this level of data traffic, non-blocking I/O is required. When many users access an application at once, as with RFID, most middleware solutions open a socket for each client and create a unique thread for each user. This technique, known as blocking I/O, severely limits performance and scalability. In contrast, non-blocking I/O enables middleware such as BEA WebLogic Server to multiplex a small number of reader threads across many concurrent users, ensuring high performance and scalability.

I/O and networks are utilized heavily in terms of the inflow of high volumes of data from the readers, and notification messaging. CPU utilization at the edge server stems from the duplicate detection and pattern matching at the edge server. Given the amount of data being processed, network bandwidth could also become an issue. "Boxcarring"—packing many requests into one data packet—can ease network congestion. It can also reduce the time required for multiple requests to pass through security and other code layers.

Finally, the use of a central data repository at the edge can create system bottlenecks, affecting scalability. For example, if all data captured from a set of RFID readers were written to a database, the rush of data to the database could severely hamper performance. Instead, database interactions should be handled at the integration layer, where much less data is processed. This architecture, shown in Figure 1, can be conceptualized as an event source approach as opposed to an event repository approach.

Figure1: Using a database at the edge severely limits scalability. The edge should serve as an event source rather than as an event repository.

Availability

To ensure data is delivered reliably to the appropriate destinations across an infrastructure and application stack, it is necessary to eliminate single points of failure at the edge layer, the integration layer, and all points in between.

At the edge layer, where data is captured and filtered, dependency on a central database hinders both scalability and availability. In contrast, a system may briefly maintain events in memory, either discarding them after use or recording them in a file system when necessary. This practice can greatly reduce dependence on database availability.

At the reader level, overlapping fields—for example, multiple readers/antennae at a dock door—increase the possibility of accurately capturing events at the physical layer. The edge layer can manage readers at this level, turning on readers when others are down, eliminating duplicates, and so on.

Because the edge does not record the events it passes, and because the integration layer houses business logic, availability at the integration layer is critical. Interoperability of any RFID solution with commercial load balancers must also be considered, as the load balancers are needed to distribute a load and ensure failover. The integration layer must also be able to offer highly available messaging through clustered JMS (Java Message Service).

To ensure the absence of single points of failure at every layer of the stack, a customer may want to use a clustered database to back the integration layer. It is, of course, much more efficient to use a database at the integration layer than at the edge layer.

Security

With RFID the vast amount of potentially sensitive data involved makes security a critical aspect of RFID systems. At the lowest level, secure administration prevents readers from being turned off and items stolen. The administrative interface, therefore, must be protected by authentication, authorization, or audit, potentially over SSL (Secure Socket Layer).

However, most RFID middleware solutions cannot use SSL; the SSL "handshake" involves CPU-intensive calculations that could affect the edge's ability to do other CPU-intensive work such as filtering. Without SSL, the edge is left comparably insecure. As a result, the entire stack—reader, edge, and integration—should often be wrapped in a firewall with all remote access to the stack through permitted ports and protocols. Perimeter authentication could then be enforced, with a Web application or Web service administering the stack remotely.

Finally, the chosen middleware platform must easily integrate with third-party providers of authentication, authorization, LDAP, and audit technologies, as Figure 2 shows.

Figure 2: The edge server will need to support a pluggable security provider interface.

Interoperability

Interoperability is important at several levels to ensure successful RFID implementation. Perhaps the most critical need is for standards-based JCA adapters to connect effectively to applications such as warehouse or transportation management systems. It is not enough to simply be able to publish a JMS message or event in a proprietary format; application vendors such as SAP, Yantra, and Manhattan require that events be presented in certain formats. Adapters bridge the gap, propagating information to the appropriate application in a format it accepts. A middleware solution should provide and support adapters for critical applications.

Out-of-the-box interoperability is critical at other points as well. For example, middleware should Interoperate with firewall providers; authentication, authorization, and audit providers; load balancers; and JMS vendors. Reader interoperability is also important. Although efforts to standardize reader communication protocols are underway, until one standard becomes dominant, each middleware vendor will have to provide a reader abstraction layer and interoperability solution.

A well-designed stack puts a reader abstraction layer at the edge, making the integration layer reader-agnostic. The integration layer, in other words, should not be concerned with specific reader protocols or formats.

At the reader abstraction layer, it is important to expose all reader-specific commands rather than just the least common denominator of commands (potentially through dynamic reader interface discovery). The layer should also support multiple reader versions and vendors, while providing a uniform abstraction layer, as shown in Figure 3.

Figure 3: The edge server will be required to interoperate in heterogeneous environments.

Integration

Some form of enterprise application integration (EAI) is needed to get the full value from RFID events. Simply dispatching events from the edge to a series of applications is not an adequate solution, as it raises issues related to security, reliable messaging, performance, availability, adapter connectivity, business process definition, and so on.

In contrast, an EAI solution provides a global view of the problem. An organization with different edge servers in Dallas and San Francisco, for example, could send events to a common EAI solution. Events involving readers or antennae connected to different edge servers need to be composed and correlated at a unifying EAI layer. Moreover, complex event composition is not suitable in this situation, given the CPU cycles required at the edge layer. The EAI layer becomes even more critical as business processes touch more and more systems and people, both inside and outside an organization.

Several other aspects make an integration solution necessary. Standards-based adapters are required for connectivity to backend applications; the ability to assemble, monitor, and manage processes in a visual environment is also important. The ability to compose complex interactions between business processes, portals, Web services, RFID readers, and other elements can be greatly enhanced through a common abstraction layer such as controls. (For more information on controls, go to the dev2dev Beehive page.) Finally, seamless integration must exist between the edge and the actual integration layer as events are passed.

Administration

As RFID is enabled across supply chains, the ability to administer across the entire stack becomes necessary. At a high level, there are two aspects to RFID monitoring and administration: device management and provisioning of configuration to the readers. Administrators require a single interface for managing the entire stack, which sits inside a centralized portal framework.

An RFID administration solution should also integrate seamlessly with the existing management provider (for example, HP OpenView or Tivoli), necessitating support for standard protocols such as SNMP and JMX. Ideally, a central configuration master would push the configuration to the edge and the readers across the supply chain.

Other challenges, such as ensuring singleton services and eliminating split-brain syndrome, arise when provisioning inside complex and distributed environments. These must be resolved if RFID provisioning is to become successful.

Messaging

Guaranteed exactly-once message processing semantics is difficult to achieve. Possibilities of message disruption exist on the sender and receiver sides, and even during the intervening transport. Most middleware solutions fail to consider the need to ensure exactly-once message semantics. Failing to take this problem into account, however, could have real consequences—for example, if individual delivery reports are inadvertently delivered multiple times. A warehouse manager could believe that two items were shipped to a partner as opposed to one; multiply this situation across time and location, and the effect is significant.

Another major factor is ensuring transactional guarantees on message enqueue and dequeue. If a message is not enqueued transactionally, there is no guarantee that it made it into the queue at all; similarly, a dequeued message is not guaranteed to have been fully processed. Other considerations revolve around operation idempotence—whether it is safe to retry a partially completed operation.

Occasionally, connected computing is required, especially when the sender and the receiver are geographically distant. In such a case, if one end relies on synchronous responses from the other, a network disruption could bring the entire operation to its knees. Such communications should be made asynchronous.

Asynchronous communication is often implemented using JMS. If the JMS provider is on the receiver side, however, the sender side will be blocked if it cannot enqueue its messages (or it gets an error and has the responsibility of retrying). So putting the JMS on the receiver does not help the sender in the case of these kinds of issues. However, if Store and Forward messaging are used, many of these issues are resolved. In this case, asychronicity is restored as the Store and Forward system will be responsible for sending the message on, retrying, and so on. For this reason, a JMS Bridge or Store and Forward technology is critical.

Reference Architecture Tiers

BEA's reference architecture is made up of four tiers: readers, edge server, integration layer, and application layer. These tiers are illustrated in Figure 4.

Figure 4: A future-state reference architecture

At the bottom layer, readers poll the tags between 120 and 400 times a second, often based on a trigger simliar to a motion sensor. At any one time, the IP-addressable readers should be controlled by one and only one edge server. This requirement is necessary to avoid problems related to network partitioning.

The edge server regularly polls the reader (for example, twice a second), removing duplicates and performing filtering and device management. The edge server is also responsible for creating ALE events and dispatching them to the integration layer. This dispatch often requires exactly-once message semantics (see Messaging, above).

The integration layer receives multiple ALE events and combines them into workflows that touch various systems and people as part of larger business processes. The integration layer interacts with packaged applications, such as warehouse or product information management systems, using standards-based JCA adapters. This layer may also work with systems through controls and open-source frameworks that provide an abstraction layer that exposes backend components as reusable components.

The integration layer may also communicate with the object naming service (ONS) through a Web services interface. Analogous to a DNS server, the ONS can be used to look up a unique RFID tag ID and identify additional product information. The integration layer must also persist to and query data from the Electronic Product Code Information Service (EPC-IS) repository, which provides business context to ALE events—for example, tracking and tracing product through the supply chain. Standards around the EPC-IS repository are currently being defined.

Finally, the integration layer can also communicate with external systems through a gateway in the firewall using B2B messages, such as EDI or Web service requests that query the EPC-IS repository.

The separation of the edge and integration layers improves scalability and reduces cost for the customer, as the edge is both lighter and less expensive. Just as the use of application servers and database connection pooling became prevalent with a rapid increase in Internet database connections, as the industry moves from Internet traffic to RFID traffic, a separate tier is needed for filtering and connection concentration back to the integration layer.

Control messages flow into the system through a management portal to the integration layer, then on to the edge and, eventually, to the reader. Provisioning and configuration is done down this chain, while reader data is filtered and propagated up the chain.

Conclusion

This article examined seven hidden challenges of the RFID server: scalability, availability, security, interoperability, administration, messaging, and integration. It also provided a reference architecture with the overall ecosystem in which RFID plays a part. Commonly seen architectural differences like the existence of the database at the edge and its ramifications were also discussed.

In summary, when considering an RFID edge server it is important to choose a lightweight, remotely manageable, remotely provisionable, secure, scalable, reliable RFID edge server. Other key RFID-specific considerations are how the edge server architecture approaches high I/O and network bandwidth concerns, high CPU utilization caused by intensive pattern matching, and how that meshes with the requirements of low CPU and memory utilization at the edge. Transactional reliable messages with message ordering and exactly-once messaging guarantees and the ability to function in disconnected mode are also important considerations for the RFID server, especially around disconnected mode operations.

This reference architecture and the above considerations, among others, are implemented in the WebLogic RFID Server.

References

• EPC Global
• RFID Talk
• RFID Journal
• RFID Exchange

Puneet Agarwal is the Product Manager for the BEA RFID Server Product.

Ashok Banerjee is the Development Manager for the WebLogic Server J2EE Container team. Ashok also worked as the architect for the WebLogic Server RFID Edition incubation.

Jeffrey Flammer is a Senior Director in Product Marketing. Jeff originated the entire RFID Server proposal some 3 years ago and was the overall lead for the incubation of the BEA RFID Server product.

---

Return to dev2dev.