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 15:58:27 UTC