Minutes W3C WS Choreography Face to Face Meeting

17 – 19th December 2003, Cambridge, UK




Role Call:        



 Martin Chapman


Steve Ross-Talbot




W3C Staff Contacts


Yves Lafon









Anthony Fletcher

Choreology Ltd

David Burdett

Commerce One

Jeff Mischkinsky

Oracle Corporation

Nickolas Kavantzas

Oracle Corporation

Monica Martin

Sun Microsystems, Inc.

Ed Peters

webMethods, Inc.





Gary Brown (sub for Duncan)


Andrew Watson


Mark Little


Robin Milner

Cambridge University

Kohei Honda

Queen Mary and Westerfield College

Nobuko Yoshida

Imperial College





Raw IRC logs at:            http://www.w3.org/2003/12/17-ws-chor-irc





Appointment of scribe:


Meeting scribes were: Nick Kavantzas, Tony Fletcher, Jeff Mischkinsky, Ed Peters, Monica Martin.


Day 1



After the usual system configuration antics, the meeting was called to order at 10:15 GMT



Welcome Andrew Watson -- from OMG


Agenda:  http://lists.w3.org/Archives/Member/member-ws-chor/2003Dec/att-0022/Agenda.html


Agenda review - shorten liasion section

possible start spec/overview review if we're early

add omg to liasion section

Delay approval of previous minutes


Minutes of last meeting: http://lists.w3.org/Archives/Member/member-ws-chor/2003Dec/att-0031/20031209-1.htm


Action Item Review:


ACTION : chairs look at WSA issues process and recommend whether it should be adopted by this group. (IN PROGRESS, 1021, 1028, 1111,1118, 1125, 1202, DONE)


Chairs recommend sticking with our current process as defined in an url steve is about to post

Issues process to be used by WS-Chor is outlined in http://lists.w3.org/Archives/Member/member-ws-chor/2003Jul/0040.html


no objections from anyone


DONE:ACTION: issues process



ACTION:Daniel to look though document and see which requirements we captured so far regarding transactions.  (NO PROGRESS,1021, 1028, 1111, 1118, 1125, 1202, DONE)


no action so far -- not clear whether Daniel will be a member, and the requirements document needs to be closed. Propose to drop this action. No objections.


DONE:ACTION: Daniel tx issues


ACTION:SRT to clarify use of “business transaction” using more neutral terminology if possible in section 2.1 (IN PROGRESS 1125, 1202, DONE)


Steve has done that. In latest requirements draft to be discussed later

DONE:ACTION: Steve bus transactions



ACTION: Editors of the requirements are directed to look at the issues list and filter each issue in a similar way to the filtering method used at the F2F.  To be taken into account at editors meeting in November. ( IN PROGRESS, 1021, 1028,1111, 1118, 1125, 1202)


On agenda for this meeting. Hopefully we will close later today or tomorrow



ACTION: Nick to see if roles/participants fit with forth coming meta model (IN PROGRESS for F2F 1202, Done)


ACTION: SRT to add Marcos’s use case to agenda. DONE

ACTION: SRT to update report to incorporate Monica’s comments on report to WS-BPEL and send to Martin. Done

ACTION: SRT to place the hot topics on the agenda for the face to face. DONE

Coffee break


WSDL 2.0 vs WSDL 1.2

We need to be able to express bindings to the transport and services such that we can leverage the features and properties (f&p)

If we did not use f&p we would have to invent something similar within WS-CHOR in order to be able to express QOS related items in concrete bindings.

We have a consensus on asking the WSDL group to continue to support f&p in order to leverage it within a WS-CDL.

NEW ACTION: Chairs to communicate f&p requirement to WS-CG

NEW ACTION: WSDL MEP agenda item to be organised by chairs

Aim of this is to review current work on MEP with a view to seeing what we can leverage.


Martin gave presentation at WSBPEL F2F with Monica's help

Martin requested a formal report/liaison back. No one volunteered, so at this point there is no one.

The WS BPEL TC adopted a new working draft as its baseline doc. All issues should now be raised against it.

Martin proposed that we send the WSBPEL TC a formal request asking for report/updates

NEW ACTION: Chairs to send formal request to WSPEL Chairs

SRT observed that one of our CSFs is ability to work with BPEL. He wanted to verify that is still the case and to ensure that we in fact do address it.


BPSS liaison report by Monica -- slides have been sent, but are currently hung up on someone's smtp server somewhere

jeffm: confusion between the use of terms -- e.g. "business atomic tx" is NOT a traditional atomic tx -- it could be "implemented" by a whole series of msgs, txs, etc.

nick: would like clarification of what "business semantics" really means, perhaps some examples

tony: simple req/rsp is not by itself a "business semantics"

tony: If I request a quote, and receive it back, that may mean that there is now a business contract, legally binding, etc.

tony: that's the business semantics

monica's slides


BPSS might provide the QoS aspects from a business point of view. Where QoS might be equated to performance

BPSS also needs to deal with higher level observable behaviour that may not be bound to WSDL - indeed it might describe human interaction as part of a BPSS description.

SRT suggest that BPSS could sit atop of WS-CDL and might be a user of the abstract WS-CDL that has been proposed in the current overview document.

MM agreed that this was a possibility

Requirements Document

Req Doc http://lists.w3.org/Archives/Member/member-ws-chor/2003Dec/0005.html

Spreadhseet: http://lists.w3.org/Archives/Member/member-ws-chor/2003Dec/0032.html

SRT's latest text http://lists.w3.org/Archives/Member/member-ws-chor/2003Dec/0021.html

we shall subst "semantic transaction" for "collaboration"

Tony: A Choreography is interactions + collaborations

In the afternoon we finished up the BPSS liaison from Monica

then went on to the Requirements document dated 3 Dec 03 - see URL above

Went through Reqs doc starting at section 2.2

Discussed 2nd para

Jeff M suggested deleting, but Steve defended including something on using for testing

