RE: [wsbpel] Issue 2 - A modest proposal

[Maciej Szefler <mbs@fivesight.com>]

Peter: i think it is agreed by all parties that dealing with a
prodigious number of sub-processes, would in the present spec be a very
great additional grievance ;-)
-maciej 

On Tue, 2004-09-28 at 13:21, Furniss, Peter wrote:
> 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.
> > 
> > 
> 
> 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.
> 
>

This is a digitally signed message part