As more enterprises move toward an e-business strategy, the communication and integration of disparate, heterogeneous applications and systems is key. Businesses must be able to securely connect and communicate with customers and trading partners alike.

Using Web services, different businesses and customers can communicate by exchanging information through platform-independent protocols such as SOAP, XML, and HTTP.

However, the flexibility of Web services can prove to be a double-edged sword. While Web services allow businesses to connect to partners and customers, this same flexibility and connectivity provide increased opportunities for errors. Web services are complex systems that attempt to marry software, hardware, new code, legacy code, existing systems, systems in development, and who-knows-what on the client side. There are countless opportunities for things to go wrong - a slight mistake in any component or interface will cause problems that ripple throughout the system (see Figure 1).

 

Therefore testing, which is important for any software application, is even more crucial for Web services. As companies and consumers rely more on Web services, the importance of quality and reliability will continue to increase, thereby increasing the importance of Web services testing. This article explains the general testing practices required to ensure complete Web service functionality, interoperability, and security.

Server Functional Testing
Server functional testing is usually the first step in testing any Web service - be it a consumer-based Web service where thousands or even millions of clients can send requests to a large commercial server, or a B2B Web ser-vice in which business partners exchange information through common servers. In any case, if the server does not work correctly, its performance, security, interoperability, and so on, are essentially irrelevant. The goal of server functional testing, therefore, is to ensure that the server delivers the expected responses for any of a wide range of request types and parameters.

The simplest possible functional test involves sending a request and checking whether the server returns a response or an error message. The response can be analyzed either by inspection or by running the response through a tool or script that verifies conformance to a specification. The analysis can be as simple as performing a text comparison with the expected response, or as complex as extracting specific information from an XML document and performing application-specific checks. For example, if you have a Web service that handles bank transactions, you can perform a server functional test by sending a valid request (such as a transfer of money) to the server. You can then verify whether a response or an error message is returned from the server.

However, because of the complex nature of Web services, testing a server's functionality may be far from simple. With most Web services it is impossible to anticipate exactly what types of requests clients will send. Traffic may occur with extreme highs and lows, with users accessing the service using a variety of clients, connections, and platforms. With so many differing clients accessing a single Web service, the server is bound to encounter unexpected requests either as a result of mistakes (such as a bad WSDL) or from attempts to breach service security (hackers sometimes trick applications into behaving unexpectedly by sending it invalid inputs).

An effective way to prevent errors caused by unexpected inputs is to perform what some refer to as "monkey testing" - throwing the proverbial wrench into the Web services works by sending the service requests with illegal and/or unexpected parameters, then verifying the response with assertions, custom code, or other tool-specific verification methods. For example, how will the server react if a customer attempts to transfer more money than is available? Will it return a proper message to the client? Will it allow the transaction? Or will the server just crash and die?

By checking for the conditions and inputs that are not expected, you enable more thorough tests for what cannot be foreseen. By performing such testing at the unit and application level, you can quickly and easily identify and correct any weaknesses before security breaches can occur. Therefore, it is important to verify whether the server can handle a wide range of request types and parameters. In order to test the server functionality of a Web ser-vice, you must be able to emulate many of the types of clients that might access the server, and verify that the server will behave as expected in relation to any type of client request.

Regression Testing
After you have verified the server's functionality, you can rerun your functional tests as regression tests. Regression testing is the process of running all existing test cases and verifying that all test cases pass. The purpose of regression testing is to detect unexpected faults - especially those faults that occur because a developer did not fully understand the internal code correlations when he or she modified or extended code that previously functioned correctly. Regression testing is the only reliable way to ensure that modifications did not introduce new errors into code or to check whether modifications successfully eliminated existing errors. Every time code is modified or used in a new environment, regression testing should be used to check the code's integrity. Ideally, you perform regression testing nightly (during automated nightly builds) to ensure that errors are detected and fixed as soon as possible.

Load Testing
After you have performed functional and regression testing on your server, you know that your Web service can handle at least one client. But can the server handle requests from 100, or even 1 million, clients? Since millions of clients can potentially have access to a Web service server, the server must be able to handle every request under extremely heavy load, or at best "fail gracefully." Therefore, the next step in the server testing process is load testing.

Load testing typically involves exercising your application with virtual users and measuring performance statistics to verify whether the application supports the anticipated traffic load as well as possible traffic surges, growth, and so on. To ensure that your virtual users' experiences effectively predict your actual users' experiences, you want your virtual users to simulate realistic scenarios. For example, the test could check functionality and response time under different degrees of load increases (sudden surges versus gradual ramp-ups) or different combinations of valid and invalid requests. If the load tests reveal unacceptable performance or function-ality under load, the next step is to diagnose and repair the source of the bottleneck.

When problems surface under a reasonable load, they typically indicate fundamental design problems such as algorithmic problems, inefficient database-application interaction, and so on - not infrastructure issues that can be resolved by upgrading hardware or fine-tuning system configuration. As a result, it is recommended that you begin load testing as early in the development process as possible. Ideally, you want to begin performing load testing on a staging server as soon as you can exercise any segment of the application. This way you can expose and resolve problems before they become more deeply embedded in the application and fixing them requires increased time and effort.

