"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Service Profiles: An Implementation Approach

Contents

Related pages



Abstract

ISO and W3C service architectures both assume that general service invocation protocols will be applied to domains of usage through use of specific profiles that simplify and constrain the possible variations in use. It appears that this applies to equally to data access services where the end-user is concerned with the behaviour in terms of data products and query formulation.

There are several requirements introduced by the publish-find-bind paradigm, in terms of service metadata as well as service behaviour. It turns out that many restrictions need to be inherited from different contexts: roughly corresponding to the registries the service may be published within. Thus a service delivering water quality for a region, say an Australian State government, might be expected to conform to profiles for discovery within the state's Spatial Data infrastructure, the data custodian organization's internal infrastructure, a national water resources infrastructure, an international standard for water resources, a national Natural Resources data registry etc. Different communities will require different standardised implementations, but they may not be inconsistent with each other.

This is achieved with a single, simple mechanism: allowing profiles to inherit from other profiles and incrementally constrain generic behaviours into specific requirements that allow end-users to interact in a predictable way with the service. A service profile registry is used to implement this in the context of services oriented architecture.

Introduction

Inherent in the design of general-purpose Web Service protocols is the need for implementations to take cognisance of the domain of use, and to describe the actual utility of the service within that domain.

It is usual that any protocol sufficiently powerful and flexible to be applied to a wide range of applications also introduces the possibility of multiple, different, implementation choices for achieving particular functionality. For example, an OGC Web Feature Service exposing a FeatureType could rely on a canonical naming schema (eg a URN) for the FeatureType, or rely on the MetadataURL linking to a standardised implementation of a data product description, from which the FeatureType can be inferred.

The concept of a profile is simply conformant version of a specification that constrains usage to ensure compatible implementations. Typically profiles will specify:
  • Which optional aspects must me implemented within a domain of use;
  • Specific data types to use where more general data types are allowed, where the specific is a sub-type of the general case;
  • Binding value domains (or expected content) to specific parameters;
  • Extensions (NB these restrict the ways that the extended functionality may be implemented).

This paper outlines a theory and implementation path for creating a coherent data access services infrastructure allowing:
  • Discovery of services using registries;
  • Interoperable data access services delivering common data products;
  • Access to sufficient metadata to perform meaningful queries when invoking discovered services;
  • Predictability of service behaviour for end users;
  • Conformance testing;
  • Configuration rules;

In order to make it possible for multiple services to behave in a similar fashion, it is necessary to create a profile for deployment of a service type within a usage context. This profile binds value domains to the, often very general, data types defined by the service interface. The challenge is that, for any given service, the data types and associated metadata (WSDL, OGC GetCapabilities responses etc) will be bound to value domains governed by many different communities of use.

Thus, this profile pattern will need to be implemented in a distributed environment, and although quite simple to define and implement, the long term management will be simplified by common implementation of this critical service metadata.

Profiles for Data Access Services

Requirements

Profiles for Data Access Services have to perform a number of roles:
  1. Ensure that a service that claims to deliver a particular data product do so "correctly". In particular, a client should be able to attach directly to different services and run the same form of queries and process the data identically.
  2. Enable discovery, possibly automated, of services providing a data product.
  3. Ensure that the end-user expectations regarding availability, accessibility etc are clear, and can be met.

These requirements are best understood by looking at the examples below, identifying the specific requirements met by each profile in the hierarchy.

Multiple Facets of Data Access Services

A data access service profile must bind together behaviour from at least three different perspectives, (with separate governance):
  1. The organisational context (management)
  2. The technical context (protocol binding)
  3. The data (information community)

Figure 1 shows how these perspectives map to the specifics of describing a service. Note the strong similarity between Service Profiles and Data Product Specifications. At this stage it is suggested that a Data Product Specification references the service profiles expected to create interoperable access to the data product.

* Figure 1:Facets of Service Profiles:
image002.gif

It is assumed in this case that the Domain of Use refers to a specific system implementation, where the underlying intent of service profiles is to enable a specific community to operate within a organisational mandate. Service Types may be specified for a broader range of possible uses than that required to implement a service profile. For example:
  • a standard for a cadastral data model may be created at a national level, but a profile may be created at the State level to implement it, so the "domain of use profile" would involve the application of the national model in the context of the State;
  • a water resources metadata profile may be modelled at the national level by the information community and the domain of use may also be national, involving a nation-wide organisation like the WRON Alliance defining a profile of the national profile or
  • a meteorology data model may be defined at the international level and applied in an international context by the World Meteorological Organisation.

