SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 170 of 233
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.2.3 Specification of the SensorSA RESTful Web Services Platform
The SensorSA RESTful Web Services Platform is based on architectural principles introduced in Architectural Styles and the Design of Network-based Software Architectures Fielding, T.R.,
2000. Although similar to the SensorSA OGC Web Services Platform it further defines several constraints on the specification of service interfaces.
RESTful Web Services offer the following options regarding the transport protocol, the request and response schema, and the protocol bindings:
Topic Options
Transport HTTP
Request KVP Key Value Pair
XML plain XM Response
HTML XML plain XML
Binary any MIME Type Protocol binding
HTTP OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT
Table 9-4: Options for the SensorSA RESTful Web Service Platform
The SensorSA RESTful Web Services Platform is characterized by the following properties:
-
Platform Name The name of the platform is
“SensorSA RESTful Web Services Platform”.
-
Reference Model The SensorSA RESTful Web Services Platform is based on the architectural principles
introduced in Architectural Styles and the Design of Network-based Software Architectures Fielding, T.R., 2000
-
Interface Language The formal language that may used to define the SOA-RM Service Interfaces is either the
resource model as defined in section 7.6 or the Web Application Description Language WADL Hadley, M. J., 2006 which has been specifically developed for the description
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
