BPMN to BPEL: be careful

.
I just read the article in InfoQ written by Pierre Vignéras about BPMN and BPEL.

I was finishing my last entry to the blog but I think that that article is a bit misleading and I must react to it. Why? because it makes a point on some wrong interpretation of BPMN. In addition, this gives me a good excuse to explain some details about process algebras.

First, I must clarify that I like Bull and their suite, and that I could have rich discussions with the Bull guys and a couple of OW2 Project Managers in LinuxDays in Geneva. Besides, I used eXo in a project recently, and I think that’s a nice portal and that their implementation of the JCR-standard is just great. Bull’s philosophy is different from Intalio and very respectable, and Bonita is a nice-to-have BPM Suite. I like eXo and its family: Orchestra, JOnAs, the way the integrate…

Nevertheless, as an ancient researcher in this domain I cannot just let it pass a misinterpretation like the big one in his article, and specially the conclusion that he has created from that misunderstanding.
In a very short form, the process they describe is: a new employee starts working, and the company must proceed to some exams, and some logistics takes place (like giving her a computer). You can see the ~BPMN description here:
http://www.infoq.com/resource/articles/bpelbpm/en/resources/onboarding.png

Is this really a correct model?
Although Mr. Vignéras article starts with a discussion of structured and unstructured approaches to programming, his diagram is not structured. He just did not respect the most basic good practices for modeling in BPMN.
As in any language, in BPMN there are different levels (as I described in my last entry): lexical, syntactic, semantic and pragmatic. The two latter levels mean that not everything that is grammatically correct is necessarily a valid construction in the “common sense” understanding (If you want more on this, you should read Chomsky).

I must suppose that the author did not know in depth the substance he was dealing with. At least, he did not analyze the BPMN semantics of the process in advance. As a matter of fact, the BPMN model and the BPEL one MATCH, but it is the (textual) process description that is wrong :-O

In the description he says: “… When a new employee arrives at a company, a workflow is instantiated. First a record needs to be created in the Human Resources database. Simultaneously, an office has to be provided. As soon as the Human Resources activity has been completed, the employee can undergo a medical check. During that time, a computer is provided… “. If you face a description like this, you should ask yourself several things:

• What activities do happen in parallel
• What does it mean “During that time“?
• How do you represent “can” ? and what about the other modal words?

Let’s Put Some Music
Let us decompose the description onto sentences:

1. A = “First a record needs to be created in the Human Resources database”.
2. B = “Simultaneously, an office has to be provided”.
3. C = “As soon as the Human Resources activity has been completed“
4. D = “the employee can undergo a medical check”
5. E = “During that time, a computer is provided”

Going further, I will isolate the temporal and modal operators:

1. TA = “First”
2. TB = “Simultaneously”
3. TC = “As soon as the … activity has been completed”
4. TD = “can“
5. TE = “During that time, “

Then, back to the initial text we obtain:

1. A = TA + “a record needs to be created in the Human Resources database”.
2. B = TB + “an office has to be provided”.
3. C  — let’s just forget it
4. D = TD + “the employee undergo a medical check”
5. E = TE + “ a computer is provided”

Now we can write different descriptions of the BP. The basic thesis should be that During that time means “something that happens in parallel“.
Let us consider a quite basic process algebra (you can adopt a more precise CSP or CCS or Pi-calculus if you want):

• sequence (.)
• parallel construct (||)
• exclusive OR (ø)
• inclusive OR (+), and
• the epsilon joker (ε).

Mr. Vignéras wrote a model that can be represented by this equation:

( (A.C)+ (ε ø D)) || (E) ) || (B.C.E)        :-O

No matter why the employee receives two computers !!

Now if we read the textual process description, and if we simplify the undeterministic expression D from “can“ to a deterministic “will certainly“, we may write the BP in 2 ways:

1. f ( A.B.C.D).E — this is not valid because E is not in parallel.
2. f (A.B.C.D)||E — this is valid but ambiguous

We must rewrite this last equation, but in a less ambiguous fashion. Because the sentence C establishes a causality between A and D, we can reduce the design space to those options that respect such causality. This does not, however, give us a unique option:

