[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]