|
Difference between
version 2
and
version 1:
| 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 4 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. |
| + |
| + |
Back to Eco Grid Registry Design,
or to the Page History.
|
