Patric, it is a very laconic explanation of Grid, thank you! Unfortunately, in the market, a word grid is associated with 'many' while bus is associated with 'one', which is much simpler to sell.
> That being said, who really wants an ESB? No one. Many software > architects and designers want the ability to perform various bits of > E, T, and L on different sources and sinks and to distribute the > results, but an ESB is a means to an end, not the end itself. A "grid > platform", by which I mean both what is commonly and mistakenly called > an "data grid" and a "compute grid" provides a superset of most of the > capabilities of an ESB. +1. - Michael ----- Original Message ---- From: Patrick May <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, June 27, 2008 2:56:33 AM Subject: Re: [service-orientated-architecture] Re: Vandersluis on a Data Abstraction Layer's Benefits On 26 Jun 2008, at 13:50, Gregg Wonderly wrote: > htshozawa wrote: >> >> Hi all, >> >> Database abstraction is one of a topic being resolved by OGF. They >> are >> doing a really nice job of distributing queries, but I have to say >> that >> it's a little off of the business SOA concepts. >> >> Food for thought: Can a grid platform be made to be usable as an ESB? > > Look at gigaspaces for one example... In deference to our esteemed moderator I was trying not to pollute this list with crass commercialism, but Gregg popped my cork (so to speak). For the record, I am employed by GigaSpaces. However, I joined GigaSpaces because the software architecture is excellent, I'm not claiming it's excellent because I work for GigaSpaces. That being said, who really wants an ESB? No one. Many software architects and designers want the ability to perform various bits of E, T, and L on different sources and sinks and to distribute the results, but an ESB is a means to an end, not the end itself. A "grid platform", by which I mean both what is commonly and mistakenly called an "data grid" and a "compute grid" provides a superset of most of the capabilities of an ESB. The one functional area in which typical ESBs do not overlap grid platforms is the ability to transform various object formats. Once information is mapped from the source formats into a common model (often an OO model, which is why "data grid" is a misnomer), the publish/subscribe or queueing transport layer most often provided with an ESB is pretty limited. A grid platform is far richer in functionality. Taking GigaSpaces as a (completely arbitrary) example (solely because Gregg brought it up), the concept of Space Based Architecture (SBA) addresses the non- functional requirements of scalability, resiliency, and performance through the profoundly simple idea of a processing unit. A processing unit is a lightweight container that co-locates the business logic, messaging infrastructure, and objects required to execute one or more instances of an end-to-end business transaction. A processing unit runs, as might be expected from the name, in a single process, thereby providing extremely low latency. The processing unit is the unit of scalability and recovery. This makes high throughput achievable through the simple expedient of running more instances of the same processing unit. It also means that, after a failover, both the data (objects) and business logic are recovered. That's enough of the sales pitch (http://www.gigaspac es.com). The answer to your question is that yes, Virginia . . . er . . . Hozawa- san, you can get all of the benefits, and more, of an ESB from a grid platform. Regards, Patrick [EMAIL PROTECTED] .com ---- [EMAIL PROTECTED] S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)
