Table of Contents
Jini grew from early work in Java to make distributed computing easier. It intends to make network devices and network services into standard components of everyone's computing environment. The computing world is currently abuzz about service-oriented systems, and Jini has been a major platform for service-oriented computing since its inception, long before the term became popular.
Jini supports both software and hardware services. When you buy a new piece of office computing equipment such as a desk lamp, or a new home computer appliance such as an alarm clock, it will not only carry out its "traditional" functions, but will also join a network of other computer devices and services. The desk lamp will turn itself off when you leave your desk, informed of your departure by sensors in your chair; the alarm clock will tell your coffeemaker to switch on a few minutes before it wakes you up. These hardware services will interact with software services such as calendar and diary services, and possibly with external services such as weather and stock exchange services (to wake you up early if the weather is cold or if there is sudden movement on the market). Jini doesn't care what is behind services; it just makes the services available to applications.
Homes, offices, and factories are becoming increasingly networked. Current twisted-pair wiring will remain, but it will be augmented by wireless networks and networks built on phone lines and power cables. On top of this will be an infrastructure to allow services to communicate. TCP/IP will be a part of this, but it will not be enough. There will need to be mechanisms for service discovery, for negotiation of properties, and for event signaling (e.g., "My alarm has gone off-does anyone want to know?").
Jini supplies this higher level of interaction. This chapter provides a brief overview of Jini, and the components of a Jini system and the relationships between them.
The licensing model for Jini has now changed to an open source Apache license from a proprietary license. This change, plus the continued quality of the middleware, has sparked renewed interest in Jini.Jini is the name for a distributed computing environment that can offer network plug and play, meaning that a device or a software service can be connected to a network and announce its presence, and clients that wish to use such a service can then locate it and call it to perform tasks. Jini can be used for mobile computing tasks where a service may be connected to a network for only a short time, but it can more generally be used in any network where there is some degree of change. Jini is useful in a large number of scenarios, including the following:
A new printer can be connected to the network and announce its presence and capabilities. A client can then use this printer without having to be specially configured to do so.
A digital camera can be connected to the network and present a user interface that will not only allow pictures to be taken, but also be aware of any printers so that the pictures can be printed.
A configuration file that is copied and modified on individual machines can be made into a network service from a single machine, reducing maintenance costs.
New capabilities extending existing ones can be added to a running system without disrupting existing services, or without any need to reconfigure clients.
Services can announce changes of state, such as when a printer runs out of paper. Listeners, typically of an administrative nature, can watch for these changes and flag them for attention.
Jini is not an acronym for anything, and it does not have a particular meaning (although it gained the post-hoc interpretation of "Jini Is Not Initials"). A Jini system or federation is a collection of clients and services all communicating by the Jini protocols. Often this federation will consist of applications written in Java, communicating using the Java Remote Method Invocation (RMI) mechanism. Although Jini is written in pure Java, neither clients nor services are constrained to be in pure Java. They may include native code methods, act as wrappers around non-Java objects, or even be written in some other language altogether. Jini supplies a middleware layer to link services and clients from a variety of sources.
When you download a copy of Jini, you actually get a mixture of things. First, Jini is a specification of a set of middleware components, including an application programming interface (API) so that you as a programmer can write services and components that make use of this middleware. Second, it includes an implementation (in pure Java) of the middleware, as a set of Java packages. By including these packages in the classpath of your client or service, you can invoke the Jini middleware protocols to join in whatever Jini services and clients are currently running. (This collection of clients of services is sometimes called a djinn.) You also get source code to these packages as a bonus. Finally, Jini requires a number of "standard" services, and Sun gives basic implementations of each. These implementations are not an official part of Jini, but are included to get you going, and in practice, most users find these implementations sufficient to do substantial work with Jini.
Jini was not born in a vacuum. It was based on long experience within Sun Microsystems of building networking applications and frameworks. Many of the most important lessons from this were summarised in the Eight Fallacies of Distributed Computing. For the last few years Jini has not been highly visible. There are various non-technical reasons for this, but also technology that works and works well is often not reported. Nevertheless, to show that Jini came from somewhere and has been used in substantial projects, in the subsections that follow, I discuss the Eight Fallacies of Distributed Computing and how they relate to Jini, and I also describe some Jini success stories.
Since the early days, computers have been linked in networks. For over 20 years, the mantra from Sun Microsystems has been "The Network Is the Computer," and this idea has been a cornerstone of much work in distributed computing. Based on the experience of Sun engineers over many years, Peter Deutsch took a critical look at the state of distributed computing in 1999 and concluded that early optimism was in many ways misplaced. Networks and applications that run on them are prone to all sorts of problems that do not occur with stand-alone applications, and ignoring these problems can lead to unreliable and unstable applications. Deutsch identified the following fallacies of networking (extended by James Gosling):
The network is reliable.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.
Latency is zero.
Typical ways of "hiding" the network such as remote procedure calls (RPCs) assume these fallacies are all true. For example, Sun's RPC was one of the earliest widespread RPC frameworks. This does assume that the network is reliable, and it does assume that bandwidth is infinite, so applications assume that remote calls will always succeeed and that there is no overhead in making remote calls. Network calls are several orders of magnitude slower than local function calls and do sometimes fail, but there is no recognition of this in the RPC programming model - that was its purpose: to hide the network! These assumptions have been continued into many later middleware systems such as CORBA, and even into quite recent (and popular) frameworks.
Jini recognizes these fallacies and attempts to deal with them. For example, specifications of services have to be marked as "potentially remote" and all method calls have to handle possible network failures.
Jini has been around since 1999, and while it has achieved some notable successes, it does not have the visibility of many other middleware systems. In part, this is because Jini simply works and has been a stable but evolving platform over these years. The Sun web site lists many successful projects using Jini. This section covers a couple of them plus some other systems. For more stories, visit http://www.sun.com/software/jini/news/success.xml.
You should be aware that Jini is only one competitor in a growing market. What conditions the success or failure of Jini is partly the politics of the market, but also (hopefully) the technical capabilities of Jini. This book deals with some of these technical issues involved in using Jini.Note that the systems described in the sections that follow often have to deal directly with the issues raised by the Eight Fallacies described in the previous section. For example, they need to work in changing topologies, on unreliable networks, and with limited bandwidth. Jini is middleware designed to manage such issues, but it is not perfect. Nevertheless, it recognises the Fallacies and provides mechanisms adequate for many systems, with the possibility of sophisticated configuration for more demanding situations.
Frank Sommers reports on a banking system developed by Rubean, A.G., in an article at http://www.artima.com/lejava/articles/banking_on_jiniP.html. A group of German and Swiss banks with 35,000 customers run a centralized Java 2 Platform, Enterprise Edition (J2EE) system. However, this system needs to interact with ATM machines, cash-dispensing machines, and other devices linked to PCs typically through an RS232 cable. These devices have differing capabilities, their PCs are not always on, and they have IP addresses assigned by the Dynamic Host Configuration Protocol (DHCP), so they are continually changing. This dynamic environment could be a maintenance nightmare to a centralized system. The solution by Rubean uses Jini services running on each PC, talking to the devices using the Java Comms API. Each service advertises itself to Jini lookup services, which can handle the dynamic nature of the services without needing configuration. The J2EE system just sees collections of services and is unaware of configuration details.
Magneti Marelli Motorsport builds monitoring equipment for Formula One racing cars, and its hardware and software is used by most racing teams. However, its software used to run on proprietary platforms and lacked the flexibility and robustness required. In the cars, sensors collect a great deal of information, which is relayed by radio links to teams in the pits. The environment in the pits is often hot and noisy, and real-time responses are needed to deal both with the data itself and with a changing environment (computers die, network cables are tripped over, etc.). New software was developed using not only the discovery mechanisms of Jini, but also its ability to self-heal the service environment. Being able to run in multiple operating system environments was also a help. The project is described at http://wiki.javapolis.com/confluence/display/JP05/Formula+One+Telemetry+with+Java.
Nedap N.V. is a security management company used by over 6 million people every day. Some years ago, the company saw the need for a next generation of security systems and began to design one from the ground up. The heart of the system is a 64MB controller with an Ethernet connection to the network and CAN connection to devices. Each controller exposes itself to the network as a Jini service. Examples of use include the security system controlling elevators within the Eiffel Tower in Paris. Every time an elevator comes within wireless range of a Jini lookup service, it is discovered. This allows security access of an elevator to any floor to be controlled, with Jini dynamic service management handling access to services. This system is described at http://www.jini.org/meetings/eighth/J8abstracts.html#Wegman.
The previous examples seem to suggest that Jini is just for linking hardware systems into software systems. Jini is certainly good at doing this, since it makes the devices appear as services, making them first-class citizens in a service-oriented system. But that is not all that Jini is good for: it is a framework for service-oriented middleware, and it excels in purely software-based systems too. An example of such a system is Orbitz, a multibillion dollar online travel company based in the United States. Orbitz uses over 1,000 Linux servers, and it has both a changing set of machines and evolving applications running on them. For example, if a supplier is having a sale, Orbitz will allocate more services to that company. Obviously, reconfiguring applications to use new services could be an ongoing horrific task, but Jini dynamic discovery allows it to be done transparently. In addition, services can be upgraded in place and the new versions become automatically available. The Orbitz system is described here: http://www.sun.com/software/jini/news/Jini_Orbitz_Profile_Final.pdf.
Orange is a major mobile communications company, with over 44 million customers worldwide. It offers a range of services, many of them supplied by external organizations. Again, this is a dynamic service environment, with new services begin deployed and existing services being revised, all in a high-volume environment, and Jini manages many aspects of this dynamism automatically. For more information, see http://www.sun.com/products-n-solutions/telecom/docs/orangesp_1.pdf.
Jini for may years has been licensed under a Sun Community License. While generous in many respects (for example, Jini source code has always been available) it is, nevertheless, a proprietary license. Recently the Jini group has decided that this has possibly limited the uptake of Jini, and so early in 2006 the license was changed to the open source Apache license.
However, grander changes are underway. At the time of writing, negotiations are under way to turn Jini into an Apache "incubator project", and later perhaps into a top-level Apache project. This will turn Jini into a true open source project and hopefully will bring in a new set of users and developers, in addition to being build on, and contribute to, other Apache projects. Among the issues still to be resolved is the name of the project--since Jini is all of: a concept for middleware, a specification and API and an implementation, the name might change in moving to Apache. One possible name that has been suggested is Babylon. Associative thinking leads to "Rivers of Babylon", then to "disco", and from there to "discovery" -- which is one of the principal features of Jini :-)
Until recently, the primary site for Jini was http://www.jini.org. A new site has been added https://jini.dev.java.net/ and most of the projects have been moved to there. In the future, it is hoped that Jini will be on the Incubator's page on the Apache site at http://incubator.apache.org/ and later on perhaps will have its own top-level page on the main Apache site.