Web Service Testing

The great advantage of Web services is that they empower different types of entities to communicate with one another through platform-independent protocols such as SOAP, XML, and HTTP. However, the tradeoff for this flexibility is that this open, non-native traffic brings with it additional overhead. Take, for example, an enterprise that wants to use a Web service to integrate a J2EE application with a variety of client types or other applications

In this situation, many different types of clients can now access the information contained within the EJBs by going through the Web service layer. But this introduces a potential issue: a new layer of communication has been added with its own overhead and potential for failure into an application whose quality and performance was formerly under control. If the Web service layer makes the application slower or introduces quality issues it could affect application service-levels and negatively impact end users. The only way to ensure that this doesn’t happen is to test the quality and performance of these Web Services before they are deployed.

Web Services are applications that exist within a network. Since web services are being used more and more by businesses, security and testing are essential to web services. Testing ensures that SOA deployments can be reliable and successful for an enterprise. However, there are many gray areas that often occur during testing. To avoid these gray areas it is important to focus on performance, security, SOAP attachments, WSDL, and interoperability.

At a very basic level, one needs to consider how the remote method calls take place via SOAP, how the data is passed, how to test the transport layer, discovery methods, response data, scalability, performance, integrity etc.Testing Approach: Test Case Design, Test Execution shall be Top-Down and Bottom-Up respectively. Documenting test cases for the individual services can be a tedious task and subject matter experts can take part in unit testing the individual service so that they are error-free in the downstream process. This approach facilitates meeting the high-level business requirements and can also be used to create the data contents for the exchanged message. This will avoid the major pitfall of delivering a technically acceptable solution which fails to deliver business value. Once this is done, the data must be formatted into messages (XML) that express service request and replies from consumer and provider respectively.

Test tools must be used before and after publishing a web service. To do this, the WSDL must be loaded into the tool. The tool then acts as a client of the web service and sends SOAP requests. This describes a simple consumer-producer test scenario. Since web services depend on other services, the whole chain must be tested in order to find the problems. If a web service is not performing correctly, it may be due to another web service which it is attached to. This is easy to find if one simply monitors the CPU and memory statistics of each web service as the test transaction occurs. Many performance characteristics must be looked at such as response times and fail/pass ratios.

Security validation is also very important to evaluate when testing web services. This must be taken care of at the message level by using tools such as signatures and encryption. Test cases are also important to look at since a negative test case shows where the web service is inefficient.

SOAP is used to carry complex attachments through a network. These transmissions must also be evaluated to ensure that the attachment is not corrupted. To test a SOAP attachment, one can simply make sure that the upload and download values match and re-calculate the check-sum. The break point for message size must also be figured out.

WSDL acts as an important contract between the consumer and producer. However, this also provides gray area in web services testing since it is often not accessible through a firewall after handled by a partner. To avoid this dilemma, it is important to flatten the WSDL before handing it over to a trading partner. WSDL quality must also be identified.

Web Services Process Flow


A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used. Service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service. Part of the WSDL provided by the service provider is passed to the service consumer and this tells the service consumer what the requests and responses are for the service provider.

Web Services

A Web service is a method of communication between two electronic devices over a network.
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically Web Services Description Language WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

The W3C also states, "We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.

Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

The full-function web services platform can be thought of as XML, HTTP, SOAP, WSDL and UDDI. At higher levels, one might also add technologies such as XAML, XLANG, XKMS, and XFS -- services that are not universally accepted as mandatory.

SOAP (Simple Object Access Protocol) is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol.

UDDI (Universal Description, Discovery and Integration Service) provides a mechanism for clients to dynamically find other web services. Using a UDDI interface, businesses can dynamically connect to services provided by external business partners. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business applications.

Web Services Description Language (WSDL) is a new specification to describe networked XML-based services. It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as Simple Object Access Protocol or XML) or encoding (such as Multipurpose Internet Messaging Extensions). WSDL is a key part of the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business.

SOA Testing Challanges

When it comes to testing SOA applications, one has to look beyond functionality and performance (load) testing. SOA testing requires testing of interfaces and services that might bring together diverse systems and platforms, along with other performance (latency) and security related aspects.
One of the other challenges to be tackled in SOA Testing is the availability of the environment with the dependent underlying services and/or applications. For instance, an SOA Implementation might bring together two or more autonomous internal applications/services when composing a business process.
The availability of these internal applications/services becomes highly important during integration testing in parts as well as during end-to-end testing of the business process.
Some of the SOA Testing challenges are:
• Services that do not have a user interface
• Data driven business logic within services
• External services to the organization
• The quality of 'service' software will be vital to promote reuse and facilitate business agility. Services that have known bugs and quality issues will not be reused by the development teams. A significant increase in testing activities and test assets (functional, performance and security regression suites that include sophisticated harnesses and stubs) will be required at a service (program) level
• Predicting the future usage of services to assist with performance, load, stress, scalability
• As your SOA evolves, security testing will have a higher priority and profile within your organizations test strategy
Additional considerations:
• In SOA, Services are based on heterogeneous technologies. The ability to string together multiple types of components to form a business process requires unconstrained thinking from an architect's perspective, and test planning and scheduling complexities from a tester's perspective.
• In SOA, application logic is in the middle-tier, operating within numerous technologies, residing outside the department, or even outside the company.
• To test SOA, you need to go far beyond merely testing a user interface or browser screen. Web Services (WSDL/SOAP) will be an important component for many SOAs, but if you're only testing Web Services, you are not likely to test the entire technology stack that makes up the application. What are the transactions happening at the messaging layer? Is the right entry being reflected in the database?