BACKGROUND OF THE INVENTION A Web services is a collection of functions that are packaged as a single entity and published on the network for use by other applications. Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform various functions that range in difficulty. They can perform functions as simple as initiating a simple request to as complicated as utilizing complex business processes. Web services may provide a single stock quote or even process complex credit card transactions.

Web services dynamically interact with other Web applications using open standards that include XML, UDDI (Universal Description, Discovery and Integration) and SOAP (Simple Object Access Protocol). Such applications typically run behind the scenes, one program"talking to"another (server to server). Microsoft's. NET and Sun's Sun ONE (J2EE) are the major development platforms that naively support these standards.

Web services are guaranteed to be at the heart of the next generation of distributed systems for the following reasons: Interoperability. Any Web services can interact with any other Web services. Thanks to SOAP, the new standard protocol supported by all major vendors, the agonies of converting between CORBA, DCOM, J2EE and other \ protocols are virtually eliminated. Since Web services can be written in any programming language, developers need not change their development environments in order to produce or consume Web services.

Ubiquity. Web services communicate using HTTP and XML. Therefore, any device that supports these technologies can both host and access Web services.

Low Barrier to Entry. The concepts behind Web services are relatively easy to understand. Free toolkits from vendors like IBM and Microsoft allow developers to quickly create and deploy Web services. Additionally, some of these toolkits allow pre-existing COM components and JavaBeans to be easily exposed as Web ! services.

Industry Support. All of the major vendors are supporting SOAP and the surrounding Web services technologies. For example, the Microsoft. NET platform is based on Web services, making it very easy for components written in Visual Basic to be deployed as Web services; or consumed by Web services written with IBM VisualAge.

The promise of Web services is in the integration of disparate software systems. Web services provide the neutral ground where theoretically, and perhaps practically, any and all computer systems can communicate/interact with each other. Integration is the interoperability between different kinds of systems. The key advantages of developing and deploying new Web services or migrating existing applications onto the Web services platform are: Easier application interoperability both inside and outside the Enterprise Improved vertical integration with suppliers and vendors to drive increased efficiencies Greater and improved application development choices for developers and Web services Better utilization of existing applications and the investments made in them Intranet Web services are used internally by organizations but not exposed to the general public. In today's enterprise, many functional and geographical distributed groups are using multiple applications that were developed by using many different protocols/middleware/databases for automating critical business processes. As a result of these heterogeneous applications, it is very expensive to share critical business data between applications, or to have applications interact with each other. Web services enable these applications to interoperate/interact with each other seamlessly as a result of standard communication protocols such as SOAP and WSDL. This integration results in a significant efficiency gain for the enterprise.

Web services over the public Internet are expected to materialize over the next several years. For global services to be successful, industries must define the details of every function that such a service must provide before it is put into operation. This is accomplished through Web services Description Language (WSDL). WSDL is protocol for a Web service to describe its capabilities. Co- developed by MicrosoftT and IBMT"", WSDL describes the protocols and formats used by the service.

To promote the use of Web services worldwide, WSDL descriptions can be housed in a Universal Description, Discovery and Integration (UDDI) directory, which is a searchable universal business registry (catalog) of Web services. UDDI is designed to enable software to automatically discover and integrate with services on the Web. Using a UDDI discovery system, the goal is to register the service on the Internet so that an application may search for and find the service, and then seamlessly exchange data with it. The UDDI registry contains white pages (addresses and contacts), yellow pages (industry classification) and green pages (description of services). The green pages include the XML version, type of encryption and a Document Type Definition (DTD) of the standard. UDDI messages ride on top of the SOAP protocol, which invokes services on the Web.

In essence, Web services are a new programming paradigm. Since they are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web, testing these Web services is a significant and challenging task. Web services are designed so that they can interact with each other, with or without human intervention. They, therefore, do not inherently display a user interface that can be tested. Moreover, Web services strive on interoperability, which means that a. NET-based Web services should be able to access and be accessed by any J2EE-based application. This means that irrespective of the base platform on which Web services are built, they have to be tested using all variations of possible client applications (i. e.,. NET-based, J2EE-based, python-based, PERL-based).

CHALLENGES IN TESTING WEB SERVICES Web Services create unique and significant testing challenges, more so

than testing conventional Web applications or client-server applications. Existing testing tools currently available in the market do not directly address the issues in testing Web Services. While some tools test Web Services post deployment, most do not test in both pre-and post-deployment situations. It is essential and most efficient to check the functionality, scalability, and reliability of the Web Services in both pre and post deployment scenarios.

Here are some of the key problems/challenges in testing the Web Services: Web Services are reusable, network-accessible software components that could be invoked by any number of different applications/clients within and outside the firewall. Since Web Services are not attached to any single application or GUI of the application, performing GUI testing of an application will not completely test the Web Service. The result will be poorly tested Web Services that will result in poor quality, unhappy customers, and lost opportunities.

Web Services are completely GUI-less. They do not display any graphical user interface that can be tested directly by any of the available GUI testing tools (WinRunner, QARun, SilkTest). Any of the existing GUI testing tools cannot be used for testing Web Services as they do not have their own GUI.

