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
=========================================================================================
References:
Primer is at:
http://www.w3.org/2002/ws/chor/edcopies/primer/primer.html
8th Nov Minutes:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Nov/att-0006/minutes_20051108_-_0.txt
Gary's slides on implementation issues are at:
http://lists.w3.org/Archives/Public/public-ws-chor/2006Jan/att-0002/ImplementationIssuesDec2005.pdf
Marco's slides on formalism are at:
TO BE ADDED
Formalism paper is at:
http://lists.w3.org/Archives/Public/public-ws-chor/2005Nov/att-0015/part1_Nov25.pdf
Agenda is at:
http://lists.w3.org/Archives/Public/public-ws-chor/2005Dec/att-0006/Agenda-Dec-F2F-0.txt
IRC log is at:
http://www.w3.org/2005/12/12-ws-chor-irc
http://www.w3.org/2005/12/13-ws-chor-irc
*** Roll Call:
Guests:
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
DONE
3. ACTION: SRT to reissue the TOC for the primer in light of out discussion at this conf call
IN PROGRESS
4. ACTION: Move parallel composition and modularisation subsections into Section 3 of the primer
IN PROGRESS
5. ACTION: WG Members to think about examples and volunteer to do some
IN PROGRESS
6. ACTION: SRT to add a "degenerate use of CDL" section to the primer
IN PROGRESS
7. ACTION: steve to update f2f agenda to move kohei to monday
DONE
Primer review:
ACTION ITEM 3 NEW DONE - NEW TOC SEE BELOW
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:
[http://lists.w3.org/Archives/Member/member-ws-chor/2005Nov/att-0006/minutes_20051108_-_0.txt]
* 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
http://caml.inria.fr/
http://caml.inria.fr/about/history.html
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:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Jun/0008.html
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.
Notes:
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