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.
: 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.
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.
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.
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