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