A third serious problem with GUI-based testing approaches is that they cannot provide the scalability testing which isßessential for a Web Service.

Adding a new vendor/supplier or their app cannot be tested using the existing GUI testing approach since it will result in an endless process of testing each new vendor/partner's app that will be integrated along with the Web Service.

The best approach is to test the Web Service for its complete functionality, scalability, and reliability before deployment and then monitor its behavior after deployment. This way one can focus on what should really be tested rather than trying to chase each new vendor's app and requiring that it be tested using a specific GUI testing tool.

Additionally, Web Services are often used/invoked by other GUI-less applications or other Web Services. The GUI-based testing approach is unable to test effectively when Web Services comprise of other Web Services thus

defeating the actual benefits of Web Services which are re-usable, network- accessible software components which could be accessed on demand.

The GUI-based testing approaches of Web Services also make the problem/bug isolation process very costly and time consuming as the problem could be with the GUI, with the application, or with the Web Service. GUI-based testing is inefficient and ineffective in testing a Web Service and will increase the overall cost of maintaining the application.

The GUI-based Testing approach offers the following choices for a QA/Tester : 1. Write a GUI application that will simulate the usage of the Web Service for testing. With this option, one must write a dummy application that thus will require time to develop and increase the overall cost. As Web Services can be invoked by many different applications from different users/vendors/partners, it is inefficient and, for all practical purposes, impossible to simulate all of these situations into one single dummy application thus leaving the Web Service poorly tested. Additionally, testing Web Services using wrapper applications does not support cross-platform environments and most organizations will have to use different tools on different platforms and record the scripts for each platform, separately. This again adds to the extra cost of the testing efforts, if the testing has to be performed on multiple platforms.

2. Use a conventional GUI testing tool to test the GUI that in turn may be invoking/using the Web Service. Again, the problem here is that you will not be able to simulate the environment that may exist within different apps that may be using this Web Service. Another problem here is that the GUI of the application often keeps changing even though the underline Web Services it is using are unchanged. This results into a very repetitive, redundant and endless record and replay cycles where one will have to re-record the GUI test for all small GUI changes, even if the Web Service (s) being used are unchanged. Again, this approach to Web Service testing will significantly increase the cost of QA and cause substantial delays in bringing new services to-market.

Neither of these approaches is ideal or efficient for Web Service testing.

Efficient and optimal Web Services testing is performed at the API level.

Traditionally API level testing identifies more defects/bugs and isolates

them quicker than GUI-based testing. The overall product release, cost, time-to- market, and cost of ownership of the product (in terms of maintenance) is reduced dramatically if API level modular testing approach is used over GUI- based testing.

Currently, customers of Web services have two options for testing the Web services. The first option is to use GUI testing tools for testing the applications that interact with the Web services, and indirectly testing the Web services through the applications. The second option is to perform internal test development and automation to some degree.

When each of the situations is examined carefully, the disadvantages become apparent. Using the GUI testing approach, the Web service will be left poorly tested since there is no way the web service tester can simulate the GUI environments for hundreds of GUI applications that are going to connect to the Web service. When the poorly tested Web service goes live, many problems will become uncovered when it is accessed by applications from different vendors/partners/users. Supporting each of these vendor/partner could be an extremely difficult and very expensive affair. The details of the disadvantages include : o The company still has to invest resources and cost in developing simulated GUI applications to test the Web services. o The company will have to develop scripts using conventional record and playback tools for testing the GUI, which will involve cost and money. o The company will have to change the GUI scripts as and when the GUI environments change (which will happen almost all the time in real world situations). This means the company is constantly allocating resources to maintain the GUI tests. o GUI testing is unable to test complex Web services cascading and workflow. o The cost and time spent in isolating the bugs is going to be huge since there are multiple layers thru which the test engineer will need to analyze before isolating the bug or the problem. o For load testing, the company will need to develop test driver scripts (with learning curve for learning proprietary scripting language) for the load

tester. o The load testing cycles will become very unpredictable, long, and costly. o The test development and maintenance efforts remain a very costly and time-consuming task. o The total cost of ownership of the tests will be very high. o The company will not be able to address key Web services issues such as interoperability and security.

The option of internal test development for testing Web services is no more attractive. The disadvantages of developing internal tools include the following : o Very expensive and costly to develop a comprehensive tool internally. o Tests (API level) will need to be developed internally. o Lack of core expertise in Test Tools space would make it challenging as well. o Focus will deviate from the company's core competency. o On going support for the tool will need on-going resource allocation and cost. o The Tests and Automation will not be available in time and would delay time-to-market.

Web Services are usually consumed by a number of applications or users and it is critical to know the scalability, availability and performance of the Web Service when a large number of users are accessing/consuming it. A SOAP message level Lo, ad Testing tool provides mechanism to do the scalability & performance testing of individual Web Services operations. However these tools do not provide any mechanism to find out how the entire business process would perform if a large number of users are accessing it.

The traditional Load testing solutions typically expect the user to do a lot of guess work by allocating and configuring different number of Virtual Users (VUs) to different number of operations based on the expected usage. However this guess work does not allow to simulate the load in the same manner as if

