RE: Definition of Terms

MessageI definitely agree with you about the confusion in using the term
'execution' for both.

I think everybody knows that an orchestration is executed by one role. That
definition is easy. But how would we define choreography?

We want to say that a choreography can be 'driven to completion' by all the
roles. We also want to say that it requires all the roles to participate per
the activities they are responsible for, not just a subset. And we want to
say that the responsibility is placed on the shouldiers of all these roles
that act as peers, there is no 'big brother' sitting in the middle (central
control). We need some understandable terms to capture that. Any ideas?

I have an issue with choreography instance. There is a choreography instance
in play. But there are also conversations. A mulit-party choreography may
involve multiple such conversations, with participants joining and leaving
conversations over time (as expressed in the choreography in a very precise
way). Sometimes it's helpful to think of a conversation thread ongoing
within the choreography. If we don't have that notion as separate from
choreography instance, it may be confusing to define the choreography for
some use cases.

arkin

  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Edwin Khodabakchian
  Sent: Wednesday, March 19, 2003 12:43 PM
  To: 'Assaf Arkin'; 'Burdett, David'; 'WS Choreography (E-mail)'
  Subject: RE: Definition of Terms


  Assaf,

  I think that we would benefit not reusing the same term for what we do
with a choreography and orchestration. Meaning avoid reusing the term
execute. This is an area where there is already a *lot* of confusion on the
market and I think that adds to it.

  It seems to me that choreography is about creating protocols that services
comply with and orchestration flows that gets executed by an engine. So I
would keep execute for orchestration and find another term for choreography.

  I also think that JJ's suggestion to use "Choreography" and "Choreography
Instance", "Orchestration and Orchestration Instance" is a good suggestion
because it reduced the number of new terms and potential sources of
confusion.

  Edwin

    -----Original Message-----
    From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Assaf Arkin
    Sent: Wednesday, March 19, 2003 12:13 PM
    To: Burdett, David; WS Choreography (E-mail)
    Subject: RE: Definition of Terms


    Absolutely.

    arkin
      -----Original Message-----
      From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
      Sent: Wednesday, March 19, 2003 6:34 AM
      To: Assaf Arkin; Burdett, David; WS Choreography (E-mail)
      Subject: RE: Definition of Terms


      Assaf

      I quite like the definitions:
      - The process defined by an orchestration is executed by a single
      role/service type
      - The process defines by a choreography is executed by a combination
of all
      roles/service types

      ... but would add ...
      -  A process defined by an orchestration is constrained by the
choreographies in which the process takes part.

      David

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




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

      How about:

      - The process defined by an orchestration is executed by a single
      role/service type
      - The process defines by a choreography is executed by a combination
of all
      roles/service types



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

      If I understand the other terminology list correctly then a message
would be
      something like a WSDL abstract message definition, and a
representation
      would be the protocol binding/encoding. So if we express the
choreography in
      terms of WSDL operations (as WSCI and BPEL4WS do), it would meet the
      abstraction requirement.

      I know that there are issues with WSDL if you want more abstraction in
the
      message definition. But I don't think this is a problem that occurs
only
      when you use choreography, and I'm not sure if this group should try
to
      solve it, though we should highlight problems/issues/proposals. I am
fine
      working with WSDL here and then working in the WSD to improve what
needs to
      be improved. I'm not too excited about the possibility of redoing WSDL
      outside of the WSD WG.




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

      The way I see it, to draw a very loose analogy, is like interface,
abstract
      class and class. (Or if you like you can substitute abstract class
with some
      templating mechanism). A choreography is like a definition of
interfaces
      that mesh together (think one interface per role for a second). An
      orchestration is like a class.

      An orchestration can be as full as the implementation (a concrete
class), or
      it can be less than an implementation (abstract or template) to the
point
      where it's so abstract that it parallels the interface. In fact, if
you look
      at Java, an interface is an abstract class that has no non-abstract
methods.

      So one orchestration can extend another. I may have an orchestration:

      orch A
        do X
        ...
        do Z

      and another orchestration:

      orch B extends A
        do X
        do Y
        do Z

      orch A may say what my constraints are for participating in the
      choreography, and orch B may include some other things I do in private
and
      may well be my implementation. Being able to say that orch B extends
orch A
      is useful because if I can understand how A fits with the choreography
I can
      also understand how B can fit. I may also have another orchestration
called
      C (a different implementation altogether):

      orch C extends A
        do X
        do U
        do V
        do Z
        do W

      but notice that both B and C extend A so I may use either of these
      implementation orchestrations for the choreography requiring me to use
A.

      A behavioral type system based on mobile processes deals with exactly
that
      kind of type checking: not just the input/output, but also the
sequencing
      rules. (This example is simplified, but it can deal very well with
more
      complex things like parallel flows, branching, exceptions, cycles,
etc)

      arkin

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