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

RE: Grounding Choreographies (the atoms) - WAS Simple Choreograph y composition suggestion

From: Burdett, David <david.burdett@commerceone.com>
Date: Fri, 18 Jul 2003 13:36:27 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1C0D@C1plenaexm07.commerceone.com>
To: "'Tony Fletcher'" <tony_fletcher@btopenworld.com>, public-ws-chor@w3.org

Tony

My use case for having a choreography definition is covered by slides 9 and
10 of the presentation I gave at the F2F in June [1]. 

Quoting from this the key requirements are that:
1. One role can't control what another role does, for example a buyer can't
control what the seller does and vice versa.
2. For roles to interoperate, they both *have* to agree how they will
co-operate (e.g. the buyer and seller must agree how orders will be placed
and satisfied)
3. This means that the roles (e.g. the buyer and seller) must have a shared
understanding of what each will do.
4. The Choreography definition is *one part* of the shared definition of
what the roles will do in terms of the sequence and conditions in which
interactions/messages occur. (Other parts include message content and
service interface definitions).

So without a shared definition of the choreography, interoperability will
not occur.

Providing a *single* definition of the shared choreography that defines the
behavior of all the roles involved means that those roles are using the
*same* definition which means that the chances of a role misunderstanding
what's required are reduced. By comparison, separate definitions of what
each role will be more open to errors.

David


[1]
http://lists.w3.org/Archives/Public/www-archive/2003Jun/att-0037/WS_Choreogr
aphy_v.0-1_Overview.ppt

-----Original Message-----
From: Tony Fletcher [mailto:tony_fletcher@btopenworld.com]
Sent: Friday, July 18, 2003 12:52 PM
To: public-ws-chor@w3.org
Subject: RE: Grounding Choreographies (the atoms) - WAS Simple
Choreography composition suggestion



Dear Colleagues,

I take no credit for raising this question - I think I remember Paul Lipton
asking it on one of the early Telecons six months or so ago.  But it is
raised again in the mail below so I will surface it again explicitly.

What is the use case for having a Choreography language of the type that
this group is trying to develop?  Who will use it or what will use it.  At
what stage(s) of designing and running business processes will it be used?
What will we be able to achieve when we have the language available that we
can not achieve now?  (And what are the advantages of expressing the
language in XML syntax (I can list some disadvantages already!) rather than
just building the language ourselves (as Java, C#, Perl, etc., etc.)?

The use cases we have all describe various business 'situations' or
scenarios that the language could / should be able to describe but do not
describe how such a description would be used or what the benefits of having
one available would be.  (By the way if any of the authors of the use cases
have included this then apologies, thank you, and please point me to chapter
and verse (OK a URI will do!) and I will go and read properly.)

I do have my own views on the answers to these questions but I am hoping
that others will respond with some sound reasons.  If people do I really
feel that it will focus and re-invigorate the group. 

Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0) 7801
948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Champion, Mike
Sent: 17 July 2003 19:25
To: public-ws-chor@w3.org
Subject: RE: Grounding Choreographies (the atoms) - WAS Simple Choreograph y
composition suggestion





> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> Sent: Thursday, July 17, 2003 1:59 PM
> To: Martin Chapman; Steve Ross-Talbot; Champion, Mike
> Cc: public-ws-chor@w3.org
> Subject: RE: Grounding Choreographies (the atoms) - WAS Simple 
> Choreograph y composition suggestion
> 


> While I agree that it should be possible to define a MEP with the 
> choreography langauge, I would not like a reliable messaging 
> choreography to be merged with a purchasing choreography.
> I want the purchasing choreography to be expressed with the
> reliable messaging protocol implied, i.e., abstracted out.
> 
> The MEP will have implications to the design of the business 
> choreography.  Consequently, it may be necessary to incorporate a 
> reference so that the assumptions are clear, but I don't see a single 
> choreography incorporating both levels of abstraction in any more 
> complex way.

Maybe we could agree that ...

-- The underlying formalism we use or devise must be rich enough to describe
all known MEPs, and RM protocols, etc.

-- The actual WS-Choreography language must be rich enough to describe the
interaction at the "logical" level, with RM, Security interactions, etc.
abstracted away.

-- Our objective is that business choreography *languages* can be built as a
layer on top of WS-Choreography, not that it should be directly useable by
non-technical business analysts  .  
Received on Friday, 18 July 2003 16:59:27 GMT

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