RE: Definition of Terms

Christoph
 
See comments inline below.
 
David

-----Original Message-----
From: ChBussler@aol.com [mailto:ChBussler@aol.com]
Sent: Monday, March 17, 2003 9:44 PM
To: david.burdett@commerceone.com; sanjay.patil@iona.com;
public-ws-chor@w3.org
Cc: ChBussler@aol.com
Subject: Re: Definition of Terms


Hi,

a remark on 'control' (or maybe a question). I assume that your definition
of 'message' is abstract, i.e. does not imply asynchronous transmission
between sender and receiver. 
[David Burdett] Right. A message is completely abstract. It is simple the
transmission of information from one location to another (e.g. from one
service to another). How this transmission is achieved is immaterial, i.e.
it can be eith synchronous or asynchronous - whatever those words mean. In
fact on the WSA group there has been great difficulty and debate around
defining what synchronous and asynchronous actuall mean [1]. 
 If this is so, then in context of synchronous invocations some control is
applied from the invoking party since it controls when the receiving party
has to respond, i.e., receives the 'message'.
[David Burdett] I think it is useful to distinguish between: a) the control
implied by sending a message that alters the state of the choreography, for
example, the sending of an order, and b) the control used to make sure that
an individual message is delivered, which is where synchronous invocations
come in. You can always implement the same sequence of exhchange of messages
(e.g. a choreography) either synchronously or asynchronously. The actual
approach you follow is an implementation decision since the meaning (or
semantics) behind sending the message should remain the same.  

The definition of 'control' in general is difficult. Maybe a distinction has
to be made between controlling the definition vs. controlling the execution
(i.e., type vs. instance).
[David Burdett] Very true. A choreography definition (the type) is, IMO,
something that MUST have an independent existence and be agreed by all the
roles involved before interoperable solutions can occur. The actually
choreography *definition* must also be owned by someone as it is a single
definition that describes what all the roles must do. For example, in B2B,
the owner of a choreography definition could be: a) an 800lb Gorrilla, e.g
Walmart telling all its suppliers follow the Walmart choreography or you
don't do business, b) a trade association, e.g. RosettaNet with their PIPS,
or  c) an international standards organization, e.g. UN/CEFACT.
On the other hand, the execution of a choreography can be owned by no one
and HAS to be handled by mutual agreement, even if it is the SME agreeing to
do business the way Walmart wants them to!

Thanks,

Christoph

[David Burdett] [1]See, for just one example, the thread starting at
http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0074.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0074.html> 
 
In a message dated 3/17/03 4:55:50 PM Pacific Standard Time,
david.burdett@commerceone.com writes:




Subj:RE: Definition of Terms 
Date:3/17/03 4:55:50 PM Pacific Standard Time
From:  <mailto:david.burdett@commerceone.com> david.burdett@commerceone.com
To:  <mailto:sanjay.patil@iona.com> sanjay.patil@iona.com,
<mailto:david.burdett@commerceone.com> david.burdett@commerceone.com,
<mailto:public-ws-chor@w3.org> public-ws-chor@w3.org
Sent from the Internet 




Sanjay

I've responded inline below, but first here's an attempt at clarifying the
difference between the Choreographies and Orchestrations ...

Choreographies ...
1. Involve more than one "domain of control" (e.g. the exchange of messages
between two businesses to place an order)
2. Have no single point of control. One "domain of control" has *no way* of
controlling what any other "domain of control" does. For example a buyer
cannot tell a supplier how to run their business
3. MUST be mutually agreed. If all the domains of control don't behave in
precisely compatible ways, then, it won't work. For example if a buyer
expects the supplier to send an Invoice when he sends an order, BUT the
supplier sends a shipping note instead then the order placement will fail.
4. Can't be executed directly. Because there can never be a single point of
control that governs the behavior of all the domains of control involved in
the choreography.
5. *Can't* be described by languages like WSCI or BPEL4WS since they only
describe what is going on in one "domain of control"
6. Should be content independent. Choreographies should be defined
independently of the content of the messages. It should not matter whether
UBL, EDI, fax or a letter is used to represent an order in an order
placement choreography.

