This link http://www.soaprinciples.com/p16.asp titled "Service-Orientation and the Concept of 'Integration'" is content from Erl's book SOA: Principles of Service Design.
"In the past, integrating something implied connecting two or more applications or programs that may or may not have been compatible. ... The increasing need to hook up disparate pieces of software to establish a reliable level of data exchange is what turned integration into an important, high profile part of the IT industry. ... Services designed to be "intrinsically interoperable" are built with the full awareness that they will need to interact with a potentially large range of service consumers, most of which will be unknown at the time of their initial delivery. ... As a result, the concept of integration begins to fade. Exchanging data between different units of solution logic becomes a natural and secondary design characteristic." I disagree that the conept of integration begins to fade. It's just easier to do. Service clients cannot magically start interacting with providers without any work or effort. It must create the document the service wants, mapping the client data to the document format. It must use a communication channel the service supports. Even if it is just using a tool or running some sort of wizard to make the connection, connecting components is not a zero-effort prospect. The prep work that a typical integration effort had to do, such as doc definition, communication path, etc., are already done--because the service definition *must* consider integration concerns up-front. Whether one realizes or not, when one connects a service client to a service provider integration work is being done. In Erl's words, one is working to "hook up disparate pieces of software to establish a reliable level of data exchange." -Rob
