I agree with " Integrations have interactions. Interactions are not always within the context of an integration" This means that service interaction is not necessary integration, right? Even more, orchestration is the example of the interaction w/o integration while choreography is the example of very strong integration. (BTW, since choreography violates 2 SO Principles, I think it is suitable for aggregate services only)
Thus, SOA is not about integration but about interaction, IMO, and Mr. Yefim Natis' opinion is incorrect. - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Thursday, December 18, 2008 3:50:57 PM Subject: [service-orientated-architecture] Re: Yefim Natis is sure that ""SOA is integration" Integrations have interactions. Interactions are not always within the context of an integration. IMO, integration is the interaction between components that are in different ownership domains, although this is a somewhat fuzzy view. For example, packaged software is often called an "integrated package" where multiple (optional) modules of various functionality are designed to interact in some way. Thus, even within a single ownership domain, components may be considered to be integrated. My redundancy comment was not intended to address high-availability or failover scenarios. Rather, in some cases duplicate capability in multiple organizational units is not only okay but may be desirable to support specific goals. -Rob --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > What is the difference between integration and interaction? > > Maybe this is the way to finally find if SOA is about integration > or not. When we gather services into the orchestrated process, it > this an integration or interaction? > > I would agree with "integration strategy is a side-effect of > applying SO principles at the enterprise level" after we find the > answer to my question above. > > To the " Side note: Redundancy isn't always bad and eliminating it > isn't always the right course of action. Generally speaking, > eliminating redundancy is good but we must be careful about blindly > following that principle" - I agree with this in the following > interpretation: > - if we deal with technical business services that implement > business functional services (functions, features, processes), > access to particular business service/function/ feature has to be > guaranteed in the terms of the business operating model. To provide > such 'guarantee' we, probably have to have a redundant access to > those business service/function/ feature implementation. It is not > exactly the same as redundant applications that perform the same > things (in different ways) but rather several services that have > capability to support the same business functionality, on demand. > This is the concept; how to implement it - is the art of design. > > - Michael
