[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [wsbpel] Issue - 280 - Proposal to Vote
|
Hi Dieter and Frank, Frank ... welcome back to the discussion of this TC. :-) Yes, non-determinism is bad. And, having *future* <catch> logic to match fault based on runtime type does not introduce any non-determinism into the BPEL language. Before diving into Dieter's discussion/points ... [a] First of all, I want to clarify that I would prefer not adding the XSD type based feature for <catch> and <throw> in this late stage of game. I tend to think that adding such a potentially complex feature this late would usually yield some suboptimal design or bugs. [b] When this type-based <catch> and <throw> feature is added in future BPEL spec, it actually involves adding multiple layer of decisions to the existing matching logic described the current spec:
For 1), runtime type matching is used, not static variable declared type. e.g.: in Java, the first catch for "IllegalArgumentException" would be used. ------------------------------- try { IllegalArgumentException iae = new IllegalArgumentException(...); Exception e = iae; throw e; } catch (IllegalArgumentException iae) { } catch (Exception e) { } ------------------------------- For 2), instance-of is used. e.g.: in Java, the first catch for "Exception" would be used. ------------------------------- try { IllegalArgumentException iae = new IllegalArgumentException(...); Exception e = iae; throw e; } catch (Exception e) { } ------------------------------- For 3), appearance order would be use to set priority, if the data matches with more than one types used in catch clauses. Note: I am not proposing we adopt this set of approaches in BPEL 2.0. Mainly because BPEL 2.0 spec has not been defined on a runtime type-system/datamodel that allows us to do 1) and 2). [c] Matching the declared type Dieter Koenig wrote: Q1: can you provide a usage scenario (hopefully different from the one above) where strict matching based the declared QName is not sufficient? Example: <variable name="myCustomerVariable" type="foo:CustomerType" /> And, this variable is used in a throw action: <throw faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myCustomerVariable" /> Now assuming that we have this list of <catch> handlers defined in our processes and "bar:US_CustomerType" is a derived type from "bar:CustomerType". : ------------------------------ ... <catch faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myUSCustomerVariable" faultType="foo:US_CustomerType" > ... </catch> ... <catch faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myCustomerVariable" faultType="foo:CustomerType" > ... </catch> ... ------------------------------ If we do matching based on the static type used in variable declaration, only the second <catch> will be triggered to handle the fault regardless of data values/types stored in the variable, because the <throw> is associated with a variable declared with "foo:CustomerType". That is, even if the variable is used to store data of type "foo:US_CustomerType", the first <catch> will never be triggered to perform the error handling. That differs quite a bit from how other typical programming languages that deals with data type that supports inheritance and polymorphism. And, I expect people would want to handle the fault differently based on the data being thrown. Given that inheritance and polymorphism are parts of XML schema, I also expect these features can be used within a BPEL process in general. This static declaration type based matching would force us to drop these features in the areas of <catch> and <throw>. It will be very odd and inconsistent for us to say that. I know some people do not like XML schema per see. If we adopt this static declaration type based matching, we would face the same problem, if the underlying data model is based another OO language. (e.g. C++) [c1] When people use <assign> "keepSrcElementName" to copy to the root element of element-based variable correctly, it is usually related to SubstitutionGroup pattern. When a variable declared with "bar:CustomerElement" can contain "bar:US_CustomerElement" element value, it would be valid XML values, not invalid. An example similar to the above for "faultElement" would play out. E.g.: ------------------------------ ... <catch faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myUSCustomerVariable" faultElement="bar:US_CustomerElement" > ... </catch> ... <catch faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myCustomerVariable" faultElement="bar:CustomerElement" > ... </catch> ... ------------------------------ The first <catch> would be matched to handle the fault variable declared with "bar:CustomerElement" but containing "bar:US_CustomerElement" element value On the other hand, I would agree with you, if one throws a fault with invalid XML data values, the result of the process would be bound to be funky. But, using the static type used in variable declaration for <catch> matching would not cure this problem. We are just delaying the problem to a particular <catch> handler. Using your example, if one assigns an invalid "redElement" value into a variable declared based "blueElement", <catch> of "blueElement" is activated based on static type proposal. That <catch> will more than likely face errors of its own. The best practice is to make sure the <assign> results are valid XML data by means of compile-time analysis and/or runtime validation before the results are used in <throw>. [c2] If we pick matching based the static type used in variable declaration, the QName used in variable declaration and <catch> matching would essentially become yet another QName identifier similar to faultName. It does not resemble any typical data type related info at all. Let me illustrate this by extending the above example further: -------------------------- <variable name="myCustomerVariable" type="foo:CustomerType" /> <variable name="myUSCustomerVariable" type="foo:US_CustomerType" /> -------------------------- Code Path #1: -------------------------- <assign> <copy> <from variable="myUSCustomerVariable" /> <to variable="myCustomerVariable" /> </copy> </assign> <throw faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myCustomerVariable" /> -------------------------- Code Path #2: -------------------------- <throw faultName="bar:CustomerCreditNotEnoughFault" faultVariable="myUSCustomerVariable" /> -------------------------- If we used static type used in variable declaration for matching, the code path #1 will always get the <catch> with "foo:CustomerType", even though the data is really "foo:US_CustomerType". (That is again very strange?) On the other hand, code path #2 will get the <catch> with "foo:US_CustomerType". Why do we want to have two static QName values (one faultName, one faultType) used in <catch> matching, while the static type QName in variable declaration does not give some new information about the most precise type of the fault variable? [d] Strict QName matching I would call strict QName matching for Element-based variable is a good enough solution. It may not be a complete solution, if we want to consider SubstitutionGroup (see below). To answer your particular question in the context of your example: 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? In order for a piece of XML data to be matched with (or instance of) a GED, I would say that it at least needs fulfills two criteria: [i] the QName of XML data matches with the QName of GED [ii] the dynamic/runtime type of XML data matches the type associated with the GED. Again, we don't have any formal definition of dynamic/runtime type of a piece of XML data yet in BPEL 2.0. So, we need to opt out in [ii]. So we would enforce [i] only. See XPath 2.0: -- "instance of" operator: http://www.w3.org/TR/xpath20/#id-instance-of -- "element test": http://www.w3.org/TR/xpath20/#id-element-test The above two [i] and [ii] conditions are based on "4. element(ElementName, TypeName ?)" of "element test" of XPath 2.0, while "element test" would be in turn used in "instance of" test. [d1] 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). Reminder: I prefer matching element-based fault variable and <catch> clause based on runtime data, instead of static type used in variable declaration. That would be the way to interprete your example scenario. If a faultVariable containing <E2> as the data is thrown, it is expected that a <catch> with "E1" would not be able to catch that fault. Because, the element QName just don't match. That is consistent with instance-of check based on "4. element(ElementName, TypeName ?)" of "element test" of XPath 2.0 On the other hand, if a faultVariable containing data of "T2" is thrown, it is expected the catch associated with "T1" will be able to catch that fault. That is consistent with instance-of check based on "6. element(*, TypeName ?)" of "element test" of XPath 2.0. And, it is essentially based on "derives-from" relationship. e.g.: "777 instance of xs:decimal" in XPath 2.0This example returns true because the given value is an
integer literal, and xs:integer is derived by restriction
from xs:decimal[quoted from the XPath 2.0 spec] [d2] The not-so-complete piece about QName exact match for Element-based <catch> is the SG matching functionality. As mentioned in an email to Thomas a while ago, I think we can potentially add a new attribute in future BPEL spec: <catch faultElement="QName" matchSubstitutionGroup="yes|no"? > ... [Note: XPath 2.0's "Element Test" actually explicit rule out SG. I am trying to solicit some extra opinions from some other XML related standard peers within Oracle.] Sorry for this long email. After all, this is a complicated topic. :-) Thanks! Regards, Alex Yiu Frank Leymann wrote: +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. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]