Grid Computing Overview

He briefly mentions Tangosol, but he should have checked out their grid processing support:

wiki.tangosol.com/display/COH31UG/Scaling Out Your Data Grid Aggregations Linearly

Spaces in URLs .. ;-)

tinyurl.com/zobej

(as posted originally on TSS)

Building "sigrid" may have been a fun exercise for Tim, but business application architects and developers are looking for some pretty specific things, such as:

1) stable state image, even during and after server failure
2) resiliency and consistency of operations across a distributed environment
3) guaranteed semantics, such as "once and only once" and "guaranteed delivery"
4) all or nothing semantics (e.g. no "partial failures")
5) automatonic processing (e.g. no manual recovery of transaction logs, no manual rollforwards and rollbacks)

Only after guaranteeing the various necessary qualities of service can one even earn the right to worry about scalability. One cannot later add correctness and deterministic behavior to a system. It is either designed in, or it is not.

Regarding the capabilities that were described in the article, the map/reduce capability and much more (but with the guarantees stated above) has been available in our Coherence product for a while now (Jason posted a link), as has the grid-wide batch and service invocation capabilities (since 2003). The truth is that Tim wanted to do something fun, so he made sure that there was nothing out there that would prevent him from deciding to have some fun ;-)

Here's the problem, though:

My problem is that I?ve been a Unix guy for twenty years and a Web guy for ten. My feeling is that if something says it?s a service, the right way to talk to it is to get a hostname/port-number combination, call it up, send a request, and wait for a response.