[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 2 - Reopen the discussion
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]