email article printer friendly

Jini at Your Service
Discover how what was originally a revolutionary environment for distributed computing has evolved to be not unlike a service-oriented architecture
by Alex Krapf

November 28, 2005

Sun Microsystems introduced Jini originally as a technology that would allow devices to participate in reliable, distributed applications. Historically, it never found acceptance in that problem domain for several reasons: it requires a pretty large chunk of the Java run-time stack; it competes head-on with the UPnP specification that was supported by Microsoft in its dominant Windows platform; it's licensing was fairly nonstandard; and its continued support by Sun was not a certainty.

What most people didn't realize during the initial launch of Jini was that it also provided a gorgeous framework for building service-oriented applications. The failure to notice this important capability is easily understood: the term service-oriented architecture (SOA) had not even been invented yet. SOA was something that good client/server architects did instinctively or based on long, hard-won experience. Since those early days, a lot has happened.

Jini is now available in version 2.1 under the Apache 2.0 license. Sun and third parties have shown that Jini can work on small, embedded devices with a memory footprint of tens of kilobytes as well as on massively parallel super computers. Jini can be used from C/C++, .Net, or other clients and does not necessarily require a full Java stack.

How could Jini have been so misunderstood? Is it still relevant now that we have Web services and other technologies at our command? Let's take a closer look at Jini to answer these questions.

We shouldn't blame Sun all too much for Jini being misunderstood. After all, Java itself was originally aimed at applets and at powering small devices like cell phones or handhelds, and it took the majority of us a while to recognize its benefits for building powerful desktop and server applications. A revolutionary idea is by definition, well, revolutionary, and that means that its own creators frequently have no idea where it's going to take them. In the case of Jini, the technical vision was compelling: smart devices that just need to be plugged into a network or a bus or any communications channel, and they would make themselves known to their consumers; a standardized, simple lookup mechanism to identify a device that a consumer might wish to use; and a standardized, simple way to work with device and communication failures, acknowledging the fact that things break and network administrators occasionally make mistakes (no really, they do!).

Not So Fast
Well, it was not to be. Was a device vendor really going to add the necessary hardware to run the required Java Virtual Machine (JVM)? And even if they were to do that, would Microsoft add Jini support to its Windows operating system to take advantage of such devices? Of course not! The answer seemed so perfectly obvious to most people that they just looked at Jini as YADOAT (yet another dead-on-arrival technology).

However, not everybody discarded Jini right away, and—to Sun's credit—they kept developing and supporting it. Some early adopters looked at Jini and said, "Wow! Nothing in the specification says that I have to use it for devices. I could instead build applications that take advantage of the Jini features." These early adopters included hobbyists, visionaries, and places with big problems in the area of distributed computing: telcos, financial firms, and the military. To understand what they saw and what the others had missed, let's look at Jini's features. (See the sidebar, "The Jini Alternative" for a brief description of why Jini offers a more attractive problem-solving alternative compared with other technologies.)

What is Jini? To take its definition straight from the Jini Architecture Specification (see Resources for a link to the specification), Jini is a set of components that provides an infrastructure for federating services in a distributed system, a programming model that supports and encourages the production of reliable distributed services, and a set of services that can be made part of a federated Jini system and that offer functionality to any other member of the federation.

That definition sounds very software oriented, in fact, it sounds very much like a description of an SOA. Let's break down this definition. Federating services means that you take a group of independent, potentially distributed services and aggregate them into a single, dynamic distributed system. The difficulty here is that every single service can fail, and a federated service system has very nasty partial failure modes, which brings us to the second point: reliable distributed services. Reliability lies truly at the heart of a well-designed distributed system. Jini is arguably the first architecture that acknowledged the near certainty of partial system failure and turned it into a cornerstone of its design (see Resources for more information on distributed computing).

The third part of Jini's definition in the specification is about a set of utility services that offer functionality to other services. These services include such necessities as a transaction service and a persistence service. The best way to understand the core ideas behind Jini is to give yourself a traditional problem, and then describe what your application might look like if you solved the problem using Jini.