Strongly disagree - an architect can and will do quite different things and we will never get the agreement of what should be done because integration and interaction have significantly different capabilities. One will say that SOA failing because promises based on interactions never realise when doing integration. I am trying to separate integration via Web Services from business efficiency encapsulated in the service orientation (which is questionable for the sphere of integration).
I see more and more evidences now of the organisations start forgetting about the integration and more interested in the business capabilities of SOA. "SOA is integration" is the call for retreat. As of choreography (as it is defined in current standard), it violates principles of Loose-Coupling and Atomicy. Atomic service cannot participate in the choreography becuase that may not know anything about other services (they are self-contained) and they do not need any other services to perform their business tasks/functionality. Services participating in the choreography are coupled with all other participants and this is true for every choreography the service participates. So, only aggregate services that depend on other services by definition are suitable for the choreography. I see that one of my last messages, where I responded to ynatis, has lost. If you look into it, you can find that Yefim's now saying that "SOA is not integration"... Take it or leave it. He also promotes 3T architecture as a service model and states that "Most modules in business applications should not be Services". It is not clear - this is his personal opinion or it is the Gartner's position. - Michael P.S. In orchestration, services do not integrate with each other, they collaborate via the orchestration manager. In choreography, services integrate. If I integrate 2 apps with a Web Service type message exchange, none of them constitute a service. ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Saturday, December 20, 2008 8:58:20 PM Subject: [service-orientated-architecture] Re: Yefim Natis is sure that ""SOA is integration" I'd argue that most services are more or less independent. And are likely in various ownership domains. IMO, *most* (if not close to all) service interactions are an example of integration. IMO, orchestration and choreography are both types of full-blown integration. SOA is fundamentally about structuring capability such that it can be used by other components. That, at its roots, is integration. But instead of us endlessly debating "it is about integration" vs. "it isn't about integration" let's ask this question--what are the real impacts if it is one or the other? What will an architect do differently if SOA "is" integration vs. if SOA "isn't" integration? IMO, nothing. The integration (or interaction if you prefer) aspect, which is embodied by exposed, documented interfaces, is present simply by following SO principles. I recall there was some significant discussion about choreography vs. orchestration but I didn't pay close attention. Can you list the 2 SO principles that choreography violates? By "suitable for aggregate services only" do you mean suitable for service implementation? -Rob --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > 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
