## 2 Related Work on Bridging Between Sensors and Applications
### Middleware for Sensor Web Infrastructures  
This class comprises middleware solutions which are particularly designed for making sensors available on the Web and enable the access to sensors from the application level by building up Sensor  
Figure 1: The Sensor Web layer stack and located middleware classes. Web infrastructures. The comprised approaches abstract from details of the sensor network and (usually) do not provide sensor network management functionality, such as the approaches described in Section 2.1. Some of the comprised middleware approaches make use of the SWE standards to offer interoperable access to sensors. Others define their own proprietary interfaces and data encodings. First, implementations of the SWE service specifications itself can be seen as part of this class. The 52 North Sensor Web framework (_[http://52 north.org/swe_](http://52 north.org/swe_)) provides implementations for the different SWE services. An implementation of the Sensor Observation Service (SOS; Section 3.3.2) enables querying as well as inserting measured sensor data and metadata. While the SOS follows a pull-based communication paradigm to access sensor data, the Sensor Alert Service (SAS) and its successor the Sensor Event Service (SES; Section 3.3.4) push sensor data to subscribed clients in case of user defined filter criteria. The Sensor Planning Service (SPS; Section 3.3.3) enables tasking of sensors (e.g., setting the sampling rate of a sensor). Discovery of sensors is supported by implementations of Sensor Instance Registry (SIR) and Sensor Observable Registry (SOR; Section 3.3.5). To integrate sensor resources with the SWE service implementations, the 52 North framework comprises an intermediary layer, called the Sensor Bus [29], to which sensor resources and SWE services can be adapted to establish communication. Other middleware systems for building Sensor Web infrastructures based on SWE are GeoSWIFT [30] and its successor GeoSWIFT 2.0 [31]. The latter redesign the GeoSWIFT system to optimize its scalability by introducing a peer-to-peer based spatial query framework. The PULSENet framework [32], which reuses and amends the open source components of the 52 North Sensor Web framework, allows the implementation of a SWE-based Sensor Web. An important aspect of the system is to accommodate legacy and proprietary sensors (e.g., IEEE 1451 or CCSI) in SWE-based architectures. NASA's Sensor Web 2.0 [33] system incorporates SWE services and combines them with Web 2.0 technology. It envisions an easy creation of mash-up applications which integrate data from multiple sources. This includes for example the creation of composite maps overlaying data from sensor sources with data from other sources such as weather or traffic. The mash-up functionality is realized by incorporating the representational state transfer (REST) approach [34] to access data. However, it remains unclear how the system provides REST access to sensor resources by leveraging SWE services. Non-standardized approaches for building a Sensor Web are for example Hourglass [13], the Global Sensor Network (GSN) [7], the Sensor Network Services Platform (SNSP) [35], or SOCRADES [36]. GSN focuses on a flexible integration of sensor networks to enable fast deployment of new sensors. Its central concept is the virtual sensor abstraction with XML-based deployment descriptors in combination with data access through plain SQL queries. GSN provides distributed querying, filtering, and aggregation of sensor data as well as the dynamic adaptation of a system during runtime. Similar to GSN is Hourglass, that provides an architecture for connecting sensors to applications. It offers discovery and data processing services and focuses on maintaining the quality of service of data streams. SNSP defines a set of service interfaces usable as an application programming interface for wireless sensor networks. Similar to the SWE framework, the approach follows a top down view on sensor networks independent of a particular implementation or hardware platform.