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

[Frank.Leymann@t-online.de (Frank Leymann)]

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.