the cajo project
Free, simple, powerful: Transparent Distributed Computing
Supporting cajo proxy objects

The CodebaseServer could be considered the world's smallest application server. It is completely customised to support the cajo framework. The entire server consists of a single class, yet it serves (pun intended) two major roles:
  • First, it provides codebase service; to allow client VMs to run remote objects locally, for which they do not have the local class files.
  • Secondly, it provides client service; to allow transparent distribution of User Interfaces, as either Applets, or as WebStart applications.
Codebase Service

When a proxy item is sent to another VM, it arrives solely as a serialised collection of many coöperating objects, but with no code (i.e. class files). The receiving VM will first check its local codebase to find class definitions for these objects, if it does, it will use them. However, as is often the case with proxies, it will not have the application specific classes needed by the received proxy. When this happens, the RMI framework steps in; it will call back to the item server, and request the class definitions. The primary use of the CodebaseServer is to manage this transfer, and it does this automatically, and transparently. The necessary classes are provided to the remote host, loaded into its runtime, and the proxy is free to operate locally, in the context of that VM.

For efficiency, all proxy-specific class files, and other files needed by the proxy, such as images or localised string tables, are typically packaged into a single jar file. The supplied example illustrates how to do this very easily.

You will need a codebase server any time you are sending proxies to another remote machine that will not have all of the class files needed by the proxy in its local classpath. You will also need one if you are sending application specific objects as arguments, or method results, to a remote machine.

Client Service

If the tutorial conclusion seemed almost magical; this is due to the functionality of the codebase server. The previous discussion on codebase service could be provided by any general purpose webserver. What makes an application server special, is knowing what to do with all that "extra-stuff" appended to the end of the URL.

As explained previously, the CodebaseServer first checks if a jar file is being requested, if so, it fulfills the request. However, when the request is not for a jar file; here is where things get interesting.

The CodebaseServer will parse the URL to extract additional meaning from the request. Based on its content, one of three things will happen: First, and trivially, it may not understand the request, in this case, the request is rejected. However, if the request is understood; now one of two things will happen:
  • If no exclamation point is terminates the request, the CodebaseServer will interpret this as a request for a GUI proxy to be run as an applet, inside the requesting browser.
  • If an exclamation point is terminating the URL, this will be interpreted as a request for the GUI proxy to be run as a WebStart application, on the desktop of the requesting host.
In either case, the remaining URL components are used to configure the client for operation within the requester's VM, as explained in the client topic.

For the curious; the client GUI loading process executes as follows:
  1. The host requests the client
  2. The CodebaseServer returns instructions on how to do this
  3. The host requests the client codebase
  4. The CodebaseServer provides this
  5. The host asks the server item for its graphical proxy
  6. The server item provides this
  7. The host requests the codebase needed by the proxy
  8. The CodebaseServer provides this
An elaborate process, to be sure, but all handled transparently behind the scenes. The source is all there for the curious, but truth be told; just like the Java Runtime Environment source, you do not need to know it, in order to use it effectively. Note: this was only a high-level overview, the mind-numbing technical details were intentionally omitted. If this already has your head spinning, don't worry about it; especially don't worry about the next section, simply go on to the conclusion.

CodebaseServer Sharing

For those out there who want to squeeze out every last gramme of performance, you probably already thought of this, but here it is anyway. Since the CodebaseServer fundamentally performs the functionality of a generic http server, if you do not require the client application service functionality, you can share another item's CodebaseServer (or generic http/ftp server). Simply place your proxy jar file in the working directory of another codebase server, and use the fully-qualified constructor of ItemServer to tell clients where to find the files. Note: The CodebaseServer need not even be in the same physical box as the server items. (Just ponder the implications of that :-)

Conclusion

The CodebaseServer handles the low-level protocol details to make object transfer between virtual machines, transparent. It can allow the generic client object the ablity to display any graphical proxy. Its purpose is to bring the power of proxy items, and remote graphical proxy viewing, to everybody; not just the 'Rocket-Scientists.'


A cajo framework-specific application server, to make proxy service simple.
© 2004 John Catherino, GNU FDL