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:10:32 UTC