"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 : [email protected]
[mailto:[email protected]] De la part de
Michael Poulin
Envoyé : mardi 23 décembre 2008 10:50
À : [email protected]
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 <[email protected]>
To: [email protected]
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-
<mailto:service-orientated-architecture%40yahoogroups.com>  architecture@
yahoogroups. 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

 

 

Reply via email to