Re: [wsbpel] Issue - 2 - Reopen the discussion

["Yaron Y. Goland" <ygoland@bea.com>]

Please see below

Trickovic, Ivana wrote:

> 
> 
> Here is a list of requirements for sub-processes. Sub-processes:
> (1) Should/could be understood as outsourced pieces of BPEL codes that 
> can be reused within a process or across multiple processes
> 

What does the term 'outsourced' mean in this context?

> (2) Can be defined locally within a single bpel process and reused only 
> within that process, or defined as a top-level bpel process and reused 
> across multiple bpel processes
> 
> (3) Are executed in the context in which they are defined

I'm unclear on what this means. Is this requirement redundant with 6? Or 
are you suggesting that sub-processes would have visibility into the 
variables, links, correlation sets, etc. of it's parent? If that is the 
intention then I would object to the requirement along the same lines as 
Frank's mail, such a requirement makes sub-processes too fragile.

> (4) Must have input/output parameters in order to "pass" data between 
> calling processes and sub-processes; the data is passed by value

Our customers routinely pass around megabyte plus sized XML document so 
requiring that everything be passed by value is unworkable for us. 
Perhaps our situation is unique but I tend to doubt it. I therefore 
object to this requirement and believe we should instead have a 
requirement that values be passable both by value and by reference.

> 
> (5) Must have definition consistent with bpel scopes/processes
> (6) Are tightly coupled with calling processes. That means:
>         (6.1) If calling process is terminated the sub-process must be 
> terminated as well (at least in case of synchronous call)
> 

So this would imply that you believe it is a requirement that it be 
possible to asynchronously call a sub-process?  This would also imply 
that if such an asynchronous call occurs and the parent process is 
terminated then the sub-process would continue. Neither of these 
behaviors is consistent with BPEL today. I would suggest that they are 
not desirable either. If someone wants a truly asynchronous experience 
then I can't help but wonder if that isn't the line we should draw and 
say 'use another BPEL process and not a subprocess'. I would therefore 
object to the implied asynchrony of this requirement and instead suggest 
that we require that all calls be synchronous.

>         (6.2) If sub-process fails and cannot recover from the failure, 
> the fault must be propagated to the calling process
> 
>         (6.3) Calling process should be able to call the compensation 
> activity of the sub-process
> 
> One aspect has been mentioned in our previous discussion as well: using 
> sub-processes in expressions/conditions. I would definitely exclude this 
> aspect.
> 

On what basis would you make such an exclusion? For us one of the most 
useful things one can do with a sub-process is encapsulate decision 
logic. Taking that away make sub-process significantly less useful.

Can you provide an example of a programming language that doesn't allow 
subfunctions to be used in expressions? It would be interesting to see 
how they handled the situation of conditional logic re-usability.

In any case, I object to this requirement and instead propose a 
requirement that sub-processes MUST be capable of returning a value that 
can be used in XPATH expressions/conditions/etc.

I would also add a requirement around exactly what kind of data we 
expect to be able to pass into and out of sub-processes. For example, we 
probably will at least need to be able to pass through variables, 
partnerLinks and correlation sets. Probably an in/out type system would 
be best as it would also give us a very natural way to address the need 
to make calls by reference.

> It would be worth agreeing on the above-mentioned set of requirements 
> first.
> 
> Regards,
> 
> Ivana 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
> 
>