--- In [email protected], "JP Morgenthal" <jpmorgent...@...> wrote: > > > 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."
Let's explore that in a bit more detail. How does getting component A to interact with component B differ in the "integration" approach vs. the "orchestration" approach? Does "integration" imply additional work, always? When it is determined that client A must interact with service B, what are the steps involved to get them to do so? How would we characterize: * A and B already understand the messages to be exchanged. And the communication path. A just needs to connect to B. * B exposes several interfaces but A understands none of them. A is able to use the interface communication path exposed by B. * B exposes a particular interface but it is not enough for what A needs. It is determined that the additional capability/data is within the domain of the service offered by B. * A understands neither the messages nor the communication path exposed by B. * Neither the messages nor the commuication path are understood by A or B. In getting A to interact with B, which scenarios above would be considered as needing "integration?" Which would be "orchestration?" > 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. Semantic clarity is very important! What exactly are "integration requirements?" When 2 or more components "interoperate" what should that be called? Michael contrasted "integration" and "loose-coupling" as apparently orthogonal notions. Does "integration" imply tight coupling? What baggage is "integration" carrying along with it that some feel it is something to be avoided? -Rob
