SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 120 of 233
-
ns-id optional : Defines the namespace for the identifiers of the representations of the
resource. It may but need not be the same as the name of the resource. Note: When mapping to a service platform, the relationship between the identifier of the
resource and the identifierss of its representations has to be defined. This is done in an identifier scheme and has to be defined as part of the Engineering Viewpoint of the system‟s
design. In the case of RESTful Web Services, a typical identifier scheme is to combine the ns-id into one hierarchical URI such that the start of the URI denotes the resource name and the rest
denotes the identifier. The boundary between the start and the rest is specific to the resource.
7.6.2.4 Resource link
The possibility to link a representation of a resource to other representations of the same or a different resource is one of the key features of a resource-oriented architecture. It is modelled by
the association class ResourceLink. A resource link is a directed link that determines the navigation direction between the corresponding representations.
It has the following properties:
-
definition optional: Human-readable description of the purpose of the link.
7.6.2.5 Uniform Interface
The uniform interface is an instance of the meta-class OMM_InterfaceType of the service meta- model of RM-OA, 2007. As illustrated in Figure 7-13, it requires that the following operations
be defined for a given platform. Examples for HTTP 1.1 as the mandatory transport protocol of the SANY service platforms see section 9.2 are given in brackets:
-
createResource cR: create a new resource e.g. HTTP PUT to a new resource
representation, HTTP POST to an existing resource representation
-
getResource gR: retrieve a representation of a resource e.g. HTTP GET
-
deleteResource dR: delete an existing resource e.g. HTTP DELETE
-
updateResource uR: modify an existing resource e.g. HTTP PUT to an existing
representation The following operations are to be optionally provided:
-
getResourceCapabilities gC : check which methods are supported by a particular
resource e.g. HTTP OPTIONS
-
getResourceMetadata gM : retrieve the descriptive information about a representation
e.g. HTTP HEAD
-
createSubordinateResource cS : create a resource representation in the context e.g.
namespace of a given resource representation e.g. HTTP POST
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 121 of 233
-
appendToResourceState aS : create additional information about the state of a resource
e.g. HTTP POST.
Figure 7-13: Model of the Uniform Interface 7.6.2.6
Resource Method
The resource method defines a method that is supported by a resource and its possible mapping to an operation of another interface type. It has the following properties:
-
opName : Method that is supported by the uniform interface see section 7.6.2.4
-
definition optional : Human readable description of the meaning of the method for the
resource.
-
opSpecificIF optional: name of an operation of another specific interface other than the
uniform interface that is semantically equivalent to this resource method. This property is essential when the uniform interface is defined in addition to an existing interface of a
given service type.
Example: The getResourceRepresentation operation of the resource type “observation” is
semantically equivalent to the getObservation operation of the interface Core Operation Profile
of the Sensor Observation Service see section 8.2.2.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 122 of 233
7.6.3 Relationship between Resources, Services and Features
