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


As per our disccussions, I'd like to propose the following resolution to 69:

Section 12.5: Flow 
Change the following text:
OLD: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. 
NEW: 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.

Section 12.5.1: Link Semantics
Insert the following text:
EXISTING: The precise semantics of link status evaluation are as follows: 
NEW:      The link status is a tri-state flag associated with each declared
link. This flag may be in the following three states: "positive",
"negative", or "unset". Each time a certain flow activity is activated, the
link status of all the links delcared in that activity is "unset", that is
the lifetime of the status of a link is exactly the lifetime of the flow
activity within which it is declared.
EXISTING: When activity A completes, the following steps are performed to
determine the effect of the synchronization links on other activities: 

The above changes imply option C (if you all remember the options).  The
second part is essentially Satish's earlier proposal in the context of the
current language, while the first part addresses the problem brought up by
Yaron in the conference call relating to while loops that use links declared
outside the while loop. The major consequence of the above changes is that
the following is no longer permitted:
<flow name="f1">
  <link name="l1">
  <while>
    <flow name="f2">
      <empty>
        <source linkName="l1"/>
      </empty>
      <empty>
        <target linkName="l1"/>
      </empty>
    </flow>
  </while>
</flow>

The link "l1" will now need to be declared in "f2". 

The issue of whether links are belong in scopes as opposed to flows will be
made a separate issue. 

-Maciej

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Wednesday, January 28, 2004 1:26 PM
To: Maciej Szefler; ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

Maciej,

On (1) I think we agree, given your clarification that you mean "declaration
scope" rather than <scope> in that part of your comments.  The additional
constraint of not allowing declaration outside the uncrossable boundaries
should fix the problem that provoked this discussion.

On (2) I agree with you that we have blended graph and structured styles,
largely to our advantage I believe.  However it does require the creation of
a few bridging concepts such as the suppressJoinFailure attribute.  This
attribute is clearly just a shortcut since it creates an implicit scope when
True.  The only point I was trying to make is that the main motivation for
adding this attribute was to make it easy to express the semantics of
dead-path-elimination, which is a concept that is native to the graph-based
process design paradigm which is one of the historical branches of this
field from which we inherit concepts in BPEL.  You are absolutely right that
we already allow links within purely sequential structured activities
(although I would not mind us considering a ban on that, if that makes for
greater consistency).  What I am trying to avoid is further encouraging this
type of usage for links which will do no one any good IMHO.

Satish

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

Satish,
 
I am not proposing the mechanism, the mechanism already exists. What I'm
proposing is two-fold: 
	1) simplify the description of link semantics by declaring that
links "belong" to scopes just like variables "belong" to scope.  
	2) modify the syntax to allow links declared in <scope>s since this
can already be done by using a <flow> with only one child. 

I think (1) is critical as it allows us to reason about link / scope
semantics  without having to resort to convoluted language like  "nearest
enclosing <flow> activity". To elaborate, I'll define sets of links that are
"declared in", "imported to", and "exported from" a scope (here I mean
"scope", not <scope> activity). I'll consider a link to be "declared in" the
implicit scope of that link's associated <flow> activity; I'll define the
scope's set of "imported" links as consisting of those links where the
source activity is nested under the scope, and similarly the set of
"exported" links as those links where the target activity is nested under
the scope. Now I can talk about links very easily; for example if I wanted
to talk about non-permeable scope semantics, I'd say (approximately) :
	* each scope maintains a "local copy" of all links declared in,
imported to, and exported from that scope
	* when a scope faults a "false" value for each "exported" link is
propagated to the parent scope
	* when a scope completes, the "local copy" values of its "exported"
links are propagated to its parent scope
	* when a scope receives a link status propagation from another scope
it updates its "local copy" and propagates this value to all child scopes
that "import" the link
	* ... 

