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.