Tangosol, Oracle and Gevas blog

I was just looking at this Gevas blog entry and while I agree with his architecture assessment, I don't see why he alone is in this space. His space based architecture is what we all do already. Cameron does it, I do it with ObjectGrid, Geva does it with gigaspaces. You don't need a Java spaces API to do space based architectures. Everything he describes to characterize it is exactly what we all do anyway.

Here is what Geva says SBA embodies (copied from his blog, I hope he doesn't mind):

First:

• Collapse the tiers into a single process
• Co-locate the services in a single process
• Manage state and other in-flight data in memory

You have essentially created a self-sufficient process ("Processing Unit" in GigaSpaces parlance). No more network hops. No more database calls.

Now:

• Scale-out these self-sufficient processes across your hardware infrastructure (cheap, standard hardware, mind you)
• Have the middleware partition and load-balance incoming requests across the many processes
• Dynamical manage the environment from a single-point-of-access (but not a single-point-of-failure) with SLAs for response times and reliability

The resulting architecture is:

• Linearly scalable -- because there is no dependency among the Processing Units, the law of diminishing returns does not apply. Each additional unit added provides the same throughput as the one before it
• Low latency -- because network hops between the tiers and the services that make up the application have been eliminated, and because data and events are accessed locally and in memory
• Simple -- because you have a single clustering model to manage high-availability, load-balancing and partitioning across your entire environment

I coudn't say it better myself. Thats exactly what XD and ObjectGrid do at IBM. That architecture is what we're telling customer who have suitable applications that can leverage it.

Comments

[Dan Creswell]

So I think the real root of the issue is that "space based architecture" has a mixed meaning.

It's an expression of the underlying technology (JavaSpaces) and a particular vertical application (data grid?). I've never been a fan of the term as I've always felt it smelled of muddled thinking and caused confusion.

So Tangosol/Oracle, XD/ObjectGrid and Gigaspaces all support data-grid but only one of them is using JavaSpaces. There's obviously value in data-grid but I wouldn't pretend to understand what the axes of differentiation are between each of the products.

[Nati Shalom]

Billy it would be interesting to see an example that shows how all the different pieces between XD and ObjectGrid fit together to enable the end to end scalability of a stateful application. This could be a good basis for comparing between the different approaches and see the real difference.
As usual the devil is in the details. Based on my experience, even though there could be a lot of similarity at the very high level, the actual differences in the architecture, the approach and the implementation that we have taken is far more fundamental.

The advantage of using the space as the underlying implementation of SBA is the fact that it provides common and simple runtime for handling events, data and processing. I outlined some the benefits of SBA approach vs plain caching under the following post:

http://www.gigaspacesblog.com/2007/01/18/the-difference-between-space-based-architecture-sba-and-distributed-caching

In short DataGrid/Caching such as ObjectGrid is targeted to solve the data bottleneck and SBA is targeted to solve the entire application scalability from a holistic point of view. I'm sure that you will agree that these are two separate things.
The nice thing with our implementation is that we don't need to drag a full-blown XD application server with all the complexity associated with it to address that need.

Nati S.
GigaSpaces

[Billy]

I just read your blog and I gotta say I don't know which products you're categorizing as DataGrid but what ever it is, it falls well short of what we offer. I appreciate you're marketing spaces as a differenciator but lets call it what it is, it's just marketing.

ObjectGrid offers spaces (MapSets), data persistence, messaging, transactions, partitioning, processing units (partitions), horizontal scaling of processing units aka partitions, fault tolerance and disaster recovery for partitions/p.u.'s, i.e. everything you claim SBA requires. You can think of a MapSet/ObjectGrid in OG as the equivalent of your space.

We chose not to implement Java spaces as a business decision. It's a syntatic sugar on top of the same architecture. API wise, it's very verbose and not in popular use.

We view our runtime as a standalone grid enabled application server for extreme OLTP that can also be embedded in either a conventional container or a provisioning system such as XD.

ObjectGrid is based around a Mapset or a space in your language. Mapsets can be partitioned and replicated for scalability and persistence. Mapsets hold typed data in the form of a schema. This data can be indexed and queried conventionally or continuously. Entities within the MapSet can be treated as FIFO queues if persistent messaging is needed. A solution built on top of partitioned MapSets can be scaled at will at the level of persistence required by the customer with no latency degradation. We have customers building systems now with latency well under two ms per transaction and this latency is possible at any transaction speed through horizontal scaling.

An ObjectGrid MapSet can, of course, deliver services as part of an overall SOA system.

I understand that you are trying to differenciate yourself with buzzwords but lets leave the marketing somewhere else. You're doing a great job characterizing these new application architectures, but you are by no means the only game in town here with a platform that can do it.

Thanks

[David]

Could not agree with you more Billy!

The thing that Nati typically forgets to mention is that you have to use the Gigaspaces container. So while you don't have to "drag in" an XD container, you have to use a different one... the Gigaspaces one right?

With something like Tangosol/Oracle Coherence (or ObjectGrid as I know), your just including a library, or if you like, running a standalone application (of which you can modify). The choice is yours. That library allows you to massively and resiliently clustered your applications JSE, JEE, Tomcat, Spring, .NET (or what ever), resiliently manages your data (allows applications to become scalably stateful) AND provides reliable Grid-based processing ie: provide services to applications or the Grid itself! All of which makes it far more than 'just a cache' and without having to adopt a Space paradigm and make everything an "Entry" (or do some magical AOP to do this for you)

And let me make this very clear... there is nothing wrong with the Spaces paradigm. It's an architectural pattern for solving certain classes of challenges, just like, say, the master/worker pattern or caching is. But it's no silver bullet. I'm sure Dan would agree.

Of course, Nati will compare and contrast "just" the caching parts of Data Grids to Gigaspaces and for some unknown reason, leave out all of the bits that directly compete with Gigaspaces.

In reality technologies like ObjectGrid and for that matter Coherence et al often does all of the other stuff that Nati claims these "Data Grids" can't do. I can;t figure it out, but such claims and comparisons are either based on;

a). An unfortunate or complete lack of information.

