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 69 - Proposal to vote


I am sorry to say that I don’t find that specific argument convincing.  The main thing I disagree with is the inclusion of E4 and E5 in the sequence — they are alternatives and their selection would be a lot easier to understand if they were in a flow in parallel with the switch.  The implied sequencing between them, E4 before E5, is actually meaningless and misleading.  You could just as well have E5 before E4.  The sequencing of the switch before either E4 or E5 would be implied by the links.  Thus, to me,

 

 <flow>

 <link name="l1" />

 <link name="l2" />

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

  </flow>

Is a lot easier to understand and completely equivalent — all I did was eliminate the sequence and replace the scope with a flow.

In general, use of links within a sequential process is always difficult to understand because it is not used for synchronization, but for selecting alternatives or suppressing the execution of some process fragment.  In my opinion, using the transition condition in a switch, or making the alternatives clear in a flow as in this case, is always a better and clearer alternative.

Satish

 


From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Monday, January 26, 2004 10:18 AM
To: Satish Thatte; 'Maciej Szefler'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

 

As Maciej says, I have wondered if we shouldn't just declare links in scopes. It would make everything a lot more consistent and as Maciej convincingly argues, there are usages of links that exist outside of flows.

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Sunday, January 25, 2004 8:56 PM
To: Maciej Szefler; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

Maciej,

 

If I read your proposal correctly, I agree with you.  The boundary crossing notion needs to be strengthened to include usage of links relative to the definition, not just having the source and target on different sides of the boundary.  This would prohibit usage of a link (entirely) inside a while loop when its definition is outside, thus making the offending example illegal.  This makes sense because of the very essence of issue 69 which points out that status lifetime is an important aspect of link semantics – and the point of the boundary crossing prohibition rules was that the construct boundary defines the limits of the meaningful use of a link and the use of a link includes the lifetime of its status.

 

Satish

 


From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Wednesday, January 21, 2004 10:26 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

 

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

 

 



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