BPEL has no goTo

You might wonder why it is relevant. You could argue you have loops and switches to solve that. Let me illustrate it with two examples.

Example 1. BPMN in BPA Suite

When you use the BPA suite (10.1.3.3) to model your business processes in BPMN, you can transform the process to a BPEL process. This results in a BluePrint that can be opened in JDeveloper10.1.3.3 to add implementation details. One of the problems you run into, is the conceptual mismatch between the two modeling languages. BPMN is a graph oriented language (see this article where an example is shown) in which you are relatively free to move back and forth between steps. In contrast, BPEL is in its essence a block language, that follows a linear flow. When you represent a certain control flow in BPMN that involves moving back in the flow, you need to use another construct in BPEL to execute it, because BPEL has no goTo. You could argue that this is not a big deal, but in “On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages”, Jan Recker and Jan Mendling explain why this is relevant. Apart from the semantical difficulties, you can run into practical obstacles. In the BPA Suite a certain transformation model is implemented to translate gateways into BPEL constructs. You can easily create a process that is valid BPMN, but that won’t translate to a BPEL process in the BPA suite. This can be a sign of either of the following problems:

• BPEL is not the right implementation technique for the process you are modeling. Usually this is the case when you have a finite state machine where a lot of different state transitions are possible.
• The process is not modeled correctly. Sometimes, generalizations are made on the wrong modeling level. For example, imagine a travel reservation process with a step ‘edit the reservation’. This step might return after each event. This can result in numerous loop backs. Instead, the process should move forward. For example, the first time you ‘edit the reservation’, you are completing the client data. After checking availability, you might change the flight date. Translating both of them into edit the reservation is a generalization that should be done in the implementation phase, not in the process design.

Example 2. BPEL as the Controller implementation in your MVC pattern

You run into the same thing when you are using BPEL for your navigation flow, as the controller implementation. This is possible in JBoss Seam, but also with Oracle BPEL and ADF Faces. There are several advantages when you use BPEL as a controller:

• you can trace user steps (for support, e.g.) using the logging capabilities of BPEL
• you can have long running sessions (go for lunch or home and resume your registration process for example) using the dehydration store
• you can deploy a new flow separate from the running application

However, it has a couple of disadvantages:

• page flows can have back buttons. This is not supported in BPEL. Of course you can ’simulate’ that by using loops or compensation handlers but this results in the same mismatch as there exists between BPMN and BPEL.
• Performance hit. Every time somebody starts the webapplication, a BPEL process needs to be instantiated. This is a lot of overhead, that is not as scalable as a ‘regular’ web application.
• you need to build a bridge between the web session and the process instance.

To conclude: whenever you catch yourself wishing BPEL had a goto, re-evaluate your process model and/or implementation choice, it is a sign something is wrong!