>From one point of view, an ESB is a pattern (as IBM once professed). >From another point of view, an ESB is a product platform (as seems to be the mainstream conception). One's point of view will determine your philosophy on one vs. many ESBs and also the necessity of the ESB.
A trivially simple definition of ESB as a pattern could be a mechanism for enabling Service-to-Service communication and composition. Yeah, that's simple. Too simple? Who knows, but I think it works. A trivially simple definition of ESB as a platform could be a stack of infrastructure technologies that enable Service exposure, consumption, composition, and value-added messaging. Yeah, that's simple too, but seems to fit. Does SOA require ESBs? Not any more so than n-tier architectures require application servers. Can you do SOA without an ESB? For sure, but we've already talked this one blue. You can certainly do highly scalable web-apps without application servers, too. Can you do SOA with ESBs? Sure, just as you can do highly scalable web apps with application servers. Who has the answer? Ron of course. Err, I mean, you do. Figure out what works for you, but don't be too dogmatic - realize that there are many ways to skin the SOA cat. And in any case, I already discussed the need to do architecture first, technology selection and implementation last. Don't let the technology drive the architecture, or depression (manic?) might set in. You're the market - you decide what works. Horse: dead and beaten (what's up with all the animal mutilation?) Ron: gone (but not forgotten!)
