BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

BPEL or ESB: Which should you use?

Marc Fasbinder (mfasbind@us.ibm.com), BPM Integration Solution Architect, IBM
12 Mar 2008

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.

Overview
In the IBM® SOA reference architecture, shown in Figure 1, services are grouped into functional areas,
communicating through an enterprise service bus (hereafter called ESB). In an ideal world, each functional area
such as process services, would be "pure", offering only one class of services in order to provide a separation of
concerns.

Figure 1. SOA reference architecture

However, In the real world, there are often functional areas in any product set where overlaps exist. For example,
WebSphere Process Server (hereafter called Process Server) is the software component that provides process
services in the reference architecture. It evolved from WebSphere MQ Workflow, WebSphere Interchange Server
and WebSphere Business Integration Server Foundation. To facilitate upgrades for users of previous generations of
products, it includes functions equivalent to those in the older products. For example, Interchange Server included
business object mapping, which exists in Process Server in the form of interface maps.
Business objects flowing into and out of a business process can be mapped. Mapping is also one of the primary
functions in an ESB. Therefore, if you have both Process Server and an ESB, you need to make a decision about
which product is the right one to solve a given business problem, because of these areas of overlap.
There are other use cases where either Process Server or an ESB could be used. For example, suppose three
existing services need to be called, using a two-phase commit. This is known as a composite service. You could use
a mediation flow in an ESB to call the services. Mediation flows are committed as a transaction, or rolled back.
You could use a WS-BPEL micro-flow to call the three services, also providing transactionality. In this, you could
use both products as the solution. How do you decide which is the right one?

ESB overview
An ESB is an architectural pattern, not a software product. Different software products can form an ESB. In some
cases, companies use multiple products in different areas, leveraging specific functionality to meet their unique

1 of 6 09/06/2009 06:20 p.m.

BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

requirements. These different products can be federated together as the realization of the ESB pattern.
At a high level, an ESB has four major functions:
Message routing: An incoming message is sent to a destination determined either through hard-wired logic,
or dynamically-based on content. Routing is a key function to enable service virtualization. Having a level of
indirection between the caller and the service allows the location of the service to be moved without the
caller having to know about the change.
Message transformation: An incoming message is transformed from one format to another. For example, a
comma-delimited message might be reformatted into SOAP so that the data can be passed to a Web service.
Protocol mediation: An incoming message is sent using a different protocol from the original. For example,
the incoming message could use HTTP, while the outgoing message might use WebSphere MQ.
Event handling: An incoming message for an event is distributed to a number of endpoints, usually through
a publication and subscription model.
Often these major high-level functions are combined in a given transaction. For example, an incoming message
might be a Web service call using SOAP/HTTP, while the destination is a legacy system requiring a fixed-length
message format using WebSphere MQ. The message must be transformed, the protocol mediated, and the message
must be routed to the correct location.
Programming for an ESB usually involves a visual environment, representing the logic as a flow of connected
activities called a message flow or mediation flow. These flows are transactional, using mechanisms such as
two-phase commit, so that the entire flow can be rolled back in the case of a failure, or committed in the case of
success. These flows are stateless; in general, a message comes in, the flow performs various operations on the
message, then an outgoing message is sent.
Given the stateless transactional nature of an ESB, high performance is a given. It's not uncommon for an ESB to
handle millions of messages each day in a large organization.
IBM has several software offerings in the ESB space. WebSphere ESB is built on the WebSphere Application
Server Network Deployment platform. It's built to support standards such as Web services, JMS, and XML.
WebSphere Message Broker (hereafter called Message Broker) is a non-J2EE product, which supports standards
found in WebSphere ESB such as Web services, as well as many non-standards based protocols and data formats.
WebSphere DataPower is a hardware appliance that can perform ESB functions at wire speed. Together, these
three offerings can be used as the basis of an ESB.

