OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.    


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]