Web Service Testing in a Service-Oriented Architecture
Web services form the topmost layer of a service oriented architecture (SOA) and expose the SOA capabilities to the customer. For the end user, the exposed web service is representative of the whole enterprise behind. So, the full array of SOA capabilities is rendered useless if the web service fails to perform at the expected level. In addition, the quality of the web service is often indicative of the health of the SOA as every major component can be related to the exposed web service. These are some of the reasons why web services need to be tested and monitored thoroughly and systematically in a SOA.
Aim of this Article
In this work, I shall discuss the various aspects of testing a web service in a service-oriented architecture. I shall stress upon the musts in testing the web service, the interoperability of web services, and quality of service and recovery in case of a service disruption. I shall conclude with mentioning some of the best practices in SOA.
SOA and Web Service Testing
Click here for a larger image.
Figure 1: Service Oriented Architecture
Service-oriented architecture adds value and exposure to the business at the cost of complexity. The interconnected implementation of a SOA is difficult to manage, with complexity increasing exponentially at the introduction of a single new service. Hence, the processes needed to develop, test, and operate a SOA need to be drastically different from the standard processes of software development. For example, in a SOA scenario where the services are interdependent, the contract of a service may need to be in place even before the underlying functionality is developed, thus emulating the real service. The conventional methodologies of 'design, develop, and then test' give way to more proactive and intuitive processes that implement testing at every stage of the lifecycle of a service.
The various aspects of testing a web service in SOA can be classified as the following:
* Interoperability
* Quality
* Recovery
Interoperability
Web services define a new architectural paradigm for software applications. A web service is defined as a loosely coupled standards-based software component exposed over the web for programmatic consumption. The various standards used are for XML, SOAP, WSDL, and UDDI.
Interoperability is the most important aspect of the distributed loosely coupled architecture of web services. To define a standard for interoperability, the Web Services Interoperability Organization (http://ws-i.org) has delivered ws-i basic profiles (version 1.0 is most widely used) that define a set of conformance rules. These rules comprise of the general specifications of XML, WSDL, SOAP, and UDDI and define how to use these technologies to describe, develop, and consume a web service. Ws-i basic profiles are now universally adopted by the industry as a standard measure for interoperability.
The web service must be tested for a ws-i basic profile. On the website, the Web Services Interoperability Organization exposes its own free testing tools for testing the implementation of a web service for conformance to basic profile.
The ws-i site for testing tools: http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools
Testing tool for J2EE web services: http://www.ws-i.org/Testing/Tools/2005/06/WSI_Test_Java_Final_1.1.zip
Quality
As the number of web services grows, chances are that many web services will compete with each other to provide the same type of functionality. In that case, one of the differentiating parameters between two such web services will be the quality of service. The various quality requirements from a web service in a SOA are given below:
1. Availability
The web service should be up and running within the stipulated hours. If the web service is meant to be used over the Internet, availability throughout 24 hours will increase the chances of the consumption of the service. High availability of the web service indicates that the SOA is scalable and robust.
2. Accuracy in functionality
The functionality exposed by the web service should be accurate. So, the underlying service in SOA should be thoroughly tested. Unit testing, as well as functionality testing, should be done on the service at an early stage of developing the SOA because later in the lifecycle, changing implementation in SOA is very difficult.
3. Accessibility
The web service should be able to handle a web service request and thus can be consumed by clients built on different platforms by different technologies such as J2EE, .NET, and so forth.
4. Reliability
Reliability of the web service is a measure of how well the service can maintain its quality over a sustained period of time. To ascertain the stability in the functional behavior, the web service needs to be monitored for regression while in production. Reliability is often measured in failures per day/month.
5. Seamless integration
Web services hide the complex mesh of services and layers in SOA and only expose the relevant functionality. To optimize the utilization of the capabilities of SOA, the seamless integration between various layers should be tested thoroughly. Integration is best tested by successfully implementing a real-world scenario by web service orchestration where various web services from the SOA can be involved. To avoid duplication of implementation effort as well as changing implementation, service emulation, as discussed earlier, is used to test the integration of the SOA from an early stage of development.
6. Performance under load
Performance of a web service is one of the most critical requirements for an enterprise. Performance is normally measured as how quickly the web service responds as the number of users is increased. If there is an unacceptable change in performance, the SOA needs to be investigated for performance bottlenecks that can exist anywhere, starting from the hardware.
The performance of a web service depends on the time required to access the web service as well as the time required to execute the functionality. One way to improve performance is to cache the web service results wherever possible.
7. Ease in discovering services
Visibility is one of the main concerns in SOA. The web service should be easily discoverable in the UDDI registry. In the UDDI, the web service is exposed as a business service that is associated with taxonomies, categories, keywords, and other search criteria. These search criteria should be chosen judiciously so that the service is readily found in an appropriate search.
8. Security
Web services interactions are often exposed to the Internet and can be corrupted. To counter this, the web services security specification (ws-security) provides a set of mechanisms to help developers secure SOAP message exchanges. These basic mechanisms can be used to build a wide variety of security models using different cryptographic technologies. Ws-security also provides a way of encoding and associating security tokens—such as username tokens and SAML tokens—with messages as well as helps preserving message integrity and confidentiality by XML signature and XML encryption respectively, along with security tokes.
The web service should be tested for compliance with ws-security standards as well as various common security loopholes like SQL injection, XML bombing, malformed or large XML, cross site scripting, and so forth.
Recovery
Before going into production, the web service should be tested for recovery from failure owing to any common cause such as an infrastructure failure, large traffic, and the like. First of all, a proper backup strategy should be in place. Ideally, the web service call should be automatically routed to an alternate endpoint while the actual web service is offline for maintenance. After the service is updated, the new information needs to be updated in the UDDI so that the applications that were consuming the service can get the latest binding information from the Registry.
Conclusion
You have seen the basics of web service testing in a SOA. Technologies around SOA and web services are fast evolving and yet to reach the maturity to be fully reliable and generic. Hence, the SOA developer should monitor the performance of the service at various points of the lifecycle and develop customized strategies and best practices for each SOA. Some of the common best practices are to have clear service level agreements for various quality aspects, to choose the appropriate XML parser judiciously and to use coarse grained web services where a lot of data can be retrieved in a single call.
References
* http://ws-i.org
* J2EE Web Services, by Richard Monson-Haefel
* Developing Enterprise Web Services, Sandeep Chatterjee and James Webber
