UNDER THE JINI HOOD

Jini software can run on anything with a digital heartbeat—cellular phones, digital cameras, PDAs, alarms, televisions, and even smart cards. As illustrated in Figure 14.1, Jini software is an infrastructure that runs on top of a Java platform to create a federation of virtual machines. Each virtual machine sits on top of an OS that sits on top of the network. It is based on a simple model that devices with microchips should connect and work together in communities. The formation of these communities requires:

• No device drivers

• No operating systems

• No new cabling systems

• No human intervention

Each device on the home network provides services that other devices in the community may use. These devices provide their own interfaces, which ensures reliability and compatibility. Sun Microsystems is currently working with a number of manufacturers to integrate the Jini home networking technology into the next generation of digital appliances. Jini technology uses a lookup service with which devices and services register. When a device plugs in, it goes through an add-in protocol, called discovery and join-in. The device first locates the lookup service (discovery) and then uploads an object that implements all of its services'interfaces (join). To use a service, a person or a program locates it using the lookup service. The service's object is copied from the lookup service to the requesting device where it will be used. The lookup service acts as an intermediary to connect a client looking for a service with that service. Once the connection is made, the lookup service is not involved in any of the resulting interactions between that client and that service. It doesn't matter where a service is implemented—compatibility is ensured because each service provides everything needed to interact with it. There is no central repository of drivers, or anything else for that matter. The Java programming language is the key to making Jini technology work. Devices in a network employing Jini technology are tied together using Java Remote Method Invocation (RMI). RMI is best described as a set of protocols being developed by Sun's JavaSoft division that enables Java objects to communicate remotely with other Java objects. The discovery and join protocols, as well as the lookup service, depend on the ability to move Java objects, including their code, between Java virtual machines. Jini technology not only defines a set of protocols for discovery, join, and lookup, but also a leasing and transaction mechanism to provide resilience in a dynamic networked environment. The underlying technology and services architecture is powerful enough to build a fully distributed system on a network of workstations. And the Jini connection infrastructure is small enough that a community of devices enabled by Jini connection software can be built out of the simplest devices.

All of Jini's ability to support home networked-based services is based around six key concepts. The concepts are:

• Communities

• Discovery

• Lookup

• Leasing

• Remote events

• Transactions

Communities

A Jini community is a group of services on a home network that are available both to each other and to the consuming applications. All of the members of a community are available and visible to all other members of that community, and to any application that looks at that community on a Jini enabled in-home network. Each community on a home network has a unique name. All communities are put together without any planning, installation, or human intervention.

Discovery

Before a Jini-aware entity on a home network—either a service or an application— can take advantage of other Jini services, it must first find one or more Jini communities. The way an entity does this is by finding the lookup services that keep track of the shared resources of that particular community. A lookup service is basically a name server. The next section of this chapter explains the functionality and features of a lookup service in more detail.

This process of finding the available lookup services is called discovery. The Jini discovery protocol is the means by which Jini-aware home appliances find Jini communities on a typical in-home network. There is not just a single discovery protocol— Jini supports several, useful in different scenarios.

• The multicast request protocol is used when a home networked application or a service first becomes active, and needs to find the "nearby" lookup services that may be active. Figure 14.2 demonstrates the communication flow of the multicast request protocol in a live environment.

• The multicast announcement protocol is used by lookup services to announce their presence. When a new lookup service that is part of an existing community starts up, any interested parties will be informed via this protocol. Figure 14.3 shows the communication flow of the multicast announcement protocol.

• The unicast discovery protocol is used when a home-based application or service already knows the particular lookup service it wishes to talk to. The Unicast discovery protocol is used to talk directly to a lookup service, which may not be a part of the local home network. Figure 14.4 shows the communication flow of the unicast discovery protocol.

The end result of the discovery process is that the entity—the object doing the discovery on the home network is handed one or more references to the lookup services for the requested communities. Broadly speaking, there are two basic forms of discovery. One form is used to support "serendipitous" interaction between services and lookup services. Serendipitous interaction means that the lookup services and Jini services find each other without any previous configuration or advance knowledge of one another; they discover one another without being explicitly told to search for one another. The second form of discovery is used to "hard wire" a Jini service to a lookup service. Unlike the serendipitous forms of discovery, where services find any and all lookup services in their vicinity, this "direct" form of discovery allows home network services to use lookup services that they may know about ahead of time. This form of discovery uses its own protocol and has a URL-based naming scheme for specifying lookup services.

Lookup

To make use of the community services, an application program must first locate a Jini technology lookup service by using the discovery protocol. It can then use the lookup service to locate a device offering the desired type of service. The application then downloads a Java object from the lookup service that can be used to interact with the selected device. This object handles any device-specific details; the machine running the application does not need to have a driver for the device. We can think of the lookup service as a name server—it's essentially a process that keeps a track of all of the services that have joined a Jini community. But unlike a traditional name server, which provides a mapping from string names to stored objects, the Jini lookup service supports a richer set of semantics. You can, for example, search the Jini lookup service for particular types of objects. After discovery has successfully found a lookup service for a home networking user, it returns a reference to an object that implements the lookup interfaces. This interface is commonly called the service registrar. How the internals of the lookup service are actually implemented is hidden from consumers who use a Jini-based home network. Devices on a home network often use lookup to publish their own and find new services.

