BPM vs ESB - orchestration?

Question

Is it safe to say that if the ESB provides Orchestration features, it can be an implementation of BPM?

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

Answer 1

First question:

Your expression is valid for some business processes that simply simulate the interaction of a request and a response.

But when it comes to complex business processes, we need to consider some other functions besides the functions of orchestration. Here I list a few of these scenarios.

• Let me adopt a business process that requires maintaining its state for a long period of time. Usually we call them government or long-term business processes. To support such business processes, a state preservation mechanism must exist. This functionality is not related to orchestration functions.
• Consider a business process that requires some offsetting capabilities. In this case, some business process modeling standards, such as WS-BPEL, have defined compensation mechanisms. . Thus, in addition to the features of orchestration, there are some other functions that must be considered.

Second question:

Yes. But there are several profiles in the BPM engine compared to your mentioned implementation mechanisms.

One of the advantages is that it is not possible to achieve the level of modeling abstraction provided by the BPM engine from a Java application. Let's say we used the JAVA application to implement the logic of business processes and the business process. Say we need to change the endpoint URL of his affiliate service. In this case, it is now necessary to change, recompile and deploy the business process into a production system. if we implement a business process using a standard business process language, for example WS-BPEL , we can easily change the configuration of the business process and return it back to Production. This improves efficiency and reduces the cost of servicing a business. There are also other reasons, such as easy adaptability and flexibility.

Answer 2

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

You need to understand a different perspective between something like BPEL / ESB / Orchestration and BPMN (business-oriented), they have very different areas.

Greetings

Answer 3

Typically, an ESB is assigned to a mid-tier — organizing low-level services into larger service units that will be available to the business for use in processes — and BPM at the top tier.

Thus, BPM will be used at the level of business process orchestration, and the ESB will allow and facilitate this by working in Business Services and Service Enablement.

In other words, in order to successfully work with business processes, you need to have all your systems and applications that will be displayed as services; That's where the ESB comes into play.

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

Answer 4

Let me add clarity by distinguishing between BPM, Orchestration, and ESB, using design patterns and specifications.

Generally speaking, Orchestration has been defined as a composite model using process abstractions, process centralization, and state store design patterns. Due to the implementation of the state repository template and contrary to the previous mail, Orchestration supports long synchronous business processes like BPM.

The main practical difference between 2 is that Orchestration middleware (such as 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 enterprise-level Orchestration, but be very careful about using BPM in this area.

In practice, BPM and Orchestration tools provide a graphical representation of the business process. The difference is that Orchestration can be expressed through the Vendor-Neutral BPEL (Business Process Execution Language), while BPM is expressed using the Specific Provider> BPMN (Business Process Modeling Designation). This is another reason to avoid using BPM tools at the SOA / Enterprise level.

In cases where the BPM tool implements the Ws * specifications, it is an orchestration tool for all practical purposes. The difference, again, is that BPM tools rely on vendor-specific BPMN and Orchestration tools, based on the Vendor-Neutral BPEL.

In cases where both BPM and Orchestration must coexist, restrict the BPM to the application architecture (such as the MVC style) and allow Orchestration to facilitate the sharing of enterprise assets.

ESB is a completely different animal. It should be used for asynchronous rather than synchronous processes and relies on a different set of design patterns (i.e. Service broker, asynchronous queue, intermediate routing, and Content Enricher patterns)