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: Re: [wsbpel] Issue - 137 - Making properties consistent with variablevalues


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_workgroup.php. 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]