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] implicite links of the runtime engine (was: Implicit <sequence> macro)



Supporting multiple instances of a given activity is a well-known
requirement (sometimes called "bundles"). But they are needed only in a
small part of flow/process applications. This is why they are not in BPEL
as submitted.  Weaking the execution semantics of join conditions doesn't
solve the "loop problem" at all, it makes it worse: "Ignoring" the join
condition will result in executing "the" activities after the join
activities too - very (!) difficult to understand, debug, etc.!!  And you
need attributes at the activity level telling you what to do if the control
flow reaches the join activity "via a different path": Execute the activity
again, simply do nothing, compensate the work along the subject path etc
etc.. These behavior variants result from many years worth of working with
customers and their business processes, and abstracting what is needed to
support when weakening the join semantics.

Changing the execution semantics in such a manner that each and every
activity can be run multiple times (without affecting the past as indicated
above) is useful in messaging systems geared toward high throughput. It's
useful to base a message broker, e.g., on such a paradigm. But not business
processes management - a completely different notion of process instance
results with inferred deep problems about auditing, monitoring, analysing
what's going, what went on etc.  It make process analysis a nightmare!

Finaly, cycles can be avoided when modelling business processes!  Our
experience out of many many years of working with customers is that
customers accept very fast that they cannot draw cyclic graphs once you
educate them about the problems. And we never bumped into real-world (!)
processes that really needed arbitrary cycles - although its easy on the
white board to draw graphs that give me headache to transform them (but we
all know that CS text books offer algorithms to xform a programm with GOTO
into one without ;-)).

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinghuished Enineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
-----------------





To:    Satish Thatte <satisht@microsoft.com>
cc:    wsbpel@lists.oasis-open.org
Subject:    Re: [wsbpel] implicite links of the runtime engine (was:
       Implicit <sequence> macro)


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! ;-)]


---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org








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