minutes WS Choreography WG F2F 12-13 December 2005

Minutes of the W3C Choreography Working Group Face to Face Meeting
12th to 13th December at Oracle, London

	Primer is at: 
	8th Nov Minutes:
	Gary's slides on implementation issues are at:
	Marco's slides on formalism are at:
	Formalism paper is at:
	Agenda is at:
	IRC log is at:

*** Roll Call:
		Paul downey, BT, Web Services Guru, Chair of Xml Schema Patterns ....
		aimed at resolving interop issues wrt to exchanging schema elements.

		Adomas Svirskas: involved with ws-cdl at RAL and eu project trustcom
		Vilnius University, Lithuania.
		Marco Carbone: researcher at QMC doing the formal underpining of WS-CDL.

	Martin Chapman, Steve Ross-Talbot, Yves Lafon, Charlton Barretto, Monica Martin, Gary Brown,
	Kohei Honda, Nobuko Yoshida

*** Scribe: Gary Brown

*** Agenda Discussion:
	Move formalism after lunch

*** Action Item Review:
	2. ACTION: Exit criteria discussion for next week's conf call
	3. ACTION: SRT to reissue the TOC for the primer in light of out discussion at this conf call
	4. ACTION: Move parallel composition and modularisation subsections into Section 3 of the primer
	5. ACTION: WG Members to think about examples and volunteer to do some
	6. ACTION: SRT to add a "degenerate use of CDL" section to the primer
	7. ACTION: steve to update f2f agenda to move kohei to monday
Primer review:
	1 Introduction
	    1.1 Structure of the primer
	2 An Overview of WS-CDL
	    2.1 Using WS-CDL
	    2.2 Why use WS-CDL?
	    2.3 The Structure of WS-CDL
	3 Getting Started with WS-CDL
	    3.1 An Example
	    3.2 Interactions Oriented Design
	        3.2.1 Interactions
	        3.2.2 Roles
	        3.2.3 Relationships
	        3.2.4 Information Types
	        3.2.5 Tokens
	        3.2.6 Channels
	    3.3 Choreographies, Sequences, Choices and Workunits
	        3.3.1 Choreographies
	        3.3.2 Sequences
	        3.3.3 Repeating Workunits
	        3.3.4 Choices
	        3.3.5 Complete Example
	    3.4 Modularization
	        3.4.1 Choreographies and sub-choreographies
	        3.4.2 Performing a choroeography
	  ?3.5 Parallel and concurrent
	        3.5.1 Managing join conditions
	4 Advanced topics
	    4.1 Dependent Workunits
	    4.2 Advanced Channels
	        4.2.1 Usage
	        4.2.2 Channel Passing
	    4.3 Business exceptions
	        4.3.1 Exceptions
	        4.3.2 Exceptions as messages
	    4.4 Compensations
	        4.4.1 Finalizers and Finalization
	    4.5 Silent Actions and Conditions
	    4.6 NoActions
	    4.8 Isolation levels
	5 An EAI example
	6 Implementation considerations
	    6.1 End point projection
	        6.1.1 Java
	        6.1.2 WS-BPEL
	        6.1.3 Runtime Monitoring
	    6.2 WSDL
	        6.2.1 WSDL 1.1
	        6.2.2 WSDL 1.2
	    6.3 WS-Addressing
	        6.3.1 Channel representation
	SRT: Change is that we have moved Modularization and Parallel and Concurrent sections to Section 3 - 
	     these now appear as 3.4 and 3.5
	SRT: Three things to do for primer:
		1) Reorg of contents
		2) Adding degenerate use of CDL in primer
			we need a bit more detail of what actually needs to be done
		3) Reissue contents of primer

	Yves: does it (2) mean applying to alternative situation (e.g. human interaction)
	SRT: Main comments from 8th Nov Call as relating to the primer overall structure:

		* What not how. Today it is mostly how and not what.
		* Introducing the context and architecture
		* Purpose of the primer is to explain, in greater detail, the spec.
		* Targetting the business analyst is outside the scope
		* How fits things together is what we need to approach in the primer
		* We seem to have broad consensus that the primer is targetted to a software 
	  	  role in an organisation that wishes to use CDL or provide tools for CDL

	SRT: I need concrete suggestions for changes
	MC: Let us start by  review open actions for the primer in bugzilla

