An Introduction to BPEL standard and its extentions

Transcription

1 An Introduction to BPEL standard and its extentions Yanbo Wu T Special Course in Information Systems integration, HUT, Finland Abstract. BPEL (also known as WS-BPEL) is an XML-based language that allows business to describe inter or intra enterprise business processes that are connected via Web services. Due to the limitation of traditional methods for business integration and process automation, BPEL came to the picture and highly promoted by companies such as IBM and Oracle. Specification of WS-BPEL 2.0 has been approved as OASIS Standard. In practice, BPEL is typically used when approve loan request and make travel reservation. To support a broaden range of scenarios involving people and sub-process within business processes, two BPEL extensions, BPEL4People and BPEL-SPE, are developed. Both extensionts are still in their early stages. Due to the increased importance of business integation, EU SUPER project started in 2006 aiming to achieve better cooperation between IT and business.

2 1. INTRODUCTION 1.1 Background Web Service Orchestration (WSO) provides the ability to integrate and assemble individual Web services into standards-based business processes. It is a bridge to connect an enterprise s Service Oriented Architecture and a critical layer in the web services technology. To facilitate WSO, the Business Process Execution Language (BPEL) was created to standardize integration logic and process automation between web services. Combination of business process execution standards and Web services promises to dramatically reduce costs and provide broader interoperability and reusability benefits. BPEL or WS-BPEL permits orchestration of web services. While the obvious business activity of a human interaction and sub-process are not covered by BPEL. To support a broaden range of scenarios, several BPEL extensions were proposed, and in this paper BPEL4People and BPEL-SPE are being discussed. 1.2 Objective to review current BPEL and the proposed extensions General picture of BPEL, its extension BPEL4People and BPEL-SPE Specification of above standard Study the result of EU SUPER project 1.3 Scope of this paper Basic concept of latest on BPEL related technology Simple case analysis 1.4 Research problem In this paper, I study the current BPEL standard and what can be achieved with it, as well as the proposed extensions and their improvement over the existing BPEL standards. 1.5 Methodology Literature review is the main methodology used in this project. The sources for literature are from Internet, academic journals, books and thesis database. 1.6 Structure of report 1. Introduction of project 2. BPEL and its application in business 3. BPEL4People 4. BPEL-SPE 5. EU Super project 6. BPEL case study 7. Conclusion 8. Reference

3 2. BPEL AND ITS APPLICATION IN BUSINESS Web service is thought to be the next great thing in the area of e-commerce and system integration. However, Web service is merely great technology without a way for business to use it, unless there is a common standard to orchestrate multiple services into business and audit/manage the results. BPEL acts as glue to connect Web services and cohesive business solution, enables the orchestration of tasks in web-based services. 2.1 What is BPEL? BPEL (Business Process Execution Language), also known as BPEL4WS or WSBPEL, is an XML-based language that allows business to describe inter or intra enterprise business processes that are connected via Web services. BPEL is the convergence of language features of IBM s WebService Flow Language (WSFL) and Microsoft s XLANG [1]. As an XML-based language, BPEL describes the logic to coordinate Web services in a process flow. The XML grammar can be interpreted and executed by a BPEL orchestration engine, which controls all activities in the process [1]. Many companies including IBM, Oracle as well as open source organizations have released BPEL implementations in their platforms and tools. The available BPEL engines includes Oracle BPEL Process Manager, IBM BPWS4J, Apache ODE, ActiveBPEL, Twister [2] 2.2 Why BPEL is needed? Traditional methods for business integration and process automation usually involve logic inside of applications designed to meet a specific business need such as ERP, supply chain, CRM. The development, testing and making the change of such applications can be quite costly and complicated [1-4]. To solve the problem, proprietary Enterprise Application Integration (EAI) and Business Process Management (BPM) emerged to raise integration and process automation into a new level of software tools [5]. But proprietary EAI and BPM are too expensive [5]. XML-based Web services came into picture as a solution. However, Web services do not fulfill the need to integrate and coordinate business processes themselves. This is where BPEL appeared (Figure 2.1) [1, 5]. Adoption of Web services and BPEL enhances productivity, reduces operating costs and betters service through process automation.

