New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Session 8: Jini – The Universal Network?

 

Course Title: Extreme Java                                                                 Course Number: g22.3033-007

Instructor: Jean-Claude Franchitti                                                         Session: 8

 

 

While Java does let you write code that runs on different platforms, it doesn't completely address the problem of integrating those disparate platforms. If you want to connect a digital camera to your computer, you'd better have the right software for the camera. If you want to use the camera on a different computer, you'll probably have to connect it directly to that second computer, and you'd better have the camera's software handy. Drivers for Windows don't work with UNIX, for example. Sometimes you even need different drivers for different versions of Windows.

 

Jini (pronounced GEE-nee) is a set of services and protocols that solves this problem. A Jini-compliant digital camera connects directly to an IP-based network. Other nodes on the network will detect the camera and can download the drivers required directly from the camera. This ensures that the driver matches the target hardware. Since Jini is based on Java, any computer with a Java virtual machine (JVM) can use the driver (in theory, anyway), avoiding the which-driver-do-I-need-for-this-computer problem.

 

At first, this doesn't sound all that radical. But like many simple ideas, Jini has the potential to completely change the way you look at familiar tasks, in this case, working on a network. For example, consider adding more storage to your network. Today, that probably means adding a hard drive to your server. However, with Jini you'll simply plug a storage device in to the network. Everyone on the network will immediately see the storage device, load the appropriate drivers, and start saving and loading data to their hearts' content. This same process works for printers or other devices. It can also work for services that aren't specifically hardware related, such as an email gateway or a service that translates English to Spanish.

 

A Jini Glossary

Discovery - The process a service uses to notify the Jini federation that it is available. Followed by the Join process.

federation - A Jini network, or group of cooperating objects. Sun often refers to this as a federation of objects.

infrastructure - The protocols that allow Jini to work (Discovery, Join, and Lookup).

JavaSpaces - A standard service that provides one way to store objects.

Join - The process a service uses to inform the Jini federation about itself. Preceded by the Discovery process.

lease - A service can grant a client a lease for a particular resource. This lease implies that the client can use the resource for a specified time period (negotiated between the client and the service). If the lease is not renewed, the client must relinquish the resource when the lease expires. Leases may be exclusive or nonexclusive.

Lookup service - A special, predefined service that performs the Join process and lets clients locate available services. If necessary, any client can implement a Lookup service, allowing for peer-to-peer networking.

programming model - Sun refers to Jini-provided programming functions (such as leasing, transactions, and remote events) as the Jini programming model.

proxy object - A stand-in for a remote Jini object. The Lookup service holds the local proxy object and provides it to clients. Clients can call the proxy object just as they would any local object.

RMI - Java's Remote Method Invocation lets you make objects that you can access over the network. RMI forms the core communications protocol that Jini builds upon.

services - Entities that provide functions for clients. A service might be a piece of software, a piece of hardware, or a combination. Services provide proxy objects that clients can call to interact with the remote service. Typically, the proxy object communicates back to the remote object. However, it could perform some or all of the work itself, or communicate to a piece of hardware directly.

stub object - RMI uses this term to refer to an object provided to a Java program that lets it manipulate a remote object. A stub object is similar to a proxy object.

transaction - Jini supports transactions via a special predefined transaction manager service. This lets a client attempt an operation on multiple objects. If the operation succeeds, the client can commit its changes. If the operation doesn't succeed, the client can roll back the changes, restoring the objects to their original state.

 

Inside Jini

Conceptually, JINI is a collection of services. When a service (which may be hardware, software, or both) connects to the network, it transmits a small packet (just 512 bytes) on the network. A Jini "Lookup service" on the network will notice this packet and use it to query the device about its capabilities, and then make that information known to other devices on the network. There might be more than one Lookup service. In some cases, there might be zero Lookup services active, for example, in a peer-to-peer network.

 

When a client wants to use a service -- say, a printer or storage system -- it asks a Lookup service to describe the available network services. If the client can't find a Lookup service, the client can elect to become its own Lookup service. In that case, it broadcasts a request for services to register with it. From that point, the client acts like a Lookup service. This concept of a local Lookup service is ideal for peer-to-peer networks.

 

Of course, the Lookup service is just another Jini service. This service makes up part of the Jini infrastructure as defined by Sun. However, it's possible for third parties to provide their own infrastructure services that add features.

Each Jini service provides functions via Java interfaces. Java's Remote Method Invocation (RMI) handles the network communication and security. You can think of Jini as several layers that build on top of the ordinary JVM.


 

 


A high-level view of Jini technologies and their relationship to Java.

 

When a service registers with a Lookup service, it provides a proxy object. This object exposes the service's functionality and also contains descriptive information about the service. For example, a scanning service might indicate what media it can scan, what resolutions it can provide, and similar information.

 

