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 below. These tutorials are recommended but are not a prerequisite for understanding this article.
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:
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). 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.
Building A Simple Web Service
Follow these steps to build 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 their infrastructure work as advertised across functional, performance, and interoperability requirements. Let’s examine these Web services testing requirements for our Add Web service.
Three Pillars Of Webservicestesting
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 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:
With test cases and test suites, testers can easily organize test scenarios to ensure 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:
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:
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, HTTP-level error codes are sufficient; however, for Web services testing, these error codes are inadequate. Testers must examine 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 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:
Testers can generate comprehensive design-time and run-time 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.
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.