Re: [soa-rm] Comment: Section 2.1.1 Service Composition

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Autonomy is inherently a relative concept -- one is autonomous from  
control by something.

Having said that, there is a sense in which people intuit autonomy in  
SOA-style systems: the provider of a service and the consumer of a  
service may belong in different ownership domains; and, as such, have  
certain *freedoms* that do not normally apply to C++ code: the  
provider can refuse to offer service (like the notices you  
occasionally see in restaurants:)
and the user of a service can similarly bail out. It makes sense to  
design systems with this constraint in mind if you wish to provide  
reliability in your services *and* in your 'client' code.

I.e., the autonomy constraint for service participants leads to a  
reliability benefit in SOA architectures.

Frank

On May 5, 2005, at 7:00 AM, Duane Nickull wrote:

> Joseph:
>
> This is actually a really hot topic in many camps right now.   
> Before I get into that however, I also am somewhat inclined that we  
> might drop this altogether from the RM, but would like to hear how  
> other folks feel.
>
> There are two camps of service management - one is that the service  
> consumer manages services while the other PoV is that services are  
> fully autonomous.  If a service is being told to do things for  
> multiple consumers, it may eventually become squeezed for internal  
> resources.  If a service has been "leased" by too many providers,  
> it may need to cancel some of the leases to free up resources to  
> fulfill obligations for other consumers.
>
> The alternative to this is that the service cannot prematurely  
> expire a lease and must perform its obligations.  This is not  
> optimal IMO.
>
> Service autononimity (spelling?? Is even a word??) is the concept  
> of who is the master, who is the slave.
>
> This is a basic premise behind some web service architectures.  Is  
> it relevant for the RM?
>
> Duane
>
> Chiusano Joseph wrote:
>
>
>> [Please note that the format below is not the official format for  
>> us to use for comments - that is still pending. I wanted to send  
>> this out while it was fresh on my mind.]
>>  SECTION: 2.1.1 Service Composition
>> LINE: 193
>> TEXT: "The functionality described above is mandatory to comply  
>> with the notion of service autonomy. A service alone must  
>> determine whether an invocation request succeeds or fails."
>> COMMENT: Recommend more clarity on the second sentence above. If a  
>> service wouldn't determine whether an invocation request succeeds  
>> or fails, what would determine it? IOW, why is it necessary to  
>> state this (what verification are we trying to provide to the  
>> reader)?
>>  Kind Regards,
>> Joseph Chiusano
>> Booz Allen Hamilton
>> Visit us online@ http://www.boozallen.com <http://www.boozallen.com/>
>>
>>
>
>
> -- 
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. - http:// 
> www.adobe.com
> Chair - OASIS Service Oriented Architecture Reference Model  
> Technical Committee - http://www.oasis-open.org/committees/ 
> tc_home.php?wg_abbrev=soa-rm
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources  - http://www.adobe.com/ 
> enterprise/developer/main.html
> ***********
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFCekbNdvrlFWWPLfkRAoGaAKCP+MsP7GsP1rJTvGcAcYaUlK8GFgCdEgwo
pAVrhCLCPj8faV1hsOdE4yU=
=UmB1
-----END PGP SIGNATURE-----