Posts tagged flow
Introduction of BPEL 2.0 forEach activity – valuable loop and standard based successor to FlowN
1BPEL 2.0 introduced the forEach activity – similar to for [-loop] found in many programming languages. Oracle SOA Suite 11g adopted BPEL 2.0, first in run time (PS2) and later in Design Time (JDeveloper) as well (PS3 an beyond). For BPEL processes created using BPEL 2.0, forEach is a looping mechanism – similar to repeatUntil and while – and also the successor to the proprietary Oracle extension to BPEL 1.x called FlowN. In that latter capacity, forEach is the activity that enables parallelism in BPEL processes to a dynamic degree.
The well known Flow activity also supports parallelism – but only for a static number of branches, known at design time. FlowN (1.x) and forEach (2.0) add the ability to execute a scope a dynamic number of times, determined at run time.
For example when an operation needs to be performed on multiple elements in a collection, such as all order lines in an order or all persons in a travel booking, forEach is valuable – especially when it makes sense to perform the operation on multiple elements at the same time.
Note however that parallelism in BPEL is a relative concept: a single BPEL process instance is never operated on in more than one JVM thread, so More >
Advanced Concurrency control in BPEL Flow – controlling the execution of parallel branches
In a previous article I discussed the parallel execution of activities in BPEL, more specifically in Oracle BPEL PM 11g (TP4). This article concluded that true parallellism hardly exists. The branches within a Flow get their chance in turns to execute their next step. Not until an activity is complete in one branch can the next branch take over and make one step. The only exception I was able to determine was the Receive activity that waits for an Asynchronous Service to call in with its results – when a branch is executing the Receive (waiting!), other branches can continue with their next step. It seemed that normal Wait operations and Synchronous calls (with nonBlockingInvoke set) should also free the lock the current branch has and allow others to run, but I could not observe that behavior in Technical Preview 4.
I hinted in that article that we can take more control over the way the activities in the parallel branches are executed. Right now it seems that when a Flow executes, the BPEL PM determines when which branch gets a chance to run, whereby it seems – though I do not know whether that is guaranteed behavior – that the branches (BPEL sequence activities) get a turn in More >
Investigation into the true parallellism of the Oracle BPEL PM Flow activity in 11g (Technical Preview 4) – on flow, sequence, wait and (a)synchronous calls
The Flow activity is used to configure parallel activity in BPEL processes. In theory, activities contained in two or more branches (sequence containers) inside a Flow activity are executed in parallel. However, some sections in the BPEL PM documentation raise some doubt: "By default, Oracle BPEL Process Manager executes in a single thread, executing the branches sequentially instead of in parallel". I am not sure exactly what this means. But it certainly suggests that what I assumed to be pure parallel branches are in fact activity sequences that are both carried out, but sequentially! Time to investigate…
In this article, we will go through a number of steps to ascertain what exactly the parallellism for the Flow activity is. Note that I did this research in the 11g TP4 release of the SOA Suite. I will repeat the analysis in the 10g stack – as some findings seem erroneous and are perhaps due to the status of the Technical Preview. (more…)
Recent Comments