*** Issues Review related to Primer:
	2360: Semantics examples needed
	using RDF in an example

	664 add UML diagram - MC will do it

	663: marked as duplicate of 664

	566: Signals and business messages
	SRT - in CDL all messages have equal status
	MC: I think this issue is about business level semantics
	MM: Any difference will be handled outside CDL
	ACTION: Add text from 566 into primer about equal importance of application messages

	1503: Lists and arrays - how to handles situations (such as RFQs to variable number of participants)
	can be achieved by providing a set of examples of how to iterate over arrays
	ACTION: Provide examples for issue 1503 of how to use lists/arrays - bounded and unbounded

	1457: Relationship between participants and roles and how they should be associated
	and what constraints there are
	MC: possibly needs pictorial examples in Primer as opposed to CDL
	CB: This has implications for a number of CDL use cases

	1456: Duplicate of 1503 - but has resolution text related to lists and arrays using silentActions

	1455: Interaction Syntax - successul-sending and properly-received are not clearly defined
	SRT: need to go through lifecycle of an interaction
	MC: Anders issue - e.g. if sent in the post, then is legally binding - this is equivalent in CDL
	MC: Means that if want guaranteed send, then must use 'align=true', or else catch specific exceptions
	SRT: Though a good example of a multi-exchange interaction with different records and timeouts
	SRT: explain the lifecycle of the interaction.
	SRT: May also need something to explain what it means to successfully-send and receieve. Perhaps
	SRT: Using coordinated=true.
	SRT: Need to also explain what happens in the face of failures and how best to model them in CDL.
	ACTION: Add text to explain interaction lifecycle, and that exchanges are only guaranteed if align=true, 
		or else modelled to catch specific exceptions

	2360: Clarification about what relationshipType is used for and what its constraints are
	      Distributed Choice Problem: need examples of how to work around
	ACTION: Add pitfalls sub-section in Advanced Topics section, and include the distributed choice problem

	1177: Should reference tokens on channel type be mandatory - SRT thinks was withdrawn but may not have been documented

	624: Closed, as decided description in requirements doc should remain as is.

	SRT: RDF could be used for datatype mapping
	CB: Semantic Web Interest Group: http://www.w3.org/2001/sw/interest/
	ACTION: SRT to request CG to ask relevant group to provide example of using semantics in CDL 
		- why would semantics be used to annotate a choreography?

*** LUNCH ***

Scribe: Charlton Barretto

