RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"

["Peter F Brown" <peter@justbrown.net>]

O = Orchestration...
So, the SOA-RM would be Service Orchestration Archicture RM?
>:-)

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: 25 May 2005 18:22
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"

[scroll down please]

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Wednesday, May 25, 2005 2:05 PM
> To: McGregor.Wesley@tbs-sct.gc.ca
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop 
> It!"
> 
> 
> 
> McGregor.Wesley@tbs-sct.gc.ca wrote:
> 
> >Perhaps a new metadata tag such as "aggregation" is more appropriate?
> >
> >  
> >
> Wes:
> 
> Can I ask you what would make a single service care that the consumer 
> is invoking it as part of an orchestration?  Why should the service 
> care.
> It's function is simply to facilitate the invocation request. 
>  If someone created a dependency on the service to know about the 
> state of other service invocation requests, that would be very bad 
> architecture IMO and also violate the principles of autonomicity (not 
> really an English word but you get the idea).
> 
> Individual services MAY have to be architectued to have the specific 
> capabilities required by such infrastructures (example - a two phased 
> commit vs. a single phase) to account for the fact a service request 
> may only be committed if other services are successfully completed.  
> Once again however, I do not see that the service has to know the 
> state of the other service - all such coordination is done as a higher 
> level application.
> 
> I will propose that we accept this axiom:
> 
> "Services should not have to have explicit knowledge of the states of 
> other services called by a consumer that invokes them"
> 
> Does anyone disagree with that?  The idea is that the coordination of 
> states of multiple service calls is coordinated at a higher level.  
> Each service is only the "slave" in a "master - slave" relationship.

Completely agree with this axiom. I also recommend that we explain it in the
terms in your paragraph just above, even mentioning the two-phased commit
notion you describe earlier, and also the "O" word (orchestration). I
believe this will make our points even clearer.

Joe 

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 
> Duane
> 
>