Investigation of BPEL Modeling

Transcription

1 Technical University Hamburg Harburg Department of Telematics Project Work Investigation of BPEL Modeling Kai Yuan Information and Media Technologies Matriculation NO March 2004

2 Abstract The Business Process Execution Language for Web Service (BPEL4WS) is a XML based standard for defining how to integrate Web Services to implement business processes. A BPEL4WS process is defined in terms of its interactions with partner. A partner may provide services to the process and also may require services from the process, or participate in two-way interaction with the process. This report focuses on the modeling of BPEL4WS. Two approaches of modeling BPEL4WS are analyzed. One is modeling BPEL using Unified Modeling Language (UML). The other one is using Collaxa BPEL Designer, which is a commercial product of Collaxa. At the end of this report, the two approaches are compared from various points of view, such as modeling tools, modeling detail level and converting model graphic diagram into BPEL codes. The advantages and disadvantages of two modeling approaches are analyzed also. 1

3 Contents 1 Introduction Motivation Objectives and Goal of this project Modeling BPEL with UML Why UML? UML profile and UML customization Model BPEL with UML Profile Defining a Business Process Data Types and Interfaces Modeling Protocol Modeling Process Modeling with state, port and protocol Basic Activity Modeling Event Handling Modeling Exception Handling Modeling Complete Payment Process Behavior Modeling UML to BPEL transformation Prerequisites The Procedure of converting Summary Modeling BPEL with Collaxa BPEL Designer Collaxa BPEL Designer introduction Model BPEL using Collaxa BPEL Designer Summary Validating a process execution with model Conclusion Comparison Similarities Differences Conclusion Advantages and Disadvantages of UML modeling approach Advantages and Disadvantages of Collaxa BPEL Designer Summary Appendix A The BPEL and WSDL file of Payment Process References

4 Index of Figures Figure 2.1 Class Diagram with <<Entity>> Stereotype in Rational Rose Figure 2.2 PayFlow Example 9 Figure 2.3 Model PayFlow process overview using UML activity diagram 10 Figure 2.4 Defining a Process with UML class diagram 11 Figure 2.5 Message types and part types 11 Figure 2.6 Message classes for use in the Payment Process 12 Figure 2.7 Notation for interfaces 12 Figure 2.8 Port Types in WSDL of Payment Process 13 Figure 2.9 Port types supported by PaymentProcessorService 13 Figure 2.10 Interfaces supported by payment process 13 Figure 2.11 Interfaces supported by PaymentProcessorService 14 Figure 2.12 Protocol notation 14 Figure 2.13 partnerlinks of Payment process 15 Figure 2.14 protocols and roles of Payment process 16 Figure 2.15 Notation for process modeling 17 Figure 2.16 Payment Process 17 Figure 2.17 Invoke notation 18 Figure 2.18 expanded invoke activity of Payment process 19 Figure 2.19 Expanded assign activity of Payment process 19 Figure 2.20 The Model of BPEL event handling 21 Figure 2.21 Payment process event handling 21 Figure 2.22 notation for exception handler modeling 22 Figure 2.23 Exception Handling in Payment process 23 Figure 2.24 Payment process payment process modeling 24 Figure 2.25 Procedure of from UML to BPEL 26 Figure 2.26 Export XMI from Rational Rose 26 Figure 2.27 Generate BPEL from XMI 27 Figure 3.1 Collaxa BPEL Designer 30 Figure 3.2 New Collaxa BPEL project creating dialog 31 Figure 3.3 Asynchronous process skeleton 32 Figure 3.4 BPEL Palette in Collaxa BPEL Designer 32 Figure 3.5 Properties of <scope> element 33 Figure 3.6 Payment process model in Collaxa BPEL Designer 34 Figure 3.7 Payment process overview in Collaxa BPEL Designer 35 Figure 5.1 Invoke activity model in UML 41 Figure 5.2 Invoke activity model in Collaxa BPEL Designer 41 Figure 5.3 Detailed information about Invoke activity 41 3

5 Figure 5.4 abstract process in Collaxa BPEL Designer 42 Figure 5.5 Synchronized BPEL model and code in Collaxa BPEL Designer 43 4

6 1 Introduction 1.1 Motivation Web services technology is rapidly evolving to meet complex needs of the enterprise customer. Today, Web services can communicate with each other, advertise and describe themselves, and be discovered and invoked using industry-wide specifications. The ability to integrate and assemble individual existing Web services into standards-based business process is an important element of the service-oriented enterprise. Business process execution standards and Web services will dramatically reduce vendor lock-in to greatly reduce costs and provide wider interoperability benefits. To meet these needs, Business Process Execution Language for Web service (BPEL shortly) was introduced by BEA, IBM, Microsoft and others. BPEL has the potential to create the foundation for new composite, Internet-scale, loosely coupled applications. As BPEL is becoming a standard of Web services orchestration, the service-oriented technology gains in popularity. It will be increasingly necessary to gain the overview of processes structures and the processes definitions; also it will be necessary to be able to design large-scale solutions that incorporate Web services. We therefore need some modeling approaches, which are valuable for solution design and comprehension. Also, modeling is the essential of model-driven architecture and development, which enables execute systems to be generated automatically from detailed models. 1.2 Objectives and Goal of this project The goal of this project is to investigate two BPEL modeling approaches through modeling a typical example using both of them. Finally find out the similarities and differences between them and also analyze the advantages and disadvantages of the two modeling approaches. The objectives of this project are: 1 Investigate whether it is helpful to use a BPEL model to validate a process execution 2 Investigate UML profile for BPEL 5

