Eco Grid Registry Design

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

DRAFT FOR COMMENTS

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

We need to both identify and describe services.

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)

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

Query service

Search languages accepted (e.g., EML, Darwin core) (use namespace to identify)
Types of documents in collection (e.g., EML, Darwin Core, etc) (identify using namespace URI)
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

Obviously, each service type will need its own set of metadata fields to properly describe it, in addition to the core fields. The Globus design for this seems excellent in this regard. So, in many ways we may just want to emulate that for infrastructure (or utilize it, seeing as the 'findServiceData' method is implemented for every one of our services anyway). Doing it this way would mean that the registry wouldn't need special methods for getting the additional service-specific metadata. Really, the only thing that would be actively registered would be the GWSDL URL -- from there the registry should be able to call the service's 'findServiceData' method and get any and all additional metadata.

Service identifiers

We need to decide how to handle identification of services. Globus' GSH is the right idea, but we have recently been discussing using LSID identifiers for identifying data sets, actors in Kepler, taxonomic concepts, and other things [1]. It would only make sense for us to treat services uniformly from an identification perspective. But we need to decide how this will fit into the WSDL/GWSDL framework.

[#1] See the EcoGrid Identifiers discussion and the Identifiers in Kepler discussion.

EcoGridCommunity

Go to top More info... Attach file...

This particular version was published on 10-Sep-2004 12:30:07 PDT by NCEAS.jones.