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
---------------------------------------------------------------------
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