*** Formalisms:
	Marco Carbone presents formalisms for type checking, etc.
	Marco: How do we express Buyer's intiating session with a Seller through a channel?
	Marco: Buyer -> Seller : InitB2S(B2Sch).I
	Marco: Arrow: Direction of communication
	Marco: ChannelName: Name of session (InitB2S)
	Marco: in-session channel name: B2Sch - in CDL, these w/b tokens
	Marco: "." indicates sequencing, as in process calculi
	Marco: Conditionals - e.g. x =< 100 @ Buyer then {...} else {Buyer -> Seller: B2Sch<QuoteReject>.0}
	Marco: Note that the conditional branch is explicitly located at the Buyer
	In CDL - Buyer & Seller are waiting on own requests, but do not sync on them; therefore, they cannot guarantee order.
	Marco: Recursion: Where in CDL have WorkUnit repeat/until, pi-calculus provides recursion as well. Buyer->Seller: InitB2S(B2Sch).rec
	Buyer->Seller: InitB2S(B2Sch).rec X
	Buyer->Seller: InitB2S(B2Sch).rec {...} else {...}
	Marco: Recursion is a theoretically nicer operator
	Marco: Can encode while ([[...]] = rec X.if e@A ten I +O else 0
	Marco: End-point recursion - buyer/seller example
	Marco; Syntax of mini-CDL
	Marco: Semantics: Global - relation such that (o, I)->(o', I') whenever the whole system I, from a state o evolves to I' in new state o'
	Marco descrives the syntax and semantics of the end-point calculus
	Marco: Types: Types to ensure right kind of information flows through right channels
	Marco: Types: Types to ensure properties guaranteed by a type system
	Marco: Types: Types to help the designing process of a programmer
	Marco: Enriched Buyer-Seller with type checking
	Marco: Can manage lifecycle of session, where types specify the behaviour of the channel protocol
	Marco: Can refine this for deadlock detection
	Marco: Once write chor, something automatic that would check that InitB2S is of type X....
	Marco: Result: Subject Reduction: If have chor, and it evolves, it will still be typed (somehow)
	Marco: What this means: No RT errors, and that lineariyty
	Marco: linearity is maintained
	Marco: And there is no run-time error
	SRT: In CDL, you never lose typing
	SRT: If have system that's fundamentally well-typed, it is very difficult to have a rouge service attempt to exploit it
	Kohei: Better security
	SRT: If have run-time type checking, can narrow the scope of chors
	Marco: Algorithm - we're dvping algorithms for type inference and type checking
	Marco: Type inference: Check if a program is typable (and infering a type for it)
	Marco: Type checking: Checking if a program has a certain type
	Marco: Both are quite efficient: i.e. can be executed in practically polynomial time w.r.t. the size of the program
	Kohei: ML handles type checking efficiently, but in a linear fashion
	Yves: Points to 
	Marco: End-point projection: Take a choreography, want to know end-point system it models
	Marco: Have formalisation in this
	Marco: Only consider chors with no parallel operator
	Marco: Connectedness: A sequence is connected if the sequence transparently contains the actors involved (e.g. S = ... A->B)
	Marco: A->B : s <op, e y> =; if e@A then A->C : s1 <op1, e1, y1> else <A->B : s<op", e", y"> is connected
	Marco: A->B : s <op, e, y>' if e@A then B->C : s'<op', e', y'> else A->B : s<op", e", y"> is not connected
	Martin: Chose not to have such restrictions in CDL since disconnection implies multiple choreopgraphes.
	Marco: Encoding with connectedness
	Marco: Have encoding which leverages Connectedness
	Marco: Strong connectedness - e.g. S = SUMiA->B : s<opi, ei, xi>.S1 then Si are connected and top(Si) is in {B}
	An interaction I is strongly connected whenever it has the form Sx|...|Sk with Si connected sequences
	Marco: A->B : s<op, e, y> ; if e@B then B->C: s'<op', e', y'> else B->A : s<op", e", y"> is strongly connected
	Marco: A->B : s<op, e, y> ; if e@A then A->C: s'<op', e', y'> else A->B : s<op", e", y"> is not strongly connected
	Martin: This is analogous to a braided BPEL....
	Marco: Properties of strong connectedness: Onely ONE participant (leader) at the time is able to perform an outout (output enabled)!; the other are waitin gto perform an in input; Other operations are ONLY allowed between an output and an input - this saves on chattiness between parties
	Kohei: This is very promising, but can't say too much about it at this point ;-)
	Marco: End-point projection - if have 10 parties, none w/b blocked
	Marco: These properties keep things simple
	Martin: The idea is that CDL can handle these as well as other design patterns
	ACTION: Describe Connectedness/Strong Connectedness design patterns in CDL (assigned to who?)
	Marco: Another encoding: Flow encoding
	Marco: Generate code for each end-point
	Marco: Main observations: Encoding has no sync issues, simple encoding
	Marco: Main observations: It imposes restrictions on the global descs - however, most "good" business protocols may be strongly connected through some transformation
	Marco: Results: Theorem - for both encodings (original and evolved), the encoding can do all what the original can do, and the encoding does not do what is not expected from the original
	Marco: Conclusions: Formalised CDL-like prog lang; typing system based on sessions; translation algorithm for global to end-point; two encodings ready to be implemented; type system and algorithms for type checking/inference are (almost) ready to be implemented
	SRT: Still need slides :-)
	SRT: Would like working note part 1 to be done, and then publish part 2 separately
	Yves: Either publish as one or two notes
	SRT: Publish it as working draft in W3C format, then publish working note when more formalised
	Nobuko: Should be safe to say that we'll be ready to publish this work next month
	Nobuko: Preference to publish Part 1
	SRT: Yves can take Part 1 doc, apply W3C style; review by WG and Kohei/Nobuko/Marco; once accepted, publish
	Martin: The parts s/b titled appropriately....
	Nobuko to have Ph.D. lectures for students in Italy in July 2006 (6 days) on this topic - if we have collateral to present w.r.t. CDL, she would be happy to incorporate it
	SRT: Myself, Charlton, Nick, Abbie all have presentations that are available to be shared
	ACTION: SRT to send URLs to our public presentations to Nobuko for inclusion if desired in her Ph.D. lectures

