> I don't agree with the interaction versus integration argument. > If there's no way to interact with a system, it can't be > integrated.
Sure. What you are really disagree with? We may have to accessible systems, i.e. they have interfaces for interactions but they do not have means to talk to each other. This is the case of integration, i.e. where somebody comes and "holds the talking". Does it change system's disability to interact? Of cause, not. Both of them interact with the Holder, not with each other. In other words, interaction (for clarity) is explicit communication while integration is implicit interaction. To Rob, we do not need anybody to INTEGRATE two systems which can interact directly, do we? - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, July 2, 2008 5:37:33 PM Subject: [service-orientated-architecture] Re: Legacy into SOA (was Vandersluis on a Data Abstraction Layer's Benefits) +1 -Rob --- In service-orientated- architecture@ yahoogroups. com, Todd Biske <todd.biske@ ...> wrote: > > First, I personally think the whole m^n complexity thing is a bit > of FUD. Yes, you can create a big, ugly spaghetti bowl and many > have. It remains true, however, that there is still a need for m > systems/integration points to communicate with n > systems/integration points. We need to manage those relationships, > and strive to eliminate redundancy across m and n. > > I don't agree with the interaction versus integration argument. > If there's no way to interact with a system, it can't be > integrated. Now, the interaction may not be easy, but it's still > available. > > Typically, I see the term integration used when it's an > interaction that crosses a control boundary. The system I need to > talk to is under someone's else's control (different team, vendor, > etc.). That sounds very much the relationship between a service > consumer and a service provider, to me. > > A change that needs to occur is that designing for integration > needs to be a primary goal, rather than an after-the-fact goal. > There's no reason that any solution should go live today without > documented integration points (events, service interfaces). They > also shouldn't go live without proper instrumentation and metric > collection (separate soap box item on my mind). Yet this happens > probably every single day in corporate IT departments around the > globe. > > -tb
