- From: Fletcher, Tony <Tony.Fletcher@choreology.com>
- Date: Fri, 18 Jul 2003 11:22:26 +0100
- To: "Martin Chapman" <martin.chapman@oracle.com>, "Andrew Berry" <andyb@whyanbeel.net>, <public-ws-chor@w3.org>
Dear Martin and others, It is entirely possible that those who attended the F2F agreed that we should work only on the technical contract aspects (although I doubt that Bob Haugen bought into that view as such!), but unfortunately I was not privileged to attend this F2F. I have not seen any such decision broadcast on this list (or any other decision for that matter), nor announced on a Telecon. I have searched through the F2F notes produced so far and although some discussion around the topic of contracts is evident, an actual decision / resolution is not. Perhaps you would therefore like to clarify what you mean by a technical contract (as opposed to a business contract) and announce this decision / resolution. My personal view is that the work will do on a language for describing choreographies (interactions and their sequencing) will contribute to the technical aspects of a contract, but we should have a general awareness of the encompassing business contract 'framework' within which such technical aspects sit. 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: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: 17 July 2003 17:09 To: Fletcher, Tony; Andrew Berry; public-ws-chor@w3.org Subject: RE: Revised: Mission Statement I had though that at the chicago f2f we agreed that we would only be working on technical conracts and not on business ones. Cleary there is an intersection, but the group should focus on the technical foundations first. Cheers, Martin. > -----Original Message----- > From: public-ws-chor-request@w3.org > [mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony > Sent: Thursday, July 17, 2003 3:57 AM > To: Andrew Berry; public-ws-chor@w3.org > Subject: RE: Revised: Mission Statement > > > > 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 Friday, 18 July 2003 06:22:41 UTC