BPEL overview
The OASIS standards organization has defined the Business Process Execution Language (BPEL) as a
standards-based way of orchestrating a business process composed of services. WS-BPEL 2.0 was ratified as a
standard in 2007. As an execution language, WS-BPEL defines how to represent the activities in a business
process, along with flow control logic, data, message correlation, exception handling, and more.
IBM’s WebSphere Process Server (hereafter called Process Server) includes the business process choreographer, a
flow engine based on WS-BPEL. The previous version was called WebSphere Business Integration Server
Foundation, which also included WS-BPEL support.
Process Server has several major features including:
Business processes: Processes can be stateful and long-running, or transactional micro-flows. Long-running
processes can’t be rolled back like micro-flows, however they can have compensation handlers to undo
previously performed activities. Processes can be used to implement composite services.
Human tasks: A key part of a business process is the ability to bring people into the process. The human
task manager enables steps with people to be invoked as a service. Workflow patterns are supported through
either external (participating) tasks, or inline tasks using a BPEL extension.
Business Rules: The integrated rules engine enables business rules to be created and evaluated, rather than
hard-coding the decisions into the business process. Authorized users can update the rules using a Web
browser. Administrators can activate the updates, and export them so the development environment can be
kept in sync with the run-time.
Integrated ESB: Process Server includes the complete WebSphere ESB product. In this article, we'll only

2 of 6 09/06/2009 06:20 p.m.

BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

look at the BPEL engine component of Process Server.

SCA: Service invocations in Process Server are done using the Service Component Architecture (SCA)
specification. SCA interface maps can be used to invoke services with different interfaces than the calling
component. Interface maps also support advanced functionality, such as relationships. If System A uses
"123" as a customer identifier, but System B uses "ABC", you can use a relationship to mediate "123" to
"ABC" or vice versa, when going between the systems.

Deciding which run-time to use

As mentioned earlier, there is some functional overlap between Process Server and an ESB. Both can work with
adapters. Both can transform data. Both can support the composite service pattern. When faced with deciding the
best software to use for a given business problem, you need to decide which to use.
As an architect, you need to have a good understanding of the capabilities of both software platforms. After you've
gathered the complete set of requirements, you can begin the process of deciding.
The first order of business is to look through the requirements, and decide if one of the choices is a better fit. For
example, if a stateful process is required, you can immediately rule out the ESB. If on the other hand the
requirement is to process a message transformation in under 0.2 seconds, clearly the ESB would be the choice.
Alas, not all projects in the real world are so cut and dried. Often times, you need to examine several criteria in
order to determine the best option.
ESB strengths

One of the main strengths of an ESB is processing messages. Message in, message out, perhaps with protocol or
format mediations applied. When the requirements clearly call for message processing, an ESB is going to have
several advantages, including the ability to handle greater complexity in the transformations. If the requirements
call for one of the basic ESB functions, such as message routing, transformation or protocol mediation, an ESB
would be the clear choice.
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.
If the requirements are data-centric, an ESB is the clear choice.
BPEL strengths

The main strength of a BPEL engine is the ability to orchestrate a business process. If the requirements call for a
process with complex logic, BPEL will be a better choice. WS-BPEL has container activities, such as while loops
and scopes that ESBs don’t support. The logic in an ESB is normally straightforward, while WS-BPEL can handle
more complex cases.
Another strength of a WS-BPEL engine such as WebSphere Process Server, is the ability to have a long-running
business process where state is maintained. You should not use an ESB when state is required, since it would take a
lot of custom code to maintain the state. If the requirements call for stateful processing, you can rule out the ESB as
your choice.
If the requirements are process-centric, WS-BPEL is the clear choice.
Functional considerations

The detailed requirements for a particular project are a major factor in determining which environment best suits a
given project. Some of the important questions you need to answer are:
What transport protocols are required? Both Process Server and Message Broker support WebSphere
MQ, but only Message Broker supports IP Multicast, for example. If JMS is used, it is also important to
understand if the specific JMS provider is supported.
What standards are required? The requirements might call for WS-Security, for example, or support for a
complex industry standard schema. You need to know whether these standards are supported on the server.
Message Broker may have stronger support for untyped message processing, for example, while Process

3 of 6 09/06/2009 06:20 p.m.

BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

