Dataflow and the Rifidi Edge Server

This is the first in a series of blog posts that give a technical overview of the architecture of the Rifidi Edge Server.

The most basic (and important) function of the Rifidi Edge Server is to collect data from sensors, filter them, and deliver them to systems that use the data for business processes.  This diagram gives a high-level depiction of how data are collected and flow through the edge server.  The data begin their journey as they are produced by sensors.  While these sensors are normally hardware RFID readers, such as an Alien 9800, Symbol XR400, etc, data might also be produced by a legacy barcode reader, a database, or even another edge server.  The Sensor Abstraction Layer provides a way for users to develop their own plugins for their custom sensors.

As data are collected from the sensors, they are pumped into a high speed internal message bus through which other internal edge server components can access them.  Because sensors have the ability to produce an enormous number of events, users normally want to filter them.  The Application Layer Events (ALE) specification from EPCglobal provides a standard API for collecting and filtering RFID data.  The Rifidi Edge Server has an implementation of the ALE 1.1 specification.  Internally, the ALE layer uses an event stream processor called Esper to collect data according to the ALE rules.

Some users will decide that they do not want to use ALE in their solution.  Because the Rifidi Edge Server is built on an extremely flexible architecture, they can create a custom data collection layer and hook it up directly to the internal message bus.

Future architecture posts will describe other aspects of the Rifidi Edge Server in more detail.

What’s in a Name?

Going into the RFID Journal Live trade show, I assumed that I had spent the past eight to ten months of my life developing an edge server — a piece of middleware that connects to RFID readers, collects data from them, filters the data, and pushes the data up to a higher level business application. Was I ever wrong. What I had actually been working on was an application platform. Talking to all the people at the trade show reminded me once again of just how general of a technology RFID is. Not only are there many classes of deployments (RTLS, inventory, supply chain, asset tracking, etc), but even within similar classes, deployments differ greatly depending on all kinds of variables — from the physical layout of a facility to the IT infrastructure that is already in place — that are unique to that situation.

Because there is no such thing as an off-the-shelf RFID deployment, middleware that is not completely malable is unuseful. This is why describing Rifidi Edge Server as simply an edge server is limiting; it implies that Rifidi Edge Server is a static piece of software. Describing it as an application platform, however, better captures how it will be used in practice. Much like JBoss is not so much an application server as it is a platform for building J2EE solutions, Rifidi Edge Server is more of a platform for constructing RFID applications rather than a solution in and of itself. In deployments, Rifidi Edge Server will be used as a core that provides a base set of tools and functionality that developers will tailor to their particular needs by writing extensions and plugins to it.

You might say that the difference between describing Rifidi Edge Server as an ‘edge server’ or as an ‘application platform’ is simply a marketing device. But to me, as a developer, it represents a fundamental difference in how I view the code. Before the show, I knew extensibility was a priority; now I know it is vital. With this refined viewpoint, I am looking forward to the next few months.