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




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.

Duane



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