An Analysis Tool for Execution of BPEL Services

Transcription

1 An Analysis Tool for Execution of BPEL Services Ariane Gravel 1 Xiang Fu 2 Jianwen Su 1 1 Department of Computer Science, UC Santa Barbara, {agravel, su}@cs.ucsb.edu 2 CIS School, Georgia Southwestern State University, xfu@canes.gsw.edu Abstract Business Process Execution Language (BPEL) is an XML-based language for specifying services. There have been numerous recent research and development efforts in both statically analyzing service specifications and support for services execution. In spite of these work, there is still an urgent need for quality assurance for BPEL services in the following two aspects. First, there is a lack of tools and techniques to aid understanding BPEL service specifications and execution in order to make informed decisions about the correctness of its observed functionality. Second, we need maneuverability in exploring a service execution to identify the source of an erroneous service. In this paper, we develop an Execution Analysis tool for BPEL (EA4B) that can be used to address both aspects of this problem. EA4B defines an execution log design that formats what and how information should be written to file by a BPEL execution engine. EA4B can then establish an indirect link to the execution engine through the execution log, which can be read only once for post-execution debugging or frequently for near real-time monitoring. Moreover, EA4B provides an interactive graphical user interface for modeling BPEL code and simulating a walkthrough of its execution. Together, the execution log and user interface address the need for information gathering and representation. In addition, EA4B can be integrated with static analysis tools such as Web Service Analysis Tool (WSAT). Error traces generated by WSAT can be translated to log files accepted by EA4B and visually displayed by EA4B. Overall, EA4B provides an execution analysis tool simple enough to ease the understanding of a service process to the novice user, but powerful enough to aid the advanced users in their developing and debugging tasks. 1. Introduction Recent efforts in the research and development of (e-) services have been focusing on the architectures and interfaces. While it is unclear how much design automation can be achieved, significant work still needs to be done in developing services as software. It has been argued that software development in services is different from traditional software systems [2], debugging tools and techniques are still very applicable and useful in developing services. This paper aims at developing a monitoring and debugging tool for services specified in BPEL. Business Process Execution Language (BPEL) [3] is an XML-based language that defines the business process of a service. BPEL builds on top of WSDL and can define processes that invoke and interact with other WSDL services or WSDL interfaces of services defined in e.g., BPEL. Due to advantages of BPEL in business applications, it has been attracting attention in both software development (e.g., IBM, Microsoft, BEA, Oracle, etc.) and applications. BPEL can be used both to specify the abstract process logic, or as an implementation of the abstract process. This paper focuses primarily on the latter use of BPEL and investigates techniques to support for the specification and execution of BPEL services. In a world where businesses cannot afford to lose processes of any worth, it is important that every process be successful. Since a service is very much end-to-end oriented, standards such as WSDL and BPEL were introduced to provide an increasing level of specification as to what should happen between the moment when a service is invoked and the moment when it is completed. With the introduction of such standards also comes the need for thorough quality assurance. The quality assurance of a service is a two-fold problem. First, we want to gain information about the process and its execution so that we can make

