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

RE: Definition of Terms

From: Burdett, David <david.burdett@commerceone.com>
Date: Wed, 19 Mar 2003 06:33:54 -0800
Message-ID: <C1E0143CD365A445A4417083BF6F42CC07E6EDDA@C1plenaexm07.commerceone.com>
To: Jean-Jacques Dubray <jjd@eigner.com>, "'Burdett, David'" <david.burdett@commerceone.com>
Cc: public-ws-chor@w3.org
Jean Jacques

I hear you! I was just trying to get some definitions published so that we
can start the dialogue. I think, as has been suggested in an earlier email,
it would be a good idea to develop definitions in a more measured way once
there is some a general consensus on the concepts.


-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Tuesday, March 18, 2003 1:45 PM
To: 'Burdett, David'
Cc: public-ws-chor@w3.org
Subject: RE: Definition of Terms


Even though all the names make the spec more poetic, I think ultimately
it also makes it less readable. I am personally in favor of using full
names for the concept (e.g. collaboration, orchestration and then
proceed via fully qualified concepts: collaboration definition,
collaboration instance, collaboration instance history. The can also use
TLAs, such as CD, CI, OD, OI, ... where appropriate.

I am suggesting this because otherwise we need a full name for the
concept, its definition, its instances, ... some concept might even have
a third level: such as "concept type usage". For instance in BPSS a
usage of a concept type is called an activity (Business Transaction ->
Business Transaction Activity).

Look at how much confusion there is already between orchestration and


>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>On Behalf Of Burdett, David
>>Sent: Tuesday, March 18, 2003 3:58 PM
>>To: Ricky Ho; Burdett, David; WS Choreography (E-mail)
>>Subject: RE: Definition of Terms
>>Assaf raised the same point suggesting that Conversation be restricted
>>instance of a Choreography, in which case we need a word to describe
>>instance of an execution of an Orchestration. Generically, an
>>instance is a process execution, but process executions are much more
>>general. Do you (or anyone else) have any ideas?
>>-----Original Message-----
>>From: Ricky Ho [mailto:riho@cisco.com]
>>Sent: Tuesday, March 18, 2003 9:27 AM
>>To: Burdett, David; WS Choreography (E-mail)
>>Subject: Re: Definition of Terms
>>David, I agree with all except the last one "conversation".  How can
>>object be an instance of two different classes ?
>>Rgds, Ricky
>>At 02:33 PM 3/17/2003 -0800, Burdett, David wrote:
>>>There has been a lot of discussion about Choreographies,
>>>Conversations, etc, so I thought it might help to make an attempt at
>>>definitions of terms so that the distinction between them all was
>>>The following is my attempt. It starts with some very basic
>>>which later definitions rely. I am also certain that there is still
>>>of scope for improvement and revision, so comments are welcome.
>>>Hope this helps.
>>>Information is data of a specific type, for example, "Order
>>>"Status Information". Information has a specific semantic meaning,
>>>"Order Information" is a  "request to purchase goods". The same piece
>>>Information can take many different forms, for example an XML, PDF,
>>>paper letter, fax, voice, etc.
>>>A Message is a description of one or more pieces of Information
>>>with adressing information. A Message can have one or more different
>>>A Message Representation is a definition of the binding of a message
to a
>>>particular form, for example each of the following are Message
>>>Representations: a UBL Order schema defintion within the Body of a
>>>Message, an EDI Order document within an ebXML Message or a spoken
>>>description of an Order.
>>>A Message Instance, is an instance of an actual Message
>>>a real UBL order expressed in XML with real line items inside a SOAP
>>>message, etc.
>>>A Location is a description of a person, place, software, application
>>>service that can generate or accept Message Instances. A Location may
>>>or generate Message Instances in one or more different Message
>>>Representations. (In WSDL this would be a Port).
>>>A Role is a description of a set of related Processes that serve a
>>>purpose. For example a "buyer role" is the set of activities taken by
>>>party, individual, business or software that are required to purchase
>>>A Role may be supported at multiple Locations. A Location may support
>>>multiple Roles.
>>>An Interaction is the definition of the sending of a Message from one
>>>to one other for a reason. For example: a) sending an "order message"
>>>"buyer role" to a "supplier role" so that the "supplier role" can
>>>the order, or b) sending an order message from an "archive requesting
>>>to an "archive "archiving accepting role" so that the latter role can
>>>archive the order message.
>>>An Interaction Instance is the sending of one Message Instance from
>>>Location acting in one Role to another Location acting in another
>>>A Process is the description of a set of activities that do useful
>>>occur as a result of an event such as the arrival of a Message
>>>the passage of time. The execution of a Process usually results in
>>>generation of additional Message Instances.
>>>A Sub-Process is a Process that is executed as part of and under the
>>>of another Process.
>>>A Control Domain is a description of the set of Processes that are
>>>management control of a single entity or organization. The Processes
>>>Sub-Processes that are within a Control Domain can only be changed or
>>>altered by the entity that manages them. A Control Domain can support
>>>more Roles.
>>>A Collaborative Process is a Process that is implemented through
>>>Interactions between two (or more) Roles within two (or more) Control
>>>A Choreography is the definition of the sequence and dependencies of
>>>Interactions between Roles required to implement a Collaborative
>>>For example the process by which a "buyer role" places an order with
>>>"supplier role", or the process by which a procurement system
>>>order information with an ERP system.
>>>An Orchestration is the definition of the sequence and dependencies
>>>Processes executed by a single Role. The Interactions that result
>>>executing the Processes MUST comply with: a) any constraints implied
>>>Choreographies in which the Role takes part, and b) any constraints
>>>Message Representations that Locations that receive Message Instances
>>>generated by the Orchestration require.
>>>All the Processes and Sub-Processes within a single Orchestration
>>>should be related to one another. An Orchestration definition may be
>>>define the behavior of a Process that is executed by a single Role.
>>>A Conversation is an instance of the execution of a Choreography or
>>>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 09:34:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:57 UTC