RFID Middleware - Smart Devices?
For any organization to adopt RFID (radio frequency identification), the biggest challenge is to integrate their existing enterprise applications with the data collected from RFID devices. Neither do these applications have the capability to hold and process EPC data, nor do they have the capability to communicate with devices and hardware. While the first issue of holding and processing EPC information is something that I've addressed in my white paper here, this blog is targeted towards discussing the issue of integrating enterprise applications with devices.
This purpose of integrating existing legacy applications with RFID is enabled by deploying a thin piece of software called as the RFID middleware. Simply put, the job of the RFID middleware is to collect data from RFID devices, eliminate duplicate or junk data, convert the data to a format which the enterprise application understands, and feed the data to the enterprise application.
The market for RFID middleware has been tapped by many players in the space, though it is dominated by product vendors who consider their RFID middleware as an excuse to sell more licenses of their existing products by making it dependent on their application servers, web servers, database servers, so on and so forth. Device vendors realized this to be a challenge for enterprises in terms of cost, and came up with an alternative - provide an embedded version of the middleware on the firmware of the device itself (making it a "smart" device) and let it communicate with enterprise applications directly. But is this a favourable approach?
There are several returns of having an embedded RFID middleware, e.g., it reduces the TCO (total cost of ownership) because it is not dependent on any other licensed products like application-servers or databases. However, are there several drawbacks as well, for example, it over-burdens the device with additional processing responsibility, it doesn't allow filtering of duplicate data to be done across devices (since a middleware instance is specific to a device and can't access data from another device), and most importantly, it increases the dependency of the organization on the vendor - which is not a scalable strategy in the long run, especially for an enterprise which spans across multiple geographical locations, in each of which the vendor might not have presence and customer-support.
Therefore, a more recommended approach is to use an RFID middleware which brings about the best of both worlds - the processing capabilities of a server-based RFID middleware and the low-cost, light-weight behaviour of an embedded middleware.
I've done more in-depth analysis of this in a technical view-point which was published on RFID Journal under "RFID Expert Views", accessible here. It provides more insights into some of the unforeseen challenges that an embedded RFID middleware on a "smart" device might bring about for an enterprise. If you have any thoughts to share on this topic, I'd be glad to take your comments on the same.