Client Testing
SOAP-client developers are responsible for ensuring that the client sends requests correctly. If a client sends invalid or improperly formed requests, the server usually cannot deliver the expected results. The process of testing clients is a little different from testing services because clients are the initiators of Web service interactions. This means that from a testing standpoint there are two main things to verify: whether the client can correctly initiate an interaction by sending a request, and whether the client behaves as expected when it receives a response.

The best way to test a particular client depends on the nature of the application. If the client accesses a server that can accept "test" requests without any harmful side effects, it can directly access the live server during testing. However, you may need to test client functionality by emulating server-supplied responses. Emulating the server is especially useful when the server is still being implemented, has bugs, or should not be accessed during testing. For example, if you have a live system that performs credit card processing, you will not be able to access the server without disrupting ongoing business transactions.

No matter what type of server a client accesses, the same general principle applies: the client sends a request, the server responds, then client success or failure is determined by recording and verifying the request and/or by verifying the server response. The same techniques and tools used to verify server functionality can be used for this purpose. However, server bugs could also be misleading: if the server is not operating correctly, correct client requests might result in incorrect responses, and incorrect requests might result in apparently correct responses. You can ensure that server functionality problems are not confusing your results by first verifying the request as well as the response, and then testing the simplest possible server implementations (server stubs) instead of - or in addition to - testing actual, complex servers.

After verifying that the client sends acceptable requests and can receive responses, you should shift your attention to testing exceptional cases. For example, test that the client behaves properly when the server goes offline by sending the response to an invalid URL. Or use server stubs to simulate the server sending the client invalid data.

 

Ensuring Web Service Interoperability and Security
Performing functional testing, load testing, and client testing will ensure that your Web service functions properly without error. However, as Web service development continues to mature, the issues of interoperability and security must also be addressed during the testing process. After all, interoperability is really the main reason to utilize Web services in the first place, since Web services allow for the integration of disparate entities. And because of the flexibility and connectivity provided by Web services, proper security measures must be taken as well to authenticate messages as well as prohibit outside parties from viewing private messages. Therefore, while being sure to practice the steps necessary for a Web service free of functional errors, developers must also practice the methods necessary to ensure interoperable and secure Web services.

Interoperability
The core technologies that comprise Web services (such as SOAP, WSDL, XML) are designed to ease interoperability and integration. However, the mere adoption of these technologies does not guarantee seamless interoperability. The main problem that developers face today is that they sometimes inadvertently introduce platform-specific features into the Web services that they develop. For example, a developer may expose only a Java solution without considering the effects on a .NET client.

Ideally, interoperability would be verified by checking that a service adheres to a comprehensive, universally implemented set of standards. With the recent announcement of Basic Profile 1.0 by the Web Services Interoperability (WS-I) organization, developers now have a set of standards to follow. Basic Profile 1.0 (BP 1.0) consists of implementation guidelines that define how core Web services specifications should be used together to develop interoperable Web services.

By restricting Web service development to technologies specified in WS-I Basic Profile 1.0, developers can increase the odds that their systems will interoperate with others' systems. In addition to BP 1.0, WS-I has also developed a set of test tools that automatically check conformance to BP 1.0. In the event of nonconformance, developers can pinpoint exactly what needs to be changed to ensure compliance to BP 1.0, and ultimately to ensure interoperability.

Security
Since Web services can be accessed across the open Internet, security risks become inherent in Web services development. Therefore, developers must know how to implement the proper security standards to ensure authentication, authorization, data integrity, data confidentiality, and proof of identity.

In addition to interoperability, WS-I has influence in Web services security as well with its WS-Security specification. The aim of this specification is to define the SOAP security headers and how they should be used. Developers should configure SOAP headers according to the following WS-Security specifications:

• Include security evidence from the client to the server through use of security tokens: Various tokens are available, each containing different types of security evidence in various formats to allow the target endpoint of the message to verify client identity. For example, the Username token contains the name of the initiating client and an optional password.
• Ensure that the message has not been modified through use of XML Signature: XML Signature is a standard that allows parts of an XML document to be digitally signed, thereby providing proof that the document has not been altered since the inclusion of the signature.
• Ensure that only the intended party can read the SOAP message through use of XML Encryption: XML Encryption is a standard that uses cryptography to encrypt the SOAP message to hide it from those not intended to view the message.

Conclusion
The future of e-business undoubtedly lies in Web services. Organizations building and developing Web services will do well by moving forward in this direction while avoiding the pitfalls that will inevitably arise with Web services development. Developers must ensure that each part of the system is reliable, and that all of these parts interact flawlessly and securely.

By integrating server functional testing, load testing, and client testing throughout the full Web services development life cycle, you can ensure that a Web service server works well with the possible types and volumes of client requests, and that a Web service client correctly accesses and retrieves whatever data a service has to offer. By following specifications such as Basic Profile 1.0, and WS-Security, you can be sure that your Web service is interoperable and secure.