thousands of users are accessing the business process at the same time. It is limited to only individual operations and the QA engineer's ability to configure and guess load level for these individual operations. Also this technique deviates from the real world situation and would not be able to detect errors that are caused due to a specific path within the business process workflow. In the end, you would be leaving your workflow or business process poorly tested from the scalability point of view and would increase the cost and manual configuration dramatically.

Accordingly, what is needed is an improved method and system for testing Web services. The present invention addresses such a need.

BRIEF SUMMARY OF THE PRESENT INVENTION The present invention provides a system and method for automatically testing a workflow for Web services. The present invention will test the Web Services Workflow for Web Services that are deployed within an Intrant as well as over a public network, such as the Internet. According to the method and system disclosed herein, the present invention provides a tool to automate Web Services Workflow testing tasks that can automatically parse the workflow information-including but not limited to-sequence of the Web Services execution, information pertaining to asynchronous and synchronous execution of the Web Services, interdependencies amongst various Web Services, Data assignment and Data flow from source Web Services to Target Web Services.

The present invention, disclosed herein, can test the Workflow of the Web Service for following types of testing-Functional testing, Regression Testing and Load Testing. The tool also monitors execution of the workflow of Web Service and also the each individual Web Service participating in the Web Services Workflow for fault conditions (viz. SOAP Faults, Exceptions, etc. ) and for time- outs. The present inventions also analyzes the results for Pass/Fail/Timeout decisions and generates the test reports for the Web Services Workflow execution.

Aspects of the present invention include reading a Web Service Description Language (WSDL) file and a Business Process Execution Language for Web Services (BPEL4WS or BPEL) file for the Web Service (s) over the

network, wherein the WSDL file specifies operations performed by the Web service (s) and BPEL file specifies the workflow of the Web Service (s). Sequence of execution of the Web Service (s) is decided as per BPEL description and SOAP requests are automatically generated for testing each activity specified in the BPEL file. At least one test data set is automatically generated for testing the Web service. The user can modify the automatic generated test data or add/delete the data manually. The present invention, disclosed herein, will perform the appropriate test data assignments and ensure the appropriate data flow from source Web Services to Target Web Services. The Web Service are invoked in pre-defined sequence (synchronously or asynchronously) as specified in BPEL file and using the automatically generated SOAP requests and available test data such that requests are sent to the intended Web service. The responses are received back from the Web Service (s) and analyzed for pass/fail/timeout decision depending on pre-defined test metrics or Service Level Agreements (SLAs).

BRIEF DESCRIPTIONS OF THE DRAWINGS Figure 1 is a diagram illustrating and architectural view of the BPEL Web Services Workflow Tester system in a preferred embodiment of the present invention.

Figure 2 is a flow diagram for how the WebServiceTester system process the workflow of the Web Services described using BPEL language according to a preferred embodiment of the present invention.

\Figure 3 is a block diagram showing portion of the WebServiceTester relevant to BPEL Parsing.

Figure 4 is a flow diagram illustrating the process performed by the BPEL Parser to obtain the Web Services workflow information specified in the BPEL file.

Figure 5 is a block diagram showing portion of the WebServiceTester relevant to SVG File Generation.

FIG. 6 (comprising FIG 6A, FIG 6B, FIG 6C) is the flow diagram illustrating the process performed by the SVG File Generator.

Figure 7 is the sample SVG file that represents the Web Services

workflow information used to represent the graphical presentation of the Web Services Workflow.

Figure 8 is a block diagram showing portion of the WebServiceTester relevant to BPEL Test Data Generator.

Figure 9 is a flow diagram illustrating the process performed by the BPEL Test Data Generator to create the sample test data file that is used to exercise the Web Services workflow.

Figure 10 is a block diagram showing portion of the WebServiceTester relevant to BPEL Tester.

FIG. 11 (comprising FIG 11A, FIG 11 B, FIG 11 C) is a flow diagram illustrating the process performed by BPEL Executor.

Figure 12 is a diagram illustrating the graphical presentation of <assign> activity in the flowchart.

Figure 13 is a diagram illustrating the graphical presentation of <throw> activity in the flowchart.

Figure 14 is a diagram illustrating the graphical presentation of <catch> activity in the flowchart.

Figure 15 is a diagram illustrating the graphical presentation of <catchAll> activity in the flowchart.

Figure 16 is a diagram illustrating the graphical presentation of <switch> activity in the flowchart.

Figure 17 is a diagram illustrating the graphical presentation of <pick> activity in the flowchart.

Figure 18 is a diagram illustrating the graphical presentation of <invoke> activity in the flowchart.

Figure 19 is a diagram illustrating the graphical presentation of <terminate> activity in the flowchart.

Figure 20 is a diagram illustrating the graphical presentation of <receive> activity in the flowchart.

Figure 21 is a diagram illustrating the graphical presentation of <reply> activity in the flowchart.

Figure 22 is a diagram illustrating the graphical presentation of <wait> activity in the flowchart.