7 What can be modeled? What kind of models can be used? What are the available modeling tools? 3 Investigate Collaxa Designer 4 Model a typical example using both modeling approaches The example should contain asynchronous invokes, exception handling and event handling 5Compare the two modeling approaches and analyze the advantages and disadvantages of them 6

8 2 Modeling BPEL with UML As we talked in chapter 1, modeling BPEL is significant to design large-scale Web services orchestration solutions. This chapter will focus on modeling BPEL with UML. First of all, why use UML to model BPEL4WS and what kinds of tools are available for modeling will be explained in section 2.1. Later on section 2.2 introduces the concept of UML profile and UML customization. The core of this chapter is presented in section 2.3, which is how to model BPEL with UML profile for Automated Business Processes. As introduced before, model-driven architecture and development is able to generate executable system automatically. Modeling BPEL with UML certainly correspond model-driven architecture and development, section 2.4 presents how to transform UML model into BPEL automatically. Finally, the section 2,5, the last section of this chapter, gives a summary of this chapter. 2.1 Why UML? UML is an OMG standard, which can provide visual modeling notation to design and make complex system architecture understandable. UML has several general advantages: [2] UML is the most widely known Object-Oriented (OO) modeling notation. UML has a graphical notation which is readily understood, and a rich set of semantics for capturing key features of OO systems. UML is widely used in the development of object-oriented software and has also been used, with customizations, for component-based software, business process modeling, and systems design. This enables the considerable body of UML experience to be applied to the maturing Web services technologies. Moreover, the value of UML modeling of systems has the potential to increase significantly through the emergence of initiatives such as model-driven architecture and development which enables executable systems to be generated automatically from the detailed models. Section 2.3 will present this approach in detail. There are a number of tools can be used for modeling with UML diagrams, some of them support stereotypes, such as Rational Rose and Rational XDE. In order to model BPEL with UML, we need to extend UML through using a subset of the UML modeling elements and introduces some stereotypes to customize them. Therefore, in this report, Rational Rose Enterprise Edition 2004 is the tool to model BPEL with UML. 7

9 2.2 UML profile and UML customization A UML profile is both a subset and extension of UML. It allows UML to be customized for modeling in a particular context. For example, there are Profiles defined for CORBA and Data Modeling. The ability to extend or customize UML is essential to model-driven architecture (MDA). UML can be customized to support the modeling of systems that will be completely or partially deployed to a Web services infrastructure. Customization is achieved by defining the following items: [1] The subset of model elements to be used in the profile Stereotypes, tagged values and constraints to be used with specific model elements The scope of this chapter is mainly focus on stereotypes. Stereotypes are a way of categorizing elements of a model. For instance, assume there is a class in an order system which represents Product. Because the Product class is a domain class a stereotype of <<entity>> could be attached to indicate that it represents a domain data object (perhaps an Entity Bean or a JDO persistent object and so on). This stereotype can be used to help the readability of the model for a human, and can even be used to change the icon representing the class in a CASE tool such as Rational Rose (See Figure 2.1). In this case, moreover it can be used to guide the behavior of a model translator. Figure 2.1 Class Diagram with <<Entity>> Stereotype in Rational Rose 2003 The UML profile for automated business processes described in this report is a profile of UML

10 2.3 Model BPEL with UML Profile We discussed the reason why using UML to model BPEL and how to customize UML, later on, this section will focus on how to model BPEL with UML profile for Automated Business Processes Defining a Business Process This section introduces BPEL overview Modeling using UML activity diagram and process defining using UML class diagram through an example. The example (PayFlow example ) used here is taken from Collaxa website. It is available at Figure 2.2 PayFlow Example I use this example here because: 1. What makes this application interesting is that the partner services (payment processor) are asynchronous. Which means that it might take anywhere between several minutes to several days before the partner service calls back the business flow with the result data. 9

11 2. Managing timeouts and handling the various types of exceptions that can be thrown by the payment processor are important aspects of developing reliable business flows. Figure 2.3 Model PayFlow process overview using UML activity diagram Figure 2.3 represents the PayFlow process overview modeled using UML activity diagram. In this diagram, the two swimlanes indicate the process has two ports, which are PayFlowRequester and PaymentServiceProvider. The stereotypes on the activities, <<invoke>>, <<assign>>, <<eventhandler>> 1 and so on, represent the activities in BPEL. The names of activities which are with <<reply>>, <<invoke>> and <<receive>> stereotypes indicate the corresponding operation names defined in WSDL. BPEL processes are stateful and have instances, in BPEL this PayFlow scenario is implemented as a PayFlow process which would have an instance for each actual payment request being processed. And each instance has its own state which is stored in BPEL variables. In the UML profile, a process is represented as a class with <<Process>> stereotype. And the state of the process is represented as attributes of this class. The UML class diagram defining the PayFlow process is showing in Figure This stereotype is created by myself. There is no available notation mapping BPEL event handler in current version of UML profile for BPEL. 10

