WS-BPEL (BPEL4WS)

BPEL is maintaind by OASIS Web Service Business Process Execution Lanugage (WSBPEL) TC. The current version is Web Services Business Process Execution Language Version 2.0 Committee Specification 31 January 2007 as of today (April 3, 2007).

History

XLANG (IBM, BEA, Sun, OASIS, SAP, INNODATA/ISOGENE) was an extension to WSDL "that describes the behavior of the service as a part of a business process" and first developed in 2001-5.

WSFL (Web Services Flow Laugnuage) was proposed by IBM.

BPML was proposed by BPMI (Business Process Management Initiative). BPMI is a part of OMG (Object Manageing Group), of which IBM, BEA, and others are the members.

All were superceded by BPEL4WS v1.0.0 09/15/02 First version delivered by Microsoft, IBM and BEA. The cuirrent version (2.0) is now called WS-BPEL.

What BPEL does

BPEL is a web service orchestration and execution language. It defines Processes with Activities, Flows, Compensations and so on. A Process is a composite of web services, which is defined with various input/output and the intrinsic flows (contorl, data, message) of the composite.

The following descriptions are taken from WS-BPEL v 2.0 Committee Specification 31 January 2007.

A <process> is made up of sections, such as <documentation>, <partnerLinks>, <variables>, <faultHandlers>, <eventHandlers> and one main "activity", usually a <sequence>.

If a <sequence> is used in the <process>, for example, it can nest other activities as sub elements.

E.g.

<process>
    <extensions>
    <import>
    <documentation>
    <partnerLinks>
        <partnerLink>
    <messageExchanges>
    <variables>
    <correlationSets>
    <falutHandlers>
        <faultHandler>
    <eventHandlers>
        <onEvent>
    <sequence>
        <receive>
        <flow>
        <reply>

WS-BPEL activity can be any of the following:  

Free BPEL Editors

• ActiveBPEL Designer is an Eclipse plugin. It comes as Windows installer (.exe file).
• TBD

BPEL example by ActiveBPEL

BPEL is an XML definition, but with ActiveBPEL you can edit the workflow graphically as well as view it as an XML (source).

ActiveBPEL's Loan Approval example is as below:

 
The source code for this diagram.
 