Figure 23 is a diagram illustrating the graphical presentation of <while> activity in the flowchart.

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to testing of the Web Services workflow specified using BPEL language. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and it's requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described herein.

BPEL TESTER MODULE OF WEBSERVICETESTER The present invention provides a BPEL Tester portion of a software test management system, referred to as WebServicetesterw. BPEL Tester portion of the WebServiceTester software test management system has the following functionalities.

1. BPEL Tester portion of the WebServiceTester supports the extraction of workflow and controlled execution of web services described in BPEL file, conforming to BPEL4WS specifications version 1.1.

2. BPEL Tester portion of the WebServiceTester defines the sequence of execution depending on the <flow> and <sequence> activity definitions from BPEL file to ensure that all source services are executed before the target services.

3. If the <flow> consists of concurrent <sequence> then all concurrent <sequence> activities should be executed simultaneously by BPEL Tester portion of the WebServiceTester.

4. BPEL Tester portion of the WebServiceTester extracts the workflow and identify the source and target relationship of the web services from the BPEL file.

5. BPEL Tester portion of the WebServiceTester provides the graphical

presentation of the extracted workflow in the form of flow diagrams.

6. BPEL Tester portion of the WebServiceTester supports the execution of nested, multiple level of <flow> and <sequence> activities that can appear in <flow> and <sequence> activities.

7. All source and target links are correctly extracted by BPEL Tester portion of the WebServiceTester, that appears inside all activities definitions as per BPEL specifications version 1.1.

8. BPEL Tester portion of the WebServiceTester supports the workflow extractions for the following activities defined in BPEL specifications. a. <receive> b. <reply> c. <invoke> d. <assign> e. <throw> f. <terminate> g. <wait> h. <empty> i. <sequence> j. <switch> k. <while> <BR> <BR> I. <pick><BR> m. <flow> n. <scope> o. <compensate> 9. BPEL Tester portion of the WebServiceTester supports passing the complete output extracted from the response of the source web service as the input to the target web service.

10. BPEL Tester portion of the WebServiceTester supports passing the complete output extracted from the response of the source web service as the part of the input to the target web service.

11. BPEL Tester portion of the WebServiceTester supports passing the part of the output extracted from the response of the source web service as the

input to the target web service.

12. BPEL Tester portion of the WebServiceTester supports passing the part of the output extracted from the response of the source web service as the part of the input to the target web service.

13. BPEL Tester portion of the WebServiceTester supports conditional execution of web services to satisfy the <switch> statements that can appear in BPEL.

14. Depending on the evaluation of the boolean expressions in case statement, BPEL Tester portion of the WebServiceTester invokes certain web services as specified by the workflow definition.

15. In <switch> statement if none of the specified <case> statement condition holds true then the web service specified in <otherwise> branch is executed BPEL Tester portion of the WebServiceTester.

16. In <switch> statement if <otherwise> branch is not specified explicitly then an <empty> activity is assumed and no operations are performed BPEL Tester portion of the WebServiceTester.

17. BPEL Tester portion of the WebServiceTester supports <throw> activity to signal the internal fault explicitly as per BPEL4WS 1.1 specifications.

18. BPEL Tester portion of the WebServiceTester supports updating the variables by assigning the whole variable to another whole variable using assignment activity <assign> as per BPEL4WS 1.1 specifications.

19. BPEL Tester portion of the WebServiceTester support for updating the variables by assigning the whole variable to the part of another variable using assignment activity <assign> as per BPEL4WS 1.1 specifications.

20. BPEL Tester portion of the WebServiceTester supports updating the variables by assigning the part of the variable to another variable using assignment activity <assign> as per BPEL4WS 1.1 specifications.

21. BPEL Tester portion of the WebServiceTester supports updating the variables by assigning the part of the variable to the part of another variable using assignment activity <assign> as per BPEL4WS specifications.

22. BPEL Tester portion of the WebServiceTester supports <wait> activity to allow the web services to delay the execution for a certain period of time specified using"for"statement as per BPEL4WS 1.1 specifications.

23. BPEL Tester portion of the WebServiceTester supports <wait> activity to allow the web services to delay the execution until the certain deadline is reached which is specified using"until"statement as per BPEL4WS specifications.

24. BPEL Tester portion of the WebServiceTester supports ordinary sequential execution of the web services dictated by sequence, switch and while activities and its combinations.

25. BPEL Tester portion of the WebServiceTester supports synchronization of web services execution defined by <flow> activity. Any concurrent activities will be executed asynchronously while preserving the synchronization between these activities.

26. BPEL Tester portion of the WebServiceTester supports non- deterministic execution of web services based on external events defined by the pick activity.

27. BPEL Tester portion of the WebServiceTester supports <while> activity to execute the web services repeatedly until the given boolean while condition holds true. Repeated execution of the web service should stop soon the boolean condition becomes false.

28. BPEL Tester portion of the WebServiceTester supports controlled execution of web services based on occurrences of one of the set of events specified by <onMessage> or <onAlarm> events specified in <eventHandler>.

