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..