Re: Reengineering Java EE Servers
Posted: Nov 13, 2007 12:24 PM
> In that case, we must ponder why everyone doesn't just use
> JINI. I can only come up with three possible
Hi Cameron, thanks for jumping in!
> 1) People have an irrational dislike of JINI and so they
> avoid it despite it being free and providing what they
> need. This does seem unlikely, since there must be some
> individuals out there who would overlook their dislike in
> order to profit wildly.
I think that there have been some personal exchanges that have put some people in this group.
> 2) Somehow the industry is completely unaware of what JINI
> can do for them, so they invented other stuff instead.
> This also seems unlikely, since in the long term such
> valuable information would be hard to suppress.
Largely this is the point that I think makes the most sense of the three. People do know of the word Jini. What they don't know is how to use it. More on the point below.
> 3) It's not quite as appropriate and/or up-to-the-task
> and/or easy-to-use as indicated. This seems the simplest
> possible explanation that is consistent with the
My experience with the community, over the years, has taught me that people largely want something more than what Sun's original JTSK packaging provided. Because of J2EE and because of many other "container" systems, they didn't understand how to use a "toolkit" (the JTSK in particular) for building distributed systems.
Jini is not a container, it is a specification. Sun Licensing didn't allow others to freely build competing implementations. Key Sun management did not have any desire to use Jini because it was a "technology" thing, or because it was not a J2EE thing. I've been privy to a number of internal Sun discussions as part of the Sun developer advisory council. Sun is using Jini internally. A lot of people are using Jini internally and not talking about it. Some of the things I hear from such people is, "Jini is easy enough to use, that I don't want my competition to know how that could be more competative with me."
> OSGi has already solved a number of problems described by
> the article, and done at least a passable job of it. If
> you look at the work from Paremus, they mounted OSGi on
> top of JINI, so it seems that JINI didn't actually do what
> they needed in these respects, and OSGi did. I'd be
> curious about their spin on this.
Passable jobs are often good enough. OSGi's success has largely been led through its use and support by Eclipse, from my perspective. I think that at the point that OSGi was started, the Jini specification and the JTSK did not supply all the answers. Today, it is closer by a long shot, due to the 2.x changes for security and improvements in Javaspaces performance through batching. Because it isn't arbitrary, application specific code, it can be beat by benchmarks from other more vertically focused software, perhaps.
I use the Java mobile code model in lots of interesting ways through smart proxies. I hope to get a talk accepted at JavaOne this year that is about building a synchronized distributed system that is loosly coupled. It takes full advantage of a number of Java features, and really shows off how mobile code, smart proxies and other Java things provide the real power to make Jini a solution toolset.