[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
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
Mark Ford
24.05.2006 19:47 <mark.ford@active-endpoints.com>
cc
Thomas Schulze/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 280 -
discussion
Hi,
[ 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.
Thanks!
Regards,
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
>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 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.
>
>Rationale:
>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"/>
></wsdl:message>
>
>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
>variables:
>
><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"/>
></bpel:receive>
>
>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
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>---------------------------------------------------------------------
>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
>
>
>
---------------------------------------------------------------------
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]