4 Traditional business integration and process automation methods Expensive to make changes Web services W Proprietary EAI and BPM Too expensive Implementation of Internet transport protocols (HTTP, SMTP) Data model (XML) Message exchanged (SOAP) Description of service operations and specifications (WSDL) Publishing and discovery of services (UDDI) Unable to fill the need themselves BPEL Figure 2.1: Development of process integration and process automation [1, 5] 2.3 Development BPEL 1.0 was initially developed by Microsoft, IBM and BEA as BPEL4WS in August In April 2003, BPEL 1.1 was first submitted to OASIS to obtain broader acceptance and open standardization [3, 6]. The OASIS WS-BPEL technical committee voted on 14 September 2004 to name their specification WS-BPEL 2.0, and approved it as OASIS standard on 12 April 2007 [2, 7]. 2.4 What can BPEL do? BPEL makes it possible to keep internal business processes separated from external enterprise processes. Hence, changing of internal processes will not affect data exchange between enterprises [3]. BPEL provides enterprise with a standard for business orchestration and execution. It specifies how to send/receive XML messages, exchange message with partners, implement parallel or sequential process, manipulate data between partner interactions, define parallel/sequential execution, etc [6]. By using BPEL it Makes integration with business partners easier and more effective Stimulates enterprises to further define their business processes, Leads to further optimizing the business process

5 3. BPEL4PEOPLE 3.1 Limitation of BPEL4WS and demand for BPEL4People BPEL permits orchestration of web services, while the obvious business activity of a human interaction within a process is not covered by BPEL [8], and this means that vendors will most probably create their own proprietary extention to BPEL, and this will result worse interoperability between products, therefore it makes sense to standardize this part of the process too. However the activities that make up general business processes are broader than this, because people often participate in the execution of business processes. To support a broaden range of scenarios involving people within business processes, a BPEL extension is required [9, 10]. An additional group of syntax and semantics which focus on the description has to be added to BPEL. 3.2 Development of BPEL4People IBM and SAP recognized the importance of extending BPEL for people and jointly published a white paper in July 2005 [13, 14, 15, 19]. It addresses various BPEL4People requirements and scenarios. In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications, which define an approach for integrating human interactions using WS- BPEL 2.0 [9-12]. The authors of BPEL4People plan to submit the specifications to OASIS (Organization for the Advancement of Structured Information Standards) in the near future [12]. 3.3 BPEL4People specification A BPEL language contains features needed to describe complex control flows. Since human interactions are usually involved in business process, BPEL process should define people as another type of participants. BPEL4People is now comprised of two specifications [12]: WS-BPEL Extension for People (BPEL4People) Version 1.0, which features lay on top of WS-BPEL to describe human tasks as activities that may be incorporated as first-class components in WS- BPEL process definitions. Web Services Human Task (WS-HumanTask) Version 1.0, which introduces stand-alone human tasks. Web Services Human Task may be utilized by Web services-based applications beyond WS-BPEL processes. BPEL specification focus on the business activities which interact with Web services. BPEL4People specification extends BPEL elements and enables the modeling of human interaction patterns [12]. Complete specifications of BPEL4People 1.0 and WS-HumanTask 1.0 can be found at [13, 14] People integration To achieve best possible interact between people and process, it is essential to understand people roles in the process and how process identifies the people to interact with.

