If I am using a car, bus, or train, I do interact with them but I do not integrate with them.
For an extreme example, I can broadcast (via Topic) a message via MOM somewhere in China but write the content of the message in Russian or English. Do I integrate with the receiver of the message if I do not preliminary agree with the message receiver on the message content format and semantics? I do not think so; I may have a fact of interaction w/o integration. - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Saturday, March 21, 2009 3:09:05 PM Subject: [service-orientated-architecture] Re: Misperceptions about integration and SOA Who mentioned the use of a bus? Client A directly interacting with Provider B is still integration, bus or not. -Rob --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > Good points, Rob. However, I still cannot equal 'my use of a bus from point A > to point B' with 'my integration with a bus'... > - Michael > > > > > ____________ _________ _________ __ > From: Rob Eamon <rea...@...> > To: service-orientated- architecture@ yahoogroups. com > Sent: Thursday, March 19, 2009 4:16:39 PM > Subject: [service-orientated -architecture] Misperceptions about integration > and SOA > > > This link http://www.soaprinciples.com/p16.asp titled "Service-Orientatio n > and the Concept of 'Integration' " is content from Erl's book SOA: Principles > of Service Design. > > "In the past, 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. > ... > Services designed to be "intrinsically interoperable" are built with the full > awareness that they will need to interact with a potentially large range of > service consumers, most of which will be unknown at the time of their initial > delivery. > ... > 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. " > > I disagree that the conept of integration begins to fade. It's just easier to > do. > > Service clients cannot magically start interacting with providers without any > work or effort. It must create the document the service wants, mapping the > client data to the document format. It must use a communication channel the > service supports. Even if it is just using a tool or running some sort of > wizard to make the connection, connecting components is not a zero-effort > prospect. > > The prep work that a typical integration effort had to do, such as doc > definition, communication path, etc., are already done--because the service > definition *must* consider integration concerns up-front. > > Whether one realizes or not, when one connects a service client to a service > provider integration work is being done. In Erl's words, one is working to > "hook up disparate pieces of software to establish a reliable level of data > exchange." > > -Rob >
