This quote at the introduction:
People sometimes ask what a service-oriented architecture enables today that could not have been done with the older, proprietary integration stacks of the past 5 to 15 years, such as those from Tibco, IBM, or Vitria. One such ability is the greater degree of interoperability between heterogeneous technology stacks that is made possible by the standards SOA is built on, such as Web services and BPEL. Although interoperability is only one facet of the SOA value proposition, it is one that has become increasingly more important, due in large part to the evolving IT environment, merger and acquisition activity, and increased partner connectivity.
It becomes more understandable once you read who the authors are. They of course work for Oracle and a Microsoft Partner who are really promoting a product suite. The problem with this quote of course is it is simply not true or at the very least misleading. I don't think most folks bought Tibco, Vitria, IBM, webMethods, SeeBeyond etc to integrate technology stacks like Java and .Net. They bought these EAI platforms to integrate multiple proprietary software packages. Lets say SAP, Oracle, PeopleSoft, Remedy, Mainframes, Java, .Net, EDI (Trading Partners)and the list goes on and on.
Those integration needs are still there. Some vendors like SAP, Oracle and Peoplesoft are evolving their offerings to include Web Services. But for the other million package applications out there, integration is an issue. Web Services doesn't solve the problem of legacy integration. Even for companies moving towards a SOA style of architecture, legacy integration is still an issue. The "private side" of a service still has to communicate/work with legacy packages in a lot of cases. I do think the concept of creating service wrappers around these legacy integrations is a good idea. However you should not think by using Web Services that you somehow don't have to deal with this issue. By the way all of the platforms referenced in the quote offer the same functionality that the vendors in the article are touting.
The other issue I had with the article is the concept of asynchronous processing. But I'm going to leave that for a future discussion.