OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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