[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [soa-rm] Comment: Section 2.1.1 Service Composition
Begin forwarded message: > From: Francis McCabe <fgm@fla.fujitsu.com> > Date: May 5, 2005 10:07:55 AM PDT > To: Duane Nickull <dnickull@adobe.com> > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Comment: Section 2.1.1 Service Composition > > > Yes, I think that it is worth including; at least for know. We > might discard it later. > Frank > > On May 5, 2005, at 10:03 AM, Duane Nickull wrote: > > >> 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 >> *********** >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]