Re: WorkUnit guard semantics issue

The Work Unit's matching semantics have always being the same starting from
Oracle's proposal submission on Sept 17, 2003. In fact I remember that
when I presented this proposal to the Working Group in Seattle's 2003 F2F,
Monica said 'these reactions (the old name of WU) look like production
rules'.


After that, in Oracle+CommerceOne's joint proposal, myself and Dave Burdett
(CommerceOne)
decided to keep the Work Unit's matching semantics the same as they were in
Oracle's
proposal and these are captured on the WS-Choreography Model Overview
document (which was
then accepted as a Working Draft from the WG on Mar 2004):

  3.6.1 Work Units
  Each Work Unit has two optional conditions or guards associated with it:

  An Enabling Condition, which specifies a combination of states that must
be available
  and also evaluate to true before the Work Unit can be performed, and

  A Repeat Condition that specifies a combination of states that, if they
evaluate to
  true once the Work Unit is complete, means that the enabling condition of
the
  Work Unit (if specified) is re-checked.


Also, in both docs (1) Editor's Draft 22 September 2004 and
(2) Working Draft, 12 October 2004 in the 2.4.5 WorkUnit section there
is text that says:

  The Work Unit's interest(s) are matched when all the required Variable
information are or
  become available and the specified matching condition on the Variable
information is met.

And example (c) on both documents says:

  .c. Example of a Work Unit waiting for alignment to happen..

  In the following Work Unit, the guard condition waits for an alignment
Interaction to
  happen between the customer Role and the retailer Role:

  <workunit  name="WaitForAlignment"
           guard="cdl:variablesAligned(
                    "PurchaseOrderAtBuyer",  "PurchaseOrderAtSeller",
                    "customer-retailer-relationship")"
       block="true" >
     ... <!--some activity -->
  </workunit>



The design decision for having these matching semantics for Work Units
was not driven by just the 'timeout' use-case.

The example (c) above, demonstrated another 'constraints' use-case. There,
unless alignment
of variables happens there is no progress made within the WaitForAlignment
WU.

Also, the third bullet example from Working Draft, 12 October 2004  showed
another use-case:
'A Change Order Work Unit that can be performed whenever an order
acknowledgement
message has been received and an order rejection has not been received'.


In gereral, any 'constraints', as specified by the guard condition (I
must confess that the guard attribute that was choosen was/is a poor english
word
to discribe the intent), should be fullfilled for progress
to be made within a WU.

Of course, this could be considered as very draconian, so one could use
block=false to avoid the
wait and just do a check instead.

Also, one can write the following CDL code in order to avoid
waiting for a condition (that accesses variable info) to eval to true:

<WU-1  block=true, guard="isVarAvailable(v1) AND isVarAvailable(v2)...">

  <WU-2  block=false,
         guard="getVar(v1) == 'a' AND getVar(v2) == 'b', ...">
        ... <!--some activity -->
  </WU-2>

</WU-1>



--
Nick


----- Original Message ----- 
From: "Steve Ross-Talbot" <steve@enigmatec.net>
To: "WS-Choreography List" <public-ws-chor@w3.org>
Sent: Wednesday, December 08, 2004 7:07 AM
Subject: Fwd: WorkUnit guard semantics issue



Gentlepeople,

I wanted to present to you a history from 22nd Sept through to the
current date of the WorkUnit with guards and blocking set to true.
In my previous email I alluded to all that follows. I do not think that
this should prevent us from continuing on a present path but we
will need to rectify this matter during a last call period. We may as a
group choose to include it in the LC issues page or we choose
to have it raised (and I am happy to do so) against the LC working
draft when it has been done.

Best

Steve T