On the other hand, Orchestrations:
1. Involve a single "domain of control". They describe what is going on in
one place, e.g. a within a Buyer
2. Have a single point of control. As they describe what is going on in just
one domain of control everything can be controlled and coordinated
centrally. It also means that changes to the orchestration can be made at
any time.
3. Don't require any pre-agreement. A Buyer can decide independently how
they are going to run their business without consulting with anyone else.
4. Can be executed directly. As there is a single point of control, you can
have a single piece of software that controls everything going on.
5. *Can* be described by languages like WSCI and BPEL4WS since they define
executable logic that can be run in one "Domain of control" using a Business
Process Manager.
6. Are constrained by choreographies. Whenever an orchestration involves
flows of information outside of its domain of control, then the
Orchestration must follow precisely the constraints implied by the
Choreography. See item 3 under choreographies.
7. Are implementation specific. Orchestrations should describe exactly what
the flows of information are and how they relate to services and
applications.

Also see comments inline ...

David

-----Original Message-----
From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
Sent: Monday, March 17, 2003 4:04 PM
To: Burdett, David; WS Choreography (E-mail)
Subject: RE: Definition of Terms



Frankly speaking, it's still not clear to me what the differences are (or
how we want to define the differences for our convenience) between
orchestration and choreography (and it seems we have to also deal with:
process, conversation, interaction, interaction instance!).
<DB>Maybe I covered a few too many nuances in one document but there are
reasons for all the definitions. Would it help if I explained why these
separate defintions are useful, for example between interaction and
message?</DB>

David, this is what I am interpreting from your definitions. Please let me
know if I am wrong ...
Choreography provides the global view, where as the scope of orchestration
is confined to any single entity participating in the choreography!
Expanding the concept further, as per your definition, an orchestration is
constrained by the roles it plays (that are defined by choreographies) and
the other orchestrations it interacts with.
<DB>That's a good summary.</DB>

I remember somebody distinguishing these two terms in another way during the
F2F, by associating liveliness with them, that is, choreography is a
definition where as orchestration is an execution of the definition!
<DB>We're just choosing words. The convention in other work, e.g. ebXML is
to use the word Conversation as the execution of an orchestration which is
why I used it. I don't really care as long as we have an agreed definition
that is documented ... which is why I tried coming up with some definitions
;)</DB>

I also remember we simply abandoning the use of the term "orchestration" in
order to move on!!
<DB>IMO, the difference between the processes executed within a business
(i.e. the Orchestration) and agreeing how businesses (domains of control)
interact (i.e the Choreography) is *absolutely critical*. Unless and until
there are widely published and agreed instances of choreography definitions,
e.g. on how to place an order, B2B will never get off the ground and you
can't get instances of choreography definitions without having an agreed way
of defining them. BPSS is the closest to this that we have at the
moment.</DB>

What I really carried with me on this topic in the F2F was somebody's
comment that:- let us first nail down the concepts that we want to define
and then we can associate any terms with those concepts. That is, let us
first define the problems we want to deal with (I guess this is where we got
into the internal vs external debate!!).
<DB>Totally agree. A Use case driven approach is the way to go. This is why
I referenced in an earlier email the three party use case discussed in WS
Architecture at ...
http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0369.html
</DB>

Sanjay Patil
Distinguished Engineer
sanjay.patil@iona.com
-------------------------------------------------------
IONA Technologies
2350 Mission College Blvd. Suite 650
Santa Clara, CA 95054
Tel: (408) 350 9619
Fax: (408) 350 9501
-------------------------------------------------------
Making Software Work Together TM


-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
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.
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






----------------------------------------------------------------------------
-----------------------------
Christoph Bussler
ChBussler@aol.com
hometown.aol.com/ChBussler/
www.google.com/search?q=bussler
www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
----------------------------------------------------------------------------
------------------------------