--- In [email protected], Michael Poulin <m3pou...@...> wrote: > > 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.
What things will an architect do differently? * Define components of the architecture (some will be services) * Define the relationships and interactions between those components (integration, though it might seem like some other activity) If 2 services are to interact, that interaction will constitute an integration 99% of the time, IMO. > 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). Two services within an SOA design interacting via web services (or via any other mechanism) is 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. They may forget they are doing integration, but that is what they are doing. What are the steps needed for 2 services, that never before interacted, to start interacting? What are the steps that an orchestration must take to start using services? Those steps are integration. > As of choreography (as it is defined in current standard), it > violates principles of Loose-Coupling and Atomicy. Loose-coupling != no coupling. Minimize coupling for the given situation. Some coupling is *always* necessary whenever two components interact. Services participating in choreography may still be considered "real" services in an architecture definition--they may just be more constrained (by state) than others. I'm trying to recall--is "stateless" a *must* for SO or just preferred? > 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 I'd offer they are constrained by state requirements (entry and exit conditions that must be satisfied), not by coupling with other participants (and certainly not *all* others). And there are ways to make the "who's next" call configurable or run-time dynamic (rules engine, for example). > 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. Which is to say, turn an aggregate into an orchestrator? (If I understand the orchestration vs. choreography correctly.) > P.S. In orchestration, services do not integrate with each other, > they collaborate via the orchestration manager. Right. They are integrated with the orchestrator. > In choreography, services integrate. Understood. Increasing the coupling, which may be perfectly legitimate (and would not necessarily render the design "non-SOA" IMO). > If I integrate 2 apps with a Web Service type message exchange, > none of them constitute a service. That depends on the nature of the capability exposed by the apps. An app can certainly be the implementation environment of a "real" service. But I think your point is that simply tying 2 apps together via web services doesn't necessarily create a "service", which I agree with. I think we may be more in agreement than what it seems. IMO, integration is a core part of SO principles and approaches--but one shouldn't focus primarily nor solely on that. -Rob
