[kepler-dev] Re: scope, design of the Ecogrid registry vs Kepler registry

Matt Jones jones at nceas.ucsb.edu
Thu Oct 14 09:03:57 PDT 2004

Hi Bertram,

Bertram Ludaescher wrote:
> Matt et al:
> Another topic that came up in todays meeting was the EcoGrid
> registry. Bing is working on an XML Schema for the registry schema. 
> I also found some other documentation, e.g. here:
> http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/seek/projects/ecogrid/docs/meeting-notes/ecogrid-mtg-notes-20030923.txt
> Here are my questions:
> 1. Are additional design docs available?

> 2. What is the planned functionality, scope, and schema of this
> registry, and last not least
It provides a registry for various web and grid services, with metadata, 
modeled after the VORegistry in the globus toolkit.  Its intent is to 
allow us to discover data and computaitonal services dynamically and 
determine whether they are appropriate for particular uses.  Metadata, 
including both system-level metadata (ie, the endpoint) and semantic 
metadata (e.g., semantic annotation) would be available for each 
service.  Jing is building an interface in Kepler for accessing and 
querying it, so we really intend for it to be *the* registry in Kepler.

> 3. How does it relate to the planned Kepler actor repository that we
> have been talking about recently? (aka load an actor from a remote
> repository kind of stuff...)
Well, the 'actor repository' hasn't really been designed, and what we've 
talked about is far more on the local side than the server side.  See my 
and Shawn's emails to the list regarding dynamic transfer of actors and 
using LSID's to identify actors in a data store.  The EcoGrid registry 
is closely aligned in purpose with the idea of an actor store, but we've 
done far more design work and implementation on the EcoGrid registry.

> It seems that a Kepler actor repository might very well subsume the
> Ecogrid registry, since instantiated web service actors would have all 
> the info that the Ecogrid service registry has and probably more
> (e.g., semantic annotations)
Actually, I think its the other way around -- the EcoGrid registry is a 
far broader concept.

> Overall it seems that at least the following issues need to be addressed:
> (a) schema definition f the repository (e.g., need to store WSDLs,
> Kepler actor jars, semantic annotations etc. in the case of the Kepler 
> actor repository)  
Similarly to the Globus toolkit's ServiceData concept, we've agreed the 
metadata schemas for the resitry should not be constrained.  So we're 
using a flexible storage system for metadata rather than hard coding it. 
  Each service has a core set of metadata and potentially 
service-specific  metadata as well.
> (b) repository access functions: how to register stuff into the
> repository, how to update and delete from the repository, and how to
> query and get it out?
These API's have already been designed and partially implemented.  See 
in particular the diagram describing the registry methods and 
interactions among various system components:

> Part (a) sounds like a SMODD (simple matter of database design ;-) ...
> Are there any repository standards that we could use? 
Yes.  VORegistry is the closest.  We've also evaluated UDDI, but decided 
it wasn't what we needed because it does not allow for dynamic metadata, 
and is very complicated for what you actually get.

> Ideas?
Yep - I've got lots :)


> Bertram

Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org

More information about the Kepler-dev mailing list