2 informed decisions about the correctness of its observable functionality. Second, we need maneuverability in exploring a process execution to identify the source of erroneous services directed with BPEL. In this paper, we develop an Execution Analysis tool for BPEL (EA4B). EA4B can be used to address both aspects of this two-fold problem to increase the trustworthiness of the service. EA4B provides a graphical user interface for modeling code and a monitoring tool for modeling its execution, which solves the information issue of our problem. The tool, along with a few additional features of this software, can also help the debugging process when further analysis may be necessary to verify the validity of a result. We also integrate EA4B with a service analysis tool WSAT [6, 7, 8] developed previously. An interesting use of the integrated tool is to use WSAT to find logic errors in a BPEL specification and generate error traces, the error traces are then fed into EA4B (via the an execution log) that can visualize the error trace and aid in discovering the error cause. Other contributions have been made in the BPEL community. Many companies, like Oracle, now provide a drag-and-drop graphical user interface to build code. IBM has also recently added functionality to their WebSphere BPEL execution engine to model business processes. They have also developed an execution log and a visualization tool. However, most significant efforts in this field have been made towards simplifying the constructing and launching of a service, they all lack EA4B s focus on debugging. The remainder of the paper is organized as follows. We discuss in 2 the development process for services and motivates this work. 3 presents a design for logging BPEL execution. 4 gives an overview of the visualization design for BPEL processes. 5 describes the tool EA4B, in particular, the monitoring and debugging functionalities. 6 outlines the integration of EA4B with an analysis tool WSAT. 7 concludes the paper. 2. BPEL Services Development of a service can be done by human in traditional fashion, or by algorithms and other automated tools. The latter has been attracting attention in research community. However, in much of the practical applications service development is still a labor intensive process. In this section, we give a brief summary of the BPEL process model. BPEL extends WSDL as an attempt in filling the gap between a service and a business process. It makes the business integration possible by mimicking how a business process happens in real life. When a business process takes place through human interaction, there is usually a specific order to the process that is either assumed as a social standard or defined upon agreement to the service. It is to mimic this human interaction that BPEL provides constructs to control the flow of the process. Such constructs serve as a constraint on the execution to ensure that it follows a predefined order. In the same way that a vendor would expect payment before a customer leaves with an item, business-oriented services can use BPEL to explicitly define their expectations of the business exchange. BPEL defines the expectations by providing detailed information to which the process must comply, such as variables, partner links, correlation sets, and flow alternating activities. The execution order defined in a BPEL process contains complex activities and atomic activities. Complex activities describe the structure of the execution. The most frequently seen complex activities are SEQUENCE, WHILE, FLOW, PICK, and SWITCH. SEQUENCE describes multiple sub-activities that are to be executed sequentially. WHILE only contains one sub-activity, though it may be a complex activity. A condition is tested and the WHILE subactivity will be executed until the condition is evaluated to false. FLOW describes multiple subactivities that are to be executed concurrently. A PICK activity will wait for a specific message or alarm to execute its sub-activities appropriately. Finally, a SWITCH contains one or more case activities, followed by a single otherwise activity. <switch> <case condition= "bpws:getvariabledata('arraymode')=0"> <reply name="returntheintegerarray" operation="makeintegerarray" partnerlink="arraycreationplt" porttype="ns2:arraycreation" variable="integerarrayresponse" /> </case> <case condition= "bpws:getvariabledata('arraymode')=1"> <reply name="returntheintarray" operation="makeintarray" partnerlink="arraycreationplt" porttype="ns2:arraycreation" variable="intarrayresponse"/> </case> <otherwise> <reply name="returnthestringarray" operation="makestringarray" partnerlink="arraycreationplt" porttype="ns2:arraycreation" variable="stringarrayresponse"/> </otherwise> </switch> Figure 1: A BPEL Specification makearrayfromstring.bpel [1] Atomic activities are many and usually simple in concept. For example, valid BPEL code could contain a RECEIVE to receive a message, a REPLY to send back

