On Mon, Jan 5, 2009 at 4:34 PM, Rob Eamon <[email protected]> wrote: > --- 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.
I'm not going to debate this one because I believe it all is covered by my point below about semantics. > > 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?" Again, here I point to the overloaded use of the word integration, which is why finer-grained semantics help to clarify. > > When 2 or more components "interoperate" what should that be called? Fruitoscopy, that's the word I like, but it's not very descriptive (yes, I am in a "fun" mood today) > > Michael contrasted "integration" and "loose-coupling" as apparently > orthogonal notions. Does "integration" imply tight coupling? Integration implies too much (hence the overloaded reference). It implies orchestration, tight-binding, loose-coupling, interfaces, no interfaces, data tables, etc. What it implies is that two or more entities that were not combined are now treated as one. I don't care if Harry Potter comes down and taps his wand to make it happen, integration still occurred. Let's take it out of the technology domain for a minute. Let's talk about desegregation of schools in the US in the '70's. That was called integration. Two segregated schools were integrated to be one school. And, just like in technology, chaos ensued at first, but settled down over time. > > What baggage is "integration" carrying along with it that some feel > it is something to be avoided? Again, to my original point, SOA (when done right) allows for services that are designed incorporated into multiple "ones". That is, each single entity can simultaneously belong to multiple applications (the one) without losing it's own oneness. See my blog entry marriage is an SOA Charlie Brown (http://www.avorcor.com/morgenthal/index.php?entry=entry070317-142858). The point is they are designed from the gitgo to do this, it's not an afterthought. > > -Rob > >