1. (A.C.D) || B || E
2. ((A.C.D) + B) || E
3. ((A.C.D) || E) + B
4. ((A.C.D) || (B + E)
5. ((A.C.D) || (B.E)
6. ((A.C.D) || (E.B)

As you can see, at no moment we can obtain the extrange model of Mr. Vignéras. In this case, we have exclusive paths to the E premise, i.e. a single computer given to the employee.

Are Exceptions Unstructured?
I was quite surprised with Mr. Vignéras’ view of exceptions as a non-structured approach. Actually, this was the real reason to feel uncomfortable when reading his article before I saw the BPMN modeling problem. He put the fault on Business Analysts, on the real world, and on everything else but a good structured programming/modeling language (his title reads “Business Analysts Write Parallel and Unstructured Processes”)… These are my reasons:

• First, the 1968 article from Dijkstra was really focused on unstructured architecture of programs.
• If one takes the time to study the more complete Dijkstra’s “A Discipline of Programming” (from 1976),  that is also more modern than the 1968 article, one can conclude that the essence of his message is that the modules have contracts (I won’t go into the details of the guarded command language). Each contract is fulfilled if the pre-condition is respected. This does not exclude the introduction of exceptions, because they are basically the result of not respecting those pre-conditions. Dijkstra is very clear: “If the precondition is not respected, we can say nothing about the postcondition“… the rest does not come from him.
• The work done by Meyer for building the exception treatment that was eventually built onto the Eiffel language (and re-adopted by all major OO-languages) is actually a nice proposal to a very structured way of dealing with erroneous conditions. It was a counter-proposition to defensive programming, and it guaranteed that someone had to deal with the error. It instantiates a very well-known and structured pattern: the chain-of-command, that’s it.
• The fundamental and complementary works of Parnas (modularity), Liskov (the Substitution Principle), from Rebeca Wirfs-brock group or the Fusion method group (that dealt with roles and design principles), are perfectly compatible with the notion of exception.
• All these proposals are built around the Hoare Triple, and if you go really deep, the famous triple is another “not uncompatible” specification tool.
• The language theory, specially the grammar automatas, say that a grammar is accepted if the path arrives to an endpoint.  I’d like to see this comunity’s reaction when considered as non-structured.

The unstructured nature of graphs (?)
Let us cope with graphs nature: I’m not fond of graphs, and I am almost allergic to them (more on that when I’ll come to my Ph.D. dissertation some day). This does not mean that graphs are bad, because they are useful.

For example, I kind-of-hate them but I have to admit that when working on parallel computing and data-flow, they really helped us structure the solutions. However, you had to be aware of their power and their flexibility.

Graphs are useful not only for parallelizing frameworks and middleware. When I worked on real-time systems, I also enjoyed using Structured Analysis models (for example Hatley & Pirbhai, some 16 years ago), that were kind of data-flow + control flow (quite similar to BPMN when zoomed-in) and helped you understand the complex relations among architectural modules.

Yes, graphs can get really wild, and I agree that you can create monster models, but they are not necessarily unstructured. As a matter of fact, in the cases mentioned above a graph was a hyper-useful means to structure your solution. It all depends on your use of the modeling techniques.

CONCLUSION
The author of the article mentioned above wrote a wrong BPMN model, then he wrote a process description that does not correspond to the diagram, and finally he explained a 2nd wrong model in BPEL. I know his goal was to prove something else, but I do not appreciate being mislead.

I hope I proved many fundamental notions in Computer Science do not share the definition of structured that was presented by the author. I also could show that  there is no single way to define “structured”, even for computer languages.

I think you can miss the point if you do not go far enough on your analysis. Brooks explain this very well when he calls this complexity, and differentiates essential from accidental.

• For more curious people, please read the incredibly illuminating discussion of Weinberg on state and structure, as well as the work of Barwise and company on the modeling of logical systems (Stanford’s CLI).
• I also invite you to read Mr. Bruce Silver discusses the distance from BPMN to BPEL, from market strategy to the issues related to the implementation of BPEL standards.
• I will review my model once in the future, in order to check that everything is right. No guarantees for the moment.
• I may add to it that XPDL (used by Bull’s products) is an interesting and may-be-extremely-structured language, but I am quite confident that you can also write things that do not make sense (on this domain, I only trust formal proofs and/or model-checking). Of course, I won’t spend time on doing that: it is possible, more than probable, and completely useless.

I do not put more pointers or bibliography, because of lack of energy. Sorry. Lo siento.

---

Possibly related posts: (automatically generated)

• Before you start creating the BP model in Intalio…
• Model Portability is No Accident
• BPMN Modeling and Reference Guide
• BPMN – Quick Reference Cheat Sheet