3 a message, an ASSIGN to assign a value to a variable defined at the top of the BPEL file. Figure 1 shows an example of a complex activity containing an atomic activity. 3. Execution Log for BPEL Services Upon execution, data must be gathered and stored by the execution engine in order to allow for any sort of later monitoring. EA4B relies on the engine to output all information about the process execution in a predefined design. This design must therefore allow for complex information to be presented in a precise way such that EA4B can revisit every step of the execution in the order in which they were executed without leaving any possible room for loose interpretation. With this in mind, a log structure was designed to include thorough information during execution. The execution log file consists of a single <log> element. This log element may contain logging information for one or more BPEL execution processes. The log element presents the execution information in the form of log records with <logrecord> elements. In the remainder of this section, we describe key concepts in the log structure. 3.1 Log records A log record contains information about a single action taken by the engine. Such actions can be in response to a start or end of a process, a successful completion of a BPEL activity, an error, or an unexpected event within the engine. The type of information the log record contains will vary according to the nature of the action. Every process will be introduced with a log record containing a <begin> element and concluded with a log record containing an <end> element. The begin log record will always be the first log record of an executing BPEL process, and should include information about the BPEL file location, service end point, and end time. The end log record will also contain the time at the end of the process. This time information will be useful for the user to monitor the overall health of the execution process. The end log record should be the last log record of a process and will contain again the file location so that the end can be properly matched to the appropriate begin log record. Except for the start and end of process actions, which are special log records, the log records will always contain at least the following data: LSN (Log Sequence Number): The execution engine is responsible for assigning this identification number at execution time. Since the engine may only execute one thing at a time, the LSN will be ordered sequentially in the log, even though neighboring log records may not belong to the same BPEL process. PrevLSN (PREVious Log Sequence Number): To keep track of which log records belong to which processes, the execution engine also keeps track of the LSN of the action s logical predecessor. AID (Activity IDentification number): Since the log record s purpose is to record one action, every log record must identify the activity associated to that action. Unfortunately, BPEL has no effective way of uniquely identify activities. We extend BPEL so that each activity has an extra attribute AID that can uniquely identify activities within the BPEL process. ATYPE (Activity TYPE): This is useful since every type of activity are handled differently and knowing its type defined as an attribute in the execution log record allows the monitoring tool to anticipate the expected information and possibly perform tasks that apply specifically to selected types. 3.2 Activity states Complex and atomic types of activities will go through a series of states, namely started, executing, evaluated, faulted, and ended. The started status indicates that a new activity is beginning execution. Although executing, ended, or faulted imply that an activity must have been started in order to get to any of those three finishing status, the started status records serves as a checkpoint in case the execution log ends abruptly. An execution could end abruptly, for example when a technical problem prevents the execution engine from terminating properly, and therefore we might not see an executing, ended, or faulted that would clue the monitoring tool into knowing that the last activity must have been started before the execution engine failed. For similar reasons, it is also important that the execution engine send an executing status report. The executing status report is used only for atomic activities that delay the process execution (e.g., wait or invoke ). The evaluated status is for complex activities that require condition checking. For example, every time a Case is evaluated, a log record is written to show that the activity was evaluated. The ended and faulted states both indicate the end of an activity. The ended state is used in the case of a successful completion. Consequently, faulted

4 represents that the activity was not completed due to an error. There are four categories of error types: time_out, crash, aborted, and other. Time_out means a service was forced to terminate due to a lack of progress in the execution over elapsed period of time. Crash represents a wrongful termination of a process, and is caused by a runtime, power, software, or hardware failure. Aborted means the service was voluntarily terminated by human interaction, other running applications, or the engine itself. Finally, other represents any other unexpected event not defined in the above cases. 3.3 Errors A faulted status report should always be followed with an <error> element, defined with by an <errortype> and possibly an <errordesc> element. Error types are the four categories in which errors can be classified, namely time_out, crash, aborted, and other. The <errordesc> element provides more information about the error that has occurred. 3.4 Variables A log record may also contain a variable. In the case when the service needs to exchange data, the <variable> element will represent this exchange. The variable element may have a name parameter, and contain <part> elements to allow more complex data to be stored together as one entity. To allow for tracking of these variables, the execution engine should also include the variable's previous value along with the LSN of the action that last modified that variable. 4. Visualization of BPEL Processes In this section, we briefly describe the visualization framework for BPEL processes. The design of the process visualization follows in principle the UML Activity Diagram [4]. The process visualization is used in EA4B to not only allow easy understanding of the functional logic of the process, but also enable the monitoring and debugging functionalities in EA4B. Sections 5 and 6 will discuss in some detail of these functionalities. The graphical representation of BPEL processes in EA4B consists of a set of nodes attached by lines. Each activity is a node, and the flow of the nodes is represented by the 2D structure of the graph and the lines. Time evolves from top to bottom, so two activities, if one is situated on top of the other, will be processed in the order determined by their vertical placement. Consequently, two nodes situated next to each other horizontally should either be executed at the same time, or one of them will be executed. The nature of the parent structural activity that contains them will determine how two nodes at the same level will be handled. The lines represent links connecting the nodes to their successors. In the graph, a node has a successor activity if there is a direct way to go to the successor. This means that a structured activity does not have any links to the activities it contains, but only to the activities that can logically follow it in the timeline of the execution. The nature of the activity will determine how the activity and its sub-activities are drawn. Here the term sub-activities refers to all activities that are child nodes of the activity in question in the XML structure. The design for each activity node and the structure of the graph was mostly influenced by UML Activity Diagram, though UML Activity Diagram is too limited to dictate the whole design in EA4B. UML influence is most noticeable in SWITCH and FLOW activities. EA4B supports abstraction in visualizing BPEL: nodes can collapse and thus hide the information (i.e., included sub-activities). Initially, all nodes are collapsed, which means that there is only one node, the root activity, drawn in the graph. Simple activities, such as reply or receive, cannot be expanded as they do not contain any sub-activities. Simple activities are therefore all represented with a basic rectangular shape. Complex activities, such as SEQUENCE and WHILE, will contain a + sign on the top right corner of the basic rectangular shape when they are collapsed. (a) FLOW (b) SWITCH (c) PICK (d) SEQUENCE (e) WHILE Figure 2: Visualization of BPEL Activities FLOW shape is a thin and wide rectangle because its purpose is to define that its sub-activities are to be executed concurrently. Its sub-activities are drawn horizontally next to each other. SWITCH shape is a