29. BPEL Tester portion of the WebServiceTester supports invocation of the web services specified by the compensation handler to compensate for incomplete operations in case of incomplete execution of the web services as specified in <scope>.

30. BPEL Tester portion of the WebServiceTester supports invocation of web services specified by the fault handler to handle the faults in case of the occurrences of the faults during web service execution, as specified within the <scope>.

31. BPEL Tester portion of the WebServiceTester supports <catch> and <catchAll> activities to handle the faults.

32. If the fault with matching name specified in <catch> activity occurs then the web service specified in that <catch> activity is executed by the BPEL

Tester portion of the WebServiceTester.

33. If the fault with matching name specified in <catch> block does not occur and if <catchAll> activity is specified then the web service specified in <catchall> activity is executed by the BPEL Tester portion of the WebServiceTester.

34. BPEL Tester portion of the WebServiceTester provides a provision for importing the BPEL4WS file to set the workflow relationship automatically as per rule specified in BPEL4WS file.

35. BPEL Tester portion of the WebServiceTester supports the testing of Web Services workflow for following types of testing a. Functional Testing b. Regression Testing c. Load Testing 36. For Load test of Web Services workflow, the cumulative response time of the complete workflow is displayed in the"Response Time-vs-Time" chart.

37. BPEL Tester portion of the WebServiceTester supports testing of multiple web services workflows simultaneously.

38. BPEL Tester portion of the WebServiceTester supports the testing of the combination of Web Service workflow and the individual web services that are not part of the web services workflow.

39. BPEL Tester portion of the WebServiceTester parses the workflow information and represent the workflow in form of flow diagram.

FIG. 1 is a diagram illustrating an architectural view of the BPEL Tester module of the WebServiceTester system in a preferred embodiment of the present invention. The architecture of the BPEL Tester module of the WebServiceTester product includes six major components: BPEL Parser 14, SVG File Generator 12, BPEL Test Data Generator 19, BPEL Executor 28, BPEL Results Analyzer and Reporter 34. The functionalities of all these blocks are interdependent.

FIG. 2 is a flow diagram for how the BPEL Tester tests the workflow of the Web Services according to preferred embodiment of the present invention.

Referring to both FIG. 1 and FIG. 2, the process begins in step 51 when

the BPEL Parser 14 reads given WSDL File (s) 24 and BPEL file (s) 23 from user specified locations. WSDL file (s) 24 can be specified by the user using the WSDL URL or can also be obtained otherwise, such as, user download (s), emails, and directly from the web service provider. BPEL file (s) 23 are created by the user, which has all necessary workflow information for the target business process under test. The WSDL file 24 includes the information such as the endpoint URL of the Web Service, how the Web Service is invoked, the operation performed by the Web Service, and the type of input and output required by the Web Services operations. BPEL file (s) 23 includes the information about the business process such as, Web Services execution sequence, Web Services interdependencies, Web Services input data assignments, and how to handle the fault conditions. In step 52, BPEL Parser 14 then parses the WSDL file (s) 24 to extract the method signatures, operations, parameters and other details that are used for parsing BPEL file (s) 23, generation of Test list file (s) 25, Test data 21 and Template file (s) 26.

In step 52, BPEL Parser 14 also reads the specified BPEL File (s) 23 and extracts the Web Services workflow information.

In step 53, the SVG File Generator 12 uses the workflow information parsed by the BPEL parser 14 and generates SVG file (s) 10. These SVG file (s) 10 contains the workflow information in Salable Vector Graphics format, which is then used by the Flowchart Generator 11 to pictorially represent the business process in flow chart form.

In step 54, Test data generator 15 and BPEL Test data generator 19 generate the test data 21 to be used by the individual activities described in the Web Services Workflow. In step 57, if the workflow uses the <assign> activity to assign the data to the variables specified in the business process, then the BPEL Test Data Generator 19 assigns appropriate test data to the specifies variable (s) and/or plug-ins the test data from the source variable (s) to the target variable (s) as described by the <assign> activity.

In step 58, BPEL Tester Executer 28 feed the workflow specific information such as execution sequence, test data, flow control information to the Request Generator 20. The Request generator 20 then generates appropriate SOAP requests depending on the current activity being processed,

test data 21 and the template file (s) 26. These SOAP requests are then used by the various tester such as Functional Tester, Regression Tester 29 and Load tester 30, depending on the type of testing being performed by the user, to invoke the specified web services activities defined by the BPEL workflow. Once the test execution is complete then in step 60, the result analyzer and reporter 34 analyzes all result (s) 31 produced as specified in step 58. If the user specified the expected results in form of Golden data 22, then the actual results produced in step 58 are compared with the golden data 22. PASS/FAIL decisions are made based on either the golden file (s) comparison results or the SOAP faults received in the response from the Web Services under test. In step 60, Result analyzer and Reporter 34 also generates the consolidated reports in HTML format.

