WS-* vs. Enterprise Service Bus (ESB)

Tomas Restrepo calls out Richard Turner for not being very pragmatic. Richard outlines his opposition to building a communications “bus” for the enterprise in the hope that it solves all the integration needs of the business. Instead Richard is relying on WS-* to deliver the necessary interop. Tomas says:

_My humble opinion on the matter (not being an expert on either ESBs nor WS-*) is that Richard's comment is, well, not very pragmatic and overly optimistic, at best. In theory, I'd agree 100%, it certainly sounds like a very compelling vision of the future. In practice, however, I can't see how this would ever be a reality._

To the contrary, this comment actually describes my opinion of the Enterprise Service Bus (ESB) approach. You see, for the last few years the ESB proponents have been offering essentially the same vision under various different guises. They say that your current systems that look something like this…

…can be changed, if you spend enough money on their particular middleware/server/ESB/whatever infrastructure, into something that looks like this…

Much neater. And here’s where I would choose to apply Tomas’quote: “In theory, I’d agree 100%, it certainly sounds like a very compelling vision of the future. In practice, however, I can’t see how this would ever be a reality.” The problem is that a radical enterprise wide overhaul of systems to make them fit into this pattern is just too hard to achieve.

Where I agree with Tomas is that BizTalk Server provides an excellent platform for integrating enterprise applications. It really is a fantastic way to bring disparate systems together and makes it easy to place a service oriented interface around existing applications. In fact, Microsoft could promote BizTalk as the solution for how to provide an ESB using the Windows platform. I think, though, that this would be a mistake.

The pragmatic approach I promote is to use BizTalk where necessary to integrate applications into islands of functionality. It may be useful to build a solution around two or three existing business applications and to expose this collectively as a service to the rest of the enterprise. In other areas, new systems will be built as native services and will participate in service oriented applications directly. Rather than seeing the enterprise built upon a common service “bus”, consider an enterprise wide directory enumerating the disparate services made available within the organisation. UDDI fulfils this role and allows services to be catalogued and searched. This way, if your organisation already has a zip code or postal code look-up service, or a payment gateway service, or an invoicing service, or a credit checking service, or whatever you need, then you can reuse an existing service if it provides the functionality you need. Alternatively, you might be able to extend an existing service if it doesn’t provide everything. This is how I see the value and promise of service orientation being delivered and it doesn’t require a centralised message “bus”.

We’ve come so far with web services in the last three or four years and the future promises to move just as quickly. I respect the doubts that Tomas has about whether we will arrive at a compatible WS-* world. I certainly share some of those concerns as the complexity level of the web service protocols increases. I remain positive, though, that the goal of greater interop is one that we will continue to be pursue. For the places where we need localised integration, tools like BizTalk will deliver that functionality without demanding enterprise wide agreement. More broadly, integrating business services either through BizTalk or simply in application code will be the best way forward.