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?