Service Oriented Sensor Web
Xingchen Chu and Rajkumar Buyya
University of Melbourne, Australia
Presented by: Gerardo I. Simari
CMSC828P – Fall 2006
Professor Nick Roussopoulos
Department of Computer Science
University of Maryland College Park, USA
Introduction
• Current sensor nodes are more sophisticated in
terms of CPU, memory, and wireless transceiver.
• Sensor networks are long running systems that
consist of sensing nodes that work together to
collect data (light, temperature, images, etc).
• Common applications are real-time detection and
early warning systems (fires, tsunamis,
earthquakes).
• The challenge: collection and analysis of information
from heterogeneous nodes.
Why is this a challenge?
• There is a lack of uniform operations and standard
representation for sensor data.
• There exists no means for resource reallocation and
resource sharing.
• Deployment and usage of resources is usually
tightly coupled with the specific location, application,
and devices employed.
• The Service Oriented Architecture (SOA) is an
approach to describe, discover, and invoke services
from heterogeneous platforms.
• Here, the term “service” is used both for software
and hardware.
SOA and Sensors
• Applying the idea of SOA to sensor networks
presents sensors as reusable resources which can
be discoverable, accessible, and even controlled
through the WWW.
• It also allows to link distributed resources in order to
create a sensor grid, enabling the advantages of a
computational grid.
• The main goal of the Sensor Web (SW) is to offer
reliable and accessible services to end users.
• The following figure illustrates an abstract vision of
the SW, a combination of SOA, grid computing, and
sensor networks.
Vision of the Sensor Web
Sensor Web Enablement
• A set of web-based services may be used to
maintain a registry of available sensors.
• The same web technology standard for describing
the sensors’ outputs, platforms, locations, and
control parameters should be used all across.
• This enables the necessary interoperability.
• The Open Geospatial Consortium (OGC) developed
the Sensor Web Enablement (SWE) standard.
• This standard encompasses specifications for
interfaces, protocols, and encodings that enable the
use of sensor data and services.
Sensor Web Enablement
• The following are the five specifications for SWE:
– Sensor Model Language (SensorML): Information
model and XML encodings.
– Observation and Measurement (O&M): Information
model and XML encodings.
– Sensor Collection Service (SCS): Service to fetch
observations; also uses SensorML to describe sensor
platforms.
– Sensor Planning Service (SPS): Helps users build
feasible sensor collection plans, and schedule
requests for sensor platforms.
– Web Notification Service (WNS): Manages client
sessions and notifies about outcomes of requests.
Sensor Web Enablement
SensorML
• SensorML is an XML encoding scheme that allows
clients to remotely use real-time data from webresident sensors.
• A standard format for sensor information enables
integration, analysis, and creation of data views
depending on the user.
• It also benefits the integration of heterogeneous
sensors and platforms, providing an integrated view.
• It describes the geometric, dynamic, and
observational features of sensors.
• The following figure shows the structure of the
Sensor Model Language (SensorML).
SensorML
Observation and Measurement
• O&M is another standard information model and
XML encoding.
• It is required for the Sensor Collection Service and
related components of the OGC SWE.
• The aim is towards defining terms used for
measurements, and the relationships between them.
• The following figure shows the basic observation
structure.
Observation and Measurement
SWE Services
• SWE defines several standard services that can be
used to collaborate with sensor networks.
• As we mentioned before, SWE contains three
service specifications:
– Sensor Collection Service (SCS)
– Sensor Planning Service (SPS)
– Web Notification Service (WNS)
• There are also two new services: Sensor Alarm
Service, and TransducerML.
• The paper only covers the basic three mentioned
above.
SWE Services (cont.)
• SCS is used to fetch observations from a sensor or
collection of sensors.
• It plays the role of intermediary agent between a
client and an observation repository or near realtime sensor channel.
• It responds to queries from the client with XML data
conformed to the O&M model.
• SPS provides a standard interface to handle asset
management (AM) that manages information
sources to meet the client’s goals.
• It plays a role of coordinator responsible for
evaluating the feasibility of the request and
submitting the query to the SCS.
SWE Services (cont.)
• The WNS is an asynchronous messaging service.
• Sending and receiving notifications are the main
responsibilities of the WNS, utilizing various
communication protocols (HTTP POST, email, SMS,
instant message, phone, fax, etc).
• Operations are defined to conduct both one-way
and two-way communication between users and
services.
Service Oriented Sensor Web
• Open Source Web Architecture (OSWA) is an SWE
compliant infrastructure for providing service
oriented access and management of sensors.
• It’s a platform for integrating sensor networks and
distributed computing platforms such as SOA.
• Among the benefits, the heavy information
processing load can be moved to backend
distributed systems such as grids.
• This can save a lot of energy in the sensor
networks, and accelerate the processing.
• Individual sensor networks can be linked together as
services.
High Level View of OSWA
The OSWA Platform
• Fundamental services are provided by low-level
components, whereas high-level components
provide tools for creating applications.
• The OSWA platform provides services such as:
–
–
–
–
–
Sensor notification, collection, and observation
Data collection, aggregation, and archive
Sensor coordination and data processing
Faulty sensor data correction and management
Sensor configuration and directory service
• The OSWA focuses on providing an interactive
development environment, a middleware and
coordination language for developing sensor apps.
A Prototype Instance of OSWA
Design and Implementation
• The primary design and implementation of OSWA
focuses on its core services (SCS, WNS, and SPS),
• The Sensory Repository Service is also key,
providing the persistent mechanism for sensor and
observation data.
• In the following figure, we show a typical client
collection request, and the invocations between
relating services.
• We will then discuss the design and implementation
of each of the core services in turn.
Invocation for Sensor Web Client
Sensor Collection Service
• SCS is one of the most important components
residing in the service layer.
• It is the only component that needs to communicate
directly with sensor networks.
• It is responsible for collecting sensing data and
translating the raw information into the XML
encoding so that other services can use it.
• The design of SCS provides an interface to both
streaming data (built on top of TinyOS) and query
based sensor applications (built on top of TinyDB).
• The following figure illustrates the architecture of the
SCS.
Sensor Collection Service
Sensor Planning Service
• SPS uses a rule engine which reads a set of rules
used to decide the feasibility of the plan made by
the user.
• Rules can be in many different languages.
• The most important component is the scheduler:
– It first composes the collection request and invokes
the SCS to get the observation.
– Asks the DataCollector to store the observation data
for later use by other clients.
– Sends notification to the WNS indicating the outcome
of the collection request.
• The following figure illustrates the architecture.
Sensor Planning Service
Web Notification Service
• The WNS contains two basic components:
AccountManager and Notification.
• The account manager stores data corresponding to
users who have registered with the service.
• The notification component creates and sends
messages, using various protocols, to users who
have registered.
• The following figure shows the WNS architecture.
Web Notification Service
Experimental Results
• The authors present a series of preliminary results.
• Although the services they implement all work
properly, the entire OSWA is not fully implemented.
• Many implementation issues are left as future work,
especially regarding the SCS.
• This central component needs to be reliable, have
good performance, and be scalable.
• The authors conclude that the SCS will greatly affect
the performance and reliability of the entire system.