[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 2 - Proposal for discussion (first cut)
Based on feedback I received, I would like to make the following change to the proposal below. [1] Exclude asynchronous mode. It requires a kind of coordination protocol; whether it should be a coordination protocol for distributed processes or not is still an open issue. Therefore, the syntax for the call activity will be changed (attribute mode can be omitted). Note: The syntax for the call activity proposed below is not complete - a list of parameters is missing. Also the syntax for parameters of the process element should be reviewed. Regards, Ivana > -----Original Message----- > From: Trickovic, Ivana > Sent: Dienstag, 21. September 2004 14:57 > To: 'wsbpel@lists.oasis-open.org' > Subject: RE: [wsbpel] Issue 2 - Proposal for discussion (first cut) > > > I updated the proposal with syntax (and accompanying > explanation). Please note that the semantics concerning > asynchronous calls is not complete. > > Regards, > > Ivana > > > Motivation > =========== > At the moment, the only way to reuse a piece of a BPEL code > is to define it as a BPEL process and call it within another > process using activity <invoke>. But, many problems arise. > For example, there is no possibility to terminate the process > if the calling process terminates although the invoke > activity will be interrupted and terminated prematurely. The > BPEL processes are primarily designed for modeling loosely > coupled processes. > > Sub-processes > =============== > Sub-processes: > * Should be understood as outsourced pieces of BPEL codes > that can be reused within a process or across multiple > processes. They may also be long-running processes, which > include interactions with other partners. > * 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. > Sub-processes may be defined directly under the <process> > element, inside local scopes or as top-level processes. > * Are executed in the context in which they are defined. This > means that a sub-process may "see" variables from the scope > where it is defined. For example, a sub-process defined as a > top-level process "sees" 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. > * Must have input/output parameters in order to "pass" data > between calling processes and sub-processes; the data is > passed by value. (Note: this decision is motivated by the > fact that 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.) So, a sub-process shares > data with their parent scope(s) in addition to having > explicit parameters. This is needed is cases such as > following one. 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. > Input/output parameters may be variables, partnerLinks or > correlationSets. > > Syntax for sub-processes > Use existing element <process> for two different flavors of > processes: bpws processes and sub-processes. > > <process> > <parameters>? > <parameter name="qname" type="qname"? messageType="qname"? > element="qname"? direction="in|out|in-out|fault"?>+ > </parameters> > > <partnerLinks>? > ... > </partnerLinks> > > <variables>? > ... > </variables> > ... > </process> > > Element <parameters> lists all parameters of the sub-process. > The parameter definition is similar to the variable > definition except that a parameter is further classified into > one of the following categories: input parameter (value > "in"), output parameter ("out"), input/output parameter > (value "in-out") or fault parameter (value "fault"). We > assume that for each parameter there is a variable with the > same name and type (this variable must not be defined). > > Question: Does a fault parameter must always provide a value? > > Invoking sub-processes > ========================= > Sub-processes may be called in two ways: > (1) Calling process invokes a sub-process and waits until it > completes. > (2) Calling process invokes a sub-process and continues with > the next step. This part needs to be extended. I envisage > that we need a mechanism for sub-processes, which may run in > parallel with other activities of the calling process, to > signal that they completed/not completed. > > Syntax: > > <call process="qname" mode="sync|async" > standard-attributes> > standard-elements > </call> > > Activity call is used to initiate the execution of a > sub-process. It specifies the process name and the way in > which the calling process will behave; the calling process > may wait until the sub-process completes (mode="sync") or may > continue without waiting for the sub-process to complete > (mode="async"). > > > Sub-processes and fault handling > ================================= > Synchronous calls: If sub-process fails and cannot recover > from the failure, the fault must be propagated to the calling > process (activity call completes unsuccessfully (re)throwing > the propagated fault in the enclosing scope). The sub-process > will return a fault parameter. The name of the parameter is > the name of the fault. In addition the fault parameter > carries some fault value. > > Synchronous calls: If calling process is terminated the > sub-process must be terminated as well. > > Open issue: Appropriate semantics needs to be defined for > asynchronous invocations. > > Compensation and sub-processes > =============================== > We allow processes with parameters to specify compensation > handlers. If sub-process completes successfully the > compensation handler will be installed. (The call activity is > deemed as completed successfully as well.) The compensation > handler of sub-processes may be invoked either explicitly or > implicitly (by the default compensation handler of the scope > enclosing the call activity). The name of the sub-process is > the name of the scope to be used in the compensate activity. > > Open issues: Complete semantics for asynchronous invocations. > > > > > -----Original Message----- > > From: Trickovic, Ivana > > Sent: Mittwoch, 15. September 2004 16:42 > > To: 'wsbpel@lists.oasis-open.org' > > Subject: [wsbpel] Issue 2 - Proposal for discussion (first cut) > > > > > > There is still some disagreement about the set of > > requirements for this issue. Nevertheless, here is a first > > cut of the proposal (without syntax). > > > > Regards, > > > > Ivana > > > > > > Motivation > > =========== > > At the moment, the only way to reuse a piece of a BPEL code > > is to define it as a BPEL process and call it within another > > process using activity <invoke>. But, many problems arise. > > For example, there is no possibility to terminate the process > > if the calling process terminates although the invoke > > activity will be interrupted and terminated prematurely. The > > BPEL processes are primarily designed for modeling loosely > > coupled processes. > > > > Sub-processes > > =============== > > Sub-processes: > > * Should be understood as outsourced pieces of BPEL codes > > that can be reused within a process or across multiple > > processes. They may also be long-running processes, which > > include interactions with other partners. > > * 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. > > Sub-processes may be defined directly under the <process> > > element, inside local scopes or as top-level processes. > > * Are executed in the context in which they are defined. This > > means that a sub-process may "see" variables from the scope > > where it is defined. For example, a sub-process defined as a > > top-level process "sees" 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. > > * Must have input/output parameters in order to "pass" data > > between calling processes and sub-processes; the data is > > passed by value. (Note: this decision is motivated by the > > fact that 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.) So, a sub-process shares > > data with their parent scope(s) in addition to having > > explicit parameters. This is needed is cases such as > > following one. 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. > > Input/output parameters may be variables, partnerLinks or > > correlationSets. > > > > Invoking sub-processes > > ========================= > > Sub-processes may be called in two ways: > > (1) Calling process invokes a sub-process and waits until it > > completes. > > (2) Calling process invokes a sub-process and continues with > > the next step. This part needs to be extended. I envisage > > that we need a mechanism for sub-processes, which may run in > > parallel with other activities of the calling process, to > > signal that they completed/not completed. > > > > Sub-processes and fault handling > > ================================= > > If sub-process fails and cannot recover from the failure, the > > fault must be propagated to the calling process. > > If calling process is terminated the sub-process must be > > terminated as well. > > > > Compensation and sub-processes > > =============================== > > The idea is to equip sub-processes with the same > > capabilities/features as scopes. This should not be > > controversial for locally defined sub-processes. For > > sub-processes defined outside a bpel process it could be an > > issues. But, it could be more matter of syntax and not > > semantics. That means, sub-processes do not exist in > > isolation; they are always called by a process and may be see > > as part of that process. > > > > > > > > > > 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]