RFID Middleware: Build vs. Buy

Early on in any IT project architects need to decide which software
products best solve their business problems. “Build versus Buy”, and if
“Buy” what are the best and most efficient products. In principal any IT
problem could be solved and coded using even Assemblers. In the early
90s, people used C/C++ for their early internet systems. Yes, no one
would even think about such choices anymore. We long have learned to
rely on Java, Web Servers, and Application Servers. They are geared
towards Internet problems and come with much functionality out of the box.

Looking at RFID business problems, it has not been so clear in the past.
Many existing systems are “Build” type solutions for which developers
use .Net or Java and are accessing RFID readers’ API directly, trying
to build a minimum level of infrastructure code to address some key
technical requirements. I bet there are thousands of those individual
“infrastructure” implementations being used right now. Some of them
present an enormous maintenance burden.

What are our key requirements for RFID platforms products? Surely, they
have to address connectivity to RFID readers, also sensors if possible.
Data come in real time, often in volumes that are not predictable in a
reliable way. RFID data are basically read events that need to be
filtered and transformed into business events. This is similar to
processing requirements of high volume financial systems. Credit card
processing systems that obtain a high volume of events need to correlate
such basic events into business events and trigger actions. RFID systems
are inherently event-driven. They can very much benefit from
event-processing engines such as Esper. Those systems allow to filter
and process RFID events in memory and in real-time. They provide event
correlation, for easy detection of business events from low-level RFID
events. Esper, for instance, provides time-based queries, making it easy
to detect for example if an item has been in a zone for too long.

Another key requirement is based on the light-weight environments we
typically want to build. RFID systems are on the edge on the enterprise,
and as such need to run and perform on inexpensive hardware. Heavy
application server architectures are a fundamentally wrong approach. The
IT industry recognized this problem several years ago and defined OSGi
as a common standard for such appliances. It is being used in
refrigerators, and many day-to-day appliances that are produced in high
volumes; a nice, light-weight and flexible industry standard that avoids
the burden of for example having to run application servers on a small
appliance.

In summary, requirements for RFID platform products being used for IT
projects have many clear and common characteristics. Sufficient and
appropriate RFID Reader adapters, being able to handle high volumes of
load, event processing engines are some key criteria. In addition, the
product needs to be open enough so developers can use their trusted
development environments. A last, but very important criteria is the
light-weight approach that RFID systems and appliances can use in order
to keep hardware cost to a minimum. After all, appliances should run on
the edge of the enterprise, easy to maintain, and with low hardware
costs, but in high volumes. RFID systems that meet those requirements
will help the industry advance and become standard software. No need to
build your own RFID platform anymore.