davidpratten.com

STEPS Toward The Reinvention of Programming has a great piece about the promise of a uniform model of computation based on arbitrary decomposition to the internet. On p32 they say:

Part of the solution to “an Internet all the way down” has interesting conflicts with today’s hardware and we are curious to see just how far this can be taken without having to posit a different (but pretty minimal) set of machinery to help out. Basically, we would like to make a distributed object system that is (a) so protected that it can allow completely foreign objects to be brought in from elsewhere without causing harm, and (b) so efficient that a much higher level of abstract communication can be used between objects (perhaps an advanced form of “publish and subscribe” or “forward inferencing using knowledge patterns”).

One of the central observations underlying RDBC (and Hypertext Computing) is just this idea of the Internet All the Way Down!

In this post I argue that the current convergence of Desktop and / Web Apps (RIAs) suggests a convergence of Server and Clients and that this opens up some interesting possibilities.

I have been following an interesting series of posts by Arnon Rotem-Gal-Oz on the web/desktop convergence trend (all four posts are worth reading!). As well, in January and April, Arnon observes software converging towards:

• the ease of deployment of web applications,
• the richness and responsiveness of desktop apps,
• using a unified programming model for the whole app.

Technologies competing for the privilege of delivering some or all of this trifecta include (but are not limited to) AJAX, Adobe Flex, Flash, Adobe Air, Microsoft Silverlight, JavaFX, Google Gears, Mozilla Prism, Aptana’s Jaxer and JNext.

These technologies are being developed in the context of increasing awareness of two trends 1) the possibilities of ‘on-tap’ cloud computing and simultaneously 2) the promise of 100’s of cores in our client computers.

Here are some observations about the current web-app situation:

• Increasingly, the Virtual Machine environments on the server are being introduced down the tiers and ported to clients. (Silverlight’s CLR, and Java VM come to mind.)
• The use of Javascript in browsers has taught us about the secure use of mobile code and a similar mechanism could be inductively applied back up the tiers so that servers also are extensible like browsers. (Unlike the movement of server VMs into clients, I am not aware of production or prototype implementations of this.) Aptana’s Jaxer is a great example of this. (Thanks to Peter Svensson for pointing this out.) See Request Based Distributed Computing for a candidate architecture.

What we are seeing is not just a Web/ Desktop Convergence but also the possibility of Server/Client Convergence.

This convergence has the potential to address another problem in the current state of affairs with web apps:

• Forcing the developer to choose in advance about the location of code execution is like forcing the developer to place a long running bet on the relative performance of the cloud, network and heterogeneous clients.

Actually, this is one of the drivers underlying Microsoft Volta - a technology that is designed to reduce the cost of reassigning portions of an application between server and client. However as Arnon has pointed out it does not provide an abstraction that reinforces the “coarse-grained interface” that works well in the context of the fallacies of distributed computing. Unlike Volta, tier-agnostic requests relies on the same coarse grained interface as AJAX.

Convergence of server and client technologies
However, the convergence of server and client technologies opens up the possibility for Request Based Distributed Computing and tier-agnostic requests to provide a simple mechanism for delaying architectural decisions to run-time as well as supporting:

• the ease of deployment of web applications,
• the richness and responsiveness of desktop apps,
• using a unified programming model for the whole app.

The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC).

This is how I summarised RBDC in a recent post:

Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution - instead issues like availability of computing power, intellectual property and security will dictate this at run time.

This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion.

In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request.

DIAGRAM 1

In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it’s local computing capacity. In this case the relevant code is evaluated on the server.

DIAGRAM 2

The two ways of satisfying the request have differing performances. The relative performance of the two alternatives will be determined by things like the server/client balance of: response time, network bandwidth, and network latency.

A monitor can observe the time to complete each http request and recommend to the client whether to request mobile code or to let the server evaluate the code that generates the resource. This is an adaptive process because during a 24 hour period server availability, network latency and available bandwidth could change radically. Once the monitor has decided on the fastest way to execute a piece of mobile code, it may attempt the evaluation of mobile code in the opposite way once every N requests - in this way keeping its adaptive capability current.

Tier-Agnostic requests are being used by the Wadi project in Java Server Farms. This Java-specific implementation lends support to the general applicability of Request Based Distributed Computing (RBDC) for client centric distributed computing.

WADI is an acronym of ‘WADI Application Distribution Infrastructure’. WADI started life as a solution to the problems surrounding the distribution of state in clustered web tiers. It has evolved into a more generalised distributed state and service framework.

The Wadi Docs describe an Invocation mechanism that shares features with RBDC. The Invocation Interface is a tier-agnostic encapsulation of a remote call. Here is a first-cut comparison:

Similarities

• Both use the idea of Tier-Agnostic Requests
• They have similar session-state mechanisms. See here for one proposal about state within RBDC.
• Both delay location of computing decisions until run-time.

Differences

• Wadi is targeted for use within a server farm, where as RBDC is proposed as starting in the client and works into the server farm with the same mechanism.
• Wadi maintains centralised knowledge of the location of active Java objects whereas RBDC works as an extension of http’s native request by request invocation pattern.
• Wadi is programmed specifically for Java, RBDC is proposed as a generic mechansim.
• Wadi is visible to the Java programmer. RBDC is proposed as a generic mechanism that could become as ubiquitous and ‘invisible’ as http requests are today.

