When Are Naming Services Appropriate?

The bootstrapping problem is simple: in a distributed application, clients running on one machine need to connect with servers running on another machine. On a large network, there are really only three ways to solve this problem: [ 1] [ 1] On smaller networks, automatic discovery by m ulticasting is also an option. See Java Network Programming, Second Edition by Elliotte Rusty Harold OReilly and Jini in a Nutshell by Scott Oaks and Henry Wong OReilly for more information on multicasting and automatic discovery, respectively. • The client knows in advance where the server is. Either the server location is actually compiled into the client application or, more typically, the location of the server is stored in a secondary resource for example, in an easily edited text file distributed with the client application. • The user tells the client application where the server is. The client might then store this value. For example, in an email client, one part of configuration the user is usually required to enter is the address of the mail server. The location of the mail server is then stored, or the user may have to enter the value repeatedly, such as with web browsers. • A standard server in a well-known location serves as a point of indirection. In this scenario, the client queries a network service to find out where the server is. This is the solution that naming services provide. The client has to know how to find the naming service, but then asks the naming service for information about how to connect to the server applications it requires.

14.1.1.1 Installing a new printer

To illustrate this, consider our printer server. Look what happens in each case when we move an existing printer to a new location on the network: The client knows in advance where the server is. In this case, we need to update each client application or change the secondary resource to reflect the new information when we move the printer. If we were clever, and stored the list of printers in a single file to which all machines on the network had access, this might not be so bad. On the other hand, arranging to have a single machine mounted by all the client computers on a large network is a difficult chore. Moreover, having a single file with all the printers listed in it comes awfully close to having a form of centralized indirection and is a hint that we probably want to use a naming service anyway. The user tells the client application where the server is. In this scenario, when the user runs the application, the user enters the information about the new printer or the new location of the old printer. This is, more or less, an unworkable solution. End users dont want to do this, and a significant percentage of them will get it wrong. The client makes a query to a network service to find out where the server is. When the printer is installed or moved, the naming service is updated to reflect the new information. When clients launch, they query the naming service. The clients are always up-to- date, the client machines didnt need to be modified in any way, and the end users didnt have to do anything. 14.1.2 When Are Naming Services Appropriate? Each of the three approaches to the bootstrapping problem has advantages and disadvantages, depending on the application being written. Servers in a typical client-server application have many properties, which suggests that the flexibility provided by naming services is worth having. Among them are: Servers migrate. Servers sometimes overwhelm the machine on which theyre initially deployed. Sometimes, server hardware is retired or repurposed. Sometimes network administrators install a firewall, and the server applications must be moved to another machine. For whatever reason, server applications are often moved from machine to machine over the applications lifetime. There may be many servers. This is obvious in the case of network services such as printers. Every floor may have a printer. However, its also true for our bank example; there are thousands of servers, and each client needs to be able to access each one. Servers get partitioned and replicated. One response to overwhelming demand is to replicate servers. We discussed partitioning briefly in the bank example; the idea was to move some of the instances of Account to another machine if the server response time was unacceptable. In addition, read-only requests can be farmed out to any number of replicated servers. There may be many servers running on one machine. A single machine can run many servers. Some of these servers may have reserved well-known ports for example, port 80 is reserved for web servers. However, reserving ports is a risky strategy because the more ports that are reserved, the greater the chance of having reservations conflict. A much better strategy is for servers to randomly grab an available port number when it launches. Note that the bank example exhibits all of these properties. In contrast, consider the prototypical naming service. Its implemented once and reused. It never evolves. Theres usually only one, and it doesnt get partitioned. And its a simple enough piece of code that an implementation can usually handle large numbers of requests quite robustly. If you have to hardwire a servers location into your client or as a parameter in a configuration file, hardwiring the location of a naming service involves the least risk of having to update the client. All of the preceding points are arguments for indirection. If many of them apply to an application, then the design should include a level of indirection when clients connect to a server. A naming service provides this indirection in a very simple manner: clients call a stable and well-known server whose sole responsibility is to direct them to the server that they really need. That is: • Servers are registered bound into the naming service using logical names. • Clients know the location of the naming service and the logical names of the servers they require. From this information, they can find the servers at runtime.

14.2 The RMI Registry

Weve done three things with the RMI registry: weve launched the actual registry server, weve bound objects into the registry using strings for names, and weve looked up objects in the registry. All of the code weve written has used static methods on the java.rmi.Naming class to accomplish these tasks. In particular, Naming defines the following five static methods: public static void bindString name, Remote obj public static void rebindString name, Remote obj public static void unbindString name public static String[] listString name