Recent top five:
Let's talk about exceptions ...
How do you handle exceptions? Do you think upfront about the type of exceptions that you want to catch or do you just let
the outside world handle it?
-- Jeroen van Bergen in JW Blogs
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
Jini's conceptual simplicity is impressive, but newcomers may find the complexity of setting up and running a Jini system daunting. Just to run a simple Jini system, you need to launch six or seven processes:
rmidThe following figure illustrates this deployment process.

Deployment diagram
These HTTP servers serve jar files or classfiles to the Jini client, which uses them to run the Jini proxy in its own process space; likewise, these servers can serve code on the client's behalf, for use in events.
HTTP servers, by themselves, are of course not Jini-specific; they are familiar from the World Wide Web. On the Web, the deployment scenario is simple: the clients make HTTP requests from the server. In a Jini system, though, any component may need code served on its behalf, and so we may have to set up many HTTP servers for even the simplest systems. As the Jini Testing Handbook at Jini.org puts it:
The codebase property and dynamic downloading of code can be a confusing hurdle for many Jini programmers.
We need a simple code-serving process. During development, we don't want to repeatedly stop and restart the system. Even after development, we'd like to simplify deployment of the system, with all its associated clients, services, and HTTP servers.
Several helpful solutions exist. I review these options for serving code, and discuss their pros and cons for various scenarios. In this article, I don't cover Jini basics, remote classloading principles, and other configuration problems, including log files, codebase definition, and security restrictions. (See Resources for information on these topics.) Instead, I focus on technologies useful in deploying a Jini system's code-serving portion. For this article, I assume you're using Jini's reference implementation.
Before reviewing some good solutions for Jini code-serving, let's eliminate some poor solutions. First, you may be tempted
to give a file URL as a codebase (such as file:///usr/myjiniservice/lib/myjiniservice.jar), which may even work, but it limits your Jini system to one machine. Jini's whole point is to construct distributed systems,
so don't use file URLs!
Second, since you typically run one HTTP server per machine, using port 80, you may be tempted to serve all the code for your Jini system from one HTTP server using one port, using all classfiles from one directory or serving them in one jar file. Don't do it. This setup may work for development, but when you deploy the system on multiple machines, you will have to divide the classfiles among the machines, which means different HTTP servers. Copying all classfiles to all machines would obviate the purpose of dynamic classloading: an application dynamically downloads the classes it needs. The complexity of multiple HTTP servers, each serving only the code relevant to one Jini service or client, may be daunting, but you shouldn't bypass it, even during development.