At last, Microsoft talks up 'ESB'

It seemed that to Microsoft, "enterprise service buses" were those vehicles that transported people around the Redmond campus.

Now, it appears Microsoft is pushing the role of ESBs a little harder as part of its emerging go-to-market SOA strategy. It's even actively using the term 'ESB.'  Earlier this month, the software giant announced that it is working with consulting partner Neudesic to promote the deployment of ESBs in customer's software stacks. Why hasn't Microsoft's latest ESB announcement received the same press as those from IBM or BEA?

Microsoft's ESB strategy began to come into focus last year around this time, when the computer giant released a position paper that indicated that it was positioning its BizTalk Server integration and process server and Windows Communication Foundation as its defacto ESB solution. 

Microsoft said it wouldn’t treat ESB as a standalone product, but "customers looking to purchase an ESB will find that Microsoft offers a significant superset of ESB functionality," according to the position paper. Scott Woodgate, group product manager in the Connected Systems Division at Microsoft and a co-author of the position paper, said that "We don’t believe that customers will benefit significantly from the ESB products." Microsoft believes the ESB concept is too ambiguous. Instead, "BizTalk Server 2004 enables decoupled integration with a range of systems, including MQSeries, SAP systems, and Web services… BizTalk Server provides for all the capabilities of traditional ESBs," Microsoft said in its paper.

But the industry seems to have greeted the news with a collective shrug. Is it because we've already been inundated with every vendor announcing ESBs? And, now, enterprises have the challenge of figuring out how to piece all these different vendors' buses together? Or even if they need an ESB?

Ronan Bradley looked at Microsoft's most recent ESB announcements, and wonders out loud why the announcement "doesn’t seem to be getting a lot of coverage, unlike IBM’s and BEA’s recent SOA announcements."

The big news, Ronan says, is that unlike the other vendors, Microsoft appears to be getting it right, in that its ESB would play different roles in different enterprises, even sitting alongside IBM WebSphere-MQ. "Microsoft, unlike some of the other major players, seems to understand that SOA requires a different view not only of architecture but also about middleware. In particular, the 'one stack to rule them all' doesn’t hold water. There will almost always be a need to implement your SOA across multiple infrastructures." 

Ronan also observed that he "can see little benefit for customers from replacement of deployed queuing systems, BI systems or anything else that works just to get the benefits of a single vendor/stack solution when there is no reason the ESB can’t sit along side these."

How important or relevant is having an ESB, or federated series of ESBs, to SOA? At the same site as Ronan's post, Illuminatus Research's Steve Craggs also talked about the continuing confusion between SOAs and ESBs. "I often meet people who think that an ESB is required in order to build an SOA. This is, of course, a load of rubbish - companies have been deploying SOAs from long before the ESB came to market. Others think that once they have implemented an ESB then they have an SOA. Once again, this is completely incorrect - a service-oriented architecture is about a lot more than just a messaging bus with a bit of mediation."