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