12 Figure 2.4 Defining a Process with UML class diagram With the class and activity diagram, the structure and workflow sequence of the PayFlow process are represented very clearly. However, the two diagrams are only two of the diagrams required to model this process completely. Detail is elaborated using further diagrams supported by the profile, such as exception handling, activity modeling, data types and interface modeling. All these more detailed modeling will be introduced in following sections of this chapter Data Types and Interfaces Modeling In last section, the process is defined with a class. The attributes types in PayFlowProcess class are message types. A message could have a number of parts; each part has a specified data type. Data types are represented by classes with the <<data>> stereotype; message types are represented by classes stereotyped as <<messagecontent>>. Figure 2.5 shows the model of relationship between data types and message types. The profile does not require message types to be introduced if the messages have only a single part, in this case, a data type can be used directly. Because in this example, no message has more than one part, the data types in the classes diagram are all part types. Figure 2.5 Message types and part types 11

13 The data types are represented in the profile by UML classes. Figure 2.6 shows the model of data types in PayFlow process. In the diagram, the stereotype <<external>> is used to indicate that the elements in the PaymentDataTypes package are defined outside of the current model and consequently should not be mapped to platform-specific (such as BPEL) artifacts. A new package, Payment, is introduced. This has an import dependency on PaymentDataTypes so that the existing types in that package can be reused. Figure 2.6 Message classes for use in the Payment Process In the WSDL file of a BPEL, a number of port types are defined. A port type defines a set of related operations. In this UML profile, port types are represented by interfaces. Figure 2.7 shows the UML notation for modeling a port type. Figure 2.7 Notation for interfaces Figure 2.8 shows the port types the PayFlow process supported, and figure 2.9 presents the port types supported by PaymentProcessorService. 12

14 Figure 2.8 Port Types in WSDL of Payment Process Figure 2.9 Port types supported by PaymentProcessorService The two port types described in figure 2.8 can be modeled with the following two UML interfaces (Figure 2.10). Figure 2.10 Interfaces supported by payment process And the UML interfaces of port types supported by PaymentProcessService are shown in Figure

15 Figure 2.11 Interfaces supported by PaymentProcessorService Protocol Modeling The relation between a business process and partner can need messages to flow in either or both directions. A protocol links together two complementary roles and specifies the interfaces that are provided or needed by each role. [1] A process can have a number of ports, with each port corresponding to a role in a protocol. The role determines the interfaces that are required and provided through that port. A protocol is modeled as a package stereotyped as <<protocol>>. A protocol includes a pair of classes with stereotype <<role>>, the name of this package is the name of the protocol. Figure 2.12 shows the UML diagram. Figure 2.12 Protocol notation 14

16 In the Payment process scenario, there are two protocols. One is between the process and client; the role of process in this protocol is PayFlowProvider, however, client s role is PayFlowRequester. The other protocol is between the process and the PaymentProcessorService; in this protocol, the process plays the role of PaymentProcessorServiceRequester, the PaymentProcessorService plays the provider. All these relationships between roles and protocol are described in BPEL <partnerlinks> (Figure2.13) Figure 2.13 partnerlinks of Payment process Figure 2.14 shows the model of protocol in this scenario. 15

17 Figure 2.14 protocols and roles of Payment process Process Modeling with state, port and protocol Last four sections present how to define a business process with class diagram; model message types with package and class diagrams; model port types with UML interfaces and how to model protocol with class diagram. Now it is the time to combine them together. A process is modeled as a class stereotyped as <<process>>. The attributes of the class correspond to the state of the process. Each port is represented by an association, stereotyped <<port>>, to the role offered by that port. [1] Figure 2.15 shows the notation for process modeling. 16

18 Figure 2.15 Notation for process modeling Figure 2.15 shows a process named Process1 which maintains its state in attribute1 and attribute2. Process1 has two ports, port1 and port2, indicating that the process participates in ProtocolX (in Role1) and ProtocolY (in Role2). In this way, our Payment process example could be modeled as Figure Figure 2.16 Payment Process 17

19 2.3.5 Basic Activity Modeling In section 2.3.1, an activity diagram (figure 2.3) depicted the behaviors of payment process generally. Nevertheless, the data handling, event handling and exception handling were not described in that diagram. In this section, the modeling of data handling and event handling will be introduced in order to model a process activity completely. A process is able to manipulate and update the state through an expression language. BPEL uses XPATH as the default scripting language and provides conventions for accessing variable data and BPEL -provided utility functions from XPATH expressions. [1] This version of the profile supports XPATH as the default language for expressions and provides conventions for accessing attributes. This provides a straightforward mapping to BPEL. Each activity has a descriptive name and an entry action detailing the work performed by the activity. Typically the actions would be hidden in the activity diagram, such as figure 2.3. In fact, the entry action is represented by XPATH expression. Figure 2.17 shows two invoke activities. Figure 2.17 Invoke notation In this figure, Activity1 is a one-way activity (it does not specify an attribute for a result) which invokes operation1 through port1 with attr1 as the input message. Activity1 completes as soon as the operation invocation request has been sent and does not wait for a reply. However, activity2 is a two-way invoke which invokes operation2 through port2 with attr2 as the input message and waits for a synchronous reply which it places in attr3. Figure 2.18 is an expanded <<invoke>> activity in Payment process and the corresponding BPEL code. 18

