Opera Unite and Tier Agnostic Computing

Posted on June 16, 2009 Written by

Opera has just released Opera Unite web server in the browser technology. Here is analysis by Mashable. Opera Unite is an enabling technology for tier agnostic Request Based Distributed Computing (RBDC). Key issues directly addressed by Opera Unite 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
  • Enable applications to ‘run anywhere’
  • Provide a Language agnostic mechanism
  • Use a Client agnostic approach

Conclusion
Reading the Opera Unite announcement has confirmed that the building blocks of RDBC are coming into being.

Filed Under: Request Based Distributed Computing Tagged: , , ,

Tier-agnostic Requests and Microsoft Volta

Posted on February 8, 2008 Written by

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?

Filed Under: Request Based Distributed Computing Tagged: , , ,

RBDC Illustrated

Posted on February 6, 2008 Written by

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
RBDC 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
RBDC 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
RBDC 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
RBDC Diagram 4

See here for a more detailed description..

Filed Under: Request Based Distributed Computing Tagged: ,