Following up on the disruptive abilities of web services a brief recap of what the disruption is all about. It can be paraphrased like this "Web services are unix-style 'simple tools' for business processes"

The "simple tools" philosophy of the unix system environment is the style of development that carefully avoids to build monolithic systems to solve specific tasks, but rather solve all problems by ad-hoc assembly of a long list of simple tools that "do one thing well" through the shared metaphors of the unix shell, files and pipes. The simple tools philosphy is in contrast to the idea of the 'Integrated Environment' - invariably huge, comparatively closed, 'total' systems with an answer for everything. While there are many good reasons to work inside huge monolithic apps (the "simple tools" style has never been able to make sense of GUI's for instance) the simple tools philosphy is remarkably powerful for many problems, as anyone who knows the awesome power of the command line will gladly confirm.
The portability and end user simplicity of (good) open source build processes are evidence of the remarkable power of the simple tools philosophy.
The economics of simple tools comes from the network effect of integration. The total value of 'grep' comes about as a sum of (part of) the value of all the simple toolchains 'grep' is used in.

The way this particular webservice pitch goes traditional business software is entirely about expensive, closed source, monolithic, hard to integrate apps. The value of their constituent parts comes about as a fraction of the single toolchain (the monolithic app) they appear in.
Web services are to these apps as simple tools are to complex IDE's.

The latest buzzword that attempts to do for web services what the shared metaphors of the unix environment (files, pipes, processes) do for the simple tools is the Enterprise Service Bus.

Or we can just let Jon Udell explain the whole thing: The ESB, the quintessential simple tool in this context - the Active Intermediary, and finally let him wrap up with a toy example of what this kind of open, ad-hoc, transparent integration can do.

The essential concept for the simple tools is that each tool along the chain is really transparent to the next tool. Only the data in the pipe matters. That is why web services need to focus not on API's and programming interfaces but on data representation API's. And this is why SOAP is already under fire from REST interfaces. In SOAP the data interface is tied into the API, the action interface and that's just not very transparent. Hmm, I think I just started another very lengthy post by accident.