Business Process Execution Language for Web Service (BPEL)

BPEL is gaining increasing attention as a potential standard for the definition of executable business processes based on web services. This paper gives an overview of standardization efforts in the area of business process execution, of the main concepts of BPEL, and of its support in practice. 1 Business Process Execution and Standardization The standardization of business process management and workflow technology has been discussed for more than ten years (see e.g. [Hol04]). Several standardization bodies have proposed specifications for different aspects of business process management. The five bodies that have gained the most attention in this context are WfMC, OMG, BPMI, W3C, and OASIS. The WfMC (Workflow Management Coalition) has been the first organization to promote workflow standards. Its Workflow Reference Model distinguishes five interfaces of a workflow system [Hol94]. From WfMC’s set of specifications1 the XPDL standard for process definition (interface 1) is the most prominent (see [Wor05]). The BPMI (Business Process Management Initiative) started off in 2000 as an industry consortium to promote business process management standards. In 2002 BPMI published BPML [Ark02], an XML-based language for the specification of executable processes with web service interaction, and in 2004 BPMN [Whi04], a corresponding visual notation for business processes. The OMG (Object Management Group) first got involved with workflow technology as they accepted the Workflow Management Facility specification as a standard in 1998. In 2005 OMG and BPMI agreed to merge their business process related activities. As a consequence, BPMN is now an OMG standard. The W3C (World Wide Web Consortium) has published several standards for web service choreography. Choreography describes the interaction of distributed processes from a global point of view. WS-CDL [KBR05] is the most recent specification in this area. It is meant to be utilized in conjunction with process definition languages that define the private implementation of processes. OASIS (Organization for the Advancement of Structured Information Standards) is an in1see http://www.wfmc.org/standards/docs/Stds diagram.pdf for an overview of WfMC workflow standards and associated documents. dustry group that defines XML-based standards for web services and business integration. OASIS participates e.g. in the specification of the ebXML framework. For further details on business process related standards see [MzMP05]. Since 2003, OASIS is also responsible for the standardization of BPEL2. The work on BPEL started with a merger of IBM’s WSFL process definition specification with Microsoft’s XLANG which resulted in the first version of BPEL [CGK02]. In 2003 BEA, SAP, and Siebel joined in to extend BPEL to version 1.1 [ACD03]. Currently, the second version of BPEL is in the final phase of standardization3. 2 Main Concepts of BPEL BPEL is an XML-based language that models a business process as a composition from a set of elementary web services. A so-called BPEL engine is a dedicated software component that is able to execute BPEL process definitions. Each BPEL process can be accessed as a web service of the BPEL engine, too. The BPEL specification depends on the W3C standards WSDL for web service description, XML Schema for the definition of data structures, and XPath for retrieval of XML elements. Six of BPEL’s most important concepts are briefly presented in the following, i.e., partner links, variables, correlation, basic activities, structured activities, and handlers. We will use the element names of BPEL 2. • Partner links: A partner link provides a communication channel to remote web services which are used in the BPEL process. A respective partner link type must be defined first to specify the required and provided WSDL port types. • Variables: Variables are used to store both message data of web service interactions and control data of the process. A variable must be declared in the header of a BPEL process by referencing a WSDL or an XML Schema data type. • Correlation: As BPEL supports long-running business processes, there may be several process instances waiting for web service messages at a certain point of time. A correlation set specifies so-called properties, i.e. XPath statements to retrieve message parts that are unique for a specific process instance. According to a certain property value, like e.g. ordernumber = 1002006, a message is handed to the matching process instance. • Basic activities: The basic steps of a BPEL process are performed by basic activities. There are activities to send and receive messages from web services (receive, invoke, reply), to change the content of variables (assign), to wait for a certain period or up to a certain point in time (wait), or to terminate the process (exit, formally called terminate)4. The second version of BPEL introduces an activity to check conformance to a Schema (validate) and the possibility to add proprietary activities 2The old acronym is BPEL4WS (Business Process Execution Language for Web Services), the new one WSBPEL (Web Service Business Process Execution Language). The acronym BPEL can be used for both. 3The Committee Draft is available at http://www.oasis-open.org/committees/download.php/16024/wsbpelspecification-draft-Dec-22-2005.htm. 4Basic Activities in BPEL 2 are: receive, invoke, reply, assign, validate, empty, throw, rethrow, exit, wait, compensate, compensateScope, and extensionActivity. (extensionActivity). • Structured activities: The control flow of basic activities can be defined in two different styles: block-oriented or graph-based. Both styles can be mixed. Blockoriented control flow can be defined with structured activities. BPEL offers activities to specify parallel execution (flow), conditional branching based on data (if-else) or on receipt of a message (pick), sequential execution (sequence), and different loops (while, repeatUntil, forEach). Structured activities can be nested. Scopes are special structured activities. They mark-off the scope of local variables and handlers. Control flow can also be defined graph-based, but without introducing cycles, using so-called links. A link represents a synchronization between two activities. • Handlers: BPEL provides handlers to deal with unexpected or exceptional situations. Event handlers wait for messages or time events. They can be used to specify deadlines on the process level. Fault handlers catch internal faults of the BPEL process. If the fault cannot be cured, the compensation handler can be triggered to undo the effects of already completed activities. Finally, the termination handler offers a mechanism to force a process to terminate, e.g. due to external faults. Even though BPEL supports a rich set of primitives to specify executable processes, there are still some features missing towards full-fledged business process specification. The extension activity of BPEL 2 is a useful anchor point to fill these gaps. Currently, there are several BPEL extensions in progress of development, in particular BPELJ5 for Java inline code, BPEL4People6 for human worklists, and BPEL-SPE7 for sub-processes.