As a followup to the recent JavaSpaces
article published on TSS, this article attempts to address the headaches of dealing with remote codebases during the deployment of Javaspaces applications. Source code
in a complete Eclipse project is included, as well as scripts for running the code.
Anyone who has used Javaspaces has probably achieved a measure of success on one or two machines, then started to think more about how to deploy their solution. They might ask...
"How do the other
computers get the libraries needed to execute work without my altering their classpath?"
This is where the "codebase" comes in. Javaspaces/JINI (and other Java/RMI technologies for that matter,) have the ability to query a url for a particular class or jar file, and receive bytes from that request. That downloaded bytecode can then be added to the ClassLoader of the running JVM. For further explanation, read "How Codebase Works"
In short, an Http server can easily serve classes OR jar files. However, configuring the client computers to take advantage of the available code still exists as a task. The scenario can increase in complexity based on added jars and new tasks to execute. One day, three jars served up may be enough. A month from then, perhaps fifteen jars are needed.
If you didn't read the article mentioned above - Note the following
... If the codebase url ends in a slash - "/" then the url points to the root of a classpath. However, if the url is a list of jars, separated by spaces, then that specific jar is served by the Http server instead. It is possible to do both:
So if we serve multiple jars to the network, then obviously this configuration path can become long. When mutliple machines start participating, maintaining the proper list can be a problem. Also, one hard coded Http server address is hardly fault tolerant. Some failover ability is needed and lord yes, some simplicity.
I ran into this problem myself while working with a couple Grid Computing frameworks
and decided to make my life more simple. The code for my solution can be downloaded here
, free to anyone who'd like to use it. The code is simple in concept and involves three components:
1. A small Http Server to handle requests.
2. A multicast listener (my own grid client processes extend a multicast base class that finds the url automatically on a LAN)
3. A jar indexer. The indexer should be pointed to a directory, and will recursively index every jar found in its path (including subdirectories.) One url is then needed to serve any class file found in any of the jars.
What this gives me, is the ability to always treat my jar serving an Http address as if it's pointing to the root of an unzipped classpath, even though I may be actually serving classes from fifty jar files. Further, my grid clients can automatically find new jar servers if one of the jar servers goes down, since the servers themselves listen for requests and answer with their own url. This means that none of my grid computing remote computers require any rmi codebase configuration parameter at all
. All I have to do to serve a new jar is drop the jar file into the path my jar server is indexing and it will be picked up and its classes will be available.
I am currently working on a more robust solution with a visual administration interface coupled with the ability to manage participating grid client tasks.
Download the source code for the solution described above, here.