6 Human roles In BPEL4People process, four generic human roles are defined: process initiator, process stakeholders, potential owner and business administrators [13, 15]. Process initiator is the person who triggers the process instance. The initiator can be either determined by the process automatically or specially assigned. Process stakeholder is the person who can influence the progress of a process instance. Their responsible can be adding attachment, forward task or follow the process progress. If no process stakeholders are specified, the process initiator becomes the process stakeholder. The process stakeholder is only associated with a process instance. Potential owner is the person who is assigned to claim and complete the activity. Business administrator is the person who is allowed to perform administrative actions on the business process. If no business administrators are specified, the process stakeholders become the business administrators. Unlike process stakeholder, a business administrator has an interest in all process instances and not just one People link People links are used to bind a group of people to a business process, they are similar to partner links which are used to bind Web services to processes. People links are usually associated with generic human roles. Using human roles and people link, a people activity is defined (Section ) Scenarios People interaction can be as simple as manual approval, such as giving approval/rejection to loan request. People interaction can be more complex involving data, such as feeding customer feedback to the process. The scope of BPEL4People is described in five scenarios [15] People activity The new BPEL activity people activity is not performed by any software, it is the task assigned to a user and it requires action be performed by that user [15]. The actor of a people activity is determined by a people link. In PBEL4People, BPEL engine does not invoke Web services, instead it creates and distribute a task to certain user. And user needs to carry out specific action on task. Like BPEL activity, people activity has name and input/output variable, it allows the specification of deadlines. Moreover, people activity can set a priority, which prioritizes the work people work on [15] Initiating process When a group of people involved in a business process, it is necessary to appoint people who initiate a business process.

7 Managing process In a long-running business process, continuous human involvement may be expected. Let s use an online voting system as example. The online voting site could be jammed due to excess data flow. In order to keep the process running smoothly, people with adequate business knowledge should be assigned as business administrators, and shut down the voting system temporarily, when the excess data flow reaches certain limits. These business administrators (humans) play crucial role to ensure the running running and best possible outcome of the process[15] Human and automatic services transition This scenario defines that two-way transition between human and automatic services must be nondisruptive Advanced people interaction Above four scenarios are simple task and execution actions. In many cases people interact with process in a more complex pattern, which requires BPEL4People [15]. 4-Eyes Principle takes place when decision needs to be made independently by two or more users. In the extreme case, users are not allowed to know who else is involved in the decision making. Escalation is used if a task does not progress as expected or it does not meet its deadline. If it occurs, a notification is sent to escalation recipients. Then they will decide further actions to get the process back on track. Nominations, just as its name implies, it is used to nominate user for certain task. Chained execution referes to scenario where a sequence of actions is taken by a same person. In this wizard-style interaction, the person running the process is also the process initiator Task The work people perform is defined as task, which has following properties [15]: Multilingual description Priority Expected data Deadline User interface When task is integrated with process, two patterns are formed: inline tasks or standalone tasks [15].

8 BPEL Process BPEL Process BPEL Process BPEL Process People Activity People Activity People Activity People Activity Inline Human task Inline Human task Standalone Human task Callable WSDL Interface HT Protocol Interface Standalone Human task Figure 3.1: Interaction patterns between process and task [15] In Pattern 1, the task is specified inline within a People activity. In Pattern 2, the task is specified inline within the BPEL process. In both patterns, the task automatically shares process context and data. In Pattern 3, the task is defined externally to the process without a specific interface, In that way application vendors can expose their functionality as tasks which can be called from BPEL process engines. Pattern 4 is like 3 except that the task interface is specified using a callable WSDL, which is invoked using Web services. Moreover, WS-HumanTask is used for communication between process and task. 4. WS-BPEL 2.0 EXTENSIONS FOR SUB-PROCESSES BPEL-SPE 4.1 Demand for BPEL -SPE Besides excluding people action, BPEL does not support the explicit definition of business fragments that can be invoked from another (or the same) business process either [16]. In both the BPEL4WS 1.1 and the WS-BPEL 2.0 specifications,, the only way to simulate this behavior is to define a complete business process as an independent service and invoke it via invoke activity. However, sub-process is completely hidden from its parent process, namely it does not have lifecycle coordination with its parent process. 4.2 Development of BPEL-SPE In September 2005, IBM and SAP published a white paper called Extensions for Sub-Processes (BPEL- SPE). The paper calls for the explicit definition of sub-processes, allowing for the reuse of the subprocess, tight coupling of the sub-process's lifecycle with its parent process, and the ability of the subprocess to access its parent processes data [16]. The language specification defining the precise syntax and semantics will be published in the future.

