[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 2 - Reopen the discussion
Please see below Trickovic, Ivana wrote: > > > 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. > Given that BPEL already has a well defined mechanism for enabling top level processes to communicate with each other, web services, I don't understand why that issue would be in scope for issue 2. > > > 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 we create a solution that cannot be implemented in a performant manner then the solution is not useful. So, yes, it is a performance issue, one of such critical import that if we don't get it right then the feature cannot be reasonably said to be useful. > > 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. > I suppose it all depends on how you define a sub-process, I am not clear on what your definition is. > 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. > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]