More RFID Journal Sites: RFID Journal Espanol RFID Journal Brasil RFID Journal Events RFID Journal Awards
RFID EXPERT VIEWS
Text size:
T
T
T
RFID Middleware: To Embed or Not to Embed
Embedded middleware products do not usually comply with any Electronic Product Code (EPC) standards, but instead are proprietary, and they might not be able to communicate with applications in an enterprise network across firewalls in cases whereby the devices are on separate controlled networks within a facility (in a manufacturing plant's production line, for example).
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.
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.
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.
READERS' COMMENTS
Embed for performance and cost savings - if it's mission cri
After over 300 RFID projects (http://tinyurl.com/300RFID) we've learned a lot about middleware. Our team has deployed scores of different middleware packages and determined that the only way to get 99.9% read accuracy and lower the server infrastructure (as Mayank correctly points out) is to embed software on the readers. Embedded edgeware offers several advantages over server-based or managed service middleware: 1) Much higher accuracy due to greater device control & configuration management 2) Lower total cost of ownership, less servers to maintain and manage 3) Higher availability because it eliminates a single-point of failure (the middleware server or managed server) 4)Lower bandwidth requirements and cost, and because processing is done locally no latency on GPIO commands - like alert lights, or switching conveyors 5)Better remote diagnostic capability RFID readers have become so much more powerful that embedding the edgeware on the reader can increase performance because there is no latency controlling GPIO or making immediate decisions. Server based middleware or managed services are only as good as the high speed connection getting the control responses, and even then only get a portion of the reader capability via network. ODIN's EasyEdge is a great example of what is possible when you work hand-in-hand with the major reader manufacturers to get the most out of performance and the lowest possible cost. Edgeware should make your existing application like SAP, Maximo, or Oracle more valuable. After all, you've invested millions in those, why pay more for a specific RFID software? For best performance and cost savings go with an embedded operating system on the readers that is EPC compliant and you'll get accuracy and cost savings. Many of the Fortune 100 corporations are using ODIN's EasyEdge (http://tinyurl.com/EasyEdge).
Posted By: P. Sweeney 7/19/2010 at 10:06:07 AM
Embedded is difficult at times
I work in the IT department of an FMCG company in the Asia/ Pacific region. We also have operations in Europe. We had used RFID for tracking some of our shipments with select retailers, and had jumpstarted it with different devices in Asia and Europe, both having embedded middleware (I can't take the names of the vendors). They worked well in the POC stages but later we realized that we were facing problems with scalability because our IT department was having difficulties maintaining multiple versions, and we also needed customizations to be done based on a few firewall constraints that we had in some areas. One of the vendors (in Asia) had agreed to doing the customizations whereas the other vendors refused, stating it as infeasible. We realized that the maintenance cost for the embedded middleware was also going higher than expected. Finally we used a server based middleware and we hired an IT services provider to do the customization for us, and it was easier for us to manage. This is just personal experience that I thought I would share, because I'm aware of some of the challenges with embedded middleware.
Posted By: A. Smith 7/20/2010 at 9:54:46 AM
Informative article!
Thanks for this informative article. last paragraph very well summed up. I am working in an IT company and have worked in an RFID middleware product. I feel middleware is the way to go if 1) external integration is expected to happen 2) Vendor agnostic server application is desired.
Posted By: R. 7/20/2010 at 12:00:19 PM
Try Distrix
Using Distrix software by Spark Integration (www.sparkintegration.com) for integration now. project costs dropping by orders of magnitude. Frankly, projects we could not get done before are getting done in a fraction the time with Distrix. Very small footprint and best of all no need to adhere to one vendors standard.
Posted By: B. 7/22/2010 at 4:18:01 PM
Excellent Read
Very interesting and informative article. Great Work!!
Posted By: R. 7/24/2010 at 10:15:06 AM
Thanks
Thank you, everyone, for your valuable comments. My viewpoint here is that embedded middleware helps speed up the deployment and offers low cost, however when a lot of scalability and flexibility in processing logic is desirable, then a server based middleware is the way to go. It also enables the organization to not become vendor-dependent.
Posted By: M. Shridhar 7/31/2010 at 8:26:38 AM