Resources Resources and their Identification

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 74 of 233 - New Sensor Data: Generated by a sensor or sensor system when the sensor acquires new data, e.g. new data is inserted into a Sensor Observation Service. - Service Trigger: Generated by a service orchestration environment in order to trigger other services, e.g. in service chains. - Service CreatedDeleted: Generated by a service in case of creation or deletion of a service. It may be used to trigger the harvesting of service capabilities. - Service Capabilities Updated: Generated by a service when the capabilities of a service have been changed. It may be used to trigger the harvesting of service capabilities. - Threshold Exceeded: Generated when a value has exceeded a given threshold. It may be used in environmental monitoring applications. - Sensor Battery Low: Generated when the remaining power of a sensor energy supply system e.g. a battery has fallen under a given level.

6.5. Resources and their Identification

6.5.1 Resources

In general, the SensorSA denotes by the term “resource” anything that‟s important enough to be referenced as a thing itself RichardsonRuby 2007. Examples of resources in the SensorSA may be sensors, functions possibly provided by means of services, data objects possibly but not necessarily modelled as feature types, views upon data objects or descriptions of data objects or services capabilities. The SensorSA focuses on a service-centric computing paradigm and puts the services and their interfaces into the foreground. However, these services access and manipulate underlying resources with quite complex schemas e.g. the elements of the observation and measurement model described in section 7.2. Typically, these resources provide views subsets upon data sources driven by the needs of the user. The effects of the service operations heavily depend on the meaning and the status of the underlying resources that are selected by the caller of an operation when setting the operation parameters. An alternate paradigm would be to focus upon these resources and their representations when defining a service platform. This approach is followed by the resource-oriented architecture ROA realised by so-called RESTful Web services RichardsonRuby 2007. The SensorSA aims at conceptually linking a service-oriented and a resource-oriented view upon a sensor service network in order to gain flexibility. This approach follows the architectural principles of “technology independence”see section 4.1.3 and “component architecture independence” see section 4.1.5. The concept “resource” is covered in the SensorSA by considering the following aspects: - The identification of resources is defined below in sections 6.5.2 to 6.5.3. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 75 of 233 - A resource model that links basic concepts of a ROA to the concepts “service” and “interface” is defined in the Information Viewpoint in section 7.6.3. - A SANY RESTful Web Service platform is defined in the Technology Viewpoint in section 9.2.3.

6.5.2 URN Namespace for SANY Resources