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

[Mark Little <mark.little@arjuna.com>]

I'd also add the context (and WS-Context as a specification) is 
incredibly important in service composition. However, it's more 
fundamental to any SO architecture.

Mark.


Chiusano Joseph wrote:

> Thanks for your insight Duane. It seems to me that we have something 
> tangible to point to regarding this issue, that may help make the 
> point even more concrete: Orchestration and Choreography (I hope my 
> understanding of your explanation below - which helped me make this 
> link - is correct).
>  
> With Orchestration some relevant specifications/in-process standards are:
>  
> - WS BPEL 
> - WS-AtomicTransaction (NOTE: This is a specification that is really a 
> "helper" to Orchestration in that it provides capabilities that are 
> needed by Orchestration)
> - WS-BusinessActivity (same explanation as with WS-AtomicTransaction)
> - WS-Coordination (same explanation as with WS-AtomicTransaction)
> - WS-CAF (also an Orchestration "helper")
>  
> For Choreography, we have W3C WS-Choreography.
>  
> The major distinction between these 2 camps is that Orchestration is a 
> run-time concept, and it implies a single "conductor" (hence the term 
> "Orchestration") in charge - that is, a single process (represented as 
> a service) exists with which multiple other processes/services 
> register as part of the same single activity - for example, an 
> activity involving a single purchase order whereby all processes are 
> "associated" with a single purchase order ID.
>  
> Choreography, however, is a design-time concept, and it also does not 
> imply a single process/service in charge. It involves creation of a 
> "script" (choreography) that is defines the peer-to-peer observable 
> behavior between participants in a multi-party collaboration, each 
> participant having their own private business processes that are 
> considered abstract to the choreography. Hence, the choreography 
> details a "dance" between these participants, and it is used as the 
> basis for run-time interactions (such as is choreography for a 
> Broadway show, for example).
>  
> Having said all this, I will try to relate these points to your 
> response below:
>  
> <Quote>
> 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. 
> </Quote>
>  
> Not sure what you meant by "the service consumer manages services" - 
> did you mean "service provider" instead of "service consumer"? That 
> would make sense as a reference to Orchestration.
>  
> <Quote>
> If a service is being told to do things for multiple consumers, it may 
> eventually become squeezed for internal resources.
> </Quote>
>  
> Does the first part above mean that "If a Coordinator (the 
> "conducting" process in an Orchestration) has too many resource 
> demands on it"?
>  
> <Quote>
> 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.
> </Quote>
>  
> Does the first part above mean that "If a participating 
> service/process (the "conducted" process in an Orchestration) has too 
> many active threads due to its participation in too many coordinated 
> processes"?
>  
> Thanks,
> Joe
>
>  
>
> Joseph Chiusano
>
> Booz Allen Hamilton
>
> Visit us online@ http://www.boozallen.com <http://www.boozallen.com/>
>
>  
> ------------------------------------------------------------------------
> *From:* Duane Nickull [mailto:dnickull@adobe.com]
> *Sent:* Thu 5/5/2005 10:00 AM
> *To:* Chiusano Joseph
> *Cc:* soa-rm@lists.oasis-open.org
> *Subject:* Re: [soa-rm] Comment: Section 2.1.1 Service Composition
>
> 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
> ***********
>