Server can use J2EE security, since it runs in the J2EE container. The different environments might both
support a standard, but at different levels. Be sure to check all of the details before deciding.
What are the quality of service (QoS) requirements? Does the system have to be highly available? If
Message Broker is installed in a high-availability environment, but Process Server is not, that might sway
your decision. You need to look at your particular environment to understand the QoS available. You need to
consider performance requirements, as well as requirements like guaranteed message delivery.
What routing and messaging styles are required? Various messaging styles can be used in a system, such
as synchronous or asynchronous, request/response, one-way, and publication/subscription. Which ones are
required? It could be one messaging style, or a combination of them. Which ones are supported in a given
environment? Process Server can perform message publication through JMS topics, whereas Message Broker
has more advanced functionality, such as content-based subscriptions. These requirements may help narrow
your run-time selection.
Non-functional considerations

Along with the functional requirements, every system has a set of non-functional requirements that you need to
consider when selecting the right run-time.
What is the total cost of ownership? You need to take into account the initial cost of the software, along
with the associated long-term costs. For example, if a customer will have lower costs by implementing the
solution on a J2EE platform, that could sway the decision towards Process Server.
What are the administration costs?. Every system requires an administrator. If a company already has
administrators who could be used for a new project (as opposed to having to add a new resource), it can
impact the total cost of ownership. For example, the MQ administrators might have an affinity for Message
Broker, where as a J2EE-based run-time could have a steeper learning curve for them. You should also
considered how easy the environment will be to monitor, as well as the security aspects that administrators
deal with.
What skills are needed? Along with administrators, developers, testers, and other roles will be needed. If
existing skill sets can be leveraged, you may realize time and cost savings associated. Learning new skills for
a project may require training or a mentoring services engagement.
What does the existing environment look like? Is the middleware environment already in production? Are
users familiar with the tool set? If new tools are required, what are the affinities with the current tooling
environment? Are your current version levels for the prerequisite software in sync, or will you have to
upgrade existing assets? Are any migrations required before you can use the system?
Does one of options offer unique functionality? A unique function in one of the environments could drive
your decision. For example, you can perform mapping in an ESB or through an interface map in Process
Server. But only interface maps in Process Server offer relationship mapping. If you require this function,
only Process Server can provide it.
When both Process Server and the ESB seem to be good candidates, the non-functional requirements can often
narrow the selection.
Patterns

Patterns for e-business are a group of proven, reusable assets you can use to increase the speed of developing and
deploying e-business applications. IBM publishes a series of Redbooks that describe the use of patterns with
various technologies, such as Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
You can examine your requirements, and determine whether patterns can be used to implement them. If an existing
pattern or a combination of patterns has already been proven for a given run-time, you'll know that the run-time is
capable of handling your requirements. Risk will be lower, since it has been done before, and development time
can be shortened by applying the pattern. If the pattern exists on only one run-time, that can help you in making
your decision.
Some typical patterns are:
Message aggregation and disaggregation (N-to-1 and 1-to-N)
1-of-N responses (send multiple requests, pick one response)
Service virtualization (location and identity)
Content based routing
Adapter interaction
Message enrichment
Dynamic registry lookup

4 of 6 09/06/2009 06:20 p.m.

BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

Event propagation
Gateway (controlled and secure interaction between internal and external domain boundaries)
For example, the referenced Redbook describes the use of DataPower using the gateway pattern. The XS40 XML
Security Gateway meets the functional and non-functional requirements to support this pattern. This could help
drive your decision if you were looking at which solution to use in order to implement the gateway pattern.
Gray areas

