|
Difference between
version 5
and
version 2:
| 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]). |
| At line 24 added 1 line. |
| + 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. |
| At line 25 added 10 lines. |
| + !! 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. |
Back to Eco Grid Registry Design,
or to the Page History.
|
