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