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: Re: [wsbpel] Issue - 280 - discussion

Hi Alex and Mark, rules 1 and 4 should take care of both element and type
by means of strict QName matching.

In other words,
 - when a variable is defined with a type ns:t then it can be caught using
a faultType that specifies the same QName ns:t
 - when a variable is defined with an element ns:e then it can be caught
using a faultElement that specifies the same QName ns:e

This clarification would need to be added to the two rules, and the
faultType attribute be added to catch.

Kind Regards
 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                                                  
             com>                                                       To
                                       Mark Ford                       
             24.05.2006 19:47          <mark.ford@active-endpoints.com>
                                       Thomas Schulze/Germany/IBM@IBMDE,
                                       wsbpel@lists.oasis-open.org, Alex
                                       Yiu <alex.yiu@oracle.com>       
                                       Re: [wsbpel] Issue - 280 -      

[ Changing the subject line ... such the issue list can "correlate" this
email thread ;-) ]

Currently, there is a set of rules stated in section "12.5 Fault
Handlers" to determine which <catch> will be used during fault handling.
(under "in the case of faults thrown with associated date ...")

As Mark stated, if we want to support XSD-type (both simple and complex
type) in the <catch> clause, we need to modify that set of rules
significantly. There are 6 rules involved in that set. They are just
using element's QName matching and message type's QName matching there.
The passed resolution intentionally avoid any type inheritance-based
checking there.

If we allow simple-type or complex-type based <catch> clause, it would
be odd to some users, if we don't do any type inheritance-based checking
(similar to Java catch). If we do inheritance-based checking (e.g. a
"foo:AddressType" based <catch> can handle a "foo:USAddressType" fault),
we would wander in the territory of "best-match" schema type semantics,
which I am not sure any other spec has done that before.

If we don't do inheritance-based checking, it may not be that simple
either to resolve all the most appropriate <catch> either. e.g. which
one will be matched?
<catch faultType="foo:AddressType">
vs <catch faultElement="foo:AddressElem">
(where "foo:AddressElem" is based on "foo:AddressType")
vs <catch faultMessageType="foo:AddressMsgType">
(where "foo:AddressMsgType" has a single part based on "foo:AddressType")

I am quite sure if we spend enough time, there will be a matching
algorithm developed. But, at the same time, the 80-20 rules applies
here. That is, we may need to double the size of rules (from 6 to 12)
for a 20% usecase?  Complexity kills usability.

Last, it may be too late for this cycle of spec to add such a new
feature to <catch>.

I hope my train of thoughts sound reasonable to you guys.

Alex Yiu

Mark Ford wrote:

>I think this issue boils down to how we determine the type of the fault
>data. The current matching rules match element data by their QNames. There
>is a subtle difference with WSDL Message fault data that define a single
>part of type element. In this case, the QName for the fault data comes
>the part's element type declaration as opposed to the actual data for that
>If we add support for type-typed variables, then we need to change how the
>type of the fault data is determined. The existing rules for determining
>type of the fault data are insufficient in this regard because they look
>only at the element data itself which could be ambiguous with complex
>and elements.
>How do you propose to determine the type of the fault data?
>-----Original Message-----
>From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com]
>Sent: Tuesday, May 23, 2006 1:32 PM
>To: wsbpel@lists.oasis-open.org
>Subject: [wsbpel] BPEL Issue 280
>BPEL Issue 280 addresses an inconsistency between BPEL's <throw> and
><catch>. While <catch> can only handle message-typed and element-typed
><throw> can additionally throw type-typed data. The proposal is to put the
>restriction on <throw> to be able to throw only message-typed and
>element-typed data.
>Before doing this, I would like to discuss the other opportunity, allowing
><catch> to catch type-typed data.
>The BPEL 2.0 spec builds on WSDL 1.1 which allows to have messages with
>multiple parts. These parts can either be element-typed or type-typed. For
>instance, assume the following WSDL message (from the initial example in
>section 5.1):
><wsdl:message name="POMessage">
>  <wsdl:part name="customerInfo" type="sns:customerInfoType"/>
>  <wsdl:part name="purchaseOrder" type="sns:purchaseOrderType"/>
>Besides i.e. receiving such a message in a message-typed variable, you can
>use <fromPart>. This means, you can receive this message in two type-typed
><bpel:variable name="CustomerInfo" type="sns:customerInfoType"/>
><bpel:variable name="PurchaseOrder" type="sns:purchaseOrderType"/>
><bpel:receive name="ReceivePOMessage" partnerLink="..." operation="...">
>  <bpel:fromPart part="customerInfo" toVariable="CustomerInfo"/>
>  <bpel:fromPart part="purchaseOrder" toVariable="PurchaseOrder"/>
>Now imagine a process which makes use of only such type-typed variables.
>They never can be thrown when resolving the issue as proposed. If a
>of a BPEL process needs to throw such a variable, he is forced to
>a new message or element making use of that type and then throw this
>message-typed or element-typed variable.
>This problem have already been discussed in Issue 93
>(http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue93). The
>reasoning for not allowing to catch type-typed data was: "Throwing complex
>types as faults is vaguely odd and WS-I requires that all SOAP faults be
>defined using elements so in general Web Services faults are typically
>elements anyway."
>I think WS-I does not apply here, because <throw> and <catch> are BPEL
>internal constructs. If a BPEL process should produce a Web Service fault
><reply> have to be used. BPEL does not put any restrictions on replying a
>fault. So why on throwing a fault?
>Additionally remember chapter 8.1: "The infoset for a complex type
>consists of a DII that contains exactly one child, which is an EII
>referenced by the document element property. ... However the children of
>document element MUST exclusively consist of the complex type values
>assigned to the variable."
>Does that mean that type-typed variables have to be internally represented
>as element-typed? (maybe one of the DII / EII / AII / TII experts can
>that question) If yes, the catch logic shouldn't differ that much from the
>existing when allowing to catch type-typed data.
>I appreciate any comments/further thoughts on this. Tanks in advance!
>Best regards/Mit freundlichen Grüßen,
>       Thomas Schulze
>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
>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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]