Web Services


This is a discussion page: we need to design the architecture for the DDC visualisation and want to look ahead to make software and metaware [by which I mean agreed interfaces and architecture -- does anyone have a better word?] components reusable for the more complex DDP visualisation and data delivery packages.

Both the DDC and the DDP require the capability to deliver images and data through a web interface. We want to provide this through OGC compliant interfaces to (1) exploit community knowledge about robust interface structures, (2) facilitate coordination between different developers by using a well owrked out standard, (3) facilitate the creation of flexible and reusable components.

It appears that we will require:

  • WMS: Web Map Server to supply images for browser visualisation.
  • WFS: Web Feature Server to supply data objects.
  • WPS: Web Process Server to perform data processing.

(See also the NDG Cdataservices page as the two projects will be sharing resources.)


Two layouts are illustrated schematically below. The two issues are ease of development and efficiency of use. We don't want a simple request which could be handled by a single process to result in multiple processes being started just because of technicalities in the interface protocol.

Architecture A

In this version, the portal passes a request to a OGC Web Services manager. This breaks up the request into processing, feature retrieval and image requests, and passes them to appropriate services. The services all communicate with the backend data servers.

Architecture B

In this version, the OGC Web Services manager only issues requests for either a feature or an image. The WMS does not communicate directly with the data providers, but goes via the WFS. The WFS capabilities should include derived features [is this allowed under OGC standards? -- see WebMapService], which it obtains from the WPS.

This version has fewer communication links, and would pass a single user request as a single request to the WMS or WFS.


The WMS, WFS and WPS could, perhaps, be modules runing in a single process: this would be easier to implement under architecture b.


Out approach to the standards could be:

  • Full: we probably don't have resources to do this.
  • Subset: i.e. only use features which are in the standards.
  • Intersection: Use the standards when they cover features we want, otherwise improvise. This appears to be the favoured option.

User storyline

Consider a simple case from the DDC User Requirements: creating an image of the difference between 2 user specified fields.

Under architecture A, this would get broken up into a WPS request and a WMS request, the WPS results would go to cache and then accessed by the WMS.

Under architecture B, the request is passed to the WMS which then call the WFS which in turn calls the WPS.

A WMS can, under the OGC standard, be configured to use a WFS in this way. It does not appear, however, that the extension to a WPS is possible. The WFS needs to have a list of available features. This could be augmented by a call to the WPS, creating new data, but the Capabilities of a WPS can't be advertised through a WFS.

This suggests the following:

When dealing with a complex request, the OWS would first have to instruct the WPS to generate the data in such a form that it can be advertised in the WFS Capabilities and then pass a request to the WMS to map it.