20 Figure 2.18 expanded invoke activity of Payment process Figure 2.19 Expanded assign activity of Payment process The <<assign>> activity is in charge of the variables assignment. XPATH still is used in the assignment in order to locate the variables. Figure 2.19 depicts an expanded <<assign>> activity in Payment process and the BPEL code it maps to Event Handling Modeling In the Payment process scenario, the process invokes the paymentprocessorservice asynchronously. When the processorservice gets the result data after executing a set of business logical calculations, the processorservice invokes the callback operation of the process, triggers the event handler. Depends on different return value from the processorservice, one specific activity will be executed by the process. In BPEL, the event handler could be implemented by <pick>. The following codes indicate the event handler in Payment process. <pick> <onmessage partnerlink="paymentprocessorservice" porttype="services:paymentprocessorservicecallback" 19

21 operation="onresult" variable="response"> <!-- copy the response value of Payment Processor to the digitalreceipt variable--> <assign> <copy> <from variable="response" part="payload" query="/digitalreceipt"/> <to variable="digitalreceipt" part="payload" query="/digitalreceipt"/> </copy> </assign> </onmessage> <onmessage partnerlink="paymentprocessorservice" porttype="services:paymentprocessorservicecallback" operation="ontransferrefusedexception" variable="transferrefusedfailure"> <!-- This situation happens when the partner throws a fault notifying us that the initiated request was refused --> <terminate/> </onmessage> <onmessage partnerlink="paymentprocessorservice" porttype="services:paymentprocessorservicecallback" operation="oninsufficientfundexception" variable="insufficientfundfailure"> <!-- This situation happens when the partner throws a fault notifying us that the initiat request was invalid because the included SSN is invalid. --> <!-- terminate the flow --> <terminate/> </onmessage> <onalarm for="p2d"> <!-- 2-day timeout --> <!-- This situation happens when the receive call times out. It means that the partner did not get back to us with the expected 2 days. --> <!-- terminate the flow --> <terminate/> </onalarm> </pick> List 2.1 Payment process event handling 20

22 The BPEL server create a <<receive>> activity once an asynchronous callback is received from the payment processor and the <onmessage> event is triggered; otherwise the <<wait>> activity will be created if <onalarm> event is triggered. A UML decision node and a set of activities can represent this event handling scenario. Figure 2.20 depicts how a BPEL event handling is modeled with UML profile. Figure 2.20 The Model of BPEL event handling In this way, to the event handling of Payment process, the code in list 2.1 can be modeled as figure 2.21 shows. Figure 2.21 Payment process event handling 21

23 2.3.7 Exception Handling Modeling Once an exception occurred during the execution of process activities, the normal execution within the containing scope will be terminated. An exception can be caught within the containing scope so that error recovery behavior can be performed. Normally, the exception handler in BPEL is represented as list 2.2. <faulthandlers> <catch> </catch> <RecoverActivities/> </faulthandlers> List 2.2 Exception handler in BPEL To model the exception handler, an UML activity stereotyped as <<catch>> in containing <<scope>> can be used for representing the <catch> activity in BPEL. Outgoing control links from a catch activity indicate the behavior to be performed on catching the exception. The recovery behavior can be nested with in the catch activity if using hierarchical nesting to indicate control flow. Figure 2.22 shows how to model an exception handler in general. Figure 2.22 notation for exception handler modeling In this figure, there are two exception handlers in one scope. One is acitivity1, which 22

24 only catch exception1. The activity2 will be performed once the exception1 on catching. The other exception handler is activity3, which can catch all exceptions in the scope. The activity4 nested in this handler is the recovery activity. In the Payment process, the exception handler is represented in BPEL as list 2.3. <scope name="executepayment" variableaccessserializable="no"> <faulthandlers> <catchall> <!-- terminate the flow --> <terminate/> </catchall> </faulthandlers> </scope> List 2.3 Exception handler in Payment process As shown in the codes above, the exception handler catches all exceptions in ExecutePayment scope. Once exception occurs, the process execution will be terminated. Figure 2.23 depicts the model of exception handler in Payment process. Figure 2.23 Exception Handling in Payment process Complete Payment Process Behavior Modeling Even though the figure 2.3 in section showed the behavior overview of Payment process, it is not detailed enough. Now, it is the time to add some detailed activities such as event handling, exception handling and specific actions into the activity diagram so that the Payment process behaviors can be completely modeled. Figure 2.24 shows a more specific activity diagram of Payment process. 23

25 Figure 2.24 Payment process payment process modeling 24

