8 TECHNOLOGY VIEWPOINT
8.2 S ERVICE PLATFORM
8.2.1 Requirements for the specification
Components of a service platform specification137 are:
135 LifeWatch Document “Infrastructures for Biodiversity Research – Status Report, January 2010 (D5.1.2)
136 But even standards should be used with care since standards may be competing reflecting particular interests and they may not be fully accepted by the community.
137 See also http://lifewatch.iais.fraunhofer.de/HowTo/Web%20Programming%20Cookbooks.html
• Platform Name
• Reference Model
If the platform specification is based on a specific version of the LifeWatch Reference Model, the version number shall be provided
• Interface Language
Formal language used specification of service interfaces
• Execution Context
Specification of the Execution Context as an agreement between service providers and consumers that contains information about, e.g., preferred protocols, semantics, policies, and other condi-tions and assumpcondi-tions that describe how a service can and may be used.
• Schema Language
Specification of the schema language for defining Information Models
• Schema Mapping
Specification of how to map platform neutral information model to the schema language used for the particular platform.
• Information Model Constraints
Specification of the constraints on the LifeWatch Information Model, especially the constraints on the message format required for accomplishing the LifeWatch Action model.
Specific aspects that may be considered at the platform level are:
• User Management, Authentication, and Authorisation
The LifeWatch Reference Model provides a platform neutral specification of concepts for User Management, Authentication, and Authorisation (UAA) in order to be able to cope with estab-lished UAA mechanisms for dedicated platforms. For a specific platform, the platform neutral specification may have to be refined to agree with the authentication and authorisation mecha-nisms provided by the specific platform.
• Data Formats
An agreement on the usage of standard data formats and specific/proprietary data formats may be part of platform specification.
• Platform Mapping
In case that information models are modelled directly in a platform-specific schema language, conformance of such information models to the LifeWatch Meta-model has to be ensured: it must be possible to generate the UML representation out of a platform-specific specification such that the mapping rules for Application Schemes generate the original platform specific specification.
• Mapping of Service Interfaces
Procedures for the mapping of the platform-neutral service interfaces to a specific interface lan-guage may have to be defined. These procedures shall ensure that the mapping is in compliance with the rules of the LifeWatch Service Meta-Model. The mapping itself shall be part of an im-plementation specification. Ideally, the mapping should be bi-directional in that the platform neu-tral interface specification can be automatically retrieved.
• Restrictions on Certain Services
A platform specification may reduce the complexity or restrict the scope of certain services, if this is required to meet the main characteristics of the selected platform. This may, for instance, be the case if a platform provides semantically similar services of restricted nature. Note that this complicates interoperability between different platforms.
A platform specification may include recommendations for libraries and tools.
8.2.2 Platform example: components of a web service platform
Possible choices for the definition of a web service platform are sketched.
Interface language
Interface language may be a Web Service Description Language such as WSDL, or SAWSDL if semantic information is incorporated. WADL may be the choice in case of a RESTful web service. The precise version number is part of a platform specification.
Execution context
The message exchange protocol may be, for instance, SOAP 1.2 with HTTP as transport protocol. The message style may be defined in terms of a MIME type, for example “document/literal non-wrapped”.
For security, the basic mechanism may be SOAP Message Security for encryption of SOAP messages. As a requirement, the execution context may state that session information must be included in the SOAP header. RESTful services might require HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials.
The format of machine-readable descriptions of services may be another topic to include in the execution context. In general, whatever is used to run services should be included here with references to all the relevant documents, version information included.
Schema language
An example for a schema language for the geospatial domain would be the Geography Markup Language (GML) or the Ecological Markup Language (EML) in case of application in the ecological domain. Of course, more than one schema language may be referred to.
Schema Mapping
A schema mapping can be defined in terms of encoding rules. For instance, given that the schema lan-guage is GML, the rules of ISO 19136:2005 Geographic Information – Geographic Markup Lanlan-guage (GML): Annex E: UML-to-GML Application Schema Encoding Rules.138 These schema encoding rules are based on the general idea that the class definitions in the UML application schema are mapped to type and element declarations in XML Schema, so that the objects in the instance model can be mapped to corresponding element structures in the XML document as defined by the following general constraints on conversion rules.
UML application schema GML application schema
Package One XML Schema document per package (default mapping)
<<Application Schema>> XML Schema document
<<DataType>> complexType, property type and global element
<<Enumeration>> Restriction of xsd:string with enumeration values
<<CodeList>> Union of an enumeration and a pattern (default mapping, an alternative mapping is a reference to a dictionary)
<<Union>> Choice group whose members are GML objects or features, or objects corresponding to DataTypes
<<FeatureType>> Global element, whose content model is a globally scoped XML Schema type derived by direct/indirect extension of gml:AbstractFeatureType, property type
No stereotype or <<Type>> Global element, whose content model is a globally scoped XML Schema
138http://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHeaders=0&access_license_id=3&target=htt p://portal.opengeospatial.org/files/index.php?artifact_id=20509
type derived by direct/indirect extension of gml:AbstractGMLType, prop-erty type
Operations Not encoded
Attribute local xsd:element, the type is either a property type (if the type is a com-plex type) or a simple type.
Association role local xsd:element, the type is always a property type (only named and navigable roles)
General OCL constraints Not encoded
Information Model Constraints
For instance, the ORCHESTRA web service platform requires that, to avoid technical complications, all references GML in a WSDL interface shall be substituted by the XML schema base type xsd:string.