BPM vs ESB - Orchestration?

Question

Can we safely say that if ESB provides Orchestration features, it is eligible to be an implementation of BPM?

I understand that BPM has a different purpose, which is to Model some business processes and the implementation of those business processes can be done by any simple Java/J2EE application, complex SOA application, or some application saying that I provide BPM. Is that right?

Debus

Answer 1

First Question:

Your statement is valid for some business processes which merely models request-response interaction.

But when it comes to complex business processes we need to consider some other features apart from orchestration features. Here I have list down few such scenarios.

1. Let's take a business process which requires to maintain its state for a long period of time. We normally call them state-ful or long running business processes. To support these sort of business processes, there should be a state persistence mechanism. This functionality is not relevant to orchestration features.
2. Consider a business process, which requires some compensation capabilities. In that case, some of the business process modelling standards like, WS-BPEL have defined its compensation mechanisms. So apart from orchestration features, there are some other features which are needed to be considered.

Second Question:

Yes. But there are several pros in a BPM engine compared to your mentioned implementation mechanisms.

One advantage is, it's not possible to achieve a level of modelling abstraction provided by a BPM engine from a Java application. Let's say we used a JAVA application to implement a business process logic and that business process went to production. Say we need to change a endpoint URL of its partner service. In this case, now the business process implementation need to be modified, re-compiled and deployed back into the production system. if we implement the business process with a business process language standard like WS-BPEL, we can change the business process configuration very easily and push it back to the production. This improves the efficiency and reduce the business maintenance cost. As well there are other reasons like easy adaptability and flexibility.

Shelley

Perfect answer! Thanks for the explanation. (#346249) this question is also very similar and has been answered beautifully. – Debus

Answer 2

I've created these slides some time ago to explains exactly how you can use them both and the relationships between them: http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers

You need to understand the different perspective between something like BPEL/ESB/Orchestration and BPMN (business oriented) they have very different scopes.

Cheers

Whiffler

This seems to be a great presentation. I would want to give +20 for the presentation, not sure if that's possible. – Debus

I have few questions on the presentation e.g. I thought we can safely say "A workflow can be represented as / is a process". From the presentation, is seems this is not correct. Need reasons/differences. Can I have a discussion/chat/mail exchanges in similar questions? – Debus

A Business Process can be considered to be a more high level, business related representation. If you are a technical person you need to try to not confuse that with a state machine that you can use for a very technical purpose, which is not relevant for the business people. You can write questions to my blog if you want: salaboy.com – Whiffler

Answer 3

Normally ESB is assigned to the middle layer — orchestrating low-level services into larger service units, which will be exposed to the business for use in processes — and BPMs in the top layer.

So BPM will be used in the Business Process Orchestration Layer and ESB will enable and facilitate this by working in the Business Services and Service Enablement.

In another words to be successful with business processes first you need to have all your systems and apps exposed as services; that is where an ESB comes into play.

You could see this link : http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/

Blizzard

Answer 4

Let me add clarity by making the distinction between BPM, Orchestration, and ESB, via design patterns and specifications.

Generally speaking, "Orchestration" has been defined as a compound pattern employing the Process Abstraction, Process Centralization, and the State Repository design patterns. By virtue of the implementation of the State Repository Pattern and contrary to a previous post, Orchestration supports long running, synchronous business processes, just like BPM.

The major practical distinction between the 2 is that Orchestration middleware (e.g. WebSphere Process Server, BizTalk, Oracle BPEL Manager, and Windows Workflow Foundation) supports most of the WS * specifications. This includes Ws BPEL, Ws Security, Ws Atomic Transaction, Ws Business Activity, Ws Reliable Messaging, etc., while most BPM Tools do not.

As a result, feel free to use Orchestration at an Enterprise Level, but be very careful about using BPM in that scope.

In practice, both BPM and Orchestration tools enable the graphical representation of a business process. The distinction is that Orchestration may be expressed through Vendor-Neutral BPEL (Business Process Execution Language), while BPM is expressed via Vendor Specific BPMN (Business Process Modeling Notation). This is another reason to avoid BPM tools at the SOA/Enterprise Level.

In cases where a BPM Tool implements the Ws * specifications, it is an Orchestration Engine for all practical purposes. The distinction again being that BPM tools rely on Vendor-Specific BPMN and Orchestration tools rely on Vendor-Neutral BPEL.

In cases where both BPM and Orchestration need to coexist, limit BPM to application architecture (e.g. MVC style) and let Orchestration promote the sharing of enterprise assets.

An ESB is an entirely different animal. It should used for asynchronous, rather than synchronous processes and relies on a different set of design patterns (i.e. Service Broker, Asynchronous Queuing, Intermediate Routing, and the Content Enricher patterns)

Camouflage