RE: Definition of Terms

The only area where I am not in complete agreement is around how BPEL4WS and
WSCI can be used for choreography definition - see below.

David

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


David,

I want to say upfront that I agree with this analysis. Most of my comments
reflect the fact that I agree on the intent in what you are saying, but I
don't think the language expresses that intent in the best way. I want to
carry this discussion forward, because I think this list of distinctions
should make it to the introduction.


> Choreographies ...
> 1. Involve more than one "domain of control" (e.g. the exchange
> of messages
> between two businesses to place an order)

+1

> 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

I perfectly understand what you mean and fully agree. But I think the notion
of 'single point of control' can have other interpretations that are not
adequate, so I would look for a better definition. But we are in full
agreement on the notion.

Stefano used to say that there is no 'big brother'. I would probably say
something like 'no controlling authority'. Is that a good description?
<DB>Yes. I think this is a better way to describe it.</DB>
> 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.

And also in reverse: the need to have a mutual agreement or understanding is
the driver for proposing a standardized language for choreography.
<DB>Agreed.</DB>

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

Again I definitely agree with the intent but has an issue with the wording.
I could argue that when a buyer and seller interact they 'execute' the
choreography. So perhaps a refinement would be 'a choreography can be
executed only when all participants perform their designated activities'.
<DB>I suppose the point I am trying to say is that you can't feed a
choreography definition into some process management software and expect it
to be executed directly. Instead, you need to feed the *same* choreography
definition into the process managers running at all the roles involved in
executing an instance of the choreography so that they can check they are
following the choreography in a correct way for the role that they are
taking.</DB>

> 5. *Can't* be described by languages like WSCI or BPEL4WS since they only
> describe what is going on in one "domain of control"

Here I would disagree. Both WSCI and BPEL4WS, and going back to WSFL and
XLang, make a distinction between a choreography as a composition, and the
elements of composition. A choreography would be something like a global
model, which in fact meets all these needs. An element of composition would
be something like an interface, of a WSDL operation type, or an XML data
type used in a message. Which is not by itself a choreography, but merely an
element that is used in the definition of one.

So there's a definition of what service X does for its part (XSDL + WSDL +
interface) and a definition of what service Y does for its part (ditto) and
a composition of both parts (model) which is the definition of the
choreography.
<DB>I think this needs exploring further. I don't think that defining a
choreography in terms of WSDL works if you want a reusable choreography that
can be used for B2B (see my other email on Uses of the WS Choreography
spec). On the other hand it does work very well, if you have a one-off
choreography agreed between two parties. There are two different uses here
which have different requirements. I also think there needs to be two parts
to a chorepgraphy definition: a) an abstract choreography definition that is
indpendent of the precise message format and service format, and b)a
"Choreography Implementation Binding" which binds the abstract choreography
definition to specific message formats and service instances to an
implementation.</DB>

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

+1

However, I would not exclude the possibility of using an abstract model for
defining content that does not force a particular encoding or protocol, such
as one that is possible with an abstract definition given by WSDL.

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

+1

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

+1

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

This is not always true. For example, if the buyer participates in the
choreography than the buyer has a lot of freedom to change various parts of
the orchestration - except those that are covered by the choreography.
<DB>Agreed.</DB>

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

Again I fully agree with the intent but not sure about the wording.

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

+1

> 7. Are implementation specific. Orchestrations should describe
> exactly what
> the flows of information are and how they relate to services and
> applications.

Here I would disagree only because I consider the orchestration to be
separate from the implementation, sometimes overlapping (e.g BPEL, BPML) and
sometimes being a non-complete subset. By definition any choreography
language (WSCI, BPSS, yet-to-be-imagined) can define an orchestration that
fulfills the service's role in the choreography, but such an orchestration
may be a simple template that requires much more details to construct an
orchestration that will also serve as an implementation.

In OO terms I would say that an orchestration is like a Java class. It may
be the class you use to create objects from (implementation process
instances), but it can also be an abstract class that only matches the
interface but must be extended before any objects can be created.

The analogy is not complete. Process models are type systems that can define
behavior while OO are type systems that can only describe points of
interaction (much like WSDL operation). So one has to look at how mobile
process calculus has been used to define behavior of objects beyond the
limitation of OO languages (benefiting from >10 years of experience).
<DB>I think you are hinting at some layering in the spec when you talk about
templates. We need greater clarity on what these layers are.</DB>

arkin

>
> Also see comments inline ...
>
> David
>

Received on Tuesday, 18 March 2003 15:36:06 UTC