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

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

Yaron,

My apology for the slow response. Please see my inline comments.

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Freitag, 23. Juli 2004 18:44
> To: Trickovic, Ivana
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 2 - Reopen the discussion
> 
> 
> 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?

In this context outsourced means that a piece of BPEL code used in different places within a process (or multiple processes), is defined as a BPEL scope (or a BPEL process).

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

Sub-processes do not share variables from the scope it is "invoked" by, but from scopes where it is defined. As I responded to Frank: For example, a sub-process defined as a top-level process "shares" no variables, because it is a top-level process and there is no parent process. A sub-process defined directly under a process element "sees" only process variables but not those defined within local scopes.  
 
> > (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.

Sharing data "by reference" introduces additional complexity (especially when a sub-process is defined as a top-level process), because we have to ensure consistent access to shared (transient) data.

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

Mininum will be to support synchronous calls.

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

I would distinguish between sub-processes and functions. The problem is that sub-processes may be complex, and may include interactions with other partners, may take longer time. Sub-processes you mentioned are rather functions doing probably simple computations (e.g. data manipulation). I believe we should separate functions/sub-functions from sub-processes.

Regards,

Ivana

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