W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

RE: Definition of Terms

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 18 Mar 2003 14:06:15 -0800
To: "Patil, Sanjaykumar" <sanjay.patil@iona.com>, "Burdett, David" <david.burdett@commerceone.com>
Cc: <ChBussler@aol.com>, <public-ws-chor@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNEEMDDFAA.arkin@intalio.com>
RE: Definition of TermsThat would make perfect sense.

I think I know what David means, and I think he knows what I mean, but if we
use words incorrectly we may confuse other people. That would make the
discussion harder. For example, in one of my examples I used service when I
ment role, and that was kind of confusing. And we still don't have a good
word for orchestration instance (other than 'orchestration instance').

So we're trying to find simple explanations that are not confusing but
capture the intention very well, and then we should summarize that. I also
think that David's list captures the jist of it and should be represented in
tabular form. That would help move the discussion further.

arkin
  -----Original Message-----
  From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
  Sent: Tuesday, March 18, 2003 1:01 PM
  To: Assaf Arkin; Burdett, David
  Cc: ChBussler@aol.com; public-ws-chor@w3.org
  Subject: RE: Definition of Terms



  David/Assaf, would it make sense to capture these definitions (at least
the ones for orchestration and choreography) in a document? We could even
use the set of characteristics that David listed in his original email to
highlight the differences between orchestration and choreography, perhaps in
a tabular form. Once again, I am personally keen on clearly distinguishing
the two conceptual areas and it doesn't matter to me much which words we
stick to them.

  I am sure there are others on the list who would prefer to review the
summary of this discussion before making any further comments! Chairs, any
thoughts?
  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: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Tuesday, March 18, 2003 12:51 PM
    To: Burdett, David
    Cc: ChBussler@aol.com; Patil, Sanjaykumar; public-ws-chor@w3.org
    Subject: RE: Definition of Terms


    You'll have to excuse me for confusing people again. I also think of
choreography in terms of roles, so it can support any number of services,
but most of the time when I write down examples I use the term service. I
did mean what you said and said not what I mean ;-)

    arkin

     -----Original Message-----
    From: Burdett, David [mailto:david.burdett@commerceone.com]
    Sent: Tuesday, March 18, 2003 12:36 PM
    To: Assaf Arkin; Burdett, David
    Cc: 'ChBussler@aol.com'; sanjay.patil@iona.com; public-ws-chor@w3.org
    Subject: RE: Definition of Terms


      Assaf

      I agree with your response completely, but with one exception.

      Choreographies should be expressed in terms of roles not services,
e.g.

      Role J
        activity A1 send request

      Role K
        activity A2 receive request

      I think this is important as it enables reuse of the choreography
definition, to take a more realistic example ...

      Buyer
        activity order send request

      Seller
        activity order receive request

      If you don't use roles then you would have ...

      ABC Co Buyer service
        activity order send request

      XYZ Inc Selling service
        activity order receive request

      ... and every interaction done in business would each have its own
separate choreography. This won't scale.

      Choreography really should be abstract in order to enable reuse. This
also applies to the message definition as well as the service.

      Thoughts?

      David




      -----Original Message-----
      From: Assaf Arkin [mailto:arkin@intalio.com]
      Sent: Monday, March 17, 2003 11:58 PM
      To: Burdett, David
      Cc: 'ChBussler@aol.com'; sanjay.patil@iona.com; public-ws-chor@w3.org
      Subject: Re: Definition of Terms



      Burdett, David wrote:

      > 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].
      >
      I would tend to define a message as a container of information. The
      container notion is important because it lets you compose different
bits
      of information that can be reused in different messages, and different
      bits of information may have different significance (e.g. the business
      request, the topic of request, the requesting party). WSDL does that
      pretty well.

      The message definition is that of a message at rest. It says nothing
      about which direction it goes on, or which service can consume or
      produce it. That information is provided by the operation. The
operation
      tells you whether that message is an input or an output, and in fact
      what it signifies. The action then tells you which service is
      responsible for performing that operation either as the requestor or
      provider, and in relation to all other actions.



      >     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!
      >
      I think that the use of the term 'domain of control' depends on
context.
      We can talk about who owns the definition, who runs the instance, even
      who serves the coffee. But I think there's a very clear and precise
      meaning in terms of choreography.

      Let's say that some service X sends a message (request) to service Y,
      service Y receives that message, does something and then sends back a
      response. Service X performs some activity A1 which sends the message.
      Service Y performs some activity A2 which receives the message, and
      later on some activity A3 which sends back a response. Service X and
      service Y belong to different domains of control.

      Service X can't just start an activity in service Y by wishful
thinking.
      And ESP technology is not proven yet. So service X "coerces" service Y
      to start an activity by sending it a message. Service Y needs to
perform
      two activities one after the other. Service Y has some unspecified
means
      to do that, maybe because it has a big piece of Java code, or because
it
      uses some internal mechanism to chain these activities together. But
      it's not important to express how these activities are chained
together
      in the context of a choreography.

      So in the choreography we would say something like:

      service X
        activity A1 send request

      service Y
        activity A2 receive request

      We show the relation between two activities executing in different
      domains of control by expressing how they communicate, which is
      important information for both services to understand.

      On the other hand, the choreography definition of service Y could say
      something like:

      service Y
        activity A2 receive request
        activity A3 send response

      Exactly how service Y chains these two activities together is not
      interesting for service X (or any other service in the choreography).
      It's an implementation detail. Service Y may have some other message
      that is send by A2 to start A3, or it may update some record in the
      database, of have some person flicking switches on a big panel. That's
      not important.

      We show the relation between two activities executing in the same
domain
      of control using some form of sequencing that does not require
explicit
      form of communication, e.g. in a procedural way, using state
transition
      diagrams, or by expressing a process flow

      (WSCI takes the third approach since it makes it easier to model
      activities that occur in parallel. Unfortunately, due to the choice of
      syntax - and I'll be first to take the blame - it is often confused
with
      being procedural and non-cyclic despite the intent of the authors)

      arkin

      >
      >     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
      >
      >     In a message dated 3/17/03 4:55:50 PM Pacific Standard Time,
      >     david.burdett@commerceone.com writes:
      >
      >



      --
      "Those who can, do; those who can't, make screenshots"

      ----------------------------------------------------------------------
      Assaf Arkin                                          arkin@intalio.com
      Intalio Inc.                                           www.intalio.com
      The Business Process Management Company                 (650) 577 4700
Received on Tuesday, 18 March 2003 17:07:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:06 GMT