> Editors copy of 22nd Sept
> ref: http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html
>
> 2.4.5 WorkUnits
> ......
> ? When the attribute block is set to "true" and one or more
> Variable(s) are not available, then the Work Unit MUST block waiting
> for the Variable information to become available. This attribute MUST
> not be used in Exception Work Units. When the Variable information
> specified by the guard condition become available then the guard
> condition is evaluated:
> ?  If the guard condition evaluates to "false", then the Work Unit
> matching fails and the Activity-Notation enclosed within the Work Unit
> is skipped and the repetition condition even if specified is not
> evaluated
> ? If the guard condition evaluates to "true", then the Work Unit is
> matched and then the repetition condition, if specified, is evaluated
> when the Variable information specified by the repetition condition
> become available
> ? If the repetition condition evaluates to "true", then the Work Unit
> is considered again for matching
> ? If the repetition condition evaluates to "false", then the Work Unit
> is not considered again for matching
>
> Comments:
> Thus according to this draft if a WU has a guard with variables A, B
> and C and condition "A > 1 && B != 6 && C < 5" and has blocking set to
> "true" then when the variables A, B and C are available the condition
> "A > 1 && B != 6 && C < 5" is evaluated. If the condition is false
> because the information at A or B or C is such that this is so then
> the Activity-Ntation within the WU is skipped.
>
> No examples in this version suggest otherwise.
>
>
> Working Draft 12th Oct
> Ref: http://www.w3.org/TR/2004/WD-ws-cdl-10-20041012/
>
> 2.4.5 WorkUnits
> .....
> ? When the attribute block is set to "true" and one or more
> Variable(s) are not available, then the Work Unit MUST block waiting
> for the Variable information to become available. This attribute MUST
> not be used in Exception Work Units. When the Variable information
> specified by the guard condition become available then the guard
> condition is evaluated:
> ?  If the guard condition evaluates to "false", then the Work Unit
> matching fails and the Activity-Notation enclosed within the Work Unit
> is skipped and the repetition condition even if specified is not
> evaluated
> ? If the guard condition evaluates to "true", then the Work Unit is
> matched and then the repetition condition, if specified, is evaluated
> when the Variable information specified by the repetition condition
> become available
> ? If the repetition condition evaluates to "true", then the Work Unit
> is considered again for matching
> ? If the repetition condition evaluates to "false", then the Work Unit
> is not considered again for matching
>
> Comments:
> The 12 October working draft is unchanged at least in terms of the
> guard semantics on WU's with blocking set to true.
>
> Editors Draft 11th November
> Ref:
> http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/att-0055/
> cdl_v1-editors-nov11-2004-XML.pdf.tar.gz
>
> 2.4.6 WorkUnits
> .....
> The optional attribute block specifies whether the matching condition
> relies on the Variable that is currently available, or whether the
> Work Unit has to block waiting for the Variable to become available in
> the future if it is not currently available. This attribute MUST
> always be set to “false” in Exception Work Units. The default for this
> attribute is set to “false”.
>
> .....
>
> • If the attribute block is set to "true" and one or more required
> Variable(s) are not available, then the Work Unit MUST block. When the
> required Variable information specified by the guard condition become
> available and the guard condition evaluates to "true", then the Work
> Unit is matched. If the repetition condition is specified, then it is
> evaluated when the Work Unit completes successfully. Then, if the
> required Variable information specified by the repetition condition is
> available and the repetition condition evaluates to "true", the Work
> Unit is considered again for matching. Otherwise, the Work Unit is not
> considered again for matching
>
> Comments:
> In this draft the text has changed considerably but nothing in the
> text suggests that the semantics are significantly different from the
> previous working draft and editors draft listed above.
>
>
> Editors Draft 3rd December
> Ref:
> http://lists.w3.org/Archives/Public/www-archive/2004Dec/att-0004/
> cdl_v1-editors-dec03-2004-XML-sent.pdf
>
> 2.4.6 WorkUnits
> .....
> The OPTIONAL attribute block specifies whether the Work Unit has to
> block waiting for referenced Variables within the guard condition to
> become available (if they are not already) and the guard condition to
> evaluate to “true”. This attribute MUST always be set to “false” in
> Exception Work Units. The default for this attribute is set to
> “false”.
> .....
> If the attribute block is set to "true" and one or more required
> Variable(s) are not available or the guard condition evaluates to
> "false", then the Work Unit MUST block. When the required Variable
> information specified by the guard condition become available and the
> guard condition evaluates to "true", then the Work Unit is matched. If
> the repetition condition is specified, then it is evaluated when the
> Work Unit completes successfully. Then, if the required Variable
> information specified by the repetition condition is available and the
> repetition condition evaluates to "true", the Work Unit is considered
> again for matching. Otherwise, the Work Unit is not considered again
> for matching
>
>  Comments:
> This changes the semantics since it explicitly states that the guard
> condition to evaluate to "true" in the first paragraph above as well
> as or the guard condition evaluates to "false", then the Work Unit
> MUST block in the second paragraph which was never stated before and
> was in fact different all other references from 22nd Sept onwards to
> 11th November.
>
>  Whilst we appreciate the need to make progress and we understand the
> need to incorporate sensible semantics for timeouts we do not believe
> that changing the semantics to accommodate the timeouts is a good
> thing to be doing. It would be better to take a longer view.
>
> We do intend to raise this as an issue against the LC document when it
> is published and we do not believe it has a major architectural
> impact.
>

Received on Wednesday, 8 December 2004 21:51:26 UTC