To ESB or Not to ESB

, Jul 31, 2004

Radovan criticizes the ESB idea, i.e. the idea that SOA will be provided by a single, powerful middleware product that combines asynchronous messaging and Web services. I have my problems with the idea, too — I believe that SOA is not going to be provided by any single vendor, regardless of whether what they sell is an ESB, some integration server or other product. But that’s only because I view SOA as something very large-scale — I believe that SOA is not an architecture for applications, but rather for multiple applications, possibly across multiple enterprises (and it’s the connection of multiple enterprises, or autonomous business units, where the ESB idea breaks down).

In any case, I think there are three areas which merit distinct discussions:

  • Service-oriented application development, i.e. a methodology and set of architectural patterns that can be applied when the goal is to find a modular, flexible, future-proof architecture for a a new system;
  • Service-oriented integration, where the goal is not so much to provide something new, but rather to connect existing stuff; and finally
  • Service-oriented architecture (for want of a better term), which describes a higher level, multi-enterprise architecture of services that may or may not be facades in front of legacy apps or the outward-facing boundaries of newly developed systems.

If I found a better word for the last area, I could say that all three are subsets of the larger concept, which I would then call SOA. But you can also call them X, Y and Z — what matters is that you accept that different solutions discussed in the SOA space have different advantages for each of them. For example, I can see ideas from Microsoft’s Indigo to be a good match for the development of new ones; ESB (or Systinet’s Gateway) for the second, and maybe concepts from the REST space are suited for the third. Ultimately, it would obviously be great to have a single set of patterns for all three scenarios, but these are only just emerging.

On July 31, 2004 6:11 PM, Jean-Jacques Dubray said:

+1 +1 +1

except for REST matching the 3rd one, it is now clear to me that REST cannot support as it is state alignment -which is ironic, but I think true-, second REST cannot support the notion of data centric, a.k.a conversational, interfaces which are also mandatory for the 3rd one.


On August 1, 2004 10:21 PM, Steve Loughran said:

First, ESB scares me too. Integration hell is what springs to mind, “eternal cash flow to IBM global services” being the other. Nor do I see ‘one single ESB solution’ being adequate: the moment you have two companies merging, unless they use the same one, you are going to need an inter-ESB to glue together the different ESB systems.

But at the same time, I think SOA could be good. Or more to the point, I dont think the old Distributed Objects Pattern worked as well as intended.

One thing that large distributed object applications never seemed to enable was some third party writing code that plugged in to the system. It was always a self contained thing. So the ability of me to write a half decent front end to our intranet travel expenses app is zero. In an SOA world I could ignore the inherent awfulness of the front end app (or even the front end site), fetch the WSDL and write a python script to fill in my monthly vehicle mileage without so much suffering.