In Dave's latest posting: SOA is architecture with integration (http://weblog.infoworld.com/realworldsoa/archives/2009/01/soa_is_architec.html) he posits that integration is an inherent sub-component of SOA by its nature.
"Second, SOA, while also leveraging integration as a sub-pattern -- and integration is a byproduct of SOA -- is really about architecture, or at least it should be. You get to SOA through integration, or more accurately the loose coupling of systems that create and architecture that's easy to change. You can call this agility, changeability, or whatever, but I call it good architecture. Integration indeed has value, don't get me wrong, but the largest value is the ability to get to an SOA, if you ask me. Or, at least to the SOA that's right for your enterprise. " I commented on his blog as follows: "Perhaps the problem is with the word integration more than with the term SOA in this particular case. Integration is clearly overloaded in this case. By their nature services are designed to be chained together in series to form a flow (we exclude the mega-service concept here which usually indicates poor design, in which one service does everything). I don't believe we should be calling this integration any longer. IMHO, integration is about making two disparate systems participate in a larger systematic effort. If you have SOA, you remove this limitation. Your services are designed to work with each other by nature. Hence, we don't have integration, we have orchestration." I thought it would be interesting to take this debate to this forum where it could be addressed by the larger SOA contingent. I know it's really just all a matter of semantics, because I'm sure there are those among us that would consider orchestration a sub-component of integration. However, for me, the distinction is important because successful SOA should reduce integration requirements and lead to a more interoperable services infrastructure. Thoughts? JP
