- From: Burdett, David <david.burdett@commerceone.com>
- Date: Wed, 19 Mar 2003 06:33:54 -0800
- To: Jean-Jacques Dubray <jjd@eigner.com>, "'Burdett, David'" <david.burdett@commerceone.com>
- Cc: public-ws-chor@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC07E6EDDA@C1plenaexm07.commerceone.com>
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. David -----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 David: 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 choreography! JJ- >>-----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 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 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 Wednesday, 19 March 2003 09:34:01 UTC