ELJonline: Experimenting with Jini on Linux
Jan 1, 2001 — by LinuxDevices Staff — from the LinuxDevices Archive — 3 viewsJini developers promise a very different day-to-day life in the near future.
While using your PC at home, you want two slices of bread toasted. You enter a message: “Any toasters available?” A reply appears on the screen: “I am a toaster in the kitchen. What would you like?” and a menu box pops up. You select the number of slices and the level of darkness, and the slices are toasted. After the job is completed, the toaster announces: “Two slices toasted. Anymore orders?”
You might think this is something out of a Jetsons cartoon or sci-fi movie, but Jini developers promise that this scenario will be as commonplace as TV or VCR remote controls in a few years. Indeed, the speed at which embedded computing progresses indicates that embedded devices will be an integral part of future computer networks.
Background
The traditional approach adopted by the designers of operating systems was based on the simple assumption that a computer has a processor, some memory and a disk drive. There is now a gradual transformation taking place in the design of computing systems. The proliferation of embedded devices has been rapid in the last few years. These embedded devices do not have disk drives. Instead, they rely on a network connection. This transformation in the hardware environment requires new software mechanisms to be developed for embedded devices in networks. Jini technology, introduced by Sun Microsystems, provides a mechanism to create a flexible and dynamic network of varied devices.
What Is Jini?
In the simplest terms, Jini can be defined as a federation of devices and services. A better way of describing Jini would be a set of APIs and network protocols that allow development of a distributed system that federates groups of the users (clients) and the resources (services) required by those users (clients). Jini technology makes a network more dynamic by creating the means for plug-and-play devices (i.e., the smooth addition and removal of devices from the network dynamically, without the need for configuring each device). In addition, Jini provides a programming model that makes it easier for programmers to get their devices talking to each other. According to Benoit Marchal, the Jini concept converts the Java programming model “write once run anywhere” into “write once run from anywhere”.
Java and the Jini Technology
Jini architecture brings object-oriented programming to the network by permitting the separation of interface and implementation. Jini is a Java-specific technology and requires JVM's (Java Virtual Machines) to be present in all devices on the network. Since the devices and software components in the Jini federation need to exchange objects between one another, they require a mechanism to download and run code dynamically. Because the Java programming model provides this mechanism efficiently (mainly because of its Remote Method Invocation [RMI] mechanism), Jini federation uses Java as its foundation. Although Jini is written in pure Java, it is not necessary that the clients or services also be written in pure Java; they can be written in any other language. They just need to communicate through the Jini protocols, making a Jini federation usable even in a non-Java environment.
Main Objectives of a Jini System
The main goals of a Jini system are to
- Provide a mechanism that allows devices to join or detach from a network without requiring any configuration, thus eliminating the need for a system administrator.
- Allow users to share the resources available in the network without requiring device drivers to be installed for each client. This creates an economical system in which devices, data files and software can be conveniently shared.
- Turn the network into a flexible and easily administered dynamic entity.
- Allow different devices based on different network protocols to communicate smoothly with each other. This gives different device vendors more flexibility since they need not agree on network protocols.
- Enable interested clients to be automatically notified about any remote events taking place in the network, e.g., a cell phone embedded in the network can report its battery status.
Components of a Jini System
The three main building blocks of a Jini system are services, clients and lookup service.
A service is anything that sits on the network and is ready to perform a useful function. Hardware devices (e.g., a toaster, printer, disk drive or digital camera), software (such as a computational program to make extensive mathematical calculations), communications channels–even human users themselves–can be services.
Clients can use any of the services available in the network to carry out their tasks. An amusing (but accurate) example is that of the toaster mentioned in the opening paragraph of this article. A more realistic example is the transmission of a picture to a disk drive for storage purposes or to the printing services of a color printer available in the network.
The central organizing mechanism of a Jini-based system is the lookup service that registers devices and services available on the network. It provides the major point of contact between the system and the users of system. Any new service joining the network has to be registered with the lookup services while the clients require the lookup service to assist them in finding the services needed to perform desired tasks.
How a Jini Federation Works
When a device is plugged into the network, it locates the lookup service and registers its service. During the process of registration, the device provides a callable interface and attributes. Thus, all the services in the system have the necessary information available at the lookup service. In order for users (clients) to find their desired service, they query the lookup service for the specific service and then invoke the callable interface of that service. The callable interfaces are exposed and accessed through Java RMI (Remote Method Invocation). The proxy code used to access an interface is stored within the lookup services during the registration process and automatically downloaded by clients at runtime, negating the need for any device drivers.
The idea behind the word “federation” is that the Jini view of the network doesn't contain any central controlling authority. All services form a collection of cooperating but autonomous entities. Instead of a controlling authority, Jini's runtime infrastructure merely provides a way for clients and services to find each other. The client and its enlisted services perform their tasks independently of the lookup service. If the Jini lookup service crashes, any services and clients brought together before the crash can continue working together.
Protocols Involved
A Jini system consists of a runtime infrastructure residing on the network that provides a mechanism by which the services or Jini-enabled devices can be added to the network and registered with the lookup service. The services can then be located and accessed by the clients in the network. This run-time infrastructure is based on three protocols, namely discovery, join and lookup.
1. Discovery
Services and clients locate lookup services using the discovery protocol (see Figure 1). There are two types of discoveries: Unicast and Multicast. Unicast Discovery is used when the address of a lookup service is known. When the address of a lookup service is not known, the client or the service sends a multicast signal and all lookup services present in the network will respond to it. The following steps are involved in the discovery process.
 |
 |
 |
 |
