RE: Definition of Terms

See comments in line.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, March 18, 2003 1:48 AM
To: Burdett, David; WS Choreography (E-mail)
Subject: RE: Definition of Terms




> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
> Sent: Monday, March 17, 2003 2:34 PM
> To: WS Choreography (E-mail)
> Subject: Definition of Terms
>
>
>
> 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.

It is absolutely important to make this distinction between information and
the message as being a container for that information. Let's for a second
call it an info bit (alluding to the fact that it can be represented as an
infoset).

An info bit can be an address or the order details. An info bit can be
represented at rest by storing it in the database or as part of the process
instance, it can be manipulated for example using XPath, or it can be
communicated as part of a message. Info bits don't move around, they get
duplicated and communicated.

> 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).

I tend to prefer a distinction between the concept of a location and the
representation of a location by its identifier which may be an end-point
(WSDL port) or in abstract form a channel. I know this adds another layer of
indirection, but it may be beneficial.

> 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.

Absolutely.

> 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.

How about using the term action for such simple interaction, and the term
interaction for interactions or arbitrary complexity (one or more actions)?
<DB>Sounds reasonable.</DB>

> 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.

The definition that uses "as a result of an event" is quite useful for
defining some forms of processes but not others (parallel composition in
pi-calculus or BPSS collaboration). In the later case the process includes
both the emittence and recipt of that event and the triggering event is not
defined as part of the process (though implicitly everything starts
somewhere, including the universe).

> 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.

This is one definition of control domain, but may not be accurate. For
example, as a company I may own two processes and have full control, but for
modularity and reuse would like to treat them as separate control domains.
On the other hand, I may use a service hosted by some service provider and
choreograph my interaction with it, yet may have full management and control
over that process.

I would like to think of control domain as one in which the sequencing of
activities is managed in an unspecified way, as opposed to the need to
exchange messages in order to sequence activities across control domains.
<DB>So how about this as an updated definition...
A Control Domain is a description of the set of Processes that the entity or
operator of those processes chooses to manage and control together. The
sequencing of the processes within a Control Domain is under the control of
and can only be changed or altered by the entity that manages them. A
Control Domain can support one or more Roles.
</DB>

> 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.

I agree with the former but not the later. A conversation that requires two
parties cannot be accomplished by the execution of an orchestration but by
the execution of two orchestration.
<DB>Agreed. So how about "A Conversation is an instance of the execution of
a Choreography". But what would you call the instance of the execution of an
orchestration?</DB>

arkin


>
> 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