The reason of these two words used is in that some people strictly follow UML definition of 'composition'. In UML, when composition ends it life, all included components do the same, i.e. they do not exist outside of the composition. In the UML aggregation, components of the aggregation have thir own life-cycles independent from the aggregation. Saying so, the final result of aggregation and composition is the same.
- Michael ________________________________ From: Ashley at Metamaxim <[email protected]> To: [email protected] Sent: Tuesday, December 23, 2008 11:42:28 PM Subject: [service-orientated-architecture] composite vs. aggregate Hi There is talk here of "aggregate services" and "composite services". Are they the same thing or different? Thanks Ashley Michael Poulin wrote: > Absolutely agree, Harm. > > However, we are talking about integration capabilities of the service > itself. The nature of an aggregate service suggests integration in the > service implementation with engaged services. This is why an aggregate > service can participate in the choreography while atomic service cannot. > > Consumer does not distinguish between aggregate and atomic services. > This created additional challenge for the atomic service in the > Service Description document because such service > becomes responsible to the consumer for all business functionality and > RWE of engaged services while they are not under the control of > the aggregate service (and may belong to different ownership realms). > > Actually, the ownership and accountability of the service provider is > an interesting topic in the context of integration. But it is not > about Yefim's statement and may deserve another thread. > > - Michael > > ------------------------------------------------------------------------ > *From:* Harm Smit <[email protected]> > *To:* [email protected] > *Sent:* Tuesday, December 23, 2008 10:42:05 AM > *Subject:* RE: [service-orientated-architecture] Re: Yefim Natis is > sure that "SOA is integration" > > "In contrast, an aggregate service – does.” > > > > Why? > > IMO, a composite service made up from atomic services should itself be > perceived from the outside world as a self-contained service and it > should not need any services other than those used for its composition > to provide its RWE. As seen from the outside world, there is no > distinction between an atomic and a composite service and, since a > service hides its implementation, the outside world should be unaware > of how a composite service orchestrates its subordinate atomic > services (or other composite services, for that matter). > > > > Harm. > > > > ------------------------------------------------------------------------ > > *De :* service-orientated- architecture@ yahoogroups. com [mailto: > service-orientated- architecture@ yahoogroups. com ] *De la part de* > Michael Poulin > *Envoyé :* mardi 23 décembre 2008 10:50 > *À :* service-orientated- architecture@ yahoogroups. com > *Objet :* Re: [service-orientated -architecture] Re: Yefim Natis is > sure that "SOA is integration" > > > > Here is a misunderstanding, Rob. Certainly, to run, a service needs an > external call. However, self-contained atomic SOA business service > does not need any other business services to provide its RWE; it does > not know about outside world of services. In contrast, an aggregate > service – does. > > - Michael > > > > ------------------------------------------------------------------------ > > *From:* Rob Eamon <rea...@cableone. net> > *To:* service-orientated- architecture@ yahoogroups. com > *Sent:* Tuesday, December 23, 2008 4:01:52 AM > *Subject:* [service-orientated -architecture] Re: Yefim Natis is sure > that "SOA is integration" > > --- In service-orientated- architecture@ yahoogroups. com > <mailto:service-orientated-architecture%40yahoogroups.com>, Michael > Poulin <m3pou...@.. .> wrote: > > > > Integration with what? > > > > Assume, we have a self-contained atomic SOA business service. It > > does not need anything outside its boundaries to perform announced > > business functionality and provide for the RWE. > > Oh yes it does. A service all by itself does nothing. Without some > external stimulus, it does nothing at all. > > Something outside of the service must call it via one of the exposed > interfaces or the service will do nothing whatsoever. > > > Certainly, it has to run in an execution environment and it > > integrates with it. However, it does not integrate with an > > orchestration or a process that uses it because it perfectly > > functions alone. > > The orchestration or process integrates with the service by > connecting to and invoking one of the service's exposed interfaces. > > > Invocation of such service does not generate any new business value. > > Invocation of a service is required to generate any busines value. A > service uninvoked is a useless pile of bits. > > > As I responded to Rob, if a SOA service does not have an interface > > for particular type of communication channel, does it " have > > intrinsic seamless integration capabilities" ? > > No. But then how did the architect miss that channel? But for the > channels/interfaces that are not missing, the system has intrinsic > integration capabilities. > > > So, integration is just a link system between participants (may be > > one link for 2 participants) . Connecting those participants we do > > not create a SOA system, or we do? > > Connecting participants creates an integration. Creating an "SOA > system" (a term I loathe) requires creating service providers with > separately standing interfaces that are invoked within an execution > context by service consumers. Consumers integrate with providers via > the agreed upon interfaces. > > -Rob > > > > > ------------------------------------ Yahoo! Groups Links
