The Middle Kingdom – From Wired to Wireless


Abstract needed here…


Middleware is the bridge between one world and the other. Middleware for 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, bi-directionally from the device layer to the business applications, or out to the communications infrastructure, to the web or satellites (figure 1).

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.[1] 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.

Figure 2
(Click on image to view larger)


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 MO 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 ok 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 Gen 2 standards, which allow for a large amount of security, using ONS to create a bi-directional 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 ackage, 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).


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 a key here. This is another group of really smart algorithms.


Isolating and identifying, this is the core of RFIDs’ value. Integrating the physical (sensing) world to the digital world, in all its manifestations—light, sound, vibration, smell (which need 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.

Figure 3

In addition, this kind of information is broad-based, from merchandizing/demand management, as well as transportation trace and track, as well as item level intelligence leverage. (Figure 4).

Middleware also assigns data, serial numbers, etc., and at some point, when the chip sizes are larger, a whole host of other information. On active tags today, there is a lot of data written to the devices, from customer coded PDAs and readers, as well as very sophisticated middleware that also acts as a true RFID application (Savi, is the key player here.) When you see the proliferation of information that users want, either in the system or on the tag, you see the footprint growing in middleware application.

So I (as well as probably you, at this point) am a bit curious as to why RFID Middleware is not a truly hot category. If so many people want to subscribe to the data, and it provides a unique capability, why is this stuff not flying off the shelf?

The reality

Middleware developers have to be on a big accelerating path to design and develop the code to deal with these issues and many many more (too many to list here). Today, there are some pretty straightforward applications that do middleware, and then there are some that are, well, misnamed. The problem is (or the good news is) that they do very useful things. It’s just that calling it middleware, well, I have a problem with that. And ironically, some of the best middleware—you can’t really buy, unless you pass the right hurdles!

Middleware issues also include what they integrate. For example, are they an open standalone product that can basically work amongst a variety of applications, or are they embedded within business applications, exclusively? Some of the warehouse and logistics solutions have these middlewares. Let’s face it; they were doing data collection before it was hot! And adding new devices is all part of the game. However, the standard thinking in business circles is heterogeneous or agnostic approaches— integration to any platform, and global in its ability. So, thinking through the delivery architecture is critical here. You never know where a device will be popping up—and whose device it will be!

So let’s look at the most interesting solutions out there. In alphabetical order, please….


-DataPass. This is one of the best solutions in the market today. There are many implementations of this software, probably more installations than the others on this list. Their customer list to use this middleware is exclusively SAP. And ‘Aye’, there is the rub! (Sorry, Oracle users.) Acsis is adept at integrating to most devices as well as process control (SCADA, MES, WMS systems etc.), so whatever the data collection layers are, they can grab the data, make sense out of it, and parse it to the right subscriber, as well as instruct these layers.


RFTagAware suite of products. If you buy RFID middleware from BEA, you are getting the RFTagAware (there is a product that is begging for a new name!). ConnecTerra sells through channels, embedding their software in others’ solutions. Again, direct access is difficult, if you can get it. Again, no direct sales force. ConnecTerra’s basic strategy is an OEM network, where you can get its technology through partnerships. So major EAI or application network vendors embed RFTagAware within their stack of products. Most notable is BEA Systems and Yantra (now owned by Sterling Commerce).

ConnecTerra also views the world as a centralized platform on the web. This is ok for some applications, but after implementing so many merchandising systems, warehouse and yard applications throughout the world, with a variety of sometimes not so good network connectivity outside the 4 walls (and inside, too), I just can’t imaging getting the kind of response times required in today’s high performance business applications! Beyond Gen2 RFID, I am not sure if they can absorb the entire device community. Youth means lack of experience, but there are new architectural approaches—born out of the MIT Auto ID center. Here is their dedication to EPCglobal and participation in standards efforts. So, if you are looking for strict adherence to the ARC committee work, they are able to build this right in.


imotion Edgeware Platform. Beautiful to look at, GlobeRanger is the master of work flow. Remember, we talked about devices popping up everywhere and using RFID as both art and science. Those of us who have implemented RFID know that it is a challenge to understand the design and testing of the physical arrangements, and then to manage the processes to accommodate the physics of RF waves. Here is the imotion user layer of workflow that can allow you to model in software what would have happened on the physical layer. GlobeRanger also has both local and centralized tiered implementation approaches. This is smart, since it addresses the local performance issues, as well as the inter-enterprise visibility.
Again, we have a big focus on channel strategy! So, if you are interested in this software, call them!


(Sybase) RFIDAnyWhere. Here we have lots of great experience with mobile devices—Customer service and repair and migration into the RFID world. So this is interesting, since the issues of device to device communications should be addressed. Rich applications on the PDA, and then instruction to the tag can happen locally.


RFID Premises Server (part of the Websphere Application Server). IBM is throwing big money into getting this together. Device layer integration and pushing data up into their middleware applications. This is the same concept with BEA – a one vendor approach of all middleware. This is new. But with IBM, of course, you get IBM.


BizTalk. Microsoft is positioned well in this market. Microsoft already had mobile device integration for years, with the ubiquitous operating system presence (the one competitor to Palm). Also, Biz Talk has great item level, scalable cases in retail, such as Marks and Spence. Regardless of certain opinions, Microsoft has been the master of creating software for ever smaller platforms—right?

Oat Systems

Oat Foundation Systems. Oat as a middleware vendor strikes me as one of the vendors who is going down that road of application. Beyond the Capture, Filter Publish model, they message ‘Control’ as a prominent value prop of the application. What are the analytics associated with the movement of goods in the supply chain? What applying of context turns data into information? In addition, Oat addresses local storage of data. There is great data coming through the environment which I can use, locally, to improve operations that might not ever need to be published up to remote or legacy systems. Oat achieves this by in-memory data base, and then users can draw off information into reports or spread sheets to perform this analysis. Beyond that, RFID will create new types of data and analysis of business events. From observing Oat, I infer that they directionally have their heart in these new concepts.

Savi Technologies

SmartChain Middleware component is embedded within the overall Savi Smart Chain Solution. Savi proactively, long before the various standards groups got into the act, created a ‘universal adaptor’ so that readers could communicate to the software layers and out to the network. As the market interest migrated to EPCglobal standards, Savi (also a member of the MIT Auto ID Center) embedded the EPC components. So, whether your solutions are active or passive, four walls or on the ocean, you can get through the world.

Savi is also most progressive on the security layers required in the various layers. This is a huge challenge, which only the tough can tackle. But with Savi’s market (port and container security) they have the most interest. Savi also has been addressing the security layers required at every hand-off, device-to-device, from physical to digital. This is a huge challenge, which most of the middleware vendors have only contemplated. With RFIs being issued from Home Land Security and the Military, as well as other government agencies, ones mind races on security as a prime differentiator. Savi also delivers both local and global attributes (network data synchronization), so that the goal of local performance (but with global integration) can be achieved.

What Else?

Middleware does not equate to successful integration. There is a lot more to consider. Environmental and infrastructure assessments, process mapping, etc., all need to be considered. For example, does the network in your facility, your campus, or your corporation scale to meet the performance goals? How do I deal with transaction sequentiality? What data should I isolate, identify, etc.?

This article is not designed to specifically address these issues. Frequently—and more than you could imagine—organizations think that once they buy middleware, the rest will take care of itself. But you still have to deal with these process, performance and technology issues to ensure successful integration.

The Future- Getting Light

I dream of a world where we are all united! And I am not alone. So do many other business executives, based on the research recently done by ChainLink.

Figure 4

With RFID usage on the rise, the introduction of Internet Protocol V6, and more and more cell phones and other personal devices on the rise, things are going to get really fascinating. Millions of devices all over the world—in your home, your refrigeration, your kitchen, in your supply chain, talking to your PDA, talking in the stores, PSA (personal sales assistants)—all talking to RFID. So much talking-talking-talking—and on the move—Walking and Talking! We expect that in the future many of the functions of RFID Middleware will be embedded in the devices themselves. And more networks with both RFID aware event management and complimentary applications are to be born. We will—and are—having a real burst of light in creativity here!

All these approaches, protocols, etc., will just require a middle layer to make sense of it all! Filtering, adding context, etc.—all this will be critical. Yet, there are so many layers to security, and so many easy ways to out-fox the security, that we expect this will be a pernicious problem, which middleware will only have a modest role in solving.

Government regulatory thinkers are also out and about thinking of the downside of RFID and how we can avoid disaster in privacy. Will middleware be seen as a way to guard or block the aggregation of personal information? RFID is creating an explosion of data and an explosion of ideas. RFID, a resident of the physical world, needs a conduit to connect to the digital world. Surely, we will need a new and fresh way—some new applications—in this middle world!

[1] See Delivery Architecture article in last month’s Parallax View, as well as Demystifying ONS.

Scroll to Top