To ESB or Not to ESB

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.