26 2.4 UML to BPEL transformation Section 2.3 presents how to model BPEL using UML profile through a Payment process example. The model not only makes the process workflow structure very clear but also presents the relationship between the process and partners, message flows, message types and specific actions of each activity. Another benefit of BPEL modeling is that the BPEL codes can be generated automatically from the model which is also the essential of the Model Driven Architecture. This section will devote to introduce how to convert UML model into BPEL document Prerequisites In order to convert a UML model into BPEL there are three prerequisites which are UML modeling tool, a IDE java development environment and ETTK. Later on, the three requirements will be introduced in detail. UML Modeling Tool Choosing appropriate modeling tool issue has been discussed in section 2.1, in order to model a BPEL process, the modeling tool should be able to introduce new stereotypes freely to extend UML. Besides that, the modeling tool should have the ability to export the UML model to a XMI (XML Metadata Interchange). Both Rational rose and XDE are suitable to be used to model BPEL and export the models as a XMI. However, if use Rational Rose as the modeling tool, a XMI plug-in for Rational Rose must be installed. Other wise it cannot export XMI. In this project, Rational Rose Enterprise 2003 is chosen as the modeling tool. IDE java development environment There are a lot of IDE available for java programming. But only Eclipse (with plug-ins) and WSAD (WebShpere Application Developer) can import XMI and translate it into BPEL. In this project, I used Eclipse 2.1 as the java IDE. To make Eclipse generate BPEL automatically via XMI, 3 plug-ins and features are required. 1 Eclipse Modeling Framework, available at 2 XML schema infoset model, available at 3 UML2BPEL plug-in, can be found in ETTK. ETTK (Emerging Technologies Toolkit) The ETTK is a software development kit for designing, developing, and executing emerging autonomic and grid-related technologies and Web services. The ETTK 25

27 provides an environment in which to run emerging technology examples that showcase recently announced specifications and prototypes from IBM's emerging technology development and research teams. In addition, it provides introductory material to help developers easily get started with development of autonomic technologies, Web services, and grids The Procedure of converting Figure 2.25 Procedure of from UML to BPEL Figure 2.25 shows the procedure of converting UML model into BPEL. In the figure, indicates the first step, modeling the process and export XMI using the modeling tool, which is Rational Rose in this project. Figure 2.26 depicts how to export a well-modeled BPEL in XMI using Rational Rose with XMI plug-in installed. Figure 2.26 Export XMI from Rational Rose 26

28 The and in figure 2.25 are the second and third step, importing the XMI into a java IDE, in this case is Eclipse and generate BPEL. First create a java project in Eclipse, then import the XMI file which is exported by Rational rose, in the pop menu of right click there is Generate BPEL from UML, click this item, the corresponding WSDL, XSD, BPEL can be generated automatically based on the XMI file. Figure 2.27 shows the screenshot of Eclipse. Figure 2.27 Generate BPEL from XMI 2.5 Summary This chapter introduces how to model BPEL using UML profile through modeling a typical example process and how to generate BPEL from the UML model. 27

29 Modeling Tool The UML is customized for modeling BPEL by introducing new stereotypes. Rational Rose / XDE is the best choice for modeling BPEL because it not only supports new stereotypes very well but also can export the UML model to XMI conveniently. Other modeling tools such as Together, also support XMI exporting, but cannot support stereotypes very well, for example, Together cannot set a stereotype on an activity in an activity diagram, and this is required for BPEL modeling. How to Model? Generally, a BPEL contains two parts, one is concerning the process definition and structures, such as process definition, variable declaration, partner links, message types, port types definition and so on. The other part is related to the process behaviors such as invoke, receive, reply activities, error handling, event handling and so on. The first part can be modeled using UML class diagram, the most important class in the class diagram is the class stereotyped as <<process>>. This class is the definition of the process, however, the second part can be modeled using UML activity diagram, in fact the activities of the process definition class. XPATH expression is used to represent the actions in each activity. Table 1 lists the overview mapping between UML profile construct and BPEL UML Profile Construct <<process>> class Activity diagram on a <<process>> class <<process>> class attributes Hierarchical structure and control flow Swimlanes in Activity diagram <<receive>>, <<reply>>, <<invoke>> activities <<pick>> decision node <<catch>> activities <<messagecontent>> and <<data>> class <<interface>> class BPEL4WS Concept BPEL process definition BPEL activity hierarchy BPEL variables BPEL sequence and flow activities BPEL partners BPEL activities BPEL event handler BPEL exception handler WSDL message type and its parts WSDL port types Table 1 UML BPEL mapping overview UML To BPEL Transformation Generating executable system from a model automatically is the essential of Model Driven Architecture (MDA). One benefit of BPEL modeling is to generate BPEL code automatically. In the procedure of converting from UML to BPEL, XMI is the core. 28

30 First UML can be exported as XMI by the modeling tool. Then some Java IDE such as Eclipse or WSAD can import the XMI and generate BPEL automatically. Besides the modeling tool and the java IDE another toolkit is necessary in order to convert UML model to BPEL. This tool is Emerging Technologies Toolkit (ETTK). In this report, two BPEL modeling approaches are introduced. So far the UML modeling approach has been presented, the other one, which is modeling BPEL using Collaxa Designer, will be introduced in next chapter. 29

