During the last conference call we were discussing the proposal below. Some points are left open. So, additional explanation follows:
* The proposal introduces a new type of processes which is only a design-time feature. The idea is to introduce appropriate format for reusable BPEL pieces that could be easily transformed into <scope>-like structure. Keeping reusable BPEL pieces as a pure design feature avoids introduction of a new model for process instantiation, for example.
* Locally defined sub-processes do not access variables in enclosing scope(s). The very initial idea was that sub-processes would be executed in the context in which they are defined. This means that a sub-process would "see" variables from the scope where it is defined. For example, a sub-process defined as a top-level process would "see" no variables, because it is a top-level process and there is no parent process. A sub-process defined directly under a process element would "see" only process variables but not those defined within local scopes. In order to implement this, the proposal would have to specify renaming rules - which is non-trivial requirement and the question is whether this would postpone any (positive) resolution for this issue. In order to avoid this complexity it is proposed to restrict the visibility. The comment was that this adds complexity for only a small gain. One reason why is valuable to have locally scoped sub-processes is because their visibility is restricted to the processes where they are defined so it is not needed to define top-level sub-processes for pieces that are used multiple times within a single process.
* The comment was that term sub-processes might be overloaded. The idea is not to introduce a new tag for reusable BPEL pieces defined at the top-level but to extend the current definition of the <process> tag. Therefore, term sub-processes is used in the proposal.
* Sub-processes cannot have starting activities (a receive activity having attribute createInstance with value "yes").
* Passing information to/from compensation handlers of sub-processes. At the moment compensation activities are only aware of the state of the associated scope and no enclosing scopes. This has limited value. We may discuss about allowing compensation activities to have parameters, similar like sub-processes. In this way compensation activities would be also affected be the current state of the enclosing scopes (including the process). The question is whether this would bring any value for "normal" scopes given the resolution for issue 3.
* Example for parameters
Code
<process>
<variables>
<variable name="inMsg1" messageType="tns:type1"/>
</variables>
<sequence>
<receive variable="inMsg1" .../>
<scope name="myBlock1">
<variables>
<variable name="inMsg2" messageType="tns:type2"/>
</variables>
<sequence>
<send variable="inMsg1" .../>
<receive variable="inMsg2" .../>
</sequence>
</scope>
</sequence>
<process>
is equivalent to
<process>
<variables>
<variable name="inMsg1 messageType="tns:type1"/>
</variables>
<subProcesses>
<subProcess type="block1">
<parameters>
<parameter name="inMsg" messageType="tns:type1" direction="in"/>
</parameners>
<variables>
<variable name="inMsg2" messageType="tns:type2"/>
</variables>
<send variable="inMsg" .../>
<receive variable="inMsg2" .../>
</subProcess>
</subProcesses>
<sequence>
<receive variable="inMsg1" .../>
<scope name="myBlock1" type="tns:block1">
<parameters>
<parameter name="inMsg" variable="inMsg1"/>
</parameters>
</scope>
</sequence>
<process>
Regards,
Ivana
-----Ursprüngliche Nachricht-----
Von: Trickovic, Ivana [mailto:ivana.trickovic@sap.com]
Gesendet: Mittwoch, 24. November 2004 16:44
An: 'wsbpel@lists.oasis-open.org'
Betreff: [wsbpel] Issue - 2 - Proposal to vote
Here is a proposal to vote. It is based on previous conversations, particularly with Maciej and Chris.
Regards,
Ivana
Reusability in BPEL
====================
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.
Solution
=========
The notion of sub-processes is introduced. 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. They are defined either locally within a single bpel process and reused only within that process, or 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. Input and output parameters are needed in order to "pass" data between calling processes and sub-processes. These parameters may be variables, partnerLinks or correlationSets. [Note: Links parameters are not included in this proposal because we did not find compelling example for that.] Sub-processes do not share data with their parent scope(s).
Syntax for sub-processes: The syntax for locally defined sub-processes looks as follows.
-------------------------
<subProcess type="ncname">
<parameters>?
<parameter name="ncname" messageType="qname"?
type="qname"?
element="qname"?
correlationSet="ncname"?
partnerLink="ncname"?
direction="in|out|in-out"/>+
</parameters>
<partnerLinks/>?
<variables/>?
<correlationSets/>?
<faultHandlers/>?
<compensationHandler/>?
<eventHandlers/>?
activity
</subProcess>
Locally defined sub-processes may be enclosed within a process or a scope so a new section needs to be defined within elements <process> and <scope> as follows:
<process>
<partnerLinks/>?
<variables/>?
<correlationSets/>?
<faultHandlers/>?
<compensationHandler/>?
<eventHandlers/>?
<subProcesses>?
<subProcess/>+
</subProcesses>
activity
</process>
<scope>
<partnerLinks/>?
<variables/>?
<correlationSets/>?
<faultHandlers/>?
<compensationHandler/>?
<eventHandlers/>?
<subProcesses>?
<subProcess/>+
</subProcesses>
activity
</scope>
For top-level sub-processes the syntax for "normal" processes is extended in order to allow passing data.
<process>
<parameters>?
<parameter name="ncname" messageType="qname"?
type="qname"?
element="qname"?
correlationSet="ncname"?
partnerLink="ncname"?
direction="in|out|in-out"/>+
<partnerLinks/>?
<variables/>?
<correlationSets/>?
<faultHandlers/>?
<compensationHandler/>?
<eventHandlers/>?
<subProcesses>?
<subProcess/>+
</subProcesses>
activity
</process>
Top-level sub-processes are not treated like "normal" processes. They cannot be instantiated upon message receipt.
Note: Instance compensation handlers should be introduced again, although just for top-level sub-processes.
Invoking sub-processes
-----------------------
Activity <scope> is extended in order to support additional semantics which is including a sub-process as a scope.
<scope name="ncname"? type="qname"? standard-attributes>
standard-elements
<parameters>?
<parameter name="ncname" variable="ncname"/>+
</parameters>
</scope>
Attribute name is used to name the scope, attribute type references either a top-level process definition (element <process>) or a local sub-process declaration (element <subProcess>). The scope activity provides a list of actual parameters. Attribute name is used to reference a formal parameter of the sub-process. Attribute variable refers to a (locally defined) variable holding the value to be passed to the sub-process.
Example
--------
Code
<process>
<variables>
<variable name="inMsg1" type="tns:type1">
</variables>
<receive msg="inMsg1" .../>
<scope name="myBlock1">
<variables>
<variable name="inMsg2" type="tns:type2"/>
</variables>
<sequence>
<receive msg="inMsg2" .../>
<send msg="inMsg2" .../>
</sequence>
</scope>
<flow>
<scope name="myBlock2">
<variables>
<variable name="inMsg2" type="tns:type2"/>
</variables>
<receive msg="inMsg2" .../>
<send msg="inMsg2" .../>
</scope>
<flow>
...
</flow>
</flow>
<process>
is equivalent to
<process>
<variables>
<variable name="inMsg1 type="tns:type1"">
</variables>
<subProcesses>
<subProcess type="block1">
<variables>
<variable name="inMsg2" type="tns:type2"/>
</variables>
<receive msg="inMsg2" .../>
<send msg="inMsg2" .../>
</subProcess>
</subProcesses>
<receive msg="inMsg1" .../>
<scope name="myBlock1" type="tns:block1"/>
<flow>
<scope name="myBlock2" type="tns:block1"/>
<flow>
...
</flow>
</flow>
<process>
A more complex example is needed to illustrate all transformation rules which might be summarized as follows:
* Activity scope pointing to a sub-process is equivalent to a scope with the same body as one enclosed within the referenced sub-process
* For each parameter of the referenced sub-process one local variable will be generated within the scope with the same name and type, excluding parameters used to pass correlationSets and partnerLinks. For those two types of parameters it is assumed that an instance with the same value exist locally and it is read-only (attribute direction may only have value "in"). Input parameters provide initial values for corresponding local variables (there is an assign statement at the beginning of the enclosed body). Output parameters provide no initial value, but their value will be mapped to corresponding variable visible in calling scope (there is an assign statement at the end of the enclosed body). In-out parameters are combination of input and output parameters.
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.