The following is a description of the major components of the BPEL Tester module of WebServiceTester: o BPEL Parser Referring to FIG 1, BPEL Parser 14 reads given BPEL file (s), parses them to decipher workflow information. BPEL Parser 14 extracts the workflow activities specified in BPEL 23, decides the execution sequence of the work flow activities, setup the appropriate interdependencies amongst different activities, establishes the data assignments and the data flow from one activity to another. BPEL Parser 14 also provides the required information to the SVG (Scalable Vector Graphics) File Generator 12 that can be used for creating the SVG files 10 for each BPEL. o SVG (Scalable Vector Graphics) File Generator Referring to FIG 1, SVG file Generator 12, uses the information parsed by BPEL parser 14 and creates the SVG file 10 for each BPEL file 23. One SVG file is created for each BPEL file. This SVG files 10 contains the pictorial presentation of the workflow specified by BPEL file 23, in form of flowchart. o BPEL Test Data Generator Referring to FIG 1, BPEL Test Data Generator 19 generates the test data

to be used while testing the web services involved in the workflow. The test data 21 provided by the user is read and validated against parsed WSDL files 24.

BPEL Test Data Generator 19 then establishes the required data assignments and data flow from one activity to another. o BPEL Executor Referring to FIG 1, BPEL Executor 28 uses the information extracted by BPEL parser 14, the test data provided by BPEL Test Data Generator 19 and creates the appropriate SOAP requests. BPEL Executor 28 then invokes the target web services using these requests with the test data 21. BPEL Executor 28 can invoke the web services in either of the following modes-Functional, Regression and Load Test. It also retrieves, collects and stores the responses received in appropriate data files. It monitors the execution of different tests for time-out, exceptions, errors, etc. and keeps the user informed about the current status via GUI updates. o BPEL Result Analyzer & Reporter Referring to FIG 1, BPEL Results analyzer and Reporter 34 analyses all responses sent by the web Services 13. The Pass, Fail and Timeout decisions are made based on either the golden data 22 (expected output file) comparison or exit status verification for each response from the web services 13. BPEL Result analyzer and Reporter 34 also analyzes and reports the status and statistics for the entire workflow against the predefined Service Level Agreements for each web services and hence the activities.

BPEL PARSER FIG. 3 is the block diagram of BPEL Parser module. Referring to FIG 3 and FIG 1 BPEL Parser 14 receives the BPEL Files 23 and WSDL files 24 through user input or from the WSDL repository and BPEL repository. BPEL workflow information is provided in a separate BPEL file 23. BPEL Parser 73 reads given BPEL files 23 and WSDL files 24, parses them to decipher workflow information. BPEL Parser 14 extracts the workflow activities specified in BPEL, decides the execution sequence of the work flow activities, setup the appropriate

interdependencies amongst different activities; establish the data assignments and the data flow from one activity to another. BPEL Parser 14 also provides the required information to the SVG File Generator 12 that can be used for creating the SVG files 10 for each BPEL.

FIG 4 is a flow diagram illustrating the process performed by the BPEL Parser 14 to extract the web services workflow information. The process begins in step 81 by receiving the user inputs, which includes the WSDL files 24 and the BPEL files 23 to parse. In step 82 the BPEL parser 14 parses the web services workflow information. In step 83 the BPEL Parser 14 invokes the SVG File Generator 12, which starts the process of SVG file 10 generation. In step 84, the BPEL Parser 14 invokes the Test Data Generator 15, which in turn starts the process of Test Data generation. In step 85 and 86, the BPEL Parser 14 checks for <assign> activities specified in BPEL and performs the appropriate test data manipulations. In step 87, the BPEL Parser 14 updates the Testlist file 25, which consists of the test execution sequence, such that the sequence of activities specified in BPEL matches with the sequence specified in the testlist file.

SVG FILE GENERATOR FIG. 5 is the block diagram of SVG File Generator 12. Referring to FIG 1 and FIG 5, SVG file Generator 10 uses the Parsed BPEL data 72 parsed by BPEL parser 14 and creates the SVG file 10 for each BPEL. One SVG file is created for each BPEL file 23 and stored on disk in SVG (Scalable Vector Graphics) format. This SVG file 10 contains the pictorial presentation of the workflow specified by BPEL file 23, which then can be used to display the web services workflow in form of a flowchart.

For each activity in BPEL file 23, SVG File generator 12 creates an appropriate SVG block to represent the BPEL workflow. Activities in the <sequence> are displayed as one after another as part of the same execution path. If the <flow> consists of multiple sequences, then each sequence is displayed as independent, asynchronous execution path. The generated SVG files 10 are then used by the WebServiceTester GUI to render the flowchart for the BPEL file on user's request.

For each activity mentioned in the BPEL file 23, the SVG file generator 12

will write the rectangular block to the SVG file. The activity name is displayed in that particular rectangular block for that activity. If any operation is used by the activity, then the operation name will also be displayed in the rectangular block of that activity. Depending on the flow mentioned in the BPEL file 23, the connecting links for starting point and ending point for the various blocks of the process flow diagram are computed and written to SVG file 10. If the variables or conditions are used by any of the activity in the BPEL process, then the control conditions are variables used are displayed for each of those activities.

FIG. 7 illustrates the sample SVG file 10 generated by the SVG File Generator 14.

