Grid Services Orchestration with OMII-BPEL - Grid Computing: Infrastructure, Service, and Applications - page 193

using link s that connect them with optional transition condition s and/or
join condition s at the start or the end of a link, respectively, to evaluate and
control l ow transitions. The limitation of l ow , though, is the lack of expres-
siveness to dei ne repeated parallel processes. Typically in grid computing,
application processes or computation models are repeatedly executed in
parallel. Differences between individual executions are merely those
parameters or data being used. Apparently, l ow will be too tedious or even
impossible* in this case to duplicate, say, thousands of subprocesses just to
implement concurrency. As difi cult as it is to construct a workl ow like
this, changes to parallel branches that must be applied frequently in devel-
opment cycle or due to experimental requirements are neither manageable.
In WS-BPEL 2.0, a new construct has been added to cater to the exact paral-
lel looping like this. In the default mode of sequential looping, for each is a
functional equivalent to while , whereas in the parallel mode it allows the
spawn of iterations all at once. A user can dei ne how each iteration should
differ from the other with reference to built-in counter or custom expres-
sions or variables, based on a same procedure template. In the example
below, all ten wait s will start timing for a period of Counter seconds:
<bpws:forEach counterName=”Counter” name=”ForEach”
parallel=”yes”>
<bpws:startCounterValue>1</bpws:startCounterValue>
<bpws:finalCounterValue>10</bpws:finalCounterValue>
…
<bpws:wait>
<bpws:for>concat('PT', $Counter, 'S')</bpws:for>
</bpws:wait>
…
</bpws:forEach/>
A common concern in the design of concurrent systems is that concur-
rent access to shared resources may cause race conditions leaving resource
status undeterministic due to corrupted read/write operations. Problems
like this can happen for BPEL processes too. Take variable access for
example: the state information of a BPEL process is stored in variable s;
for example, invocation messages, counters, constants, user-dei ned data
models, and so on. Attempts of updating variables from within concur-
rent procedures are almost certain to lead to unexpected results unless
proper synchronization has been explicitly implemented as part of com-
plete process logic. BPEL addresses the problem by forcing serialization
of these concurrent accesses using synchronized scopes. Being similar to
the concept in procedural programming languages, scope is such a con-
text in which local activities and declarations are dei ned. Isolated scope is
one that has implemented concurrency control in particular. For example,
* Related work on parallel looping using l ow is discussed in a separate chapter.