9 4.3 Sub-process As a fragment of BPEL code a sub-process should be reused within a process or across multiple processes [15]. It can be defined as standalone sub-process and inline sub-process (Table 4.1). Table 4.1: Sub-processes types Standalone Sub-process Definition Defined within another BPEL process Reuse Reused only within that process Access to variables Can access only global process variables Properties Have its own variables, partner links, receive activity Inline Sub-process Defined as a BPEL process Reused across other BPEL process Can access no variables from other processes Does not have its own variables, partner links, receive activity 4.4 Invoke activity Two invoking mechanisms between parent process and sub-process are supported by BPEL-SPE Via a reply activity Via a one-way invoke activity Parent Process <Call> WSDL request response Sub-Process <Receive> <reply> Figure 4.1: Receive-reply invocation mechanisms [15] Sub-process receives the input message via its receive activity and responds the message via its reply activity.

10 Parent Process <Call> Call... partnerlink= PL requestoperation= op1 responseoperation= op2 Op1 Sub-Process <Receive> Op2 PT2 PL PT1 <reply> Figure 4.2: Receive-invoke invocation mechanisms [15] The parent process uses call activity to call sub-process. The call activity specifies the port type which is used to send the input message to sub-process and port type which contains the operation to be used by sub-process to return a message. Several parent processes can call same sub-process, which means subprocess needs to return message to different endpoints. Therefore it is important that those endpoints in parent processes are recognizable by the process engine hosting sub-process, so that response message can be sent back successfully [15]. 4.5 Coordination scenarios There are seven coordination scenarios between a parent process and a sub-process (Figure 4.3)[15] Parent process Request operation Response operation Close Close Sub-process Figure 4.3a Invocation of sub-process without compensation Sub-process is invoked and message is returned. After parent process is completed, sub-process is closed.

11 Parent process Request operation Response operation Compensate Compensate Sub-process Figure 4.3b: Invocation of sub-process with compensation Sub process is invoked and message is returned. Compensation occurs and it passes to sub-process. Parent process Sub-process Request operation Response operation fault data Figure 4.3c: Invocation of sub-process with application fault Sub process is invoked, but it does not send result back to parent process, instead it sends fault data and closes. Parent process Sub-process Request operation AbnormalSubprocessTermination Figure 4.3d: Invocation of sub-process with application fault Sub process is invoked, but it does not send message back to parent process as it should be. AbnormalSubprocessTermination is sent to parent process.

12 Parent process Request operation Terminate Terminate Sub-process Figure 4.3e: Invocation of sub-process with termination Sub process is invoked. Parent process is terminated and termination is passed to sub-process. Finally, termination completion is sent back to parent process. Parent process Sub-process Request operation SubprocessExited Figure 4.3f: Invocation of sub-process with exit (parent process to sub-process) Sub process is invoked. Parent process encounters an exit activity and exit is passed to sub-process. SubprocessExited is sent to parent process. Parent process Request operation Sub-process Exited Figure 4.3g: Invocation of sub-process with exit (sub-process to parent process) Sub process is invoked and it encounters an exit activity. The exit is passed to parent process. Sub-process exits in turn. 4.6 Future action The white paper only recognizes the problem of process reused in BPEL, describes different invocation scenarios and coordination mechanisms between parent process and sub/process. However, no consensus on how the problem should be resolved. No other official paper had been released than BPEL-SPE white paper. Detailed BPEL-SPE language specification (syntax and semantics) is still under construction

