--- In [email protected], Michael Poulin 
<m3pou...@...> wrote:
>
> If two people listen a radio broadcast, would it be right to say 
> that they are integrated via the same language ? I think, it is too 
> much. Plus, they, probably, understand different things from the 
> broadcast depending on the 'context' of their minds.

Two subscribers listening to a publisher are not integrated with each 
other--they are integrated with the publisher. 

They must have the same understanding of the message and the context of the 
publisher else they may not perform as desired.

> I do not understand why we have to go that deeply 
> into 'integration'... Integration and Usage make more sense to me 
> than just Degrees of Integration. 

I'm not claiming there are degrees of integration. Rather, there are degrees of 
coupling.

Why you and I are diving into it is because we disagree on what constitutes 
integration.

My contention is that the work to connect consumer and provider, however 
trivial, is integration and results in the consumer and provider being 
integrated (with varying degrees of coupling). Consumers and providers don't 
just magically start interacting. There is work to define and implement the 
agreed upon interaction on both ends. 

Your contention is that they are simply interacting. That the work done to 
facilitate that interaction is not integration but something else.

I have been thus far unable to convince you that the work done to connect 
consumer and provider is the same as is done in classic integration efforts. 

I'll try to make my case in another way.

>From Erl: "...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."

Would you agree that consumers and providers are "disparate pieces of 
software?" That they are independent components possibly (likely) from 
different ownership domains? That integration is the act of connecting two or 
more such items? That integration is equivalent to "hook up" these things?

Erl: "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."

Perhaps the Erl's intent here is "...the concept of integration begins to fade" 
*from the limelight.* Or from the center of focus.

The concept of integration remains the same, but it is less important though it 
is still there. It becomes a secondary concern because the SO principles and 
the actions of defining a service address many integration aspects as a matter 
of course. Defining a service interface is effectively integration work. The 
provider *must* anticipate integration needs up front (at least some of them) 
rather than solely on an ad hoc basis.

-Rob


Reply via email to