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

["Edwin Khodabakchian" <edwink@collaxa.com>]

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
> 
>