[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]