RFID middleware: what sits between the reader and the business system

01 / FIELD NOTE

Keep the decision tied to the operating context.

A reader in a busy read zone produces an enormous number of observations. The same tag is seen many times a second for as long as it is in the field, and a zone covering a pallet may report hundreds of tags at once. Passed upstream unchanged, that stream is unusable: the business system would receive thousands of records describing a single event, and would have to work out for itself which ones mattered.

Middleware is the layer that turns that stream into something a business system can act on. Its job is to decide what counts as an event, when an event has finished, and how it should be described to the systems downstream. Everything the reader reports is data; what middleware produces is meaning.

The conversion involves several distinct operations. Filtering removes observations the application does not care about, so a dock-door reader can be told to report pallet tags and ignore case tags. Aggregation collapses repeated observations of the same tag into one event with a duration rather than thousands with separate timestamps. Smoothing decides when a gap in reads means an item has gone rather than that a read was briefly missed, which is the difference between a report of a departure and a spurious alert. And translation converts the result into the format the receiving system expects.

This is separate from the conventional integration middleware that already exists in most organisations. Conventional middleware links applications — routing data between transport protocols, converting between formats, exposing services. RFID middleware sits in front of that, reducing a high-volume, ambiguous observation stream into discrete events, which the conventional layer then delivers.

The requirements a reader-facing layer has to meet are specific. It has to interface efficiently with databases, because it is handling far more records than a typical application. It has to integrate devices from different manufacturers — readers, printer-encoders, sensors — without the business system knowing which is which, because hardware changes over the life of a system while the integration should not. It has to be manageable centrally and remotely, since a site may have many readers and the people who can configure them are not always on site. And it has to connect to the enterprise applications that consume the data: warehouse management, enterprise resource planning, supply chain systems and the rest.

The interfaces between these layers are standardised. The EPCglobal community, which became part of GS1, defined a set of specifications covering the link between readers and the software that drives them. The low-level reader protocol defines the interface between a reader and the application driving it, and is described as low-level because it controls the reader directly rather than expressing business intent. The application level event standard works at the opposite end, converting raw observations into filtered reports of the kind an application can subscribe to. Alongside these sit specifications for reader discovery and configuration, and for managing a population of readers.

The practical consequence of standardised interfaces is that the business layer is insulated from hardware. A system that integrates against the event interface continues to work when a reader is replaced by a different model, provided the new reader supports the same protocols. That is worth having in a system expected to run for years, because the alternative is re-integrating the business layer every time the hardware is refreshed.

Where middleware sits in a given deployment is a design choice. Some readers do part of the work internally — filtering and aggregating before forwarding — which reduces what the middleware layer has to do but ties the behaviour to that device. A dedicated middleware layer keeps the logic in one place at the cost of another component to run and maintain. Which is preferable depends on how many readers there are, how consistent they need to behave, and who will maintain the system after the project team has gone.