[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 2 - Reopen the discussion
Frank, My apology for the slow response. There is no requirement that sub-processes must share variables from the scope it is "invoked" by. I agree with you that this would be a strong precondition. The requirement is that sub-processes may "see" variables from the scope where it is defined. 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. This should cause no additional complications since a local sub-process can be called within that process only and not by any other top-level process. Regarding your comment: > I would discard your sentence in parentheses in (6.1). > Independent of how > you kicked-off a subprocess, you want the ability to request its > termination. I agree. > Compensation of subprocesses can get subtle: If you invoke it > "synchronously" you define a compensation handler with the > invoke. I think > that this compensation handler is used for compensation form the > compensating scope's perspective. If there is no such a > compensation handler > defined, compensation of the subprocess itself must be > started. But what > does that mean? What is "the" compensation handler of the > subprocess? An > asynchronously kicked-off subprocess leads to the same questions... Compensation handlers of locally defined sub-processes should be defined in the same way as for any local scope. If a sub-process completes successfully the compensation handler should be instantiated. For processes defined as top-level processes maybe we need to review issue 25 and the resolution to remove attribute enableInstanceCompensation. For synchronously invoked processes the semantics should not be complex, but for asynchronously invoked processes- I agree - things are little more complicated. Regards, Ivana > -----Original Message----- > From: Frank.Leymann@t-online.de [mailto:Frank.Leymann@t-online.de] > Sent: Freitag, 23. Juli 2004 17:09 > To: wsbpel@lists.oasis-open.org > Subject: AW: [wsbpel] Issue - 2 - Reopen the discussion > > > As units of reusability, I believe that a subprocess must not share > variables from the scope it is "invoked" by. A subprocess > that relies on > data that it can access from the outside is quite fragile, > and its re-use > has strong preconditions. > > Maybe we should distinguish between subprocesses and some sort of > "subroutines" which run in the context of the "invoking" scope. > > The difference between a subprocess and a "subroutine" would > be that the > former is more "autonomous", can be outsourced and run be a > partnern etc.. > > I would discard your sentence in parentheses in (6.1). > Independent of how > you kicked-off a subprocess, you want the ability to request its > termination. > > Compensation of subprocesses can get subtle: If you invoke it > "synchronously" you define a compensation handler with the > invoke. I think > that this compensation handler is used for compensation form the > compensating scope's perspective. If there is no such a > compensation handler > defined, compensation of the subprocess itself must be > started. But what > does that mean? What is "the" compensation handler of the > subprocess? An > asynchronously kicked-off subprocess leads to the same questions... > > Regards, > Frank > Phone:......+49-711-7816 470 > > > -----Ursprüngliche Nachricht----- > Von: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] > Gesendet: Thursday, July 22, 2004 3:37 PM > An: 'satisht@microsoft.com' > Cc: 'wsbpel@lists.oasis-open.org' > Betreff: RE: [wsbpel] Issue - 2 - Reopen the discussion > > Satish, > > The minimum would be to be able to define sub-processes (a) > directly under > the <process> element and (b) as top-level processes. But > certainly more > general solution would be to allow sub-processes to be > defined inside local > scopes as well. Answer to your second question is "yes". The > reason is that, > for example, a sub-process C defined inside a local scope A > may be called > within a scope B nested inside A. In this case, sub-process C > does not "see" > local variables of B, which may be needed. I believe this > would be also > consistent with the <scope> definition. > > Regards, > > Ivana > > > > -----Original Message----- > > From: Satish Thatte [mailto:satisht@microsoft.com] > > Sent: Mittwoch, 21. Juli 2004 20:51 > > To: Trickovic, Ivana; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 2 - Reopen the discussion > > > > > > Ivana, > > > > Could you clarify (3) a little further? Do you mean that > subprocesses > > should be definable in local scopes? Do you mean that they > would then > > share data implicitly with their parent scope(s) in > addition to having > > explicit parameters? > > > > Satish > > > > -----Original Message----- > > From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] > > Sent: Wednesday, July 21, 2004 7:33 AM > > To: 'wsbpel@lists.oasis-open.org' > > Subject: [wsbpel] Issue - 2 - Reopen the discussion > > > > 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 > > (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 > > (4) Must have input/output parameters in order to "pass" > data between > > calling processes and sub-processes; the data is passed by value > > (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) > > (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. > > > > 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_workgr > > oup.php. > > > > > > 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. > > > > 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. > > > > > 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]