13 5. EU PROJECT SUPER It happens quite often that IT staff is needed to solve business problems. The situation is quite troublesome, which is both resource and time consuming. The needs for better alignment between IT and business are getting stronger. Starting on 1st April 2006 Semantics Utilised for Process Management within and between EnterpRises project, also called SUPER project, is an integrated project funded by European Sixth Framework Program. It has 3-year duration. 19 educational and industrial partners take part in the project [17, 18]. Overall budget of the project is 16.4 M Euro, of which 11 M Euro is from funding [18]. SUPER project intends to raise business process management (BPM) from the IT level to the business level. It will enable business to use information technology more efficiently and to make cooperation between IT and business better. To achieve this objective, the project aims at adopting Semantic Web Services technology to make companies more adaptive. In 2006 the BPM domain was framed. In 2007 SUPER focused on the tools of semantic technologies in the business process domain [19]. 6. CASE STUDY EXAMPLE OF THE USE OF BPEL BPEL4People and BPEL-SPE are still on their very early stage, no specification has been approved as OASIS standard. Since, their language specifications and structures are based on BPEL, I will take a simple BPELWS example to illustrate how BPEL related application is used in practice [20]. 6.1 Case scenarios In the case, a loan procurement application is implemented by a bank called Superloan. An applicant sends a loan request, then the request is handled by Superloan, finally the decision is sent back to applicant stating whether the loan is permitted or not. 6.2 Setting up the system In BPEL receive activity, invoke activity and reply activity are used for getting a message, invoking the Web service and returning results to customer respectively [20, 21]. Since above three actions are taken on after the other, it needs sequence activity to ensure they occur in right order. That will means first receive to get the message, then invoke to call Superloan approval process, and finally reply to send decision to applicant (Figure 6.1).

14 Applicant Superloan BPELWS loan approval process <receive> <invoke> <Reply> Loan approver Web servie Figure 6.1: Loan approval process 6.3 Service description In order to exchange the message and invoke the Web service WSDL, description of services involved in the BPEL process must be written beforehand. In this case, loan definitions, loan approval service and loan approval process. 6.4 Creating process BPEL process likes a box where relationship to external partners, handlers for various purpose and activities to be executed can be declared [21]. A BPEL process always begins with process. 1 <process name="loanapprovalprocess" targetnamespace=" xmlns=" xmlns:lns=" xmlns:loandef=" xmlns:apns=" Each service interaction in BPEL process is modeled as a partnerlink. For one partner, there can be a several partner links. In order to specify the role and the type of a partner, PartnerLinkType and a role name are used [21]. In the case the partners are the applicant and loan approver. MyRole means the role process plays, while partnerrole means the role that partner plays. 1 <partners> <partner name="applicant" servicelinktype="lns:loanapprovelinktype" myrole="approver"/> <partner name="approver" servicelinktype="lns:loanapprovallinktype" partnerrole="approver"/> </partners>

15 Message is stored in containers to where BPEL can have access [20]. <containers> <container name="request" messagetype="loandef:requestmessage"/> <container name="approval" messagetype="apns:approvalmessage"/> 6.5 </containers> Receive, invoke and reply activity Receive, reply and invoke are the activities for exchanging messages with external partners. Receive is used for receiving messages from an external partner. It always specifies the partnerlink and an operation that can be invoked. A process can be initiated by setting createinstance to yes in a receive activity. <sequence> <receive name="loanapprover" partner="applicant" porttype="apns:loanapprovalpt" operation="approve" container="request" createinstance="yes"> </receive> After the message is received, loan approver is asked whether the loan will be approved or rejected. This is done by invoke activity. Invoke activity is used to call a Web service which has been defined as a partner. Like reply, a partnerlink and operation have to be specified. Executable BPEL is requestresponse operation where both input and output variable are required. <invoke name="invokeapprover" partner="approver" porttype="apns:loanapprovalpt" operation="approve" inputcontainer="request" outputcontainer="approval"> </invoke> After decision is made by loan approver, the result is sent to applicant via reply activity. Reply activity provides means to send a response to partners by specifying a partnerlink and operation. A reply activity can be only placed after a receive activity with same partnerlink and operation. After reply activity, the process ends. The sequence and process tags need to be closed. <reply name="reply" partner="applicant" porttype="apns:loanapprovalpt" operation="approve" container="approval"> </reply> </sequence> </process>