SRT: A choreography description may also be used to aid the testing of participating Web Services through the generation of test messages that could be sent to participants by means of an appropriate vendor specific tool that reads the choreography description and manages the test interaction according to the choreography description.

clarify that the Web Services are participating WS in the specified choreography

SRT: core use at the head of the section

Agreed to clarify and retain

Add a paragraph or two on the core use of being a vehicle for developing, agreeing sharing choreographies between parties

Steve captured paragraph with help of the group

Head of sec 2.2: The main use of a choreography description is to precisely define the sequence of interactions between a set of cooperating web services in order to promote a common understanding between participants and so make it as easy as possible to automatically guarantee conformance to ensure interoperability increase robustness and generate code skeletons.

Para 2.3

Remove the number of uses in the first line

Combine 2.3 and 2.2 with current 2.3 text on benefits coming first

Top benefit is to promote a common understanding between WS participants

s/nnn/mmnn/ in sec 2.4

Section 3

Remove section and add text at the end of the Introduction (section 1)

Section 4 Use cases

Delete para under 4 and last para of 4.1

Remove section 4.1 heading

Section 4.2 Objective is to move D marking (draft) to C (Candidate)

Ed and Tony previously sent emails (to Steve and Abbie) to the public WS-Chor list


Add concurrency and sequence req in second example


Need some way of going back to a defined state - also need to say need to 'confirm' progress and move on

DavidB: Hello everyone ...

Comments on Req 1 (and potential 1 a) in Tony's comments

Tony's new figures are in http://lists.w3.org/Archives/Public/public-ws-chor/2003Dec/0081.html

Sorry should have been section

New requirement need to demark transaction boundaries

of collaborations

These reqs are about providing guidance to the underlying infrastructure

UC-001-O-R-07: Need transactional boundaries to facilitate the integration of various transactions becomes:->

Need to demarcate transactional boundaries in order to define the collaboration boundaries in order to provide guidance on the underlying infrastructure required to implement the collaboration.

UC-001-O-R-07: Need transactional boundaries to facilitate the integration of various transactions becomes:->

Need to demarcate transactional boundaries in order to define the collaboration boundaries in order to provide guidance on the underlying infrastructure required to implement the collaboration.

Section Variation 1

Add note that CDL does not specify the form of the comments. Change fully to further in text above the 2 Reqs

Use in order to supplement the description of the choreography

Variation 2

This variation is supposed to call out information sharing and hiding Ed has recommendation for another requirement

Add Ed's text from email

Note that transaction boundaries and composition boundaries may not be the same

Remove the word hierarchical in this section

edp: The email I referenced uses the word "hierarchical" -- editor beware

Variation 3

Exceptions are not generated by the Choreography itself

Participants and Choreo engines can raise exceptions

To be able to send a message then that message must be part of the choreography

Add default exception handling behaviour facility as a req and hence into the language?

Variation 4 Move req from main Use case to here

Merge req here with previous one

SRT: the old is "A CDL shall facilitate the demarcation of observable transactional behaviour"

17:03:21 [scribe]

Change text 'during the confirmation step' to 'when confirming the travel itinerary'

SRT: The new is "A CDL shall facilitate the demarcation of observable transactional behavior in order to define collaboration boundaries and provide guidance to the underlying infrastructure (i.e. to recover, replay messages etc)

Make text after Req 1 in Variation 4 into Variation 5 and increment subsequent variation Nos

Propose new req on variation 4: Need to be able to model retries and timeouts and the taking of one path if a retry succeeds and possible a different one of timeout expires etc.

Variation 5 (old number scheme)

In change 'mechanism' as that is out of scope

Intent is that should be able to express QoS type requirements in the language on underlying mechanisms

UC-001-V5-R-00: There should be a binding mechanism to enable a choreography to bind to differing QoS as applied to messaging and to differing correlation mechanisms. BECOMES UC-001-V5-R-00: There should be a means to describe the differing QoS as applied to messaging and to differing correlation mechanisms that a choreography requires.

Change the previous requirement into two, one for QoS and one for Correlation

s/keys/mechanisms/ in same section

First Use case approaching readiness to convert from draft to candidate

Second use case Section 4.2.2

Issue we want to be compatible with WSBPEL but they are building on WSDL1.1 whereas we are targeting WSDL 2

This use case requires number of replies can be same or less than number of messages sent out - can WSDL support this?

Same message sent out to a number of different parties

In use case 2. s/fixed supplier/supplier/

Intent is that some types of parties may not have a fixed number in the Choreo description but only fixed at runtime of an instance of the Choeo description

Issue: support of multicast in WSDL

4b change relevant to respective

Req 2 Keep here but change for flights to manufacturers and suppliers

Each individual interaction may have its own timeout or apply a timeout to a set of interactions

ISSUE: If we have variable timeouts on individual interactions then where does the value of that timeout come from? Is in something that is looked up and bound? Is it something that is computed?

OLD: UC-002-O-R-00: The ability to repeat a set of interactions is needed. The interactions between supplier and manufacturers need only be defined once and then repeated for each supplier manufacturer interaction

NEW: UC-002-O-R-00: The ability to repeat a set of interactions is needed. The interactions between supplier and manufacturers need only be defined once and then repeated for each respective supplier manufacturer pairing.

Steve summarised remainder of doc to gauge time for tomorrow.

Meeting concluding for today - thank you folks - see you tomorrow

Day 2

SRT: Requirements doc comments cont

Martin: Do we need to emphasize BPEL?

Monica: i agree

09:22:12 [scribe]

SRT: sub/abstract WS-BPEL with/code skeletons for WS

s/with a WS-BPEL plug-in// req for var-1

s/needs to participate/may be used/

s/needs to be able to participate/may be used/ - on second req

Monica: use-case does not support generating abs-BPEL

Martin: taken care by sub BPEL with code skeletons

Martin: var-2, what does it mean?

MC: If we don't finish the requirements today then we may need to have a dedicated conf call to finish this.

This may imply an action at the end of this F2F

NEW ACTION: Steve/Martin to potentially arrange a follow-up for the requirement doc

