RE: Definition of Terms

I underestand your concerns. Do you want to make a "friendly amendment"?
 
David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, March 18, 2003 2:02 PM
To: Burdett, David; WS Choreography (E-mail)
Subject: RE: Definition of Terms


<DB>So how about this as an updated definition... 
A Control Domain is a description of the set of Processes that the entity or
operator of those processes chooses to manage and control together. The
sequencing of the processes within a Control Domain is under the control of
and can only be changed or altered by the entity that manages them. A
Control Domain can support one or more Roles. 
 </DB>  
 
I still have a problem with that. I can have an interaction between two
business partners but be able to change or alter the processes running at
both side. I may do so because I have some controlling authority, or because
I hand them an implementation to use as part of my business relation, or
because I actually implement a proxy working on their behalf (see my use
case). But I still see how all these use cases implement different control
domains.
 
Let's look at one particular example of control domain having to do with
SLA. In order for the buyer to get a good price the buyer must present the
seller with an SLA. The SLA is granted to the buyer at some point in time
and is revoked at an agreed upon time. Buyer promises to buy a lot of goods,
so they get a fair discount, at the end of the year their purchases are
reviewed to determine if they met the quota, and a new discount/SLA is
created.
 
The seller executes a sequence of activities on behalf of the buyer and they
all carry around the same SLA presented by the buyer when the PO is
submitted. There is no need to specify how this SLA is carried since it
occurs in the same control domain, so we can just say sequence(A,B,C,D,etc).
The seller executes a sequence of activities on behalf of the buyer, but the
buyer must provide a valid SLA as part of sending the PO. Regardless of how
this is done technologically, it must be represented in the message
exchange, since the buyer is in a different control domain. So we need some
message link between the two.
 
In the use case I presented the buyer process is actually executed by the
seller as a proxy on behalf of the buyer. But it's still subject to the same
choreography even though it is implemented in the same closed network, maybe
even on the same machine. So it still must present that SLA. There are two
control domains: buyer and seller, and seller does not grant buyer any
priviledges just because they happen to run on the same machine: all
privileges must be granted by passing the SLA around. So there are still to
control domains even though there may be one execution domain, or one
management domain, or one definition lifecycle domain.
 
arkin
 
 

> COLLABORATIVE PROCESS 
> A Collaborative Process is a Process that is implemented through 
> Interactions between two (or more) Roles within two (or more) Control 
> Domains. 
> CHOREOGRAPHY 
> A Choreography is the definition of the sequence and dependencies of the 
> Interactions between Roles required to implement a Collaborative Process. 
> For example the process by which a "buyer role" places an order with a 
> "supplier role", or the process by which a procurement system comunicates 
> order information with an ERP system. 
> ORCHESTRATION 
> An Orchestration is the definition of the sequence and dependencies of the

> Processes executed by a single Role. The Interactions that result from 
> executing the Processes MUST comply with: a) any constraints 
> implied by any 
> Choreographies in which the Role takes part, and b) any constraints on 
> Message Representations that Locations that receive Message Instances 
> generated by the Orchestration require. 
> All the Processes and Sub-Processes within a single Orchestration 
> definition 
> should be related to one another. An Orchestration definition may 
> be used to 
> define the behavior of a Process that is executed by a single Role. 
> CONVERSATION 
> A Conversation is an instance of the execution of a Choreography or an 
> Orchestration. 

I agree with the former but not the later. A conversation that requires two 
parties cannot be accomplished by the execution of an orchestration but by 
the execution of two orchestration. 
<DB>Agreed. So how about "A Conversation is an instance of the execution of
a Choreography". But what would you call the instance of the execution of an
orchestration?</DB>

arkin 


> 
> Thoughts? 
> 
> Director, Product Management, Web Services 
> Commerce One 
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA 
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704 
> mailto:david.burdett@commerceone.com;
<mailto:david.burdett@commerceone.com;>  Web: http://www.commerceone.com
<http://www.commerceone.com>