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 JVMsOSGi 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.
5 comments:
Hi Patrick,
So I have some other things to do this week but maybe you'd like to do a skype discussion (or a phone call or IM) next week?
In the meantime, one thing that Jini has at it's core that the (red herrings) likes of CORBA and RMI don't is that Jini services don't rely on stubs (dynamically or statically generated). And further, if there is code that needs to be placed on the client-side, it is downloaded at service discovery/bind time.
These differences appear trivial to start with but lead to some very neat abilities. There are a number of other nice benefits to building services the Jini way which I'll leave for later.
I'll finish by saying that many a techie has the impression that JavaSpaces are just for compute farms and Jini is just another CORBA. They're wrong though that's forgivable as even some "Jini experts" unwittingly present things that way.
Best,
Dan Creswell
http://www.dancres.org
dan_no_spam_dot_creswell_at_nospam_lonecrusader.co.uk
Thanks Dan.
I am not concerned about the CORBA/RMI statement.
What interests me in this post is Tangosol's equating Coherence with Jini/Javaspaces. Or at least they are saying you don't need Jini if you have Coherence.
Well, why should I believe this? On the surface the feature sets don't line up, so there must be something deeper.
Okay, got a better picture of where you're coming from now - onwards:
"What interests me in this post is Tangosol's equating Coherence with Jini/Javaspaces. Or at least they are saying you don't need Jini if you have Coherence."
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.
"Well, why should I believe this? On the surface the feature sets don't line up, so there must be something deeper."
Indeed - basically, if all you want to do is build stuff with Jini in a traditional enterprise style following all the old patterns, you're missing the point and making your life more complex. But there is another way.....
I could certainly build a distributed data grid with javaspaces, and jini is how we get at the javaspace service. I think, as others have commented, that seeing JINI as traditional means you are just trying to do the same old things with a different technology.
I took part in a grid computing vendor selection project back in 2005, it was interesting to compare the underlying philosophy behind the approaches. There was the 'database centric' design, the grid as a data cache but the basic design of the software running in the grid remaining 'traditional'. So the data remains seperate from the tasks, and we only really solve part of the problem: we try to avoid making the database a bottleneck by having a cache, but distributing the tasks around the grid and providing access to the the services the tasks provide is not really addressed.
With javaspaces things are different, its not about building a cache around a database. Spaces give us distributed associative memory, if we have a database at all it's as offline storage - a backup of the data, not the centrallized repository. We can put our data and tasks into the space, we can use jini to expose the compute services our grid provides. We can start to think in new ways about how to build distributed systems where tasks collaberate by putting and taking data and tasks in the space.
btw - couple of interesting open source efforts:
http://www.dancres.org/blitz/
http://newton.codecauldron.org/
Hi all,
I’m a bit dismayed at the “my toy is shinier then your toy” angle that this discussion is taking. While Tangosol Coherence is the most successful Clustered Caching solution in the market (fact), Coherence continues to innovate, expand and define new segments of the market, including Data Grids and grid-based Complex Event Processing (CEP) and Event Driven Architectures (EDA).
Further, Tangosol Coherence has never been marketed as a replacement for Jini. Jini/JavaSpaces are clearly targeted as a means of coordinating processing across a distributed environment (oversimplifying a bit). Coherence is clearly positioned as a data management solution that builds on distributed technology to provide reliable and scalable data management, notably in the areas of transactions, analytics and event processing.
Tangosol Coherence, as competing vendors should know and reasonably acknowledge, provides many extensions to the Clustered Caching and Data Grid concepts (just as Gigaspaces provides many extensions to the concept of JavaSpaces and the Spaces paradigm itself - like “Space Workers” as I understand them). Coherence also provides many facilities to support the SOA paradigm, and while not generally marketed as such, many engineers still choose to use it as their sole SOA platform. I guess the frustrating thing for some vendors purely pushing the Enterprise SOA message is that Coherence has the inherent flexibility to do so and does - just as some solutions also 'do caching' to some extent.
For example: Coherence provides Parallel EntryProcessors, Parallel Aggregation, Parallel Indexing, Parallel Filtering, Parallel Queries, Parallel Event Processing Synchronous and Asynchronous Storage and so on that are all available out-of-the-box and have been for years. It also provides grid-based agents and distributed workflow management that includes guarantees for service execution. It also provides a very clean .NET integration without the need for code-bridges, JNI, additional wrappers, third-party libraries etc. In reality, I would say that the majority of Coherence implementations use these features more often than say the 'standard caching' stuff. And I'm not talking about 'you could build this stuff on top of coherence', I'm saying 'this stuff already exists and can be used out-of-the-box'. I should know, since before working for Tangosol, I used Coherence as the basis for the algorithmic futures trading system and algorithmic direct-market execution system that my previous employer uses.
Other vendors’ failure to acknowledge such features in Coherence could be due to poor knowledge of the domain, or possibly a lack of confidence in their own solutions forcing them to resort to FUD and confusion. In any case, it is unfortunate for all involved, and casts those vendors in a very bad light.
Jini and Javaspaces clearly have their uses. I am involved with projects using Jini, Javaspaces and the space paradigm itself, and will continue to push these technologies within Tangosol. I can tell you that within Tangosol, there is no objection to the use of Jini, and there are a number of fans of Dan Creswell’s open source Blitz Javaspaces. We believe that Jini has compelling features for compute and service grids, which is where we will use and leverage it. We view Jini as just another possible way for our customers to get to their data and services hosted by Coherence grids, which are now deployed in so many of the major banks, insurance companies, ecommerce sites and so on I can't keep count. As the market leader, we have even volunteered to work directly with our competitors if our customers request it. We already work closely with IBM’s grid efforts, for example, but it would also include smaller vendors such as Gigaspaces.
-- Brian
-----------------------------
Brian Oliver
Data Grid Solutions Architect
Tangosol Inc.
Post a Comment