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 Tuesday, 18 March 2003 16:49:02 UTC