I've always railed against ESB as a concept, but it's still nice to find Microsoft echoing my point of view. According to an official Microsoft position paper previewed on his blog by BizTalk product manager Scott Woodgate, ESB is an "ambiguous term" for a "transitional technology." Posted on August 1st, these remarks went relatively unnoticed until eWeek's Darryl Taft used them as the basis for a news report last week (it being a quiet week for news).
Taking a stance that Joe McKendrick on his ZDNet SOA blog yesterday characterized as fuzzy but oh-so typical, Woodgate in his blog posting added that Microsoft offers everything you'd want from an ESB and more besides. Considering the views expressed in the white paper, that's about as helpful as saying that Microsoft offers a longer piece of string.
All the same, I am at one with Microsoft in regarding ESB as an imprecise and unhelpful term. I would go further and argue that it's dangerously misleading as a product category, a view that I share in common with Lawrence Wilkes of CBDI. In his commentary last Friday he sets out a number of reasons why ESB is first and foremost an architectural pattern. One that I hadn't seen expressed before but which is a very important consideration is this:
"Donít make the mistake of thinking it is safe to 'standardize' on an ESB product on an internal basis. The whole point of SOA is to provide the agility so that business and IT capability can be bestsourced. What is internal today may be external tomorrow, and vice versa.
"For these reasons," he concludes, "it is better to think of ESB as a service architecture of infrastructure capabilities, and then to consider what products best provide an implementation of each of the infrastructure services required. This may result in the selection of a product (or products) bearing the ESB label, or it may not."
I suspect that more and more decisions are going to go against ESB, and I believe Microsoft's positioning paper highlights one of the most important reasons. CNET's Martin LaMonica did his own reading of the paper and noted in his blog this week how Microsoft is splitting the ESB pattern (or rather what Scott Woodgate would prefer to call Microsoft's "ESB superset") between BizTalk and the Windows Communications Foundation (formerly known as Indigo):
"BizTalk offers process orchestration, document transformation and other higher-level services, while Windows Communication Foundation is the messaging infrastructure and development model to build Web services and move information."
Microsoft isn't the only major player that's splitting the supposed functionality of ESB into two separate tiers, one to deal with messaging and routing and the other to deal with transformation, orchestration and so on. The recently launched Synapse project is another notable adherent of this approach. Microsoft's move is probably the most significant, however, since any organization that aims to standardize on a "one ESB to rule them all" strategy will find WCF a rather inconvenient spannner in the works.
But even more important will be the cost implications of relying on a homogenous ESB stack. I've seen a coupleof articles in the past few days picking up on the emergence of XML networking after Cisco and Intel each made moves into the area (as covered extensively already here on Loosely Coupled Why Intel bought Sarvega, Making sense of AON, AON takes integration to the wire). The closer messaging and routing moves to the wire, the less sense it will make (and the more costly it will become) to keep these communications and mediation functions integrated within a middleware stack. As I predicted some time ago, ESB's days are numbered. The countdown to oblivion has now started.