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

[ 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 from
>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 the
>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 types
>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 data,
><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 modeler
>of a BPEL process needs to throw such a variable, he is forced to introduce
>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 variable
>consists of a DII that contains exactly one child, which is an EII
>referenced by the document element property. ... However the children of the
>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 answer
>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 OASIS
>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

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