Publishing a Service

A lookup service maintains a list of service items. Each service item contains a proxy object that other participants in the community can download and execute as well as attributes that describe the service. The idea of downloadable service proxies is the key idea that gives Jini its ability to use services and devices without doing any explicit driver or software installation. Figure 14.5 illustrates the concept of a lookup server maintaining a list of service items. If, for example, a new DSL modem was plugged into your Jini home network and wished to publish its services (that is, making its services available to all other devices in your home), it needs to register with all lookup services returned from the discovery process.

Finding a Service

We've seen how home networking devices join communities to publish their services. Now we can look at how consumers of services find and use the services of other members in the community. Once a device on your network has a reference to a lookup service, it can search all the items on the lookup server to find services of interest. Jini provides a number of ways to search—you can search based on the type of the downloadable proxy contained in each service item, you can search by unique identifier of the service, or you can search the attributes contained in each service item.

Leasing

So far I've talked about discovery and lookup, the aspects of Jini that allow communities of services to spontaneously form and interact with each other. But I haven't talked yet about how to ensure that these communities are stable, self-healing, and resilient in the face of (inevitable) network failures, machine crashes, and software errors. The issue of reliability is important when software systems are intended—as Jini communities are—to be long-lived entities that can stay running and responsive over a period of months or even years, with little or no intervention from the user of the home network. Consider the following example.

Suppose you have a new MP3 player and connect it to your in-home network. In a Jini-based network, the player joins a community by registering itself with a lookup service for that community. The MP3 player publishes the fact that it is available for use, and all is well. That is, all is well until you decide to move the player to another room in the house without turning it off first. What happens to your home network? To the other members of the community, this may look like a classic failure situation— they may not be able to tell if the MP3 player has gone down, if it's simply slow to answer requests, or if the MP3 player's Jini software has crashed. But, regardless of how it was disconnected, it has not had a chance to unregister itself before it disconnects because of the abrupt termination of the player's communication with the network. The result of your disconnecting the MP3 player without shutting down properly—a completely common and understandable occurrence—is that a "stale" registration will linger in the lookup service for the community. Services that wish to use the player will see it registered but will not be able to use it. To get around these problems, Jini uses a technique called leasing. Leasing is based on the idea that, rather than granting access to a resource for an unlimited amount of time, the resource is "loaned" for a fixed period of time. Jini leases work much like leases in the real world. The grantor of the lease may deny Jini leases. They can be renewed by the holder. Leases will expire at a predetermined date unless they are renewed. They can be cancelled early (and unlike in real life, Jini imposes no penalty on early lease cancellation). Finally, leases can be negotiated, but, as in real life, the grantor has the final word on the terms of the lease that is offered.

Leases provide a consistent means to free unused or unneeded resources throughout Jini: If a service goes away, either intentionally or unintentionally, without cleaning up after itself, its leases will eventually expire and the service will be forgotten. In the case of our MP3 player, the leasing mechanism allows you to move the player around the house without causing problems on your in-home network.

Remote Events

Jini services—like many software components in a system, whether distributed or local—occasionally need to be notified when some interesting change happens in the world. For instance, a software component on a digital set-top box may need to be notified when a consumer uses a remote control to close a window on the television screen. An event is best described as an object that contains information about some external state change that a Jini software component may be interested in. Let's look at a practical example of how events are used in a Jini-based home network.

Take the example of a digital camera that connects to a home network and wants to be able to use any printers that are available in its Jini community. The camera contacts all the lookup services it could find, and then searches for services that implement the printer interface. In this example, we are assuming that the printer is already connected to the network and available for use before the digital camera. What if the inverse was true? In this case, there are no printers available when the camera first connects, although a printer in the home office may come on line later. Certainly the owner of the camera would still like to print pictures, regardless of the order in which we plug in the devices into the home network. Consequently, the digital camera needs the ability to be notified when any services that it might be able to use appear in a community. It's easy to imagine the user interface to the camera. The print button on the LCD is grayed out. You plug a printer into the home network, and suddenly the print button comes alive! The camera has just received notification (via an event) that a printer is now active on the network. This is only one example of how events are used in Jini.

Transactions

It's now time to deal with the last of the six key Jini concepts: transactions. Devices on a home network regularly contact each other for computational purposes. At some point midway through the computational process, one of these devices may crash or the network itself may become unstable This can result in a device continuously trying to contact an unreachable component on the network. This is where transactions come to the rescue. Transactions are a way to group a series of related operations so that there can be only two possible outcomes: Either all of the operations succeed, or all of the operations fail. In either case, the system moves to a known state in which it is relatively easy either move on if the transaction succeeds, or try again later if the transaction failed. The idea of transactions is to ensure data integrity on a home based network.