5 rhombus because it clearly defines a decision to be made between two or more sub-activity options. Subactivities to the Switch are one or more Case activities followed by one Otherwise activity. These subactivities are drawn horizontally next to each other. PICK shape is a triangle, meant to look like a half rhombus because it is also an option-based decision activity. SEQUENCE shape is a square. After all, if a wide rectangle represents concurrent activities, than a square, which is nothing more than a narrow rectangle, is a limitation of that. Figure 2 shows the visual forms of the five structured activities in BPEL. When complex activities are expanded, an end shape is added and a boundary region is defined. The end shape defines the end of the reach of an activity. The boundary region is defined by the begin and end shapes of expanded complex activity and encompasses all sub-activities. The goal of this end shape and boundary region is to clearly define the span of an activity. Without them, it would be hard to visualize if activities are sub-activities or just a follower in the flow order. Figure 3 shows a part of the BPEL process makearrayfromstring. Figure 3: A Snapshot of the EA4B Tool 5. Execution Monitoring and Debugging The goal of the EA4B tool is to support for easy understanding and design (execution monitoring and debugging) of BPEL processes. To achieve this, the tool allows visual representation of a BPEL process, controlled animation of execution (from a log file) including step by setting break points and step-by-step execution, and examination of execution states, including variable contents. We briefly describe these functionalities in this section. Once a log is fetched, the monitoring and debugging can start. The monitoring is mainly represented through changes in the colors of each shape in the process visualization. The user can move through the log records one at a time and its effect will be applied to the appropriate part of the graph. If the log record contains information about an activity beginning, the activity s beginning shape and its boundary region will light up (change its color to red). This shows that the activity is active. Upon the next log record, the beginning shape will go to gray to mean that it has been visited and is now over. However, the boundary region will remain red for all sub-activity records until the activity ending record is encountered. The red boundary region shows that the region is hot, i.e. that it is the region where the execution currently points. Once an activity ending record is encountered, the end shape will light up red. Once we move on to the next log record that will define actions about another activity, the end shape and boundary region will change to gray to represent that the activity as a whole entity has been visited and is no longer active in the execution. An activity node can also be light red if it is currently being evaluated. The light red is used to differentiate an activity that is only evaluated against activities that are actually started. Similarly, if an activity is evaluated to false and is thus not started, the visited color will be a dark gray to make this distinction. The user can see that the process is complete when the end shape of the very first activity is gray and therefore has ended. At any time in the execution monitoring, the user can restart the execution monitoring again from the beginning, though the nodes visited on the previous run will still be gray. This can be useful when looking for an error because the user is reminded of the flow taken the first time around. Other tools are available in EA4B for the debugging functionality of the code graph. Such tools are assertions (conditional break points), a table of variables, and a detail panel. Assertions can be added to links in order to provide condition checking during the execution monitoring. This can serve as an alarm for wrongful execution of a specific activity. The variable table shows the current and past values for all variables in the BPEL process. The detail panel simply serves as an area which can contain more information about interface component of interest. We briefly describe the three components below. Assertions. Assertions can be added to any link to define a logical stopping point in the execution visualization. Each assertion (point) will be shown as a red dot on the link (Figure 4). Such a red dot representation is very popular within computer

