: 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.
