This is the eleventh edition of our weekly BPM 2.0 post. Today, I will try to explain why interpreting BPEL code natively is important. When you are a software vendor and you have invested tens if not hundreds of man-years into the development of some proprietary process engine, it is very tempting to add a simple translation layer that would turn BPEL code into what your engine can digest. Customers should shy away from such solutions though, for they create more problems than they really solve.

Some of the issues to be aware of are described in the original article on BPM 2.0, therefore I will focus today on some additional considerations. First and foremost, translating BPEL into another proprietary language creates the temptation to modify executable code at that level, which adds a third layer underneath BPMN and BPEL, and makes the task of supporting roundtrip engineering twice as difficult as it should be. To keep things simple, BPMN should be serialized in a canonical way using technologies such as the MOF or EMF, then translated into BPEL code at deployment time. This is pretty much how client-server database development tools have been working using UML and SQL for years, and process development tools are not much different in that respect.

Furthermore, not adopting a native BPEL execution model creates an impedance mismatch between the semantics of process execution defined by BPEL and the one supported by the proprietary runtime. In most cases, this leads to the development of process engines that will only support a subset of the BPEL specification, while adding some extra features that require proprietary extensions. If you believe in the benefits brought by industry standards, this is bad, plain and simple.

Additionally, vendors that invented their own language and built support for it within their process design tool and their process runtime usually have a base of legacy customers to take care of. If the migration strategy is to support both languages within both the tool and the runtime, the required engineering effort is at least four times as significant as supporting a single execution language. As a result, it is very likely that the needs of legacy customers will prevail over the needs of prospective customers, and support for BPEL will be poor at best.

Like it or not, BPEL is a very powerful yet extremely complex language, especially with version 2.0 of the specification, and supporting it properly is no simple task. If you’re a BPM vendor and find yourself in the position where customers are asking for it, I would strongly recommend that you embrace it fully and migrate your existing customers to a next-generation product that implements native support for the specification, and nothing more. And if you’re an end-user my advice is even more radical: do not consider using any product that is not natively built around BPEL, for you will pay the price of not being standard-compliant down the road.