See http://www.w3.org/2003/12/18-ws-chor-irc#T09-29-10

SRT: collapse var-2, 3 into one var

NEW ACTION: SRT to edit var 2and 3 consolidating the requirements and making the text fit the reqs.

Martin: 2 more use-cases to consider

Review of Marcos use case


Tony: i don't understand marco's re-written use-case

Jeff: +1

Martin: the pattern is a set of WS instances that all support the same WSDL interface, so that invoke one oper invokes the same oper on all instances in the set

Tony: how is this diff from use-case-2?

Martin: good observation; is there something more that just the factory pattern in addition to use-case-2 pattern?

Martin: how does this relate to choreo?

Nick: this use-case generates a req for creation and passing dynamic references (channels)

SRT: this is already captured

Martin: +1

Martin: is there another req?

We agreed that we thought we have already captured requirements from Marco in our doc.

Monica: but how about state that needs to be remembered, like a session you can go back (ie. EJB session beans)

Martin: right, it looks like a new req

Tony: marco, should look in the latst req-doc that chairs will distribute

NEW ACTION: chairs should also ask marco to see if his requirements are captured within the latest req-doc

When the “Individual State of an Instance is reclaimed” the history of interaction of such Instance is lost.

The Instance returns to a state that corresponds to a newly created Instance.

The reclaim operation can be initiated either by the User or by the Parent or by the Instance itself depending on the specific choreography.

NEW ACTION: this is the text chairs should use to inquire from marco new reqs, get clarifications

EAI Use case

SRT: anything new in the EAI use-case?

SRT: if choreo is just type why do you want to propagate exceptions?

SRT: if exec then there shouldn't be any propagation

Nick: should there always be explicit modelling for propagating exceptions?

Monica: there is a req that exception info is properly tagged

SRT: if there is something wrong that interrupts the choreo, then should we understand more details of exc messages?

Nick: we should not preclude explicit and implicit modelling of exceptions; right?

Monica: exceptions are not the same as error

Martin: you can not really say the difference from the observable point of view

Monica: i agree with nick

SRT: this is an issue to be recorded and resolved later

Martin: reqs: alter-path, default-exception; we should check if some other req is missing

SRT: observable exception propagation & mgmt should be somewhere in the issues

NEW ACTION: record exceptions/errors as an issue

Martin: monica's req is alternate paths based on non-observable decision

Nick: there should be two reqs: external & internal choice should be supported

NEW ACTION: log as an issue is fork/join covered as requirements

NEW ACTION: log as an issue if external/internal choice is covered as requirements

NEW ACTION: steve as an editor will organize a call for the req-editors to review the reqs doc

Nick: ws-choreo model overview doc is missing the external/internal choice

Nick: oracle's original proposal had this construct as a reaction-choice-group which is not the same as the choice construct in the model overview doc

Liaison – Overview of WS-CAF

Mark Little gave an overview of WS-CAF (slides to be included in minutes)

(srt) where's the boundary and what's the relationship b/w WS-CAF and WS-Chor

(ml) we saw WS-CAF as infrastructure; BPEL assumes it but it doesn't exist

(ml) I've been focused more on BPEL, but this could be an infrastructure that WS-Chor builds on

(ml) CAF defines a stack of functionality; CHOR could sit sort of to the side

(ml) you could use transactions, or you could directly use context

(mc) we've discussed whether or not there's such a thing as a choreography coordination protocol

(mc) you have to decide which reliability mechanism, which transaction protocol, etc.

(mc) some people may think CHOR shouldn't make decisions on that, so we could use any

(srt) if choreography never binds to anything, it's perfectly interoperable

(tf) there are 3 ways to get interop:

(tf) (1) one standard way of doing things (WS-I is taking this route)

(2) standard way of starting a conversation, and then negotiate options on the fly

(tf) this allows for controlled failure or success

(tf) (3) ebxml way -- lots of different options and you have a separate agreement for a particular process

(tf) you can configure your systems for interoperability among these options

(gary) do we have to treat a coordination service any different from another web service?

(mc) this gets to: are there any implicit messages around? things participants need to understand?

(gary) couldn't your tools understand this, and hide the fact of these built-in services

(mc) we could work on one or two of tony's options: language doesn't assume particular decisions

(nick) if you look at the global model, the way exception handling is managed

(nick) if you fault on the child, does the parent know? does the parent exit?

(nick) if you have to propagate this information, you need a coordination protocol

(gary) if you model the coordination as a web service, then everything is explicit

(nick) if you do that, you'll get uncoordinated

(nick) the language won't know what to do -- you need to know what happens when you fault

(mc) this might actually be one of the bigger issues as we detail the language

(mc) you can't just sort of plug in any transaction model (e.g.) and expect that language to match

(mc) how constraining that is on protocols is an open issue

Specification Document

(srt) next item: discussion of language specification (model overview document)

introduction of robin milner as an observer to the meeting.

(nick) this is the outcome of joint work with myself and david burdett

(nick) at chicago F2F, david (commerceone) submitted a proposal language

(nick) three months later in seattle, oracle submitted WS-CDL

(nick) so we got together to see how we could propose a common model, merging our ideas

(nick) we have right now four editors: myself, david, greg, and yaron

(nick) the model overview is the result of the last several months' work with myself and david

(nick) the bulk of the meta-model here comes directly from the original oracle proposal

(mc) it's important to avoid dickering over XML syntax right now, and focus on large concepts

(nick) all the interesting things need to be fleshed out: exceptions, visibility, etc.

(nick) the goal of the model is to model interactions b/w autonomous processes

(nick) these could belong to the same organization (domain) or separate

(nick) there are surely legal differences between the intra- and inter-domain cases

(nick) but we won't address those; for the most part, we think they're the same

(nick) we've chosen a global model where we see the composition of the entire system

(nick) rather than describe individual participants and magically combine those descriptions

(nick) this was decided at the chicago F2F to be an important part of our mission

