Minutes WS Choreography WG conference call 06 September
2005
IRC: http://www.w3.org/2005/09/06-ws-chor-irc
Agenda: http://lists.w3.org/Archives/Public/public-ws-chor/2005Sep/att-0005/Agenda20050906-0.txt
Latest Editors Draft is at:
http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html
1. Role Call
------------
Charlton_Barreto, Gary, Martin, Abbie, Monica, Steve, Greg, Nick, Yves
Apologies:
2. Confirm scribe
-----------------
Who exactly?
3. Agenda Changes
-----------------
Added to the agenda: Examples (under item 6 Issues), Review of Editors' Draft (after item 6 Issues)
4. Minutes
----------
August 25th minutes
http://lists.w3.org/Archives/Member/member-ws-chor/2005Sep/att-0000/minutes_20050825-2.txt
ADOPTED
August 30th minutes
http://lists.w3.org/Archives/Member/member-ws-chor/2005Sep/att-0001/minutes-20050830-0.txt
ADOPTED
5. Action Items
----------------
1. ACTION: To editors use this to make it consistent in the defs of roleType, participantType, relationshipType
DONE
2. ACTION: for the group to review on the latest CDL editors draft (that is going to be sent by Greg to the member's list)
SUSPENDED for the moment - chairs would like to figure out how close we are ...
3. ACTION: Editors to change "MAY" to lower case "may"
DONE
4. ACTION: Editors to apply change above.
DONE
5. ACTION: Note to editors, when putting text in (new, or from the proposals) always make it consistent with the text in the spec (like lower v in variable, roleType with no spacing, etc.)
DONE
6. ACTION: Editors to make necessary changes as above.
DONE
7. ACTION: Nick/Monica to review the minutes and add clarity
DONE
8. ACTION: On Editors: Nomative language changes is to be picked up and applied by the editors
DONE
9. ACTION: Chair to send this fragment to the public list for further discussion.
DONE
10. ACTION: Next F2F on the agenda for the next week
DONE
11. ACTION: to editors: in section 5.6 all the examples should be in 'yellow'
IN PROGRESS
6. Issues
---------
Discussion ....
*** Exceptions ***
Gary: Would like required minimal change in supporting exceptions
Gary: If have chor which completes, and the business faults - how would we deal with this using a RM transport or Security
Gary: Specify relevant exceptions in qname - or define exceptions more specifically to CDL - e.g. CDL security exception, and mapping that to the underlying mechanism
Gary: As such this should be low impact
Monica: We should pursue Gary's approach - we're in the 11th hour
Charlton: This will provide the least impact and only add flexibility to the mechanism
Nick: What is tha actual mechanism?
Nick: Issue - at binding time, exceptions based to specific classes - so as in BPEL, whereever you put a qname, you handle it there
Nick: I think it is a very flexible mechanism
Gary: We need to explicitly define system level exception types - it definitely requires an exception handler; Nick's approach relies on the exchange
Two approaches: Nick's using qname and the exchange and Gary's explicit definition of system-level exception types
Monica: Comment: Had a long discussion whether we'd define high-level types, the decision was not to define the types from that discussion. Can we recall the points as to why that decision was made?
Monica: Decision was made at the Cannes F2F
Gary: In this case, why not use the default exception handler?
Nick: Problem is that there's no way to define the exceptions to be handled therein
Nick: In CatchAll, no way to know what exception has occurred
SRT: If we have a choreo that's live, and one of the tech exceptions occurs - if we can't name it, there's nothing we can do about it - if we can name them, we have a list of exceptions, but can't do much about - have to be able to bind CDL exception to someething outside the CDL world
Nick: That's what the faultName and qname are used for - points to something in WSDL
Martin: If I specifically catch one, then I have to catch all, and switch in the handler to decide what to do with the exception based on tyoe
Gary: Why can we not do this outside of the catch all?
Nick: Fault on the wire is the exception to be thrown - our protocol can't address this without jumping out
Gary: What I'm suggesting is that knowing the type - a high level abs - would never go down to the details of the exception
Martin: Any benefit to breaking them out from the default handler?
Gary: I'm asking what about using the default handler? Use the default compensation mech for that chor
Nick: Problem is that you have no way to diff between types - e.g. WSS and WSRM w/b in the same package
Gary: I'm suggesting we don't change anything, use the default handler, and leave the issue to the next rev of WS-CDL.
SRT: If I were to get a WSS or WSRM exception in a Choreo, but didn't know what they were, only that I got a technical exception, all I could really consider doing is trying to find another instance of something with the same behaviour, or decide to talk to some other role entirely, or terminate my choreo
SRT: Then, do we really need technical exceptions
SRT: It seems to be a right royal pain in the backside w.r.t. a choreo
Nick: My view on this: For the case of WSS, you have the case such as the Buyer/Seller.... Let's say there's an authorization error thrown from either one - e.g. not authorized to buy this quantity of goods. Then, what comes back is an AuthorizationException, and maybe the client needs to do something about it. If have WSRM, if picking loans based on rate, but one was unreachable or untrustworthy, then deselect from the list of "good" loan providers.
Nick: We need more of a line between system exceptions and business exceptions
Nick: I think what would be the case is that you don't always diff or never diff - if want to diff, may want to do the above, if don't want to diff, we already support this....
SRT: Agree it would be nice to have some differenatiation - however, to do this at the level Nick is suggesting, you are rolling the exception into the business protocol
SRT: The minute you do that, the service throwing the exception would have to directly handle this exception
Nick: I agree, but with the specs as defined, how would you do that?
Charlton: WSRM faults are at the SOAP level, but WSRX faults have a higher level definition
Monica: This may all have to do with impl - there may be a tech failure that precipiates up through the choreo
Monica: I think we have to learn how this gets used in the real world
Nick: I disagree - it is a qname - specs are in development - we cannot wait until other specs are done
Monica: What I was going to say to your points is that there may be a lot more work to consider in the future on this - I'm OK with taking a minimalist approach to this
SRT: I vote for Gary's no change and lets see where this leaves us as we get more experience.
Nick: Within the exchange element, the OPTIONAL faultName attribute is used to identify this exchange element as a fault exchange with the specified name. If the faultName attribute is specified, then it will be used to identify the specific fault within the context of the operation. If the operation is defined using WSDL, this will occur in the following way:
Nick: Only thing I'm proposing - section 6.2.3 - the above paragraph - that we change this to apply only to WSDL
Nick: Add one line: It does not have to be WSDL (correction to the above line)
Martin: Sounds good
Gary: If qname is populated, faultName wouldn't have to be?
Nick: It is just a qname - it doesn't quite impact faultName
Gary: I think we have to bind faultName to the explicitly defined fault in the operation
Nick: Other approach - relax how the causeException attrib would be able to point to exception info
20:00:35 [scribe]
Nick: Change to section 5.3.1 - and some addition in the WorkUnit/Exception Handling section
Nick: [Pasted text]
�When an exception workunit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then it is matched when an exception causing activity is performed that has a causeException attribute value that matches the exceptionType specified within the WS-CDL function.
Nick: The above paragraph in section 5.3.1 w/b the one changed
Nick: In 5.8: I pasted in the text we would need [above] (not 5.3.1)
Nick: I see this function in a handler, assign or interact
SRT: Relaxing the qname on the causeException, right?
Gary: Can we explain how this would work?
Nick: If there's an interaction - define it with a busn protocol - get down to runtime, to a reliability protocol - that protocol throws an exception - so in CDL, you can define an exception type that would catch it?
Actually, Gary: If there's an interaction - define it with a busn protocol - get down to runtime, to a reliability protocol - that protocol throws an exception - so in CDL, you can define an exception type that would catch it?
Nick: The language in the spec as is today covers this
Gary: I thought you were suggesting that we would loosen the binding so that it can be linked to something else as well
Nick: Correct
Nick: We change section 5.8, first bullet - replace with the below language:
"When an exception workunit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then it is matched when an exception causing activity is performed that has a causeException attribute value that matches the exceptionType specified within the WS-CDL function."
Monica: I'm talking about supporting protocols other than WSDL - and that we'd express this in the primer - are we changing this for other mechanisms beyond exceptions?
Nick: I'm worried that if you have WSDL and WSRM and WSS, what happens to WS-CDL?
Charlton: I think the use case is clear - people want to bubble up exceptions from all levels - I see the exisiting protocol with Nick's proposal (relaxing the requirement) as sufficient to support this. My work on the examples illustrates that we can manage exceptions sufficiently this way.
Gary: What about if you take out the part of the sentence that reads "has a causeException attribute"
Gary: When an exception workunit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then it is matched when an exception causing activity is performed that matches the exceptionType specified within the WS-CDL function
SRT: Text goes in after "The rules for matching an exception are:"
Various: Need MUST
FINAL PROPOSAL:
The change would be - first bullet in section 5.8 after "The rules for matching an exception are:"
"When an exception workunit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then MUST be matched when an exception causing activity is performed that matches the exceptionType specified within the WS-CDL function."
PROPOSAL AGREED
NEW ACTION: To add primer issue on lower level exceptions
NEW ACTION: Editors: Exception Type should be exception type
NEW ACTION: Editors: cdl:hasExceptionOccurred has to be hasExceptionOccurred
NEW ACTION: editors to change: cdl:hasExceptionOccurred has to be hasExceptionOccurred
NEW ACTION: editors to change: Exception Type to exception type
*** Examples (added to the agenda) ***
http://lists.w3.org/Archives/Public/public-ws-chor/2005Sep/0004.html
Not covered today
7. Review of Editors Draft (added to agenda)
---------------------------------------------
Issues listed as outstanding in the Editor's list: http://lists.w3.org/Archives/Member/member-ws-chor/2005Sep/0002.html
*** 7) Semantics ***
In "4.4 Channel Types"
"A ChannelType MUST describe the roleType and the type of a party reference"
SHOULD ADD AT END OF PARA
Nick: "Where a party is defined as ......" - subject of discussion
Nick: Motion to group - issue still outstanding
We agree to Nick's proposal for 5.8
*** 9) Semantics ***
Nick: 5.2 Variables
Nick: "Channel Capturing Variables. For example, a Channel Variable could
Nick: contain information such as; the URL to which the message could be
Nick: sent, the policies that are to be applied (e.g. security), whether or
Nick: not reliable messaging is to be used, etc."
Nick: QUESTION: How and where exactly is this extra information (policies,
Nick: security and reliable messaging) expressed. The reader is left
Nick: wondering.
Nick: These need a motion to group in order to resolve them because we [the editors] could not find the resolution.
SRT: Agreed that we need ensure all CR edits have been completed/resolved by next week
SRT: What about the Examples (see above)?
Nick: We don't want to wait until next week.
Nick: Need to ensure examples are consistent
Nick: But in a way that may impact examples
NEW ACTION: SRT & Gary to go through examples and potential semantics issues
SRT: For next week
SRT: Let's get this out on the public list as quickly as possible
Have to address F2F next week at latest
THE MEETING RAN OUT OF TIME AND WAS ADJOURNED
TO DO:
Examples
Review of Editors' Draft
F2F Meeting
SUMMARY OF ACTION ITEMS
------------------------
1. ACTION: for the group to review on the latest CDL editors draft
(that is going to be sent by Greg to the member's list)
SUSPENDED for the moment - chairs would like to figure out how close we are ...
2. NEW ACTION: to editors: in section 5.6 all the examples should be in 'yellow'
3. NEW ACTION: Editors: Exception Type should be exception type
4. NEW ACTION: Editors: cdl:hasExceptionOccurred has to be hasExceptionOccurred
5. NEW ACTION: editors to change: cdl:hasExceptionOccurred has to be hasExceptionOccurred
6. NEW ACTION: editors to change: Exception Type to exception type
7. NEW ACTION: To add primer issue on lower level exceptions
8. NEW ACTION: SRT & Gary to go through examples and potential semantics issues