Current trends show that the vast majority of companies are moving to services-oriented architectures (SOAs) and deploying Web services within and across their IT infrastructure. However, the success of those deployments is determined by the integrations and innovations that Web services make possible and how Web services affect the quality and performance of the mission-critical applications with which they interface. As such, it is crucial to thoroughly test Web services before they are deployed in order to ensure service level compliance in production.
Ensuring Web Service Quality for
Service-Oriented Architectures An Oracle White Paper June 2008
Ensuring Web Service Quality for Service-Oriented Architectures
WEB SERVICES OFFER NEW OPPORTUNITIES AND NEW CHALLENGES Web services hold the promise of integrating software applications from heterogeneous networks and exchanging information in a simple, standardized manner. Current trends show that the vast majority of companies are moving to services-oriented architectures (SOAs) and deploying Web services within and across their IT infrastructure. However, the success of those deployments is determined not only by the integrations and innovations that Web services make possible, but also by how Web services affect the quality and performance of the mission-critical applications with which they interface. As such, it is crucial to thoroughly test Web services before they are deployed in order to ensure service level compliance in production. This white paper discusses the testing challenges presented by Web services, and introduces best practices to ensure SOA application quality through the use of Oracle's award-winning Web service testing solution, Oracle Application Testing Suite.
WHY WEB SERVICES MUST BE TESTED The great advantage of Web services is that they empower different types of Once Web services are inserted as another entities to communicate with one another through platform-independent protocols layer in enterprise software, the likelihood of application slowdowns and functionality such as SOAP, XML, and HTTP. However, the tradeoff for this flexibility is that failures increase. It is therefore critical that this open, non-native traffic brings with it additional overhead. Take, for example, Web services are tested before they are an enterprise that wants to use a Web service to integrate an Enterprise Java deployed. Beans-based (EJB) application with a variety of client types or other applications. Figure 1 shows how a Web service could be implemented to meet this business requirement.
Ensuring Web Service Quality for Service-Oriented Architectures Page 2 Figure 1: Using Web services to give access to information contained within the EJB In this situation, many different types of clients can now access the information contained within the EJB 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.
ENCOUNTERING CHALLENGES WHEN TESTING WEB SERVICES Let's begin by discussing the requirements for testing Web services. The following Oracle incorporated the industry's first types of tests must be run against each Web service to ensure that it is ready to be automated Web services testing technology into Oracle Application Testing deployed: Suite, eliminating the problems associated . The Web service must work functionally (correctly) for a single request, with traditional test automation tools. and always return the correct information in response to a request. . The Web service must provide information within a reasonable amount of time, scaling or performing well in relation to the number of simultaneous requests. . The Web service must not crash in response to an anticipated (or even unanticipated) maximum number of simultaneous requests. Testing Web services presents a unique challenge since, by definition, Web services themselves have no inherent user interface (UI). Traditional automated testing solutions rely on recording end-user transactions to create automated test scripts, which can be used for functional testing or in the case of load testing tools, be scaled up across hundreds or thousands of virtual users for performance testing. Without a UI, Web services testers have either foregone testing entirely or relied on manual testing for functionality and built performance test harnesses from scratch. Writing software to test Web services or relying on redundant manual testing is an inefficient use of quality assurance (QA) resources. H... [download for more]
