"The boxes and arrows of outrageous fortune ...." When a business analyst stands at a whiteboard, sketches the flowchart of a business process as a cluster of boxes linked by arrows (apologies to Shakespeare), and asks the software team to make it run, Business Process Modeling (BPM)--sometimes known as Business Process Management--comes to the rescue. BPM is a set of technologies and standards for the design, execution, administration, and monitoring of business processes. A business process is the flow or progression of activities (the "boxes")--each of which represents the work of a person, an internal system, or the process of a partner company--toward some business goal.
Over the years, the scope of business processes and BPM has broadened. Less than a decade ago, BPM, known then as "workflow," was a groupware technology that helped manage and drive largely human-based, paper-driven processes within a corporate department. For example, to handle a claim, an insurance claims process, taking as input a scanned image of a paper claims form, would pass the form electronically from the mailbox (or worklist) of one claims specialist to that of another, mimicking the traditional movement of interoffice mail from desk to desk. BPM today is an enterprise integration technology complementing Service-Oriented Architecture (SOA), Enterprise Application Integration (EAI), and Enterprise Service Bus (ESB). The contemporary process orchestrates complex system interactions, and is itself a service capable of communicating and conversing with the processes of other companies according to well-defined technical contracts. A retailer's process to handle a purchase order, for example, is a service that uses XML messages to converse with the service-based processes of consumers and warehouses.
My forthcoming book, Essential Business Process Modeling, explores the concepts, design, and standard specifications of BPM. BPM today is somewhat of a morass, my book argues, with far too many misunderstood, misapplied, and excessively hyped vendors and standards. In its survey of the landscape of BPM, my book emphasizes standards over vendors, because standards are a better source of concepts, and bring greater clarity to the subject. Granted, BPM's standards are ostensibly a murky alphabet soup (see Table 1), but when the best of them are combined properly, they form a surprisingly intelligible architecture, shown in Figure 1.
|Business Process Execution Language (BPEL)||OASIS||Execution Language|
|Business Process Modeling Notation (BPMN)||Business Process Management Initiative (BPMI)||Notation language|
|Business Process Modeling Language (BPML)||BPMI||Execution language|
|Business Process Query Language (BPQL)||BPMI||Administration and monitoring interface|
|Business Process Semantic Model (BPSM)||BPMI||Process metamodel, in fashion of Object Management Group (OMG) Model-Driven Architecture (MDA)|
|Business Process Extension Layer (BPXL)||BPMI||BPEL extension for transactions, human workflow, business rules|
|UML Activity Diagrams||OMG||Notation language|
|Workflow Reference Model||Workflow Management Coalition (WfMC)||Architecture|
|XML Process Definition Language (XPDL)||WfMC||Execution language|
|Workflow API (WAPI)||WfMC||Administration and monitoring, human interaction, system interaction|
|Workflow XML (WfXML)||WfMC||Choreography (or similar to it)|
|Business Process Definition Metamodel (BPDM)||OMG||Execution language and/or notation language, as MDA metamodel|
|Business Process Runtime Interface (BPRI)||OMG||Administration and monitoring, human interaction, system interaction, as MDA metamodel|
|Web Services Choreography Interface (WSCI)||World Wide Web Consortium (W3C)||Choreography|
|Web Services Choreography Description Language (WS-CDL)||W3C||Choreography|
|Web Services Conversation Language (WSCL)||W3C||Choreography|
|Web Services Flow Language (WSFL)||IBM||Execution language|
|Business Process Schema Specification (BPSS)||OASIS||Choreography (and collaboration)|
Figure 1. BPM architecture--click for full-size image
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
The architecture might be not have any current implementations, but, using the example of a retailer's handling of a purchase order, let's approximate its prescribed development cycle and build an actual process. We begin with choreography. A retailer process does not operate in isolation, but rather collaborates with consumer processes to receive orders and warehouse processes to have orders filled. The choreography can be described in plain English as follows:
A consumer sends a purchase order to a retailer.
The retailer sends to the consumer an acknowledgement that it received the purchase order.
The retailer forwards the purchase order to a warehouse, passing to it the electronic address of the consumer. The warehouse will use this address to notify the consumer when the order is complete.
If the warehouse accepts the order, it sends a positive acknowledgement to the retailer. If the warehouse rejects the order, it sends a negative acknowledgement to the retailer. In each case, the retailer forwards to the consumer the result from the warehouse.
Assuming it accepted the order, when the warehouse has finished its processing and is ready to ship the goods, it sends a notification directly to the consumer.
The benefit of WS-CDL is that it can encode these steps formally in an XML language. The first two steps in the English description above are represented in WS-CDL by the code in Example 1.
Example 1. WS-CDL consumer-retailer interaction
1 <interaction name="POInteraction" channelVariable="tns:RChannel" 2 operation="handlePO" initiate="true"> 3 <participate relationshipType="tns:CRRelationship" 4 fromRole="tns:Consumer" toRole="tns:Retailer"/> 5 <exchange name="POReq" informationType="tns:PO" action="request"> 6 <send variable="cdl:getVariable(poC, tns:Consumer)"/> 7 <receive variable="cdl:getVariable(poR, tns:Retailer)"/> 8 </exchange> 9 <exchange name="PORsp" informationType="tns:POAck" action="respond"> 10 <send variable="cdl:getVariable(poAckR, tns:Retailer)"/> 11 <receive variable="cdl:getVariable(poAckC, tns:Consumer)"/> 12 </exchange> 13 </interaction>
This code describes an interaction with two exchanges: in the first exchange (lines 5-8) the consumer sends (
action="request") a purchase order (
informationType="tns:PO") to the retailer; in the second (lines 9-12), the retailer responds (
action="response") with a purchase order acknowledgment (
The first step in building the retailer process is to generate a BPMN diagram that satisfies the retailer's required role in the choreography. Today this step is necessarily manual; there is no current WS-CDL tool that can generate BPMN (www.pi4tech.com presents a good source of information about the one or two current experimental WS-CDL implementations). The manual approach is to look at the choreography and draw a process that fits the role; Figure 3 shows the BPMN diagram representing the retailer as a participant in the choreography.
Figure 3. Retailer process to satisfy choreography (BPMN representation)
The logic of the process is straightforward. The process starts when it receives a purchase order (PO) message from the consumer ("PO From Consumer"). It then successively sends an acknowledgement of receipt to the consumer ("Send Receipt Ack to Consumer") and forwards the PO to the warehouse ("Send PO to Warehouse"), before waiting until it receives a response from the warehouse ("Wait Warehouse Response"). When the response arrives, the retailer process forwards it to the consumer ("Send Warehouse Response to Consumer"), and the process completes. The notation is clear and intuitive: the boxes perform "activities," the circles with enclosed letter symbols wait for "events," the empty circle marks the endpoint of the process.
Figure 4 shows the process with the addition of private steps (i.e., steps not required by the choreography but driven by internal requirements). These steps are italicized: "Write PO to DB" persists the purchase order to an internal retailer database when it arrives from the consumer; "Update PO Status in DB" updates the database record with the status of the warehouse response (i.e., accept or reject); "Sales Followup" is a manual task, assigned to a sales representative to help the consumer resubmit the order in case it was rejected by the warehouse. (The diamonds in the figure are called XOR gateways. When combined, they form a conditional code structure that works like an
if statement. Gateways are discussed at length in Essential Business Process Modeling.)
Figure 4. Complete retailer process (BPMN)--click for full-size image
These diagrams were drawn with ITpearls' Process Modeler, which is a set of BPMN stencils for Microsoft Visio. Process Modeler is not a full-fledged process development tool, but merely a drawing application. It cannot, for example, generate BPEL code; this step, too, is manual. Regardless, the diagrams are valuable for design documentation; just as a UML drawing tool that cannot generate actual Java or C# code can still help software architects document the objects and components of an application, so Process Modeler helps business analysts or architects render process flows in a standard process representation.
As it turns out, the mapping to BPEL is straightforward: the "events" of the BPMN process (e.g., "Wait Warehouse Response") are BPEL "receive" activities (or activities that wait for events to occur); the "activities" (e.g., "Send PO to Warehouse") are BPEL "invoke" activities (or activities that call services); the conditional structure enclosing "Sales Followup" is a BPEL "switch" activity; and the entire flow is a "sequence" activity. The BPEL code, each of whose eight steps derived from BPMN is indicated by a comment (e.g., line 12 indicates step 1), is provided in Example 2.
Example 2. Retailer BPEL code
1 <process name="Retailer" 2 targetNamespace="http://acm.org/samples" suppressJoinFailure="yes" 3 xmlns:tns="http://acm.org/samples" 4 xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" 5 xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/ business-process/"> 6 7 <!-- some code omitted - -> 8 9 <!-- Mainline process code starts here --> 10 <sequence name="main"> 11 12 <!-- Step 1: Consumer sends PO --> 13 <receive name="receiveInput" partnerLink="consumer" portType="tns:Retailer" 14 createInstance="yes" operation="sendPO" variable="po"> 15 <!-- Use the inbound PO message as the basis for correlation --> 16 <correlations> 17 <correlation set="poset" initiate="yes"/> 18 </correlations> 19 </receive> 20 21 <!-- Step 2: Send receipt ack to consumer --> 22 <invoke name="callbackClient" partnerLink="consumer" 23 portType="tns:RetailerCallback" operation="poReceipt" 24 inputVariable="po"/> 25 26 <!-- Step 3: create PO record in internal database --> 27 <invoke name="writePOToDB" partnerLink="retailerDB" portType="tns:RetailerDB" 28 operation="createPO" inputVariable="po"/> 29 30 <!-- Step 4: send PO to warehouse --> 31 <invoke name="sendPOToWH" partnerLink="warehouse" portType="tns:Warehouse" 32 operation="sendPO" inputVariable="po"/> 33 34 <!-- Step 5: wait for warehouse response --> 35 <receive createInstance="no" name="receiveWHResponse" partnerLink="warehouse" 36 portType="tns:WarehouseCallback" operation="onResult" 37 variable="poResponse"> 38 <!-- correlate on identifiers in initial PO --> 39 <correlations> 40 <correlation set="poset" initiate="no"/> 41 </correlations> 42 </receive> 43 44 <!-- Step 6: send warehouse response to consumer --> 45 <invoke name="responseToConsumer" partnerLink="consumer" 46 portType="tns:RetailerCallback" 47 operation="poResult" inputVariable="poResponse"/> 48 49 <!-- Step 7: update PO in internal database --> 50 <invoke name="updateDB" partnerLink="retailerDB" portType="tns:RetailerDB" 51 operation="updatePO" inputVariable="poResponse"/> 52 53 <!-- Step 8: Special processing if warehouse rejected PO --> 54 <switch name="checkResp"> 55 <!-- It's a reject if the "action" field of the 56 warehouse response is "reject" --> 57 <case condition="bpws:getVariableData( 58 "poResponse","payload", 59 "/tns:POMsg/tns:action") = "reject""> 60 <sequence> 61 <!-- Assign a task to a sales rep to contact the consumer about the 62 rejection. Fire and forget: don't bother waiting for the result 63 of the task. --> 64 <invoke name="salesFollowup" partnerLink="taskMgr" 65 portType="tns:WorkflowTaskManager" 66 operation="create" inputVariable="task"/> 67 </sequence> 68 </case> 69 <otherwise/> 70 </switch> 71 </sequence> 72 </process>
In the BPEL code, "partner links" (marked by the
partnerLink XML attribute, such as
partnerLink="consumer" in line 13) are used to identify the parties with which the process converses. Four partner links are used:
consumer, representing the consumer process, is used in steps 1, 2, and 6.
warehouse, representing the warehouse process, is used in steps 4 and 5.
retailerDB, a web service interface to the retailer's internal database, is used in steps 3 and 7.
taskMsg, a web service interface to human workflow, is used in step 8.
All three types of process interactions are represented:
warehouse are external system interactions,
retailerDB an internal system interaction, and
taskMgr human interaction. All interactions are web-service-based. Each partner has a WSDL that describes its interface. Interestingly, the retailer process itself is a web service; its "receive" activities are web service operations, which are documented in a WSDL that the process published to its partners.
Unlike BPMN and WS-CDL, BPEL has an abundance of good tools, such as Oracle's BPEL Process Manager, which is put to use in the development of two substantial BPEL examples in Essential Business Process Modeling. Oracle's platform can be used to test the retailer process.
The realization of those sketchy flowcharts drawn by business analysts on whiteboards requires an architecture built on the best of BPM's many standards: BPEL, BPMN, and WS-CDL. Alas, no actual vendor implementation of this architecture exists today, but, as our retailer process example shows, a useful approximation can be fashioned.
Michael Havey is an architect of several major BPM applications and author of magazine articles on BPM and process-oriented applications.
View catalog information for Essential Business Process Modeling
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.