John Catherino's Blog

Community Archives

Messaging is degenerate RPC

"Avoid the telephone; the network is unreliable: the post is superior."

public final class Queue implements gnu.cajo.invoke.Invoke {
   private java.util.LinkedList list;
   private final Object object;
   public Queue(Object object) { this.object = object; }
   public synchronized Object invoke(String method, Object args) {
      if (list == null) {
         list = new java.util.LinkedList();
         new Thread(new Runnable() {
            public void run() {
               try {
                  while (list.size() == 0)
                     synchronized(Queue.this) { Queue.this.wait(); }
                  String method = (String)list.removeFirst();
                  Object args = list.removeFirst();
                  gnu.cajo.invoke.Remote.invoke(object, method, args);
               } catch(Exception x) { return(); }
            }
         }).start();
      }
      list.add(method);
      list.add(args);
      notify();
      return Boolean.TRUE;
   }
}

Take that .NET!

Thanks... and good luck Bruce!

Now people can develop sophisticated solutions, with little effort, time, skill, or even knowledge!

The cajo what?

Inside the World Wide Virtual Machine

The network is a vast collection of objects, ready to be used to create other objects.

An application is an object, which itself is composed of, a collection of objects.

• An object has 1 or more public methods,
• An object has 0 or more non-public member objects,
• An object's public methods interact with 0 or more private member objects, with 0 or more argument objects, to return 0 or 1 result object; or to throw an Exception.

• Local Objects: existing in the local VM address space.
• Remote Objects: existing in the address space of a remote VM, linked by the network.
• Proxy Objects: existing in the local VM address space on behalf of a remote VM, and may (or may not) be communicating with it.

• Local objects are instantiated, either via a new or newInstance method invocation; or are deserialized from an ObjectInputStream.
• Proxy objects are obtained via a remote object method result, or exception.
• Remote objects are obtained via a request from a remote VM; or via a remote VM broadcast. (sometimes called listening to radio station WWVM :-)

• A local object can be passed to a remote object, only if allowed by both sides, where it will exist there, as a proxy.
• A remote object reference can be freely passed between all objects and Virtual Machines.
• A proxy is unique to the runtime in which it exists, and cannot be passed to another VM.

It is expected that all proxy objects will be hosted in a JNLP/Applet-type sandbox.

The World Wide Virtual Machine

Disclaimer: This entry is in no way meant to slight the many other fine distributed frameworks out there. It’s just that this one is designed for us non-rocket scientists. :-)

I host a free project here on java.net called the cajo project. It allows any Virtual Machine to easily expose access to any of its selected objects to Remote Virtual Machines, as well as to send any of its selected objects to RVMs. It offers a very simple yet highly flexible framework for applications to work together. Most importantly, any existing object can be made remotely usable, with no changes to its source; an application simply adds this framework, not restructures around its requirements. I have found this unique amongst distributed frameworks.

A client can obtain a remote reference to an exposed object in one of two ways. It can request one explicitly, using just the name of the server, and the name under which the exposed object is registered, if it knows these things. In the framework, this is called static binding. It can also listen for object reference broadcasts, sent from RVMs. This is called dynamic binding. The references can then be freely shared in turn with other remote objects. Exposing an object for remote reference is done conversely; it can be bound locally under a name, or be broadcast to all listening VMs, even both.

Clients can invoke the remote object’s methods, and receive the resulting return, just as though it was a local object. How does the client know how to use a remote object? The object can implement a getDescription() method, it would provide detailed usage information. The object often implements a getProxy() method, it would generally return a graphical user interface component with which to interact with the remote object. The framework also features a standard generic client, which can be run as applet in a browser, or as an application via JNLP, to remotely host the GUI component.

Any VM can send an object (or remote object reference) to an RVM, as an argument to one of its methods, or by returning it as a method result. The objects will physically exist locally in the RVM, i.e. in the same address space, as its own objects. These objects are known as proxies in the context of this project, as they exist to act in a remote location, on behalf of their sender. The previously mentioned the getProxy() method is used to return a GUI proxy object.

The framework borrows from the best concepts of Jini, CORBA, and DCOM, but it is far smaller, as powerful, and much simpler to use. The core framework consists of only two packages; a total of only 13 small class files. It can be so small and easy to use, as it does not impose any application semantics beyond those outlined above. It comes with a detailed example file, ample documentation, and several support fora. It is completely free, licensed under the GNU LGPL, to allow both free and proprietary applications to operate together.

The framework is currently running on all Java Runtime Environments; J2EE, J2SE, and even J2ME. It is in active use on Linux, Windows, Solaris, and OSX systems. The goal of the project is to foster the creation of a WWVM. This is an exciting shared space of applications and object libraries, where they all appear and are used as though they were local, to foster the creation of new dynamic, interactive application networks. All VMs are free to join, from big mainframes, to tiny PDAs. (You can use any JVM compatible language, even Java)

Please come visit the WWVM community, all are welcome. Participants needed. :-)

Java raised to the power Linux

For passionate Java developers, the network is the computer. However Java, and in particular its runtime environment, require a highly sophisticated operating system on which to run. Enter Linux; you would be hard pressed to find any system with more features. So, how does Linux increase the power of Java?

First let’s look at what Linux represents; it is a free, heterogeneous, network-integrated operating system. It runs on many hardware architectures (RISC, CISC…) and many platforms (ARM, PPC, x86, SPARC…). On the other hand, Java is a heterogeneous, network-integrated language. It is architecture agnostic, meaning no recompiling, and its code is network loadable. Together they can provide a ubiquitous standard environment, on a diversity of platforms.

Next look at all of the fine Java projects here at java.net, and other places, like Sourceforge and Savannah. Not only are our numbers increasing, but also another interesting thing is happening. You’ll see all sorts of projects to develop standard utility applications; browsers, mail clients, office suites, and even media players. Are we reinventing the wheel? No. We are inventing the ubiquitous wheel. Very soon all major utility applications will have been rewritten in Java.

Finally consider how easy it will be to make useful new devices. Design the hardware, bring up Linux, add in Java, and presto! A multitude of pre-written software, from enthusiastic developers, all dynamically loadable. Innovation and platform diversity is an exciting vision. Would all this flexibility require Java to be open source? I believe yes, to be as adaptive as would be required for this scenario. Linux combined with Java create the opportunity to easily and quickly create ‘JVMlets’, i.e. small fully functional runtime environments, on multitudes of devices, all working together.

There is no question, Java is huge, and I truly believe Java will reach even greater heights, standing on the exceptionally broad shoulders of Linux. Essentially, Linux abstracts the hardware, and Java abstracts the network.

This is where I want to go today, how about you?

This work is licensed under a Creative Commons License.