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

[Duane Nickull <dnickull@adobe.com>]

Frank:

Thank you.  I concur.

Based on what we know - do you (and others) think the concept is worth 
mentioning in the RM as an aspect of services?  Do it add anything  to 
the RM by being mentioned or do we miss anything by it not being there?

Duane

Frank McCabe wrote:

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


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