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?

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

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

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

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

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

arkin

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

Received on Tuesday, 18 March 2003 03:26:02 UTC