The Middle Kingdom - From Wired to Wireless

Middleware is the bridge between one world and the other. Middleware for radio frequency identification (RFID) bridges the worlds of waves (radio), light beams, and sensory (light temperature and vibration), to the hardwired world of servers, routers, Internet, and software systems. The Middle Kingdom is the world between the physical world and the digital world. And to add to the definition—middleware may span from the device to the edge (the border, and slightly over) of your kingdom. Mobile devices need bidirectional communications beyond the firewall.

So the challenge for middleware in this sense is to traverse the world of air to the hardwired, and from the event to the enterprise, and to the inter-enterprise world.

Sounds Easy, and Don't We Already Have Middleware?

Middleware here traverses multiple concepts, hardware device management and software, architecture for local application and for global applications, security, business process management, and adherence to standards, to name a few important issues!

Middleware of the past—EAI-application middleware has dealt with the intersection of software applications across platforms—in the enterprise, and then across enterprises. The word from middleware developers for RFID is that the traditional security protocol to the web is a different security to and at the device level.

RFID middleware has a critical role to play in cleaving together and clarifying the signals and intelligence, bidirectionally from the device layer to the business applications, or out to the communications infrastructure, to the web or satellites (figure 1).


Middleware becomes critical, due to the significantly increasing population of devices in the world. We also see an increase of privacy concerns by governments; the ability to provide some security in the system has to be addressed. Software becomes the means to do this. Like the cell phone accessing the network, the ability to identify and authenticate is critical. What's in? Device interface and management is in, through delivering the event information to a subscriber—the network or an execution application.

What's out? ChainLink does not include the network component within the middleware application, though clearly this component is critical to the overall success of the RFID enabled process.[] But generally the transaction occurs external to the enterprise. Work flow and developer tools are in, and are important, since they allow you to customize the application.

So let's explore a few key differentiators of RFID middleware.


Authentication is a key attribute. Once your device finds the network, the network identifies your unique ID (your number plus some magic on the chip in your cell phone) and allows you into the network—if you have paid your cell bills each month.

In the Internet world, approaches have been well designed. An approach to communicate/integrate (Secure Socket Layer) establishes a secure connection between the two systems by sending and receiving packets with keys that authenticate and validate the server, as well as the client. This method is the standard modus operandi for many pervasive approaches. So, some analysis (standard protocols) at the hub or central server takes place. Across applications and enterprises, the obvious question occurs, "Is she allowed to use our network?" So the IP address is critical here.

As the amount of devices in the enterprise increases to the millions, taxing of current approaches, it becomes apparent that more intelligence will be required somewhere in the RFID stack. Every device, every server has to store a bit of intelligence and code to allow secure communications. The challenge becomes get this just as you sign-up your cell phone (well, this is a time-consuming process). Want to go through that for every chip in the universe? The cell phone analogy works here, since everywhere you roam, the new connection needs to be established and authenticated through the central server. But on the client side (the cell phone side) most of us do not lock or password protect, so when the phone is on, it is okay to connect to the network. Now, unless you are dumped from the service, you have access to the world. Who's going to do this with millions of tags?

Part of the issue has been addressed with the generation 2 standards, which allow for a large amount of security, using ONS to create a bidirectional secure communication. However, the demands of these devices to respond extraordinarily quickly (in real time) will require local infrastructure and intelligence to perform most requirements of reading/writing, instructing, etc. If the goal is to gain really high read rates and performance of some simple functions (like isolate a unique package, ferret our expired products, re-route a high priority item), then there is no way that a centralized web approach can work. It just does not perform that quickly. Locally, we will just have to have a method to perform these functions. This will mean that devices will need security between each other; that local middleware installations of some kind will need to be in place. (More on that later.)

Filtering

Potentially, part of dealing with the explosion of devices that are always talking-talking-talking is the filtering capability. Above, we presented only a few of the security and performance problems associated with so many devices needing authentication. But, the reality is that not so many do, all the time. Getting the chatter boxes off the scene (technically speaking) is key here. This is another group of really smart algorithms.

Identification

Isolating and identifying, this is the core of RFID's value. Integrating the physical (sensing) world to the digital world, in all its manifestations—light, sound, vibration, smell (which needs security), through the air (which needs security), to other devices (which need security), and to networks (which need security).

Another factor is the need for heterogeneous identification and integration—device independent, as well. We need some standards here, Houston! (or is it Washington?) I always feel frustrated by the limited discussions of RFID and related technologies when people call this barcodes on steroids'. There is already a world of EDI/scan data standards out there. How will middleware logic integrate and interpret to the miniature sensing devices, and interpret smell, spoilage, etc? There is huge power in the physical/sensing attributes of this technology—yet to be developed.

All this is pretty cool stuff. And somewhere in your RFID stack all this work will need to get done. Ironically, the middleware applications in the market don't necessarily do all of this. (We will talk about that soon.)

What Will Business Do with The Data?

ChainLink has done a tremendous amount of research in this area, and it is clear that the business community wants to—expects to—not only leverage auto-identification data, but also share it with trading partners.


SOURCE:
http://www.technologyevaluation.com/research/articles/the-middle-kingdom-from-wired-to-wireless-18152/