## 3 M2M Information and Services
### Sensor Web Enablement
SES uses the OASIS WS-Notification (WS-N) standard for the definition of the service operations needed for a publish/subscribe communication. This suite of standards defines operations for subscription handling and notifications (WS-BaseNotification), for the brokering of notifications (WS-BrokeredNotification) and for the use of event channels (WS-Topics). Event channels allow a grouping of notifications with respect to a specific topic, for instance weather forecasts. Instead of defining the filter for forecasts in each consumer's subscription, a consumer can simply subscribe for all notifications on the weather channel. Consumers may also use filter criteria while subscribing to sensor data. Depending on the filter type used these criteria operate on single observations or on observation streams, potentially aggregating observations into higher-level information (which itself can be regarded as observation data). Figure 3: SWE Service Model. Figure 2: Sensor web enablement (SWE) common. Sensor Instance Registry (SIR) provides functionality to collect, manages, transform and transfer sensor metadata through SensorML as well as extended discovery functionality and sensor status information. It is intended to close the gap between the SensorML based SWE world and conventional Spatial Data Infrastructures (SDIs). In the future it is expected that the functionality of the SIR interface will partly be covered by other existing SWE services (e.g., SOS for retrieving sensor status information and the SES for filtering sensor status updates). Sensor Observable Registry (SOR) is designed in order to support users when dealing with identifiers pointing to phenomenon observed by a sensor (observable) which is very important when searching for sensors. Usually such parameters are expressed within SensorML documents through some kind of identifier (_i.e._, URIs). Figure 4 depicts two scenarios where the SWE architecture is in action: sensors without embedded IP stack, and sensors with embedded IP stack. The scenarios have been simplified in order to clarify the basic idea. More details can be found in the standards specifications and the SWE white papers. SWE is a standard M2M architecture that focuses primarily on the requirements of the scientific community dealing with remote sensor and sensor data management. Certain features of the SWE architecture pose a barrier for its widespread adoption for this purpose. For example, the complexity of the SOAP based SWE service interface specification and other extension specifications (e.g., OASIS WS-Notification, _etc._) are one of these barriers. Future versions add a lightweight HTTP GET binding for certain operations with the aim of improving ease of adoption. Another issue is the tight coupling of the information model with GML which binds spatial data infrastructure across all data ubiquitously. While this feature makes it easy to relate sensor data with other spatial-temporal resources (e.g., maps, raster as well as vector data) at the application level, this is not a requirement in all M2M scenarios. However, adaptation of the SWE information model may provide useful solutions within the context of M2M service networks. Figure 4: SWE Architecture in action.