Download
1 / 28
280 likes | 408 Views
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.
E N D
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 accessibleservices to end users. • The following figure illustrates an abstract vision of the SW, a combination of SOA, grid computing, and sensor networks.
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.
SensorML • SensorML is an XML encoding scheme that allows clients to remotely use real-time data from web-resident 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).
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.
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 real-time 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.
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.
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.
Sensor Collection Service • SCS is one of the most important components residing in the service layer. • It is the only component that needs to communicatedirectly 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 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.
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.
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.
