The state machine of an ACME dispute, drawn as a state diagram, is shown in Figure 2 and Figure 3. The first figure depicts the top-level view. The three stages of the disputes process are modeled as three states: Capturing, Investigating, Charging Back. Capturing is the initial state, triggered by the event Cust Submit. Rejected, Written Off, Cancelled, Won, and Lost are final states in which the processing of the dispute is complete. Capturing, Investigating, and Charging Back have sub-states shown in Figure 3. The Capturing state, for example, begins in the Initially Captured state, and moves to the Awaiting Docs state on the Need Docs transition. Awaiting Docs, in turn, transitions to Examining Docs on Cust Update, and moves back to Awaiting Docs if more docs are needed (Need Docs). The dispute can be rejected, written off, or declared captured in either the Initially Captured or Examining Docs states. In any of the states, the customer may cancel (Cust Cancel).

Figure 4 is a visual representation of the flat BPEL process. The process begins with an initial event (receive CustChannel Submitted) that starts up the machine. The main logic is a switch within a while. Each iteration of the while handles one state: it enters the state, performs any entry actions, and waits for the next event to transition to the next state. The while runs for as long as the machine is active; when a final state is entered, it sets the Boolean variable Continue to false to stop the loop. The switch inside the while has cases for each top-level state (for readability, these boxes are shaded and have a thick border); the current state is identified by the process variable state, whose initial value is Capturing. There are five top-level cases (Cancelled, Capturing, Investigating, and Charging Back have one case each, and Rejected, Written Off, Won, and Lost share the fifth). The three hierarchical states - Capturing, Investigating, and Charging Back - each have an internal switch with a case for each sub-state; they use the variables capturingState, investigatingState, and chargingBackState respectively to select the appropriate case. Transitioning out of a given state is modeled with a pick, which receives one of multiple events, performs actions required to handle that event, and sets a state variable to advance the state. That state variable is either state (which advances to another top-level state), or capturingState, investigatingState, or chargingBackState (to advance to a different sub-state within the same top-level state).

To see the mechanics of this, consider Listing 1, an excerpt of the actual BPEL disputes process. (The complete code can be downloaded from http://webservices.sys-con.com/read/issue/archives/.) If the current top-level state is Investigating and its current sub-state is FullyCaptured, the process first asks operations to pick up the dispute for investigation (invoke on line 54), and then uses a pick to wait for operations' response. If the response is to reject (onMessage in line 56), the process sets the top-level state to Rejected (assign in lines 57-62), and on the next iteration will jump to the top-level case for Rejected (line 33). If the response is to request documentation from the merchant (onMessage on line 80), the process keeps the top-level state as is, but sets the sub-state to AwaitingDraft (assign in lines 81-86); on the next iteration, the process will jump to the AwaitingDraftcase (line 92).

Although there are several levels of hierarchy in the flat approach (transitions on a sub-state, for example, are modeled in a pick within a switch within a switch within a while), there is an upper bound on the number of levels. State machines, even hierarchical ones like the dispute machine, are comparatively flat; even the most complex actors seldom require more than three levels of state. If companies paid for their processes by the level, meandering tree processes would exceed their budget quickly, whereas flat processes would incur a predictable charge up-front but stay on budget. Flat processes would also pass an SOA audit with flying colors, because in the flat structure states, transitions, and actions are easy to find.

Handling Concurrency and Other Conversion Tips
Table 1 provides some tips on how to map, element-by-element, existing BPEL processes to the flat form. The disputes example presented above demonstrates most of these tips.

Concurrency is a notable exception. In BPEL, concurrent execution of activities is modeled with a flow activity. There are two sorts of flows: those that merely perform a set of actions in parallel and those that model what state machine guru David Harel calls orthogonal states (or a set of states that apply to the same entity simultaneously). The former type is easily accommodated in the flat approach: the flow construct is simply embedded in the logic of a particular state or transition. The latter type contains transitions (receives, waits, or picks), and thus affects the shape of the state machine. In the latter case the flat approach of modeling state as a single switch within a while breaks down, because it assumes states are mutually exclusive. Two possible design approaches are to flatten the flow into mutually exclusive form, or to explicitly build the logic to support orthogonal states.

A good example is presented in the Voting process presented in the BPMN specification. In the "Collecting Votes" part of this process, three main activities occur in parallel: a moderated e-mail discussion, a moderated conference call, and the collection of votes. A visual representation of the BPEL implementation recommended in the spec is shown in Figure 5.

The model shown in the figure, which features a disconnected set of e-mail activities (Invoke Moderate Email Discussion, despite appearances, is closely related to the sequence Wait for 6 Days and Invoke Email Deadline Notice) and a time-based exception to break an infinite while loop, is obscure to say the least. The overall meaning is clearer when represented as a state machine with orthogonal states, as shown in Figure 6. According to the diagram, the voting procedure has, simultaneously, a conference call state, an e-mail state, and a voting state.

Figure 7 is a BPEL representation in a variation of the flat form in which the set of orthogonal states is a flow, and each of the orthogonal states is a while within the flow. Notice that each while has its own internal state-transition structure; each while is a little state machine, running in parallel with the state machines of peer states.

The flow, of course, is encompassed within the overall while-switch structure of the larger state machine, the same overall structure used in the disputes example.

Although this representation has expressive power, it's complex - much more so, in fact, than the obscure but barren implementation from the BPMN spec! An alterative is to flatten the structure, reducing the voting cycle to three mutually exclusive states, as shown in Part (a) of Figure 8. In Collecting Votes Not Started all the setup work is done, which includes starting timers whose expiration events will lead to major transitions later on. Most of the time is spent in the state Collecting Votes, and of its four transitions, three are self-transitions whose occurrence keeps the machine in the Collecting Votes state. The machine moves to its final state, Collecting Votes Complete, when the voting period ends. The BPEL implementation, shown in Part (b), has the same overall while-switch form as the disputes example. The self-transitions in the middle state are a poor man's concurrency, preserving the requirement that events that impact the state machine can arrive concurrently, in unpredictable order.

Concurrency is a delicate subject, and the flattening heuristic does not work in all cases. The moral of the example is to preserve the spirit of flat even when faced with the challenge of orthogonal states.

References
1.  Michael Havey. "State Machines and Workflow in Weblogic Integration: State Machines and Process-Oriented Applications." Weblogic Developer's Journal. January, 2004. http://weblogic.sys-con.com/read/43046.htm.

2.  Michael Havey. Essential Business Process Modeling. O'Reilly. 2005. www.oreilly.com/catalog/essentialpm.

3.  David Harel. "Statecharts: A Visual Formalism for Complex Systems." Science of Computer Programming, 8 (1987) 231-274. www.tik.ee.ethz.ch/tik/education/lectures/hswcd/papers/Statecharts.pdf.

4.  Object Management Group. "Business Process Modeling Notation Specification." www.bpmn.org/Documents/BPMN%20V1-0%20May%203%202004.pdf.