Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Deploy code servers in Jini systems

Set up HTTP servers for dynamic code download

By Joshua Fox, JavaWorld.com, 12/21/01

  • Print
  • Feedback
Jini is one of Java's most exciting applications. With dynamic download of behavior, a universal code-execution platform, and simple construction of distributed systems, it promises to bring us to an era in which disparate software and hardware can simply locate each other and interact, without determining the communication protocol in advance.

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:

  1. The Remote Method Invocation Daemon, rmid
  2. A lookup service
  3. An HTTP server for the lookup service
  4. Your application-layer Jini service
  5. An HTTP server for your service
  6. The client for your Jini service
  7. If callback code for events needs to be downloaded: An HTTP server for the client


The 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.

  • Print
  • Feedback

Resources