Changes between Version 4 and Version 5 of Software/ContextService


Ignore:
Timestamp:
24/09/09 11:51:38 (10 years ago)
Author:
spascoe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Software/ContextService

    v4 v5  
    2020 
    2121 1. Each user should have a single active context per distributed application. 
    22  1. A context should store a collection of WMS services and selected layers as per the WMC standard. 
     22 1. A context should store a collection of WMS services and selected layers. 
    2323 1. A context could also store more WMS client state like WMC: visible layers, viewport, styles. 
    2424 1. The context could store WCS endpoints associated with WMS layers (presently this is implicit in the COWS design) 
    2525 1. The context service should serve contexts in the WMC format.  WMC need not be the primary format. 
    2626 1. 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 [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] operations through this API. 
    27  1. 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). 
     27 1. The context service should be flexible enough to provide an ad-hoc persistence to aid application integration (e.g. simple key/value pair storage). 
    2828 1. 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) 
    2929 1. 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. 
    3030 
    31 == Proposed Implementation == 
     31== Implementation Options == 
     32 
     33=== Option 1: eXist === 
    3234 
    3335The requirements suggest a data store service for XML documents with a RESTful HTTP interface supporting CRUD.  This is exactly what [http://exist-db.org/ eXist] does and therefore, given eXist is already part of our architecture, we should use that. 
     
    3638 
    3739How NDG Security is supported is less clear.  We may need a gateway service in Python to do authn/authz. 
     40 
     41=== Option 2: lightweight WSGI middleware === 
     42 
     43A 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. 
     44 
     45Advantages: 
     46 1. Solves the PHP-Pylons integration problem first. 
     47 1. Is implemented in Python so can be integrated with ndg.security 
     48 
     49Disadvantages: 
     50 1. WMC write would require coding in the future and would be more complicated than with eXist 
     51 1. Client code (cowsclient and PHP) would need more code to manipulate the JSON documents.   
     52 1. Cowsclient would have to deal with both WMC and JSON or abandon the WMC support entirely.