The six core cajo classes

The six fundamental classes of the cajo project are the key to thoroughly understanding the framework. Three are from the gnu.cajo.invoke package, and three are from gnu.cajo.utils.

From package gnu.cajo.invoke:

• Invoke: A single method interface, and the essence of the framework. The one method:

  Object invoke(String method, Object args) throws Exception;

  defines how one object calls another. The method name, and the arguments, if any, are provided. The method result, or the Exception, if any, is returned. It represents dynamic reflective invocation, to eliminate the need to create individual RMI stubs for each type of object, and for clients to have all these stubs as well.

• RemoteInvoke: A bodyless interface. Its purpose is to determine if a reference to an object is local or remote. The simple test is:

  if (object instanceof RemoteInvoke) {
     ... // the object reference is remote
  } else {
     ... // the object reference is local
  }

• Remote: This is the real workhorse of the framework. Its primary purpose is to make any object remotely callable. The object to be remoted in passed into its single-argument constructor, and the reference to Remote can be passed to remote Virtual Machines as method arguments, or returns. It implements the Invoke interface, to allow any public method on the wrapped object can be called. The only restriction is that it cannot handle primitive types; the arguments and return types both must be objects.

  It also provides the fundamental static invoke method, which provides full local/remote transparency. Its signature:

  Object invoke(Object object, String method, Object args) throws Exception;

  allows method invocation on any object, local or remote! This allows applications to use an object locally, and later migrate it to a remote object, with no source impact. This can create the need for reference locality testing, as explained in the RemoteInvoke class description above.

  It is also home to the critical static config method, used to configure the network parameters for remote operation. It is typically called once, usually after the startup of the application. It also provides some other useful utility methods. The only RMI stub needed by any application, is for this object.

From package gnu.cajo.utils:

• ItemServer: This class is used to bind Remote objects, using application specific names, so their references may be requested by other Virtual Machines. This is called static binding, in this framework . Remote Virtual Machines typically use the static utility getItem method of the Remote class; to specify the hostname, and the name String under which the remote object reference is bound. It can also be used to bind objects contained in separate jar files. This greatly helps in modularising application functionality.

  It also houses the acceptProxies method. When called, it will allow remote Virtual Machines to send customised objects, that will exist in its local address space. More on that in the CodebaseServer discussion coming up.

• Multicast: This class is used to broadcast remote object references over the network. Remote Virtual Machines can also use this class to receive these announcements. This is called dynamic binding, in this framework. Remote Virtual Machines use the announce method to broadcast their remote object references, and the listen method, to receive these broadcasts. It allows references to Remote objects to be obtained spontaneously, without having to know the TCP address of the host serving it.

• CodebaseServer: This auxilary class has two fundamental purposes. First it is used to provide class definitions to remote Virtual Machines. This allows a sending machine to pass locally defined objects, as method arguments, returns, or exceptions; and for those objects to exist locally in the address space of the receiver. As mentioned previously, the receiver must have called the acceptProxies method, as this functionality is disabled by default.

  The second major function of this class, is to act as a specialised application server. It will provide requesting browsers the generic visual proxy viewer client, either as an applet, or as an application via WebStart. Strictly speaking, if this application server functionality is not needed, any standard http or ftp server could be used in its place. In that case, the file server need not even be operating on the same machine, as the cajo server.