FIG. 6 (comprising FIG 6A, FIG 6B, FIG 6C) is the flow diagram illustrating the process performed by the SVG File Generator 14. The process begins in step 91 by receiving the input for generating the SVG file, which includes BPEL files 23 and WSDL files 24. In step 92 SVG file generator receives the Parsed BPEL Data 72 that is generated by BPEL Parser 14.

In step 93, SVG File Generator 12 start processing each activity specified in BPEL file. In step 94, SVG File Generator 14 tests if the current activity is <receive> activity. If the current activity is <receive> activity then it writes the corresponding <receive> activity block in SVG file 10 in step 95 and continues processing next available activity else it continue testing for other types of activities unless the proper match is found.

In step 96, SVG File Generator 14 tests if the current activity is <invoke> activity. If the current activity is < invoke > activity then it writes the corresponding <invoke> activity block in SVG file in step 97 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 98, SVG File Generator 14 tests if the current activity is <reply> activity. If the current activity is <reply> activity then it writes the corresponding <reply> activity block in SVG file 10 in step 99 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 100, SVG File Generator 14 tests if the current activity is start of a new <flow> activity. If the current is start of a new < flow > activity then it writes

the corresponding start of <flow> activity block in SVG file 10 in step 128 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 101, SVG File Generator 14 tests if the current activity is an end of a <flow> activity. If the current is an end of a <flow> activity then it writes the corresponding end of <flow> activity block in SVG file 10 in step 102 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 103, SVG File Generator 14 tests if the current activity is <throw> activity. If the current activity is < throw > activity then it writes the corresponding < throw > activity block in SVG file 10 in step 104 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 105, SVG File Generator 14 tests if the current activity is <terminate> activity. If the current activity is < terminate > activity then it writes the corresponding < terminate > activity block in SVG file 10 in step 106 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 107 SVG File Generator 14 tests if the current activity is <switch> activity. If the current activity is < switch > activity then it writes the corresponding < switch > activity block in SVG file 10 in step 108 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 109, SVG File Generator 14 tests if the current activity is <wait> activity. If the current activity is < wait > activity then it writes the corresponding < wait > activity block in SVG file 10 in step 110 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 111, SVG File Generator 14 tests if the current activity is <empty> activity. If the current activity is < empty > activity then it writes the corresponding < empty > activity block in SVG file 10 in step 112 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 113, SVG File Generator 14 tests if the current activity is new <sequence> activity. If the current activity is new < sequence > activity then it writes the corresponding < sequence > activity block in SVG file 10 in step 127 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 114, SVG File Generator 14 tests if the current activity is <while> activity. If the current activity is < while > activity then it writes the corresponding < while > activity block in SVG file 10 in step 115 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 116, SVG File Generator 14 tests if the current activity is <pick> activity. If the current activity is < pick > activity then it writes the corresponding < pick > activity block in SVG file 10 in step 117 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 118, SVG File Generator 14 tests if the current activity is < assign > activity. If the current activity is < assign > activity then it writes the corresponding < assign > activity block in SVG file 10 in step 119 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 120, SVG File Generator 14 tests if the current activity is <compensate> activity. If the current activity is < compensate > activity then it writes the corresponding < compensate > activity block in SVG file 10 in step 121 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 122, SVG File Generator 14 tests if the current activity is <scope> activity. If the current activity is < scope > activity then it writes the corresponding < scope > activity block in SVG file 10 in step 112 and continues processing next available activity, else it continue testing for other types of activities unless the proper match is found.

In step 125, SVG File Generator 12 consolidates all activity blocks, add the ending block for the SVG file 10 and writes the SVG file 10 to the disk.

BPEL TEST DATA GENERATOR FIG 8 is the block diagram for BPEL Test data Generator 19. Referring to FIG. 1 and FIG. 8 the BPEL Test Data Generator 19 uses the test data generated by Test Data Generator 15 and the user defined data specified using Test Data Editors. BPEL Test Data Generator 19 plugs-in the test data to be used while testing the web services involved in the workflow. The test data provided by the user is read and validated against parsed WSDL files. BPEL Test Data Generator 19 then establishes the required data assignments and data flow from activity to another.

FIG. 9 is the flow diagram for BPEL Test data generator. The process begins at step 141 by reading the test data. BPEL Test data generator uses the test data that is either generated by the test data generator or specified by the user. In step 142, BPEL Test data Generator reads the parsed WSDL file information generated by WSDL Parser 16 and parsed BPEL data 31 generated by BPEL parser 14. In step 143 BPEL Test Data Generator 19 starts processing each activity specified in BPEL file. In step 144, BPEL Test Data Generator checks whether the current activity is <assign> activity. If the current activity is <assign> activity then in step 145, BPEL Test Data Generator checks whether the <assign> activity performs literal constant data assignment. If the current assign activity perform literal constant data assignment then BPEL Test Data Generator 19 assigns the constant data specified in BPEL to the specified target variable in step 146. In step 147, BPEL Test Data Generator checks whether the <assign> activity specifies the data assignment from source variable (partial or complete) to the target variable (partial or complete). If the specified data assignment is from source variable (partial or complete) to the target variable (partial or complete) then the variable data specified by the source variable is assigned to the target variable in step 148.

