Version 1 (modified by spascoe, 12 years ago) (diff)


NDG Context Service

This page outlines a proposal to create a new service within the NDG framework to meet a requirement which has become apparent as we integrate download/visualisation and discovery services.


Throughout NDG development there has been recurring discussions about the need for a "shopping basket" of datasets to browse/download/visualise. Since NDG is conceived as a distributed system, involving multiple application servers, this obvious requirement more complicated than just implementing session state and therefore we have yet to implement a complete solution. NERC Portals Project partially solved the problem with it's set of WMS/GoogleEarth endpoints but this solution was confined to a single Pylons stack and therefore isn't distributed.

The requirement has now resurfaced in the context of  QESDI and  IS-ENES where we will be building web applications embedded in off-the-shelf content management systems (Joomla, Plone) that, although perhaps on the same server as a COWS stack, will not be able to easily share session state.

Available Standards

The OGC already has some standards in this area.  Web Map Context provides a schema for capturing the state of a WMS client session and this is being generalised into  OWS Context. These schema provide a good template to build on but there are no standards for WMC/OWC services, for instance to support creation and update of context resources over HTTP.


We need an NDG Context Service that provides a storage mechanism for web application state across multiple NDG service deployments.

  1. Each user (identified by an NDG OpenID) should have a single active context per distributed application.
  2. A context should store a collection of WMS services and selected layers as per the WMC standard.
  3. A context could also store more WMS client state like WMC: visible layers, viewport, styles.
  4. The context could store WCS endpoints associated with WMS layers (presently this is implicit in the COWS design)
  5. The context service should serve contexts in the WMC format. WMC need not be the primary format.
  6. The context service API should be callable by either server-side or client-side code (AJAX). It must be callable via: Python, JavaScript? and PHP. It must support all  CRUD operations through this API.
  7. The context service should be flexible enough to provide an ad-hoc session management function to aid application integration (e.g. simple key/value pair storage).