6 programming to represent a breakpoint, assertion, or any logical stopping point. If the complex activity containing the link with an assertion is collapsed, the basic rectangular shape with a + representing the complex activity will also have a similar red point in the middle of the left side of the rectangle. Note that activities themselves cannot have an assertion point, so if an assertion point is visible on the activity shape, one can deduce that the activity contains a link with an assertion point. JAVA Swing components, and the node graph are created with the Graphics 2D library. While other software is available for drawing tree structure, none of them allowed the kind of structured disposition we wanted to maintain all while offering some visualization flexibility. Therefore, everything in the graph area was designed and implemented from scratch using a combination of basic shapes extended with several features unique to the activity in represented. 6. Integration of EA4B and WSAT Figure 4: Visual Representation of an Assertion Variable table (upper right portion in Figure 3). The variable table contains all variables defined in the input BPEL file. Upon opening the BPEL file, variables are fetched from the file, a table row is added for each variable, and a variable name is added to each of those rows. Columns represent the value, LSN, and AID of the activity that updated the value; these cells will not contain any information until the execution monitoring starts. During execution, rows in the table will be updated to reflect the current status of variables. Detail panel (lower right portion in Figure 3). When the user clicks on an activity node, a link that relates two activity nodes, or a row in the variable table, the detail panel will show details about the objects clicked. The nature of the details shown depends on the object clicked and the information available about that object. For an activity node, the detail panel will show all its attributes defined in the BPEL file. For a link, the detail panel will show its source and destination. For a variable, the detail panel will show its name, type, value, LSN, previous LSN, and AID. Such monitoring mechanism after the process has ended can help discovering vital property of the process and provide informative feedback about the health of the overall process. By analyzing the log file, a developer can save valuable time by knowing which activity or variable has caused the process to crash. In addition, if the log file does not determine exactly what caused the problem, it can at the very least determine the last successful step taken, thus providing the user with good clues about where to look for a problem. The graphical user interface and monitoring tool was implemented in JAVA, using nothing else than standard libraries. The frame components are mainly EA4B can be integrated with static analysis tools such as Web Service Analysis Tool (WSAT) [6, 7, 8]. Error traces generated by WSAT can be translated to EA4B log files and be visually displayed by EA4B. The verification process consists of the following steps: (1) A set of BPEL (and WSDL) specifications are fed to WSAT. (2) WSAT translates the BPEL specifications to Promela programs. (Promela is the specification language of SPIN model checker [5]). (3) Desired system properties, such as a receipt message is not generated until the credit card is charged, are specified using Linear Temporal Logic (LTL) [9]. (4) SPIN model checker is employed to verify the property. (5) If the LTL property is satisfied, the service design is 100% guaranteed to satisfy the desired property; otherwise, a SPIN error trace is generated. (6) Run WSAT on BPEL services and the error trace again, to generate an EA4B log file. EA4B is used to examine the error trace visually. In the above process, Step 6 can greatly reduce the complexity of error trace analysis. Figure 5: WSAT Architecture Figure 5 presents the architecture of WSAT. The front end of WSAT accepts service designs in various popular specifications such as BPEL, WSDL, and conversation protocol. The core engine of WSAT uses an intermediate presentation called guarded finite

