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

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:

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.

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

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

soa-rm message