If the process consists of <assign> activity then the static data generated by Test Data Generator or the static data specified by the user is ignored for that particular activity and the dynamically assigned data specified by the <assign> activity is used for the SOAP request generation.

BPEL EXECUTOR FIG 10 is the block diagram for BPEL Executor 28. Referring to FIG 1 and FIG 11, BPEL Executor 28 uses the information extracted by BPEL parser 14, the test data provided by BPEL Test Data Generator 19 and creates the appropriate SOAP requests. BPEL Executor then invokes the target web services using these requests with the test data. BPEL Executor 28 can invoke the web services in either of the following modes-Functional, Regression and Load Test : It also retrieves, collects and stores the responses received in appropriate data files. It monitors the execution of different tests for time-out, exceptions, errors, etc. and keeps the user informed about the current status via GUI updates.

FIG. 11 (comprising FIG 11A, FIG 11 B, FIG 11 C) is a flow diagram illustrating the process performed by BPEL Executor. The process begins in step 171 by reading the necessary testlist files 25 and the test data 21. It also reads the BPEL test data generated by BPEL Test Data Generator 19. In step 172, it receives the BPEL workflow information parsed by BPEL Parser 14. In step 173 through step 226, BPEL Executor process each activity specified in the BPEL workflow. It checks each activity to be of specified type and executes the specified activity as a part of the sequence or asynchronously, depending on whether the current activity is part of the sequence.

In step 227, BPEL Executor consolidates all responses sent by the server and the results for each activity specified in the BPEL file. In step 228, Result Analyzer and report generator is invoked, which is turns analyzes the results generated by BPEL Executor 19 and generates the reports file 163.

GRAPHICAL PRESENTATION OF BPEL ACTIVITIES All information parsed from BPEL file will be presented in the form of a flow chart. The BPEL information once parsed from the BPEL file should be stored in a file with standard graphical format. This information will then be used/reused to render the flow chart whenever the user selects the"BPEL name"link form the"BPEL"node.

graphical presentation of <assign> activity in the flowchart If the assign activity is used in the workflow then the assign activity will be displayed in the flow chart as shown in the FIG. 12. The <from> and <to> variables name should be displayed as shown in the figure. Where <variable> in front of"from"label will be the actual variable name from which the values will be assigned. The <variable> in front of"To"label will the actual variable name to which the values will be assigned graphical presentation of <throw> activity in the flowchart If the <throw> activity is used in the workflow then the <throw> activity will be displayed in the flow chart as shown in the FIG 13. The fault name is the name of the fault that will be thrown by the <throw> activity.

Graphical presentation of <catch> activity in the flowchart If the <catch> activity is used in the workflow then the <catch> activity will be displayed in the flow chart as shown in the FIG 14. The fault name is the name of the fault that will be caught by the <catch> activity.

Graphical presentation of <catchAll> activity in the flowchart If the <catchAll> activity is used in the workflow then the <catchAll> activity will be displayed in the flow chart as shown in the FIG 15.

. Graphical presentation of <switch> activity in the flowchart If the <switch> activity is used in the workflow then the <switch> activity will be displayed in the flow chart as shown in the FIG 16. Each of the <case> statement is displayed as branch and the conditions for each of the <case> to occur are displayed above the <case> block.

. Graphical presentation of <pick> activity in the flowchart If the <pick> activity is used in the workflow then the <pick> activity will be displayed in the flow chart as shown in the FIG 17. Each of the <activity> statement is displayed as branch and the message that triggers the activity is displayed for each of the <activity> block.

Graphical presentation of <invoke> activity in the flowchart If the <invoke> activity is used in the workflow then the <invoke> activity will be displayed in the flow chart as shown in the FIG 18. The <input> and the <output> is displayed for each of the <invoke> block.

. Graphical presentation of <terminate> activity in the flowchart If the <terminate> activity is used in the workflow then the <terminate> activity will be displayed in the flow chart as shown in the FIG 19.

. Graphical presentation of <receive> activity in the flowchart If the <receive> activity is used in the workflow then the <receive> activity will be displayed in the flow chart as shown in the FIG 20. The <input> and the <output> for each of the <receive> block is displayed as shown in the figure. graphical presentation of <reply> activity in the flowchart If the <reply> activity is used in the workflow then the <reply> activity will be displayed in the flow chart as shown in the FIG 21. The <input> and the <output> for each of the <receive> block is displayed as shown in the figure.

Graphical presentation of <wait> activity in the flowchart If the <wait> activity is used in the workflow then the <wait> activity will be displayed in the flow chart as shown in the FIG 22. The wait time specified either using <for> or <until> is displayed for each of the <wait> block as shown in the figure. graphical presentation of <while> activity in the flowchart If the <while> activity is used in the workflow then the <while> activity will be displayed in the flow chart as shown in the FIG 23. The <activity> that is suppose to be executed while the evaluating condition is true and the <activity> that is to be executed when the evaluating condition is false are displayed as shown in figure below. Flow chart should also display the evaluating condition for the <while> activity.

The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.