|
 |
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.
|
|
 |
|
 |
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.
|
 |
|
 |
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:
- The host requests the client
- The CodebaseServer returns instructions on how to do this
- The host requests the client codebase
- The CodebaseServer provides this
- The host asks the server item for its graphical proxy
- The server item provides this
- The host requests the codebase needed by the proxy
- 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.
|
 |
|
 |
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 :-)
|
 |
|
 |
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.
|
|