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

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

Title:

Frank,

    Thanks for the thoughtful response. I wasn't suggesting that the join
condition semantics could be "tweaked" into allowing multiple activity instances.
I agree that attempting this would be fruitless. I was alluding to other
execution models, with quite different control mechanisms, that can support
cyclic activity graphs. If we decide that BPEL must support such graphs,
that strongly suggests we need to completely change the execution model.

    Alternatively, as you suggested, we can try to convert cyclic graphs
to acyclic ones, using structured looping constructs such as <while>.
It is interesting that your customers are okay with the idea of doing this
conversion themselves. You must have much friendlier customers than I! :-)
Business process domain experts tend not to be computer science majors, and
reshaping a process to make it properly structured according to the arcane
rules of  software engineering is considered an unnatural act. 

    An alternative may be to try to automate the conversion to a structured
process. This has some interesting implications. BPEL is not to be considered
a modeling language. What language should we use for modeling? What about
on-line debugging and monitoring?

    As with other issues that have arisen on this list, many of the answers
will be clearer when we have a clear set of requirements to fulfill. If I
understand what you are saying, you regard BPEL (like WSFL before it) to
be a largely a description of an executable process, rather than a user-level
model of business processes. Is this correct?

Cheers,
-Ron

Frank Leymann wrote:
> 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 modeling 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
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org