31 3 Modeling BPEL with Collaxa Designer One of this project s objectives is to investigate how to model BPEL using Collaxa BPEL Designer. This chapter will focus on this issue. The Payment process example will be used in this chapter also. 3.1 Collaxa BPEL Designer introduction Collaxa BPEL Designer is an Eclipse project providing a complete graphical design environment for BPEL processes and a modeling, editing, validation and testing environment for building processes conforming to the OASIS WS-BPEL 1.1 specification. Figure 3.1 Collaxa BPEL Designer 30

32 In Collaxa BPEL Designer, the BPEL source code is synchronous with the BPEL model. Thus, to generate BPEL code from model using Collaxa BPEL designer is convenient. After modeling a BPEL, the corresponding code has also been generated. If using Collaxa BPEL server as the BPEL engine, building and deploying a BPEL process from the BPEL Designer are rather easy. Next section will introduce how to model BPEL using this tool in detail by modeling the payment process example, which was used in chapter Model BPEL using Collaxa BPEL Designer To model BPEL process using Collaxa BPEL Designer, firstly, a Collaxa BPEL project must be created. During creating the project, the process name and namespace must be given. The dialog is shown in Figure 3.2. Figure 3.2 New Collaxa BPEL project creating dialog Since the Payment process is an asynchronous process, the Async BPEL Process template is chosen. After clicking the finish button to create a new BPEL project, four files are created, which are Payment.pbel, Payment.wsdl, build.xml and bpel.xml. The.bpel and.wsdl are the BPEL source for the process and the WSDL interface for this process. The bpel.xml is the deployment descriptor for the process, which defines the locations of the WSDLs for services called by this flow, along with other project-specific parameters. The build.xml is Apache Ant build script for building and deploying this process. Besides the 31

33 four files, a new asynchronous process skeleton will be generated simultaneously, just like Figure 3.3 shown. Our modeling will work on this skeleton. Figure 3.3 Asynchronous process skeleton Figure 3.4 BPEL Palette in Collaxa BPEL Designer To model the Payment process, some BPEL constructs should be added into this skeleton, just like <scope> <sequence> <pick> and so on. Collaxa designer provides a BPEL palette, which includes most of BPEL constructs. To add them in the current model, what the one shall do is just dragging them into the model. Figure 3.4 depicts the BPEL palette. After inserting a certain element into the model, there is a BPEL Inspector, which allows user to edit the properties of selected BPEL construct. Figure 3.5 shows the <scope> element and its properties of Payment process. 32

34 Figure 3.5 Properties of <scope> element Using Collaxa Designer to model BPEL is much easier than UML modeling approach because its level of detail that can be modeled is higher than that of UML modeling. The property window sets some detailed information of a process, such as message types, port types and ports. To finish BPEL modeling, one can just add the certain BPEL constructs into the right positions in the process model against the process definition, and then set the properties of the BPEL constructs. In this way, the Payment process can be modeled as Figure 3.6. Figure 3.7 is the overview model of Payment process, which contains the partners of the process and the process variables used to keep the process state. 33

35 Figure 3.6 Payment process model in Collaxa BPEL Designer 34

36 Figure 3.7 Payment process overview in Collaxa BPEL Designer 3.3 Summary This chapter introduced how to model a BPEL process using Collaxa BPEL Designer which is an Eclipse project. From some point of view, this tool is a BPEL visual editor. Even though the process structure and the process overview can be represented in the model, the main purpose of Collaxa Designer is to generate BPEL and WSDL code conveniently and visually. Also, if using Collaxa BPEL server as BPEL engine, building and deploying BPEL from Collaxa BPEL Designer is very convenient. To model BPEL using Collaxa BPEL Designer, first of all, a BPEL project must be created. During the project generating, a BPEL skeleton model will be created. To finish the modeling, BPEL constructs can be dragged from the BPEL palette to the skeleton, and the properties of the BPEL constructs can be set in BPEL Inspector. 35

37 The BPEL code and model are synchronized in Collaxa BPEL Designer. Therefore, the corresponding BPEL code has been generated automatically after finishing the modeling. In Collaxa BPEL Designer, the relationship between BPEL and BPEL model is bi-directional, which means the BPEL code can be generated from the model, also the model can be created automatically for existing BPEL and WSDL files without any third party tools. So far, two BPEL modeling approaches have been introduced. The goal of this project is not only to investigate how to model BPEL using two modeling approaches, but also to analyze and compare them, which is also a significant point. Next chapter will analyze their differences and similarities from various views. 36

38 4 Validating a process execution with model One of the objectives of this project is to investigate whether it is helpful to use a BPEL model to validate a process execution. BPEL code can be generated from BPEL model automatically. It doesn t make sense if using a model to validate an execution of BPEL process which is generated from it. The process must be executed against the model definition if the BPEL is derived from the model. The model will never find any exceptions in the process execution. However if use a model to validate an existing BPEL, it is helpful. Assume there is a BPEL process running on some BPEL server. To validate this process execution, we could model this process and then using the model to validate. Now a question, How to validate a BPEL process execution using a model?, is introduced In fact this is a big issue. Since this project focuses on BPEL Modeling investigation, I just generally analyze this issue here. A BPEL model, for example UML model, is a set of notations. It is really hard to validate a process execution. Anyway, the notations must be converted into other form to validate a process. For process validation, Mr. Doron Sherman, who is a Web Services Orchestration expert from Collaxa ever talked about that on He said A BPEL orchestration server, as the name suggests, is responsible for executing BPEL process flows and managing the deployed process instances. Orchestration is associated with private processes while Choreography stands for abstract processes, The latter describes the behavior or contract, such as message sequencing expected from the interacting services. BPEL abstract processes are not executable, but they can indirectly impose behavior compliance upon private processes executing by the BPEL orchestration server. Knowledge of BPEL abstract processes can help the BPEL orchestration server validate and assure public protocol conformance of executing processes. * * His talk is available at 37

