## 3.2. The Pi-CalculusDeveloped by Scottish mathematician Robin Milner in the 1990s, the pi-calculus is a formal language for defining concurrent, communicating processes, including, but not restricted to, business processes. In its detail, the pi-calculus is a rather advanced algebraic system requiring a senior level of mathematical training. Milner's presentation of the subject is written in the mathematical idiom of definitions, theorems, and lemmas, inaccessible to most BPM onlookers.
But somehow, despite its academic roots and its inherent complexity, the pi-calculus has become one of BPM's most attention-getting cocktail party terms. Popular BPM literature states boldly that major languages such as XLANG, WSCI, BPML, BPEL, and WS-CDL are based on the pi-calculus. This stunning level of influence, charges leading BPM commentator Wil van der Aalst, is dubious, and surely nothing but hype:
Whether or not it is hype, the pi-calculus-BPM connection merits a serious look. What, in a nutshell, is the pi-calculus, how does it apply to BPM, and what is the extent and nature of its influence on contemporary popular languages like XLANG and WS-CDL? NOTE Robin Milner visited Petri net creator Carl Adam Petri in Bonn in the 1980s to learn more about concurrent systems. ## 3.2.1. The Pi-Calculus in a NutshellAs mentioned earlier, the pi-calculus is a language that defines concurrent processes that interact with one another dynamically. Each process consists of one or more actions, which can be arranged sequentially, in parallel or conditional paths, or recursively. An action is the sending or receiving of information on a channel. According the pi-calculus convention, when one process sends information to another, it includes the name of the channel to be used for the other process to respond. This name is variable and, as you will see, can change in response to changing conditions. The process definition is a set of mathematical equations using defined symbols. Example 3-1 illustrates the interactions of a customer, a travel agent, and an airline in the booking of a travel reservation. ## Example 3-1. Travel agency pi-calculus example1 Customer(createorder,customer)= 2 <customer>.customer(result) 3 Agent(createorder,agentok,agentfail,airline)= 4 createorder(customer).<agentok,agentfail>. 5 Agent1(agentok,agentfail,customer) 6 Agent1(agentok,agentfail,customer)= 7 agentok(result).<result>+ 8 agentfail(result2).<result2> 9 Airline(airline,agentok,agentfail)= 10 airline(agentok,agentfail).<"conf no 121"> 11 End2End= 12 (new corder,cust,ok,fail,air) 13 Customer(corder,cust)|Agent(corder,ok,fail,air)|Airline(air,ok,fail) The definition of the customer process, which sends an order to a travel agent and waits for a result, appears in lines 1 and 2. Line 1 declares that the process The process for the travel agent spans lines 3 to 8 and is broken into two parts. The first part, entitled The The process One of the most distinctive features of the pi-calculus is mobility , in which the topology of communicating processes changes dynamically in response to changing conditions. An example of mobility is the enrollment of customers with retailers in a deregulated energy market. In scenario (1) of Figure 3-3, the customer initially buys energy directly from the supplier (a "standard supply" arrangement). In scenario (2), the customer enrolls with retailer A, and then in scenario (3) switches to competing retailer B. Finally, in scenario (4), the customer decides to drop retailer B, and return to standard supply. ## Figure 3-2. Pi-calculus travel agency example## Figure 3-3. Pi-calculus mobility: energy customer switches retailersAs you can see in Example 3-2, the source code to model this scenario is remarkably terse: ## Example 3-2. Energy pi-calculus example1 CustomerSS(enroll,switch,drop,rets)= 2 (r:rets).(<r,mike>.CustomerR(r,enroll,switch,drop,rets)) 3 CustomerR(r,enroll,switch,drop,rets)= 4 (r2:rets).(<r,r2,mike>.CustomerR(r2,enroll,switch,drop,rets)) + 5 <r,mike>.CustomerSS(enroll,switch,drop,rets) 6 Supplier(enroll,switch,drop)= 7 (enroll(r1,c).<"addcust",c> + 8 switch (r1,r2,c).<"dropcust",c>.!<"addcust",c> + 9 drop(r1,c).<"dropcust",c>).Supplier(enroll,switch,drop) 10 Retailer(r)= 11 r(action,c).Retailer(r) 12 Market= 13 (new chEnroll,chSwitch,chDrop,retSet={retA,retB}) 14 CustomerSS(chEnroll,chSwitch,chDrop,retSet)| 15 Supplier(chEnroll,chSwitch,chDrop) | 16 Retailer(retA)|Retailer(retB) The first two processes in this sample model a customer. The first, (r: rets).(<r,"mike">.CustomerR(r,enroll,switch,drop,rets)) means: `(r:rets)`: Choose a retailer channel`r`from the set of retailers`rets`.<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`.
(r2 : rets).( <r,r2, "mike"> .CustomerR(r2,enroll,switch,drop,rets)) means: Choose a retailer channel `r2`from the set of retailers`rets`.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`.Keep the same state, but change the retailer of record, given by the first variable, from `r`to`r2`by recursively calling the process (`CustomerR(r2,enroll,switch,drop,rets)`).
The drop option, on line 5, means send The supplier process, in lines 6 to 9, listens on channels The retailer process, in lines 10 and 11, listens on its channel The market process, in lines 12 to 16, creates a simple energy market. Line 13 creates specific instances of the NOTE The most widely cited example of mobility is the handover protocol used in GSM cell phone networks to switch cell bases for a phone call, as a phone (normally used in a car) moves through two geographic areas. ## 3.2.2. The Pi-Calculus and BPMBPM is fast becoming the practical study and design of solutions for elaborate, multiple-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 requireS 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 ( NOTE WS-CDL, according to its author, is based on the Explicit Solos Calculus , a variant of pi-calculus, which allows a system to be modeled from a global viewpoint.
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. |

Essential Business Process Modeling

ISBN: 0596008430

EAN: 2147483647

EAN: 2147483647

Year: 2003

Pages: 122

Pages: 122

Authors: Michael Havey

Similar book on Amazon

- Chapter I e-Search: A Conceptual Framework of Online Consumer Behavior
- Chapter VI Web Site Quality and Usability in E-Commerce
- Chapter VII Objective and Perceived Complexity and Their Impacts on Internet Communication
- Chapter XIII Shopping Agent Web Sites: A Comparative Shopping Environment
- Chapter XVIII Web Systems Design, Litigation, and Online Consumer Behavior

flylib.com © 2008-2017.

If you may any questions please contact us: flylib@qtcs.net

If you may any questions please contact us: flylib@qtcs.net