As for (2), well that's just an admission that <flow>s can be used to
simulate <scopes>. I don't have any strong opinions on what the processes
people design should/will look like, I'm more interested in consistency and
simplicity of semantics. But I would again point out that the abuses that
concern you are already allowed by the spec. Also I'm a bit un-easy about
your classification of processes as "graph-like" or not "graph-like": I just
don't see where you draw the line. The fact that we can mix structural and
graph constructs in BPEL makes this distinction very nebulous in my mind.
This objection also goes to your previous point characterizing links as a
synchronization construct and not a control construct: what's the difference
really? As for naïve users, we've already made our bed by including both
structured and graph activities, I can't see how (2) makes the situation any
worse. 

It may make sense to split this issue in two; I'm more concerned with (1)
which applies directly to 69. (2) seems to be more contentious, is not so
important, and can be discussed separately.

-Maciej

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Wednesday, January 28, 2004 1:33 AM
To: Maciej Szefler; ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

Maciej,

I missed E3 -- trouble with reading XML code ;-)

My basic unease with this approach is very simple: you are proposing a
mechanism for skipping activitiesembedded in sequential control constructs
that relies on the semantics of suppressJoinFailure=True.  In my opinion the
effect of this attribute value in structured activities is very counter
intuitive.  Which is why the default for the attribute is False.  The True
value is meant to cause dead path elimination behavior in graph-like
processes which doesn't apply here.  

You only showed the simplest examples of the sort of usage in sequential
structured scenarios you are suggesting.  This can get very complex very
easily, with multiple links with transition conditions, etc.  I think naïve
users will find this incomprehensible.  

Satish
 

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Monday, January 26, 2004 8:12 PM
To: Satish Thatte; ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 69 - Proposal to vote

Satish,

I understand what your getting at but your transformation of my script is
not equivalent. Notice that in my script E3 must occur after the switch and
before E4/E5, the sequence was intended to preserve the following ordering:
switch, E3, E4|E5. In your script, E3 has no ordering with respect to E4/E4
nor with respect to the switch. Your criticism regarding the arbitrary
ordering of E4/E5 is valid and to correct it, I'd include a <flow> around E4
and E5: 
	 <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" >

		<flow name="F2">
		      <empty name="E4" supressJoinFailure="true" > 
	             <target link="l1" />
		      </empty>
		      <empty name="E5" suppressJoinFailure="true">
  	             <target link="l2"/>
		      </empty>
		</flow>
	   </sequence>
	  </scope>

The above removes the arbitrary ordering of E4/E5, preserves the <sequence>
as the main program control ensuring that the execution order is: switch
then E3 then (E4 or E5). I'm not sure how replacing the sequence here with a
flow and creating a link between the switch and E3 and another link between
E3 and F2 (to ensure E3 executes between switch and E4/E5) makes this
process any better. If clarity and conciseness are the measures, I believe
just the opposite is true: the primary intent in the above process is a
sequential execution of the three steps, modeling it as a flow belies this
intent. Also, creating links to ensure this ordering (i.e. links switch->E2
and E2->F2) seems to go up against your very objection of using
synchronization links as a control flow construct.  An alternative is to
wrap the whole <sequence> in another flow, which preserves the <sequence>,
but the price is the introduction of the following abusive construction:
	 <flow name="F1">
	 <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" >

		<flow name="F2">
		      <empty name="E4" supressJoinFailure="true" > 
	             <target link="l1" />
		      </empty>
		      <empty name="E5" suppressJoinFailure="true">
  	             <target link="l2"/>
		      </empty>
		</flow>
	   </sequence>
	  </flow>

In the above flow F1 is abused to serve as a scope with the ability to
declare links, it serves no other purpose. I'm proposing we just deal with
this reality and allow people to put links in <scopes> rather than forcing
them to unnaturally call their scopes <flows>. 

-Maciej

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Monday, January 26, 2004 1:04 PM
To: ygoland@bea.com; Maciej Szefler; wsbpel@lists.oasis-open.org
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

	 

	 



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.







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]