The cajo grail SDK is used for
transparent distributed computing between remote Java Virtual Machines,
providing client user interfaces via Applets and WebStart. Through the cajo
grail mechanism, services can dynamically discover and use each other, by
specified functionality. Also, via the cajo
CodebaseServer mechanism, rich internet distributed user interfaces to
the service objects can be provided.
The
cajo grail framework allows Java Virtual Machines to dynamically
distribute their functionality, and user interfaces, across the network
transparently. It essentially creates a seamless continuum between
cooperating remote Java Virtual Machines, or in other words, a
World Wide Virtual Machine. (wwvm) The twelve classes defined
in this SDK, along with the included
Cajo object, can provide full functional completeness.
A typical cajo server deployment consists minimally of the following
seven files:
- grail.jar - the standard cajo grail library
- client.jar - the standard cajo controller GUI viewer
- service.jar - the implementation(s) of the service(s)
- controller.jar - hot swappable
- favicon.ico - give the Applet a little style
- splash.jpeg - give the WebStart app a little style
- icon.gif - provide the WebStart app its own icon
- optionally, any other library jars needed by either controllers,
or services.*
*NB: the CodebaseServer class will send any jar files in its
immediate and subdirectories, with the notable exception of
service.jar; service-only jars are conventionally renamed with
the .zip extension, to stop the codebase server from sending them.
The .zip and .jar file formats are identical as far as the Java
runtime environment is concerned.
A hot-swappable controller.jar means that new user interfaces
can be developed for currently running services. Simply
overwriting the controller.jar file will cause all subsequent
Applet/WebStart clients to use the new views.
To view the service client in a full-screen Java Applet, visit the
http service, e.g. http://myhost:port/name. (port and name can be
omitted if they are 80, and main, respectively, keep the trailing slash
though) The application can also be started via WebStart by visiting the
server thusly: http://myhost:port/name/! (note the addition of the
exclamation mark!) Following the WebStart launch, the system will ask if you
wish a shortcut icon placed on the desktop. If yes, clicking on this icon can
be used for all subsequent client application launches.
Notes from a network perspective:
- Servers need to have two open inbound ports (typically 80
and 1196)
- Clients can operate with all of their inbound ports closed
- Servers and clients both can be behind NAT routers