Difference between revisions of "Edge Server Architecture"
From RifidiWiki
(→Core Services) |
(→Command Data Access Object) |
||
| Line 51: | Line 51: | ||
* <tt>AbstractSensorFactory getReaderFactoryByID()</tt> - Get the sensor factory with the supplied ID | * <tt>AbstractSensorFactory getReaderFactoryByID()</tt> - Get the sensor factory with the supplied ID | ||
===Command Data Access Object=== | ===Command Data Access Object=== | ||
| + | '''Purpose''': Provide access to command configurations that have been created.<br> | ||
| + | '''Interface''': <tt>org.rifidi.edge.core.daos.CommandDAO</tt><br> | ||
| + | '''Methods'''<br> | ||
| + | * <tt>Set<AbstractCommandConfiguration> getCommands()</tt> Get all available command configurations | ||
| + | * <tt>AbstractCommandConfiguration getCommandByID(String ID)</tt> - Get the command configuration with the supplied ID | ||
| + | * <tt>Set<AbstractCommandConfigurationFactory> getCommandFactories()</tt> - Get all registered command configuration factories | ||
| + | * <tt>AbstractCommandConfigurationFactory getCommandFactoryByID(String ID)</tt> - Get the command configuration factory with the supplied ID | ||
| + | * <tt>AbstractCommandConfigurationFactory getCommandFactoryByReaderID(String ID)</tt> - Get the command configuration factory with the supplied sensor ID | ||
| + | |||
===Configuration Service=== | ===Configuration Service=== | ||
===Sensor Management Service=== | ===Sensor Management Service=== | ||
Revision as of 18:59, 24 September 2009
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 using rules. Rifidi Edge Server uses a Complex Event Processor called Esper. It allows you to write queries using an SQL-like syntax:
select * from ReadCycle where ReaderID='gate_1'
One of the most important aspects of CEP is being able to use incorporate temporal knowledge into the queries. This allows you to phrase queries like "Send an order_complete event when an itemA event is followed by an itemb event" or "send an order_cancelled event when an itemb event is not seen within 10 min of a itemA event."
The Complex Event Processing Layer is intended to let application developers build much of the functionality of their RFID applications using esper queries.
Acquisition Layer
After data has been processed, it probably needs to be handed up to some kind of application-dependent system. For example, some users might want the data to be stored in an database, others might want it to be pushed into an ERP system like SAP or handed to a Rich User Interface of some sort. The edge server has several built in connectors to use, namely JMS and Web Services (via Spring's remoting framework). However, as this is application dependant, it is possible to write your own connector (such as a TCP/IP socket connection) if the application needs it.
In addition, the edge server also provides a built-in web container and MVC framework so that web applications can be deployed directly.
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.
Services
In the Edge Server, services are POJOs that provide a specific piece of functionality to other components and are registered in the OSGi Registry. For more information see How to use OSGi Services
Core Services
The following services are provided by the core bundle.
Reader Data Access Object
Purpose: Provide access to sensor configurations that have been created.
Interface: org.rifidi.edge.core.daos.ReaderDAO
Methods
- Set<AbstractSensor> getReaders() Get all available sensor configurations
- AbstractSensor getReaderByID(String ID) - Get the sensor with the supplied ID
- Set<AbstractSensorFactory> getReaderFactories() - Get all registered sensor factories
- AbstractSensorFactory getReaderFactoryByID() - Get the sensor factory with the supplied ID
Command Data Access Object
Purpose: Provide access to command configurations that have been created.
Interface: org.rifidi.edge.core.daos.CommandDAO
Methods
- Set<AbstractCommandConfiguration> getCommands() Get all available command configurations
- AbstractCommandConfiguration getCommandByID(String ID) - Get the command configuration with the supplied ID
- Set<AbstractCommandConfigurationFactory> getCommandFactories() - Get all registered command configuration factories
- AbstractCommandConfigurationFactory getCommandFactoryByID(String ID) - Get the command configuration factory with the supplied ID
- AbstractCommandConfigurationFactory getCommandFactoryByReaderID(String ID) - Get the command configuration factory with the supplied sensor ID
