Jini: A Very Brief Introduction

The original purpose of Java wasn't to produce cool Web pages. Java, then known as Oak, was to be a language for the development of cooperating embedded systems. Although Java in many ways went another direction, or at least became prominent in a different arena, Sun didn't stop work on distributed embedded systems. This work, influence by Java and many of its developers, continued forward. An important piece of this effort is the Jini project. The Jini system is the toolkit fom this research group. It is a collection of tools to facilitate the networking of embedded devices in a spontaneous network -- in many ways a toolkit for ubiqitious computing.

The Jini Lookup Service

As you might imagine, mobile embedded device might have the need to interact with other mobile and non-mobile devices. They might do this via Java's RMI and remote methods. But, to do this, they will need to know which system hosts the service and they will need a proxy object for the service. It is the role of the lookup service to provide these things. Jini clients can query a lookup service for these items by interface (the class of object they need), by attributes that describe the class (in room 302, a printer, a color printer, &c), or by a specific, unique service number (if known). Additionally, Jini clients can request that the lookup service inform them if new services become available -- this is much like specifying a "future search". In many ways, the Jini lookup service is a combined name service (search by id) and directory service (search by attributes or type).

The details of the interaction between the client and the lookup service are a little uninteresting and largely take the form of the class specifications that define the interface. This would get a little boring to look at and doesn't contain too many surprises. If you're interested in the details, you might want to check Core Jini by W. Kieth Edwards.

The Jini Discovery Service(s)

The lookup service is certainly a useful utility. But it doesn't entirely solve the problem. Instead, in typical distributed systems fashion, it moves a piece of it. Given a lookup service, we can now find the service that we want. But, how do we find the lookup service? To solve this problem, Jini includes three different discovery protocols. One of them solves the problem in the easy case: the client knows how to contact the lookup serice already. The other two tackly the problem in the more difficult, "serendipitous" case -- where the clients and the lookup service need to find each other first.

But, before we dive into the details of the discovery protocols, let me mention a bit of an administrative detail. Jini services, including lookup services, are members of administrative groups. Examples of groupsat a University might be organizations such as ECE, CSD, HCI, LTI, &c. Services and clients that are members of only certain grousp may be "within earshot" of each other. As a result, the discovery protocols allow clients to limit their queries to certain groups.

The Easy "Hard Wired" Case

Let me suggest for a moment that the Jini client knows exactly how to contact a particular Jini lookeup service. If this is the case, no black magic is needed. The Jini client can simply contact the lookup service via a TCP unicast, make its request, and get the answer. The answer tells the client which groups the lookup service handles and provides the clinet with the necessary proxy object. The request will contain the following pieces:

• Header: Protocol version, client port number for response
• Group list: List of groups in which the client is interested
• Heard from list: A list of services the client already knows about and, as a consequence, does not want to hear about again. This is an optimization and can be omitted.

The client will get a reply from the discovery service that includes the proxy object for the service, as well as a list of the groups handles by the lookup service (note: this is a list of the groups handled by the lookup service, not the discovery service that is answering).

The process is shown in the figure below:

Client-Initiated

The "hard wired" protocol above is nice and all, but it really doesn't help us in the type of spontaneous environment that makes this problem interesting. What if the client doesn't know what discvoery services might be available? What does it do?

Jini provides another protocol to solve this problem (well, actually two). This protocol allows a client to multicast to a well-known address and "yell out" and ask nearby discovery services for help. What do I mean by "nearby". This is defined by the scope parameter of the UDP multicast. I'll leave the details of this protocol to a networking course such as 15-441 (multicast is a little ugly). But for the moment, let's just say that the scope is the number of "hops" that the multicast can travel on the network. This scope prevents the whole Internet from becoming one mess of screaming questions and answers.

Nearby discovery services (those within range of the multicast) then respond to this request exactly as they would have if it was the unicast request that we discuss above. The request and reply format are both exactly as they were before. The only big difference is that the request is sent by UDP, whcih imposes a limit on the packet size. If the request is too long, all or part of the "heard from" list may be omitted to obey the UDP maximum packet size restriction.

The client initiated discovery procedure is shown below:

The Jini specification requires that clients wait a random amount of time after booting before beginning the mutlicast. This is to prevent a multicast storm if many Jini devices are simultaneously enabled. The specification also recommends that initializing Jini devices perform seven rounds of multicasts, with a five seconds delay between rounds. I don't know why 7 and 5 are favorite numbers -- perhaps just favorite sensible values.

Lookup service Initiated

When a new lookup service is initialized, and periodically throughout its life, it advertises itself to nearby clients. Much as was the case with the client-initiated protocal, the advertisement, known as an announcement is done via a UDP multicast. After the announcment, client can make requests to the lookup service exactly as discussed in the section on the "hard wired" protocol -- the announcement provides the necessary information. The process is illustrated in the figure below:

In addition to announcing their presence upon initialization, the Jini specification recommends that lookup service re-announce their presence ever 120 seconds. I don't know why 120 seconds was selected as the period in between retrys.

Lessons Learned

The Jini discovery service is an excellent example of a discovery service. These three protocols, allow for a Jini system to initalize, manage failures, and "heal" without the intervention of human administrators. As a distributed system becomes larger, failures become commonplace, partionings become commonplace, users change equipment frequently, &c. The administrative task is larger than people can manage. This is especially true in mobile and other rapidly reconfiguring environments. To operate in this environment, a discovery service (as opposed to a simple directory service) is needed.

As is the case with Jini, these services typically make use of limited scope broadcasts and unicasts, timeout periods, and redundancy. They must be able to work through failure.

On The Subject of Jini...Leases

While we are on the subject of Jini, I'd like to mention one interesting facet of the system. Much like George Washington, the inventors of Jini did not believe in permanant alliances. They never give a client a permanant right to use a service. Instead they grant a client a limited term lease. In order to continue to use a service, a client must periodically "show interest" in the service by renewing the lease. Jini actually allows some interesting options when it comes to leases: lease managers can manage leases on behalf of services, and third parties can show interest in leases on behalf of the lease holder.

Leases are useful, because they help Jini recover from failure. In the event of a failed service, the system will correct itself after the lease expires -- the client no longer expects the failed service. If a client fails, the resource automatically becomes available again after the term of the lease, because it is unable to show interest to maintain it. In this way, Jini plans for failure and makes the recovery a normal and expected procedure, not an exceptional one.

The Jini notion of a lease is not unlike leases in the other contexts we've discussed this semester. Eliminate wastage and overhead by offering resources only temporarily. Then, they can't get lost and they don't need to be tracked -- even if they might go unused for a short term at the end of the lease.