39 From his talk, abstract process is available for validating a process execution. Because BPEL model can be converted into BPEL code, it might be possibly converted into abstract BPEL process. If this assumption is accepted as true, a model can validate a process execution. This issue could be a future work of this project. 38

40 5 Conclusion After introducing BPEL UML modeling approach and Collaxa BPEL Designer, this chapter will analyze and compare two modeling approaches in various points of views, also identify the advantages and disadvantages of the two modeling approaches. 5.1 Comparison Similarities Since both UML modeling and Collaxa BPEL Designer can model BPEL, there must be some similarities between them. This section will analyze the similarities from two views, which are general ways of modeling and BPEL code automatic generation. General way of modeling Even though two BPEL modeling approaches use different notations to model BPEL, their modeling way is similar. Both approaches model BPEL in two parts, one is process structure and process definition, the other part is process behaviors. UML profile for BPEL models process overview and process structure using UML class diagram and package diagram. The process definition, ports, partner link types, port types and message types as well as the relationship among them can be represented in the model. Collaxa BPEL Designer will generate a process overview model after creating a BPEL project. The process overview model contains the information about partners, partner link types, and variables that are used for keeping process state. Since process can be defined as UML class in UML profile for BPEL, the process behaviors can be modeled as activity diagram of this class. Activity diagram can model most of process behaviors such as event handling, error handling, looping, invoking and so on. Collaxa BPEL Designer provides a process map to represent the process behaviors. BPEL code automatic generation To generate BPEL code automatically from the model is one of the purposes of modeling BPEL. Both UML modeling approach and Collaxa BPEL Designer support 39

41 converting BPEL model into BPEL code automatically. However their procedures of converting model into BPEL code using different modeling approaches are not same. Next section will elaborate this point in detail Differences This section will introduce the differences between modeling BPEL using UML and Collaxa BPEL Designer from different views. Model export For UML modeling, different modeling tools could export different UML model. For example, Rational Rose can export UML models as *.mdl files. In order to break the wall between the incompatible tools, XMI is introduced. And Rational Rose/XDE, which is the tool available to model BPEL, supports the XMI also. That means except its own model format, Rational Rose/XDE can export a unified format. However, the main purpose of Collaxa BPEL Designer is to generate BPEL code visually and easily. Even if it can model BPEL, the final destination is the BPEL code. The model cannot be exported from Collaxa BPEL Designer. After modeling a process using Collaxa BPEL Designer, what we can get are the BPEL and WSDL files but not the model. The model in Collaxa Designer is a kind of media to edit BPEL code. The level of detail that can be modeled UML profile for BPEL can model more detailed level than Collaxa BPEL Designer. In UML modeling, process port types, operations in each port types, partner link types, message types, even parts in messages can be modeled in class diagram. In activity diagram, process activities can be modeled as activities with certain stereotype; the particular operation of process activity is represented as action of corresponding activity using XPATH expression. However, Collaxa BPEL Designer cannot model so detailed level. Detailed information about a process such as message types, port types and particular operation of process activity is allowed to be edited in BPEL Inspector instead of being represented in the model to edit code visually and easily. For instance, figure 5.1 is an activity UML model and figure 5.2 is Collaxa BPEL model 40

42 for the same activity. As shown in figure 5.1, in this UML activity, besides invoke activity name, operation and parameter are modeled. The partner link and port type are modeled in the class diagram (not in this figure). Nevertheless Collaxa model in figure 5.2 only contains the information of invoke activity name. Other detailed information about this invoke activity is listed in BPEL Inspector. Figure 5.3 shows the detail behind this invoke model. Figure 5.1 Invoke activity model in UML Figure 5.2 Invoke activity model in Collaxa BPEL Designer Figure 5.3 Detailed information about Invoke activity Abstract process modeling In BPEL specification 1.1, Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. [3] The executable business processes can be modeled using either UML profile or Collaxa BPEL Designer. However, not both of modeling approaches can model abstract processes. 41

43 Draft UML 1.4 Profile for Automated Business Processes with a mapping to BPEL 1.0 declared The current version of this profile is concerned with the modeling of executable business processes. [1], which means current version of UML profile doesn t support abstract processes modeling. Nevertheless, Collaxa BPEL Designer can model abstract processes, and abstract related properties are also defined in BPEL Inspector. Figure 5.4 shows the abstract option of Payment process. Figure 5.4 abstract process in Collaxa BPEL Designer The procedure of generating BPEL code Both UML BPEL model and Collaxa BPEL model can be converted into BPEL code automatically. But the transformation procedures of the two modeling approaches are different. In order to convert UML model into BPEL code, ETTK and a supported Java IDE such as Eclipse and WSAD are necessary to be installed. UML first must be converted into XMI, and then the XMI can be imported into the Java IDE, in order to generate the BPEL code automatically. However, Collaxa BPEL Designer integrates the BPEL code editor and model designer. The model and the code are synchronized. So, to covert 42