(nick) the second intention is to be able to cooperate and leverage existing specs

(nick) in particular the BPEL spec-to-be, and specifically the abstract model it defines

(nick) this is the single-participant endpoint definition

(nick) hopefully this can be generated from the choreography definition

(nick) this applies to two-party situations, or multi-party situations

(nick) choreography is able to model multi-party situations by composing single-party

(nick) the focus of the oracle proposal was primarily web services

(nick) the commerce one proposal was more abstract, with fewer assumptions

(nick) the resulting combination includes three layers (abstract, portable, concrete)

(milner) what do you mean by participant? is this an individual, or could it be a domain?

(milner) could you define this at multiple levels?

(nick) a participant describes what sorts of services are made available (e.g. buyer, seller)

(nick) it doesn't have to be a computer, it could be a user

(milner) could a group of participants take a role?

(mc) as long as it's described by a single interface

(tony) my answer: several different participants could have the same type of role

(tony) but they'd actually perform different work in the process

(nick) there are no relationships between participants, to group participants or name them

(tony) is it true that you could have a type of a role, and a particular participant filling a role

(tony) of that type, and every time you run the choreography, you get a different instance of that

(tony) example: distributor -- as a distributor, I have a buyer-facing role, and a supplier-facing

(tony) role; the buyer fills a role (X) with respect to the distributor, and the distribute fills a

(tony) equivalent role (X) with respect to the seller

(mc) maybe we should let nick continue, and come back to this

ISSUE (from tony fletcher): can we do role types?

(tony) what's the formalism for the diagram symbols?

(nick) entity-relationship

NEW ACTION: nick or dave to send latest Visio diagram to list

(nick) a choreography is the unit of reusability; it packages interactions b/w participants

(nick) a choreography contains 0 or more sub-choreographies

(nick) in this way you can have local definitions (like inner classes)

(nick) the "perform" activity can invoke a choreography

(nick) there's also a block for defining variables and documents

(srt) so is this hierarchical nesting?

(tony) the oracle submission had an outer choreography, and embedded choreography

(nick) yes, you could do this in two ways

(nick) in the new model, you use a "perform" activity and invoke a nested choreography

(nick) I'd prefer to be able to do inline choreography definitions

(mc) the sub-choreography is not a choreography in its own right?

(nick) right, it's not usable or visible outside the outer choreography?

(srt) can I have a choreo that calls another choreo?

(nick) yes, this is also using perform

(nick) the choreography is just a way of scoping

(milner) is there analogy between an object having methods, and methods creating objects?

(nick) yes, this is a good analogy

(milner) so you replace a "method creating an object" with a choreo performing an activity

(tf) a problem I'm having is reading an entity-relationship diagram

(mc) the sub-choreo there is more of a syntactic scoping mechanism

(mm) an interact begins to pin down details of message exchange; this should be broken out

(tf) why does a choreo have a recovery block?

(nick) it has a normal block and a recovery block -- think of it like a scope

(nick) this is where you recover from failures

(tf) why is it at this level?

(mc) each choreography can have a top-level block for error recovery

(tf) the way things normally happen is that you have one or more steps, and then decide

(srt) but if you want a semantic distinction (readability), you don't want to mix error and normal flow

(tf) disagree: you want to show control logic

(nick) you can always have an if-statement after each thing you do

(nick) exception propagation is missing from this model; the semantics are missing

(nick) recovery blocks are optional; you can always avoid using them

(mc) each choreography has a main flow and an alternate flow

(tony) my point: discussing that at the intermediate level is fine, but at the overall level it's not

(tony) equivalence with BPEL is misleading, because it's single-participant

(tony) a choreography is going to involve multiple partners

(nick) we're looking at mapping CDL to BPEL, and believe that introducing a recovery block at the

(nick) global level of the choreography solves some important problems; it creates a template that both

(nick) parties need to follow

(nick) we're defining a model that allows you to knit together multiple BPEL processes

(srt) clarification: when we use the term recovery block, under what circumstances does it become active?

(srt) and how do I bind those exceptions, where do they come from, and so on? if it's optional,

(srt) I need to understand how the binding mechanism works.

(nick) a recovery block means backward or forward recovery; it doesn't necessarily mean compensation

(nick) this will apply when we talk about work units later

(nick) a normal path is define under the base choreography

(nick) it consists of work units (used to be called reactions), think of them as business rules

(nick) work units have guards, which must evaluate to true before the work unit is evaluated

(nick) there are two conditions on the work unit: "enable" and "reenable"

(nick) it can be reregistered for repetition

(mc) according to this, a work unit can have one activity?

(nick) yes, if you need more, you need to use complex activities (sequence, parallel, etc.)

(gary) at last F2F there was discussion of event calculus and process calculus etc.

(gary) what are pros and cons of this approach vs. different calculi?

(nick) good question: I think of business rule as match rule in basic process calculus

(gary) it makes the nature of the specification very reactive

ISSUE: how does the WS-CDL model compare to formal calculi?

(gary) specific issue: reactivity to state is very different from reactivity to events

(tf) back to activities: I thought one particular activity could go to one work unit

(tf) then activity is redundant -- you could do away with activity

(nick) but workunit has guards, enable, reenable

(nick) if you say that guards are optional, then workunit becomes activity

(nick) most important activity is probably interaction: interchanges information

(nick) interaction is from a role, to a role, within a relationship

(nick) (you can have more than one relationship b/w two roles)

(nick) data is moved from one role to another, and becomes visible to target role

(nick) variables belong to roles -- this means there is NO distributed state

(nick) state is born in a particular location, and is made available to others through interacts

(nick) partial alignment between states happens through interacts

(nick) actually, alignment doesn't necessarily happen: you have a guarantee that data was consumed

(mc) where would you annotate that you want to assume that state was copied?

(mc) from an interact perspective, is there a need in the language to classify interacts?

(nick) I think there is a need to deal with QOS?

(srt) where does request-response fit in here?

(srt) you could argue that if you don't care about consumption, one-way is the thing

