W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

RE: Definition of Terms

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 19 Mar 2003 12:15:36 -0800
To: "Burdett, David" <david.burdett@commerceone.com>, "WS Choreography \(E-mail\)" <public-ws-chor@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNCEOADFAA.arkin@intalio.com>
RE: Definition of TermsI would love to make a "friendly amendment", but I'm
not sure I have a clear cut definition yet. I understand what I want to say,
but a succinct definition seems to be elusive. I'll try to think of it,
throw some ideas around and see if we can come up with some good prose.

arkin
  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
  Sent: Wednesday, March 19, 2003 6:34 AM
  To: Assaf Arkin; Burdett, David; WS Choreography (E-mail)
  Subject: 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; Web:
http://www.commerceone.com
Received on Wednesday, 19 March 2003 15:16:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:06 GMT