Final Update:
This is my final update to this post. I will start a new one on some related topics. This update is just pointing out a new comment below from Brian Oliver of Tangosol.
The comment is fairly lengthy so I will not pull anything out here into a quote. I recommend reading it. There is good technical content I should put into another post.
The one thing I will say here is: my blog will not become a forum for vendors to pick on each other. It's not there yet, although it is walking the line. I simply will not approve your comments if I don't see them contributing to my technical interests.
This is my blog. I have spoken.
:-)
Reading Brian's comment one might get the impression any misunderstandings I have of Tangosol come from a competitor. That is not the case. I have met with Tangosol people in person. Any misunderstandings come from them.
:-)
Just *kidding*!!! Actually I have met with them, and they have a number of questions they're following up on. The misunderstandings are mine alone.
End Final Update
The notion that Jini/Javaspaces and Tangosol Coherence are direct competitors seems to come up fairly often. At least from the Tangosol folks. I think that's because Tangosol and Gigaspaces compete in the scalability market. Gigaspaces sells their non-standard features to the performance-challenged... update-in-place, etc.
But this seems to ignore the Jini part of Jini/Javaspaces as well as most of what a Javaspace would be used for. That gets short-shrift...
If the benefits of an organic model sound familiar, then you're probably already using the world's most innovative distributed system. If you're still struggling with traditional exception-based or recovery-based approaches to distributed systems (e.g. CORBA, JINI, RMI), then you have my deepest sympathy, but it's not too late to switch.
I will ignore the obvious red herrings in CORBA and RMI. But as for Jini...
I would really like to see how Tangosol Coherence lines up against all the things in Jini. Coherence is a distributed/shared data cache. One would have to establish all kinds of conventions to get the cache and its contents to do Jini-like things. Coherence is fairly proprietary as well, but ignore that for now.
Maybe the message is Jini-like things are not necessary. That seems to assume everything you need is in your cluster of Coherence-loaded JVMs. Coherence has some nice features, even for implementing Javaspaces and other standard capabilities above it. But that's not the claim being made over and again. The claim seems to be: you don't need Jini because our clustered cache is better.
Apples and oranges? I'm looking for better answers than that if someone can point me to an in-depth Jini/Javaspaces vs. Coherence comparison.
Update 1: btw there is nothing like getting up in the morning looking forward to working with the people you sit with, and then hearing later in the day how amazed the CIO and all kinds of people are with the team's results. We get to do good stuff that counts, no BS.
Update 2: Dan Creswell comments below, lending to my suspicions...
Right, so if you are under the impression that all you do with Jini/JS is build compute servers/farms, then you might assume this equivalence.
Update 3: Ian Cartwright comments below about conventional and unconventional uses of Jini/Javaspaces. He includes a link to an interesting combination of OSGi and Jini...
Newton makes use of OSGi for wiring up composites within a single JVM and Jini technology for tracking and wiring up dependencies between composites in different JVMs
OSGi is what Eclipse uses to wire independent objects into its JVM. Some folks on the team were looking at that for a related effort.
Update 4: Nati Shalom of Gigaspaces confirms the emerging consensus that Jini and caches complement each other, and a Javaspace can be used as a kind of cache, although for other uses as well. As Dan Creswell wrote somewhere, caches tend to have more reads than writes, while javaspaces (when used for coordination rather than as a cache) tend to have more takes and writes, fewer reads. A quote from Nati's comment...
If you’re building an SOA application, you'll need more then a cache. In fact, a cache gives you almost nothing on that regard. You will need a Service framework, which is what Jini provides. A service framework deals with how you discover, find services, invoke them, make them secure, manage their life cycle, etc.
Another part of his comment refers to
the Rio extension to Jini/Javaspaces, an interesting service management framework. All open source under Apache as well. Some of those ESB folks should look at it.
