Jul 19, 2010RFID middleware, the layer of software that enables enterprise applications to leverage radio frequency identification by integrating them with data received from RFID devices, is rapidly evolving into a commodity, as the market for RFID technology becomes commonplace across different industries.
The three primary functions of RFID middleware can be broadly classified as device integration (that is, connecting to devices, communicating with them in their prescribed protocols and interpreting the data), filtering (the elimination of duplicate or junk data, which can result from a variety of sources—for example, the same tag being read continuously, or spikes or phantom reads caused by interference) and feeding applications with relevant information based on the information collected from devices after properly performing the appropriate conversions and formatting.
|
|
There is a gamut of players in this space—from RFID-focused startups to large software product vendors. More often than not, RFID middleware products from established software giants necessitate the additional installation of numerous prerequisites or dependencies. For instance, the middleware could demand the installation of a database and an application server, as well as queuing and exchange technology, and perhaps even an operating system from the same vendor, thereby skyrocketing the total cost of ownership (TCO) from a licensing perspective.
Hence, RFID is being considered by many organizations as a means of increasing revenue from their existing products, rather than actually solving their clients' specific business problems. Such RFID middleware products can make the overall installation very heavy—that is, difficult to deploy at edge locations, such as warehouses, that may lack powerful servers to support such an infrastructure—and the increased number of licenses for every setup would thus prevent the middleware user from attaining an adequate return on investment (ROI).
To counter the need for separate RFID middleware, some vendors launched smart devices that have an operating system as part of their firmware, encapsulating an embedded middleware framework within itself. Some smart devices also come with integration capabilities, such as built-in adapters for communicating with enterprise products, such as SAP AII/ PI, Microsoft BizTalk, JMS, MQ or databases. These devices greatly reduce the TCO of owning separate RFID middleware, and often appear to be an attractive option for organizations adopting RFID.
By deploying RFID readers with embedded middleware, a company can reduce the time-to-market and TCO of that deployment, since there is no need for a separate site-server to locally host the middleware (and its dependent products) at each site. What's more, certain middleware-like functions, such as filtering for duplicate reads, can also be performed on the device itself.
There are, however, a number of potential drawbacks to employing devices with embedded middleware. While such smart devices will gradually increase their processing power and available memory in the future, their capabilities do not currently match those of server-class machines. Therefore, if middleware functionality is added to a device, it could potentially slow down the speed with which it actually reads a tag, thereby making it difficult for that device to track fast-moving objects (cars at toll gates, for instance).
Having the embedded middleware filter out duplicate or junk data would not enable filtering to be performed across devices, because the middleware on one device might not have access to the information being read by the middleware on others. Consequently, if two RFID readers have been deployed on either end of a dock door to maximize readability, and if both read an RFID-tagged product moving past them, each interrogator would then report that event to the company's back-end system. Hence, this would not constitute handling business events "logically," but rather physically, and would thus require additional filtering logic at the back-end system—which essentially amounts to reinventing the wheel, since such functionality is provided out-of-the-box with server-based RFID middleware.
Embedded middleware increases an organization's dependency on the device and its vendor, and this tight coupling might hurt the enterprise in the long run. In the future, if a device with better reading capabilities (one offering more reliable readability in case of interference, as well as better read ranges) becomes available, it would be difficult to migrate to the new device if it lacks embedded middleware. Having separate RFID middleware on a server, on the other hand, provides the flexibility of plugging and playing with multiple devices. Adding programming logic on a device is not a scalable model, whereas doing so on middleware would be comparatively more scalable. Hence, the device should be considered as a means of "data collection," and the middleware as a powerful yet generic layer for "data processing"
Some device vendors also provide a complete managed solution whereby their embedded middleware posts data to servers hosted on their network. They charge for providing this RFID information to the organization to which it caters. While this serves as an unperturbed approach (because it is a completely managed information service), if the vendor increases its hosting and information provisioning charges in the future, then that would be a setback to the client. If the repository is proprietary, it would also imply less trading-partner collaboration, which is otherwise the crux of radio frequency identification. RFID should be seen as an enabling technology for an organization's business processes, just like bar coding. Hence, a long-term dependency on vendors for the same is unadvisable.
A large enterprise would typically operate across multiple geographical regions. An RFID device being used in one country, however, might not be available in others, because the frequency it utilizes to operate might not comply with the RF regulations governed by those nations' legislative bodies. What's more, customer support for a specific device might not be available in every region, and the organization would thus have to consider employing multiple devices in different regions. Each device might not come with embedded middleware preinstalled on it—in which case, it would be a more extensible approach to have a central middleware product that communicates with multiple devices in an agnostic manner using device drivers or adapters, just as operating systems are able to communicate with multiple devices—such as printers or USB pen-drives—without being dependent on any one of them. Infosys, for example, has developed a lightweight, SAP-AII 2.1-certified middleware framework known as the Infosys RFID integration platform.
In conclusion, there is more to embedded RFID middleware than meets the eye. When such factors as scalability, interoperability, integration, vendor independence, information ownership and manageability are crucial, it is recommended to consider a lightweight, server-based RFID middleware approach that is not dependent on database servers, application servers or other licensed memory-seeking products.
Mayank Shridhar is a technology architect for Infosys Technologies Ltd.'s retail, CPG and logistics unit. A founding member of the firm's RFID & Pervasive Solutions Practice, he was also actively involved in the creation of its ShoppingTrip360 solution (see Product and Shopper Movement Tracked by ShoppingTrip360). He has seven years of software consulting experience in RFID, helping large corporations across a range of industries, leading RFID consulting assignments, carrying out RFID product evaluations, and developing high-performance RFID applications using Java and .NET. Infosys' RFID practice offers solutions catering to various industry domains, such as retail, consumer packaged goods, logistics, transportation, manufacturing, aerospace and pharmaceuticals. The company's experience in the RFID space over the past six years spans a diversity of engagements, from assessment and consulting to complete end-to-end implementations.
