Client-side Advantages

As oppossed to the server-side solutions described above, Smart Clients implement a level of abstraction between a logical computing service and the physical servers comprising it in a service-specific manner. This client-side approach allows for greater system flexibility, allowing:

• Service-Specific Load Balancing - Smart Clients allow for service specific load balancing techniques. An applet may use a default load balancing mechanism (random selection for example) or develop an algorithm using service-specific knowledge. For example, the applet for a compute service might select a lightly loaded server machine, while the applet for an FTP service might pick the server with highest available bandwidth.

• Wide Area Service Topology - Client-based approaches to transparency allow more flexibility for providing service across the wide area. As an example, transparency mechanisms co-located with server machines (such as the Magic Router) limit the server nodes to those in close proximity, e.g. on the same subnet. On the other hand, co-locating transparency mechanisms with the client places no restrictions on server topology, allowing the service nodes to be transparently distributed across the wide area. This model of wide area distribution is common for the a number of popular Web services such as Netscape's home page [Net 1994] or Alta Vista [Dig 1995].

• Scalable Services To Legacy Servers - Smart Clients allows the creation of scalable services from ``legacy'' servers, such as the FTP. Scalable services can be created from existing server code without server code modification. The FTP servers do not require code modification, while the client is free to organize the service group membership and choose a server based on load.

• Client Code Portability - Using Java, we can create a scalable service from heterogenous servers (FTP daemons on different architectures) without modifying the code for individual server platforms. Since Java code is portable, we modify the code only once for the client.

• Parallelism - Putting functionality in the client potentially creates a set of parallel machines (the clients) to speed up the service. For example, to distribute service functionality between traditional servers and clients, the responsibility of choosing a service representative can be offloaded to clients.

• Fault Tolerance - The Smart Client abstraction layer can remove the dependency on individual server failure. Smart Clients maintain both knowledge of multiple representatives providing a service and the state necessary to reconnect to a second server on failure. Ideally, end users are entirely shielded from individual server failures.

Previous implementations of Smart Clients attempted to create fault-tolerant communication primitives for services, such as special director interfaces for the HTTP protocol. It was decided, however, that instead of creating specialized interfaces for all possible service communication protocols (sockets, HTTP, FTP, etc.), allowing the application writer to apply arbitrary code to a service node is much more general purpose. In addition, since all interaction with the service is through the director interface, the application writer has less need and opportunity to cache service node names which may become stale.

are hostname to IP mappings can be cached for extended periods on the client; thus, poor load balancing can result when many active clients make requests of a single server, while others remain idle. Further, if a machine failure occurs after name resolution, clients will usually resolve the name to the same failed server.