RE: Definition of Terms

+1

It's useful to pick English-language words because of their meanings and
connotations.  But when we start mixing metaphors (like saying a
"conversation" is an instance of a "choreography"), it becomes even harder
to follow our terminology than if we had named things, "001" and "002".

Ed

> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Tuesday, March 18, 2003 4: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 11:56:57 UTC