Our Recent Posts



No tags yet.

BPEL vs OSB Times Responses Configuration.

The purpose of this post is to clarify how much the time responses are affected by some properties changed in BPEL and in OSB.

To give you a background I was doing a migration with a team from a soa architecture made in OSB 11g to OSB 12c.

There were some complex service with possible parallelism and a lot of compensation scenarios that require BPEL 12c and also because of monitoring reasons.

It is important to highlight that in the 12c environment the atomics services last a little bit longer because they have some extra actions to have better parametrization of the service in their internals flow, besides they connect to the on-premises backends from the oracle cloud (It is a migration to soa cloud service)

The response times of the business services migrates to 12c must be as close as possible to the osb old version (11g). This is challenging because complex services where done with BPEL.

These are the 2 comparison with 2 differents services. In total we are comparing 4 sceneries, here are the descriptions:

1. The first service that have 4 atomic service invocation at first stage and then after that first stage a part that will not vary neither in the OSB nor BPEL version.

It is important to highlight that after the xquery or transformation component there is 11 FOR loops that execute validations and transformations inside some xml nodes (This is the last part and was not drawn becuase is equal and done secuencuelly in both version of the service)

1.1. Service Bus Version (Secuencequatlly)

Time records:

Note: All the time in the blog are expressed in milliseconds as they were test in SOAPUI.

These are the times of the bus service version, there is no improvement to do because all invocations and activity are sequentially executed and there is not split join in the service.

1.2. BPEL Version Parallelism.

Time records:

As it is noticeable with the parallel configuration there is not improvement in the times responses at all, this parallel configuration must affect the execution of all the 11 FOR loops (after the xquery component, thus non in the graphic) of the service.

Then the nonBlocking configuration as is verifiable lower the response times from 20% to 25%. So if there is services invocation in a parallel flow.

As last the many="true" configuration in the nonBlockingInvoke node in the composite source does not affects the times at all.

2. These is service that receive a list of items, for each item it will be 2 atomic services bus invocation, these invocations can be done in parallel in the BPEL implementation and in the OSB implementation will be done sequentially.

2.1. In the OSB implementation we use the split join component to verify how the time response change with the parallel and sequence execution in the flow.

Time record, in the time record the execution was done in parallel and in sequence.

The parallelism was activate and deactivate in the for check of the split join as shown in the next image.

Here are the times:

As is show in the previous table the parallelism configuration in the OSB split join component in the for loop enhance significantly the times.

As more are the iterations for the For loop bigger is the enhancement in the performance of the service.

2.2. BPEL version

Time record: To try the bpels variation between configuration the next configuration were changed.

Parallelism in the for loop execution selecting the check below

nonBlockingInvoke property in BPEL to enable the parallelism invocation in the loop flow.

The "many" property of the nonBlockingInvoke property set to true to allow many invocations in parallel (By default is "false")

Now here are the times recording with different quantity of items (Iterations) for the loop and as going to the right for every amount of item. it is added a new performance.

As it can be verified with the first service the parallel check of the FOR loop in the BPEL does not have effect in the times at all. (Parallel column )

With the nonBlockingProperty to allow invocation of the same atomic service in parallel it is noticeable a time decrease from 10% to 25 (Non-Blocking column times).

Then with the many="true" configuration in the nonBlockingProperty improves

The response times was reduce from 25% to 33% (3 items) in comparison with the initials times and as more are the iterations of the for loop more is the benefitial obtained on time response with this configuration (Many column times).

With 3 and 6 items it is appreciable similar improvements in percentage, but with 9 items the impact is bigger and the times are from 50 to 80% lower approximately (with the many="true" configuration in the For Loop).

In resume there some states based in the tests done:

  • Service bus is way faster than BPEL in times of response.

  • Split join in service bus works better in Item's List that can be execute in parallel in a FOR loop and as more are the iterations or invocations to execute in parallel, the more is the time that can be saved and more is the benefitial obtain.

  • Parallel check in the FOR loop in BPEL does not low the response's time as is suppose to do.

  • Using NonBlockingProperty in the parallel branches of a Flow component and in multiples invocations in a FOR loop does considerably improve the performance time.

  • The many= "true" setting in the NonBlockingProperty works really well lowing the times when there are parallel invocations of the same service in a For loop, (as more are the iterations more is the effect in the time performance of this configuration)


Sometimes when you have the option to choose between OSB and BPEL there are a lot of aspects to take in account.

Here is the focus on how to choose according with the performance requirements (priorily) and some relations with other aspects as monitoring.

1. If the service have to be as fast as possible in response time the best option is the OSB over the BPEL.

2. Split join works really well and is just worthy of use where can be more than 3 invocation in parallel whether they are in parallel flow or in a For loop.

3. An orchestrated service must not have more than one split join in its flow because monitoring of the flow service would be deplorable (Split join can not be monitoring in its internal flow, just the response that it returns can be verified).

4. Split join should not have any complex flow logic in its flow, just parallel invocations, whether is in one FOR loop or one Parallel flow with several branches. (As highlighted before, monitoring of internal flow with split-join can turn hair pulling)

5. BPEL can reduce times significantly when it executes several invocations of service in parallel whether they are different atomic services invoked in a Flow Component or the same atomic service invoked several times in a FOR loop component.

6. An orchestrated service that can invoke the same atomic service several times in a For loop can be done in BPEL with great performance with the many="true" configuration in the nonBlockingInvoke property and if the monitoring of the flow service is a main factor BPEL should be the right option.

According to this point if monitoring of the service is not a priority then OSB with split join should be the best option.

7. If you have an orchestrated service that invokes several atomic service in parallel (more than 3) the osb with split join would be an option if there is not more complexity in the flow.

As the flow get more complex in its internal logic or even without complexity if the parallel service invocations are more than 5 then the best option would be BPEL due to monitoring or simplicity for complex logic (or both reasons).

#OSBVSBPEL #BPELTimesConfiguration #BPEL #BPELTimes #BPELPerformance #OSBPerformance #OSBTimes #OracleSOAPerformance #OracleSOATimes

©2018 by ITEvol7777.