Apr 05, 2004Many companies are struggling to understand how RFID data can be turned into information that they can use to cut costs and drive efficiencies. The key is likely to be found not in the RFID readers or in the enterprise systems, but in the middle—more precisely, in the middleware. But companies need to understand that RFID systems require a new kind of RFID middleware, as well as conventional integration middleware. And the key to a successful project will be in knowing when and how to use each.
What do I mean by RFID middleware? This is a new breed of software that sits between the RFID reader and conventional middleware. It facilitates communication between enterprise systems and a variety of automatic identification devices—RFID readers and bar code scanners —and performs the functions outlined by EPCglobal's Savant specification and the broader EPC Network. Savants, as defined by EPCglobal, are distributed middleware applications designed to process the streams of tag or sensor data coming in from one or more EPC readers. RFID middleware supports this core Savant functionality, plus broader functions such as EPC “commissioning,” where tags are commissioned (physically written to) using unique EPC numbers assigned to the individual items they are tracking.
|
|
Conventional middleware is used primarily to link disparate applications, both internally and externally, to the enterprise. This typically involves routing data using different transport protocols, translating data into different formats and providing a suitable means of integration such as Web services and service-oriented architectures.
Don’t be fooled by the term “conventional” middleware. This layer is important, and many analysts believe it will be the basis for most innovation in the software industry for the next several years. A good example of this innovation is the advances we’ve seen in the base-level Web services standards, including SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration) and WSDL (Web Services Definition Language); higher-level standards, such as WS-Security, WS-Trust and WSDM (Web Services Distributed Management); and the work performed around business process management by BPMI.ORG. All these standards are important to RFID applications because they help disparate applications integrate with one another more easily, more flexibly and more cost-effectively. In addition, the business process management standards help to translate integration challenges from a technical paradigm to something that can be represented in terms of more understandable business processes and workflows.
To decide when to use RFID middleware and conventional middleware, it’s important to understand the strengths and weaknesses of each category of product; you also need to understand your technical requirements in terms of application integration and data management. Additionally, each application you implement may require a different solution that may include one or both of these middleware categories. A combination of the two is often required, and it’s important to not under-utilize the conventional tools. In general, you should aim to use conventional middleware, unless it cannot perform the function you need, because it is most likely to come from a stable vendor with a mature product.
RFID middleware has a key role to play in situations where you may need to interface directly with a disparate set of auto-ID technologies, such as bar code scanners and RFID readers. Conventional middleware is not well equipped to handle this range of devices unless all hardware devices and their interfaces are programmatically exposed, meaning accessible, via easy-to-use software services using Web services standards and a service-oriented architecture.
Since the RFID middleware is positioned directly in contact with the physical hardware, it can also help perform a vital data filtering and aggregation function, by helping cut down on the data volumes moving further up the pipe and closer to enterprise systems. By inspecting the data upon initial capture, and applying some business rules, it can help to turn raw data into actual meaningful information that constitutes real events and transactions. The key functions of RFID middleware then are cross-platform hardware integration and data reduction—integrating hardware and filtering data.
As you move up the software stack, conventional middleware can do what it does best—routing and transformation. Back to our earlier definition, this means routing data using different transport protocols and translating data into different formats for varying back-end systems. It can help to serve as your vendor-neutral protocol switch in order to route your RFID information to the appropriate systems, using the required transport protocols and the required data formats. The key functions of conventional middleware then are cross-platform software integration and data mapping—integrating applications and converting data formats. You can also use conventional middleware to connect to the EPC Network using the Object Name Service—a network service similar to the Web's domain name service—to resolve lookups for specific items within the supply chain.
Both RFID middleware and conventional middleware require the use of business rules. But it's important to separate the low-level business rules for reducing the amount of data passed up the chain (RFID middleware) and the higher-level business rules for determining routing and transformation (conventional middleware). You’ll also need to consider how best to handle alerts and notifications and business activity monitoring. Many conventional middleware products have highly advanced functionality and can provide valuable user interfaces, dashboards and reporting with only a small degree of customization.
As you plan your RFID integration strategy, aim to minimize the number of products involved for simplicity, but also be aware of the strengths and limitations of both types of integration middleware. For small-scale applications and IT shops with fairly homogeneous environments, you may find that a product from a single vendor can perform each of the roles described above. But for larger-scale applications and heterogeneous IT environments, you'll most likely require a more robust solution that incorporates both RFID middleware and conventional middleware. However you craft your approach—whether it is single-vendor or multi-vendor—be sure to use a logical architecture that can serve as your framework for implementing RFID and other auto-ID technologies and support your future needs for application integration and data management. In addition, choosing products that support open-standards, such as Web services and EPCglobal specifications, is a winning strategy.
Nicholas D. Evans is global lead, emerging technology, for BearingPoint’s public services sector. He is the author of “Military Gadgets: How Advanced Technology Is Transforming Today’s Battlefield…and Tomorrow’s” and “Business Innovation and Disruptive Technology.” To comment on this story, send email to
ndevans@bearingpoint.net or click on the button below.
