NDLP Internal Documentation

A Global System of Handle Servers

The handle system is distributed across many computers

The process of resolving handles in a global environment involves a sequence of messages between several computers. Figure 1 shows a simple but realistic configuration. The user will need a web browser that incorporates a module that recognizes handles and knows the Internet name of the global handle server, a computer at CNRI. The global handle server knows about all local handle servers. The example assumes that the Library has a local handle server which has records for items in NDLP collections. These records link each registered handle with a URL (Uniform Resource Locator) or other form of locator. If presented with the handle for an item in an NDLP collection, a sequence of four messages would "resolve" the handle into a URL, which the browser could then use to request the item in a fifth message. An informal description of the messages follows the diagram.

Figure 1. Resolution of handles (basic)

Diagrams are almost essential for this 
document

Imagine that the web browser detects the following handle: hdl:loc.pp.detroit/4a32371t. The handle may be in an HTML or SGML document, such as a finding aid, have been retrieved through a search of bibliographic records, be entered directly by a user who has a reference, or any other means.

A sequence of messages resolves the handle and retrieves the item

Given the handle hdl:loc.pp.detroit/4a32371t, the following messages are exchanged:

  1. Request from handle resolution software within browser (HRS) to global handle server (GHS):
    Which handle server manages names for "loc.pp.detroit"?
  2. Response from GHS to HRS:
    Local handle server (LHS) at lhs.loc.gov
  3. Request from HRS to LHS:
    What is the URL for "4a32371t"?
  4. From LHS to HRS:
    URL is "http://lcweb2.loc.gov/image/4a/4a30000/4a32000/4a32300/4a32371t.gif"

    The handle has now been resolved into a URL. The final message is exactly the same as the message that would have been sent if the web browser encountered a link specified by a URL rather than a handle.

  5. Request from web browser to digital archive:
    Get "http://lcweb2.loc.gov/image/4a/4a30000/4a32000/4a32300/4a32371t.gif"

The handle resolution software can save time by remembering earlier conversations

In practice, messages 1 and 2 can be eliminated if the HRS "remembers" which handle server manages names for loc.pp.detroit. The HRS has a cache in which to store a certain amount of remembered information. Once the cache is full, recent transactions supplant information that has not been re-used recently. When HRS does not have the relevant information in its cache, or if it discovers (by having messages returned as undeliverable) that its cached information is out-of-date, it goes back to the global handle server to get the authoritative information on which local handle server is managing handles for a given naming authority. Similarly, messages 3 and 4 could be eliminated in some cases if recent URLs were also "remembered" in a cache.

The key to efficient handle resolution on a global scale is also built round the concept of caching. Instead of all web browsers in the world going directly to the global handle server with requests, requests can be sent to a closer handle caching server, which can carry out all the handle resolution conversations and remember a lot of handle server locations and URLs in a large cache. Figure 2 shows this configuration. When a new handle is encountered, more messages (6 instead of 4) are needed to resolve a handle into a URL, but the caching server can be configured with a large cache so that a large proportion of the messages are unnecessary.

Figure 2. Resolution of handles (with intemediate caching server)

Diagrams are almost essential for this 
document

The handle system is extensible

As the use of handles grows, subsidiary local handle servers can be added to manage names under delegated authority and caching servers can be added or expanded. No changes are needed in the process or the component software as this extension happens.

The handle system is very like an existing Internet service

The resolution process may seem complicated, but a very similar process is invoked every time an Internet domain name is used. When a user follows a link to lcweb.loc.gov, (the name of LC's WWW server and home page), the name must be resolved into its numeric IP address, currently 140.147.248.7. When a user starts a LOCIS session by opening a Telnet connection to locis.loc.gov, the same resolution process is used to get the address 140.147.254.3. No message can be sent on the Internet without an address in the numeric form, but the software does the resolution behind the scenes; users are usually unaware of the process. Some web browsers display messages on the status of resolution; these messages may occasionally be on the screen long enough to be read.

The domain name system was developed to solve the same type of problem as the handle system. The names used to access services can stay the same even when those services are transferred to different computers. Short mnemonic names are easier to transcribe and remember than strings of numbers. Basic name resolution software is incorporated into all of the utility software packages that support Internet access. Just as with CNRI's handle system, the domain name system has a central registration server, decentralized name servers that provide the authoritative name-to-address translations for certain domains, and a network of communicating caching name servers.

Notes:

  1. The diagrams represent the ideal situation in which the Handle Resolution Software (HRS) is incorporated into the browser. However, the resolution process can be carried out on an intermediate server. In particular, the URL formed by preceding any handle with http://purl.handle.net/ or http://purl.oclc.org/hdl/ will invoke the HRS on the corresponding handle- or PURL-server.
  2. For simplicity, this explanation assumed that handles will always be resolved to URLs. There are other potential forms of locator, including one that retrieves items from the repository under development with CNRI. The resolution process remains the same.
  3. Other proposals for resolving URNs will have a generally similar structure, with a central authoritative system, distributed subsidiary systems, and caching at intermediate stages. Some proposals suggest extending and modifying the existing Domain Name Service to provide resolution for URNs as well as domain names.

Previous -- Up

Handle Server:3 --
NDLP Internal Documentation
(8/11/96)