Re: [wsbpel] implicite links of the runtime engine (was: Implicit<sequence> macro)

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Satish Thatte wrote:

>The fundamental problem with cycles that do not follow the loop pattern
>is that there are multiple follow-on activities at the point of return,
>only some of which participate in the cycle.  In such cases it becomes
>unclear what the cycling back "means", i.e. what is to be repeated.  I
>believe there is an example in the WSFL specification.
>
>  
>
The problem is not fundamental, but simply a consequence of the 
execution model adopted by WSFL and BPEL. The behaviour of join 
conditions assumes that one cannot have multiple instances of  a 
particular activity (aside from primary activities of course) in a 
process instance. This is a simplifying assumption, but let us be clear: 
it has costs, including the inability to support cycles in the process 
graph. Other approaches would allow us to support cyclic graphs, but not 
without substantially altering the execution model of BPEL 1.1.

Moving up a level, the question becomes: should we support cyclic 
process graphs? We know that BPEL, as it stands, cannot. Also, we know 
that business processes in the so-called real world tend to be pretty 
complex, and do often feature cycles that cannot be reduced to loops. If 
BPEL is to retain that leading capital B, should it not be able to 
execute such business processes? Or should we perhaps entertain a more 
accurate name: WS-SPEL (Structured Process Execution Language)?

Once again, we have hit a topic whose resolution will depend on 
requirements. I hope that we can agree to a set of guiding requirements 
Real Soon Now; I feel somehow trapped in a cycle of our own creation 
right now. :-)

Cheers,
-Ron

[Have I just spent two paragraphs arguing for the equivalent of a "go 
to" statement? How shameful! ;-)]