| In most software topics, the boundary between theory and practice in software is clearly drawn: theory is for academics who seldom descend from the ivory tower, and practice is for industry professionals who have long forgotten the concepts and application of theory. In concurrency, for example, most developers either know or have programmed semaphores, but few remember the conceptual underpinnings devised by Dijkstra. But BPM belongs to a rarer category, in which theory informs practical design and theoretical jargon is part of the hype with customers. Somehow the abstruse terms "pi-calculus" and "Petri net"as impressive to the ear as database management's "relational calculus" or capacity planning's "Erlang formulae"have permeated the consciousness of the BPM community. Many BPM onlookers are familiar with and interested in pi and Petri, but have at best a vague understanding of them, and prefer an executive summary or beginner's treatment; the pedantic details are best left to graduate students. Process theory is practically important for several reasons: It is mentioned frequently in connection with BPM, even in nonacademic material. Countless presentations, for example, state without explanation that BPEL is influenced by the pi-calculus and Petri nets. For the many practitioners who are intimidated by the pedantic name-dropping but are curious to uncover its meaning (asking questions such as: What is the pi-calculus ? What are Petri nets? Which parts of each theory are used in BPEL? Why is BPEL based on two theories rather than one?). This chapter helps explain the nature of the connection. BPM is relatively immature and benefits from the ideas and rigor of theory. Control flow, for example, is often treated too casually by vendors, who are more likely to emphasize ease of programming rather than semantic precision. Regrettably, as several papers on process-design patterns have demonstrated, most vendorsand even most standardsstruggle to support certain common control flow scenarios (e.g., the "multiple instances without runtime knowledge" and "interleaved parallel routing" patterns, described in Chapter 4). To build successful solutions, practitioners should insist on knowing exactly how a given process will run. To accomplish this, they should choose a good language and understand how it works. Judged on the basis of control flow, the strongest languages are those that are based on the Petri net, including BPEL and BPMN. And, arguably, understanding the nuances of these languagese.g., dead path elimination in BPELrequires an appreciation of the Petri net. Contemporary BPM and Web Services Choreography are obsessed with the construction of complex participant conversations. Choreography especially, because it is mandated to build global collaborative contracts, requires a conceptual framework that can express dynamic communicating processes precisely and concisely. The leading choreography language, WS-CDL, bases its constructions (e.g., channel passing) on the pi-calculus. BPEL is also alleged to have pi underpinnings. By learning the basics of pi, the practitioner gains insight into the use of these languages.
This chapter is a scenic guided tour of the BPM theory route. It begins by exploring which theories have influenced which standards. The pi-calculus, the Petri net, and the state machine are studied by example and with just enough detail to give a flavor for the mechanics without overdosing on algebra. This chapter also explores each theory's significance for and influence on BPM. |
