[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)
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]