Edge Server Architecture - Revision history

Redfern3141: Undo revision 5885 by StevenCollins (talk) - Removing advertising and spam edits

2014-06-30T22:10:00Z

Undo revision 5885 by StevenCollins (talk) - Removing advertising and spam edits

Matt: /* Core Bundles */

2012-01-12T23:53:28Z

‎Core Bundles

StevenCollins at 19:08, 24 November 2011

2011-11-24T19:08:29Z

Seoagent: /* OSGi */

2011-11-01T04:55:02Z

‎OSGi

Seoagent: /* Communication Layer */

2011-11-01T04:54:07Z

‎Communication Layer

Matt: Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

2010-11-26T19:43:06Z

Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

Show changes

Amesycyxa at 23:15, 23 November 2010

2010-11-23T23:15:46Z

Show changes

Kyle: /* Layers */

2009-10-14T16:05:33Z

‎Layers

Kyle: /* Sensor Abstraction Layer */

2009-09-30T15:34:51Z

‎Sensor Abstraction Layer

Kyle: /* Bundles */

2009-09-24T21:19:51Z

‎Bundles

@@ Line 11: / Line 11: @@
 ===Application Engine 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 <span class="plainlinks">[http://www.shoppharmacycounter.com/t-Adipex-Medicine.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">what is adipex</span>] reads the sensor produces.
+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:
@@ Line 20: / Line 20: @@
 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 Application Engine Layer is intended to let application <span class="plainlinks">[http://www.supplementstoweightloss.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">weight loss pills</span>] developers build much of the functionality of their RFID applications using esper queries.
+The Application Engine Layer is intended to let application developers build much of the functionality of their RFID applications using esper queries.
 ===Communication Layer===

@@ Line 160: / Line 160: @@
 ;org.rifidi.edge.console
 : Provides the ability to control the edge server using the OSGi console provided by eclipse equinox.  For more information about how to control the console, see [[Edge_Server_Console]].
-;org.rifidi.edge.core
+;org.rifidi.edge
-: Provides configuration & persistence, Management of reader and command configurations, Abstract classes and interfaces for sensor plugins to implement, and Esper,
-;org.rifidi.edge.core.rmi.server
-: Exposes core functionality via RMI for outside clients (especially UIs) to use to control the edge server.  It exposes roughly the same functionality as the console. For more information about how to expose a service using RMI see: [[How to export a service using RMI]]
-;org.rifidi.edge.core.services
 : Contains the interfaces for several OSGi services used within the edge sever
 ;org.rifidi.edge.core.jms

@@ Line 11: / Line 11: @@
 ===Application Engine 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.
+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 <span class="plainlinks">[http://www.shoppharmacycounter.com/t-Adipex-Medicine.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">what is adipex</span>] 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:
@@ Line 20: / Line 20: @@
 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 Application Engine Layer is intended to let application developers build much of the functionality of their RFID applications using esper queries.
+The Application Engine Layer is intended to let application <span class="plainlinks">[http://www.supplementstoweightloss.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">weight loss pills</span>] developers build much of the functionality of their RFID applications using esper queries.
 ===Communication Layer===

@@ Line 29: / Line 29: @@
 ==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 deployment unit (called a bundle), which is a <span class="plainlinks">[http://www.premier-football.net<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> soccer jersey store</span>] 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.
+# A lightweight runtime that allows bundle lifecycle to be controlled.  In other words, you can start, stop, and update bundles at <span class="plainlinks">[http://thepartyhub.com/Showcase<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> party artists</span>] 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 runtime provides a <span class="plainlinks">[http://thepartyhub.com/<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> event planners singapore</span>] 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.

@@ Line 23: / Line 23: @@
 ===Communication 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.
+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 <span class="plainlinks">[http://physioactive.sg/<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> massage therapy singapore</span>] database, others might want it to be pushed into an ERP system like SAP or handed to a <span class="plainlinks">[http://www.inleds.com/products/?cid=2<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> led downlight singapore</span>] 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.
+In addition, the edge server also provides a <span class="plainlinks">[http://www.inleds.com/<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;"> singapore led lighting</span>] built-in web container and MVC framework so that web applications can be deployed directly.
 ==OSGi==

@@ Line 8: / Line 8: @@
 ===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.
+The purpose of the edge server is to connect to any kind of sensors (e.g. RFID readers, Barcode readers, Mobile Devices) and collect 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===

@@ Line 155: / Line 155: @@
 *<tt>setLoggingLevel(String loggerName, String level)</tt> - Change the logging level of the logger (class or package name) to the given logging level.
-=Bundles=
+=Core Bundles=
-==org.rifidi.edge.api==
+The edge server is deployed as a set of OSGi bundles.  The following bundles make up the core.
-==org.rifidi.edge.console==
+;org.rifidi.edge.api
-==org.rifidi.edge.core==
+: Provides core classes that are necessary for an outside UI to talk to the edge server via RMI and JMS, such as Data Transfer Objects (DTOs), JMS Notification Messages, RMI Interfaces, and Tag Messages.
-==org.rifidi.edge.core.rmi.server==
+;org.rifidi.edge.console
-==org.rifidi.edge.core.services==
+: Provides the ability to control the edge server using the OSGi console provided by eclipse equinox.  For more information about how to control the console, see [[Edge_Server_Console]].
-==org.rifidi.edge.core.jms==
+;org.rifidi.edge.core
-==org.rifidi.edge.core.services.logging==
+: Provides configuration & persistence, Management of reader and command configurations, Abstract classes and interfaces for sensor plugins to implement, and Esper,
-==org.rifidi.edge.core.services.notifications==
+;org.rifidi.edge.core.rmi.server
 =Important Dependencies=