[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 137 - Making properties consistent with variable values
Properties are aliases equivalent to "business data headers". They should stay relative to messages. I see no reason to turn them into variables. -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Tuesday, July 20, 2004 10:57 AM To: Chris Keller Cc: Satish Thatte; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 137 - Making properties consistent with variable values I completely agree with you. This is exactly what issue 137 is trying to make the required semantics in BPEL! Yaron Chris Keller wrote: > > > Yaron, > > I believe the issue is that Correlation Sets are immutable; once they are > created they can not change. However messages can change and the contents > of an alias associated with a property can and should be able to > change. So > point [2] is incorrect the property should have a value of 2. Properties > are not variables in their own right they are only aliases within a message > or a part of a correlation set. > > - Chris > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Monday, July 19, 2004 12:59 PM > To: Satish Thatte > Cc: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 137 - Making properties consistent with > variable values > > Satish, > > I'm sorry Satish but I don't understand the point you are trying to > make in your mail. I therefore have produced below a detailed step by > step example of how I understand properties to work in BPEL today. Can > you please explain which of the assumptions below you feel is incorrect > and then provide your own version of this example showing the correct > behavior? > > ... > bpws:property name="POCount" type="xs:int" > bpws:propertyAlias propertyName="POCount" messageType="PO" / > part="First" query="count(/POOrders/Order)" > > process > ... > sequence > [1] receive partnerLink="foo" operation="incoming" / > variable="Orders"... > [2] assign > copy > from > "<POOrders><Order/><Order/></POOrders>" > to variable="Orders" > > [1] When the message is received the properties associated with that > message are initialized using the propertyAlias definitions. In this > case the received message was: <POOrders><Order/></POOrders>. Therefore > the value of the POCount property is set to 1. > > [2] The programmer now changes the contents of the variable Orders to > contains two orders. However this does not cause any change to the > POCount property. Therefore the property's value is still set to 1. > > Thanks, > > Yaron > > Satish Thatte wrote: > > > > > > > This issue represents a misunderstanding of the semantics of properties > > in BPEL. > > > > > > > > Properties are not akin to variables and are not set nor do they exist > > independently. A property "occurs" in a message. One can already get > > and set it in a message through getVariableProperty and property > > assignment. Thus the fragment " the variable is edited to change one PO > > into two. Now the NumOrder property, still set to the value 1 " > > illustrates the misunderstanding. > > > > > > > > Only correlation sets have independently set values, and they are set at > > the time of a web service interaction only. > > > > > > > > Perhaps Issue 8 was not redundant after all .. > > > > > > > > Satish > > > > > > > > > > > > * From: * ws-bpel issues list editor > [mailto:peter.furniss@choreology.com] > > *Sent:* Wednesday, July 14, 2004 8:01 PM > > *To:* wsbpel@lists.oasis-open.org > > *Subject:* [wsbpel] Issue - 137 - Making properties consistent with > > variable values > > > > > > > > This issue has been added to the wsbpel issue list. The issues list is > > posted as a Technical Committee document to the OASIS WSBPEL TC pages > > <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > > basis. The current edition, as a TC document, is the most recent version > > of the document entitled in the "Issues" folder of the WSBPEL TC > > document list > > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - > > the next posting as a TC document will include this issue. The list > > editor's working copy, which will normally include an issue when it is > > announced, is available at this constant URL > > <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > > > > * Issue - 137 - Making properties consistent with variable values * > > > > * Status: * open > > *Categories:* Syntax and validation <#category_syntax_and_validation> > > *Date added:* 15 Jul 2004 > > *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> > > *Date submitted:* 15 July 2004 > > *Description:* Currently a property's value is set when a variable is > > initially set. If the variable's value is subsequently changed then the > > property's value is not updated. Instead, once the property has been > > initially set, the state of the property and the state of the underlying > > variable are no longer correlated. Allowing for a disconnect between the > > property and its variable is all but guaranteed to lead to > > misunderstandings. > > > > Imagine a variable that contains a purchase order and the NumOrder > > property which contains a count of how many orders are in the PO . Now > > imagine that after the variable is set and the property initialized then > > the variable is edited to change one PO into two. Now the NumOrder > > property, still set to the value 1, will no longer have the correct > > count of orders in the variable. > > *Submitter's proposal:* 1) We should require that any time a variable's > > value is updated (e.g. with assign) that the property alias for all the > > properties on the variable should be re-run so the property values will > > be updated. > > > > 2) We should either ban assigning directly to properties or we should > > specify that properties that are not LValues (e.g. resolve to a single > > node in the underlying variable) are read-only and properties that are > > LValues can be written to but the consequence of doing so is that the > > node in the underlying variable is changed. > > *Changes:* 15 Jul 2004 - new issue > > > > To comment on this issue, please follow-up to this announcement on the > > wsbpel@lists.oasis-open.org list (replying to this message should > > automatically send your message to that list), or ensure the subject > > line as you send it *starts* "Issue - 137 - [anything]" or is a reply to > > such a message. If you want to formally propose a resolution, please > > start the subject line "Issue - 137 - Proposed resolution", without any > > Re: or similar. > > > > To add a new issue, see the issues procedures document (but the address > > for new issue submission is the sender of this announcement). > > > > To unsubscribe from this mailing list (and be removed from the roster of > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr oup. > > php. > > > > To unsubscribe from this mailing list (and be removed from the roster of > the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr oup. > > php. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]