BPEL or ESB: Which should you use?

From Developerworks, BPEL or ESB: Which should you use?

When designing an SOA solution, it’s not always clear whether you should use
a Web services BPEL process or an ESB mediation flow. This article describes
considerations that will help you decide which is right for you.

In v6.0.x, this is an easy question to answer: BPEL always. WebSphere ESB is only simple and straightforward when involving a transformation from a single source to a single target. Anything more than that and you’ll create a Frankenstein that will puzzle support people for years. It uses a non-intuitive XSLT editor and the mittens are tight enough that you’ll land up putting custom java code everywhere.

In v6.1, as we saw in the ‘Whats new’ articles for both products there a lot of flow related constructs that have been ‘pushed down’ into WebSphere ESB.

I do have a few issues with this article though. Under the section about ESB strengths is the following statement:

Another strength of an ESB is performance. An ESB is designed to be able to handle large volumes of messages. If, for example, the requirements say that there will be 200,000 messages per day, the ESB would clearly be the better choice.

Now. A WPS Module and a WESB Mediation Module are very similar constructs. Both of them use the SCA
runtime to execute their code, they both get packaged as utility ears on generated EJB projects, they both leverage the underlying abilities of WAS (SIBus, Transactionality etc). The only real difference between them is the usage of a Mediation Flow component vs a BPEL Flow and I don’t think the performance differential between the two is significantly large. They share so much code in common and must spend so much time performing common tasks, yet there’s always this implication that Mediation Flows are magically faster.

With the introduction of these flow-like constructs to mediation flows, the performance benefit of Mediation Flows must be closer to the performance of BPEL. They are both pretty much doing the same workload.

I would severely discount performance as a reason for choosing one over the other.

I guess the other thing I don’t like about the article is that it kind of cops out on WESB entirely by lumping Message Broker in the same category. Message broker is severely expensive and does its job extremely well and has been for years but when someone talks about ‘BPEL vs ESB’, they are usually referring to WESB. The bullet points that make the ESB case sound so great are actually message broker features.

So whats my point? I guess that even in the v6.1 product my point of view on deciding which to use will still be: “Lets do it in a Process Server Module.” unless my use case is ultra-trivial (or the customer simply doesn’t have Process Server). As a customer, why would I want to learn two different runtime components when they are probably pretty equivalent in performance?

Build the skill the in process server, the superset.

Author: syndication

Comments

  1. Hi,
    Even I am confused now on how to use the mediation and BPEL. But my problem is more of a transformation capability based. Its simple. I have a source data type which is having a field of array type(1 to infinity). Now if the length of the array is 3, then I have to extract the value of the i[1] and assign it to another variable (y). Here y is the input variable of an external service which is called by the next invoke acctivity. I have to loop the same until all the values in the array are assigned to the input variable of the external service and the same is invoked.

    Do you think I can do these things in WID Process? Please advice.

  2. Hi Jake,

    No I haven’ conducted any performance testing myself to see which one is faster. My argument here is that they’re probably negligibly different, so the focus shifts to breadth of required development knowledge (two products WESB/WID instead of one WID).

    Hi Sivaraman,

    You can do this via a java snippet in your BO Map or BPEL.

  3. From the developer works article above: “..Process Server includes the complete WebSphere ESB product…” That means that with Process Server product, BPEL and ESB can be used together to decouple orchestration and mediation! Another ESB strength is integration with WSRR registry for dynamic binding to external (Web) Services.
    I can see where a company might need only IBM ESB product- when they use a different BPM product (Pega)

  4. If you’re processing 200,000 messages a day (depending on size and complexity), you may overload ESB, in which case I’d go for WMB – WebSphere Message Broker.

    (And my current project uses both WPS and WMB).

    -Chris

Leave a Reply

Your email address will not be published. Required fields are marked *