From the high-level perspective, the major problem, which is tackled by DistRegistry library, is quite simple.

To simplify explanation, we will use sample with services discovering (at least, Distributed Registry was developed to support dynamic services discovering); however, the overall approach is applicable to organization of distributed registry of any arbitrary objects which are tagged by their unique key. Internally, Distributed Registry uses Java serialization to convert both keys and values to data which are transferred via network and therefore it is required that both objects used as keys and appropriate values should be serializable (and, obviously, has proper implementation of equals() and hashCode() methods).

Let�s imagine that we have several servers that expose the set of services that could be available remotely.

Using Distributed Registry, each server can publish information about its own services. Each service is denoted by some unique identifier. The identifier can be considered as a good candidate for a key under which particular service is published.

On the one hand, server may publish information about location of that service (or, more precisely, information that allows to access service). The ordinary RMI URL is a good example of such information.

On the other hand, it is not enough to publish information about services. The client interested in using remote service (in general terms, arbitrary data published by provider) should be able to discover location of that service.

To support such a scenario, the entire distributed registry consists of two parts - the first one let's publishing information in registry and the second allows consuming published data from there.

In general, publishing part is considered to be "server-side" part of distributed registry while consuming part of registry is considered to be "client-side". Of course, terms "client" and "server" are only applicable to internal organization of registry and are not related to overall architecture of application, because the last uses distributed registry (if necessary, the same component of distributed application may include both providing and consuming parts of the registry).�

It should be noted that each publisher might store data in registry under the same key, while the data itself can vary and be specific for particular provider. As for the previous example - several identical servers may publish the same service under the same key, but it is obviously that location of that service will be specific for particular server.

Since the client is interested in obtaining information about all possible locations of the service, the architecture of distributed registry allows a client to retrieve all data items stored under the same key.

The following diagram illustrates the overall scheme of distributed registry organization.

From this diagram, it can be seen that there is a business logic code, which publishes information in ProvidingRegistry. Each providing registry is only "aware" of "own" items ("own" means items were published via it).

Data published by providing registries are propagated via network using fairly simple protocol. They are available on client side of ConsumingRegistry. Application code, which represents business logic, may ask ConsumingRegistry for available data.

Unlike ProvidingRegistry, the ConsumingRegistry contains data published by all providing registries (of course, this feature is defined by configuration of distributed registry).

ConsumingRegistry may ask ProvidingRegistry for all data published via them or for data published under particular key. In addition, particular ConsumingRegistry may "decide" that some data are no longer valid, and notify other ConsumingRegistry of that fact.

On the other hand, ProvidingRegistry may notify providing registry of data published under particular key or of all data published via particular ProvidingRegistry and also notify that some data published via it are not valid or available anymore and therefore should be removed from registry.

While previously we used examples with services publishing, the overall scheme of distributed registry allows working with arbitrary data if such a scheme should be supported inside the application.