The state machine is one of the most successful ideas in the history of computing. Alan Turing built a model of computability around the concept, and in doing so became the father of computer science. Mealy, Moore, Harel, and other theorists expanded the idea, influencing engineers of digital logic, real-time, and embedded systems whose designs are peppered with state machines and diagrams.

The concept of the state machine is also a natural fit for many contemporary enterprise applications, particularly those that are process-oriented. The distinguishing characteristic of a process-oriented application is its movement over time from state to state, or put differently, its progression from milestone to milestone to an ultimate goal. An application that manages the processing of an insurance claim is a typical example: the claim, over its lifetime, is passed from one person to another in a succession of approvals, and is defined at all times by how far it has gotten. But not all enterprise applications qualify. For example, in an automated teller machine (ATM), which lets users query their account balance, withdraw cash, deposit checks and cash, and pay bills, any sense of process is extremely short-lived and inessential; an ATM is an online transaction processor, not a process-oriented application.

The process that defines the insurance application is described by the state diagram shown in Figure 1.

The claim is initially idle. It enters the proposed state when it is first received into the claims department. In that state, it is examined by an analyst and can be accepted, refused, or passed on for further analysis, at which point it enters the waiting state. In the waiting state, the claim is further analyzed and is ultimately accepted or refused. A time limit for analysis is set; if the claim waits too long it is escalated to a supervisor, who examines the claim and accepts or refuses it. An accepted claim is examined by another analyst, who must activate it, at which point the claim enters the active state. At any point (in other words, in any state) a claim can be killed, which takes it back to idle.

Workflow and State Machines
The popularity of workflow application frameworks, such as the Business Process Modeler (BPM) component of BEA WebLogic Integration, proves not only that process-oriented applications abound, but also that companies are willing and eager to use high-level modeling languages to develop these applications. Besides state machines, workflow technology is an obvious implementation choice for business processes because a workflow is often the most similar representation of the process. That is, a workflow in BPM's design tool looks like what the business analyst has in mind or has drawn on paper. The insurance example looks like Figure 2 in WebLogic Integration 8.1 and Figure 3 in version 7.0.

The steps are the following:

1. The workflow is started when a claim is received.
2. The workflow is always waiting for a kill event. If that event occurs, stop claim processing no matter what step the workflow is at.
3. A claim is initially assigned for evaluation to a person or role.
4. If the initial evaluator refuses the claim, the workflow stops.
5. If the initial evaluator deems further analysis needs to be done, the claim is assigned to another person or role for analysis.
6. If the initial evaluator accepts the claim, the claim is assigned to a person or role for activation.
7. If the person analyzing the claim refuses it, the workflow stops.
8. If the person analyzing the claim accepts it, the claim is assigned to a person or role for activation.
9. If time expires on the person analyzing the claim, the claim is assigned to a person or role for escalation.
10. If the escalator refuses the claim, the workflow stops.
11. When the person activating the claim does so, the workflow stops.

Workflow is procedural: it describes how a process should run. By contrast, the state machine representation of a process is declarative; to define a process is to declare its states and transitions. There are advantages and disadvantages to each approach. For example, workflow is easier for a business analyst to understand, but being procedural it requires more code and is less compact than a state model. But workflow and the state machine are not mutually exclusive, and when used in concert, they can produce powerful solutions.

WebLogic Integration's BPM has four capabilities that are essential to a process-oriented application:

• Worklist: Human beings are often the key actors in a business process, not only as the source of events that drive the process, but also as participants in the actual processing. The BPM worklist enables a workflow to assign a work task to a user or role and track its progress.
• Integration: Besides human beings, external systems do much of the work in a process-oriented application. For example, in an insurance application ADP is called to cut a check for payment on the claim. Integration is what WebLogic Integration is all about.
• XML: Information exchanged between workflow and external systems or users is usually in the form of XML documents. BPM provides abundant XML facilities, including transformations and the ability to listen for events satisfying XPath or XQuery expressions.
• Events and timers: Process-oriented applications live a long time but spend most of their time asleep. Events and timers wake them up, whereupon workflows do work and possibly change state. Events and timers are built into BPM.

When these features are incorporated into an enterprise state machine framework, the result is a powerful synthesis that is ideal for process-oriented application development. The pieces of this solution are the following:

1. A state machine framework, consisting of:
   - State model: A model is a set of states and transitions, expressed in an XML document.
   - Actor database: An actor is an entity that has state. The state of the actor is persisted to a database by the state machine.
   - State machine engine: The engine injects events into an actor's state model and updates state accordingly. It also calls user-defined action classes when a state is entered or exited or a transition occurs.
   - Action classes: User-defined Java classes that respond to the entry or exit of a state or the execution of a transition for an actor in a given state model.
   
2. A BPM workflow that receives an event and injects it into the state machine.
3. A BPM workflow that sets a timer and injects a timeout event into the state machine when the timer expired.
4. A BPM workflow that is called by a state action to assign a worklist task or interact with an external system.

The insurance example is a perfect example. The state model for the application, a formalization of Figure 1, is shown in Listing 1. The XML indicates that there are seven states (e.g., "top", "idle", "proposed", "accepted") and multiple transitions (such as "approved" from the state "escalated" to the state "accepted").

The "actor" to which this state model applies is an insurance claim. An actor is identified by a unique identifier, perhaps in this case a numeric claim ID. The action class has the behavior shown in Table 1.

The corresponding BPM workflows are as follows:

• Timer flow: Starts a timer for a specified interval. If the timer expires, the workflow fires an XML timeout event. This workflow also listens for a cancellation event that causes it to stop the timer. Figure 4 shows this workflow for WebLogic Integration 8.1.
   

• Task assignment flow: Assigns a task to a given user or role and waits for the user's response. Based on the response, this workflow generates an XML event bound for the state machine. The WebLogic Integration 8.1 implementation is shown in Figure 5.
   

• State injector: All XML events bound for the state machine are intercepted by this workflow, which in turn calls the state machine via its API to inject an event. Figure 6 shows the injector workflow in WebLogic Integration 8.1
   

• Cleanup: The cleanup workflow performs whatever steps are necessary to finalize a claim, such as cutting a rejection letter or an acceptance letter with a check.

Conclusion
Process-oriented enterprise applications abound, and workflow toolsets, such as BEA WebLogic Integration's BPM, are viable and popular frameworks to develop them. However, the state machine approach is also valid, and has particular advantages when coupled with BPM. My next article will look at E-State, a reference implementation of an enterprise state machine framework that is meant to coexist with BPM.

• Source Code