Version 2 (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 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).
  8. To support client-side calling it should support authn/authz via NdgSecurity?. This requirement is optional if we are comfortable that no private information is stored in the context. However NdgSecurity? 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 NdgSecurity?, 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.

Proposed Implementation

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.