In his post about Which is simpler: BPMN or BPEL?, Michael Rowley kicked-off another round of discussion about the use of BPEL vs the use of BPMN. Bruce Silver responded in his post BPMN vs BPEL: Are we still debating this?, which in turn triggered Michael Rowley to his post BPMN 2.0 with BPEL - the debate is just starting.
The most important aspect of BPEL that cannot be emphasized enough is that BPEL exists, and that it is supported by most BPM middleware vendors in their products. This results in the portability of skills and interoperability between tools that Michael points out – and that I want to repeat here. Former attempts to standards in this area did not achieve this at such a broad scale. Thus, BPEL is an important cornerstone of BPM technology. Especially, BPEL became the BPM runtime standard (i.e., I completely contradict Bruce’s corresponding opinion here).
BPEL focuses on providing a language for specifying business processes and provides a precise operational semantics for executing processes specified in this language. In doing so, BPEL combines two different approaches to specify business processes, namely a programmatic (or block-oriented) approach as well as a graph-oriented approach. Yes, BPEL in fact is graph-oriented despite the many other claims – Bruce in his post is on the same wrong path and Michael gives an example of BPEL’s graph-orientation. The combination of these two approaches in fact is of utmost importance: both approaches had been supported by products at the time the work on BPEL began. Without this combination in BPEL the chasm between the two approaches and corresponding product worlds would have deepened – with obvious impact on the industry.
By focusing on language aspects and operational semantics aspects of modeling business processes, BPEL left the visual representation dimension of such process models completely out of scope. This dimension became the domain of BPMN 1.x which now fills this gap. By providing a visual modeling language for business processes, BPMN enables non-IT experts to communicate and mutually understand their models: a big progress in this area resulting in the wide-spread use of BPMN.
Business processes specified in BPEL are nearly always modeled with their future execution in mind. More and more, processes modeled in BPMN are also not only modeled for documentation purposes but for purpose of their execution. Because of the wide-spread support of BPEL by middleware vendors the use of BPEL engines for BPMN execution is an obvious choice. To enable the execution of BPMN process models in BPEL engines, the transformation of BPMN process models to BPEL process models is needed. But the metamodel underlying BPMN and the metamodel underlying BPEL are not identical; in fact they are quite different. Thus, the transformation is not straightforward and sometimes requires complex mappings resulting in a BPEL process model that look quite different from the original BPMN process model (quite a number of publications exist that dive deep into this).
Consequently, we are faced with the following problem: How can we bridge the gap between BPEL (an execution language with rigor operational semantics) and BPMN (a visual language with informal semantics).
One possible way to solve this problem is to standardize a visual representation for BPEL. This is possible as can be seen by the many tools providing a graphical editor for BPEL process models. But the problem is that BPMN contains quite a number of constructs that are used by BPMN modelers in practice (e.g. arbitrary backward loops, gateways) and that these constructs have no direct correspondence in BPEL. Thus, BPEL extensions would be needed to support these constructs to allow for immediate seamless graphical representations as required by BPMN users. But extending BPEL is time consuming (see the recent BPEL4People extensions) while BPMN users want to see a solution “soon”. And most importantly following the way of creating a new visual language would introduce a new chasm in BPM technology.
The other way to solve the problem – the way that has been taken – is to move BPMN forward in order to bridge the gap between BPMN and BPEL, i.e. to make transforming BPMN process models to BPEL much easier. The fundamental enhancements of BPMN 2.0 that enable this are (i) the addition of visual elements for BPEL handlers, (ii) the specification of a pattern-based approach of mapping a subset of BPMN to BPEL, (iii) an XML-based exchange format, and most importantly (iv) the definition of an operational semantics for BPMN that is close to BPEL (for that parts that correspond to BPEL). Effectively, BPMN 2.0 includes a subset of language elements that represent a visual language for BPEL and that can be naturally executed by a BPEL engine. This is a huge progress from a practical point of view.
Yes, it is a subset of BPMN 2.0 that is naturally supported by BPEL. And, yes, Michael is right that BPMN 2.0 has increased in terms of complexity. Partially, this increase in complexity is owing to support the execution of BPMN 2.0 process models, which required precision in terms of type systems, service models etc. And BPMN 2.0 had to add new features required by domain users – which are the other cause for the increase of complexity in BPMN. The latter kind of features is not mapped to BPEL by the BPMN 2.0 specification. This is because some of these BPMN features are out scope of BPEL (like BPMN conversations), and for some other features it is still under discussion whether or how they should be support by BPEL at all (like BPMN choreographies).
From a BPEL perspective the current situation is as follows: A subset of BPMN 2.0 is “isomorphic” to BPEL. As a consequence, BPMN 2.0 encompasses a visual modeling language for BPEL – this subset can be naturally transformed to BPEL and executed in a BPEL engine. From an architectural point of view, a tool supporting this BPMN subset is a layer on top of BPEL engines – just like a data modeling tool supporting an entity-relationship model or an object model can be seen as a layer on top of relational database systems.
From a BPMN 2.0 perspective, the situation is as follows: BPMN 2.0 is a process modeling language with an operational semantics imprinted by BPEL (i.e. BPMN 2.0 builds on the success of BPEL). Thus, it is now possible to build an engine that directly supports BPMN 2.0 – without the intermediate step of generating BPEL. In other words, no BPEL at all is required to execute process models specified in BPMN 2.0. Just like database systems have been build in the past that support entity-relationship models or object models directly without the need for using relational database systems (I come back to this analogy below).
The question I ask is: Why should domain users care about the metamodel of an engine anyhow? Today, nearly nobody really cares about the metamodel of a BPEL engine at all! Yes, you might be surprised about this statement, but many BPEL engines do not support BPEL “natively”. What characterizes a BPEL engine at first sight is that it supports the import of a process model specified in BPEL. After that, it typically digests the BPEL file and generates internal artifacts from it (e.g. it disperses the various BPEL elements across different tables; it creates Java representations from it; etc.). These internal artifacts, how they relate, and how they and their relations are interpreted by the implementing engine are what I call the engines native metamodel. And the native metamodel of a BPEL engine might be quite different from the BPEL metamodel. What determines the internal metamodel of an engine is what the engineers building the engine chose to ensure efficiency, scalability etc of the execution. Admittedly, the modeling language(s) to be supported at the time of the creation of the first release of the engine has deep impact on the internal metamodel of the engine. But good engine engineers take care about generality and extensibility of the internal metamodel striving towards “straightforward” support of extensions of the original modeling language(s) and even new modeling languages.
Similarly, you should not care about the native metamodel of the engine executing your BPMN process model: whether your BPMN process model is executed by a BPEL engine or by a new BPMN engine is not important. Similar to what I wrote above, the native metamodel of a BPMN engine is likely to be different from BPMN anyhow. I.e. the BPMN process model that you import in such a BPMN engine will be transformed into a representation according to the internal metamodel. And this internal metamodel might be one that supports BPEL today. I.e. a vendor of a BPEL engine that provides import capabilities for BPMN process models might become a vendor of a BPMN engine based on the very same execution engine. Note, that it is absolutely valid that an intermediate BPEL process model from the BPMN process model is generated before the actual import takes place – you might not even be aware of this intermediate BPEL file at all.
But what you should care about your BPMN 2.0 engine is its robustness, efficiency, scalability etc. Providers of today’s BPEL engines typically have invested a lot into these non-functional properties of their engines. Thus, such vendors have the capabilities to offer BPMN engines with these non-functional properties too.
Finally, let me come back to the analogy from the database domain sketched before. When modeling data based on the object paradigm became important to domain users, database management systems have been built that supported the corresponding metamodel directly (“object oriented database systems”). But over the time existing relational database systems as well as the relational model itself have been extended to support key constructs of the object paradigm (“object-relational model”). Maybe the same will happen with existing BPEL engines and BPEL itself, i.e. that BPEL gets extended to support key features of BPMN 2.0 that are missing in BPEL and BPEL engines today? This is an interesting possibility, especially under the light of what Bruce says, namely that it is likely that no vendor will support all of BPMN 2.0 in its product. According to this opinion, subsetting of BPMN 2.0 will always happen and domain users will have to live with restricted support of BPMN 2.0 in corresponding modeling tools and runtime engines. Maybe this will give BPEL and those BPEL engines supporting “just” the BPEL-isomorphic BPMN 2.0 subset time to catch up to finally support the relevant missing elements of the BPMN 2.0 metamodel.
Comments