Eco Grid Registry Design

This is version 2. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

EcoGrid needs to provide a registry of the services available and some brief metadata about each of those services. This registry will be used to locate the services and pick and choose among alternative incarnations of services when they exist. Services include core EcoGrid interfaces such as the query, authentication, and put interfaces, as well as custom services for computational tasks.

Registry Metadata

In general, I think we should keep the registry metadata brief at first, and then add more fields later as the need arises. So, it would be best if the metadata storage schema were pretty flexible. Here's the info I think we could use now:

Core (all services)

1. Logical name of service
2. URL of service WSDL
3. Service type (for gwsdl, this is derivable from the wsdl, and is a namespace URI I think)
4. Endpoint (we can get this from the wsdl, but it would be convenient to store)
5. ServiceClassification (from an ontology of service functions)

Query service

1. Search languages accepted (e.g., EML, Darwin core) (use namespace to identify)
2. Types of documents in collection (e.g., EML, Darwin Core, etc) (identify using namespace URI)
3. Spatial, temporal, taxonomic coverage of collection (use eml-coverage module) -- I'm not actually sure this is a good idea -- might be too hard to actually represent or update

Implementation