RE: [wsbpel] Issue 2 - A modest proposal

["Chris Keller" <chris.keller@active-endpoints.com>]

Building on Majciej's idea, but extending it for separate BPEL files, I'd
like to resubmit a previous idea I had suggested for Issue 2.

My rough thoughts were that we change our process types from only abstract
and executable to abstract, executable and subprocess.  And a subprocess
type introduces a list of supplied parameters for mapping variables,
correlation sets and partner links.  We then add the ability to call it at a
scope level <scope subprocess="tns:process(inputVar, plink1, corrset,
...)"/> (or via something like Maciej's syntax).  The process being itself a
scope has all the necessary pieces to be a nested scope.  The new import
syntax could be used to help implementations find the subprocesses.  We may
have to allow compensationHandler again at the process level for a
subprocess :) in order to implement this.

- Chris

-----Original Message-----
From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] 
Sent: Tuesday, September 28, 2004 1:23 PM
To: 'Maciej Szefler'
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 2 - A modest proposal

Maciej,

I find the proposal interesting (at least for locally defined reusable
pieces of BPEL code). Would you give an example of an "another abstraction"
where the scope abstractions can be declared?

Regards,

Ivana


> -----Original Message-----
> From: Maciej Szefler [mailto:mbs@fivesight.com]
> Sent: Samstag, 25. September 2004 21:51
> To: Trickovic, Ivana
> Cc: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue 2 - A modest proposal
> 
> 
> Ivana,
> 
> Keeping in mind the understandable desire by certain members 
> of the committee to make these things macros and your desire 
> to address this issue, what do you think about the following approach:
> 
> We create the notion of a "parameterized scope" an "abstraction" of a
> scope. These scope abstractions must be declared (in a scope, or in
> another abstraction), using a syntax nearly identical to that 
> of scopes:
> <scope>
>    <variables>?
>    <correlationSets>?
>    <partnerLinks>?
>    <faultHandlers>?
>    <compensationHandlers>?
> 
>    <scopeDeclerations>
>      <scopeDeclaration typeName="typeName">
>        <parameters>
> 	 <param name="paramName" {message,element,}type="" />*
>        </parameters>
>        <faultHandlers?>
>        <compensationHandlers?>
>        <variables?>
>        <correlationSets?>
>        <partnerLinks?>
>        <any-activity>
>      </scopeDeclaration>
>    </scopeDeclerations>
>    ...
> </scope>
> 
> To use a scope abstraction we have a new "concretion" activity:
> <SCOPE name="scopeName" type="typeName">
>    <arg paramName="paramname" replacement="visibleVarName" />*
> </SCOPE>
> 
> So the construction:
> <scope>
>   <scope name="foo">
>      <empty/>
>   </scope>
> </scope>
> 
> is equivalent to;
> 
> <scope>
>   <scopeDeclerations>
>     <scopeDecleration typeName="fooType">
>       <empty/>
>     </scopeDecleration>
>   </scopeDeclerations>
> 
>   <SCOPE name="foo" type="fooType" />
> </scope>
> 
> 
> In the other direction, the concretion <SCOPE name="foo" 
> type="bar"  can
> be defined simply in terms of an XML re-write rule: it is 
> equivalent to
> writing <scope name="foo"> with the body found in scopeDecleration of
> typeName="bar" subject to renaming of names found in the <parameters>
> block to the names specified in the <arg> elements. In order to keep
> this a pure "macro" we have to disallow recursion, and we 
> must disallow
> free variable or link names in the scope declarations (i.e. parameters
> are the only way to pass data around). 
> 
> To do functions: 
> 
> <scope> 
>    <scopeDecls>
>       <scopeDecl typeName="multiply">
>           <parameters>
>              <vararg name="x" ../>
>              <vararg name="y" ../>
>              <vararg name="product"  ../>
>           </parametrs>
>           <assign>
>              <to variable="product" />
>              <from>$x * $y</from>
>           </assign>
>       </scopeDecl>
>    </scopeDecls>
> 
>    <scope>
>       <variables>
>         <variable name="a1"/>
>         <variable name="a2"/>
>         <variable name="a3"/>
>         <variable name="a4"/>
>         <variable name="a5"/>
>         <variable name="a6"/>
>       </variables>
>       <sequence>
>           <SCOPE name="s1" type="multiply">
>              <vararg paramName="x" varName="a1" />
>              <vararg paramName="y" varName="a2" />
>              <vararg paramName="product" varName="a3" />
>           </SCOPE>
>           <SCOPE name="s2" type="multiply">
>              <vararg paramName="x" varName="a2" />
>              <vararg paramName="y" varName="a3" />
>              <vararg paramName="product" varName="a4" />
>           </SCOPE>
>           <SCOPE name="s3" type="multiply">
>              <vararg paramName="x" varName="a4" />
>              <vararg paramName="y" varName="a5" />
>              <vararg paramName="product" varName="a6" />
>           </SCOPE>
> 
>       </sequence>
>    </scope>
> </scope>
> 
> 
> The appeal of this approach is that it gives you parameterization, and
> can be done completely on the XML re-writing level (simple XSLT can do
> it) without introducing any new "native" BPEL constructs.
> 
> If you want to get even fancier, you can also have link parameters. 
> 
> -maciej
> 

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.