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


Here is my first attempt to come up with specific language to put in the 
spec, think of this as a first pass at a formal proposal to resolve this 
issue:

"When the getVariableProperty function is called the returned value will 
be calculated by applying the appropriate propertyAlias for the 
requested property to the current value of the submitted variable. If 
the application of the XPATH in the propertyAlias to the variable value 
results in a response that contains anything other than exactly one node 
then a bpws:selectionFailure fault MUST be thrown.

When copying a value to a property the value to be copied will be copied 
to the node identified by the XPATH in the appropriate propertyAlias 
when applied to the property's variable value. If the application of the 
XPATH in the propertyAlias to the variable value results in a response 
that does not point to a single information item in the variable value 
then a bpws:selectionFailure fault MUST be thrown."

	Yaron

Satish Thatte wrote:

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