OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue - 2 - A subfunction proposal


I appreciate your rigor in pursuing this example and I understand this
is a rough draft.  However, I think this syntax is not the right
approach.  First I think the usage of a sub-function where it can be
called as an expression introduces issues because an expression can now
be long running and the process may need to be persisted mid-expression.
Secondly this whack of syntax doesn't address the reusability concern of
external snippets of processes since it doesn't describe the export and
import of these sub-functions.  Generally I think this issue should have
been titled "subprocess" rather than "sub-function" and should probably
be addressed as a scope extension.

My rough thoughts are 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, partners and partner links.  We then add a the ability
to call it at a scope level <scope subprocess="tns:process(inputVar,
plink1, corrset, ...)"/> type syntax.  The process being itself a scope
already has the necessary pieces to be the nested scope.  We may need
restrictions, like all partner link types need to be mapped in order to
avoid complicating potential deployment issues of subprocesses.  Also
the newly introduced import syntax could be used to help implementations
find the subprocess.


-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, October 29, 2003 6:56 PM
To: 'Trickovic, Ivana'; wsbpel@lists.oasis-open.org
Cc: B.Eckenfels@seeburger.de; arkin@intalio.com; 'Liu, Kevin'
Subject: [wsbpel] Issue - 2 - A subfunction proposal

Here is a very rough, rough draft of a possible solution to Issue 2.

This rough draft introduces three new elements into BPEL - subfunction,
return and function.

The subfunction XML element is used to define a subfunction. It takes
parameters as arguments and those parameters can be variables,
or correlationSets. subfunctions can return values but only variables,
partnerLinks or correlationSets. If a subfunction returns a value then
return activity is used to specify the value to return. Other than
specifying the input parameters and optional return value a
body looks more or less identical to a scope activity's body.

A subfunction can be defined in the global scope, inside of a scope
or in another file and imported into the global scope. The normal BPEL
naming rules apply so you can only call a sub-function you can 'see'.

To call a subfunction you would use the function activity. All
are passed by reference so any changes to those parameters in the
subfunction are reflected back in the host. Returned values however are
always passed by value. Subfunctions that return values can only be
inside of expressions. This requires changing expressions to allow
as arguments but we already have that problem in Issue 13.

If a subfunction throws a fault that isn't caught by the subfunction's
handler then the fault is propagated into the host.

If the host starts compensation then the compensation handler on the
subfunction is called through the function activity in the same way one
calls a compensation handler on a scope.

In the example given below a one-way message is received which contains
math problem. The process calls the IsAddOne subfunction which looks at
type of math problem that has been received and determines if it is a
request to add one to a value in the input message. If it is then the
process calls the AddOne subfunction which will calculate the desired
and send it back to the student using a one-way message. If the request
not to add one then the process will use a one-way to return an error to
student. In either case the process ends when the logger is sent a copy
the message that was sent to the student. Notice that even if the AddOne
subfunction was called the final invoke to the logger still sees the
sent to the student because the mathProblem variable was passed by
to the AddOne subfunction.

      <partnerLink name="mathStudent" partnerLinkType="a:mathStudent"/>
      <partnerLink name="loggingService"

      <variable name="mathProblem" messageType="a:mathProblem"/>

   <subfunction name="IsAddOne">
         <parameter name="problemType" type="xsd:string"/>
      <returnValue type="xsd:boolean"/>
      <return expression="getVariableData('problemType') ==

   <subfunction name="AddOne">
         <parameter name="MathMessage" messageType="a:mathProblem"/>
         <parameter name="Student" partnerLinkType="a:mathStudent"/>
expression="getVariableData('MathMessage','partOne','/TheNumber') + 1"/>
               <to variable="MathMessage" part="partOne"
         <invoke partnerLink="Student" portType="a:AsynchResponse"


      <receive partnerLink="mathStudent" portType="a:MathProblem"

               <function functionName="IsAddOne">
                  <parameter variable="mathProblem"
            <function functionName="AddOne">
               <parameter variable="mathProblem"/>
               <parameter partnerLink="mathStudent"/>
                     <to variable="mathProblem" part="partTwo"/>
               <invoke partnerLink="mathStudent"

      <invoke partnerLink="loggingService" portType="b:loggingService"



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]