16 The diagram 6.2 shows the sequence of actions executed in loan approval process. W <process> Applicant 2 Request container 1 6 <receive> <invoke> <Reply> 3 4 Loan approver Web servie 4 Approval container 1: Applicant sends message 2: Message is stored in request container 3 & 4: Invocation of Web serviced 5: Message from invocation is stored in approval container 6: Result is sent to applicant Figure 6.2: The sequence of actions executed in loan approval process The BPEL process can be run from BPEL engine which has been available in the market (See section 2.1) 7. CONCLUSIONS BPEL is convergence of language features of IBM s WebService Flow Language (WSFL) and Microsoft s XLANG. As an XML-based language, BPEL describes the logic to coordinate Web services in a process flow. BPEL was first proposed by Microsoft, IBM and BEA as BPEL4WS in August On 12 April 2007 BPEL 2.0 was approved as OASIS standard. BPEL process needs to be run via BPEL engines, which have been developed by several vendors. BPEL-WS provides a standard language for business orchestration and execution. By using BPEL it makes integration with business partners easier and more effective, it also leas to further process optimization. However, BPEL does not cover human interaction. To support a broaden range of scenarios, BPEL extensions are required. In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People specifications, which define an approach for integrating human interactions using WS- BPEL 2.0. The specifications will be sent to OASIS for approval in the near future

17 Besides excluding people action, BPEL does not interaction between sub-process and parent process either. In September 2005, IBM and SAP published a white paper called Extensions for Sub-Processes (BPEL-SPE). The paper recognizes the problem of process reused in BPEL, describes different invocation scenarios and coordination mechanisms between parent process and sub/process. However, no consensus on how the problem should be resolved. Many efforts still need to be made before BPEL-SPE specification is finalized. In order to improve the interaction between IT and business process management, EU founded project SUPER was kicked off on 1st April The project intends to adopt Semantic Web Services technology to enable business to use information technology more efficiently and to make cooperation between IT and business better. 8. REFERENCE [1] Matjaz B. Juric, A Hands-on Introduction to BPEL, accessed 09 DEC 2007, URL: [2] Wikipedia, 2007, Business Process Execution Language, accessed 09 DEC 2007, URL: [3] 2005, Business Process Executive Language, accessed 09 DEC 2007, URL: [4] Christoph Schittko, 2003, XML conference & Exposition, Web Service Orchestration with BPEL, accessed 09 DEC 2007, URL: [5] Michael Cobban, 2004, What is BPEL and why is it so important to my business? accessed 09 DEC 2007, URL: [6] Oracle White Paper, 2004, Orchestrating Web Sevices: The case for a BPEL Server, accessed 09 DEC 2007, URL: [7] 2007, The approval of WS-BPEL as OASIS standard, accessed 09 DEC 2007, URL: [8] Ta id Holmes, 2007, BPEL4People: extending WE-BPEL for People, accessed 09 DEC 2007, URL: [9] 2007, WS-BPEL Extension for People, accessed 09 DEC 2007, URL: [10] Yoichi Takayama, 2007, WS-BPEL Extension for People, accessed 09 DEC 2007, URL: BPEL+Extension+for+People+(BPEL4People) [11] Wikipedia, 2007, BPEL4People, accessed 09 DEC 2007, URL: [12] 2007, BPEL4People Specifications Integrate Human Interactions Into Business Process, accessed 09 DEC 2007, URL: [13] Ashish Agrawal, etal., 2007, WS-BPEL Extension for People Version 1.0, [14] Ashish Agrawal, etal., 2007, Web Services Human Task Version1.0, accessed 09 DEC 2007, URL:

18 [15] A joint White Paper by IBM and SAP, 2005, WS-BPEL Extension for People-BPEL4People [16] A joint White Paper by IBM and SAP, 2005, WS-BPEL Extension for Sub-process BPEL-SPE [17] 2006, SUPER Showcase, accessed 09 DEC 2007, URL: [18] 2006, Semantics Utilised for Process Management within and between Enterprises, accessed 09 DEC 2007, URL: ftp://ftp.cordis.europa.eu/pub/ist/docs/kct/super-presentation-apr07_en.pdf [19] 2006, SUPER Annual Report, accessed 09 DEC 2007, URL:ftp://ftp.cordis.europa.eu/pub/ist/docs/kct/super-annual-public-report-2006_en.pdf [20] Rania Khalaf, 2002, Business Process with BPELeWS: Learning BPEL4WS, accessed 09 DEC 2007, URL: [21] OASIS Primer, 2007, Web services business process execution language version 2.0