The first two processes model a customer. The first, CustomerSS, represents a customer on standard supply who enrolls with a retailer. The obscure expression Σ(r:rets). (enroll r,"mike".CustomerR(r,enroll,switch,drop,rets)) means:

• Σ(r:rets): Choose a retailer channel r from the set of retailers rets
• enroll r,"mike": Send r and the customer's name "mike" on the channel enroll
• CustomerR(r,enroll,switch,drop,rets): Change state to that of an enrolled customer by calling the process CustomerR, passing the chosen value of r

These steps are separated by the sequential operation ("."), and hence are performed one after another in the order given.

CustomerR is the process for a customer enrolled with a retailer, who can either switch to a different retailer or drop the current retailer and return to standard supply. The conditional operator ("+") separates these two options. The first option, on line 4, is written as Σ(r2:rets).(switchr,r2,"mike".CustomerR(r2,enroll,switch,drop,rets)), meaning:

• Σ(r2:rets): Choose a retailer channel r2 from the set of retailers rets
• switch r,r2,"mike": Send r2, as well as the channel of the retailer with which the customer is currently enrolled, r, and the customer's name "mike" on the channel switch
• CustomerR(r2,enroll,switch,drop,rets): Keep the same state, but change the retailer of record, given by the first variable, from r to r2 by recursively calling the process
  The second option, on line 5, is drop r,"mike".CustomerSS(enroll,switch,drop,rets):
• drop r,"mike": Send r and the customer's name "mike" on the channel drop
• CustomerSS(enroll,switch,drop,rets): Change state to that of a customer on standard supply calling the process CustomerSS

The supplier process, in lines 6-9, listens on channels enroll, switch, and drop for messages from the customer. In the enrollment case, in line 7, the process first receives the message on the enrollment channel, using the notation enroll(r1,c), and then sends a message to the channel of the specified retailer (r1) to add customer c to its customer base(r1 "addcust",c). The drop case, in line 9, is similar, but this time the message from the customer arrives on the channel drop (i.e., drop(r1,c )) and the supplier's message to the retailer is to drop the customer (r1 "dropcust",c). The switch case, in line 8, switch(r1,r2,c).r1 "dropcust",c. r2 "addcust", c, is a combination of drop and enrollment. It breaks down as follows:

• switch (r1,r2,c): Receive on the switch channel the channels of the new retailer (r2) and old retailer (r1), plus the customer name
• r1 "dropcust",c: Instruct the old retailer to drop the customer
• r2 "addcust",c: Instruct the new retailer to add the customer

When these activities are completed, the supplier process continues recursively (Supplier(enroll,switch,drop) on line 9), much like a daemon.

The retailer process, in lines 10-11, listens on its channel r for the required action and customer (r(action,c)) and then, like the supplier process, continues recursively.

The market process, in lines 12-16, creates a simple energy market. Line 12 creates specific instances of the enroll, switch, and drop channels (chEnroll, chSwitch, and chDrop, respectively), as well as a set, named retSet, of actual retailer channels (retA and retB). Lines 14-16 create four concurrent process instances - separated by the concurrency operator "|" - and passes to them the newly defined channels. The processes include a single customer on standard supply, a supplier, and two retailers using channels retA and retB, respectively. Figure 3 depicts the overall exchange.

The Pi Calculus and BPM
BPM is fast becoming the practical study and design of solutions for elaborate, multi-company communicating business processes. For those seeking a formal basis for BPM processing, the Pi Calculus offers three key features:

• Control Flow. In the Pi Calculus, the sequential, parallel, conditional, and recursive behavior of a process can be declared succinctly.
• Message-Based Communication. The heart of the Pi Calculus is its clean syntax and semantics for inbound and outbound messaging.
• Mobility. Contemporary processes cannot hardcode service endpoints, but require the ability to pass around and change addresses dynamically. Dynamic addressing, or mobility, is the most distinctive feature of the Pi Calculus.

A good BPM language has the control structures of a flow chart, and has as its most significant steps "mobile" message-based interactions. The major contemporary process languages, as it turns out, are like this anyway. XLANG, for example, has similar control structures (sequence, all, switch), explicit service-oriented message support (the operation action), and dynamic channel bindings. WS-CDL is based on interactions, message exchanges on channels, and channel passing between participants. (WS-CDL, according to its author, is based on the Explicit SolosCalculus, a variant of Pi, which allows a system to be modeled from a global viewpoint. [See Kavantzas, "Aggregating Web Services: Choreography and WS-CDL."] Robin Milner, Pi Calculus creator, is an invited expert in the W3C Choreography Working Group.)

The crux of the "hype" criticism of van der Aalst is that the use of the Pi Calculus in the creation of contemporary languages is overstated; that, perhaps, these languages came together more casually and with less academic rigor than advertised. They might resemble the Pi Calculus, but they are hardly "based" on it. His challenge to prove the connection, though stated in polemical language, could inspire a landmark BPM paper.

Petri Nets
The Petri network (or Petri net), a notion devised in 1962 by the mathematician Carl Adam Petri, is a formal graphical process modeling language that can be used to design systems as diverse as train track switches and business processes. With respect to the latter, Petri nets help describe, and indeed can be used to implement, the semantics of process control flow, ranging in complexity from basic branch and join rules to complicated synchronization techniques such as "dead-path elimination," a core topic in WSFL and BPEL.

Petri Nets in a Nutshell
The graphical building pieces of a Petri net diagram are the following:

• Place. Drawn as a circle, a place is a stopping point in a process, representing, in many cases, the attainment of a milestone.
• Transition. A transition is a rectangle that represents an event or action.
• Token. A token is a black dot residing in a place. During the execution of the process, tokens move from place to place.
• Arc. An arc is a link from a transition to a place or from a place to a transition.

The Java applet design editor and simulator shown in Figure 4 is a typical Petri net modeling tool, which promotes a design-and-simulate approach to building a Petri net. Design involves dragging places and transitions onto a canvas, drawing arcs between them, and dropping an initial placement of tokens into a subset of the places. Simulation is a step-by-step run of the Petri net, where each step involves firing a transition and watching the tokens advance to new places.