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



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