Local Handle Services

The Handle System has a two-level hierarchical service model. The top level consists of a HANDLE.NET Service known as the Global Handle Registry (GHR). The lower level consists of all other handle services, which are known as local handle services (LHS).

Local handle services (LHS), defined in detail in the Interface Specification, can be used for many different kinds of Internet applications, but the most popular (and the simplest) use to date has been to give persistent identifiers to web content, so that the content can be referenced and located using those permanent identifiers (with location data stored in the associated handle records) rather than using locations as identifiers (such as URLs which frequently change). See HDL.NET Services: Proxy Server System for information on resolving handles using a web browser.

Local handle services are run by organizations with administrative responsibility for creating and managing identifiers under certain prefixes. A service may be responsible for any number of local handle namespaces, each identified by a unique prefix.

Note that HANDLE.NET software is infrastructure and should be installed by system administrators. Whether your planned use of the software is simply for managing web content, or for a complex integration with another application, preparation for downloading the HANDLE.NET software should include a review of System Fundamentals and the Interface Specification. It also requires the Java™ Runtime Environment, and familiarity with public/private key or secret key authentication.

Running an LHS

To run a local handle service, you must download and install a local handle server. A typical LHS (as may be used for managing web content which is also the simplest configuration) has one site with one handle server, as illustrated by LHS "X" in Figure 1 below.

Figure 1: LHS "X" With One Server in One Site

One site is designated "primary" and it becomes the site responsible for handle administration for that service, taking responsibility for all the requests to create/delete/modify handles. The other sites within that service may also have one or more servers, and it's not necessary to have the same number in each site. Those sites provide resolution services, but are not used for administration. In other words, while each site will have the same replicated set of handles, each site may allocate that set of handles across a different number of servers, as shown in Figure 2.

Figure 2: LHS "Y" with Three Sites and Six Servers

The Global Handle Registry (GHR), described above, behaves like an LHS except that it knows where to find (via IP address) and how to contact (via which port) all registered local handle services. In addition, the service information it stores for each LHS will enable a client to determine which servers within each site in a service to ask for a given handle. Every handle client always knows how to contact the GHR.

As illustrated in Figure 3 below, all local handle services make themselves known to the GHR so that the GHR can direct clients to the correct LHS to resolve a given handle. The process of installing a handle server generates a configuration file with the service information that the GHR requires. Instructions for submitting it come with the installation files.

Figure 3: Client Queries the Global Handle Registry

Scaling an LHS

A service "scales up" by adding more servers. A large web content provider may need more than one server, depending on variables like server speed and hard drive size. There is no solely technical limit to the number of servers that can be added. If there are multiple servers, all the identifiers, and all resolution requests, will be evenly distributed across all the servers by the use of hashing.

Another way to scale up, and to provide redundancy via "replication" or "mirroring" of identifiers in an LHS, is to add more sites to a given handle service, either at the same physical location or at different locations. Figure 3 above shows a local handle service, LHS "Y", consisting of three sites and a total of six servers. This distributed approach is intended to aid scalability, accommodate any large-scale operation, and mitigate problems of single point failure. Each site is a complete replica of every other site in the handle service.