Summary
One commenter on my previous blog entry suggested that, because "Jini has recently been released by Sun as an ALV2 licensed opensource system. Thus, the door has opened for a whole new wave of distributed systems revolution."
Advertisement
Jini is clever technology, but it's been around for quite awhile and yet to make a big impact. Maybe it will someday, but not until the presentation and packaging changes. For instance, the most common example given for Jini seems to be the "smart printer" example, where you need to print something and your Jini client dynamically finds an available printer. I asked Bill Venners if anyone had ever implemented this, and he said no. So when you give people this example, and then say that Jini isn't really used for that, it leaves you with the question "what do I use it for, then?" AOP had this problem for the longest time, when the single example they gave was "logging." People came away thinking, "Well, if I ever needed to do a lot of logging that way, then maybe I'll go to the trouble of learning AOP."
Jini also needs a better out-of-the-box experience. You should be able to install it and throw together a Jini server and client with only a few simple lines of code and very little research. Linux had this problem for years, where you'd start to install it and it would begin asking arcane questions about your computer hardware configuration. I tried installing it once a year, for two or three years, giving up each time because I was just curious and not interested enough to put a lot of effort in. Only when Red Hat came along and made the install easy did Linux begin to get some real traction.
But finally, I have to ask whether Jini solves a problem that we need to solve, enough to go up the Jini learning curve -- and Bill also said that the Jini learning curve is not an easy one. Yes, Jini solves the problem of communication between service providers and service consumers on a network, where both providers and consumers can come and go as they please. But if it's too hard, then I will find a simpler solution. For example, no one has actually implemented the Jini printer example, which is presented in the literature as the classic simple example of a Jini application. They probably decided it was easier just to plug a printer into their computer than to implement the example.
The problem of "too hard" is often ignored by technologists. One commenter on the previous blog entry said that the reason that WSDL/SOAP Web Services were not more ubiquitous is that, "Maybe because folks on both ends of the wire get overwhelmed by how theoretically complex one could make a SOAP service, don't see how practically simple it can really be..." But just saying it's simple doesn't make it so. The fact that folks get overwhelmed is the problem. It's a problem that has damned many technologies (consider JNI and RMI, for example), and I think it's why Jini hasn't taken off. You can't just take an afternoon and get something working as a throwaway experiment; it's a big investment of time and you don't really know if you're going to benefit from that investment.
Here's an example: I've recently been working on a distributed programming problem, and the possibility of using Jini came up. It quickly became obvious that the overhead of implementing the dynamic lookup mechanism -- which is, indeed, a clever and thorough solution to that problem -- was something that we had no idea how long it would take to implement. It was easier, and more predictable, to just do "the simplest thing that could possibly work," and to solve our particular problem rather than solving the entire space of problems that Jini solves.
Every once in awhile someone will write an article saying how great Jini is and how its day is coming. Or make a comment like the one on my last blog entry. Of course, anything's possible, but I've also heard the same thing about the Eiffel programming language, which has been around longer than C++. There are some interesting ideas in Eiffel, in particular Design by Contract (DBC) which seems to dominate much of the thinking in the language. DBC is an important contribution to programming thought, but the problem is that DBC is a necessary, but not sufficient solution to creating correct programs. I think Gödel's Incompleteness Theorem comes into play here. Is this why Eiffel has not taken the world by storm, and never will? Maybe. But it's been around long enough that it's had plenty of opportunities to do so, and for whatever reason, it hasn't. Jini, too, has been around for quite awhile and I haven't personally seen or used any Jini-enabled applications (that I know of) and I haven't encountered any problems that have motivated me to go up the Jini learning curve myself.
If Jini can come up with a more compelling story, a simpler learning curve, and an easier out-of-the-box experience, then maybe it will go somewhere. If not, I think someone will come up with a more straightforward solution to the problem (if we can actually pin down what the problem is), and that solution will be successful instead.
> There are some interesting > ideas in Eiffel, in particular Design by Contract (DBC) > which seems to dominate much of the thinking in the > language. DBC is an important contribution to programming > thought, but the problem is that DBC is a necessary, but > not sufficient solution to creating correct programs. I > think Gödel's Incompleteness Theorem comes into play here. > Is this why Eiffel has not taken the world by storm, and > never will? Maybe. But it's been around long enough that > it's had plenty of opportunities to do so, and for > whatever reason, it hasn't.
Couldn't the same arguments used against static typing be made against DBC? In a nutshell, it doesn't provide enough value for the work you put into it?
I'm not saying this from experience. I'm just throwing it out there.
> Couldn't the same arguments used against static typing be > made against DBC? In a nutshell, it doesn't provide > enough value for the work you put into it?
If you mean from the standpoint of deterministically correct programs, I suppose. I do find, however, that DBC is often a useful approach (even without language support; look up "Design By Contract" in the index of TIJ3 or TIJ4), whereas I seem to be able to easily create working programs without static typing.
Of course, we are taking the risk here that the conversation will devolve into a static-vs-dynamic argument. Which I'm tired of.
> > Couldn't the same arguments used against static typing > be > > made against DBC? In a nutshell, it doesn't provide > > enough value for the work you put into it? > > If you mean from the standpoint of deterministically > correct programs, I suppose. I do find, however, that DBC > is often a useful approach (even without language support;
Yes, that's just a good practice and I don't mean to devalue the DBC contribution to software developement. But again this is very similar to the static vs. dynamic argument in that it comes down to whether this is something that is dealt with at the human level or if the machine enforces it.
> Of course, we are taking the risk here that the > conversation will devolve into a static-vs-dynamic > argument. Which I'm tired of.
Yes I am too. I just bring it up because it has an interesting parallel and because I've recently gone from the static camp to fence-straddling on the issue.
> <p>The problem of "too hard" is often ignored by > technologists. One commenter on the previous blog entry > said that the reason that WSDL/SOAP Web Services were not > more ubiquitous is that, "Maybe because folks on both ends > of the wire get overwhelmed by how theoretically complex > one could make a SOAP service, don't see how practically > simple it can really be..." But just saying it's simple > doesn't make it so. The fact that folks get overwhelmed is > the problem.
I agree with Bruce here, if it is perceived as too complex, then it IS too complex. And although tools that wrap around the complexity do help, it's just not the same as being simple in the first place, because the underlying complexity often sip through. This is the same thing that original EJBs suffered from, and EJB3 was a great improvement evidenced by the fact that in a JavaOne demo, notepad was the editor used to code an EJB. I also recall something Anders Hejlsberg said in one of Bruces's taped interviews. Found the quote: "There's one kind of simplicity that I like to call simplexity. When you take something incredibly complex and try to wrap it in something simpler, you often just shroud the complexity. You don't actually design a truly simple system. And in some ways you make it even more complex, because now the user has to understand what was omitted that they might sometimes need. That's simplexity. "
Jini is something that when looking from a higher level, seemed reasonably simple, but after looking at the code sample, one can easily get lost in the complexity. I think this is because the spec tried to do too much and be too general.
I was thinking that if I found a problem that Jini solved AND Spring provided a simple template or wrapper for it, I might give it a shot!
I work down the street from the offices of Orbitz who have been touted as having widely deployed Jini and Javaspaces. Per my limited understanding, they seem to use it to provide midddleware / backend services that might otherwise have been deployed as EJBs.
So if you have used Orbitz to book travel, I imagine you have indirectly used Jini.
I think one weakness of Sun is its reluctance to implement its own technologies and Jini is perhaps the best example. At times it seems as if their slogan is "The Whitepaper is the Product" rather than "The Network is the Computer".
I'll bet that Java would be a lot more successful today if Sun had bothered to create a competitive IDE at the time of it's original roll-out rather than waiting for third-parties to do it.
<dumb joke> Press release: Today Sun announced Jeinfeld: The technology about nothing. It can connect Jini enabled devices through an entirely abstract (i.e nonexistent) network. </dumb joke>
There is nothing wrong with Jini, and I disagree with Bruce that Jini should be "withered."
There are several problems, indeed, with the way Jini was presented, and that created a huge confusion over the years.
First, Jini provides a comprehensive answer to problems in distributed computing - answers to problems that were especially ominuous in CORBA (several of Jini's architects were involved in CORBA development prior to designing Jini).
The key word is *comprehensive* -- Jini systematically solves the problems that many other systems encountered in real-world deployments. As a result, Jini is not only a tool or an API, but is also a programming model for distributed systems.
One of the implicit notions behind Jini is that distributed systems development can be made easier with a comprehensive solution, as opposed to providing a piecemeal set of patchwork technologies each aiming to solve parts of the puzzle.
While most developers would at first frown on the idea of a comprehensive solution, it's worth noting that such a comprehensive approach has proven necessary for anyone building real-world distributed systems. Hence the numerous WS-* standards. Of course, it is possible to send messages over a plain HTTP connection, sure. And there are probably many, many uses for such a simple approach. But if you want to build a secure system, provide some transactional integrity for your communication, etc., etc., then you need to use all those WS-* technologies *together* - or use Jini, because Jini provides all those capabilities.
The often neglected issue any Jini and Web services comparison is that Jini doesn't work across a WAN (i.e., the Web). Actually, it does work, but using Jini over a WAN is complex, and you end up giving up a large part of the nice service discovery attributes that Jini provides and that don't exist for Web services.
Jini would work well over a WAN if there existed a public infrastructure, much as there is one for IRC or HTTP. If there were secure, easy-to-use public Jini lookup services, then it would be possible for one to write a Jini client with just a few lines of code and invoke services available via that public infrastructure.
Writing Jini clients is much, much, simpler than writing Jini services, much the same way writing Web server clients is easier than writing a Web server.
And even writing a Jini service is not much harder than writing a servlet. However, whereas servlets can be executed in any of the large number of servlet engines, Jini never had a similar container infrastructure. That means that even if you write and publish a Jini service, you couldn't easily deploy that in production. That's the hard part of using Jini, and that's where most of the learning curve is today.
While focusing on the LAN (e.g., the data center), is probably Sun's biggest business, it is the WAN (the Web) that causes technologies to spread and develop. Jini has not really, and not visibly, participated in the stack of technologies that can be accessed through the Web.
Finally, the whole code mobility issue has not yet been explored fully in the Java community. I think it might be, though, as IoC meets the Web: In other words, if you can inject dependencies into an application at runtime that refers not only to a locally available resources (e.g., a database connection), but to a service accessible across the network, and especially across the Web. You would want to do that, for instance, to incorporate functionality from somebody else's service into your application.
There are thousands of examples of why you'd want to do that: to process credit card payments, to arrange shipping, etc. Instead of having to deal with a FedEx Web service API, you could then write a servlet and incorporate something like this in processing shipment:
ShippingService could be a dependency injected at runtime, and could represent a remote service to Fedex or UPS or the USPS, etc.
Of course, you can do that now with Web service, but with Jini and code mobility, and an IoC container, that's *all* you'd have to write: all the code, etc, would download into your application server at runtime. (BTW, this could also be achieved by wrapping WSDL lookups into with a Java service object, and dynamically creating proxies from that WSDL. I don't know if anyone has done that, though. I know that Apache's Axis had a tool that did something similar.)
I don't know if that will happen in the context of Jini, though, because it requires stepping beyond simple message exchanges, and the entire Web service/system integration business seems to now center around message interchange.
In addition, JavaScript now seems to be the mobile code of choice, not Java bytecode. Clearly, a lot of investment is made into making JavaScript easier to work with on the client, and Java 6 will even have JavaScript support built in.
> Thanks James. I think I should still keep my day job - > once I find one.
You really hit the nail on the head about Jini. I really did give it a try, and I really had an application that I knew would benefit from a t-spaces implementation. But the Jini out-of-the-box experience was too much even for me. I say that as someone who has climbed the mountain of hard-to-get-started before, using Linux before RedHat, Java before 1.2, and Perl before O'Reilly books came out.
It wasn't that I couldn't make it work, it was that there was no "kick it off and make it go to try something out one rainy afternoon" experience. The one click Ruby installer (http://rubyinstaller.rubyforge.org/wiki/wiki.pl) is the example I point to as the ideal experience.
The comment before about a Spring template rings true also. I've become a fan of "quickstart" tutorials. As part of the out-of-the-box experience there should be a sample service, with code, that is neither too simple, leaving out key concepts, or too complex, overwhelming with ptions and variations. It should be more or less obvious to the programmer where in the sample is the boilerplate that all services need to have and where the application-specific code is, so that for a first cut someone new to Jini can just copy the sample and replace to example behavior with something familiar. I happen to like the "Hello World" code in the GTK+ 2.0 Tutorial (http://www.gtk.org/tutorial/c58.html#SEC-HELLOWORLD), because it got me started in a hurry, and didn't throw in anything superfluous or confusing at the beginning.
> There are several problems, indeed, with the way Jini was > presented, and that created a huge confusion over the > years. >
Speaking of which -- I haven't looked at the changes to the licensing since the last Sun release, but before that as I read the the terms there were a couple of things that programmers couldn't do that I thought were key to allowing a community to build.
One was that you couldn't create and distribute any patches or changed code that would allow for example a replacement implementation that would run as a servlet under Tomcat, and other was that you couldn't integrate it with other tools, so for example creating an Eclipse plug-in to allow easy Jini development and testing.
I can understand and recommend "whither" Jini, I'm just left with the impression that in its current state Jini is destined with wither away.
I also agree with this thought of Jini in terms of "simplexity" as stated. I have been working on how to make Jini easier to work with for quite a while. I started using Jini just after it's initial release to the public. I was quite happy with the advances in Davis (version 2.0) and created the Maven Jini plugin to make it easier to work with.
With that plugin you can just run a Maven command and start Reggie (the service registry) and all the other base Jini starter kit services without installing the Jini starter kit and trying to figure out how to configure it for any project. It downloads the starter kit and configures it for you out of the box "except" you may have a problem with your Java security default configuration for you IP address. I put up a little troubleshooting section on the plugin's web site (http://maven-jini-plugin.dev.java.net/).
All of this does make Jini quite easy to work with for somebody like me who has already went through the bumps and bruises on multiple projects. I am still not sure how easy it is to work with for a newbie. I did have one friend who was able to startup all of the services quite easily based on the documentation. He also created his first Jini service project using the Maven 2 archetype I had created, as well. He was definitely a newbie since he had come over from .NET to do this. But starting those services up and actually writing services are two different ball games.
I tend to like the Rio project for my actual service development. I have found that most of my projects actually work best in a service grid anyways. Rio's documentation is not very straight forward and I would not just ask somebody to start working with that on any critical projects. It has a learning curve of it's own that could be smoothed out with some tooling and documentation. For me, it is a great tool for my projects and has now pretty much been integrated in the GigaSpaces product as the service grid.
I am not as much of a Spring fan but I have used Spring on 5 projects so far over the past 2-3 years. The reason for it's use is the ease of use (although not as easy as one would hope) and the ability to use mock objects through IoC. I could just as easily use PicoContainer for this or some other IoC framework but most of the developers I work with want to use Spring. They think it may look good on their resume or something. Who'd figure?
I do like Jini immensely. It has qualities which I revere from an architecture standpoint. Although the learning curve may seem an issue, once you get it, it just seems right. There are three things which I believe should live on even without the "Jini" brand:
* JERI - this RMI implementation blows all the old RMI ideas out of the water and should have been standard in the J2SE/JSE * JavaSpaces - tuple spaces have plenty of issues which they can resolve easily and performant * dynamic discovery - I believe that even this should probably be improved. The current limit is that you must compile your client with the interface of the service you would like to use. I think that this could be improved even further given enough time and resources
Since Jini has been licensed under the Apache Software License 2.0 it is quite simple for anybody to go and run with the pieces they like. Jini is also going into the Apache Foundation incubator which I think could be good for at least a few of it's pieces. Who knows, maybe Geronimo could find some usefulness of the Jini programming paradigm?
Previous Topic
