What if a Jini lookup service was available in every shipping JVM? What if Java was linked to networking in the same way that marketing tried to link Java to XML a few years back, and not just for enterprise applications--where Jini is a natural fit--but also in every J2SE and J2ME distribution. Jini is Java's secret weapon. It is so secret, however, that other technologies have been invented and adopted to solve problems that Jini already addresses.
This is not just another article championing a niche technology; it is a tempered rant on why Jini could be seen as central to the future health of Java. We can draw many lessons from the success of web services and from Apple's (soon to be renamed) Rendezvous technology, and we can find many opportunities on the desktop, in the enterprise, and on devices. Everywhere you see a JVM, picture a Jini-enabled device. The result is that every computer is networked and the network really is the computer.
Let's start with a handful of what ifs.
Every day you interact firsthand with more and more computing devices. It would require too much of your time and an assumption of training and expertise if each of these devices required a human to be involved each time they communicated with one another. The integration of devices and of applications cannot depend on us. There are many ways of accomplishing this. The one getting all the press right now is web services, but there are other alternatives.
A year and a half ago at BEA's eWorld conference in Orlando, Florida, then-CTO Scott Dietzen considered what would be required of web enabling an application. Currently, for the most part, web enabling an application means that you can run it with a browser. Dietzen posited that where the current Web is concerned with UI, the next generation of the Web will center around integration.
Dietzen argued that before web services, the choices were to either agree to use a shared data model or a shared object model between applications. In other words, you needed to either agree on what was being sent over the wire, or you needed to agree on the type system at both ends. He predicted that Java would be used for intra-application communication and XML web services would be used for communication between applications.
For many, the web services core standards (SOAP, HTTP, SSL, URI, UDDI, and WSDL) enable applications that know little about each other to collaborate and communicate. At issue, however, is that SOAP-based web services are being used inappropriately for applications that require only a socket or two. This is reminiscent of the way in which EJBs were adopted in settings that required little more than a servlet.
With web services, the agreement centers around the protocol of the data being sent back and forth. There is no need to worry about whether the applications at each end of the wire are written in the same language or are running on the same platform. When Google, or eBay, or Amazon wants to expose some of their functionality to you as a developer without telling you anything about their implementation, they can expose a set of web services and say, "This is how you initiate a request, and this is the format in which the results will be returned."
So is Jini right and web services wrong, or is web services wrong and Jini right?
In his recent address to the eighth Jini Community Meeting, Brian Murphy reminded the audience of the importance of axioms. His motivating metaphor was non-Euclidean geometry. What happens if you remove the assumption of the parallel postulate? In Euclidean geometry, this amounts to the statement that given a line and a point not on the line, there is exactly one line through the given point parallel to the given line. If you replace that assumption with the statement that ... there are no lines through the given point ... you end up with the geometry of the sphere. If you instead assume that ... there are two lines through the given point ... you end up with hyperbolic geometry.
One reaction is to look at the world around us and we say that Euclidean geometry is right, and therefore the other geometries must be wrong. Another reaction is to dismiss this all as fanciful arguments about things that don't matter. But Murphy pointed out that Reimmanian geometry provided the support for Einstein's theories. Euclidean geometry was sufficient for describing the world modeled by Newtonian physics, but other geometries were required to describe the world as modern science now understands it.
Brian's address struck a chord with me. Math for me was much like playing elaborate games: read through the rules and then move your way around the board (i.e., prove some theorems). That was Brian's point when it came to distributed computing. It isn't that Jini or any other technology is right or wrong. You need to understand the fundamental assumptions of that technology and apply it where appropriate.
If you own both sides of the wire, you should not be using SOAP and friends. In "I'd Rather Use a Socket," Robert C. Martin writes that he thinks "industry should join frameworks anonymous and swear off gratuitous framework adoption. We should all start using sockets and flat files instead of huge middleware and enormous databases--at least for those applications where the frameworks and databases aren't obviously necessary."
If you need to send and receive an integral value, you can create a SOAP message to contain your message and prepare to receive and unwrap a SOAP message containing the response. What if you or your company created both the client and the server for this particular application? Uncle Bob's point is that you could probably open up a socket on the client end and send the integer to the server. If you like, you could even encrypt the message. Open up another socket and wait for the response.
This SOAP/WSDL-based overkill phenomenon is not restricted to the software industry. There are few things easier to make than pancake batter, and yet millions of prepackaged powders and liquid mixes are sold each year. Freshly made caramel sauce can be yours in about fifteen minutes with nothing more than sugar, water, and cream. It's not that we've gotten lazy. Many of us have no idea that making some of these storebought items ourselves could be so easy. We're heading the same way with distributed computing. We're buying into the notion that we need all of these WS-* initiatives and can't imagine that we can send a message "from scratch" with our "easy-bake socket."
In particular, if we are writing applications that assume Java at both ends of the wire, then we can take advantage of the Java-based type system. What is being sent as a message can be serialized Java objects that can be reconstituted at the other end. Those who are not interested in standardizing on Java need to reject this axiom. What happens when we do not agree that Java will be present on both ends? You end up in a CORBA-like world, or in a world that agrees to standardize on web services. If you assume Java is present at both ends of the wire, you are mostly set up to take advantage of Jini technology.
At their core, Jini and Rendezvous each enable service discovery. They do so in different ways and can be used to complement each other. Their differences, however, extend beyond their core set of APIs. The Java community should look at the ways in which Rendezvous was introduced and the speed with which it has been adopted. Most important is for Jini lookup services to be ever present and for them to not need any configuration or setup on the part of the enduser.
When Jini was introduced, the initial emphasis seemed to be on devices communicating with each other. There was the futuristic notion that your coffeemaker and refrigerator could talk to each other so that if your milk was outdated, your coffeemaker would know not to make coffee for you, because you never drink coffee without milk. The Jini team emphasized that Jini was more than this, but the message got lost. They explained that Jini was all about distributed objects and networked devices, and the assumptions that needed to be made to robustly provide services on an unreliable network. Much of that message got lost. As Apple CEO Steve Jobs said to Sun CEO Scott McNealy on the JavaOne stage, "You were busy Java-enabling light bulbs." In addition to the conceptual hurdle that was placed around Jini, there were actual hurdles to adoption. If it was to be adopted by printers, then printer manufacturers had to include a JVM in their printers and the industry had to agree on a Java-based printing protocol.
Contrast this with Apple's introduction of Rendezvous. Rendezvous is an IP-based network technology for advertising and browsing services. In the introductory demo at Apple's Worldwide Developer Conference, Steve Jobs displayed a music application by browsing through his available music. Someone joined him onstage and opened up a laptop. The second laptop joined the same network as Jobs' computer, and on the screen the audience could see the music from the laptop was now available to be played on Jobs' computer. The laptop was then closed and the additional music was no longer available to be played. Thousands of developers walked away understanding what Rendezvous was all about.
Perhaps ironically, it was the device manufacturers who first embraced Rendezvous. Printer manufacturers Rendezvous-enabled their printers. Any printer that could be accessed using IP over Ethernet could easily be Rendezvous-enabled. This meant that as you wandered into a new environment, you could automatically discover and print to printers you previously didn't know existed. It was the Jini value proposition. Although Jini and Rendezvous were largely orthogonal technologies, developers left the Jobs demonstration saying "Rendezvous is French for Jini."
Rendezvous has been adopted fairly quickly. In addition to the printers, cameras, and other devices that manufacturers that have incorporated Rendezvous into, Apple has Rendezvous-enabled many of their software offerings, and third-party software houses have found interesting ways of taking advantage of dynamically discovered devices.
The keys for Rendezvous were:
Each of these are important for Jini, as well. For example, the concept is simple, but it must be communicated in a way that matters.
The most important requirement for Jini is that it gets to live "in the box." When Jini was introduced, the reach of Java was tiny compared to now. Jini needs to be inside of every JVM. Jini needs to ship as a part of the core Java platform. In addition, when a JVM launches, there needs to be a check that there is some number of lookup services available, or the local JVM must launch one. The launching and maintenance of the network on which the Jini services run must be transparent to the user. There are Java mechanisms such as Java WebStart that can be exploited to easily distribute Jini-based applications that can be used to discover required services without requiring user configuration.
Certainly having Jini distributed with every JVM is beneficial to the Jini community and should enable and encourage the use of the technology. Having support for mobile objects built into the platform is also good for Java. Remember that Java is three things: a platform, a language, and a set of libraries. Java as a platform benefits when you can assume that whenever a Java application is running, an infrastructure that supports distributed programming is available. Jini helps answer the question, "What's so special about Java?"
While you read this article, the act of displaying the HTML in a browser does not require much of the available cycles in your computer. Imagine the aggregate advantage if you and your coworkers agree to participate in local grids when your individual usage is below a certain amount. If Java developers could count on the availability of Jini, they could partition computing-intensive tasks to take advantage of other cooperating devices.
As you move with your laptop through time or space, Java applications that are built with the expectation of Jini everywhere can take advantage of self-configuring, self-healing network applications. Perhaps your machine can't handle a particular type of calculation. You know that at work, there are several machines set up to perform that task. As you arrive at work, your laptop handshakes with one of the available machines, and the task is completed and waiting for you before you've had your morning coffee.
What we learned in the case of Rendezvous is that having the supporting structure always available leads developers to take advantage of the technology in ways that cannot be anticipated.
Contrast this with the application-by-application way in which Jini tends to be supported. Someone creates a Jini-enabled application. Now they must ensure that everyone who needs to run it, can. This means configuring and running a lookup service and making sure that there are comprehensive instructions on how to start up and run the clients.
In the case of Rendezvous, it has been clear for a while that it worked on the Windows operating system, as there were Windows versions of the iTunes music application. But this doesn't help a second application that wants to take advantage of Rendezvous on Windows. The best solution is to have a single daemon on each device. Apple has produced Rendezvous daemons for Windows, Linux, and Unix distributions. With Jini, the advantage is that Jini requires Java, and that there is little that would need to change in a JVM and standard distribution to support Jini.
The advantage of supporting Jini at the VM level is, therefore, that you can "assume a network." But there is a second advantage to the Java community to making sure that Jini is built in. Since Jini requires Java, as people begin to understand the power of Jini and JavaSpaces, this helps raise the bar for or even fend off possible replacements for Java.
Jim Waldo often speaks of the Highlander principle with regards to the adoption of Jini or other core technologies. As Wikipedia explains, the Highlander is a series of movies about an immortal who does "not age and cannot die unless he is decapitated. When only one Immortal is left, he or she will gain 'The Prize' ... The phrase 'There can be only one!' is used frequently in promoting the movies, resulting in 'highlander' also being a generic phrase for computer programming solutions that involve exclusive access to a resource."
Waldo applies this concept of "there can be only one" to technologies that appear to solve the same problem. If you think of Jini as a technology for enabling enterprise applications, then it must die if other applications are to live. For different reasons, companies would like us to choose one true solution and swear allegiance to it. It is as if we could not program in Java when appropriate and Perl when the need arises.
One of the most appealing aspects of Apple's Rendezvous technology is the fundamental rejection of the Highlander principle. The rules are simple--you need an IP address to communicate using IP. One alternative is to use Rendezvous to obtain this IP address. On the other hand, if a device has obtained a legitimate IP address either through manual assignment or using DHCP, that device can fully participate in a Rendezvous network. At the second step, the device needs to obtain a user-friendly name that resolves to the address. Again, Rendezvous provides its own mechanism for doing so, while still respecting those devices that have access to a DNS server. The third step is Rendezvous-specific for advertising and browsing services--but there is no requirement that "you are all Rendezvous or not at all Rendezvous."
Jini and other Sun-sponsored Java technologies should take the same attitude. Jini is a wonderful technology that solves many of today's most interesting problems. But perhaps there are clients that can take advantage of a combination of Jini and JXTA so that the Jini Lookup Service can be exposed as a JXTA peer, as Bruno Souza and others demonstrated at JavaOne 2003. Perhaps a Jini Lookup Service can be Rendezvous enabled so that Jini can take advantage of Rendezvous' reach and ease of setup.
Applying the Highlander principle, I'm not suggesting that only Jini should be included in the box. I'd be happy to see support for JXTA and Rendezvous built in as well. Make Java a platform that embraces and enables ubiquitous networking.
In the early days, people associated Java with applets. Then there was a transition to a focus on Java as a tool for the enterprise. Similarly, Jini has been tagged with the enterprise label and it has had to fight a war on two fronts. Within enterprise applications, it has taken a back seat to EJBs, web services, and other enterprise frameworks of choice. Outside of the enterprise, it has never found much of a foothold with desktop and J2ME applications. The landscape is currently particularly friendly to reintroducing Jini into SE, ME, and EE applications.
What we need here is a killer app.
Take a look at some of the better-known Rendezvous applications. An instant messaging client is often tied to a central server. The only people who appear on your buddy list are people you have placed there. Use the Rendezvous version at a conference, and discover the people online who may be watching the same talk you are. Rendezvous-enable iPhoto and you can share your pictures. Even unlikely applications can be Rendezvous-enabled with powerful results. Add Rendezvous features to a simple text editor and you end up with Sub-Etha-Edit, a powerful collaboration tool.
As you consider creating a desktop application, think about what features could be added if one instance of your application could communicate with other instances of the application. It's not just applications that can benefit from Jini. Rather than wait for Jini to be added to standard J2SE distributions, Sun could quickly add Jini to the Java Desktop System and further distinguish it from other Linux distributions.
Take a look at the recent push towards Spring, Hibernate, Pico Container, and other lightweight frameworks. Consider the rethinking of EJB 3.0 to embrace their lessons. JDO has sufficient support to lead us to rethink some of the "early wisdom" with regards to the Enterprise stack. We have returned to a world that embraces POJOs.
Jini applications are built around these plain old Java objects. In fact, this could be why the full J2EE stack was promoted over the use of Jini in distributed applications. Jini does not require expensive application servers and complicated containers. This makes Jini a compelling choice for clients but not for application tool vendors, who benefit from sales and support of certified J2EE app servers. Jini applications are also platform-independent. At deployment time, it is nice not to have to worry about which version of which app server is being supported on each machine.
Web services send XML-based "objects" over the wire. You then need to discover the structure of the message being sent, so that it can be read and a response can be generated. After the messaging mechanism is agreed upon, you need to be concerned with supporting security and transactions. For Java developers, this support has been present in Jini for a while. Programmers need to acknowledge and code for potential problems on the network, but the patterns for working with Jini and JavaSpaces are not nearly as complex as the problems with working with EJBs.
Finally, in the enterprise there is a lot of interest in grid computing and in what is called autonomic computing. Lessons from Google on the power of running large clusters of inexpensive machines have helped to generate interest in the power of a grid. JavaSpaces is the forgotten first cousin of Jini. It provides support for grid-style computing and is being used in many settings where machines need to move in and out of a compute cluster to meet needs when demand peaks, and to provide load balancing. At the recent Jini Community Meetings, Nigel Warren demonstrated a video application of JavaSpaces and John McClain described some of the upcoming additions to the JavaSpaces APIs (including support for FIFO). This is a technology ripe for adoption.
The mobile device that fits inside of your pocket has considerably more power and memory than when Jini was first introduced. Although J2ME should, perhaps, still appropriately address the input and output constraints of such devices, there is no reason not to support Jini and other distributed computing technologies as a core part of J2ME. RMI is not part of the J2ME stack--but what would it take to include it and the Jini .jar files?
The surrogate architecture may not be required for any but the most resource-constrained devices. As we can count on Java being included in phones and other mobile devices, we create a more robust environment for our devices if Jini (and JXTA, and even Rendezvous) is present as well. Consider, for example, a Jini-enabled presentation tool that allows you to view the slides being presented in a different room on your cell phone. That same application could be used by you to deliver a presentation from your cell phone that others could view on their phones, laptops, or on a projected image in an auditorium.
This is an important time for the adoption of Jini. Opportunities abound on the desktop, in the enterprise, and in mobile devices. There are many efforts to enable distributed computing in each of these settings that could be aided by the presence of Jini. Jini is not the answer in every situation, but it is a potential solution that is often overlooked.
Some of the reasons that Jini has been ignored can be rectified. It is difficult to get started with a Jini application. The "out-of-the-box" experience must be improved. There needs to be an ease of use for end users that would require a Jini lookup service be present without requiring any action on their part.
Brian Murphy asked how we can, or should, measure the success of Jini. We can't measure it by the number of developers working on Jini code. Even at a large application such as Orbitz, there is only a small core of developers who write Jini-specific code. Hundreds of developers work on the entire application, and millions of end users take advantage of Jini without knowing it. How should we measure the success of Jini?
Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.