|
ESB vs. BizTalk Debate Heats Up in Barcelona
A couple of Microsoft guys walk into a conference session…
by Dave Chappell
November 22, 2005
While giving a presentation at the Enterprise Architect Summit in Barcelona on the subject of ESB and other SOA-related infrastructures (see Resources), I got into a public altercation with a couple of Microsoft guys who were in the audience. It turned into a pretty heated debate over core architectural fundamentals, which we hammered out in front of an audience of about 75 unsuspecting conference-goers. I have to say that in all my years of public speaking, this sort of spontaneous public debate has never happened quite like this. The conversation that ensued brought to light some important issues regarding fundamental differences between the use of an ESB as the foundation of building a service-oriented architecture vs. using a combination of BizTalk and WCF (formerly known as Indigo).
As part of defining your strategy for building and deploying an SOA, you might be considering a variety of SOA infrastructure support products. As an enterprise architect you are probably faced with these various approaches regularly as vendors offer their wares to you, positioning their software as the best choice available for building SOAs. You should consider the key differences in how those SOA infrastructure offerings are architected, and the ramifications associated with how the infrastructure allows you to build and deploy your SOA across an extended enterprise.
The debate arose out of my discussion of the ESB lightweight service container model, and how that compares and contrasts to a hub-and-spoke integration broker architecture. The focus of my presentation turned toward scalability issues. In my discussion I was talking about how an ESB allows for the selective deployment of specific integration functionality as independently scalable mediation services. I used an example of an XSLT-based transformation service, and talked about how an ESB allows an instance of that transformation service to be separately deployed in its own lightweight ESB container.
It's no secret that the parsing and manipulation of XML, including an XSLT-based data transformation, can be an expensive operation in terms of consuming computing resources. Using the ESB distributed container model, multiple instances of a particular transformation can be scaled and load-balanced across multiple containers across multiple machines to be able to support increased demands on the particular transformation as the transformation becomes more complex or the service invocation traffic increases.
I then talked about the contrast of the EAI/Integration broker approach, which typically employs a monolithic architecture that includes data transformation, messaging and connectivity, routing of messages based on business rules or scripting, application adapters, and process control all in one server implementation (an ESB, by the way, also does all these things, but each capability is separated out into its own separately deployable and independently scalable piece).
In order to scale up the XSLT transformation using the monolithic EAI broker approach, you have to install that EAI broker on a really big machine, or if the EAI broker supports the notion of clustering for scalability purposes, you would have to install that entire EAI broker stack across multiple machines. Keep in mind that we are simply trying to support the scaling up of the one XSLT transform that sits between two popular applications! All the while that transformation will still be trying to compete for computing resources with all the other things the EAI broker is trying to do—business rules, process control, execution of other services, application adapters, and so on.
OK, I started this writeup by saying it was about an altercation with a couple of Microsoft guys…
I then said something like, "…even BizTalk and Indigo (WCF) with all of its fanfare still suffers from this problem! Indigo provides a nice Web services–enabled messaging bus, but when you're doing the rest of the integration piece you need BizTalk, and you can't selectively deploy and independently scale individual integration components within BizTalk…" I was pretty fired up when I said it too.
I knew there were two Microsoft guys in the room—I was talking to them earlier that day. I didn't mean to pick on BizTalk per se. I was just using that as an example—this same situation exists with any SOA infrastructure that relies on an EAI broker architecture: TIBCO BusinessWorks, webMethods Integration Server, and so on. Sometimes I pick on them too.
Just then, Jeromy Carrière, senior technical evangelist for Microsoft, interrupted and said, "Excuse me, I hate to interrupt your talk, but actually you can do that. You can actually selectively deploy individual components in a BizTalk server." Then the other Microsoft guy, Arvindra Sehmi, lead architect of the EMEA Developer and Platform Evangelism Group, also chimed in and spoke of a couple document numbers and indicated that they were how-to documents. Then he said, "Well, it's your talk. You can say what you want up there…we'll take this off line. Please continue." So, he was basically saying that I was full of crap, but that's allowed because I had the floor. I wasn't happy with that situation so I decided to stop the rest of my presentation and debate the issue right then and there in front of the rest of audience.
Back to top
|