Business Intellegence

Reexamining the Limitations, Expectations, Capabilities and Misunderstandings of BPEL, as well as Executing BPMN Directly It seems that conventional wisdom has been for a while that "Business Process Execution Language" or "WS-BPEL4WS" is the standard for execution in the BPM space. At the same time, the majority of BPM and workflow products on the market today work successfully without using BPEL. Some say that those products that don't implement BPEL are simply dragging their feet in the mud. Others say it is not possible to do what their product does in BPEL. Whom are we to believe? It is after all, a complex subject. Recently an article was written on InfoQ which took a particular process scenario drawn in Business Process Modeling Notation (BPMN), and investigated in detail why it can not be implemented using BPEL. That process can, however, be run on a system that directly executes BPMN. This article explores exactly how this is possible, giving a step by step example of a running system executing the process in question. Since you can execute the BPMN directly, it begs the question: why translate to BPEL at all?

Finally a well considered and detailed article on the limitations of the approach to BPEL.

There are a few vendors who promote BPEL as as the one-and-only-true-way to support BPM. In fact, it is good for some things, but fairly bad at a large number of other things. It is my experience that BPEL is promoted primarily by vendors who specialize in products we might rightly call “Enterprise Application Integration” (EAI). These companies have recently taking to calling their products “Business Process Management”. Potential users should be asking the question “Is BPEL appropriate for what I want to do.” In that aim, there should be a large number of articles discussing what BPEL is good for, and what it is not, but there are very few articles of this nature.

The article “Why BPEL is not the holy grail for BPM” explores the promises and claims of the BPEL proponents and find some serious gaps in what BPEL delivers.

It starts by citing a reference that every should know from the BPMN FAQ: “By design there are some limitations on the process topologies that can be described in BPEL, so it is possible to represent processes in BPMN that cannot be mapped to BPEL”.

In my experience, fans of BPEL make the following assumptions:

1. The people making the processes are programmers
2. The activities in a process only need to send, receive, or transform XML data
3. Any standard will be better than no standard

Assumptions (1) and (2) are valid in some situations; the product category that we call EAI is in fact configured primarily by programmers, and need only to send, receive, and manipulate bytes of data. So for EAI, BPEL might be a reasonable choice. But many BPM products are designed to be configured by non-programmers; by the business people themselves (and that is indeed why we call them business processes in the first place). Non-BPEL approach exist that allow non-programmers to draw up and execute processes, safely and reliably. Those processes are qualitatively different from the processes a programmer might draw up, and many people familiar with EAI-style “BPM” are incredulous, but that basically circular reasoning based on the assumption that the process designer is a programmer. To be fair, some believe that business people will draw up initial process diagrams, that will then be fixed up by programmers. But there are other situations where there is a no programmer at all, and that in those situations BPEL would be a poor choice.

Assumption (3) drives people to think that since there is overwhelming “magazine” evidence that BPEL is the right standard, then anyone not supporting BPEL is simply too lazy or trying to disrupt the marketplace. Unfortunately for these people, the process world is inherently more complex than they realize; the variations among approaches are not simply the randomness of vendor whim, but in fact an appropriates response to the variations in the needs for process support. People should keep in mind real requirements: if BPEL meets the need, then fine, but don’t blindly assume that one size will necessarily fit all.

We need more good articles on the situations that BPEL is, and is not, useful. And let us view with great suspicion any report that states that BPEL is unconditionally the right architecture for all processes.

The article “Why BPEL is not the holy grail for BPM” presents a scenario for implementation which is difficult for BPEL based products to actually execute. It presented a particular product based on BPEL that was not able to execute this diagram. What about products that are based on executing the BPMN directly without conversion?

Fujitsu Interstage BPM is such a product. You draw the BPMN diagram, and submit the diagram to the server, and the server executes it directly. It has no problem executing the diagram as drawn. Here is the diagram as drawn in the Fujitsu Studio:

Some slight modifications: Instead of an “activity” receiving the start message, I use a start-event which receives the message. I don’t understand why people draw processes that start and then immediately go to an activity that waits for something — a start event does this much more clearly. There are many who feel that waiting for a message should always be done by an event node, and never an activity node, and that certainly seems to make sense to me. Using the start node to be triggered by the incoming message is the same semantics. Similarly, the original diagram had a final activity which was not really an activity

This is saved as XPDL. I do not say that this is transformed to XPDL, because there is no transformation. The diagram above is expressed directly, one-for-one, into XPDL which is simply a file format for storing BPMN diagrams. When you read the XPDL back in, the same BPMN diagram as you see above is displayed. XPDL is simply used as a file format to transfer BPMN diagrams around. The XPDL file is imported into the server through a web form:

Then in the server the process definition is displayed as BPMN using the Flash based process diagram viewer:

Step 1

The worklist has two workitem on it, “Provide Office” and “Fill HR DB”:

And this can be visualized graphically as:

Because these steps are in parallel, they could be completed in either order. To demonstrate how the AND node holds up the progress until both inputs are received, lets complete the “Provide Office” first.

Step 2

One work item available:

And this can be visualized graphically as:

The the “Fill HR DB” has not been completed, and so that task is still on the list. The Provide Computer step can not be started before the Fill HR DB step is completed, because the AND node requires input from both direction. There is only one active activity (indicated with green) and so we have one workitem. The AND node is colored green here to show that it has received one, but not both inputs. We complete the “Fill HR DB” workitem:

Step 3

This has two workitems available again:

And this can be visualized as:

Completing the “Fill HR DB” sent an event to the “Medical Check” activity to activate it, as well as to the AND node, satisfying that, and causing “Provide Computer” to be activated as well. So we have two activities active at this time. Again, these are in parallel, and so they could be completed in either order, so lets choose to complete the “Medical Check” workitem.

Step 4

We are left with only one work item:

And this can be visualized as: