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

["Frank Leymann" <LEY1@de.ibm.com>]

Edwin,

this was EXACTLY my reaction too!

Assaf,

I would appreciate an example of a business process that contains "wild
cycles", and I would like to see a written down description of what the
semantics of these loops are (two "intersecting" cycles suffice), a
description of how you cope with races in the process, with one and the
same activity being activited multiple time and at the same time (!), with
concurrency issues on affected variables etc.. Thanks!

Ron,

what I do is I sit down with those customers who tell me that they need
arbitrary cycles and I walk with them through their examples.  I discuss
with them what they intended to express/specify with the cycles, and how
these cycles should be interpreted.  Most often, different people in the
room interprete the cycles differently and thus, they soon realize that
this is no good.  Or I walk them through the effect of arbitrary cycles and
discuss with them the issues above and the various alternatives how these
issues may be resolved; and nearly always, different people in the room
want different ways to resolve the issues - and they soon realize that this
is no good.  Most often, the conclusion is that arbitrary cycles are to be
avoided:  Otherwise the language will become much more complicated based on
additional attributes of constructs and resulting complications to
comprehend a model.  To state it explicitly: Just allowing arbitrary cycles
is NOT enough, but you need to introduce a bunch of additional language
elements to control the operational semantics of these cycles, a fixed
"simple" operational semantics won't suffice.  Based on my experience the
"controlled cycles" are not only sufficient according to the 80:20 rule but
according to the 99:1 rule - and then it's a business decision whether or
not to go for the 1%.

Thus, Assaf, the customers I am talking about are not "redefining" their
business processes based on "severe limitations" of the language but
because they find out that what they have written down or drawn down is
under-specified.  And the additions/complications needed to result in a
well-defined semantics is admittedly far beyond the "business domain
experts" that Ron mentioned.

...which brings up another important point:  Having completely separate
languages for "business domain experts" is not a good idea because it will
result in all the known problems of transforming this language to BPEL.
While this is already complicated, this mapping has to be bijective because
of monitoring and analyzing the processes:  The other lesson I learned from
customers is that they want to monitor the processes and want to get
analysis results in terms of their original model!  Thus, whenever you
re-write a model defined by a business domain expert into BPEL and you use
a BPEL engine to monitor your running processes and collect historical data
for analysis, you must transform the monitoring/analysis results back to
the business domain expert's variant. Damned complicated!  Thus, I would
strongly recommend that the business domain expert's language is a subset
of BPEL in terms of control structures, data aspects etc but enriched by
business relevant information like resources, costs etc which is needed for
simulation, for example, before you set a process into production. But I
consider such latter extensions out of scope of what we strive to achieve
in our TC.

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
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
-----------------





Please respond to <edwink@collaxa.com>

To:    "'Assaf Arkin'" <arkin@intalio.com>, "'Ron Ten-Hove'"
       <Ronald.Ten-Hove@Sun.COM>
cc:    Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
Subject:    RE: [wsbpel] implicite links of the runtime engine (was:
       Implicit <sequence> macro)


Assaf,

Could you be kind enough to submit a specific example?

Thank you,

Edwin

>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Saturday, July 05, 2003 5:59 PM
> To: Ron Ten-Hove
> Cc: Frank Leymann; wsbpel@lists.oasis-open.org
>
> Ron Ten-Hove wrote:
>
> >     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.
>
> I want to second that. Our customers for one, and I'm sure
> other vendors would agree, are interested in executing their
> business processes. They can put up with some limitations on
> how they interfact with systems, but they're not going to
> change the way they do business just because the language has
> severe limitations. And I find it very interesting that
> customers are willing to redefine their business processes
> yet insist on having both 'block structured' and 'graph
> based' support in the language ;-)
>
> While I echo Ron's sentiments that we do need to support
> business scenarios that involve cyclic graphs, I am not
> convienced this requires any change to the language itself
> (*). If BPEL was intended strictly for execution purposes,
> then modeling such graphs becomes the responsibility of some
> other specification. We might find that the language cannot
> model them well, but certainly can execute them.
>
> I would, however, like to see this as a requirement. Some
> business scenarios do involve cyclic graphs, there needs to
> be a way to support them using BPEL, and without
> acknowledging that requirement it would never happen in an
> interoperable manner.
>
> arkin
>
> * Whenever humans are involved -- the space of collaborative
> processes is a good place to start -- processes must either
> be cyclic or are too rigid and inflexible to be useful.
> Processes modeled as cyclic can be transformed into acyclic
> processes for the purpose of execution.
> However, such a transformation may place additional
> requirements on the language which must be taken into account.
>
> >
> >     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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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