08/06/12

BPEL or ESB: Which should you use?

English Sign in (or register)

Technical topics

Evaluation software

Community

Events

BPEL or ESB: Which should you use?

Marc Fasbinder, BPM Integration Solution Architect, IBM Summary: 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. Date: 12 Mar 2008 Also available in: Japanese Activity: 26891 views Comments: 2 (View | Add comment - Sign in) Average rating (70 votes) Rate this article 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 twophase 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 requirements. These different products can be federated together as the realization of the ESB
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 1/7

08/06/12

BPEL or ESB: Which should you use?

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. IBMs 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 cant be rolled back like microflows, 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 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
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 2/7

08/06/12

BPEL or ESB: Which should you use?

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 dont support. The logic in an ESB is normally straightforward, while WSBPEL 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 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
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 3/7

08/06/12

BPEL or ESB: Which should you use?

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 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 stronger skill set might be the tie-breaker in
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 4/7

08/06/12

BPEL or ESB: Which should you use?

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 an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan. Close [x]

developerWorks: Sign in
IBM ID: Need an IBM ID? Forgot your IBM ID? Password: Forgot your password? Change your password Keep me signed in. By clicking Submit, you agree to the developerWorks terms of use.
Submit Cancel

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 5/7

08/06/12

BPEL or ESB: Which should you use?

post. All information submitted is secure. Close [x]

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks. Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons. Display name: (Must be between 3 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

Submit Cancel

All information submitted is secure. Average rating (70 votes) 1 star 2 stars 3 stars 4 stars 5 stars
Submit

1 star 2 stars 3 stars 4 stars 5 stars

Add comment: Sign in or register to leave a comment. Note: HTML elements are not supported within comments.

Notify me when a comment is added1000 characters left

Post

Total comments (2) excellent article - I was looking for use cases for a Service Bus vs BPEL Engine and this article has really clarified my ideas. A lot depens also on the custom logic one is able to embed in a solution - most commercial solution have limited support for this, often only available through a Java Callout. Posted by PierluigiVernetto on 15 December 2010 Report abuse Very well written article.. Thanks Marc Posted by Sankara on 02 March 2010
www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html 6/7

08/06/12

BPEL or ESB: Which should you use?

Report abuse
Print this page Share this page Follow developerWorks

About Help Contact us Submit content

Feeds and apps Newsletters

Report abuse Terms of use IBM privacy IBM accessibility

Faculty Students Business Partners

www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

7/7