Grid Computing Overview

Posted by Stefan Tilkov on May 25, 2006

Sections

Enterprise Architecture,

Operations & Infrastructure,

Architecture & Design

Topics

WS Standards ,

Web Services ,

SOA ,

Grid Computing ,

Jini ,

Architecture ,

Enterprise Architecture

Share |

RELATED Research

• MPI (Message Passing Interface)
• MapReduce
• Sun Grid Engine
• OSGA (which is based on Web services and the Web Services Resource Framework, WSRF)
• The Jini-based Rio
  
• Gridbus
  

Not only is my antipathy to the WS-* suite well-known, but the specs clustering around WSRF have always struck me as particularly offensive, since on the face of it they seem to re-implement HTTP (badly) on top of SOAP on top of HTTP.

RelatedVendorContent

Requirements, quality and test management e-Kit

Cloud Access 360 Overview

Modeling Your Cloud Services Brokerage

Introduction to WebSphere Liberty Profile

Getting Started with REST: Free Cheat Sheet

Related Sponsor

*Free Gartner Cloud Security Report
*REST Security Reference Card
*Securing your APIs in the Cloud

1. Back to top

   Tangosol Coherence InvocableMap and Grid Features

   by Jason Carreira

   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

   Reply

2. Back to top

   Re: Tangosol Coherence InvocableMap and Grid Features

   by Cameron Purdy

   Spaces in URLs .. ;-)
   
   tinyurl.com/zobej

   Reply

3. Back to top

   follow up

   by Cameron Purdy

   (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.

   
   
   Tim is still thinking in 1980s terms. He is still thinking client/server, but he's trying to rename it as a grid.
   
   Servers no longer have a hostname/port. In the grid, there is no such thing as a server. All you have is the grid. The servers within the grid are no more individually addressable and reachable than the CPUs within a particular server. If the grid needs to expose a service, it does so through a port on a load balancer that represents the grid as a whole.
   
   Apologies to Sun, but:
   
   The Grid is the Computer.
   
   Peace,
   
   Cameron Purdy
   Tangosol Coherence: The Java Data Grid

   Reply