Summary
There is a raging debate about OSGi and Jini, yet again. Which isn't necessary or helpful. The two technologies are very different applications of similar design philosophies, and should not be seen as competitors.

I recently ran into a surprisingly reasoned piece on a controversy I had hoped had died down long ago, namely that between Jini and OSGi. I had been ignoring the discussion within the Jini community, hoping it might be simply local or just go away. But seeing someone be reasonable gave me hope that it might be time to think about these things in a clear way for a change.

People would be amazed at how long this discussion has been going on. My first encounter with it happened just before we announced Jini to the world, and was an attempt to make sense of the two technologies with the group that was working on OGSi within Sun. The manager of that group was a guy by the name of Jonathan Schwartz (I wonder what ever became of him?), but the questions were the same that we are seeing now. Jini is a service architecture. OSGi is a service architecture. Both have ways of dealing with services written in Java. So why are their two?

This, of course, is a classic example of what I have called the Highlander Fallacy, which briefly stated is the principle that there can be only one. If any two technologies can be described using the same set of words, then there is no need for both of them, and only one will survive. I call this a fallacy because, to use a technical term, it is total crap. Certainly, there are cases where there are two technologies that are described using the same words where the two technologies actually do the same thing in the same context with the same requirements and the same restrictions. In such cases, having two may be one too many.

But far more often the two technologies are described using the same words because the English language (or any other that I know about) allows very different things to be described using the same terms. Descriptions, after all, have to elide a lot of the detail, and it is often in the detail that the distinctions are to be found. The shorter the description, the more detail is elided. A description like X is a service architecture is so short that almost all of the meaning is elided. There are going to be lots of different technologies that fit this description but that are different enough in the elided parts to make it worthwhile to know, and use, them all.

In fact, OSGi and Jini are service architectures built for completely different contexts. OSGi is a service architecture for services that are in the same address space. It allows you to build programs out of cooperating services. And for that sort of thing, it is pretty good.

Jini is a service architecture for distributed systems that are built out of services that are separated by a network. And the network is a very different environment from the single virtual machine (my one real issue with Peter Kriens' blog is that he identifies Bill Joy as the one who first insisted that the distributed system is different from the local system; in fact it was either Peter Deutsch as part of the Seven Fallacies paper or it was Ann Wollrath, Geoff Wyant, Sam Kendall and me in our paper A Note on Distributed Computing). So in fact the two are not competitors, but rather applications of many of the same design principles to fractally similar but otherwise very different problems.

Even Jonathan Schwartz was able to understand this over a decade ago. You would think that the engineers involved in this debate would be able to figure it out by now...

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.