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

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

Yaron,

Again, my apology for the slow response. Regarding sharing variables: It depends where the "bar" sub-process is defined. If it is defined within the process then yes, if it is defined outside the process (as another top-level process) then the answer is no. The reason is that this is the only way to make reuse possible. 

> > 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.
> 
> Indeed but given the size of the messages that routinely get moved 
> around by web services a by reference capability is not an 
> option, it is 
> a requirement.

Isn't this a performance issue? 

> If someone is just doing calculations and such why would they 
> use BPEL 
> which is uniquely awful at calculations? I only see a 
> function facility 
> in BPEL being useful if it can handle long running processes. But I 
> still believe that the calls should always be synchronous. If 
> they are 
> asynchronous then the function should be a stand alone web 
> service. The 
> idea here is that functions/sub-processes/etc., are a way to have 
> portable bits of BPEL code. It is a substitute for having to type the 
> code in directly. Just like all BPEL activities are synchronous (e.g. 
> you call them and nothing happens on the thread until they return) so 
> should calls to sub-processes.

Maybe there is a misunderstanding here. It is not about synchronous vs. asynchronous, but whether to allow sub-processes to be used within BPEL expressions.

Regards,

Ivana
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Freitag, 6. August 2004 20:22
> To: Trickovic, Ivana
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 2 - Reopen the discussion
> 
> 
> Please see below
> 
> Trickovic, Ivana wrote:
> 
> > 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. 
> > 
> 
> process
>     variables
>        variable name="foo"...
>     subprocess name="bar"
> 
> So can subprocess bar see variable foo?
> 
> > 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.
> 
> Indeed but given the size of the messages that routinely get moved 
> around by web services a by reference capability is not an 
> option, it is 
> a requirement.
> 
> > 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.
> > 
> 
> If someone is just doing calculations and such why would they 
> use BPEL 
> which is uniquely awful at calculations? I only see a 
> function facility 
> in BPEL being useful if it can handle long running processes. But I 
> still believe that the calls should always be synchronous. If 
> they are 
> asynchronous then the function should be a stand alone web 
> service. The 
> idea here is that functions/sub-processes/etc., are a way to have 
> portable bits of BPEL code. It is a substitute for having to type the 
> code in directly. Just like all BPEL activities are synchronous (e.g. 
> you call them and nothing happens on the thread until they return) so 
> should calls to 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/le
> ave_workgroup.php. 
> > 
> >  >
> >  >
> > 
>