In summary, the usage of Wadi in the server farm, serves as a pointer to the potential of RBDC in the client and server.

Recently my attention has been directed to Microsoft’s Volta split-tier technology. Volta is addressing the same set of issues as Request Based Distributed Computing (RBDC). Key issues directly addressed by both Volta and RBDC include:

Drivers

• Build Distributed Applications
• Provide programmers with a unified programming model (i.e. not deal with a separate programming model on the client)
• Build Mult-tier applications
• Use existing technologies
• Delay architectural decisions about the splitting of workload between client and server
• Enable applications to ‘run anywhere’
• Provide a Language agnostic mechanism
• Use a Client agnostic approach

Not withstanding that Volta deserves credit for being a real-live (beta) product while RBDC is still in gestation as an architectural idea, I want to argue that RBDC which is based on tier agnostic requests, is an architecturally cleaner solution to the problems of client centred distributed computing.

The three areas that I would like to highlight are simplicity, generality and run-time architectural decisions.

Simplicity
If you look at these illustrations of RBDC the tier agnosticism of requests leads to an extremely simple mechanism for distributed computing with equivalent expressive power to Volta.

Generality
Volta is specifically targeting the .Net platform whereas the RBDC mechanism is not just language agnostic, but Virtual Machine agnostic. Of course, the Java VM crowd could dupllicate the work done by the Volta team for .Net - but is that a good idea when a more general mechanism is available?

Run-Time Architecture decisions
While Volta provides the ability to make architectural decisions late in the development process - they still need to be decided during the application build. In contrast, RDBC provides a mechanism where these decisions may be made at run-time.

A Question
Reading the Volta website has confirmed that the drivers of RDBC are real and perceived by others in the IT community - what is the best approach to solving them?

The purpose of this post is to illustrate the behaviour of Request Based Distributed Computing (RBDC). This is how I summarised RBDC in a recent post:

Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution - instead issues like availability of computing power, intellectual property and security will dictate this at run time.

Using the mechanisms explained below the need for separate programming models on server and client is removed. RDBC is language neutral, but for illustration purposes, in the following example lets assume that the server code is written in PHP.

Distributed computing may be facilitated by mobile code moving from the server to a browser that is equipped with one or more RBDC compatible Virtual Machines. In Diagram 1 the example Virtual Machines (VMs) are in circles labeled “hXXX” one for each of 3 major web environments. The VM’s in server and client are identical. Notice that the server does not return the requested “Resource A”, but rather the code that when evaluated will generate the resource. The server does that because the client has indicated in a header of the http request that it is ready to accept mobile code. The client caches the returned code in accordance with the http cache headers. The evaluation of the code is done in the client.

DIAGRAM 1

While the cache entry for the returned code is still valid, the client can reuse it without communicating with the server. In Diagram 2 the client is again requesting resource A and is able to generate the resource autonomously.

DIAGRAM 2

Meanwhile - other users of the same application are using thin clients or legacy browsers without RBDC VMs built-in. In Diagram 3 you can see a thin client making the same request of the server - in this case - the server automatically returns the requested resource. The code is evaluated on the server.

DIAGRAM 3

In some circumstances, perhaps due to Intellectual Property or security concerns a system owner will want a code to always run on their server. In Diagram 4, even though the client is ready to receive mobile code, the code for resource B is marked as “Not Mobile” and therefore the code is evaluated on the server.

DIAGRAM 4

See here for a more detailed description..

It has been recently pointed out to me that the mechanisms underlying Request Based Distributed Computing - RDBC (see primer) are related to Continuation Passing Style CPS, Closures, Lazy Evaluation and Mobile Applets. This is a good insight. Lets have a look at it.

The CPS pattern is where

the caller passes the callee code which the callee runs when when the callee is done with his unit of work. Return never passes to the caller, but rather to the third party designated by the caller.

CPS is a widely used programming style that addresses different kinds of issues to RDBC. CPS does not address the question of the locus of code evaluation whereas with RBDC there is an explicit mechanism that controls whether evaluation proceeds in the callee or the caller. Also, in CPS the callee operates with implicit trust that the caller will pass a sensible continuation, in RBDC the callee (server) does not trust the caller (client) and never receives code from the caller.

Closures is a mechanism that associates a function with state that lasts between invocations. Closures are often used in languages (like lua) where functions are themselves first-class objects. Closures and RBDC share at least one similarity. If functions are first-class objects then variables may hold functions (ie code) whereas we are used to variables holding values. With RBDC http requests may transparently return functions (ie code) whereas we are used to http resources being returned. Unlike closures, RBDC does not bind functions with state.

Lazy Evaluation is a computing strategy where an expression or function remains unevaluated until the result is required for further computation. RBDC can be characterised as a Lazy Evaluation strategy - sometimes. RBDC also supports Eager Evaluation . A point of the RBDC paradigm is that the location of execution is decided at run-time based on availability of computing resources, intellectual property and security concerns.

Request Based Distributed Computing is quite similar to the movement of applets using java.net.ContentHandler.getContent but a key difference is that the mechanism is generalised, independent of the language employed and the programmer does not need to know where the code will execute.

Another implicit feature of RBDC (inherited from http) is that the caller (client) can cache code received from a callee (server) and can proceed autonomously while the function code cache entry remains valid.