RWP04: Registry Replication

[Keith Noddle]

On Fri, 2003-04-25 at 18:32, Roy Williams wrote:
> > > How about if we have three types of registry:
> > >
> > > 1. full: will attempt to maintain a full list of all resources on the VO
> > > 2. limited: lists only resources of interest to a specific community
> > > 3. private: only lists the resources at that location; not queryable
> 
> There is a smooth transition here to what we might call type 4: a service

I am slightly uneasy about different registry "types" as that
potentially leads to management and hierarchy issues. I prefer the
notion of a self regulating network of registries which "do the right
thing" among themselves. Building upon previous discussions, I'd like to
float the following:

      * A registry is viewed just another a resource

      * By definition, resource entries in a registry include a
        description of themselves (note: fine grained vs coarse grained
        resource metadata? This proposal requires fine grained)

      * The description of the content of a registry grows as other
        resources are added to it, BUT:

      * It is only necessary to add the "new" metadata from the added
        resource to the registry description (the goal being that the
        registry description contains the scope of the resources it
        holds but not the detail, that is in the individual resource
        descriptions)

      * All registries mirror all other registries

      * A registry only actions queries against resources for which it
        is authoritative (i.e. not resources for which it is a mirror),
        BUT:

      * A registry can initiate a query requesting it be actioned
        against mirrored resources (to manage "registry unavailable"
        problems - this needs further work)

Thus:

     1. Queries will be targeted to registries which contain relevant
        resources
     2. Duplication will be reduced to a minimum
     3. "Gridiness" will be upheld
     4. scope={"all","target","this"} will be supported (but "all" will
        obey [1] above)
     5. Time-To-Live can be supported
     6. Queries will never be more than 1 level deep
     7. Fail-over will be supported.

Keith.

-- 

Keith Noddle			Phone:  +44 (0)116 223 1894
AstroGrid Technical Lead	Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy	Mobile: +44 (0)7721 926 461
University of Leicester		Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH		Web:    http://www.astrogrid.org