RE: [wsbpel] Issue 69 - Proposal to vote

["Maciej Szefler" <mbs@fivesight.com>]

Apropos the example in the conference call:
 
<flow name="F1">
  <link name="l" />
  <while name="W1">
     <flow name="F2">
         <empty name="E1">
             <source link="l"/>
          </empty>
         <empty name="E2">
            <target link="l"/>
         </empty>
      </flow>
   </while>
</flow> 
 
The above should be considered illegal. Unfortunately, after re-reading the
spec it seems it is currently legal. The current definition of crossing link
boundaries is at fault; it reads:
 
"In general, a link is said to cross the boundary of a syntactic construct
if the source activity for the link is nested within the construct but the
target activity is not, or vice versa, if the target activity for the link
is nested within the construct but the source activity is not." 
 
The definition should should be changed to read:
 
 "In general, a link is said to cross the boundary of a syntactic construct
if the source or target activity for the link is nested within the construct
while the link is defined outside the construct" 
 
The above example can of course be rewritten to comply with the modified
definition by moving the link down to the more "appropriate" location: 
<flow name="F1">
  <while name="W1">
     <flow name="F2">
          <link name="l" />
         <empty name="E1">
             <source link="l"/>
          </empty>
         <empty name="E2">
            <target link="l"/>
         </empty>
      </flow>
   </while>
</flow> 
 
The new definition is more restrictive, but all expressions that were legal
with the previous definition will either remain legal, or can be rewritten
as the above to make them legal.  With the new definition the proposed
solution to 69 works and has no possibilities for ambiguity regarding the
value of a link status in while loops: defining "l" in  "F1" would make it
cross the while loop which is verboten, defining it in F2 means it will
unambiguously get reset with each iteration. 
 
Yaron's also pointed out that links may not belong in <flow> activities. I
agree; they should belong inside scopes. For example:
 
 <scope>
 <link name="l1" />
 <link name="l2" />
 <sequence>
    <switch>
       <case condition="foo">
           <empty name="E1">
               <source link="l1" />
            </empty>
        </case>
        <case condition="bar">
            <emty name="E2">
                <source link="l2" />
             </empty>
         </case>
      </switch>
      <empty name="E3" >
      <empty name="E4" supressJoinFailure="true" > 
             <target link="l1" />
      </empty>
      <empty name="E5" suppressJoinFailure="true">
            <target link="l2"/>
      </empty>
  </scope>
 
In the above the links "l1" and "l2" are used to to propagate the results of
the choice in the <switch> activity down to activities E4 and E5 later in
the sequence. There is no flow, but still links come in handy. The
alternative (without links) would require the introduction of a variable to
note which control path was taken in the <switch> and the nesting of E4 and
E5 in switch statements of their own. Links allow us to express control flow
dependencies clearly in this case (i.e. E4 executes if E1 executed and E5
executes only if E2 executed).  Note that we cant's simply move E4 and E4
into the switch statement in this case wihtout upsetting the requirement
that E4 and E5 execute only after E3.  
 
Links are very much tied up with scopes in any case: scope faults cause
links to be set false, and non-permeable scope semantics (if we adopt them
as we should) marries the setting of link status to successful scope
completion. Making this relationship  between links and scopes explicit is
natural and would only simplify the specification of precise link semantics.

 
 
-Maciej
 
 
________________________________

From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Thursday, January 15, 2004 12:34 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 69 - Proposal to vote



I propose that we follow Yuzo's suggestion for the resolution of this issue
(his variant C).  Specifically, I propose that we add the following language
to the fourth paragraph of Section 12.5.1

 

The status of a link is not set and not available for use when the
immediately enclosing flow activity, within which it is declared, starts.
The status may be set during the course of the immediately enclosing flow
activity, and that status then persists for the lifetime of that flow
activity.  However, if the same (syntactic) flow activity is started again,
for instance by virtue of being inside a while loop, then the status of all
links declared directly within it is reset and is again not available for
use at the start.  Thus the lifetime of the status of a link is exactly the
lifetime of the immediately enclosing flow activity within which it is
declared.

 

 

Satish

 

 


-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, January 15, 2004 12:34 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 69 - Proposal to vote

I propose that we follow Yuzo's suggestion for the resolution of this issue
(his variant C).  Specifically, I propose that we add the following language
to the fourth paragraph of Section 12.5.1

 

The status of a link is not set and not available for use when the
immediately enclosing flow activity, within which it is declared, starts.
The status may be set during the course of the immediately enclosing flow
activity, and that status then persists for the lifetime of that flow
activity.  However, if the same (syntactic) flow activity is started again,
for instance by virtue of being inside a while loop, then the status of all
links declared directly within it is reset and is again not available for
use at the start.  Thus the lifetime of the status of a link is exactly the
lifetime of the immediately enclosing flow activity within which it is
declared.

 

 

Satish