b). Misunderstanding of the "space" and the consumers in it.

c). Marketing nonsense and/or

d). Deception.

Honestly, I think it's a terrible shame that the Spaces model gets mixed up in this. I look forward to the day that ObjectGrid, GemFire, Terracotta, Coherence and any other vendor product that does "Data Grid" offers an implementation of the Spaces API.

Developers can then compare "apples with apples", actually have a choice between implementations and invest less time on marketing so they think more about solving the challenges of today and tomorrow. (though they already have a choice if they use Bliz! Rock on Bliz!)

[Dan Creswell]

Yes David, agreed re: spaces suitability.

And, did you mean Blitz rather than Bliz? http://www.dancres.org/blitz

[Simon]

This SBA stuff really is just marketing fluff. A more interesting comparison is that while you could easily build Javaspaces on top of Coherence you most certainly could not turn Javaspaces (or Gigaspaces for that matter) into Coherence.

[Billy]

Exactly right or ObjectGrid for that matter :)

[David]

Doh!

A thousand apologies Dan. Typing too fast while being asleep.

Get the real thing here: http://www.dancres.org/blitz

[Cameron Purdy]

Hi Billy,

The only thing that surprises me is that you took the time to analyze something that is so obviously marketing fluff ;-)

Yes, of course "SBA" is just a repackaging of the approach that we have been promoting for half a dozen years now.

Despite that, it is tremendously exciting to see this market growing, and the solutions in our space maturing, and the work that Gigaspaces is doing to draw attention to solutions such as our own is a very positive thing.

Peace.

[Nati]

Sorry for the delay in responding, i was away on vacation:)

I'll repeat my comment from the previous post:

"it would be interesting to see an example that shows how all the different pieces between XD and ObjectGrid fit together to enable the end to end scalability of a stateful application. This could be a good basis for comparing between the different approaches and see the real difference.
As usual the devil is in the details."

I'm sure that those that claims that SBA is marketing fluff would appreicate such comparison.

Those that still thinks of GigaSpaces as just a JavaSpaces implementations need to do some homework, i would start by looking at our documentation. Its been 6 years since we implemented the spec and as you can imagine we evolved quite significantly from that point.

As a background the term SBA has evolved from years of experience in building scalable applications for mission critical applications. We used it to define a pattern which we found as a good reciepe for addressing the scalability of statefull applications. It is very similar in principle to the "Share Nothing Architecture" that was commonly used to adress scalability of web based application. See the refernece below:
http://www.zefhemel.com/archives/2004/09/01/the-share-nothing-architecture

It's real, its working and its broader then JavaSpaces API.

To be clear I'm not arguing that you can't implement SBA-like implementation using other products and i would agree that you don't nessaraly need to comply to the JavaSpaces spec to build such architecture. See my comment on that regard when i wrote the first paper that introduced this concept:

"..SBA is a logical architecture that combines the different patterns mentioned above - caching, messaging and parallel processing - for building high- performance, stateful SOA applications. SBA is aimed at providing a broader conceptual architecture and is not necessarily limited to the JavaSpaces API..."

http://www.sun.com/emrkt/srsc/gigaspaces/GigaSpacesEndofTierBasedComputingwp.pdf

My argument is that the performance, scalability and complexity would be very different if you will try to achieve that by bundeling togather multiple technologies and products vs trying to provide a single holistic solution for addressing the end-to-end scalability.
I would also argue that addressing the end-to-end scalability is very different then addressing the data-scalability.

I'm sure that the difference between the different approaches will become more obvious pretty soon with our next release.

Nati S.