*** Next: Steve's DEMO
	Demo was brilliant [by SRT of course .... ho ho ho]

**** Primer review of text
	SRT: We use the term business architect to mean a role played by a person such that they are responsible for extracting business requirements both functional and non functional and business processes (the structured ordering of interactions).
	A business architect collaborates with a systems architect to ensure that requirements and business processes are well formed and consistent.
	Monica: We need to enumerate the roles targetted by the Primer
	SRT: We use the term systems architect to mean a role played by a person such that they are responsible for mapping business requirements and business processes into a formal description of a system.
	SRT: A systems architect collaborates with a business architect to establish design principles.
	SRT: A system architect collaborates with a technical architect to ensure requirements and business processes are well formed and consistent.
	SRT: We use the term technical architect to mean a role played by a person such that they are responsible for mapping a system into a set of technologies that can realise a system.
	SRT: A technical architect collaborates to establish design principles.
	SRT: A technical architect establishes design constraints.
	SRT: Here are the roles we have enumerated
	Martin: How do these relate to our diagram (http://www.w3.org/TR/2005/WD-ws-cdl-10-20041217)
	SRT: I'm not keen on using the term "Business Analyst" here
	Martin: Maybe it makes sense to replicate some of this bit (Section 1 description/diagramme) in the Primer
	SRT: I feel a business analyst is very unlikely to use a chor tool without significant investment
	Monica: I see this more used by business architects
	Charlton: Business analysts will use Visio-like tools - simply to sketch out a process
	SRT: Sectin 1.2 describes this, as well as provides the diagramme
	Gary: Describing the benefits is part of describing what is a choreography
	Martin: I think the paragraphs in Section 2 are out of order
	SRT: The section s/start with "WS-CDL is...."
	Martin: We can just rearrange the text
	SRT: The first paragraph should read, "WS-CDL is an XML-based language that can be used to describe the collaborative protocols, such as business processes, etc...."
	Martin: The 1st paragraph is core, it should be moved down.
	ACTION: Move the 1st paragraph of Section 2 downwards (within Section 2)
	"WS-CDL is an XML-based language that can be used to describe the collaborative protocols, for example, buyer-seller-shipper, ...."
	Martin: We should move the existing 1st paragraph into Section 2.3
	Charlton: It flows well with Section 2.3
	SRT: Agreed
	SRT: the diagramme in 2.3 needs to be updated
	Martin: We need to talk more from the conceptual perspective, then go in deeper
	SRT: The difference between observable and non-observable doesn't belong in 2.3 - it should be moved to a new subsection of 3 (3.3, 3.4); 2.3 needs to be rewritten: diagramme s/n be here, and the text should bring out participants, roles, interactions, global view, no centralised control, no centralised variables, etc.
	ACTION: Move paragraph 1 of Section 2 into Section 2.3
	SRT: Getting started deepens into participants, roles, interactions, etc. with the sequence diagrammes - this seems the right place to have the more involved content t/b moved from Section 2.3
	SRT: Also, I would like to have the Primer visible on the W3C WS-Chor web site
	ACTION: Redraft Sections 1, Sections 2, and part of Section 3 for a more natural flow in the text
	Martin: How much do we want to say about Section 6 in the Primer, Implementation Considerations?
	Gary: Is it for implementors? Or for people designing choreographies?
	Gary: If so, what does it mean to have two different WSDL versions?
	Martin: Do we have something in mind?
	SRT: Not presently
	Gary: Why not leave it as a placeholder at present?
	Gary: We do have things to discuss here, though. For example, the only way to represent a channel is using WS-Addr
	Kohei: Can this not be done using URLs?
	Paul: URLs are opaque until you assemble them. Also we should not be using URLs but URIs.
	Yves: Acutally, IRIs
	Martin: Should we be sharing implementation knowledge in this document?
	Martin: Also, can we delete "non-normative" in the section headers? The entire document is non-normative
	SRT: I have a list of examples that I need - which pretty well describe all the things we need to be putting in
	Martin: The question is then, what is basic and what is advanced
	Martin: And what are shark-infested waters :-)
	Martin: We have to identify what categories example types fall into and why
	Monica: Do we want to tie into the formalisms?
	Monica: For example, join conditiosn will touch on type formalisms
	Gary: Why not have a natural evolution - basic to intermediate, then to advanced?
	Monica: (formalisms such as connectedness)
	Martin: Once we have the categories we can drop the features into appropriate levels
	SRT: Basic is like "Hello world!" - something one can just write in CDL longhand
	SRT: Intermediate is more using CDL for "real stuff" - things you really need to get benefit from Chor
	SRT: Advanced w/b dealing with wider notions of design patterns
	Charlton: In the advanced level we might want to touch on formalisms
	SRT: In each of the chapters/sections, there s/b a paragraph indicating that "this section is named X, because ...."
	For example: In Basic, these are the basics; in Intermediate, you can use this for "serious stuff"; in Advanced, you're really good at this
	Martin: If we can deliver this, we should be good
	SRT: The limiting factor is the examples
	SRT: For example, silent action vs. no action - since they're both non-observable, how can one write a good example of these?
	Martin: We actioned Nick to get some comments back on Kohei/Nobuko/Marco's paper
	(SRT, not Martin, spoke to this action for Nick)
	SRT: We should ask Nick as well to explain no action
	Martin: silent action c/b "{}
	Martin: silent action c/b "{}", rather than no action which is "{return;}"
	SRT: When you render CDL into text, this can work for Silent Action, but not really for No Action
	Yves: No Action is for black box things. As such it is useless
	SRT: All activties are located, and have a description, but not necessarily a name
	Martin: No Action - nothing is allowed to happen. But as long as you don't have observable behaviour, it doesn't matter
	SRT: Maybe you do have a use for No Action - if you are using CDL to generate documentation, No Action can be useful to indicate "nothing is done here"
	Martin: I think it is more for structuring
	Gary: The fact it is located is a problem then
	Kohei: I think silent action is good enough to address this
	Martin: If we can't write an example of a feature, it shouldn't be in the spec
	Martin: No Action is purely structural, since we don't have semicolons
	SRT: Can we have variables and no variables?
	Martin: Yes, if we don't persist any messages....
	SRT: If we can review the list of examples I asked for, we can then keep them in the background, go through the examples themselves, and then leave enough time to discuss implementation issues, I think we have our agenda for tomorrow.
	SRT: Let's see if we can get to a hard stop at 16.00 tomorrow
	Martin: We're finishing a little early today - nothing else we can address at this point
	Kohei: I would like to note that the examples we just did were outstanding
	Martin: Let's recess for today. Reconvene tomorrow morning....
