Read an Excerpt
Chapter 1: Introduction to Jini
When Sun Microsystems released their first Java-enabled browser, the animated image of Duke, Sun's Java mascot, kindled the imagination of countless developers around the world. It wasn't that an animated image on a web page was in itself a really interesting development; there were other ways to animate images on the Web already, and you could argue that the Web suffers from the overuse of pointless animations like that one.
But a large number of people caught on to the idea that it wasn't a dancing Duke that was important: it was what the dancing Duke represented. The technology behind the dancing Duke-a simple programming environment that could take advantage of the network in novel ways-started the excitement behind Java and put it at the forefront of computer software technology.
Which brings us to Jini. Jini is a simple set of Java classes and services that has the potential to create its own revolution because it allows technology to be exploited in new ways. Some people who see a Jini demonstration might look at a camera being added to a network, and devices accessing the camera, and think that nothing really amazing is happening. There are, after all, many ways for systems and network-enabled cameras to interface with each other outside of Jini, and does the world really need another NetCam?
But the technology that drives Jini and the potential impact of Jini on networkbased computing is more compelling than it might seem from the surface of a simple demonstration like this. Jini allows co-operating devices, services, and applications (and there's little distinction between these) to access each otherseamlessly, to adapt to a continually changing environment, and to share code and configurations transparently. And Jini has the potential to radically alter our use of computer service networks, since it allows and encourages new types of services and new uses of existing networks.
What Is Jini?
In a nutshell, Jini is a set of specifications that enables services to discover each other on a network and that provides a framework that allows those services to participate in certain types of operations. The set of services on a particular network is referred to as the Jini community. The Jini specification refers to the community as a djinn, but common usage seems to favor the former term (on the other hand, the term Jini community is overloaded, as we'll discuss later).
If you've heard of Jini, chances are that you heard of it terms of hardware devices. Bring your Jini-enabled laptop into a Jini-enabled conference room, and the laptop will automatically be able to find and use the services of the conference room. Want to send output to the conference room printer? Your Jini-enabled laptop will automatically find the printer, seamlessly download any drivers required by the printer, and send it output. You can pull out your Jini-enabled PDA and do the same. And when you take that PDA and go into another office, the PDA will discard knowledge of the conference room printer and automatically find the printer local to the new office.
But Jini is not about hardware and devices: Jini is about services. A Jini-enabled printer provides a print service to the network; that the particular service is provided by a piece of hardware is irrelevant. There may be a software service on the network that also provides the same print service by accepting print requests, rasterizing them, and emailing the rasterized images to a distant recipient.
There are many Jini services that are only software. The core Jini services that we'll examine in this book are examples of such services, and you could think of many others: a service that stores and forwards events would not be hardware-based, nor would a matrix multiplication service (though it could be, if you had a really great vector processor available). Jini blurs the distinction between hardware and software: in a Jini community, everything is a service. This makes Jini appropriate for a number of applications, from integrating devices onto a network to providing enterprise services within your organization.
So the excitement around Jini stems not just from the fact that it allows hardware and applications to interact: it's also that Jini is designed to allow this service interaction to happen in a dynamic, robust way. There are three basic features of this interaction:
- The Jini environment requires no user intervention when services are brought on- or offline (other than starting the service: e.g., by turning on the Jini-enabled device or starting the Jini software service).
- The Jini community is self-healing: it can adapt when services (and consumers of services) come and go.
- Consumers of Jini services do not need prior knowledge of the service's implementation. Instead, the consumer loads the service implementation dynamically, with no configuration or user-intervention required.
These features make Jini ideal for a dynamic environment, where mobile computing devices come and go software-based services come and go, or where administration of services must be as simple as possible.
Jini at Work
In order to understand what Jini is, we'll present a high-level description of how a Jini community works. Then we'll look into the technology that enables the behavior that we'll describe.
Our Jini community starts in its simplest possible state: there is a single instance of the Jini lookup service running on this network. Clearly, some piece of hardware must be running this service, but it doesn't matter to us if that hardware is a PC, an IBM mainframe, or a network-enabled Jini lookup service appliance. The Jini lookup service keeps a list of all the Jini services that are available on the network.
Now say we add a Jini-enabled printer to the network. (There's a lot of meaning behind the word "add" here, but we'll address that a little later.) The printer finds the lookup service and then registers itself with the lookup service. It does this registration completely on its own as part of its startup sequence. And this illustrates the first key feature of Jini: it's designed so that user intervention is not required. At this point, there are two Jini services on the network: the lookup service and a print service.
Now let's add a laptop onto the network and start a Jini-aware word processing application on the laptop. The word processor will go out onto the network and find the lookup service (just like the printer did). Because it's not actually providing a service, it may not register with the lookup service; it may just inspect the other services that are registered. When it discovers that a print service is available, it will take appropriate action: it might, for example, enable the Print item in its File menu.
But remember that Jini communities are dynamic: the printer may not yet have been added to the community when we started the word processor. This is not a problem: the word processor can register with the lookup service to be notified when a printer is added to the network. When this notification comes, the word processor can then enable its Print menu item. Or maybe the word-processor will always have its Print menu item enabled, and when the user selects the Print menu item, only then will the word processor attempt to locate a print service. All this flexibility is built into the Jini environment. Similarly, if the printer becomes disconnected from the network, the word processor will be notified and be able to adapt itself to its new environment (e.g., by disabling the Print menu item).
This illustrates the second basic feature of a Jini community: it is self-healing. As services come and go, they register with and unregister from the lookup service. And the key feature that distinguishes this registration from other lookup services is that unregistration happens automatically. When a service registers with the lookup service, the lookup service issues it a lease which the service must periodically renew. If the power supply on the printer fails and it doesn't have a chance to unregister itself explicitly, then after a period of time, the lease will expire and the lookup service will automatically unregister the printer! This unregistration happens whenever a registered service fails to renew its lease with the lookup service, so it doesn't matter if the device running the service crashed, or if the network failed, or something else: if the service is not accessible, the service is eventually unregistered.
Self-healing works both ways. If the printer became unregistered because a component on the network failed, then when the network is fixed, the printer will automatically reregister its service with the lookup service. The printer doesn't need to know that the network was fixed, nor does a user need to intervene: the Jim code keeps track of the network's state and reregisters the printer automatically when the problem is fixed.
Now let's attempt to print. The first thing that our application must do is ask the user for certain printing parameters-whether to use landscape or portrait paper orientation, whether to print in color, and so on. The list of parameters is specific to the printer, and the dialog box that is presented to the user should reflect only those parameters that are appropriate to the printer.
This means that the application cannot have prior knowledge of the dialog box it must be able to show a dialog box that is appropriate for printers that have not yet been developed. So rather than attempting to put this sort of knowledge into the application, why not put it into the printer, since the printer is the only thing that actually knows what the dialog box should look like? Then the application can download the class definition for the dialog box from the printer on demand, instantiate the dialog box, and show it to the user.
Similarly, when the parameters are selected and it is time to print, the application must format its data into the correct printer language. The drivers that must normally be loaded by the user can once again be obtained directly from the printer itself. And this is the third major advantage to Jim: the implementation of all these services is loaded dynamically, at runtime, with no configuration.
Eventually, as services come and go, the Jim community may come to resemble Figure 1-1. There may be multiple instances of the lookup service. We might start some of the Jim services that come .with Sun's implementation of Jim, including a Jim transaction manager and a persistence service known as the JavaSpaces service. And so on: services will come and go, consumers of those services will come and go, and everything will be tied together by a common network...