Using Smart Clients to Build Scalable Services

One-line summary: Realize scalability through managed replication of servers, either static or dynamic, along with service-specific client support code to locate and talk to an appropriate replica, fail over when that replica goes down, etc. (as opposed to "generic" support in servers for scalability)

Overview/Main Points

• Philosophy/assumption: it is simpler to upgrade all clients than all servers, so we should leverage that in deciding where to put support for scalability.
• Services accessed by Smart Clients assumed to be provided by a (dynamic) set of peer servers; choice of which one should account for geography/network topology, load balancing, etc.
• "Director" applet (servicelet?) is the single client-resident service interface: "Perform this action on some server node".
• Director applet keeps its peer list for each service up-to-date via an application-specific mechanism.
• Bootstrap: modified jfox browser to support "service://" name space; services looked up at well-known search engines to get a service certificate which binds to the client interface and director applets and gives initial hint as to service group members; Director may contact one of the members to validate the list.
• Existing applet examples: telnet front-end to NOW (load balancing, currently no failover); FTP mirror client; chat, using an append-only WebFS file, with multiple WebFS servers mirroring the file and multicasting updates every 300ms. (But see below)

Relevance

Flaws

• Seems like the mechanism for keeping server lists up to date should not necessarily be application-specific; should have at least some support for making it easier (e.g. choice of polling, multicast update, or lazy invalidation). Because of this, the "fault tolerance" claim is suspect; how exactly is FT provided? It's application-specific.
• Chat app: with all servers multicasting file updates every 300ms, is this really scalable? There are no ordering semantics, except those you're likely to get from such frequent updates, though authors acknowledge that any well-known ordering scheme (e.g. ISIS) could be used.
• Authors claim that "entrenched" URL naming scheme is difficult to modify so we should try to be compatible with it; yet they extend the naming scheme themselves to support other applications (chat, etc).
• How easy is it, really, to upgrade clients? Assumes users are willing to install upgrades on demand, willing to run extra code in their client, and that client software is largely uniform. Not clear how long these conditions will persist. Should be done in a proxy instead :)