The goal of transparent access to network services would be compromised if the Smart Client applets necessary for service access must be downloaded from a single hostname before every service access. We have created a scalable bootstrapping mechanism to circumvent this single point of failure. To remove the single point of failure associated with a single hostname, we have modified jfox [Wendt 1996], an existing Java Web browser, to support a new service name space, e.g. service://now chat service. For the service name space, the browser contacts one of many well-known search engines with a query. These well-known search engines serve the same purpose as the root name servers in DNS.
: This example of a service certificate references both the client interface applet (Chat.class) and the
director applet (ChatDirector.class). Initial service group membership
(u81,u82 and u83) is fed to the director applet for bootstrapping
purposes. The director applet contacts one of these machines to obtain
group membership updates.
Currently, the browser contacts Altavista [Dig 1995] with a query requesting an HTML page whose title matches the service name, e.g. ``now chat service''. In this way, Smart Clients leverages highly-available search engines to provide translations from well-known service names to a URL. The URL points to a page containing a service certificate. The certificate includes references to both the client interface and director applets. In addition, the certificate contains some initial guess as to service group membership. This hint initializes the director applet, allowing the applet to validate the list by contacting one of the nodes. Figure 4 shows a certificate used for the NOW chat service.
Jfox has been extended to cache the Smart Client applets associated with individual services, the location of the service certificate, the certificate itself and any additional state that the Smart Client director needs for the next access to the service. While the client interface applet and service-certificate are cached using normal browser disk caching mechanisms, the director state is saved by serializing the director applet (and any relevant instance variables) to disk using Java Object serialization [Jav 1996]. Thus, on subsequent service accesses, the director applet need not rely on the initial group membership contained in the service certificate. Instead, it can use the last known service group membership. With this bootstrapping mechanism, no network communication is necessary to load the service applets after the initial access.
Currently, the service certificate and applets are cached indefinitely. In the future, we plan on adding a time-out period to the server certificate. After the timeout, the browser can revalidate both its service certificate and the associated applets. If either the certificate or applets are inaccessible, the decision to proceed with the cached state can be made on a service-specific basis.
Note that with the exception of bootstapping, the implemented applets work on unmodified Java-capable Web browsers such as Netscape Navigator and Internet Explorer. Further, mainstream browsers such as Internet Explorer allow for installation of filters over the entire browser [Leach 1996]. Such a filter would allow our bootstrapping mechanism to be implemented in widely used Web browsers.
The bootstrapping problem has been addressed in other contexts. For example, distributed applications need access to DNS without a name server. Such applications fall back to sending queries well-known root name servers when it is unable to resolve a hostname. As another example, applications which communicate through RPCs must bind to a server without using an RPC. This problem is also addressed by using broadcast to initiate binding to RPC servers on the network.