*** Day Two: 13th December ***

**** Exit criteria
	Discussion about exit criteria
	It is desirable for us to approach various enterprises and institutions to ask if they will do an implementation that can be used for the CR exit criteria
	There are issues relating to BPEL generation which are:
		1. Timeouts - which are handled in a different way
		2. Asychronous programming where interaction exchanges can be split across interactions with other actions occuring in between. This is something we do not believe BPEL can support and so WS-CDL is a richer and more expressive language than BPEL.
		It may also be the case that BPEL, while commercially of interest to many, is simply too unstable to be a target end point language for the WG to rely on for the CR exit criteria
	Test Scenrios for Exit Criteria are at:
	Discussion about features present in the defined tests
	Yves: There is a lack of timeouts
	Charlton: point out that interation -7 has exception examples including timeouts
	Charlton: we may want to add a test that explicity uses a timeout/duration function, since Interaction #7 is using timeouts as part of the interaction
	Yves: pi4tech implementation is close to CR level
	SRT: It may be a good idea to ask the BPEL-TC if items 1 and 2 in particular can be handled or will be handled at sometime in the future or if indeed BPEL will never be able to handle them in a way that makes sense for a peer'ed collaboration.
	Martin: do pi4tech have examples?
	Gary: we have some features tests
	Yves: challenge is to have the other implementation to test against
	Yves: the pi4tech one
	Gary: discusses implementation issues
		Presentation at: http://lists.w3.org/Archives/Public/www-archive/2005Dec/att-0005/Implementation_Issues_Dec2005.ppt
