| Line 3 was replaced by line 3 |
| - 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. |
| + 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. Initial design of the registry was done in Seattle (see the [notes|http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~//seek/projects/ecogrid/docs/meeting-notes/ecogrid-mtg-notes-20030923.txt?rev=1.1&content-type=text/plain] and the [diagram|http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~//seek/projects/ecogrid/docs/meeting-notes/Ecogrid-23Sep2003.png?rev=1.1&content-type=image/png]). |
| Line 10 was replaced by line 10 |
| - !CORE |
| + ! Core (all services) |
| Line 15 was replaced by line 15 |
| - # Search languages accepted (e.g., EML, Darwin core) (use namespace to identify) |
| + # ServiceClassification (from an ontology of service functions) |
| Line 17 was replaced by lines 17-18 |
| - !COVERAGE |
| + ! Query service |
| + # Search languages accepted (e.g., EML, Darwin core) (use namespace to identify) |
| At line 20 added 15 lines. |
| + !! 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. |
| + |
| + In addition, because the Globus service definition allows any given service to support multiple service data elements (i.e., xml document types), the service data for a service is extensible by definition. |
| + |
| + !! 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. |
| + |
| + !! Distributed registry services |
| + We've discussed that one single, centralized point for the registry is not adequate, and instead we needed a registry that is distributed across several hosts on the internet. When a new registry comes online, it would announce its presence by registering with one of the existing registries. Existing registries would take registration events and send them to all of the other know registries. The [diagram|http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~//seek/projects/ecogrid/docs/meeting-notes/Ecogrid-23Sep2003.png?rev=1.1&content-type=image/png] in our Seattle meeting notes describes this at least schematically. |
| + |
| + !! Registry prototype |
| + An inital registry prototype has been developed and currently can be viewed here: [http://kuecogrid.ittc.ku.edu:8080/ogsa/registry.jsp]. It is not complete. |
| + |
| + [#1] See the [EcoGrid Identifiers discussion|EcoGridIdentifiers] and the [Identifiers in Kepler|IdentifiersInKepler] discussion. |
