RE: [wsbpel] Issue 2 - A modest proposal

[Maciej Szefler <mbs@fivesight.com>]

Ivana,

By "another abstraction" I meant that the <scopeDeclarations> element
can occur in a <scope> or a <scopeDeclaration>. For example:

<scope>
  <scopeDeclarations>
    <scopeDeclaration typeName="fooType">
      <scopeDeclarations>
        <scopeDeclaration typeName="barType">
          <empty/>
        </scopeDeclaration>
      </scopeDeclarations>
      <SCOPE name="bar" type="barType" />
    </scopeDeclaration>
  </scopeDeclarations>
  
  <SCOPE name="foo" type="fooType" />
</scope>

yields:

<scope>
  <scope name="foo"> 
    <scope name="bar">
      <empty/>
    </scope>
  </scope>
</scope>


-maciej


On Tue, 2004-09-28 at 12:23, Trickovic, Ivana wrote:
> 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.
> 
>

This is a digitally signed message part