*** Planning, next F2F etc:
	Meeting schedule
	Plan is to have a f2f 23 24 feb, at oracle HQ in dublin (martin's house)
	People might gather somewhere one month earlier to get the ball rolling
	Publication of "part1" in january, "part2" around april/may
	Martin: Refs to predicate path expressions: http://www.ansa.co.uk/ANSATech/93/Primary/10100002.pdf as interesting
	to the formal treatment of CDL in part1 and part2 above.

*** Primer editing and review:
	SRT: What is in Basic, what is in Intermediate, what is in Advanced
	SRT: Under Basic: In this section we shall cover the concepts that are needed for building simple choreographies.
		Simple defined as: Package with more than one particpant/role. Sequence of interactions without exchanges. No exceptions or finalization.
		We might define simple in this case as something that is instructive but certainly not industrial strength
		It should use defaults where possible. It should use simple channels. No extra use of things like info types, tokens.
		If it is not possible to do it without defaults we may need to raise this as an issue to the WG
		Use case is Buyer/Seller/Shipper no CreditChecking
	Manifest for Primer Examples:
		Package, Roles, Participants, Info Types, Tokens, Channels
		Choreography, Variables (for channel instances), interactions
		Buyer asks Seller for price. Buyer buys at price, Seller asks Shipper for shipping details. Shipper responds back 
		to Shipper and to Buyer with details. Relationships and channels for all.  This becomes the degenerate 
		case - the minimum for a choreography.
		Change example above: Buyer requests PO. Seller asks for deliver from Shipper. Shipper responds to Seller. Seller responds back to Buyer.
	Next section - Intermediate Section (need to make the title more descriptive)
	In this section we describe what is needed to make the basic example more realistic
	in terms of observable decision making, further ordering of interactions and the use of vairables for housekeeping
	We also introduce error handling, channel passing, finalization
	ordering is taken to mean: workunits for repetition, workunits for decision making,
	More-or-less as section 3 example does it today.
	New TOC should read as follows:
	3 Getting Started with WS-CDL
	    3.1 Degenerate Example (see IRC log)
	    3.2 Interactions Oriented Design
	        3.2.1 Interactions
	        3.2.2 Roles
			3.2.1 Participants
	        3.2.3 Relationships
	        3.2.4 Information Types
	        3.2.5 Tokens
	        3.2.6 Channels
	        3.3.1 Choreographies
	        3.3.2 Sequences
	        3.3.5 Complete Example
	4 Intermediate topics
		4.X Information types and variables and assignments (state mgmt)
	    4.1 Workunits
			4.1.1 Repeating
			4.1.2 Conditional
		4.4 Exceptions and fault handling
	    4.5 Finalization
	        4.5.1 Finalizers and Finalization
	    4.6 Silent Actions and Conditions
	    4.7 NoActions
	    4.8 Timeouts
		4.9 Parallel
		4.10 Choice
		4.11 Modularization
			4.11.1 Choreographies and sub-choreographies
	        4.11.2 Performing a choroeography
		4.12 Channel Passing
		4.13 Exchanges
		4.14 Records
	5 Advanced
		5.1 Workunit (blocking)
			5.1.1 When
			5.1.2 Repeating When
		5.2 Concurrent performs
	        5.1.1 Managing join conditions
	    5.3 Isolation levels
		5.4 Advanced Channels
	        5.4.1 Usage
	        5.4.2 Channel Passing modes
		5.5 Pitfalls
			5.5.1 Distributed choice and race conditions
		5.6 Alignment and coordination
	6 Implementation considerations
	    6.1 End point projection
	        6.1.1 Java
	        6.1.2 WS-BPEL
	        6.1.3 Runtime Monitoring
	        6.2.1 WSDL 1.1
	        6.2.2 WSDL 1.2
	    6.3 WS-Addressing
	        6.3.1 Channel representation
	SRT: Ordering is not implied by the TOC as it stands
	SRT: Examples to do:
		4.4 Exceptions and Fault Handling
		4.5 Finalization
		4.6 Silent Actions and conditionals
		4.7 No Action
		4.8 Timeouts
		4.14 Record
		5.1 Concurrent performs
		5.3 Isolation levels
		5.4 Advanced Channel usage
		5.6 Alignment and coordination
*** Primer Examples:
	Next part of discussion will focus on scenarios to support the example above.
	4.4 Exceptions and Fault Handling
	Credit Check returns a fault which implies credit failure and this is dealt with in an exception block and you raise cause exception to interrupt the flow of the choreo. The Exception handler returns a message to the buyer to let them know that the order has been cancelled
	4.5 Finalization
	Supposing the credit checking (which implies debiting the card if ok) and the shipping details are done in parallel and are independent. Then we would have two finanlizers which handle the yes go ahead or the no back out both.
	Add some further details that explain the use case in a real world situation in which separate legs of a trade are executed in parallel (e.g. arbitrage).
	4.6 Add a silent action at the credit checker to show that something happens here to do the actual credit checking 
	that is invisible.  Silent variable conditional - silent conditional for sending back credit ok or credit fault.
	4.8 Timeouts
	Buyer side does a timeout on the RequestForQuote (e.g. 30 mins). if they hit the timeout they give up.
	Note: hasDurationPassed belongs in 5. Advanced with 5.1 Concurrent Performs
	4.14 Record
	QuoteAcceptance can have a record to take out the PO on the QuoteAcceptance from the buyer to record the PO at the Seller and then reuse it for the OrderConfirmation.
	5.1 Concurrent performs
	This is the unbounded number of sellers in an RFQ process that may use hasDurationPassed in ajoin conition in one scenario and may use first past the post in another join condition
	5.3 Isolation levels
	In the RFQ process with multilple sellers the multiple concurrent subchoreos at the buyer await responses from the sellers. When a response comes back the buyer in the sub choreo updates an isolated variable if it's value that it has is better than the value it can see for that variable. This ensures that the subchoreos are synchronised in their updating of the new isolated variable so that the correct value is arrived at.
	Note: This raises a pitfall and implementation consideration about when isolated variables get locked. If you lock too soon you may not get the correct or desired behavior.
	5.4 Advanced Channel Usage
	Once - The passed channel to the shipper is usage once so that it adds to privacy and ensures sound behavioral typing (aka this cannot participate in deadlock and livelock)
	Shared/Distinct and passing using "new" to be done
	Note: The "new" could be used to ensure that a fresh channel is passed. This would be used with the once in the advanced example and used as per normal in the normal example.
	Seller should not have "new" because the seller has received a channel from the buyer to pass to the shipper.
	5.6 Alignment and Coordination
	Coodination - Credit Check fails. Seller throws exception so goes into an exception state. And because the choreo is coordinationed the buyer also goes into its exception state because it was all coordinated. This of course involves hidden communication so that buyer and seller know abotu each other state wrt exceptions.
	Alignment will be done after we have sorted out the rest

*** AOB
	Thanks to Oracle for hosting and Martin for organising