[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Chapter 15 - Examples
Hi, here are my additional comments regarding chapter 15. (1) In the example 15.1.3 a correlation set is used only at the receive, not on the invoke activities. We should either completely remove the correlation set and all needed stuff for it (property "shipOrderID", 2 propertyAlias definitions and maybe some of the added copy elements which populate the shipOrderID properties) or we should add it back on the one-way invoke activities and ensure all needed propertyAlias definitions are available. This have previously been removed because the need of correlation set on one-way invokes was not that obvious. Maybe for the use of correlations in <invoke> invoking an one-way operation a clarification is needed in chapter 9? Maybe something like "In the case of <invoke>, when the operation invoked is an one-way operation, or in the case of <reply> the usage of correlation sets with initiate="no" is for message validation purposes only. With this, a business process can ensure that the response message to be send carries the expected correlation tokens."? (2) In 15.2.2, the propertyAliases for - propertyName="tns:orderID" messageType="oif:OrderAckMessageType" - propertyName="tns:orderID" messageType="oif:ShipRequestMessageType" are not needed. (3) In 15.2.2, the propertyAlias for propertyName="tns:orderID" messageType="oif:ShipNoticeMessageType" is needed for the following receive, I assume: <receive partnerLink="shipperResponse" portType="oif:shippingServiceCustomerPT" operation="shippingNotice" variable="shippingNoticeMsg" ext:uniqueUserFriendlyName= "receive response from shipper"> <correlations> <correlation set="orderCS"/> </correlations> </receive> The used variable is defined as follows: <variable name="shippingNoticeMsg" element="order:ShipNoticeMessage"/> Now, since this is an element-typed variable, what is the expected kind of the propertyAlias? The one given or the version with element="..." instead of messageType="..."? According to chapter 7.3 it should be the element version. Right? (3.1) While thinking about (3) the following question came up: Does BPEL allow conflicting propertyAlias definitions when having one for the message type (single part and element-typed) and one for the element referenced in the message part? Or does this need to be catched by static analysis? (3.2) The following question came up, while thinking about (3) and (3.1): When using <toPart> and <fromPart> mapping, which propertyAliases are expected? IMO the spec currently does not say anything about that. Is a message-based propertyAlias required or a propertyAlias for each variable in <fromPart> or <toPart>? A possible solution for (3), (3.1) and (3.2) would be to always require a message-based propertyAlias in the context of correlation sets. Element- and type-based propertyAliases then are only required when working with getVariableProperty(). I assume we should address that problems with an issue. (4) In 15.2.3 the optional extension ext="http://example.com/bpel/some/extension" is used. I 'd like to propose to either remove it or to explicitly declare it in the process as a mustUnderstand="no" extension. 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]