Note the strong parallel between the Conceptual Schema and the discovery metadata, but separation is maintained because it is expected that "fitness for use" would be a significant facet of data and data access service discovery. I.e discovery metadata is closely allied with the underlying data model, but is in fact different since it must include additional information about the intent of the publisher. It is expected that each profile package itself may be factored into a hierarchy of simple profiles for convenience (see examples below).

** Note that the <> stereotype is consistently used between the different meta-levels of the model. (This is the only relationship allowed between meta-levels.) This also implies that, for example the GovernanceStructure can be an abstract or concrete organisational policy that is not specifically encoded except through implementation profiles. Thus, although this diagram is relatively complex, really only the third tier must be made concrete to implement service profiles, and the parent objects may be created to support management of large numbers of subject domains in a coherent environment. Another way of looking at this is:
  • Concrete profiles support implementation
  • Common meta-profiles support efficient management and discovery across multiple subject domains

Some key patterns emerge:
  • Profiles must support multiple inheritance **
  • Vocabularies must be published objects
  • Implementation rules, management and user-friendliness of the final system rely on common profile inheritance

Example

It is perhaps valuable at this stage to consider a simple example. This is a partial example, a fuller treatment of service profiles for spatial data access has been undertaken for the Queensland Government Enterprise Architecture, from which this subset has been derived.

Figure 2 shows a tree of simple profiles to describe a useful data access service: an OGC Web Map Service delivering cadastral data. The root of the cadastre data product specification is not elucidated, but may follow similar inheritance patterns.

Terminology:
  • GEA - "Government Enterprise Architecture" referring to the jurisdictional interoperability requirement.
  • OWS - Open Geospatial Consortium Web Service
  • WMS - Web Map Server

  • Figure 2: Profile inheritance example:
    image004.gif

Let us consider each tier, and what its business purpose is:

Profile Example Constraints Purpose
GEA data services MD_Topic in { vocab X} Discovery of service within GEA service registry
GEA OWS Data Services Spatial Reference System support includes GDA94 datum Spatial interoperability of all data
GEA WMS ServiceMetadata/Keywords includes MD_Topic Refines general requirement from GEA Data services profile to a specific implementation method.
GEA Display WMS Response time for image up to 1000 x 1000 pixels is less than 5 seconds Ensure fitness for purpose in online display usage
GEA WMS FeatureInfo Response Format is known data type encoded in GML version X Make sure GetFeatureInfo response is usable. NB This operation only makes sense for a displayed map
Cadastre WMS * Layer named "Cadastre" exists and displays land tenure boundaries * Styled Layer Descriptor used is national Cadastre display standard. Ability to invoke a specific layer to get a specific data product displayed in a predictable way.

Examining these inherited nodes, its clear they introduce at the first possible opportunity * constraints that will determine the interoperability of the solution. The inheritance tree can be refactored wherever it is necessary to avoid complicated *conditional logic, without changing the contents of the final implementation profile.

Implementation

Registry Considerations

In order for profiles to be used by a community, they must be accessible.

In order for profiles to inherit from other profiles, they must be stable, referable entities.

Each profile represents the business requirements of some set of stakeholders.

Business requirements are not unique to a domain: there will be significant overlap between requirements of different sets of stakeholders.

It is desirable to minimise the number of profiles performing the same business function.

Different domains of application will establish infrastructures, often by leveraging the infrastructures of stakeholders.

All these factors point to the requirement for profiles to be published (in a standard format, or small number of transformable formats) in registries. A profile register is thus an integral part of any Spatial Data Infrastructure.

A register may be a trivial implementation (an XML file) or, more generally, will form part of the resources managed by flexible registries at the heart of any infrastructure.

Meta-model

The meta-model for profiles is relatively simple. ISO 19106 infers (but does not provide) the following UML model:

* Figure 3: Basic Profile Model:
image006.gif

Each Profile contains a list of testable Conformance Targets and a set of Requirements:

