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

RE: Revised: Mission Statement

From: Fletcher, Tony <Tony.Fletcher@choreology.com>
Date: Thu, 17 Jul 2003 11:57:21 +0100
Message-ID: <221369570DEDF346AE42821041345E891956B8@exchange1.corp.choreology.com>
To: "Andrew Berry" <andyb@whyanbeel.net>, <public-ws-chor@w3.org>

Dear Andrew,

Below you write:  "Is a choreography an electronic representation of a
business contract for the interaction?   If so, then perhaps model
visibility/scope should be defined by the contract boundaries."

Thank you for raising this topic.  I do think that contracts are going
to be an important 'overlay' to this work.  Sometimes they will be
explicit and quite tight (this is usually true in the B2B eBusiness case
I suspect) or covered by an implicit 'default' contract / legal
framework - as in some uses of Web Services.  So the range and nature of
the contract could be quite wide depending on the precise situation.

I also wonder if your last sentence needs some expansion.  My
understanding is that specific contracts are usually between just 2
interacting roles (/ parties).  Thus a choreography involving just 2
roles will conform to our sentence.  However, a choreography that
encompasses several roles and parties will involve several different
contractual relationships - one for each pair wise interaction in the
Choreography.  (I am sure you are aware of this, and I realise the
difficulty of succinctly expressing something without reproducing the
whole thesis! - just pointing out for others to agree / disagree.)

Note 1:  My understanding of a party is a single administrative domain
such as a company or some trading entity of a company.   A role is a
party acting in a specific capacity - e.g. supplier, buyer, distributor,
stock controller, etc.

Note 2:  You will need to check my understanding against what others in
the group say.  I can not claim to be expressing the group consensus
(though I am honestly trying not to mislead but contribute to forward
motion!).

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 Andrew Berry
Sent: 16 July 2003 15:12
To: public-ws-chor@w3.org
Subject: Re: Revised: Mission Statement



>
> Jon Dart wrote:
>
> > Several statements have been made about the kind of model we don't
> want.
> > But IMO it is not really clear enough what we do want.
> >
> > If I understand things correctly (a fairly big "if"), one
> requirement is
> > that there be basically one model for both client & server (or peer
> and
> > its peer, if you want to be more egalitarian). This means that I
> don't
> > need to model the messages one party sends and have a parallel model
> of
> > what the other party is receiving. The choreography description I
> expose
> > to my partners should be sufficient for them to interact with me.
> This
> > doesn't imply that there's one big model of all participants'
> > message flows - in fact I think you don't want this. But it does 
> > imply that
> as
> > party A directly interacting with party B, both parties have a model
> > they can both view and base their interactions on (could include > 2

> > participants also).
>

One of the issues that has come up for me in the past is that of 
business contracts.  Business-to-business interaction tends to be 
governed by legally-binding, written or unwritten contracts that 
specify the required roles and behaviour of all participants.  Is a 
choreography an electronic representation of a business contract for 
the interaction?   If so, then perhaps model visibility/scope should be 
defined by the contract boundaries.

Ciao,

AndyB
Received on Thursday, 17 July 2003 06:57:29 GMT

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