44 model to BPEL code using Collaxa Designer doesn t need any other tools. Figure 5.5 shows two tabs to switch synchronized model and code. Figure 5.5 Synchronized BPEL model and code in Collaxa BPEL Designer BPEL model automatic generation Because Collaxa BPEL mode and source code are synchronized, Collaxa BPEL Designer can automatically generate a BPEL model for existing BPEL file. But, so far there is no any solution supporting automatically generating UML model for existing BPEL. 5.2 Conclusion This section analyzes the advantages and disadvantages of these two BPEL modeling approaches Advantages and Disadvantages of UML modeling approach Advantages UML is well-known modeling language. UML is an OMG standard which provides a visual modeling notation valuable for designing and understanding complex systems. It is the most widely known object-oriented modeling notation. UML is widely used in the development of object-oriented software and has also been used, with customizations, for component-based software, business process modeling, and systems design. 43

45 XMI export supported In this project, Rational Rose 2003 is used as the modeling tool. Rational XDE is another choice. In fact, currently these two are the only choices to model BPEL with UML even though there are a number of case tools. As BPEL becoming standard, there must be more and more modeling tools that can be used for modeling BPEL. So breaking the border of different modeling tools is very important. XMI is another OMG standard. The main purpose of XMI is to enable easy interchange of metadata between modeling tools (based on the OMG UML) and metadata repositories (OMG MOF based) in distributed heterogeneous environments. XMI provides a standard way to exchange information about metadata between modeling tools based on the UML The level of detail that can be modeled is rather low The UML model contains process definition, ports, port types, partner link types, message types and so on. Because the level of detail that can be modeled is rather low, the UML model not only can be converted into BPEL code itself automatically, but also the process WSDL and XSD can be generated together with the BPEL code automatically Model can be converted into BPEL code automatically This makes the BPEL development easier and more precise. In order to generate BPEL code from UML model, the UML model must be converted into XMI. Disadvantages Knowledge about UML is needed Only one master BPEL technology is not enough to people who want to model BPEL using UML. The knowledge about UML modeling methodology is also necessary. Cannot be used to model abstract process Current version of UML profile for BPEL doesn t support abstract processes modeling. Maybe later version will support that. 44

46 5.2.2 Advantages and Disadvantages of Collaxa BPEL Designer Advantages Model and BPEL code are synchronized Collaxa BPEL Designer synchronizes model and BPEL code to make code automatic generation more convenient. It also supports model automatic generation from existing BPEL file. Convenient deploying generated BPEL (Collaxa BPEL server) If the BPEL server is Collaxa BPEL server, it is very easy to deploy BPEL from Collaxa BPEL Designer. To deploy the well-modeled BPEL, one just needs to click one button. To model a process, one doesn t need to know any other model knowledge than BPEL itself To model a process using Collaxa BPEL Designer, one only needs to have the knowledge about BPEL itself. Any other modeling language knowledge is not necessary. Abstract processes modeling supported Collaxa BPEL Designer can model abstract process. Also abstract process code can be generated automatically from corresponding model. Disadvantages Cannot export model individually Since Collaxa BPEL Designer is a BPEL visual editor, the main purpose of this tool is BPEL code generation. The model cannot be saved or exported, which means, Collaxa BPEL model cannot be imported into other modeling tools The level of detail that can be modeled is high 45

47 Collaxa BPEL Designer can only model basic BPEL constructs such as <invoke> activity, <assign> activity, <reply> activity and so on, the more detailed information is listed in the BPEL Inspector, just like port types, operations, partner link types, message types, and so on. The specific information about a process cannot be retrieved from the model Summary This section analyzed the advantages and disadvantages of the two modeling approaches. The following conclusion can be drawn from the analyses. Model BPEL using UML This approach focuses on pure modeling; the model can represent very detailed process information. The UML model can be converted into XMI to make different modeling tool importing and editing same model possible. The BPEL code can be generated automatically from the model, but the third part tools (ETTK, Java IDE) are needed. Current version of UML profile for BPEL doesn t support abstract processes modeling. Collaxa BPEL Designer Collaxa BPEL Designer focuses on BPEL code generation. The Collaxa visual model cannot represent the detailed information of a process, however, model and BPEL code are synchronized in Collaxa BPEL Designer, so that the converting from code to model and model to code is rather convenient. If using Collaxa BPEL server as the BPEL server, deploying BPEL is very easy from Collaxa BPEL Designer. The well-designed BPEL will be deployed on the Collaxa BPEL server through one click on the deploy button from Collaxa BPEL Designer. Therefore, if the modeling purpose is to develop BPEL code, especially when the BPEL platform is Collaxa BPEL server; Collaxa BPEL Designer is the best choice for modeling and code editing. 46