Better Software - March 2008 - (Page 30)

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 perforFigure 10: WS-I Basic Profile run-time compliance violation results mance testing, HTTP codes, SOAP faults, and business-specific data in the Testers can generate comprehensive design-time and runSOAP message all may need to be considered to identify fail/ time interoperability reports and collaborate with Web services pass ratios. developments in pinpointing interoperability problem areas and recommended remediation strategies. Such collaboration Interoperability Testing Interoperability is the third pillar of Web services testing. nurtures interoperable Web services that can integrate with Web services specifications are broad and often vague, and applications independent of platform, operating system, and the degree to which technology vendors follow these stan- programming language. dards varies significantly. To establish a tighter control around standards implementation, the Web Services Interoperability Interoperability Testing Caveats Design-time interoperability testing tools and plug-ins are Organization (WS-I) has established a set of profiles. When followed, these profiles (Basic Profile, Basic Security Profile, standard in development environments. For development and Reliable Secure Profile) enable Web services products to teams that make such design-time testing part of their developinteroperate seamlessly. Adhering to WS-I profiles ensures ment process, the Web service WSDLs that they produce will be that Web services are interoperable and that WSDL can work interoperable. That means that other diverse consumers (client within heterogeneous .NET and Java environments. When a applications) can parse and consume such WSDLs. It does not, WSDL is given to testers, it is imperative that they evaluate however, assure that the Web service itself is honoring WS-I both design-time and run-time interoperability characteristics interoperability rules at run time. Although the WSDL for the of the Web services. Both can be evaluated by SOA tools such Web service may be interoperable, the Web service itself may not be. Ensuring both design- and run-time interoperability is as SOAPSonar as follows: 1. For design time WS-I Basic Profile interoperability test- paramount in realizing the benefits of reusability—the cornering, switch to QA Mode as shown in figure 9. Select the stone of a service-oriented architecture. Documents item under the Configuration folder in the left navigation panel. Select the Interactive WS-I tab and CONCLUSION In this article, you have learned how to build a simple Web press the Analyze button to run WS-I Basic Profile tests. The design time tests show that the WSDL generated service and how to test it using the three pillars of Web services from .NET WebMatrix is WS-I Basic Profile compliant testing—functional, performance, and interoperability tests. The promise of Web service-based SOA success lies in reuswith zero violations. 2. Design-time WSDL interoperability testing is not enough. ability across distributed environments. The ease of developRun-time interoperability testing is also necessary. Test- ing Web services puts a significant burden on SOA testers to ing the interoperability of a Web service requires creat- ensure that Web services are robust, reliable, secure, and scaling specialized test suites for a WSDL. These tests ensure able. Through collaboration with development teams, a growthat the target Web services are interoperable by actively ing understanding of Web services technologies, and compresending specialized requests to the Web services and de- hensive Web services-testing tools, testers can ensure that the termining whether the Web service responds per WS-I Web services being deployed within their SOA environments profile specification. To set up run-time WS-I interoper- function as expected, scale with growing demand, and are inability testing, simply switch to Compliance Mode and teroperable among a diverse population of applications. {end} from Run View press the Run Suite button to execute Sticky run-time interoperability testing. After completing the Notes test run, a detailed report is available in Report View For more on the following topic go to and provides interoperability compliance violation dewww.StickyMinds.com/bettersoftware. tails with severity levels as shown in figure 10. n Refresher tutorials 30 BETTER SOFTWARE MARCH 2008 www.StickyMinds.com http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.