- As soon as a service is connected to the network, it sends a packet containing its IP address and port information to the well-known port of the lookup service. The port reserved for this purpose is 4160 by default.
- The lookup service port inspects the packet and sends an object known as registrar to the IP address of the service using a TCP connection.
2. Join
Services register themselves with the lookup service so that they become part of the federation of services (see Figure 2). This is done as follows:
Figure 2A.
Figure 2B.
- The service invokes a method register( ) on the object registrar obtained from the lookup service, passing as parameter an object called the service item. The method register( ) copies the service item to the lookup service.
- The service item contains a service object that can be used by clients to invoke a method of the service and hence access the service.
- The service item also contains attributes that will be helpful for the client in finding a particular service.
3. Lookup
Using the lookup protocol, clients can send a query to the lookup service in order to find the services needed (see Figure 3). This querying proceeds as follows:
Figure 3A.
Figure 3B.
- The clients invoke a method lookup( ) on the registrar object obtained from the lookup service, passing as parameter an object known as a service template.
- The service template can include service ID or the attributes that should exactly match the attributes present in the service item.
- If it happens that the service object can be copied to the client, the client can then utilize it.
Interfaces–The Heart of Jini
Jini architecture takes advantage of one of the key principles of object-oriented programming: the definition of the service and its implementation are two different issues. In other words, interfaces that define services are different from the classes that implement them. The interfaces and the classes for implementation can even run on separate JVMs and provide a distributed computing environment. The idea behind Jini is that standard interfaces will be developed for various required services. For example, there will be a standard printing interface that will be implemented by all printing services. The lookup service will return a service object that implements this standard interface to the interested client. The client will then use the printing service by invoking methods that are defined in the standard interface. Generally, the service object will be activated in the client's JVM while the code for the implementation of this printing service the will run in server's JVM. The service object will act merely as a proxy to the remote printing service.
HTTP Server and RMI Dæmon
The heart of the above mechanism is Remote Method Invocation (RMI) provided by the standard Java Development Kit. RMI consists of two classes that implement the same standard interface. One class is for the implementation of the service, and it runs on the server. The other class, known as a stub class file, acts as a proxy for the remote service and runs on the client. These stub class files will be delivered to the client's JVM by some server capable of moving these files from the service's JVM to the lookup service and, finally, to the client's JVM.
Generally, an FTP or HTTP server is used for this purpose. Whenever a service runs on a server, a codebase is always mentioned along with the classpath. The classpath indicates the path that will be used by the server for running the service. The codebase indicates the URL from which the stub class files for that service can be downloaded by the client. The codebase should always point to a valid HTTP server, and it should also mention the relative path to the directory where the stub class files for the services are available. The client's program will invoke methods on the service object. It is the RMI dæmon that will forward the method's calls to the server's JVM where implementation for the service lies. Any return values will also be sent back by RMI to the proxy object and hence to the client's program. The whole process is explained in Figure 4.
Figure 4.
Running a Simple Jini Example on Linux
Let us build a simple, practical Jini system. The following steps must be carried out for this purpose. (We built this system using Red Hat Linux 6.1 on Intel architecture machines.)
1) Installing Software
For running Jini the essential software is JDK Version 1.2.2 for Linux, which can be downloaded from java.sun.com/products/jdk/1.2/index.html and Jini Starter Kit JSK Version 1.0.1 or higher, which can be downloaded from www.sun.com/jini/index.html.
The installation instructions for these packages are on the indicated sites. After the installation of the software, Jini can be run on either a network or stand-alone machine. In our case, we established a network of three machines constituting
- machine L as lookup service
- machine S as a service
- machine C as a client
As mentioned above, a Jini Network requires support services such as an HTTP Server and a RMI Dæmon, which should be run on every machine. You can either use the Apache web server (which comes with the Linux distribution) or one supplied by Jini which is in the tools.jar file. We used the Apache web server in our Jini network.
2) Turning Multicast On
Turning multicast on and adding the following paths are essential for running Jini on Linux:
$route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
$ifconfig lo multicast
$ifconfig eth0 multicast
Where eth0 indicates the Ethernet card.
3) Starting the RMI Dæmon
RMI dæmon can be activated by the $rmid & command. The log files for the RMI dæmon are stored in the /log directory. It is always good practice to delete all log files for RMI dæmon before starting a new dæmon.
4) Running the Lookup Service
We have used only one lookup service in our system, although you can have as many as you like depending on the size of your network. We ran it on machine L.
The Jini Starter Kit provides a lookup service called reggie that can be started by a command with certain parameters:
$java -jar
Thus,
- specify a complete path to the reggie.jar file for lookup-server-jarfile
- lookup-client-codebase is the URL for reggie stub class files
- lookup-policy-file controls the security issues
- output-log-dir is used to store log files, and any path can be set
- lookup-service-group can be set to the public group
For example, we run reggie on machine L with the following command:
$java -jar /usr/local/jini1_0_1/lib/reggie.jar
>http://machine_l.group97.org:80/reggie-dl.jar
> >usr/local/jini1_0_1/example/lookup/policy.all
>tmp/reggie_log public
Here, the document root for the machine A was set to /usr/local/jini1_0_1/lib. /tmp/reggie_log must be a nonexistent directory. If it already exists, delete it first. The lookup service will exit after starting and is kept in a passive state by rmid. Step number three should not be performed on machines S and C since they do not act as lookup services.
5) The Jini Service
Let us consider a very simple example on Jini Network that permits a client to enter a temperature in Celsius and then converts it into Fahrenheit and returns it to the client. The important thing to note here is that the whole process takes place on the service side and the client is unaware of the temperature conversion algorithm. Thus, the formula this conversion is performing is a service.
TempServiceInterface.java
This is the interface file for the temperature service program. This interface file should be compiled on both machines S and C since both service and client should be aware of the common interface. The code for TempServiceInterface.java, TempService.java and TempClient.java can be found at www.jiniplanet.com.
TempService.java
The program that does the actual conversion should be compiled and run on machine S, i.e., the service. It is better to use multicast join and discovery in practical cases since the services and clients are usually unaware of the URLs of lookup services. In our simple network, we know the URL of the lookup service and have used unicast discovery.
Compiling the Service
To compile the service code we must specify classpath to the essential jar files. On our machine it can be compiled by giving the command in Listing 1.
$javac -classpath /jini1_0_1/lib/jinicore.jar:/jini1_0_1/lib/jiniext.jar:
>/jini1_0_1/lib/mahalo.jar:/jini1_0_1/lib/mahalo-dl.jar:
>/jini1_0_1/lib/sun-util.jar:/jini1_0_1/lib/tools.jar:/home/httpd/html
>*.java
We have assumed that the source files are in the /home/httpd/html directory.
Making Stub Class File
Stub class file is necessary for the execution of method calls on a remote server. For the above code, stub class file can be made by the command:
$rmic -v1.2 TempService
Running the Service
At this point Jini service is ready to run. The command is shown in Listing 2.
$java -classpath
/jini1_0_1/lib/jinicore.jar:/jini1_0_1/lib/jiniext.jar:
>/jini1_0_1/lib/mahalo.jar:/jini1_0_1/lib/mahalo-dl.jar:
>/jini1_0_1/lib/sun-util.jar:/jini1_0_1/lib/tools.jar:/home/httpd/html/
>-Djava.security.policy=/jini1_0_1/example/lookup/policy.all
>-Djava.rmi.server.codebase=http://machine_s.group97.org/ TempService
The document root for machine S was set at /home/httpd/html.
If everything goes fine, the output on the screen should be “Service Registered”.
6) The Jini Client
The Jini client, i.e., machine C, needs two programs, TempServiceInterface.java and TempClient.java, which can be found at www.jiniplanet.com.
The compilation and running of the client is carried out in a manner similar to the service, except that no codebase is mentioned at runtime. The output on the screen is shown in Listing 3.
LookupLocator = jini://machine_l.group97.org
LookupLocator's host is = machine_l.group97.org
LookupLocator's port is = 4160
ServiceRegistrar = [email protected]
ServiceID = 97ac7e75-6ef4-4df5-4dee-bcbaf8765dff
Service Template is = [email protected]
Service Object is = TempService_Stub[RemoteStub [ref:[endpoint:
[132.100.50.10:3980](remote),objID:[6a87c4d7:a5edda5ba2:-80, 0]]]]
Enter the temperature in Celsius:
45
Temperature in Fahrenheit is = 113.0
Future Study
This article presents a very simple example of a working Jini system. This is not all that Jini technology promises. Other important areas are lookup service browsers, remote events, distributed networks, embedded computing, use of Java Spaces and many others. There is a lot of work still to be done. The Jini community all around the world is working in cooperation to make JINI a fast-growing technology with a promising future. For further information on Jini, visit our web site www.jiniplanet.com, where you can find links to other Jini sites. You can also download the code for more complex Jini systems. For any questions regarding this article, e-mail us at [email protected]
About the authors: Umar Farooq, Zeshan Ahmad Chishti, Furqan Ahmad, and Shakeel Ahmad are final-year undergraduate students in the Department of Electrical Engineering, University of Engineering and Technology, Lahore, Pakistan. They are conducting research on distributed and network computing under the supervision of Professor Shahid H. Bokhari.
Copyright © 2001 Specialized Systems Consultants, Inc. All rights reserved. Embedded Linux Journal Online is a cooperative project of Embedded Linux Journal and LinuxDevices.com.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.