SOA, Web Services and hard-coded XML strings

The "Does SOA = Web Services" discussion has kicked off again.

Joe McKendrick has an interesting posting about the role of Web Services in Service Oriented Architectures. He links to Amir Shevat's piece on whether SOA and Services are synonymous. Amir has correctly observed that synchronous request-reply (in the form of SOAP over HTTP, say) is not always the best choice. Indeed, they seem to be in broad agreement that, as an architectural approach, SOA is entirely independent of invocation mechanism. However, Joe counsels that we shouldn't take this too far: you can build an SOA with other technologies (even home grown ones), but why take the effort when there are all these lovely industry-proven specs available?

I have sympathy with this opinion but we need to be clear when we're talking about these kinds of issues.

No client I have ever visited has been building their SOA in a vacuum. They have existing systems - on more platforms than one could possibly imagine - and usually have some integration solutions in production already. You can be pretty sure any serious SAP shop will be firing IDOCS left, right and centre between their machines, for example. There's likely to be some JMS (most likely MQ) in there and they may have a bunch of web services. Those web services, incidentally, will be on a variety of platforms and some will be home grown. Some will be from the early-adopter days and not conform to any known WS-* spec. You can also be sure that there's no way they're going to change them :-)

So, what's the answer in these real-world situations?

My view is that these problems become soluble when we intermediate the service requester and the service provider. The architectural construct used here is increasingly known as the Enterprise Service Bus (ESB) and I wrote about how I thought it fitted here briefly in November.

The inclusion of a conceptual ESB makes the solution clear: existing systems can continue to run unchanged. They can expose the services they offer in whatever way makes most sense to them. On the invocation side, however, you should consider mandating a standard. This could be MQ, JMS, SOAP over HTTP, whatever (perhaps a choice depending on context). The point is that we provide a simple, standards-based way for new applications to invoke existing services. The ESB is the facade that takes these requests and forwards them to the appropriate provider.... making any necessary conversions along the way.

The ESB can be as heavy-weight or as light-weight as you like or as you need. In some cases, you may have no specific implementation at all - it will simply be a guiding architectural principle. The point is that in the real world of existing systems, something like an ESB allows you to build up the ESB without having to tear down all the work you've already done and allows you to square the "SOA must be Web Services" argument with the "We're not going to redo everything!" camp.

[Update 2006-01-12: Ronan Bradley has also spotted Amir's article and writes about it here. He has also spotted that it is making an argument for an ESB]