1.5.1Overview of the SCMW API
The SCCGMMS Application Program Interface (API) allows any third party application to connect and utilize functions provided by SCMW. An application can do the following through the SCMW API:
1. Obtains the policies and data of all sensors which are currently up and running 2. Selectively subscribes to sensors with their policies fulfilling filtering criteria defined
by the application
3. Sends control messages to sensors
4. Dynamically notified for new sensors which fulfill the filtering criteria, and for sensors which have been disconnected
To use the SCMW API, an application has to instantiates an Application Client Broker (ClientGridBroker) and implements the Sensor Change Listener (ClientGridChangeListener) interface. Moreover, a Sensor Data Listener (ClientGridDataListener) has to be created for subscribing to data stream of each sensor.
Figure 3-36 SCMW Application Programming Interface
Sensor Service Abstraction Layer (SSAL)
1.5.2 Overall Sensor Service Abstraction Layer Architecture
Figure 3-37 A high-level architecture of the Sensor Service Abstractioon Layer (SSAL)
Sensor Service Abstraction Layer (SSAL) provides a common interface for all kinds of sensors. Sensor developers add new sensors to SCMW by writing Sensor Client Programs (SCP)
which connects to SCMW through libraries in SSAL.
Internally, SSAL communicates with GB for sensor management (e.g. creation, registration, definition) and SG for run-time management (e.g. data publishing, receiving control messages). In SSAL, sensors are categorized into two categories:
Normal Sensors – Sensors which take input from external environment. The input data is external to SCMW.
Computational Service – Sensors which do not take input from the environment. Instead, they take output of other sensors as input, perform various computations on the data, and output the processed data finally
Functionalities of the two different categories of sensors are supported by two different sets of classes in SSAL. Some classes are shared between the two categories for common functionalities.
1.5.3 SSAL Architecture for General Sensor Services
star t control r---- Sensor Control sto p dat a Sens or Adap ter --- 1 I I I Management Console Listen
er Sensor listenerAdapter
Servic e Adapt er Stop creat e Sensor Manager Control messages Stop-4---- -'=1 I Sensor Client Adapt er data---
Get policy, initialize
I I
: ud ---
Sensor Grid
Figure 3-38 A detailed SSAL architecture for gmeral sensor sercvices Figme 3-38 shows the architectme of SSAL for general sensors to be wrapped and deployed as sensor services. The following subsections explain the message flow for some basic operations.
1.5.3.1 Sensor Deployment
To deploy a sensor, the corresponding SCP has to instantiate a Sensor Adapter which notifies SCMW for its presence and data publishing. It also has to implement a Sensor Control Listener (for receiving control messages) and a Sensor Adapter Listener (for actions such as terminating SCP). The SCP can either be started by a way decided by the sensor developer (e.g. run a .bat script), or it can be embedded in SCMW so that it can be started by GB’s Management Console. For a more detailed message flow, please refer to section 3.3.5 .
1.5.3.2 Data Publishing
SCP is responsible for collecting data from the sensor, and then publishes it through Sensor Adapter. Sensor Adapter in turn forwards the data to the corresponding Sensor Service Adapter, and finally to all applications that have subscribed to its data through SXO. For a more detailed message flow, please refer to section 3.4.4.5 .
1.5.3.3 Performing Actions on Sensor Client Program
Sometimes the user may want to perform some actions remotely on the SCP, such as pausing or terminating the SCP. SCP listens for these actions through Sensor Adapter Listener. Currently, there is only one action supported by SCMW – terminating the SCP.
1.5.4 SSAL Architecture for Computation as a Sensor Service
Figure 3-39 A detailed SSAL architecture for computation as a sensor service
Architecturally SSAL for Computational Service combines SSAL for normal sensors and SCMW API since it needs functionalities from both sides. Figure 3-39 shows SSAL for Computational Service. You can observe that components of the SCMW API are integrated with components of the original SSAL and some new modules to form the
SSAL for Computation as a Sensor Service. The extension of SSAL to cover computation as a sensor service significantly broadens the applicability of the Sensor- Centric Grid of Grids and eases the integration of new or legacy system of systems with sensor-centric applications.
The following subsections explain the message flow for some operations of Computational Services.
1.5.4.1 Sensor Deployment
To deploy a Computational Service, the corresponding SCP has to instantiate a Sensor Client Adapter which notifies SCMW for its presence and for various sensor related operations such as data publishing, subscribing data from source sensors and sending control messages to source sensors. It also has to implement a Sensor Control Listener (for receiving control messages) and a Sensor Adapter Listener (for actions such as terminating SCP) as what normal sensors do.
1.5.4.2 Subscribe Sensor Data
Since Computational Services take input from other sensors (source sensor), they have to subscribe data from other sensors in a similar way to applications. To subscribe data, the SCP of a Computational Service has to invoke functions of Sensor Client Adapter which in turn setup the connections through SXO. SCP has to implement the Sensor Change Listener and Sensor Data Listener interfaces. Whenever the state of source sensor changes (e.g. online to offline) the SCP will be notified through Sensor Change Listener. Similarly SCP will be notified for data arrival through Sensor Data Listener.