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:
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.
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.
https://registryserver/repository/registry/add?registry.client=https://registryclient/repositoryThe 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/repositoryThe 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.