Java Remote Method Invocation JRMI (White Paper) is a distributed computing capability for the Java Platform. Like the HTC it is designed to facilitate “write once run everywhere” and “code mobility”. Naturally it does it within the paradigm of Java Objects.
The purpose of this post is to give a 30 second comparison of the JRMI and the Hypertext Computer (HTC) paradigm.
The HTC is not so much an extension of a language’s Virtual Machine but a reconceptualised computer – implemented using an extension of the http protocol along with identical Virtual Machines on client, proxy and server. It is language neutral.
No doubt the JRMI has many advantages of its own, however I would like to identify one major benefit that the HTC confers over the JRMI. It is this: the HTC does not rely on the designer choosing the locus of code execution at compile time (either on the client or on the server). To illustrate this lets use the following example from the JRMI white paper:
For example, you can define an interface for examining employee expense reports to see whether they conform to current company policy. When an expense report is created, an object that implements that interface can be fetched by the client from the server. When the policies change, the server will start returning a different implementation of that interface that uses the new policies. The constraints will therefore be checked on the client side-providing faster feedback to the user and less load on the server-without installing any new software on user’s system. This gives you maximal flexibility, since changing policies requires you to write only one new Java class and install it once on the server host.
This same scenario is handled, just as easily by the HTC paradigm. The user interface for examining employee expense reports is implemented in a client. To evaluate policy conformance the client requests a server with an HTTP GET. However the GET is extended with a request header that indicates to the server that the client has a particular virtual machine and is willing to receive a coderesource (ie program) instead of the result of the GET. The server may (at its option) return the current coderesource that defines the policy. The client then executes the coderesource and caches the compiled version of the code. The server set http caching parameters when it returned the coderesource to force the client to update its coderesource cache according to the applications update cycle. The advantage of the HTC’s handling of this scenario is that:
- Thin clients may request the same GET without offering to execute a coderesource and so would transparently be served with the correct result. Alternatively, the processing could be transparently trapped by a proxy serving a network of thin clients.
- While any particular implementation will choose one more computer languages The solution is language agnostic. It would work equally well for the JVM as it would with the .Net CLI
- The solution is very lightweight