Typically, the proxy object communicates back to the service provider to perform operations, although how it does so is not important -- the object can use Jini-provided mechanisms or a completely different protocol. A different protocol can be useful for integrating existing services into a Jini network. Of course, an intelligent proxy may do some or all of the work itself, if that's appropriate.

 

When a client looks for a service, the Lookup service provides a copy of the proxy object. The client makes calls to the proxy object that arranges to do the work. Since each part of the network uses Java, the proxy object is transportable among the service provider, the Lookup service, and the client.

 

In Figure 1, you'll see how Jini partitions these functions into layers. The very bottom layer is the JVM that executes Java code. The JVM is what makes it possible for everyone on the network to share code. RMI, which has long been a part of the JVM, provides network communications for Jini clients and services. Jini takes advantage of new distributed security features added to RMI.

Just above the JVM is the layer that makes "Discovery" possible. Discovery is the process that services use to announce their presence so that interested Lookup services can catalog them, using the "Join" protocol. The other part that comprises the core portion of Jini is the Lookup service. Above the Lookup service can be any number of services. One service that Sun supplies is the JavaSpaces service, which provides object persistence.

 

When you look at the layers, Jini seems to contain a lot of code. However, the individual layers are quite small. Sun says the entire Jini core code is around 48KB. The Java Archive (JAR) file that contains the entire version 1 of Jini is under 70KB. However, these small parts work together to create a complex system. The key operation that makes everything possible is the Lookup and Discovery protocol implemented by the Lookup service.

 

Jini consists of only a handful of Java packages for Java programs.

 

PACKAGE

DESCRIPTION

net.jini.admin

Interfaces that services implement to allow administration.

net.jini.discovery

Classes for handling the Discovery process.

net.jini.entry

Abstract classes and interfaces that contain common code for entries that jini stores.

net.jini.event

Handles event delivery over the network (remote events).

net.jini.lease

Manages leaves

net.jini.lookup

Objects related to the Lookup process.

net.jini.lookup.entry

Objects and beans that represent service information.

net.jini.transaction

Support for transactions.

net.jini.transaction.server

Classes for managing transactions.

 