(nick) request-response is for sending business information back (two-way alignment)

(mc) request-response here isn't necessarily as WSDL request-response

(nick) interact is broken in many ways; not really atomic

(mc) request-response at a business level could be implement with WSDL one-ways

(milner) it seems like three levels: sending messages, optional acknowledgement, optional response

(milner) do you need all three?

(milner) it's the first level I question: a message with no acknowledgement at all

(nick) the language doesn't force you to use an ACK

(mc) we're basing the language on WSDL 2.0, which has message patterns including no ACK

(nick) the interact doesn't stop at the messaging infrastructure, it goes into the participants

(mm) wrt milner: the business level defines what messages are needed, and what they mean

(mm) these are business decisions which are dictated to the choreo

(tf) we have role here, can we have role type?

Tony would like to register issue wrt Model Overview diagram: Why does roleType not appear explicitly

ISSUE: Why does roleType not appear explicitly?

Nick continue to explain the document

(nick) a role could be one or more interfaces that a participant supports

(nick) you can have more than one relationship per pair of roles

(nick) we're thinking about allowing things like QOS attributes on relationships

(nick) this could supplant WSDL features + properties, if they aren't added

(mc) does participant show up in the language?

(mc) i.e., do you declare participant in the language?

(nick) this model alludes to this facility, but we haven't gone that far

(mc) example: Seller is Coke and Buyer is Sainsbury's

(milner) will it make sense to consider that there is only one role?

(milner) that is, a degenerate system where you don't distinguish between participants

(milner) a bit like the notion of type in programming, where you ignore type entirely

(mc) it comes down to prime audience; we think of a business audience

(mc) you could "focus on the messages first"

(milner) not thinking about restricting to one type of role, but rather ignoring differences

(nick) in an abstract choreography, you simple describe a role in English

(nick) this doesn't get fleshed out until you go down a level

(milner) I want to define channels and perhaps messages, but not roles

(mm) a partner exists outside a role and a process

(mm) when you attach it to a process, it takes on a different identity

(tf) don't see how the structure of a choreography works, like to see one written out

ISSUE: (mm) existence of partners outside a process, and how that affects a process

(tf) also, sub-choreographies don't make sense the way they're presented

(mc) maybe it's placing too much importance on the model

(srt) what's actually in a sub-choreography definition?

(nick) it's like an inner class -- a fully-featured class that is defined within another class

(nick) it's just a definition, the same way you define a variable

(nick) they're choreographies

(mc) this looks like a problem with a diagram

(mm) when you say a sub-choreo, is it dependent on the choreo?

(mm) does it assume the same characteristics of a choreo? which takes precedence?

(mm) can the inner only exist if it has a parent?

(jeff) lexically, or at runtime?

(mm) does a sub-choreography return back to the parent?

(nick) these are lexical constructs, not runtime

(nick) the perform construct exists to make use of nested choreographies

(mc) you can use import to reuse somebody else's choreo as a child

(nick) no you can't; you can't import a child

(tf) is the recovery block a pot of useful definitions that I can pick off when doing recovery?

(nick) yes

(tf) under figure 3, p. 11: "... and sequence in which it is exchanged." what does this mean?

(mc) let's not wordsmith; this is a very rough draft

(mm) with sub-choreographies -- you could have an inner and outer, with the outer going

(mm) while the inner remains

(jeff) again, we're confusing the lexical and runtime behavior: you can't necessarily infer one

(jeff) from the other

(jeff) what a program does is indirectly related to the lexical structure

... moving on ...

(nick) a workunit is an action that is taken

(nick) workunits have enabling conditions that register interest in information

(nick) when the enabling condition becomes true, the workunit becomes active

(nick) once it completes, if there is a repeat condition, it's evaluated

(nick) if the repeat condition is true, the workunit is "rearmed", but doesn't execute

(nick) again until the enabling condition is true again

(gary) if you have a choreo that's dealing with two suppliers concurrently,

(gary) are there issues dealing with duplicate state variables

(nick) the guard has to look at state information and then matches, so the question becomes:

(nick) where does the state information live?

(nick) states live at the instance of a role; they are not shared

(tf) can a participant share or see state in one of its roles?

(tf) i.e. if a single participant plays two roles, can it share information between them?

(nick) interesting question, depends on visibility of state

(tf) if not, playing piggy-in-the-middle (e.g. buyer-distributor-supplier) is impossible

(nick) information becomes available only through interacts

(nick) having a guard with information from role1 and role2 is impossible

(tf) wrong mental model; think about one thing in the middle, sharing state internally

(mc) moving state between those two roles would be a private matter, as a participant

(mc) something happens internal to you that communicates these variables

(tf) it comes into play when I'm writing guards

(nick) we have to have some rules with this, otherwise it won't be possible to implement

(mm) you have a distributor who acts as a buyer and a seller; the visibility of data affectsd

(mm) how the multi-party collaboration proceeds

(nick) can we capture this in the requirements document?

(tf) although state is captured at a role, it's really a property of a participant

(mc) does a participant manifest itself directly within a role?

(tf) a participant is a single place

(nick) what does this mean?

(mm) use case: buyer-distributor-seller

(tf) this is a choreography that involves three participants playing four roles

(tf) buyer plays buyer, seller plays seller, and distributor plays both

(milner) we do have some solutions to offer here

(milner) process calculus defuses most of this

(milner) it may not be what you want, but it might be very helpful

(mc) this is interesting from a choreography perspective

(gary) this is only a problem if you're actively participating in the choreography

(gary) if it's passive, it's not important -- you define the choreography, and then

(gary) each participant does what they need to do

(nick) question: do you want the ability to define the guard based on the content of documents

(nick) that have been exchanged (data-dependent behavior)

(nick) if we don't do this, this whole issue goes away

(ep) outlined an extension of the mm usecase such that the initial send from buyer to seller has nested related send and receive to the next seller. That is A sends to B then B sends to C waits for C to return a receive and then does the same from B back to A.

