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

Does your proposal extend to elements as well? Specifically, should the
declared type of the element variable be considered as opposed to its actual

I'm not sure if others have interpreted the rules as I have but my reading
is that the Qname of the element content drives the match except in the case
of a single part WSDL message which relies on the declared type. 

Regardless of this issue is resolved, I think we should clarify the fault
matching rules to remove an possible ambiguities. For example, what would
happen if I had a schema that used substitutionGroups and threw a fault with
an element within the substitutionGroup? Would the fault matching be driven
by the declared type which was the head of the group or by the actual data
which was one of the allowed substitutions? 

-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] 
Sent: Monday, May 29, 2006 10:00 AM
To: alex.yiu@oracle.com; Mark Ford
Cc: Thomas Schulze; wsbpel@lists.oasis-open.org
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
<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

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 
>the part's element type declaration as opposed to the actual data for 
>that part.
>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 
>type of the fault data are insufficient in this regard because they 
>look only at the element data itself which could be ambiguous with 
>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 
><bpel:variable name="CustomerInfo" type="sns:customerInfoType"/> 
><bpel:variable name="PurchaseOrder" type="sns:purchaseOrderType"/>
><bpel:receive name="ReceivePOMessage" partnerLink="..." 
>  <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 
>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 
>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 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]