ISSUE # 23 Addendum && Re: [wsbpel] implicite links of the runtimeengine (was: Implicit <sequence> macro)

[Ram Jeyaraman <Ram.Jeyaraman@Sun.COM>]

The discussion thread "Implicit <sequence> macro" concludes that a sequence 
construct can be replaced by an equivalent flow construct with sequential 
links. But we haven't talked about the join condition needed to acheive this 
equivalency.

If this group decides to make any spec clarifications as part of the resolution 
to issue 23, it may be worth briefly describing in the spec, under what join 
conditions this equivalency may be acheived. Even though this may be purely an 
implementation exercise, this has some academic value to the casual reader.

There are atleast two cases to consider:

CASE 1: Translating a sequence-without-explicit-links-construct into an 
equivalent flow-with-explicit-links-construct

Let's consider a sequence { a, b, c } with no link dependencies. a, b, c are 
all activities. This may be translated to an equivalent flow { a <- b <- c }, 
using an implicit join condition, inclusive-OR, to evaluate the link 
dependencies a <- b and b <- c.

So, a sequence-without-explicit-links-construct can be readily replaced by an 
equivalent flow-with-explicit-links-construct, using the inclusive-OR operation 
of the implicit join condition rule.

CASE 2: Translating a sequence-with-explicit-links-construct into an equivalent 
flow-with-explicit-links-construct

Let's consider a sequence { a, b, c } with link dependencies b -> x and c -> y, 
similar to the one, Satish pointed to earlier, in the spec. a, b, c, x, y are 
all activities. Note, x and y are activities outside the sequence. Translating 
the sequence to a flow, that is,

      x  y			x    y

      ^  ^			^    ^
      |  |         ==>>     	|    |

{ a, b, c }		 { a <- b <- c }

In this case, it does not seem possible to use the same inclusive-OR operation 
of the implicit join condition rule, on a 
sequence-with-explicit-links-construct, in order to produce an equivalent 
flow-with-explicit-links-construct.

In this case, instead of using the implicit join condition rule, if the engine 
uses an explicit join condition rule of
(getLinkStatus(AtoB) && (getLinkStatus(XtoB) || getLinkStatus(..) || ..))
then these constructs are readily exchangeable.

Note: It is also possible for an execution engine to use for CASE 1, the 
explicit join condition of CASE 2, instead of the implicit inclusive-OR join 
condition. That is, CASE 1 become a special case of CASE 2. This makes 
unnecessary the use of implicit join condition for the translation.

peter.furniss@choreology.com: Peter, could you add this as an addendum to issue 
23, please? thank you.