RE: Definition of Terms

No offence David, I'm just replying to the most recent mail on this
thread.

At last weeks meeting we had a discussion on the difference between
choreography and orchestration.
It became clear quite quickly that there isn't really a clear
distinction in everyone's mind, and 
attempts at definitions always met with some disagreement. Rat holing on
terminology before we 
even know what we are doing is counter productive,  so the group agreed
to use the terms 
synonymously for the time being (or more accurately not to use the "o"
word for the time being).

We can obviously re-visit this in the future, and in the meantime I
would encourage us to spend 
our efforts on gathering requirements.

Cheers,
  Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David
> Sent: Tuesday, March 18, 2003 12: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 to an instance of a Choreography, in which case we 
> need a word to describe the instance of an execution of an 
> Orchestration. Generically, an orchestration instance is a 
> process execution, but process executions are much more 
> general. Do you (or anyone else) have any ideas?
> 
> David
> 
> -----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 an 
> object be an instance of two different classes ?
> 
> Rgds, Ricky
> 
> At 02:33 PM 3/17/2003 -0800, Burdett, David wrote:
> 
> >Folks
> >There has been a lot of discussion about Choreographies, 
> >Orchestrations, Conversations, etc, so I thought it might 
> help to make 
> >an attempt at some definitions of terms so that the 
> distinction between 
> >them all was clear. The following is my attempt. It starts with some 
> >very basic definitions on which later definitions rely. I am also 
> >certain that there is still plenty of scope for improvement and 
> >revision, so comments are welcome. Hope this helps. David
> >=========================================
> >INFORMATION
> >Information is data of a specific type, for example, "Order 
> Information",
> >"Status Information". Information has a specific semantic 
> meaning, e.g.
> >"Order Information" is a  "request to purchase goods". The 
> same piece of
> >Information can take many different forms, for example an 
> XML, PDF, email,
> >paper letter, fax, voice, etc.
> >MESSAGE
> >A Message is a description of one or more pieces of 
> Information combined
> >with adressing information. A Message can have one or more different
> Message
> >Representations.
> >MESSAGE REPRESENTATION
> >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 SOAP 
> >Message, an EDI Order document within an ebXML Message or a spoken 
> >voice description of an Order. MESSAGE INSTANCE
> >A Message Instance, is an instance of an actual Message 
> Representation,
> e.g.
> >a real UBL order expressed in XML with real line items inside a SOAP 
> >message, etc. LOCATION
> >A Location is a description of a person, place, software, 
> application or
> >service that can generate or accept Message Instances. A Location may
> accept
> >or generate Message Instances in one or more different Message 
> >Representations. (In WSDL this would be a Port). ROLE
> >A Role is a description of a set of related Processes that 
> serve a single
> >purpose. For example a "buyer role" is the set of activities 
> taken by a
> >party, individual, business or software that are required to purchase
> goods.
> >A Role may be supported at multiple Locations. A Location 
> may support 
> >multiple Roles. INTERACTION
> >An Interaction is the definition of the sending of a Message 
> from one Role
> >to one other for a reason. For example: a) sending an "order 
> message" from
> a
> >"buyer role" to a "supplier role" so that the "supplier role" can 
> >satisfy the order, or b) sending an order message from an "archive 
> >requesting role" to an "archive "archiving accepting role" 
> so that the 
> >latter role can archive the order message. INTERACTION INSTANCE
> >An Interaction Instance is the sending of one Message 
> Instance from one
> >Location acting in one Role to another Location acting in 
> another Role.
> >PROCESS
> >A Process is the description of a set of activities that do 
> useful work
> that
> >occur as a result of an event such as the arrival of a 
> Message Instance 
> >or the passage of time. The execution of a Process usually 
> results in 
> >the generation of additional Message Instances. SUB-PROCESS
> >A Sub-Process is a Process that is executed as part of and under the
> control
> >of another Process.
> >CONTROL DOMAIN
> >A Control Domain is a description of the set of Processes that are 
> >under
> the
> >management control of a single entity or organization. The Processes 
> >and
> the
> >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 
> >one
> or
> >more Roles.
> >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.
> >
> >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 Tuesday, 18 March 2003 17:07:37 UTC