[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 2 - A modest proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]