<?xml version="1.0" encoding="UTF-8"?>
<!--
	BPEL Process Definition
	Edited using ActiveBPEL(tm) Designer Version 3.0.0 (http://www.active-endpoints.com)
-->
<bpel:process
	xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
	xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
	xmlns:lns="http://docs.active-endpoints.com/activebpel/sample/wsdl/loan_approval/2006/09/loan_approval.wsdl"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="loanApprovalProcess"
	suppressJoinFailure="yes"
	targetNamespace="http://docs.active-endpoints.com/activebpel/sample/bpel/loan_approval/2006/09/loan_approval.bpel">
	<bpel:extensions>
		<bpel:extension mustUnderstand="yes"
			namespace="http://www.activebpel.org/2006/09/bpel/extension/process_coordination" />
	</bpel:extensions>
	<bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
		location="../BPEL_Samples/Resources/WSDL/loan_approval.wsdl"
		namespace="http://docs.active-endpoints.com/activebpel/sample/wsdl/loan_approval/2006/09/loan_approval.wsdl" />
	<bpel:partnerLinks>
		<bpel:partnerLink myRole="loanService" name="customer"
			partnerLinkType="lns:loanPartnerLinkType" />
		<bpel:partnerLink name="approver"
			partnerLinkType="lns:loanApprovalLinkType" partnerRole="approver" />
		<bpel:partnerLink name="assessor"
			partnerLinkType="lns:riskAssessmentLinkType" partnerRole="assessor" />
	</bpel:partnerLinks>
	<bpel:variables>
		<bpel:variable messageType="lns:creditInformationMessage"
			name="request" />
		<bpel:variable messageType="lns:riskAssessmentMessage"
			name="risk" />
		<bpel:variable messageType="lns:approvalMessage"
			name="approval" />
	</bpel:variables>
	<bpel:faultHandlers>
		<bpel:catch faultMessageType="lns:errorMessage"
			faultName="lns:loanProcessFault" faultVariable="error">
			<bpel:reply faultName="lns:unableToHandleRequest"
				operation="request" partnerLink="customer"
				portType="lns:loanServicePT" variable="error" />
		</bpel:catch>
	</bpel:faultHandlers>
	<bpel:flow>
		<bpel:links>
			<bpel:link name="receive-to-assess" />
			<bpel:link name="receive-to-approval" />
			<bpel:link name="assess-to-setMessage" />
			<bpel:link name="assess-to-approval" />
			<bpel:link name="setMessage-to-reply" />
			<bpel:link name="approval-to-reply" />
		</bpel:links>
		<bpel:receive createInstance="yes" operation="request"
			partnerLink="customer" portType="lns:loanServicePT"
			variable="request">
			<bpel:sources>
				<bpel:source linkName="receive-to-assess">
					<bpel:transitionCondition>
						($request.amount &lt; 10000)
					</bpel:transitionCondition>
				</bpel:source>
				<bpel:source linkName="receive-to-approval">
					<bpel:transitionCondition>
						($request.amount &gt;= 10000)
					</bpel:transitionCondition>
				</bpel:source>
			</bpel:sources>
		</bpel:receive>
		<bpel:invoke inputVariable="request" operation="check"
			outputVariable="risk" partnerLink="assessor"
			portType="lns:riskAssessmentPT">
			<bpel:targets>
				<bpel:target linkName="receive-to-assess" />
			</bpel:targets>
			<bpel:sources>
				<bpel:source linkName="assess-to-setMessage">
					<bpel:transitionCondition>
						($risk.level = 'low')
					</bpel:transitionCondition>
				</bpel:source>
				<bpel:source linkName="assess-to-approval">
					<bpel:transitionCondition>
						($risk.level != 'low')
					</bpel:transitionCondition>
				</bpel:source>
			</bpel:sources>
		</bpel:invoke>
		<bpel:assign>
			<bpel:targets>
				<bpel:target linkName="assess-to-setMessage" />
			</bpel:targets>
			<bpel:sources>
				<bpel:source linkName="setMessage-to-reply" />
			</bpel:sources>
			<bpel:copy>
				<bpel:from>'yes'</bpel:from>
				<bpel:to part="accept" variable="approval" />
			</bpel:copy>
		</bpel:assign>
		<bpel:invoke inputVariable="request" operation="approve"
			outputVariable="approval" partnerLink="approver"
			portType="lns:loanApprovalPT">
			<bpel:targets>
				<bpel:target linkName="receive-to-approval" />
				<bpel:target linkName="assess-to-approval" />
			</bpel:targets>
			<bpel:sources>
				<bpel:source linkName="approval-to-reply" />
			</bpel:sources>
		</bpel:invoke>
		<bpel:reply operation="request" partnerLink="customer"
			portType="lns:loanServicePT" variable="approval">
			<bpel:targets>
				<bpel:target linkName="setMessage-to-reply" />
				<bpel:target linkName="approval-to-reply" />
			</bpel:targets>
		</bpel:reply>
	</bpel:flow>
</bpel:process>

BPEL data model

A BPEL process includes one Activity element, which is the start point of the workflow. In the example, the <flow> is presented. It is connected by the use of declared <link> elements to other Activities. The <link> names are used in the linkNamed Attributes of both <target> and <source> elements which appear in various BPEL elements, namely <receive>, <assign>, <invoke> and <reply>.

If an element has two links coming in, it has two <target> elements. Similarly, if an element has two possible routes to take, it has two <source> elements to use the named <link> elements. The <transitionCondition> is assositated with the <source>, not with <link> (nor with <target>). This is in contrast with e.g. XPDL, which has chosen to bundle the <Condition> with the <Transision> in both graphical user interface and also the XML output.  Also, in XPDL, the activity IDs are used e.g. <Transition from="activity_1" to="activity_2">. Therefore, there is no need to use something like <source> or <target> to indicate the links in both Activity elements. In BPEL, the <source> and <target> are needed because it does not refer those Web Services elements but refer the named links, i.e. the connecion is <source> points to a <link> which is pointed by <target>. Repesenting what are created in the graphical interface and indicating relationships, this may be a faithful way.

The example uses names of Web Service ports and messages defined in WSDL and accessed from the BPEL editor in the exmaple (not shown). BPEL defines varibales from the messages which will be received from those web services and use them in the <transitionCondition>.

Since the Web Services expose only interfaces and the BPEL will orchestrate them to make an executable "Process", in BPEL you only see the usage of Web Service interfaces and a flow description.

Compared with traditional programming, it may be worhtwhile mentinging the a compensationHandler as a new concept. The above BPEL example does not define a compensationHandler. If you click the "compensationHandler" tab (with the real ActiveBPEL software), it is supposed to show one if it were defined.  The Compensation handling is different from error or exception handling, where automatic recovery may be performed by the system. In the BPEL context, by the time when the compensationHandler is reached, the actions may be performed to their completions and may not be reversed when it were ideal to be able to do so. In these cases, new actions must be performed to anull or comensate the effects to make amend to override the previous action(s) in order to bring the system to the desired state. E.g. When the order has been processed, the goods may be already delivered and the user may be charged. To "compensate" this to cancel the order, the new process must be started to request the goods to be returned and wait for it. When it arrives, it is necessary to update the stock list and to credit the customer account, etc. These actions are not a "roll back", but new sets of actions associated with "compensating" the order. For this reaosn, what can be done in case of compensation must be explicitely defined as a part of the process, in addition to its "forward" processing activities.

faultHandlers respond to "faults" defined in the Web Services' WSDL files. faultHandler may include compensation.

eventHandlers respond to events defined within this process as Web Service messages.

terminationHandlers may be called when activities are completed or terminated to provide the ability for scopes to control the semantics of forced
termination to some degree. It may include compensation. E.g.

<terminationHandler>
   activity
</terminationHandler>

BPEL syntax - some notes

Roles in BPEL

The "role" in BPEL is used in partnerLink:

The "roles" mentioned here are defined in WSDL using BPEL's namespace to assign the roles to the portTypes of the Web Service named "purchase".

Therefore, it is the "roles" the web services paly in the BPEL process, but not some participants like in othe workflow paradigm may mean.

Multiple-instance Activities in BPEL

BPEL specification mentions multiple-instances of activities may be created by the "loop" activities. It, however, does not seem to have any consrtruct which may be able to express the Multiple-instance Activitiy or Mutlple-instance Sub-activity which appear in BPMN specification. 

Problems with BPEL

A WS-BPEL page in ebXML and others note some problems with BPEL, namely:

• Business Transaction (BPEL has no ability to describe interactions as a transaction unit).
• Collaboration (A collaboration should be described as a whole. BPEL is not suited for it).
• Choreography (It is difficult to bind an abstract choreography, such as WS-CDL, to executable entities such as web serivces. See WS-CDL).
• No human interactions (see below).

In terms of translating BPMN to BPEL, "Translating Standard Process Models to BPEL", Chun Ouyang, et al. (2005) noted a following:

"Capturing workflow patterns such as multi-merge, arbitrary cycles and multi-
ple instances in BPEL is problematic."

BPEL4People

Please see BPEL4People and WS-Human Task