Deploy code servers in Jini systems

Set up HTTP servers for dynamic code download

1 2 Page 2
Page 2 of 2

The Jini 1.1 distribution includes a StartService class, which can launch multiple Jini components in separate processes (using Java's Runtime.exec() method). It can launch everything necessary, including rmid; HTTP servers on various ports; and infrastructural Jini services, such as the reference lookup, transaction, and JavaSpace services. It can even launch your Jini clients and services. StartService is not a standard Jini class, but rather part of Sun's reference implementation.

To use the StartService graphical user interface (GUI), run the class com.sun.jini.example.launcher.StartService. Start by examining the provided default property file (jini11_unix.properties or jini11_win32.properties in the examples directory next to StartService.java). The default properties file defines required settings for all infrastructural components. You can use most of the defaults, but change the settings to give the appropriate local host address. (Don't use localhost or 127.0.0.1, which are useless when you work with more than one host.) Add new entries for your own Jini services and clients with their HTTP servers on different ports.

StartService is easy to set up, since configuring some properties is easier than writing a script. However, the StartService GUI is less automated than a script, requiring some manual clicking every time you start the services. (The GUI has an option for stopping the processes, so at least you don't have to restart the GUI on each development iteration.) Another problem is the processing and memory burden of multiple VMs, since all components still launch in separate processes. Also, this system interface proves unusable when you move to multiple-machine deployment.

An alternative to StartService is the open source Vagrant project, available on Jini.org. Vagrant runs an entire Jini system in one process, reducing the resource burden.

Enterprise-strength HTTP server

You may already be running an enterprise-strength server such as Apache on your network, perhaps to serve files for your Website or to provide Web services. In that case, you can simply configure your server to also serve code for each relevant Jini process. Since you want to serve code for different processes separately, configure your server to use a different port and web-root directory for each Jini process's code. Enterprise-strength servers let you define virtual servers (called Web applications in Java 2 Platform, Enterprise Edition (J2EE)) that run isolated from each other. Take advantage of this feature to isolate code-serving for different Jini components.

In an enterprise-strength HTTP server, you can take advantage of a server that is running anyway. You get all the power of an enterprise-strength server: Transport Layer Security (TLS), caching, HTTP/1.1 support, management tools, and so on. By simply reconfiguring the virtual servers, you can easily distribute the processes over several machines when the time comes. On the other hand, if your Jini components run on multiple hosts, you have to either run a server on each one or gather all serveable jar files onto the server machine, which increases coupling between Jini components.

Other creative approaches

You don't have to use HTTP to serve code. Any software service can do the trick, as long as it can send the bundle of bytes that constitute a jar file. Jerome Scheuring presented an interesting idea at JavaOne 2000 of a Jini service that serves code (see Resources). Until that is implemented fully -- a good challenge for the Jini Community -- HTTP is probably the simplest way to serve code.

Jiro, a network management system layered on top of Jini, takes an interesting approach. The Jiro developers recognize that "maintaining a class server is a laborious task" and provided a service in the Jiro Deployment Station that not only serves as a registry for publish/subscribe event notification, but also serves the code needed to execute all registered events.

Code-serving option summary

The table below summarizes the advantages and disadvantages of code-serving options, with hints for the appropriate usage of each one.

Deployment options for code servers

OptionAdvantagesDisadvantagesRecommended usage
Scripts
  • Flexibility in reconfiguration
  • Easier to write than Java
  • Requires script-language interpreter (to use a full cross-platform scripting language like Python, Ruby, or Perl)
  • Memory burden of multiple processes
  • Development
In-process HTTP server for each component
  • Closely associated with the Jini service, so it can serve exactly the same code that the service uses
  • If it responds to all HTTP requests, it can violate security by serving code that should not be served
  • Incompatible with RMI activation
  • Deployment, particularly in resource-constrained environments
All-in-one system interface
  • Simplest to set up
  • Low memory burden (for technology like Vagrant, which runs everything in-process)
  • Not scaleable to systems with multiple hosts
  • Creates unnecessary coupling between Jini components
  • Not scaleable to multiple services
  • Learning Jini
  • Early stages of development
Enterprise-strength HTTP server
  • Enterprise-class features like HTTPS, HTTP/1.1, and so on
  • May already be present on the network for general HTTP-serving
  • Separates services from their code by centralizing the code-serving
  • Deployment, particularly where enterprise features are necessary

At your service

HTTP servers need to find their place in your Jini architecture as much as services, proxies, and clients. With the above techniques, you can structure your code-serving to account for your needs -- easy deployment, security, and other aspects of a well-designed Jini system.

Thanks to Jennifer McGinn and the Jini team at Sun for their helpful comments.

Joshua Fox specializes in developing Java distributed systems. His past projects include a clustered server for collaborative Web browsing and a servlet-enabled Web server. As a software architect at Unicorn Solutions Inc., he currently designs software for the ontological meta-analysis of data structures and distributed transformation of enterprise data. You can view his software engineering Website at http://www.joshuafox.com.

Learn more about this topic

1 2 Page 2
Page 2 of 2