24 BETTER SOFTWARE MARCH

Transcription

1 veer images 24 BETTER SOFTWARE MARCH

2 Web services the foundation of today s service-oriented architecture (SOA) are self-contained, modular applications that can be described, published, located, and invoked over a network. Web services are independent of operating system, hardware platform, communication protocol, or programming language. Most IT components such as databases, application servers, Web servers, and packaged applications (such as ERP and CRM applications) now advertise their interfaces as Web services through Web Services Definition Language (WSDL) interfaces. These WSDL interfaces enable applications to communicate via SOAP/XML messaging. Using SOAP for service-to-service messaging and WSDL for interface description, IT professionals now have unprecedented flexibility in integrating IT components to create major applications. It is this flexibility of developing and deploying distributed computing provided by Web services that makes testing SOA challenging. SOA testers are now responsible for adapting their testing techniques, selecting appropriate testing tools, and developing Web services domain expertise to make their SOA deployments reliably and securely deliver business value. SOA testers must have a solid understanding of XML, SOAP, and WSDL. These standards form the foundations of Web services. For a quick refresher on these standards, read through the tutorials located in the StickyNotes. These tutorials are recommended but are not a prerequisite for understanding this article. MARCH 2008 BETTER SOFTWARE 25

3 Figure 1: Web services consumer-producer setup In addition, it produces the WSDL file that defines the Web service interface. This file provides all the necessary information for the consumer, SOAPSonar, to send SOAP requests to the target Web service. SOAPSonar consumes and interprets the WSDL-based API published by the producer and invokes the Web service. Figure 2: Inputs for generating a simple Web service MathWS.asmx REQUIRED SOFTWARE AND SETUP To illustrate building and testing your first Web service, one with a single operation Add(int a, int b), the following components are required: Microsoft.NET WebMatrix: This installer includes an IDE for building Web services and a lightweight Web server. Crosscheck Networks SOAPSonar Enterprise Edition: This is a.net-based SOAP client used for comprehensive Web services testing. Both components can be installed on a Windows 2000/ XP/2003 machine with moderate resources. Figure 1 shows a typical Web service deployment with a consumer-producer interaction model. The producer is the.net WebMatrix server that supplies a Web service with the Add(int a, int b) operation that applications can invoke, typically remotely, over HTTP(S). BUILDING A SIMPLE WEB SERVICE Follow these steps to build your first Web service: 1. Download and install.net WebMatrix from 2. Go to: Start > All Programs > Microsoft ASP.NET Web Matrix > ASP.NET Web Matrix. 3. You will be prompted with the screen shown in figure 2. Fill in the information as shown. Select Web Services in the left panel and the Simple template in the right panel. You can create a C:\WebServices folder for your file location. Enter MathWS.asmx as the filename and pick C# as the language that the wizard will use to autogenerate the code. Also, declare the class as MathWS, and the namespace as math. 4. With the values selected and entered in step 3, WebMatrix auto-generates a Web service for you with the code in figure Click the Start button in the IDE and it will prompt you to start the Web application on port 9090, as shown in figure 4. Make sure your local firewall is turned off. 6. A Web browser with operation Add(int a, int b) will appear. You can click this and start experimenting with your first Web service. You are now ready to test your first Web service and determine its functional, performance, and interoperability characteristics. In the following sections, you will learn specific Web services-testing techniques. TEST CLIENT SETUP SOA testers must ensure that Web services deployed within 26 BETTER SOFTWARE MARCH