* Figure 4: Conformance Aspects of Profiles:
image008.gif

A requirement may be expressed in general terms, or may be bound to a specific testable assertion.

Requirements have unique IDs and may be referenced by child profiles which add testable assertions.

For example, an OGC Web Map Service will define a conformance target for the GetCapabilitiesResponse. This allows assertions about its content to be published. It will also specify a multi-valued conformance target for the Layer objects it offers.

Inheritance rules

The following inheritance rules apply:
  1. A profile may reference a requirement or conformance target declared in an inherited profile.
  2. Only one declaration of a requirement is allowed, ensuring unambiguous references.
  3. Requirements may not contradict each other.
  4. Requirements must satisfy all inherited assertions.
  5. Assertions may provide more restrictive versions of inherited assertions

XML binding

It is clear that a machine-readable specification of profiles will be required to manage inherited requirements. Also, some form or object must be placed within a profile registry. It is proposed that a XML schema be declared for a service profile definition, and XML encoded instance documents. At this stage, a normative XML binding is not specified, however there appears to be two logical options:
  • Adopt, and if necessary extend, W3C conformance profile XML specification schema
  • Map the meta-model into an ebRIM object model and use the derived XML schema

Conformance testing

The profile model proposed is strongly aligned with the WS-I conformance profile concept, and is specifically designed to support automated conformance testing directly from the profile specifications. Some requirements may not be machine-testable, but the goal should be to minimise such requirements.

Profiles as a simplification mechanism

The environment in which a service must be designed, implemented, deployed, discovered and invoked is quite complex in reality. The inheritance pattern of registered profiles adds one complex problem, but simplifies the contents of each profile until it is fairly trivial. The complex problem it introduces is this: there needs to be a common implementation of profiles across multiple domains of use. This is a significant problem, but one that needs solving once, upon which common profile management and client tools can then be built. In the short term, adaptors could be placed between different implementations, however there could, and should, be a common profile of a registry implementation for a Service Profile Registry. The simplifications introduced by the pattern include: Each profile has a clear owner and purpose and can be managed
  • Special cases can be pushed into specialised profiles, keeping each tier simple
  • No need for conditionals in profile specification language
  • Each profile can be quite stable since it doesn’t need to handle evolving cases, enabling clients (eg search portals) to be built and not require extensive modification

Profile Resolver

It is easy to imagine a registry client that loads a profile, and recursively loads all its parents. This resolver can cache common profiles, for efficiency.

With this component, no additional complexity would be visible from the client perspective, profiles would simply be easier to define and manage, and enforce greater interoperability.

It could easily throw an informative exception if incompatible constraints are found. This facility would be useful as part of the profile publishing process.

Next Steps

  1. Realisation of a service profile hierarchy and a service profile registry within a domain of use is required to test the theory and provide implementation examples.

  1. Development of an open source reference implementation of a ProfileResolver, conformance test suite and documentation generator. This work is underway at http://sourceforge.net/projects/ws-profile-mgr

  1. This profiles pattern should be promoted, via OGC to the ISO as a new work item to create an interoperability standard. An appropriate international sponsor for this work should be found, ideally via an extensive testing and adoption cycle. This could be achieved via, for example, ISO, W3C, OGC, the UNSDI or GEOSS but needs to be propagated to all these communities for maximum effectiveness.

References

  1. ISO 19106 Geographic information- Profiles, ISO TC211
  2. WS-I Basic Profile, Web Services Interoperability Organization, http://www.ws-i.org/Profiles/BasicProfile-1.2.html

 

Topic attachments
I Attachment Action Size Date Who Comment
image002.gifgif image002.gif manage 61.2 K 13 Aug 2007 - 18:50 RobAtkinson Figure 1:Facets of Service Profiles
image004.gifgif image004.gif manage 9.4 K 11 Jan 2007 - 10:18 RobAtkinson Figure 2: Profile inheritance example
image006.gifgif image006.gif manage 5.5 K 11 Jan 2007 - 10:19 RobAtkinson Figure 3: Basic Profile Model
image008.gifgif image008.gif manage 5.0 K 11 Jan 2007 - 10:20 RobAtkinson Figure 4: Conformance Aspects of Profiles
Topic revision: r5 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).