“STEPS Toward The Reinvention of Programming”[linkmoved] 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.