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: Issue - 2 - subfunctions used as conditionals


Chris's mail brought up the issue of - should subfunctions (or as Chris
calls them, subprocesses) be usable in expressions?

In looking at customer's workflows the expressions I see them use,
especially for control flow, are often quite complex. I think this makes
sense because generally control flow at the level of BPEL involves large
grained decisions like "Is this a gold customer" or "Do I need additional
approval?".

What I have also seen is that this is exactly the sort of logic that the
lower level programmers get called in to write and then provide as utility
functions to the higher level BPEL type programmers.

In other words, one of the most common use cases for re-use is packaging up
control logic.

It is true that we could work around the problem using something like:

<variables>
   <variable name="temp" type="xsd:boolean"/>
</variables>
<sequence>
   <function functionName="decision">
      <parameters><parameter variable="temp"/></parameters>
   </function>
   <switch>
      <case condition="getVariableData(temp)">
         ...
      </case>
      <otherwise>
         ...
      </otherwise>
   </switch>
</sequence>

But having to create temporarily variables just to pass around a value is
both difficult and error prone. It seems much simpler to just allow:

<switch>
   <case>
      <condition>
         <function functionName="decision"/>
      </condition>
      ...
   </case>
   <otherwise>
      ...
   </otherwise>
</switch>

Note that allowing for the use of XML elements as a conditional in a case
statement is the exact same problem we face in Issue 13.

The argument that was made against allowing expressions to be subfunction
calls is that a subfunction call could contain anything and so could, for
example, block. I don't understand why this is an issue. Blocking behavior
can happen all over BPEL. What is special about an expression evaluation
being able to block? How is this any harder to implement then a scope which
contains sub-scopes which can themselves block? I don't see a problem.



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