[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [wsbpel] Issue - 280 - Proposal to Vote
+1 (I.e. we should avoid non-determinism wherever possible) Gruss/Regard, Frank Leymann -----Ursprüngliche Nachricht----- Von: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] Gesendet: Dienstag, 27. Juni 2006 13:05 An: alex.yiu@oracle.com Cc: wsbpel@lists.oasis-open.org Betreff: Fw: [wsbpel] Issue - 280 - Proposal to Vote Alex, the formal point about bugs and features is up to vote when an issue is opened, so I am not responding to that. Two questions: 1. Matching the *declared* type Consider a variable "blue" declared with an element "blueElement", and a fault handler with a faultVariable declared with faultElement "blueElement". An assignment (with validate="no" and keepSrcElementName="yes") puts an invalid value "redElement" to the variable "blue". Finally, a throw activity throws a fault with the variable "blue". If there is no strict matching based the declared QName then the fault handler defined with faultElement "blueElement" does NOT catch this fault. The result is an indeterministic fault handling model based on invalid variable values (another dynamic variation of GOTO), and definitely not a behavior encouraged for business processes. Q1: can you provide a usage scenario (hopefully different from the one above) where strict matching based the declared QName is not sufficient? 2. Strict QName matching of *faultType* Consider two elements, E1 defined of type T1, E2 defined of type T2, where T2 is a restriction of T1. When a variable declared with E2 if thrown then a fault handler with a faultVariable declared with element E1 would never catch it (strict QName matching, ok!). When a variable declared with T2 if thrown then a fault handler with a faultVariable declared with type T1 would ALSO never catch it (strict QName matching). Q2: can you explain why strict QName matching is a good thing for element variables, but exactly the same behavior is a bad thing for type variables? Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany Alex Yiu <alex.yiu@oracle. com> To Dieter Koenig1/Germany/IBM@IBMDE 23.06.2006 21:38 cc wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com> Subject Re: [wsbpel] Issue - 280 - Proposal to Vote (resend the response to the correct email thread) Hi Dieter, -1 to the proposal. Copied from the word doc: ====================== - paragraph after the fault catching rules, from: Matching the type of a faultVariable to fault data as mentioned in points #1 and #4 above is more restrictive than in points #2 and #5. A WSDL message type variable can only match a WSDL message type fault data, while an element variable can only match element based fault data. They match only when their QNames are identical.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]