Its kind of interesting. Just scanning through a few articles and blog posts trying to jam as much into my head it would seem standalone BizTalk doesn’t fit the text book definition of an ESB. In some ways BizTalk Server delivers a superset of ESB.
It would seem an ESB is primarily message routing and transformation sevices, that’s the only commonality I can draw from the various definitions I’ve read. An ESB will let us package up a service and run it anywhere in our infrastructure. Based on routing rules messges will be directed straight to those services. The neat thing is we can scale those services independantly of the rest of the ESB. That equals low cost.
There’s a bit of contention around the level at which you can break down BizTalk services and deploy them independantly. At a high level BizTalk Server can be viewed as having two cores, messaging services and workflow services. Its a valid deployment scenario to run a group of BizTalk Servers as receiving servers, a group of servers as processing servers, and yet another group as sending servers. But still this is nowhere near granular enough to be a true ESB. By that I mean to set up receiving servers you more or less have to install all of BizTalk with its associated bloatware. Scaling the receiving servers would then be expensive as we’re having to pay for an entire BizTalk licence.
Hmmm, so what does the web services stack do for us? i.e. It would be pretty stupid to run our integration partners web services on our BizTalk Servers. The most likely place for these to run is on an enterprise web server farm that can be cheaply scaled. All the routing bits of a BizTalk ESB are contained on the BizTalk processing servers via port bindings and message subscriptions. So is it that with both BizTalk Server and the web services stack we can deliver a true ESB.
I mean what would we really want to pull out and scale seperately in an ESB. The transformation services. When delivering an ESB shouldn’t the first step be to develop a canonical model. This means that any transformation of significance should be getting done at the endpoints living on those nice cheap scalable web servers. Doesn’t WCF give us a nice transformation layer to do just this? So exploiting the content based routing features of our BizTalk Server farm and the web services stack we should be able to get pretty close to the definition of ESB whilst having all the features of a true integration platform, in theory anyhow. Of course in practice we will have to deal with legacy services that don’t conform to the canonical model. So it would be a matter of doing the transformation for these services on the BizTalk Sever or wrapping a simple fascade around legacy services. I know which one I’d choose.