[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
I had a private chat with Yaron on this and it turns out that I was misinterpreting his ideas based on wording like "the value of the POCount property is set to 1". Yaron's interpretation of properties is identical to mine -- the problem he is thinking of is the much more subtle one of properties that evaluate to L-values vs those that don't. He can clarify this much more eloquantly than I can but I did point out that trying to solve the L-value, R-value problem in property definitions would be a far larger headache than it would be worth -- my thought would be to tighten up the notion of property aliases to make the problem go away. But I await Yaron's clarification to make that point more clearly. Satish ________________________________ From: Satish Thatte [mailto:satisht@microsoft.com] Sent: Tue 7/20/2004 5:16 PM To: ygoland@bea.com Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Issue - 137 - Making properties consistent with variable values There is no such thing as an independent value for the POCount property. This notion of a standalone property like POCount as a thing with a value that could be used later existed in WSCI but never in BPEL. The POCount property only has a value *relative to* a message. Thus there can (obviously) be many messages available to a process simultaneously, each of which has a POCount property. There is NO notion that receiving every such message "resets the value of" the POCount property. That is why, in assignment, you cannot use just a property name as source or destination. It is always relative to a message variable. The thing that does have an independent (and immutable) value is a correlation set. When a message that initiates such a set is received, the value of the cset is initialized/set to the appropriate member-property values. This does not set values for individual properties on their own, only relative to the cset. This last para is a summary of what issue 8 was proposing to clarify. Does that help? -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Monday, July 19, 2004 9:59 AM 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_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]