You can serialize BPMN into BPEL, but BPEL should not be the serialization standard

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Jesper Joergensen's Blog | April 14, 2008   8:16 PM | Comments (0)

Bruce has written another chapter (and follow-up) in the developing story of BPMN and BPEL in a response to a post by Keith Swenson. Bruce is, as always, spot on. (I just wish he would include AquaLogic BPM when he mentions products that can execute BPMN.)

As Bruce explains, BPMN is not always easy to map to BPEL and the reason is that BPMN allows you to draw a full graph while BPEL is block oriented (Bruce's examples illustrates it well). The pro-BPEL folks say that this is not a problem because you can always devise a strategy  to "unfold" the graph into a block structure. That's true, you can always find a way to represent a BPMN diagram in BPEL. But the way you choose to do this is likely to be your way. It will not be standardized. Therefore, the same BPMN diagram will end up looking different in BPEL depending on your tool/engine/custom method.

In theory, when the process executes, this doesn't matter. The "unfolding" should not change the behavior specified by BPMN, so the result of the execution should be the same if two different strategies are chosen. But the problem is that the strategy is proprietary. For example, A BPMN compliant BAM tool doesn't know how to show process trace for a process executed in BPEL. A BPMN compliant simulation tool cannot take the BPEL file and turn it back into the original BPMN file because it doesn't know the strategy used to go from BPMN to BPEL.

Now you might say: Why don't we just create a standardized mapping from BPMN to BPEL?

Yup. That would work. It would solve those problems. But the thing is, then we need to create this new standard. And if we need to create a new standard, then the whole reason for trying to use BPEL as the serialization standard (reason being that the standard already exists) disappears.

To use BPEL as a serialization standard for BPMN, we will have to create another standard anyway. That standard being the mapping of BPMN to BPEL.

The other approach is to create from scratch a serialization format for BPMN, aka a meta model; basically a schema for how to represent a BPMN diagram as a data structure. I like this approach much better.

The importance of BPMN lies in the need for a familiar visualization of business processes that is maintained across repositories, execution engines, BAM tools (process auditing), modeling environments etc. I believe this requires a BPMN-centric meta model. Let me explain: Say you don't have a BPMN meta model, but you have BPEL plus a standardized serialization method. If you're building a BAM tool where you want to show alerts, queue sizes etc. rendered on the process diagram itself, you will have to take the BPEL and apply the de-serialization strategy to turn it back into BPMN (remember, no one will be familiar with the BPEL for visualization because it was not used to build the original model, it was generated from BPMN using the serialization method). Doing this will require you to invent your own meta model for BPMN so you can store and render the resulting BPMN diagram in your application. It's pretty likely that no two applications will invent the same BPMN meta model and thus the diagrams will look and/or behave different even if it wasn't intended. This is the wrong track. It is too error-prone, requires unnecessary duplication of work (many meta models) and it forces too much focus on BPEL when BPEL is really mostly relevant for execution. BPEL is not suitable for business process modeling because it's too restrictive and machine oriented. This has been acknowledged pretty widely in the industry, so I hope it's not a controversial statement.

This is not a criticism of BPEL as an execution format. But it appears much more sensible to standardize a meta model for BPMN and then let vendors build implementation specific mappings to BPEL from there.

Comments