7 state automata (GFSA) to represent service designs. GFSA uses XPath [9] guards to define data manipulation semantics so that services defined using BPEL can be translated without loss of data semantics. Analyses such as synchronizability and realizability analyses are applied to identify fragments of services that have lower verification complexity under asynchronous communication environment. When the analyses complete, GFSA specifications are translated to Promela. Then LTL model checking is performed. If desired LTL properties are violated by a BPEL specification, an error trace is generated by the SPIN model checker. Examination of an error trace, however, turned out to be a very difficult task in the past. A succinct XPath expression can be very complex in semantics and can result in multiple intermediate steps in the corresponding Promela translation. For example, a full dump with local/global variables for a Loan Approval example results in a 14MB text file which consists of 340K lines of trace information. Even the visualization tool Xspin (for SPIN model checker) does not help here, because there are too many intermediate steps involved. To mine information from such a log file, no wonder, can take hours even for an experienced user of SPIN. When EA4B is used, such an analysis can be greatly simplified. For example, a log file of 10 log records can be generated by WSAT from the 14MB trace file of the Loan Approval example, and the visual examination of such a log file took no more than 30 seconds in the EA4B tool. The key to the combination of WSAT and EA4B is the mapping algorithm from SPIN trace files to EA4B log files. SPIN trace file is structured in a very natural way: every atomic operation in a Promela program generates a record. As shown in Figure 6, each SPIN trace record starts with a title line that specifies the process name, line number, and the operation in the Promela program (wrapped with brackets, e.g., [state = loanapproval_s1] that generates the record. The rest of the record contains the valuation of all local and global variables. 39: proc 1 (loanapproval) line 152 "test.pml" (state 1) [state = loanapproval_s1] loanapproval_approve_in.firstname = 0 loanapproval_approve_in.name = 0... Figure 6: Fragment of a SPIN Trace File The mapping algorithm parses the SPIN trace file, filters all records that are generated by XPath data operations, and concentrates on the transitions of GFSA states. When verifying BPEL processes (before SPIN trace is generated), WSAT keeps a symbol table during the translation from BPEL to GFSA. Each SPIN variable can be traced back to one or a part of an XML variable in BPEL specification, and each GFSA state is labeled with information related to a BPEL activity, e.g., entrance of the 2 nd Assign activity in BPEL process LoanApproval. Based on this symbol table, WSAT can easily generate a log record for each state, with detailed data information. In addition, WSAT can perform a search for unmatched started records, and automatically generates the corresponding faulted records. This allows very efficient discovery of deadlock or blocked errors. 7. Conclusions In this paper we present the design and implementation of the tool EA4B that provides visualization, monitoring, and debugging functionalities for BPEL processes. An integration of the tool with WSAT is also completed. This initial work brings many new and interesting questions in the general area of service development and management. For examples, how to visualize, log invoked services? If the invoked services are logged separately (an apparent choice), how could log records of two or more executions be associated? Perhaps this could be done with correlation sets. On the monitoring front, how could multiple BPEL executions (on the same or different BPEL specification) be visualized simultaneously? Acknowledgments: Work by Su is supported in part by NSF grant IIS References 1. ActiveBPEL. makearrayfromstring.bpel J. Bloomberg. The Seven Principles of Service- Oriented Development. XML & Web Services, August /magazine/focus/jbloomberg/ 3. Business Process Execution Language for Web Services (version 1.1), ibm.com/developerworks/library/sp ecification/ws-bpel/, July M. Chitnis, P. Tiwari, and L. Ananthamurthy. Activity Diagram in UML. le.php/

8 5. G. J. Holzmann. The SPIN Model Checker - Primer and Reference Manual, ISBN , Addison-Wesley Pearson Education, September X. Fu, T. Bultan, and J. Su. Model checking XML manipulating software, Proceedings of the 2004 ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), Boston, MA, July 11-14, 2004, pp X. Fu, T. Bultan, and J. Su. WSAT: a tool for formal analysis of web services, Proceedings of the 16 th International Conference on Computer Aided Verification (CAV), R. Alur and D. Peled (eds.), LNCS 3114, Boston, MA, July 13-17, 2004, pp X. Fu, T. Bultan, and J. Su. Analysis of interacting BPEL web services, Proceedings of the 13 th International World Wide Web Conference (WWW), New York, NY, May 17-22, 2004, pp A. Pnueli. The temporal logic of programs, Proceedings of the 18 th IEEE Symposium on Foundations of Computer Science (FOCS), IEEE Computer Society Press, 1977, pp W3C, XML Path Language (XPath) 1.0,