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.

Related Posts

• Adding JMS or MQ/JMS Custom Header Attributes
• Whats new in WID/WPS v6.1
• BPEL: Beware the use of nested loops in a short running process
• What’s new in IBM WebSphere Enterprise Service Bus V6.1
• WebSphere Enterprise Service Bus does not support Event Sequencing

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.