RE: Definition of Terms

During the F2F, we did define orchestration as being the same as choreography. Any glossary item we have should just reflect that-e.g., orchestration: see choreography. A clear understanding of the meaning of choreography, however, will help in the capturing of requirements.

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Wednesday, March 19, 2003 9:10 AM
To: Burdett David
Cc: 'Patil Sanjaykumar '; 'Martin Chapman '; 'public-ws-chor@w3.org '
Subject: Re: Definition of Terms


I am with Martin here: I thought we agreed at the F2F not to try to
define orchestration.

Re the other proposed glossay terms, I do envision a glossary being part
of the output of this group (or at least additions to the WSA glossary),
but my understanding is that the near-term deliverable is a requirements
doc. So I'd like to suggest that the priority should be to capture that
part of the F2F + recent email discussion that bears on requirements.

--Jon

Burdett, David wrote:
> I think that doing a summary could be very useful as I think there is
> distinction, as Sanjay describes below, between the individual and
> global views which is at the essence of the difference between
> orchestration and choreographies and on which I think, if you had time
> to follow all the emails on the topic, there was a fair degree of consensus.
>
> So how about if Assaf and I, together with anyone else who wants to
> contribute, go off-line, write up the differences and then publish to
> the list in the near future. It would also significantly reduce the
> "noise" on the list.
>
> Anyone disagree?
>
> David
> PS I am having problems sending emails remotely from my laptop and can't
> work off-line, so I cannot easily respond to emails - perhaps that's
> good news ;-)
>
> -----Original Message-----
> From: Patil, Sanjaykumar
> To: Martin Chapman
> Cc: public-ws-chor@w3.org
> Sent: 3/18/2003 3:29 PM
> Subject: RE: Definition of Terms
>
> Sorry to belabor this point, but do we see value in clearly
> distinguishing the two different entities, that is the global view vs.
> the individual participant's view, which the discussion on orchestration
> vs. choreography was getting at.
> 
> I am not entirely sure if the envisioned summary on this topic would
> also account for the issues with the internal vs. external choreography,
> but to me, the discussion sounded very similar. Others, any comments?
>
> 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: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Tuesday, March 18, 2003 3:10 PM
> To: Patil, Sanjaykumar; 'Assaf Arkin'; 'Burdett, David'
> Cc: ChBussler@aol.com; public-ws-chor@w3.org
> Subject: RE: Definition of Terms
>
>
> see my previous mail. I thought we had agreed not to make any
> distinction for the time being.
> 
> Martin.
>
> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Patil, Sanjaykumar
> 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 <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
> <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
> <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 Wednesday, 19 March 2003 12:29:36 UTC