BPEL or ESB: Which should you use?http://www.ibm.com/developerworks/websphere/library/techarticles/0...1 of 609/06/2009 06:20 p.m.

BPEL or ESB: Which should you use?

Marc Fasbinder (mfasbind@us.ibm.com), BPM Integration Solution Architect, IBM12 Mar 2008When designing an SOA solution, it's not always clear whether you should use a Web services BPELprocess or an ESB mediation flow. This article describes considerations that will help you decidewhich 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 areasuch 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 processservices in the reference architecture. It evolved from WebSphere MQ Workflow, WebSphere Interchange Serverand 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 includedbusiness 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 primaryfunctions in an ESB. Therefore, if you have both Process Server and an ESB, you need to make a decision aboutwhich 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 threeexisting services need to be called, using a two-phase commit. This is known as a

composite service

. You could usea 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 coulduse 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 somecases, companies use multiple products in different areas, leveraging specific functionality to meet their unique

BPEL or ESB: Which should you use?http://www.ibm.com/developerworks/websphere/library/techarticles/0...2 of 609/06/2009 06:20 p.m.

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 thecaller having to know about the change.

Message transformation

: An incoming message is transformed from one format to another. For example, acomma-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 througha publication and subscription model.Often these major high-level functions are combined in a given transaction. For example, an incoming messagemight be a Web service call using SOAP/HTTP, while the destination is a legacy system requiring a fixed-lengthmessage format using WebSphere MQ. The message must be transformed, the protocol mediated, and the messagemust be routed to the correct location.Programming for an ESB usually involves a visual environment, representing the logic as a flow of connectedactivities called a message flow or mediation flow. These flows are transactional, using mechanisms such astwo-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 themessage, 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 tohandle 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 ApplicationServer 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 standardsfound 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, thesethree 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 astandards-based way of orchestrating a business process composed of services. WS-BPEL 2.0 was ratified as astandard in 2007. As an execution language, WS-BPEL defines how to represent the activities in a businessprocess, 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, aflow engine based on WS-BPEL. The previous version was called WebSphere Business Integration ServerFoundation, 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-runningprocesses can’t be rolled back like micro-flows, however they can have compensation handlers to undopreviously 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 humantask manager enables steps with people to be invoked as a service. Workflow patterns are supported througheither 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 thanhard-coding the decisions into the business process. Authorized users can update the rules using a Webbrowser. Administrators can activate the updates, and export them so the development environment can bekept in sync with the run-time.

Integrated ESB

: Process Server includes the complete WebSphere ESB product. In this article, we'll only

BPEL or ESB: Which should you use?http://www.ibm.com/developerworks/websphere/library/techarticles/0...of 609/06/2009 06:20 p.m.

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 callingcomponent. 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 withadapters. Both can transform data. Both can support the composite service pattern. When faced with deciding thebest 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'vegathered 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. Forexample, if a stateful process is required, you can immediately rule out the ESB. If on the other hand therequirement 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 inorder 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 orformat mediations applied. When the requirements clearly call for message processing, an ESB is going to haveseveral advantages, including the ability to handle greater complexity in the transformations. If the requirementscall for one of the basic ESB functions, such as message routing, transformation or protocol mediation, an ESBwould 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 thebetter 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 aprocess with complex logic, BPEL will be a better choice. WS-BPEL has container activities, such as while loopsand scopes that ESBs don’t support. The logic in an ESB is normally straightforward, while WS-BPEL can handlemore complex cases.Another strength of a WS-BPEL engine such as WebSphere Process Server, is the ability to have a long-runningbusiness process where state is maintained. You should not use an ESB when state is required, since it would take alot of custom code to maintain the state. If the requirements call for stateful processing, you can rule out the ESB asyour 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 agiven project. Some of the important questions you need to answer are:

What transport protocols are required?

Both Process Server and Message Broker support WebSphereMQ, but only Message Broker supports IP Multicast, for example. If JMS is used, it is also important tounderstand if the specific JMS provider is supported.

What standards are required?

The requirements might call for WS-Security, for example, or support for acomplex 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