4 their infrastructure work as advertised across functional, performance, and interoperability requirements. Let s examine these Web services testing requirements for our Add Web service. We begin by installing and running SOAPSonar. Download and Install Crosscheck Networks SOAPSonar Enterprise Edition from download/p_cust_info_try.php. Load the WSDL published at the.net WebMatrix Endpoint: localhost:9090/mathws.asmx?wsdl into SOAPSonar as shown in figure 5. Figure 3: C# code generated for simple MathWS.asmx operation Add(int a, int b) Three Pillars of Web ServiceS Testing With the WSDL loaded into the test client SOAPSonar, you are now ready to perform the three pillars of testing Web services functional, performance, and interoperability for your target Web service. Each of these testing criteria described below is important for comprehensive Web services-testing coverage. Functional Testing Functional testing is the first pillar of Web services testing. Functional tests for the Add(int a, int b) operation can easily be created in SOAPSonar as follows: Configure individual test cases in SOAPSonar for the operation as shown in figure 6. Use the New Test Case button for adding test cases. Figure 6 shows six test cases in the left navigation panel. For each test case, the SOAP request value is set and saved manually by the test case author. For advanced users, the input values a and b could be retrieved from external data sources such as a RDBMS, flat files, or spreadsheets. This eliminates the need for manual entry of SOAP request fields. Once the test cases are defined, the user can select any combination of test cases and build a test suite. To build a test suite, click Run View as shown in figure 7. From the left-most navigation panel, drag-and-drop test cases into the default test suite. In figure 7, all test cases are selected to run as the default suite. Additional test suiterun parameters can be configured from this view including protocol HTTP 1.0 or 1.1, timeout settings, and wait times between each test case. Figure 4: Interface prompt for starting application on a selected local port With test cases and test suites, testers can easily organize test scenarios to en- Figure 5: SOAPSonar with Web services WSDL loaded from.net WebMatrix Server MARCH 2008 BETTER SOFTWARE 27

5 sure that the target Web service behaves as expected. For the Add operation, test cases may include positive and negative test cases. For positive test cases, sending simple integer input values to the Web service ensures that the operation can indeed add the two input values, a and b. Negative test cases that send very large values, incorrect data types, and special characters also can be used to ensure that the Web service handles them as expected, returning error codes or throwing exceptions. Functional Testing Caveats As testers become comfortable with SOA functional testing and move beyond the simple Web service that we have created and tested here, the following items should be noted: Loading WSDLs: The starting point for testing a Web service is importing a WSDL from a Web services application. With WS- DLs being generated by a variety of systems such as application servers (WebLogics, WebSphere, JBoss, Tomcat, NetWeaver), RD- BMS (Oracle 10g, IBM DB2, MS SQL Server), and SaaS providers (Salesforce.com, NetSuite, Sugar- CRM), the first hurdle faced by testers is importing and parsing WSDLs so that they can navigate to the desired operation for building test suites. Broad Standards Support: With a WSDL imported and an operation selected, a SOA tester may have to perform a number of tasks within the SOAP request before sending it to the Web service. Beyond basic WSDL and SOAP standards, Web services standards that are widely used include WS-Security 1.1 for Encryption, Signatures, and Identity Profiles (SAML, User Name, X.509, Kerberos), WS-Addressing, WS-Reliable Messaging, and WS-Policy. Test Management: Once the desired operations and associated tasks are defined, the tester must focus on test management including chained WSDL operations. For example, we may have a protected Web service operation padd(int a, int b) that can only be invoked after a login (user, password) operation is called. Figure 6: Setting test cases for Add(int a, int b) operation Figure 7: Setting test suites for Add(int a, int b) operation The login operation responds with a session token. This session token then must be passed for every padd(int a, int b) test case. Setting up a chained operation sequence test case such as login(user, password) padd(int a, int b) is typical for testing real-world SOA deployments. 28 BETTER SOFTWARE MARCH

6 Response Validation: For every SOAP request, the response from the Web service must be evaluated. To determine whether a SOAP response is valid or invalid, a tester should set up pre-defined filters that examine HTTP return codes, SOAP faults, or any businessspecific content contained in a SOAP response. SOAP content-specific filters for response processing are set via XPath expressions. For example, if a SOAP fault Figure 8: Configuring performance testing for Add(int a, int b) operation Figure 9: Executing design time WS-I Basic Profile interoperability tests is expected for a set of invalid inputs, then an XPath expression such as soap:envelope[0]\soap:body[0]\ soap:fault[0]\faultcode[0] would look for the first faultcode node in the SOAP response. A test case with this XPath criterion would mark the SOAP response as valid, indicating that, as expected, an exception did occur for invalid input values. Performance Testing Performance is the second pillar of Web services testing. Testers should verify the scalability of Web services and determine performance, endurance, and stability characteristics of their Web services operations. Once the functional tests are defined, performance tests can be created as follows: 1. Change the SOAPSonar Mode to Performance Mode as shown in figure 8. The test suite configured during functional tests will now be used for performance testing without significant additional effort. 2. Performance parameters such as Protocol HTTP 1.0/1.1, response timeout, and test duration can be configured. We reduced the default run duration of thirty seconds for each test to five seconds per test case. Once the test is started, a real-time run monitor shows the performance test progress. After the performance tests are complete, a summary of performance statistics appears in the bottom panel as shown in figure 8. For more detailed performance statistics, a tester can generate reports by clicking the Report View button. For scalability testing, additional virtual clients can be added beyond the default value of 1. Performance Testing Caveats As testers become comfortable with SOA performance testing and move beyond the simple Web service that we have created and tested in this article, a better understanding of performance measurements for Web services is required. Understanding when a Web service has hit its performance knee requires deeper content awareness than just examining HTTP return codes for success (e.g., 200 OK) and failure (e.g., 500 Internal Server Error). For Web application testing, HTTPlevel error codes are sufficient; however, for Web services testing, these error codes are inadequate. Testers must examine MARCH 2008 BETTER SOFTWARE 29

