Version 5 (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. NDG applications will probably need to store attributes that don't fall neatly into WMC/OWC.


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

  1. Each user should have a single active context per distributed application.
  2. A context should store a collection of WMS services and selected layers.
  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 persistence to aid application integration (e.g. simple key/value pair storage).
  8. To support client-side calling it should support authn/authz via NDG Security. This requirement is optional if we are comfortable that no private information is stored in the context. However NDG Security should be used for finding the user's identity (e.g. a client application will need to get the users OpenID)
  9. The context service, or a secondary service which is NDG Security, must provide a one-click method of adding a resource to the user's context. This will allow MOLES catalogue records to have a "Add to Context" URL.

Implementation Options

Option 1: eXist

The requirements suggest a data store service for XML documents with a RESTful HTTP interface supporting CRUD. This is exactly what  eXist does and therefore, given eXist is already part of our architecture, we should use that.

Most, if not all, of this could be implemented in xquery and served directly by eXist. We would need specific xqueries for updating the context. The eXist documentation suggests an entire web application can be written in xquery so this should be possible.

How NDG Security is supported is less clear. We may need a gateway service in Python to do authn/authz.

Option 2: lightweight WSGI middleware

A WSGI middleware could expose a simple HTTP GET/PUT interface to a JSON document or dictionary of JSON documents bound to the user's session. The middleware would be able to serve the JSON as WMC using a Genshi template. Initially the middleware would not need to accept HTTP PUT of a WMC document, although this could be supported in the future along with other operations such as insert and reorder. Initially the context would not need to persist beyond the lifetime of the session. Persistence could be added later.


  1. Solves the PHP-Pylons integration problem first.
  2. Is implemented in Python so can be integrated with


  1. WMC write would require coding in the future and would be more complicated than with eXist
  2. Client code (cowsclient and PHP) would need more code to manipulate the JSON documents.
  3. Cowsclient would have to deal with both WMC and JSON or abandon the WMC support entirely.