At the heart of the architecture is a runtime engine that executes processes whose source code is written in the XML-based BPEL language, the most famous and widely adopted BPM standard, and the best of the BPM execution languages. These processes are designed, by business and technical analysts, using a graphical editor that supports the visual flowchart language BPMN, the best of BPM's graphical languages. The editor includes an exporter that generates BPEL code (which is then deployed to the engine) from BPMN diagrams. (The BPMN-to-BPEL development cycle is analogous to that of UML-to-Java in many current Java development tools.)
Human and computer interactions drive the execution of processes in the engine. Human participants view and execute pending manual work activities (in processes running on the engine) using a graphical worklist application. Internal IT systems, which reside on the company's network but are outside of the engine's address space, are accessed by integration technologies such as web services, J2EE, or COM, with XML as the probable message format; internal interactions can also be more lightweight inline code snippets, written in programming languages such as Java or C#. External interactions are typically web-service-based communications, governed by choreographies, such as those composed in the emerging XML language WS-CDL, the leading choreography language. Though a choreography describes the global, publicly observable view of a multi-participant process exchange (typically in business-to-business e-commerce), a choreography toolkit can be used to "generate" a basic BPMN model that captures the communications required by the process of a particular participant; the tool can also validate that a given process satisfies the choreography's contract. (WS-CDL literature suggests generating BPEL, rather than BPMN, from WS-CDL. But in this architecture, BPMN, as a design language, is a necessary layer of indirection.)
BPM system administrators use a graphical administration and monitoring console to maintain and track the state of the engine's processes. The console uses a management language to interface with the engine. The runtime engine persists process state to a database; the console hits the database directly, rather than using the management language, to perform ad hoc process queries. The monitoring infrastructure can also support Business Activity Monitoring (BAM), or dashboard-style business monitoring.
The development cycle on this platform is the following:
Generate an initial BPMN model from a WS-CDL choreography. Skip if this process does not derive from a choreography.
Design the BPMN model.
Generate BPEL from the BPMN model.
Develop the required human and (internal and external) system interfaces.
Deploy the BPEL code and its required interfaces to the engine.
Use the administration and monitoring interfaces to track running processes.
The overall shape of this architecture (inspired by the reference model of the WfMC, the most mature of the numerous BPM standards groups) resembles that of platforms offered by integration vendors such as IBM, BEA, Oracle, Tibco, SeeBeyond, and Vitria. What distinguishes this architecture is its choice of standards. BPEL, BPMN, and WS-CDL are included because they are the best approaches to execution, design, and choreography, respectively: three crucially important parts of BPM. (As Figure 2 shows, future possibilities include emerging standards BPQL (for monitoring), BPSM and BPDM (for metamodeling), BPRI (for a runtime interface), and BPXL (for BPEL extensions).) Indeed, many vendors support, or are currently building support for, BPEL. But BPMN support is rare (most vendors offer a proprietary equivalent), and WS-CDL support almost non-existent. BPEL is not enough! The architecture is ideal, waiting for actual implementations.
Figure 2. BPM standards in ideal architecture