RWP04: Registry Replication

Keith Noddle ktn at
Thu Apr 24 02:58:58 PDT 2003

In order to make a start on the design of registry replication, I have
put together the following requirements and their implications. Please
feel free to alter, add or delete. I'll assume silence to mean

1. Distributed
      * It probably doesn't make sense to store all of the registry data
        in every registry. This implies a distributed model of registry
        searching and maintenance.

2. Self maintaining
      * The registries should place the absolute minimum burden upon the
        data centres where they run. On-going maintenance costs are
        mostly those relating to support personnel, so the less human
        intervention the better.
      * Registries should where possible manage their own data integrity
        (backups etc)
      * Self maintenance almost certainly implies a peer network of

3. Extensible
      * It must be easy to add a new registry to the registry network
        (but see below).
      * It should also be a design goal to make changes to the registry
        metadata design relatively painless.

4. Robust
      * The registry network should continue working even when some
        registries are not available. This implies a certain level of
        data redundancy.
      * Registries will be visible to the Internet. They must therefore
        provide sufficient security to protect the integrity of their
        data (see also Self Maintaining) without hindering access to
        those data.
      * Registries must also resist other forms of attack for example
        "Denial of Service" attacks or providing a host for "Man in the
        Middle" attacks.

5. Reliable
      * Users should be confident that the queries they issue to
        registries will return valid, useful data. It is therefore
        important to manage the membership of the "registry club" and
        not let arbitrary registries join the network unchecked.
6. Flexible
      * Registries should support rich data enquiries.
      * A registry should also support "data harvesting" by other
        registries. This allows registry data to be copied and expanded
        as required as well as supporting data redundancy through data

Based upon this list I have started to develop use cases, activity
diagrams and a domain model to support these operations.

Please note I have NOT started work on the registry query schema as I
need help on this one!



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
Leicester, UK   LE1 7RH		Web:

More information about the registry mailing list