Jini and JavaSpaces: Supporting Technologies
This chapter is from the book
This chapter is from the book
This chapter is from the book
Jini is about federating and organizing services on a network and allowing clients to discover and use services. The Jini framework is designed to minimize the amount of human intervention required to manage services.
When you first start establishing a Jini environment, you may doubt that the goal of minimal human intervention was attained. There are a number of services that need to be started in order to deploy a basic Jini network. The initial process can be difficult, especially if you are new to remote method invocation (RMI), but after your network is established, the base services seldom need administration or management.
There are three infrastructure services that will be required somewhere on your Jini network. They are as follows:
-
An HTTP server that supports dynamic downloading of code
-
The Remote Method Invocation daemon (rmid) that provides the distributed remote object lookup and activation mechanism, covered later in this chapter
-
The Jini LUS that provides the service registry and the service lookup capabilities on the Jini network, which is covered in Chapter 4, "Building on Jini Foundation Concepts."
The HTTP Server
The HTTP server should not be new to you. Anyone who has surfed the Web has encountered an HTTP server. It is based on support for the HTTP protocol, which is the standard protocol for fetching Web pages across the Internet. Jini requires that an HTTP server be available on the network—or a server capable of file transport (ftp)—because Jini uses this familiar protocol to transport files (code) from machine to machine.
The HTTP Server is one of the first services that you will start when setting up your Jini network. This enables Jini to transport downloadable code to applications when the applications need it.
You can run one or more HTTP servers on your Jini network. I recommend starting with a single HTTP server. You will want to monitor when the code gets transported across the network by various service requests. It is much easier to start and monitor a single instance of a service until you are comfortable with the service interactions. It might then be appropriate to introduce additional servers to support multiple service configurations, redundancy, scalability, and unique application requirements.
The Role of the HTTP Server and Protocol
Any HTTP server should be able to satisfy the requirements of Jini. The simple and familiar GET method of the HTTP protocol is used to request a specific file (URL) for download. We will discuss the mechanics of requests in the section on RMI, but for now just recognize that requested files are jar or class files necessary to instantiate objects to process distributed requests.
Jini-Supplied
The class com.sun.jini.tool.ClassServer that is supplied with the Jini distribution implements a simple HTTP server for serving up jar and class files.
NOTE
You can download the Jini binaries and source code from the Java Developer Connection at http://developer.java.sun.com/developer/products/jini. Appendix A, "Environment Set Up," provides the necessary links and resources for the Jini distribution.
The HTTP server can be started with the following command on Windows:
java -jar %JINI_HOME%\lib\tools.jar -port 8080 -dir %JWORK_HOME%\lib -trees-verbose
where %JINI_HOME% references the Jini implementation directory, for example C:\files\_Jini1_1; and %JWORK_HOME% references the download directory that contains the jar and class files that you will expose to clients. Any files that you want to make available to clients or services should be placed in this directory location.
The other arguments include:
-
[-port port]
-
[-dir dir]
-
[-trees]
-
[-verbose]
The default port is 8080 and can be overridden with the -port option. The default directory on Windows is J: and the default directory on non-Windows systems is /vob/jive/jars. The default can be overridden with the -dir option. By default, all files under the default directory (including all subdirectories) are served up via HTTP.
If the -verbose option is given, then all attempts to download files are output to the console.
The -trees option can be used to serve up individual files stored within jar files, in addition to the files that are served up by default. If this option is used, the server searches all jar files in the top-level directory. If the name of the jar file is name.jar, then any individual file named within that jar file can be downloaded using a URL in the form of http://host:port/name/file.
When this option is used, an open file descriptor and cached information are held for each jar file, for the life of the process.
In the examples, I've set the following Windows variables to define the location of the Jini install directory and the location of files available via the HTTP server. Your setup will probably be different.
set JINI_HOME=D:\files\jini1_1\ set JWORK_HOME=C:\JiniJavaSpaces\services\lib
GUI-Activated
Jini also comes with a GUI-supplied service activation program. It enables you to enter the required and optional parameters to start Jini services in a tabbed pane as an alternative to scripts.
The following command starts the service launcher interface. From the command prompt, type the command:
java -cp %JINI_HOME%\lib\jini-examples.jar com.sun.jini.example.launcher.
To use the launcher, you can open and edit the properties file located under the /jini1_1/_examples/launcher directory from the file menu. This will generate the tabs shown in Figure 3.1 and enable you to customize the parameters to your environment. There are properties files for both Unix and Windows that supply a list of default values.
){kind=link}
After you load the appropriate properties file, your display should look similar to this:
If you are new to Jini, you can use this interface to examine the basic parameters that are available to start Jini services in addition to rmid and the HTTP server. This will help you become familiar with the commands that are used to start the various services.
To start the Web server supplied with Jini, simply select the WebServer tab and set the following properties, as seen in Figure 3.2:
){kind=link}
-
Executable jar file: Specify the path to Jini tools.jar
-
Port: Specify the port on which to run the HTTP server
-
Document Area: Specify the path from which to serve jar files
Figure 3.1 A graphical view to starting and stopping Jini services.
Figure 3.2 Example Web Server parameter settings.
Now select the Run tab and start the Web server. On the console you will see the command invoked and a list of the files that are in the directory pointed to by the -dir argument of the Document Area property.
If the service failed to start, you might want to check the "Gotchas and Common Failures" section in Appendix A to troubleshoot the problem.
Alternatives
As mentioned at the start of this section, any HTTP server should be able to perform the functions required to support Jini. In fact, the Jini HTTP server implementation is a minimalist approach to satisfying the startup requirements.
If you already have a Web server, check your server documentation to determine the necessary configuration parameters to access files. This is usually nothing more than a parameter in a startup script indicating a root directory or path where you place Web files.
Now let's take a look at another infrastructure service: remote method invocation (RMI). RMI is often the source of confusion when establishing a Jini environment. For this reason, it is important to understand how RMI fits into the Jini architecture and ensure that you understand the dependencies between RMI and the Jini environment.