Does SOA Require an ESB?
July 6th, 2006
Forrester’s Ken Vollmer takes issue with my inference that a BPMS truly layered on SOA must include an ESB in order to achieve the “loose coupling” promise. He writes:
I guess the one point I would argue with you is that you seem to equate SOA with ESB’s and that is not a good way to think about it. SOA existed way before ESB’s in the form of CORBA and DCOM technology. So ESB’s are a newcomer to the SOA world.
Also, ESB’s are just one alternative for achieving SOA. The other major options are application servers and BPM Suite products. Both of these have ESB features and much more baked into their solutions.
Just so you know that I know what I’m talking about, I cover ESB’s, BPM and SOA at Forrester.
CORBA? DCOM? Loose coupling? I guess I don’t know what I’m talking about! Whatever, Jesper’s post I referenced yesterday still computes better for me. By Ken’s definition, BEA already has all 3 ways to do SOA - an app server, BPMS, and ESB - without even putting them together!
But I don’t think I’m the only one confused on this issue. There is a long thread on Yahoo Groups in which some heavy hitters weigh in on the relationship of SOA to ESB, and come to no recognizable conclusion.
Entry Filed under: BPM
2 Comments Add your own
1. Derek Miers | July 11th, 2006 at 5:13 am
As we all know Bruce - SOA, ESB, BPMS, … in the end they are acronyms designed by vendors to help them differentiate their products … so it is always going to be contentious. The categories will always overlap … each vendor wants you to push their version of the truth. The most interesting posting in that long thread was from Ann Thomas Manes:
“For the most part, “ESB” is a marketing term. Sonic invented the term is 2002 (I think — maybe it was 2001) to describe its then new XML-enabled messaging system. Shortly after that, Gartner picked up the term and proclaimed that it referred to a combination of SOA and EDA (event driven architecture) — i.e., something that supports SOAP request/response and MOM-oriented reliable messaging and pub/sub. At that point nearly every MOM vendor had to have one. From that perspective, I refer to ESB as MOM++. Products that fall in this camp include Fiorano ESB, IBM WebSphere Message Broker, Sonic ESB, Tibco BusinessWorks, webMethods Fabric, Mule, and ServiceMix.
But by 2003, a bunch of other vendors hijacked the term and applied it to their own integration products, which weren’t necessarily MOM-based. Products that fall into this category include BEA AquaLogic Service Bus, Cape Clear ESB, IBM WebSphere ESB, IBM WebSphere Process Server, IONA Artix, Polar Lake, Oracle ESB, Software AG crossvision, Sun SeeBeyond, and Celtix. These systems tend to be pretty different — the one thing in common is integration and support of web services.
Then there are what I categorize as pure-play mediation systems: Apache Synapse and SOA Software Blue Titan — not really ESBs, but certainly a viable alternative.”
Pretty much summing up the hype whipped up by big tech vendors around their current set of products.
2. bruce | July 11th, 2006 at 2:10 pm
Derek,
Sure there is lots of hype, but there is also an idea behind the bull, which has to do with loose coupling. I think you could paint an SOA picture around architected business services that didn’t prattle on about loose coupling, but no one does. Even the great AT Manes puts loose coupling right up there in her defintiion of SOA.
ESB is the middleware of loose coupling. CORBA and DCOM and those other things Ken is pitching are described by today’s SOA as not-loose-enough-coupling… that’s why we ditched them (supposedly). That’s not vendor hype (but it might be architect hype).
So taking the old anything-vendors-say-is-BS line does not really advance the ball. I was just trying to say that few BPMSs use either architected business services or ESB, so what do they mean when they claim to be founded on SOA?
–Bruce
Leave a Comment
You must be logged in to post a comment.
Trackback this post | Subscribe to the comments via RSS Feed