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