Even after using the criteria in the preceding sections to pare down to the final decision, there will still be cases in
which you could choose either an ESB or Process Server as the run-time for a given project. In these cases, there
are a few other things you can consider.
Design philosophy
Some companies have an overall design philosophy that guides all of their projects. For example, you may decide
that all transformations are to take place in the ESB, while all business logic is to reside in the Process Server.
If a customer places an online order, the business decision to decide if they qualify for free shipping would belong
in the business logic layer, running in Process Server. The routing of a message to the appropriate shipping service
would be done at the ESB layer. This allows the company to alter the business logic, without having to make
changes to the integration logic (and vice versa).
This overall design philosophy should weigh in on the decision. In other words, what is the strategic direction? If
all other things are equal, you can use this as your criteria.
Cost
Each WS-BPEL process or mediation flow you deploy will consume CPU capacity on the server where it is
deployed. The middleware it runs on has a cost, of course, along with hardware costs, support costs,
administration, and so on. If it is not clear which environment to use, the cost may factor into the decision of where
to deploy.
Maintenance
You need to take the overall long-term maintenance of the system into account when deciding which platform is
the right one for a given business problem. If using a WS-BPEL correlation set would be easier than writing and
maintaining code to provide a similar capability in an ESB, not only would you be able to build your solution
faster, but it would be easier to maintain. Any time a built-in primitive function is available, that will be a better
design alternative than creating custom code. The easier to maintain solution is highly preferred.
Another aspect of maintenance is how easy it will be to upgrade your solution in the future, as middleware
products evolve. In general, major new releases have the ability to use artifacts from previous releases. WebSphere
Integration Developer, the tooling for WebSphere Process Server V6, can import integration projects from
WebSphere Business Integration Server Foundation V5.1 to use the previous project as a starting point. Logic in
the WS-BPEL process carries forward into the new environment. However, you may need to do some manual work
to update Java™ code in the process. In most cases, using built-in functions from the software products makes
future upgrade paths easier.
Reusability
Whenever constructing any assets for an SOA, you should ask how to drive reuse of that asset. When something is
created, it can solve a business problem. But if it can be reused, you can realize tremendous savings in
development time and cost.
Using the earlier example of the online order, you could use either an ESB or a WS-BPEL micro-flow process to
perform the entire job. If the business logic was broken out to WS-BPEL, with the routing logic in the ESB, there
is a greater chance of reusability. With both functions in a single environment, the service could be used only once,
for the specific purpose it was designed for. By separating out the functions, there is a greater chance that either
one of them could be reused. For example, the in-store shipping system could leverage the routing service. You
should consider the potential reusability of the solution you are creating when making your decision.
Skill strength
Your I/T staff may have stronger skills in one product over the other. For the long-term support of your project, the

5 of 6 09/06/2009 06:20 p.m.

BPEL or ESB: Which should you use? http://www.ibm.com/developerworks/websphere/library/techarticles/0...

stronger skill set might be the tie-breaker in your decision. For example, if you have three strong ESB developers,
but only one for Process Server, it might make sense for you to build the project using your ESB.
Risk
Successful projects are ones where the risks have been mitigated so that there is very little chance of the project
failing. If you've implemented five modules in Process Server, but you're just starting out with Message Broker,
you could view using Process Server as having a lower risk, since you have more experience with it.
Likewise, you might find several references and case studies for systems similar to what you need to implement. If
several other customers have done it successfully with Message Broker, you'd have some assurances that you're not
stretching the product boundaries. If others have been successful on similar projects, your risk is lower.
After assessing all factors that contribute to risk in your project, you may be able to use the lowered risk as your
final decision-making criteria.

Summary
In this article, you learned about ESBs and WS-BPEL process engines and how to decide which offers the best
solution for your environment. You learned the strengths of each environment, and how to take criteria such as
functional and non-functional requirements into consideration, as well as how to apply patterns. Finally, you
learned some of the additional criteria that might help you make your decision in cases where either solution seems
to be able to fit the bill.

Resources
WebSphere SOA zone: Get the latest technical resources for WebSphere SOA solutions, including articles,
tutorials, downloads, and more.

WebSphere Web services zone: Get the latest technical resources for WebSphere Web services solutions,
including articles, tutorials, downloads, and more.

Patterns: Implementing an SOA Using an Enterprise Service Bus: This IBM Redbook focuses on how the
service-oriented architecture profile of the Process Integration patterns can be used to start implementing
service-oriented architecture using an Enterprise Service Bus.

Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB: This IBM Redbook
discusses patterns for integrating WebSphere ESB and WebSphere Message Broker and includes a scenario
to help you design, develop, and deploy these products.

About the author

Marc Fasbinder is a BPM Integration Solution Architect at IBM with the WebSphere Technical Sales
team in Southfield, Michigan. You can reach him at mfasbind@us.ibm.com.

Share this....
Digg this story del.icio.us Slashdot it!

6 of 6 09/06/2009 06:20 p.m.