RE: [wsbpel] BPEL Issue 280

["Mark Ford" <mark.ford@active-endpoints.com>]

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