Weblog for the AMIS Technology corner
Posts tagged parallel
Introduction of BPEL 2.0 forEach activity – valuable loop and standard based successor to FlowN
Jan 10th
BPEL 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 there is no real parallel execution at CPU level.
However – when asynchronous activities are ‘waiting other activities can be performed ‘in the mean time’. Examples of asynchronous activities are Wait, Receive (for a reply to the invoke of an asynchronous service, Pick (onMessage and/or onAlarm).
When the forEach scope contains such asynchronous actions, it can provide parallel execution by executing the scope for the next element in the for-loop while the previous element’s iteration is waiting for an activity to continue or complete.
Using asynchronous mechanisms in Java and JavaScript for improving the user experience
Feb 23rd
In this article, we will continue a discussion on asynchronous processing started in a previous article that introduced asynchronous and parallel processing Java using Executors, Futures, Callable Objects and the underlying thread model in Java 5 and 6.
While a stand alone Java application – without UI – is a rare thing in my world, a Java Web application certainly is not. And performance, especially perceived performance, is pretty important in that world. The first page load is the most important measure I suppose for what the user feels is the performance of the web application. The fact that after the initial load, additional elements can be loaded into the page – asynchronously – is fine. The intial page load and the browser’s indication that the load is done (and the hourglass disappears) is what is most important for the happiness of the user.
We will see three stages in this article, of a very simple web page. It is a JSF (JavaServer Faces) page, that contains some very simple elements of which one displays an ‘expensive’ value – a value that takes some time to get hold of. Maybe because a database query is involved or web service is called. Whatever the cause, this one element is expensive. Read the rest of this entry »
Asynchronous processing in Java applications – leveraging those multi-cores
Feb 19th
Processors are not going to get much faster. No higher clockspeeds are foreseen. The speed of processing will be further increasing through parallellization, engaging multiple CPU cores for handling all tasks rather than a single faster core.
This is but one reason for taking a closer look at the threading model in Java and the way we can do asynchronous and parallel processing as of Java 5. Another reason for my interest in asynchronous processing has to do with (perceived) performance. If an application performs a task on behalf of a user, it may block until the task is completed. The user cannot do anything until the task completes – watching the hourglass or whatever busy cursor is used. With asynchronous processing, a task which the user does not immediately require the results from can be processed in a separate thread. The perception of the user therefore is that the task is performed (or at least processed) much faster than in the synchronous case. And even though it is only perception – perception is usually all that counts!
Furthermore, if the task can be broken in smaller pieces that can be executed in parallel, we really can speed up the task – provided processing power is available. Many tasks involve IO-processing, database access or web service calls – all operations that do not burden the CPU very much and leave room for parallel activities in other threads.
In this article I will tell about my first explorations of the world of Futures, ExecutorServices, CompletionService, Callback interfaces and ThreadPools. Read the rest of this entry »
Advanced Concurrency control in BPEL Flow – controlling the execution of parallel branches
Oct 26th
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 the order in which they are defined in the BPEL process and one activity at a time. In this article we discuss the <link> element that gives us a little more control over when an activity is ready to run. It allows us to define dependencies between activities in different branches in the Flow. Read the rest of this entry »
