Differences

This shows you the differences between two versions of the page.

--- sensorweaver [2014-12-17 13:57] – created, added developer guide draft toc luigi.fortunati
+++ sensorweaver [2017-09-26 07:08] (current) – michele
@@ Line 1: / Line 1: @@
-= SensorWeaver =
+===== SensorWeaver =====
 SensorWeaver is a suite of applications that enables application development in distributed sensor networks scenarios.
 It comprises:
-  * A Middleware Platform for secure communications between applications and sensor nodes
+  * A Middleware Platform for secure communications between applications and sensor network gateway nodes
   * Applications that leverage Middleware functionalities
 The software project is licensed with Apache V2 licensing.
-This page contains developers and administrators documentation on SensorWeaver components:
+This page collects developers and administrators documentation on SensorWeaver components.
-== SensorWeaver Middleware ==
+===== Middleware =====
-TODO: Report functionalities and system architecture here.
+Wireless Sensor networks are often heterogeneous in terms of communication technologies and protocols and cover a limited spatial area. Applications that use sensor data needs are often run remotely and require a secure communication channel in order to access it over the Internet.
+SensorWeaver Middleware tries to address the aforementioned issues by offering simple abstractions and API to clients and a distributed platform for secure communication between sensor nodes and applications that use context data.
-=== Developer Guide ===
+{{ ::componentdiagram.jpg|Sample deployment diagram depicting a scenario with ZigBee devices integration}}
-  * Project and development environment setup
-    * IDE setup and repositories
-    * Project setup
-    * OSGi container of choice: Karaf
-  * Getting an instance of the Middleware service
-    * OSGI Registry
-    * Blueprint
-  * API
-    * Publishing sensor data
-    * Getting sensor data
-  * Integration testing
-    * Pax-Exam
-    * Karaf
-  * Links
-    * OSGi specs and compendium
-    * Blueprint Aries
-    * MQTT Protocol
-=== Administrator Guide ===
+The functionalities offered by the Middleware are based on the simple //datafeed// and //service// abstractions. A //datafeed// generally identifies an entity that produces data and can be characterized with a set of properties and a message content definition.
+There are two areas of functionalities concerning the datafeeds, one for data publishers and one for data consumers:
+  * Datafeed publishing and sensor data dissemination
+    * Announce the presence of a new datafeed by providing a description in terms of sensor properties and message format
+    * Announce unavailability of a datafeed
+    * Publish data for a published datafeed, using the defined message format
+  * Datafeed discovery and data listening
+    * Discover datafeeds matching a set of properties
+    * Listening for data produced by a datafeed
+Regarding the services, the following functionalities for both the publishers and the consumers are provided:
+  * Service publishing
+    * Announce the presence of a new service by providing a description of the properties, request message format and response message format
+    * Announce unavailability of a service
+    * Reply to a service invocation from a client
+  * Service discovery and invocation
+    * Discover services matching a set of properties
+    * Invoking a service and receiving a response
+Any data source can be represented as a //data feed// on the middleware, enabling a sensor data fusion scenario.
+The deployment diagram depicts a scenario where ZigBee devices are integrated with the Middleware.
+In this case a Gateway computing node runs an OSGi container with several components. The //Sensor publisher// component realizes the integration layer by relying on a technology specific software stack (ZB4O for ZigBee sensor networks) in order to access the sensor network. The stack uses a physical dongle in order to access the ZigBee network. //Sensor publisher// monitors the status of the sensor network and, for each discovered sensor, publishes the availability and generated sensor data on the //Middleware//.
+The //Middleware// relies on MQTT communications in order to propagate information to interested nodes in a distributed environment.
+//Applications// running on other physical nodes can be notified in real time about the availability of new data sources and listen to data generated by those.
+The Middleware does not offer off-the-shelf integration layers for specific sensor communication technologies (Bluetooth, ZigBee, Z-Wave, etc.) or virtual sensor representations ([[https://github.com/osgi/design/raw/master/rfcs/rfc0196/rfc-0196-DeviceAbstractionLayer.pdf|OSGi rfc0196]], [[http://zb4osgi.aaloa.org/|ZB4O]], etc.).
+Main characteristics:
+  * Runs on Java and OSGi execution environment
+  * Leverage MQTT publish/subscribe messaging protocol on the lower level
+  * Underlying publish/subscribe communication paradigm based of MQTT protocol
+  * based on modern IoT communication protocol on the lower level: MQTT
+  * Provides secure communication channels
+  * Offers a simple model for the description/discovery of data sources
+  * Strives for simplicity of integration
+Links to guides:
+  *[[sensorweaver:developer-guide|SensorWeaver Developer Guide]]
+  *[[sensorweaver:admin-guide|SensorWeaver Administrator Guide]]
+  *[[sensorweaver:sensor-feeds|SensorWeaver The Sensor Feeds]]