7 SOAP faults as well as business-specific content in the SOAP response. For example, a Web service for stock quotes may appear to function as expected by returning HTTP 200 OKs during scalability testing; however, if the stock quote value returned is negative, that would indicate a business context error. Classic Web application testing tools that lack SOAP content awareness would incorrectly pass such performance tests. For comprehensive Web services scalability and performance testing, HTTP codes, SOAP faults, and business-specific data in the SOAP message all may need to be considered to identify fail/ pass ratios. Interoperability Testing Interoperability is the third pillar of Web services testing. Web services specifications are broad and often vague, and the degree to which technology vendors follow these standards varies significantly. To establish a tighter control around standards implementation, the Web Services Interoperability Organization (WS-I) has established a set of profiles. When followed, these profiles (Basic Profile, Basic Security Profile, and Reliable Secure Profile) enable Web services products to interoperate seamlessly. Adhering to WS-I profiles ensures that Web services are interoperable and that WSDL can work within heterogeneous.net and Java environments. When a WSDL is given to testers, it is imperative that they evaluate both design-time and run-time interoperability characteristics of the Web services. Both can be evaluated by SOA tools such as SOAPSonar as follows: 1. For design time WS-I Basic Profile interoperability testing, switch to QA Mode as shown in figure 9. Select the Documents item under the Configuration folder in the left navigation panel. Select the Interactive WS-I tab and press the Analyze button to run WS-I Basic Profile tests. The design time tests show that the WSDL generated from.net WebMatrix is WS-I Basic Profile compliant with zero violations. 2. Design-time WSDL interoperability testing is not enough. Run-time interoperability testing is also necessary. Testing the interoperability of a Web service requires creating specialized test suites for a WSDL. These tests ensure that the target Web services are interoperable by actively sending specialized requests to the Web services and determining whether the Web service responds per WS-I profile specification. To set up run-time WS-I interoperability testing, simply switch to Compliance Mode and from Run View press the Run Suite button to execute run-time interoperability testing. After completing the test run, a detailed report is available in Report View and provides interoperability compliance violation details with severity levels as shown in figure 10. Figure 10: WS-I Basic Profile run-time compliance violation results Testers can generate comprehensive design-time and runtime interoperability reports and collaborate with Web services developments in pinpointing interoperability problem areas and recommended remediation strategies. Such collaboration nurtures interoperable Web services that can integrate with applications independent of platform, operating system, and programming language. Interoperability Testing Caveats Design-time interoperability testing tools and plug-ins are standard in development environments. For development teams that make such design-time testing part of their development process, the Web service WSDLs that they produce will be interoperable. That means that other diverse consumers (client applications) can parse and consume such WSDLs. It does not, however, assure that the Web service itself is honoring WS-I interoperability rules at run time. Although the WSDL for the Web service may be interoperable, the Web service itself may not be. Ensuring both design- and run-time interoperability is paramount in realizing the benefits of reusability the cornerstone of a service-oriented architecture. CONCLUSION In this article, you have learned how to build a simple Web service and how to test it using the three pillars of Web services testing functional, performance, and interoperability tests. The promise of Web service-based SOA success lies in reusability across distributed environments. The ease of developing Web services puts a significant burden on SOA testers to ensure that Web services are robust, reliable, secure, and scalable. Through collaboration with development teams, a growing understanding of Web services technologies, and comprehensive Web services-testing tools, testers can ensure that the Web services being deployed within their SOA environments function as expected, scale with growing demand, and are interoperable among a diverse population of applications. {end} Sticky Notes For more on the following topic go to n Refresher tutorials 30 BETTER SOFTWARE MARCH