A RAMADDA server can register its existence with one or more other RAMADDA servers. In this case, a RAMADDA server that is registering itself with a registry server is known as a "registry client". By default a RAMADDA server comes with an initial registry server:
https://geodesystems.com/repository

The purpose of this is two-fold. First, this allows for a listing of RAMADDA servers so end users can find out about other repositories. Secondly, as part of the registration process your server will receive and store a list of all of the registered servers. You can then configure your RAMADDA server to support distributed searches across a federated network of RAMADDA servers (see below).

A RAMADDA server can also be enabled to be a registry for other servers. We term this a "registry server". This configuration is done through the Admin->Settings->Site and Contact Information page.

A registry server provides a listing of its known clients at:
https://geodesystems.com/repository/registry/list

Configuration

In the Admin->Settings->Site and Contact Information page there is a field where you can enter one or more registry servers, one per line. Just provide the top level URL, e.g., https://geodesystems.com/repository. You can also enable your server to be a registry server for other servers with the Enable this server to be a registry for other servers checkbox.

When your RAMADDA server receives a list of other RAMADDA servers as part of the registry process the server information is stored in the database. You can configure your server to provide remote search facilities on selected servers through the Admin->Remote Servers page.

Federated Searches

The basic registry service is used to support aggregated search across a set of RAMADDA servers. A client server will, on successful registration with a registry server, request the collection of client servers available from its registry server and store these in its database. The administrator of the client server will be able to select which of the other servers should be made available for federated search.

When there is such a collection of servers selected the Advanced Search form will have an entry listing the servers and will allow the end user to select which, if any, of the external servers should also be searched. When the search request is sent to the initial server if there are external servers selected that search will also be applied to those servers.

The big question is how to display those search results. The easy way is simply to show an html iframe for each of the remote search servers. There are many cases where this will be effective for the end user. However, we also want to be able to aggregate the results in the context of the original server and display the results as on collection (e.g., as a THREDDS catalog, an RSS feed, etc.) In this case the original server would launch each search request in a separate thread with the result output type being set to the internal RAMADDA xml format (as opposed to getting HTML back). The XML results are then turned into RAMADDA's internal data model structures and are displayed accordingly.

The Gory Details

The following diagram shows the basic sequence of the registration process.

When a client starts up or when its configuration has changed the client will notify each of its registry servers passing its base URL as an argument:

https://registryserver/repository/registry/add?registry.client=https://registryclient/repository

The registry server will attempt to connect back to the client passing its base URL as an argument:

https://clientserver/repository/registry/info?registry.server=https://registryserver/repository

The client, on receipt of this request, will check if the given registry server is in its list of registry servers. If it is then it responds with an xml listing of its server information including its title (the repository title) and description (the description of its top-level folder). On a successful response from the client the server will store the new client information into its database.

If the requesting registry server is not in the list of servers held by a client then an error is returned. On a failed request the registry server will remove the client listing from the database.

A registry server stores a list of client information (base URL, title, description) in the database. At start-up and at certain intervals a registry server will run through its list of clients, executing the above registry process. It does this to keep its listing up to date and to remove any clients that are no longer running. If, after removal of a client, the client starts up again it will run through its registry process (as described above) to be reinserted into the server list.