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)


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






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