Even Thomas Erl has not convinced me because we are approaching from different perspectives. I think that intention, need, interaction and integration are all about different things.
A bus may have a special door dedicated to very big people (nothing offensive, I hope). Why? Because a need for such door is assumed based on practice. Then, why a person becomes a passenger of a bus? Because a person has need for a ride. Will such person have an intent to take a bus? It depends - if the person is big and it is known the bus does not have appropriate door, there may be no intent. Presence of special door is not a fact of integration between a big person and a bus, it is a response to potential needs and support for an intention aimed to potential interaction (during the ride). There is no integration. If I model described business situation with services, I also will have a consumer intent, service capabilities and potential interactions. OASIS SOA RA articulates this much better than me here. "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", yes, and somebody is doing this 'hook up'. Why? Because none of the pieces cannot do it by themselves. Now, assume a Piece 1 with reserved publicly available hook (interfaces) and a Piece 2 - a smart distributed SW agent, which is looking for available hooks of others to connect its own hook with them. There is no a 3rd Party for doing hooking (I mean, no hookers :-), there is no adjustments on any Pieces, and the only shared thing is the execution environment. If the fact of interaction is equal to integration, then we can say that the Pieces are disintegrated after the interaction complete. How close this conclusion to absurd? - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Monday, March 23, 2009 3:48:11 PM Subject: [service-orientated-architecture] Re: Misperceptions about integration and SOA --- In service-orientated- architecture@ yahoogroups. com, 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
