Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Testing Web Services
Ensuring functionality, security, and interoperability

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.
For example, to send a secure SOAP message a client would use WS-Security to create a SOAP security header that contains security evidence from the appropriate token, and then sign and encrypt parts of the message to assure integrity and confidentiality. By following the standards set forth by WS-Security, developers can create a more secure and reliable Web service, protecting the integrity and confidentiality of a message while also authenticating the sender.

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.

About Adam Kolawa
Adam Kolawa is the co-founder and CEO of Parasoft, leading provider of solutions and services that deliver quality as a continuous process throughout the SDLC. In 1983, he came to the United States from Poland to pursue his PhD. In 1987, he and a group of fellow graduate students founded Parasoft to create value-added products that could significantly improve the software development process. Adam's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. As a result, he has orchestrated the development of numerous successful commercial software products to meet growing industry needs to improve software quality - often before the trends have been widely accepted. Adam has been granted 10 patents for the technologies behind these innovative products.

Kolawa, co-author of Bulletproofing Web Applications (Hungry Minds 2001), has contributed to and written over 100 commentary pieces and technical articles for publications including The Wall Street Journal, Java Developer's Journal, SOA World Magazine, AJAXWorld Magazine; he has also authored numerous scientific papers on physics and parallel processing. His recent media engagements include CNN, CNBC, BBC, and NPR. Additionally he has presented on software quality, trends and development issues at various industry conferences. Kolawa holds a Ph.D. in theoretical physics from the California Institute of Technology. In 2001, Kolawa was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

SOA World Latest Stories
When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand usin...
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and sy...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portabil...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder an...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
Most Read This Week
ADS BY GOOGLE