(milner) from our perspective, the difference between two one-way and one two-way send it unimportant

... skipping imports ...

(nick) quite a few problems with import, probably a longer discussion

(nick) we tried to create placeholders for issues, which need to be figured out

(nick) an interaction happens from one role to another role (it's directional)

(nick) an interaction takes place on a channel variable (specifies where & how it's sent)

(nick) if you specify that you want state alignment, you guarantee that the

(nick) two state variables on each side of the interaction will be the same after the

(nick) interaction has completed (an agreement protocol)

(tf) given that you have a relationship between two roles, why do we need channel?

(nick) the relationship is a static binding between two static entities

(nick) for instance, you can have a "Seller" as a role, but then a channel to "Amazon", "Sears", etc.

(tf) so it's basically an instance of the role

(nick) we want to make references a first-class citizen in this language

(tf) what is the relationship between channel and relationship?

Feedback from Robin Milner

(milner) there are places where we have solved similar problems, and it's worth mentioning them

(milner) our decisions may be wrong for you, but you can see

(milner) six things ...

(milner) (1) everything discussed so far as encompassed by the pi-calc, so there's nothing

(milner) strange or unusual. we're looking to impose a more refined regime onto the pi-calc, with

(milner) for example different notions of one-way and two-way messages

(2) it's worth separating the way you communicate the model within this community with the way you

(milner) communicate it to businesspeople. at this level, you might be able to put up with something

(milner) a bit more formal. in the pi-calc, we used syntax very thoroughly. for instance, you could

(milner) try representing a wholesaler as a parallel composition of roles.

(milner) I couldn't actually see what I'd want to represent as a location; perhaps you'd want to

(milner) represent a "clump" like the wholesaler like that.

(milner) You make the procedure description in this way, and then the runtime behavior is how things

(milner) like that turn into other things of the same kind, so your complete runtime state is always

(milner) represented in the same form throughout execution, and you don't need a separate state machine.

(milner) Perhaps the buyer-seller-distributer use case would be something we could have a go at in

(milner) pi-calculus, and see if you like it, and why not.

(milner) In pi-calculus, a program's state and it "program pointer" are one and the same.

(??) finite state machines can represent something with state, but this doesn't suffice

(??) pi-calculus completely does away with the represation of state, and has more power

(??) I decomposed regular pi-calculus into asynchronous pi-calculus

(??) then we noticed that there a basic structure to interaction, which can be understood

(??) but it's easy to check for certain properties: deadlock, compatibility

(nick) one thing to add: exceptions, and how they fit into a distributed environment, are important

(nick) solving exceptions and the consistency of state is as important as deadlock/livelock

(milner) I don't know how to solve exceptions, they're a very difficult problem requiring probably

(milner) more structure to represent the handler, the domain of the handler, etc. but this might be

(milner) more obvious within the framework of pi-calculus

(??2) a couple more technical comments

DavidB: I've just been reading the IRC log on today’s discussions and will post a few comments.

(milner) maybe channel naming could be consonant with the role naming

(milner) channels are the places where individual actions happen

(milner) and channels themselves are also data values, and can be passed, which isn't true for roles

(milner) maybe you could delegate roles to someone else by passing them a channel?

(??) each participant, does it have a unique channel? (NO)

(mc) so one way of modeling a callback is to create one channel for each callback

(nick) the role is a collection of interfaces; this is static information

(nick) the channel refers to this but also adds how to contact someone with that behavior

(tf) why do we need to implement this in the choreography language?

(nick) this gives you mobility and ways to connect participants

(nick) if you don't that, relationships will always be fixed

(srt) without them, you couldn't do use case 1, where you pass a connection to the credit card company

DavidB: On Import, Nick said "you can't import a child". This is true as it currently stands, although I think you should be able to import a child if you wanted to.

DavidB: On Import, Nick said "you can't import a child". This is true as it currently stands, although I think you should be able to import a child if you wanted to.

(aw) what I thought you were discussing here was a language for describing the structure of communication

DavidB: On Import, Nick said "you can't import a child". This is true as it currently stands, although I think you should be able to import a child if you wanted to.

(aw) identifying specific endpoints is necessary, but should be done elsewhere

(aw) do you think you're going to have choreos where you have indefinite numbers of partners?

(mc) at design time, yes; at runtime, you'll want many of them

(tony) maybe we're getting too detailed

DavidB: On Perform. I also think that you should be able to perform a choreography or any of its sub-choreographies. Think of the outer choreography as also being a container for choreographies. For example we've identified over 10 different choreographies that could be used for placing an order - they have many messages in common but they are different. You could put them all in one outer choreography and then just reference them

(mm) gets back to question of separating description from instantiated choreography

(tf) a key thing is a participant instance identifier: this is what you need to pass around

(jeff) that would be a web service reference

(mc) and channel is an abstraction of that

(nick) and without correlation information, you won't be able to find the right process instance

(aw) here's my problem: all this functionality is already available

(aw) I thought the difference was to provide a notation for describing the structure of the interaction

(srt) web services don't handle this behavior currently

DavidB: On Buyer-Distributor-Seller. I would think of this environment as two totally independent choreographies Buyer-Seller between the "Real Buyer" (as a buyer) and the Distributor(as a seller), and the Distributor (as a Buyer) and the Real Seller as a Seller . If the Real Buyer and Real Seller don't need to interact in any way then there is no point in describing a choreography that covers all three. In this case the distributor can use state information from

DavidB: More on Buyer-Distributor-Seller. Only if the Real Buyer and Real Seller need to interact with each other do you need to have a single choreography that covers all the roles.

ISSUE: Probably already in the issues list, but here it goes again. If we choose to have a specific relationship to WS-BPEL and we, by charter, need to be based on WSDL2.0 then we have a mismatch since WS-BPEL is based on WSDL1.1

discussion started on recovery blocks, rollback and exception message identification

srt: what cause the recovery block to be used, as seen from an observer

srt: is the exception observable?

Nick: we need to revisit the passive and active choreographies

Nick: the big picture is legacy WS, active and passive monitoring, recovery, exception ...

Gary: passive monitoring is observing only and be able to confirm that interaction has been correctly executed

Gary: active monitoring take part in the choreo and can direct things

Gary: for the active, the participant have to be able to understand and carry extra information related to that

Gary: we have to have a passive option to handle legacy WSs, and we can have also an active one if needed

MC: can't see anything in this doc that require active monitoring

nick: information move with interaction, the idea of reacting to state is what you talk about?

nick: what legacy WS mean?

MC: to me legacy WS is everything written before our spec

tony: passive is a way to go, if we can't do passive we can't do anything. there should be the potential to go further (active part)

tony: a CDL where a participant is driven by the CDL should be possible

tony: maybe a requirement

monica: if we take the passive approach, we need to define what a cdl is (testability, policing...)

Kohe: extreme case, active enforcer, all transaction between set of agent is modelled, judiciary process. if something wrong happen it would prevent it to happen

MC: no need to add extra information for auditing is needed

Kohe: extremes are single verificator of by message passing with one saying 'stop'

SRT: wrt legacy. Charter says WSDL 2.0, so no legacy services exists. If we decide to build only to WSDL 1.1 then we don't require BPEL

Jeff: when companies will use it, early implementation will use also wsdl 1.1 as wsdl 2.0 won't be done.

nick: the only contract that exist now is wsdl

mc: even if everything is well defined, a 'bug’ can happen

mc: so you need to monitor what happens

ed: in traditional WS, you will get an exception if things fail

(even if not defined in the cd)

gary: legacy ws will behave like before. what matters is a ws built to follow a cd and start to behave in a different way

kohe: do you want to have a monitoring component for each participant or a monitoring endpoint?

gary: exception handling is a local participant issue while (nick) think it may be global

nick: if there is an exception, what needs to be done to get to a coherent state?

DavidB: Although exception handling is always done locally. Participants might want to agree, through the choreography, how they will interact when specific types of exceptions occur. This is why there is an exception block. If no interactions occur between the participants when an error occurs then you don't need the exception block - can someone read this out please ;)

srt: the issue is about the use of a choreography, you can use a choreography afterward to test that the exchange conformed to that cd

DavidB: You can also use a choreography at run time to validate that the sequence of messages being exchanged in the correct sequence. If separate monitoring software is doing this, then it removes the need for the web services to include the logic as appropriate exception handling will occur - as defined in the choreography block.

ed: I can use exception handling internally and it's ok. if I have an exception in fulfilling your order I have to notify you. In bpel, everything is shared unless declared private (between scopes). in distributed processes it's the opposite it's private unless shared


ed: tight and loose coupling are both valid depending on the scenarios

tony: should we need to add transaction marker?

Srt: The minimal bar of entry for participants and their choreography is describing their external observable behaviour without any form of state management or alignment in that description.

MChapman: this is back to the CSF: easy things should easy, and easy means (possibly) no state alignment for example

Meeting concluded for the day.

Day 3

Review agenda against progress

SRT: Haven't done tools. Haven't done hot topics

Move to discuss issues raised against editors draft of specification and then continue through to planning before finishing the meeting.

SRT: Working group agreed (consensus) to move the specification document on WS-CDL to become the groups working draft:


MChapman: add links to editors draft on the public web page

NEW ACTION: Yves to add editor's draft on the public page

NEW ACTION: Chairs to table discussion of Choreology contribution for a Jan conf call.

gary: state is not just a message. if there is additional data on the message to sync data, the other end has to support this

nick: alignment is different than this

nick: do you want to remember state

gary: extra data implies a choreography protocol and will prevent web services that dont understand this protocol from being used in a choreography

martin: there is no assumption on a choreo protocol; a message is a message

gary: what is state alignment then? just message exchange?

nick: reading 3.5.6 of overview. maybe a requirement that the two roles agree the outcome (i.e. or are synced) after an interact

nick: two levels message alignment and state alignment.

message alignment is that a doc has been sent from a to b and both a and b know they have the doc with the same value

state alignment both parties know what state the other party is in

gary: why do we want alignment

nick: without it what do we have?

nick: looking at each roles state machines doesn’t give us much its where the two state machines meet that is important. this is the essence of pi-calculus

gary: async pi is more relevant here

nick: async pi, sender does not have continuations

gary: want to be able to model how systems work not impose things on systems

nick: gives a quality of service

nick: have a requirement that can support synchronization is good for customers

SRT: if i decide i want to model choreo with state alignment i have a doc with these definitions, what do i do with that document

nick: unless participant is aware of responsibilities all bets are off

martin: maybe you got the contract wrong

SRT: they are work correctly what do you do with document?

martin: don’t have to do anything with it

nick: if you want to force alignment need something that understands the protocols

SRT: say web services are running what over and above can that doc be used for in the runtime?

jeff: docs don’t do anything. could throw the choreo doc to an analyzer that has logged messages and see if the messages conform to the choreo

tony: not just passive. active use could feed to an interpreter

SRT: why i asked the questions .... trying to be crystal clear what the benefit if state alignment is

srt: helps you build more interoperable web services

SRT: if it does that it has served is prime function

jeff: conceptual model take choreo, fed to some processor, derives the skeletons for the participants, fill in the details, debug etc, and you get working system

srt: have a concern related to legacy

srt: have to deal with wsdl 1.1 services

srt: have a bottom up usage as well. What’s the minimum to bring it up to speed

srt: what the lowest bar of entry

jeff: legacy bad word, any service not designed with choreo in mind

martin: talking about interoperability as a group, not just point to point. have to obey sequencing and ordering otherwise might have knock on effect down the line hence affects interoperability

srt: any legacy web service is not locked out, but may have limited use in a choreo

srt: may have to wrap to fully take advantage of that ws in a choreo

tony: write a new party that acts on behalf of an existing ws

nick: top down vs bottom up. global model is very related

nick: global is really top down

srt: nub of this issue the bottom up approach

martin: how is global related to top down vs bttm up. Doesn’t matter how it is arrived at

jeff: minimum requirement for participation is its a web service

no need to understand any special protocols above and beyond soap and wsdl

nick: what’s the value of choreo description with an existing web service

jeff: can use for checking/testing

nick: what about policing

martin: any participant can use a choreo definition to monitor whether other parties are obeying the choreo

srt: the choreo defines the common understanding

nick: we want to be able to generate the abstract interface

martin: agreed

nick: what languages

martin: cant generate executable code only skeletons

using the word abstract interface and skeletons in the same word

ed: there may be a difference between code skeletons and generating abstract bpel

martin: no difference from a choreo perspective whether a tool generates abstract bpel java skeletons or c++ skeletons or....

tony: what happens if you cant comply with the choreo, it is a banana?

gary: all we do is declare behaviour, implemented in the web service

srt: have we covered the legacy web service issue?

martin: yes but we need to ensure that it is covered in the primer

ISSUE: put discussion in on legacy web services into primer

srt: state alignment issue

srt: since it is optional there doesn’t seem to be an issue

gary: view it like a qos level issues is ok

mm: make optionality very clear, and make sure the implications are well known

srt: state alignment issue close as it has been clarified

srt: recovery blocks issue not covered, but discussed at dinner last night (the banana conversation)

gary: look at van Der Aalst cancel pattern wrt to recovery blocks

ISSUE AGAINST Nick/Dave’s DOC: How do recovery blocks and their transactions and exceptions become enacted and bound (i.e. what exception and what transaction)

NOTE: We should look at the van de Aalst CANCEL pattern

ISSUE AGAINST Nick/Dave’s DOC: Why (pros/cons) does the design of a WorkUnit use a guard mechanism which has data dependencies as opposed to a process algebraic approach of channel availability.

ISSUE AGAINST Nick/Daves DOC: The description of a choreography should be separated from the where/how it is used in order to promote reusability

nick: is there a need for an intermediate "language" that projects a single participants view from a global modal a sort of wsdl ++

gary: wont this compete with abstract bpel and didn’t we agree not to do this

tony: just give people the whole choreo description and let each decide

nick: assume we have abstract bpel, but it is missing things that to be able to generate a single participants view of a global model

NEW ACTION: Nick to define the features required of an intermediate end-point language


next immediate steps

next con call devoted to finishing off to reqs document

call after that on the working draft

chairs can you ask Dave to send his visio file of the WS-CDL meta-model to you/group?

the diagrams are a bit confusing: few understands notation

consenus of group to recast into uml class diagrams,

NEW ACTION: convert ER diagrams into UML class diagrams

after discussion will discuss the requirements on the 13th and Working draft discussion on the 20th

concall on the 6 maybe be used for the reqs editor

no con call on 23/12, but will be used by reqs editors


need to decide how many docs we need to produce, table of contents etc

NEW ACTION: editors to propose documents and table of contents

Next F2F in South of France March 1st and 2nd – our meeting restricted to two days as

plenary session day is the 3rd.

see http://www.w3.org/2003/08/allgroupoverview.html

Jun/Jul F2F Monica Martin has been asked to host on the east coast USA

Probably Boston, Monica will confirm

NEW ACTION: Monica to confirm hosting east coast and propose a date.

We shall aim for a far east venue for the Sep/Oct F2F and will look for potential hosts

NEW ACTION: Chairs to look into a far east meeting in sep/oct

Nov/Dec F2F somewhere in the USA.

NEW ACTION: Chairs to organise an issues conference call in which the regular conf call is used with members to look at the issue in bugzilla (possibly the Jan6th conf call)

Open Floor on Issues

Discussion about intermediaries ......

MC: Soap as the notion of intermediaries whereas WDSL does not.

MC: If they are important in SOAP then why are they not visible in WSDL?

SRT: Are intermediaries important to us at WS-CHOR?

NEW ACTION: Chairs to write proposal for group in defense of f&p in WSDL.

MC: Until SOAP and WSDL resolve the issue of intermediaries we should not enter the debate

TF: Should be invisible as far as a chor is concerned

MM: ISSUE/QUESTION: How would we model/express delegation in our WS-CDL?

ISSUE: We need to consider bananas.

NEW ACTION: SRT to ask Honda/Yoshida if they would be prepared to be invited experts.

Motion to adjourn


Meeting closed

Summary of New Action Items

NEW ACTION: Chairs to communicate f&p requirement to WS-CG

NEW ACTION: WSDL MEP agenda item to be organised by chairs

NEW ACTION: Chairs to send formal request to WSPEL Chairs

NEW ACTION: Steve/Martin to potentially arrange a follow-up for the requirement doc

NEW ACTION: chairs should also ask marco to see if his requirements are captured within the latest req-doc

NEW ACTION: this is the text chairs should use to inquire from marco new reqs, get clarifications

NEW ACTION: record exceptions/errors as an issue

NEW ACTION: log as an issue is fork/join covered as requirements

NEW ACTION: log as an issue if external/internal choice is covered as requirements

NEW ACTION: steve as an editor will organize a call for the req-editors to review the reqs doc

NEW ACTION: nick or dave to send latest Visio diagram to list

NEW ACTION: Yves to add editor's draft on the public page

NEW ACTION: Chairs to table discussion of Choreology contribution for a Jan conf call.

NEW ACTION: Nick to define the features required of an intermediate end-point language

NEW ACTION: convert ER diagrams into UML class diagrams

NEW ACTION: editors to propose documents and table of contents

NEW ACTION: Monica to confirm hosting east coast and propose a date.

NEW ACTION: Chairs to look into a far east meeting in sep/oct

NEW ACTION: Chairs to organise an issues conference call in which the regular conf call is used with members to look at the issue in bugzilla (possibly the Jan6th conf call)

NEW ACTION: Chairs to write proposal for group in defense of f&p in WSDL.

NEW ACTION: SRT to ask Honda/Yoshida if they would be prepared to be invited experts.