RE: [wsbpel] Issue 2 - A modest proposal

["Furniss, Peter" <Peter.Furniss@choreology.com>]

irrelevancy:

the literary allusion of this subject line would suggest that the
process should swifly eat its own sub-processes.

I'm trying to work out the connection

:-)

Peter

> -----Original Message-----
> From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] 
> Sent: 28 September 2004 18:23
> 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/le
> ave_workgroup.php.
> 
>