We’ve heard the hype. We are struggling to absorb every last buzzword in the media. We’ve sat through all the high-level marketing. We’ve tried to envision the vision. Jini has definitely had its day in the Sun, but let’s look at Jini from a practical perspective. Cut out all the vision, marketing, press, hype, and ‘top of the head’ stuff. Here, we’ll give you an objective view of this subjective technology.
Nomenclature It is important to understand the buzzwords used so that confusion is avoided. Here are some of the terms used in talking about Jini:
- Federation — A federation consists of a group of devices (like printers, hard disks and so on) and software programs (any program that is compiled down to Java bytecode) that form a single, dynamic, distributed system.
- Resource — The devices and programs within a federation are called resources.
- Service — A resource offers a service. A service can be storage, communication, computation or anything that a resource can do. For example, printers will offer a print service; pagers will offer a paging service; encryption libraries offer an encryption service.
Architecture and implementation A Jini system consists of three main components, each of which are described below.
Infrastructure: The Jini infrastructure consists of the base software required to build a Jini federation. The base software is :
- 1.2 JVM (Java Virtual Machine) — The software required to run any Java program.
- Extended RMI (Remote Method Invocation) — An enhanced version of RMI for Jini.
- Lookup service — This essentially is the database for services available in the federation. Resources find services in the federation using the lookup service. The entries in this lookup database are Java interfaces which are client proxies for the service they implement.
- Discovery service — This service allows discovery of resources plugged into the federation. Once discovered, the resource will register it’s services with the lookup service.
- Distributed security — A security framework extended for distributed systems. It is built on top of Java’s built-in security mechanisms.
The base infrastructure code is 48K in size. It essentially boils down to a virtual machine with a set of class libraries.
Programming Model : These are rules, specifications and suggestions on how to write a Jini service. Jini services make use of the following concepts:
Other specifications which dictate a programming model are the Jini device specification, RMI, Object Serialization, JavaSpaces. A service programmer would need to understand some of these specifications and provide concrete implementations to interface methods to successfully write a service.
- Distributed leasing — which provides a time-based model for activating and freeing services and resources.
- Transactions — which allow wrapping of multiple operations on multiple services into a single unit of work that either completely succeeds or is rolled back.
- Distributed events — which is a notification mechanism between services and resources that stretches beyond machine boundaries.
Services: These are hand-coded using the programming model. They can be programmed to do any task suitable of the resource.
Once you have the Jini infrastructure and understand the programming model, you can write services. Services can be device-specific, like the storage service for storage devices or can be very generic and provide a range of methods, much like class libraries. In fact, you could have all computation-intensive code packaged in a service on a large machine where these methods execute most efficiently. This truly unleashes the power of distributed computing.
These services are mobile and intelligent moving from machine to machine executing where and when required — Jinlets, if you will. A printer could download a Jinlet that filters documents for obscene language and run it, or could simply have that service run on the remote machine and pass the results back to the printer.
Depending on the level of abstraction and encapsulation required between the service and the client, a service implementor will determine the locality and amount of computation to be carried out between client and service provider. Invoking services programmatically, requires first querying the lookup service for a particular interface, downloading the implementation of the interface and invoking its methods. The interface implementation may use remote call mechanisms like RMI, CORBA or in-house messaging protocols, may do some local manipulation or a combination of both to provide the service.
Maybe a browser will emerge to browse through available services in the lookup and activate the services. The services could be activated through a GUI by filling out some dialog box with parameter values and pressing a button.
Functionality Let’s take a look at what exactly happens when I plug in my brand new “Jini-enabled” printer?
Okay, let’s assume we successfully passed the Discovery/Join phase. What happens next? All the resources in the Jini federation have now reached a steady state. The lookup service is populated with information about all available services in the federation. But what happens when a resource in the federation needs to use the printer service?
- The printer broadcasts/multicasts a discovery packet (512 bytes) on a well-known port. The packet contains just enough information to contact the printer.
- The lookup service running somewhere on the network listens on the well-known port/multicast group and receives the packet. It registers the information about the printer.
- The lookup service replies to the printer with its location. With this, discovery is complete.
- The printer is now ready to “join” the network. It adds each of its services to the lookup service.
- All resources are now ready to use the printer, and the printer too is ready to use other resources on the network.
Using similar logic the printer can access services offered by other resources in the federation.
- The resource first queries the lookup service for a particular interface for accessing the printer’s services.
- If the interface is present in the lookup service, the client proxy for the print service is returned to the resource.
- The resource invokes methods of the client proxy interface. These methods in turn activate the printer according to which methods were called.
What’s the catch? There are numerous hurdles to achieving the Jini vision, such as:
- Availability and the install base of Java Virtual Machines: If you’re not working on Windows NT or Solaris, there is a pretty good chance that your machine is not ready for Jini. What is the chance that a printer has a JVM? First, virtual machine deployment must increase significantly. There also must be significant support from Java device vendors to realize the dream. This is the most significant challenge.
- Speed has always been a touchy subject. Caching of service implementations could improve speed but would introduce problems of synchronization. Slower devices may result in producer-consumer problems.
- Jini was designed for federations of less than 1,000 resources. That maybe all right for your home or for small offices, but what about the enterprise?
- There are potential problems with leased entries in the lookup service. Services and resources may have vanished but the lookup service will say that it is available until its lease expires.
- Only time will tell how well partial failures are actually handled. Much will be determined by which exceptions are propagated into the client space and which are not.
- Though Jini is as dynamic as it gets, it requires the use of static, well-known interfaces to access services. Unless someone takes charge and defines interfaces for popular services, there could be interface wars deteriorating into multiple APIs (from each vendor) for a conceptually well-defined concept (such as printing or saving).
- Lookup service is the bottleneck. If lookup goes down, no service can be accessed. What happens when the location of the lookup service changes? How are the resources going to rediscover it?
- Jini itself will need a fair amount of configuration and administration. All components needed to provide a service need to be up and running.
- Too Java-centric. It was designed with Java and only Java in mind. What about all my existing programs that actually work? Is it worth spending the time writing Jini wrappers for services implemented in legacy languages?
- We all know what happens to ideas that are too ambitious.
Conclusion Jini comes from some of the best minds in distributed computing today. If this technology does succeed and gain acceptance, it surely will change the way we use devices and networks. The whole network would just become an ocean of services with complete location transparency. Devices would become available as soon as they are plugged into a network. It is a distributed programmers dream environment, but that is where the environment ends, in the dream. The reality of Jini will take much support and much time to realize, but it will be worth the wait.
Jini Software Simplifies Network Computing
Apu Shah is a director of software operations at Boston Management Consultants, currently based in India. He can be reached at: firstname.lastname@example.org.