Edge Server Architecture
From RifidiWiki
This page describes several aspects of the Rifidi Edge Server Core. It is intended for developers to understand how the core is structured.
Contents
Overview
There are two main aspects to understanding the edge server. The first is the three architectural layers that facilitate the flow of data from sensor to a designated endpoint. The second is the runtime and how it uses service oriented architecture and OSGi to be dynamic and light weight.
Layers
This section shows the three conceptual architectural layers that data passes through on its journey from sensors to whatever endpoint the user chooses.
Sensor Abstraction Layer
The purpose of the edge server is to connect to any kind of sensors (e.g. RFID readers, Barcode readers, Mobile Devices) and collect ID information from them. In many scenarios, this consists of connecting to a Gen2 fixed reader (such as Alien 9800, Motorolla LLRP, etc), and collecting EPC information. However, the edge server is designed in a way so that the edge server to collect many kinds of data (active, passive, etc) from many kinds of devices. This layer allows users to connect to devices in a sensor-agnostic way to collect the kind of data required for the application.
Complex Event Processing Layer
For most applications it is not desirable to save every event that the sensors produce. Many sensors can send 1,000 of events a second, a large number of which might be duplicates. Most applications are interested in events that are one-level higher than the raw events produced by sensors. For examples, an ERP system is probably interested in the event of a box arriving in area 1, and it is not desirable for the ERP system to do the work of filtering and processing all of duplicate reads the sensor produces.
Complex Event Processing (CEP) is a paradigm of viewing data as ephemeral events (an event stream) and identifying meaningful (i.e. business) events from the stream
Acquisition Layer
OSGi
OSGi is a dynamic modules system for Java. It provides several pieces of functionality including the following:
- A deployment unit (called a bundle), which is a normal JAR with some extra information in the Manifest.
- A lightweight runtime that allows bundle lifecycle to be controlled. In other words, you can start, stop, and update bundles at runtime.
- Dependencies are explicitly stated in the Manifest either as "bundle dependencies" or "package dependencies".
- Classes are only visible to other bundles if their containing packages have been exposed. This allows developers to hide classes that should be strictly internal.
- The runtime provides a service registry -- a system-wide repository for bundles to provide functionality.
The edge server is simply a collection of bundles that run in an OSGi environment (Equinox). Functionality between bundles is shared by means of services that are available in the service registry. Because bundles can be started and stopped while the rest of the server is still running, we can update non-essential parts of the edge server without restarting it.
