OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]