!- Converted with LaTeX2HTML 0.6.4 (Tues Aug 30 1994) by Nikos Drakos (email@example.com), CBLU, University of Leeds ->
: This Figure describes the Smart Client service access model. Two service-specific Java applets are supplied to mediate server access. The client interface applet provides the interface to the user and makes requests of the service. The director applet is responsible for providing transparency to the client applet; it makes server requests to the appropriate (e.g. least loaded) server, and updates its notion of server state.
In this section, we describe how the Smart Client architecture allows for the construction of scalable services. For the purposes of this paper, we assume the service is implemented by a number of peer servers, each capable of handling individual client requests. The key idea behind Smart Clients is the migration of certain server functionality and state to the client machine. This approach provides a number of advantages: (i) offloading server load and decreasing implementation complexity, (ii) allowing clients to utilize multiple peer servers distributed across the wide area without the knowledge of individual servers, and (iii) improving the load distribution and fault transparency of the service as a whole.
When a user wishes to use a service, a bootstrapping mechanism is used to retrieve service-specific applets designed to access the service. Two cooperating applets, a client interface applet and a director applet, provide the interface and mask the details of contacting individual servers respectively. Client-side functionality is partitioned in this fashion to separate the service's interface design from the mechanisms necessary to deliver client requests to servers in a load-balanced, fault tolerant manner.
: This Figure describes the Smart Client architecture. (1) The client interface applet first makes a request to the director applet. (2) The director applet, given outside information such as load and changes to the service group membership, picks the best node to apply the request to. The director will also re-apply the request if the operation fails. (3) The result of the operation, including a success/failure code, is returned to the client interface applet.
The client interface applet is responsible for accepting user input and packaging these requests to the director applet. The director applet encapsulates knowledge of the service member set and the service-specific meta-information allowing the director applet to send requests to the appropriate server. For every user request, the Smart Client uses the director applet to invoke a service-specific mechanism for determining the correct destination server for the request. Figure 3 shows the interaction of the two applets in a Java-enabled Web browser. A number of issues are associated with this approach: naming mechanisms for choosing among machines implementing a service, procedures for receiving updates with new information about a service (e.g., changes in load, or the availability of a new machine), and bootstrapping retrieval of the Smart Client applets. We will discuss each of these issues in turn leading to a description of the Smart Clients API.