[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/leave_workgroup. php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]