Jini's simplicity makes it possible for devices like printers, scanners, and disk drives to implement Jini directly. You can also have a Jini service that stands in for a legacy service or device that doesn't support Jini, for example, a standard modem that you want to connect to the network. Eventually, Sun would like to make Jini a standard for other devices, like home electronics. One day, your DVD player, digital TV, and telephone may all communicate via Jini. (On the other hand, one day, your digital TV may also be your DVD player and your telephone, but that's another story.)

 

Discovery and Lookups

When a new service starts on the network, it initiates Discovery by broadcasting that 512-byte packet mentioned earlier, which announces its presence and provides a reference back to itself. Interested Lookup services can then request more information. In response, the new service will send the Lookup service a proxy object that contains the interface that clients will use and descriptive information about the service.

 

The object may provide programmatic interfaces that other software uses to control or access the service. The object may also provide user interfaces (in the form of applets) for interacting with humans.

 

When a new service issues a proxy to a Lookup service, the Lookup service grants the new service a "lease." This lease implies that the new service's proxy object is valid for a specified interval. When the lease expires, the service must either renew it, or relinquish the object. This prevents problems when services vanish. For example, if someone removes a printer from the network, its Lookup entry will eventually fail to renew and the Lookup service will discard the entry and associated proxy object.

Leases are negotiated. A client requests a lease of a certain duration. The service then grants a lease for a specific time period, presumably considering the client's request. Leases can be exclusive or nonexclusive depending on the type of resource requested.

 

Notice that, like an IP address issued by a Dynamic Host Configuration Protocol (DHCP) server, the lease expires after a certain amount of elapsed time, not at an absolute time. Using an interval makes it unnecessary for computers to have synchronized clocks. The code related to leasing is in the net.jini.lease package.

 

Exactly how any Jini service performs its work is of little interest, as long as it presents the expected interfaces. A service object might employ other objects to execute certain tasks. In some cases, these objects all need to share a single virtual machine. When this is the case, the service can create an object group. Jini will make sure that objects in an object group always run on the same virtual machine. From the client's point of view, this distinction is unimportant. Clients make calls to the proxy object and that object takes care of whatever details are important.

 

Inner Workings

When all your code is on one machine, events are straightforward. Once you start communicating over the network, events become harder to manage. You can't be sure that you'll get every event. You can't even be sure that you'll receive events in the correct order. Jini provides code in the net.jini.event package to help you manage these problems.

 

Another common problem in distributed environments is managing transactions. The problem here is that you may need to interact with several different objects to perform a particular task. However, if any of the pieces you need aren't available, you'd like to restore everything back to its original state.

 

As an example, consider a bank-teller's terminal. When the teller enters a deposit, the system updates the local branch database, write to the customer's smart card, and also write a record to the main computer downtown.

Suppose the program updates the main computer and the smart card, but finds that the local branch database is down. You'd like to roll back the work you did with the smart card and the downtown mainframe. Jini provides code in the net.jini.transaction package that lets you handle this.

 

You can divide the various parts of Jini into three broad interrelated areas. The infrastructure, or core, consists of the Lookup, Discovery, and Join protocols. Without these parts, nothing can happen. Just as the JVM is at the core of Java, these pieces are at the core of Jini.

 

The second area contains the leasing, distributed events, and transaction support. These fundamental components enable the core, much as, say, dynamic object manipulation functions enable the JVM. All by themselves, leasing, events, and transactions don't really do anything. However, they're essential for your Jini programs and for the infrastructure itself. For example, services lease entries in the Lookup service. When Discovery takes place, interested objects receive events. Sun refers to these parts as the Jini programming model.

 

Finally, services like JavaSpace and others that will appear as Jini evolves are analogous to large-scale Java APIs like Enterprise JavaBeans. These services are the reason Jini exists as they provide the functions that clients want to use. Of course, there is some blurring of these layers. For example, Jini's Lookup is itself a service. It's a special service defined by the system, but it's a service nonetheless.

 

RMI -- The Heart of Jini

 

From the preceding discussion, you should have gotten the idea that Java RMI is at the heart of Jini. RMI is not a new technology (although Jini requires a few new features available only in the JDK 1.2 release, also known as Java 2). If you've ever used Remote Procedure Calls (RPCs), you'll find that RMI is essentially an object-oriented, Java-flavored RPC system.

 

The purpose behind RMI is to let you make Java objects available across a network. All objects with remote capabilities must support the Remote interface. In particular, the object will have one or more interfaces that extend the java.rmi.Remote interface. Each method in the remote interface must signal the compiler that it may throw the java.rmi.RemoteException by using a throw clause.

 

The remote object itself implements the interface (or interfaces) and often extends a standard base class from the java.rmi package. These base classes (like UnicastRemoteObject) provide basic functions that you often won't want to replicate yourself. The remote object has to provide a default constructor (that is, a constructor with no arguments).

 

Of course, the remote object also provides code for the functions it supports via its remote interfaces. The object will also install a security manager. When instantiated, the object will make calls to include itself in the RMI registry (a list of available remote objects). Programs that want to use an object remotely can only access the member functions in the remote interfaces. There's nothing to prevent the object from having other member functions for its own use, however.

 

Programs that are clients of a remote object look up that object using special calls from the java.rmi package. The static object Naming provides the Lookup method for this purpose. The client program supplies this call with a hostname and a remote object name (one that matches the name in the RMI registry). The call returns a stub object that has all the methods available in the remote interface. The client program calls these methods, which causes the same call to occur on the remote object. The client receives return values from the remote object as though the remote object were really the stub.

 

RMI is almost a mini-Jini. Its purpose is to make providing network services practically transparent. The client makes a call to a normal object (the stub). The remote object receives calls and returns values in the normal way. RMI handles all the details: converting arguments into a form suitable for transmission, physically transmitting the data, collecting and converting return values, and transmitting the return values.

 

When you pass objects to remote methods as arguments, the arguments may also be remote objects. In that case, RMI uses a stub object for the argument, which amounts to passing the object by reference. Any change to the passed object reflects in the original object.

 

What if you want to pass a nonremote object? No problem, as long as the object supports Java serialization. Serialization lets you load and store an object. In this case, RMI will "save" the object to the network, and load it at the remote object. This actually passes a copy of the object (a call by value instead of by reference). Changes made to the object argument will not affect the original argument.

 

When you want to work with the Jini Lookup service, you'll do so using a remote object. By the same token, services you write will consist of remote objects. These remote objects may have to provide specific interfaces to support leasing and transactions, but beneath it all, it's still nothing more than a set of remote objects.

 

Where to from Here?

Will Jini be the next wave, like its predecessor, Java? Or will it go the way of the BetaMax video tape? Only time will tell. Jini has a few competitors that aim to provide similar services.

 

Microsoft has technologies that overlap Jini, such as Microsoft Transaction Server (MTS) and its forthcoming Millennium technology. Over 10 years ago, AT&T tried to bring disparate computers together (albeit with a very different philosophy) with its Plan 9 operating system. However, Jini offers one major advantage that few, if any, other technologies can touch: the ability to run on practically any computer that supports the JVM with no changes to its code. That makes it hard to beat.

 

One thing is clear: Whether Jini succeeds or fails, its vision is discernably the way networks are evolving. If I were a betting man, I'd put my money on Jini. In any case, it's a sure bet that something will provide the type of functionality that Jini wants to provide. If you want to learn more about Jini, there's a wealth of information on the Web:

 

Jini Home Page
java.sun.com/products/jini

Jini specifications
java.sun.com/products.jini.specs/index.html

More about Java RMI
java.sun.com/products/jdk/rmi/indes.html

Guide to changes in RMI
java.sun.com/products/jdk/1.2/docs/guide/rmi/index.html