SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 171 of 233
of RESTful Web Services.
-
Execution Context The execution context of the SensorSA RESTful Web Services Platform is defined by the
following properties: Transport Protocol and Message Format:
The HTTP POST, GET, PUT and DELETE methods are used to perform generic create, read, update and delete CRUD operations on resources.
Resources are addressed and uniquely identified using uniform resource identifiers URI. A POST, PUT or UPDATE request is typically XML-
encoded. In the case of a HTTP GET or DELETE request KVP encoding of parameters shall be used. The response shall either be an HTML, XML or binary
document for example an image or a string representing the URI of the resource upon which the operation has been performed. For example, in the case
of a PUT request the URI of a newly created resource shall be returned. In any case the format of the response has to be made transparent to the requestor, for
example with an interface description or in the capabilities document of the service. An XML response shall be described by a corresponding XML-Schema
e.g. the SensorML schema, a binary response by a MIME-Type e.g. imagepng.
Security The common security aspects of the different SensorSA Service Platforms are
discussed in section 9.3.1. The following aspects, however, are specific to the SensorSA W3C Web Services Platform:
Encryption: Optional transport-layer encryption of HTTP requests and responses shall be accomplished by SSL 3.0 Netscape, 1996.
-
Schema Language The general schema language used to define the SOA-RM Information Models is the
eXtensible Markup Language XML 1.0 XML, 2006. Section 9.3.2 will list further XML-based schema and modelling languages.
-
Information Model Constraints There are currently no immediate constraints on information models themselves.
9.3. Specification of Further Platform Properties
9.3.1 Selection of User Management, Authentication and Authorisation
Mechanisms
This topic comprises the specification of how security and access control mechanisms are intrinsically supported by the platform. The current draft of the SensorSA security model implies
that there could be a co-existence of different access control solutions. The platform
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 172 of 233
specification has to define whether the use of disparate implementations of security services and disparate communication channels for security related information are permitted.
9.3.2 Agreement on Data Formats and Application Schemas
This topic comprises the agreement on the usage of specific data formats e.g. non-GML representation of coverages. There are currently no extensions required.
.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 173 of 233
10. Engineering Viewpoint
10.1. Overview
Based on the major concepts of the SensorSA, the specification of information models and services in the Information and Service Viewpoint of a SensorSA, the following sections provide
definitions of policies for the set-up and operation of sensor service networks.
Policies are defined for the following aspects:
-
resource discovery see section 10.2
-
sensor and service monitoring see section 10.3
-
sensor planning see section 10.4
-
access control see section 10.5
-
processing of quality information see section 10.6
-
handling of large data sets see section 10.7
-
cascading sensor observation services see section 10.8
-
processing and fusion support see section 10.9
-
integration of mobile sensors see section 10.10
-
event handling see section 10.11
-
plug-and-measure support see section 10.12 Here, the SensorSA follows the basic idea of the RM-OA, 2007 to consider qualifying
characteristics of a service network in terms of policies.
10.2. Resource Discovery Policy
10.2.1 Introduction
The process of resource discovery may be carried out in multiple ways. However, for a given service network it has to be specified in detail in order to enable interoperability.
If not otherwise specified, a sensor service network is qualified as a “mediated service
network” and follows the policy of a “centralised discovery”. According to RM-OA, 2007 this means that there shall be a distinguished instance of a catalogue service in the following simply
called the “SANY Catalogue” or simply “the catalogue” that serves as the discovery entry point to a sensor service network. The meta-information schema of the SANY catalogue is specified in
section 7.6.3.
