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.