XML, SOAP, REST Testing for SOA and Cloud Computing

SOA Testing

Subscribe to SOA Testing: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Testing: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA Testing Authors: Mamoon Yunus, John Savageau, Tim Hinds, SOASTA Blog, Hervé Servy

Related Topics: SOA & WOA Magazine, SOA Testing

SOA & WOA: Article

Testing SOA Solutions

What's different and how to handle it

Service Oriented Architecture (SOA) has been discussed as an important architectural style for the last few years. Organizations have started to develop service-oriented solutions and many are now leveraging services in their production environments.

SOA introduces new technical complexities and challenges and makes testing a critical component of the development lifecycle. Teams need to think about:

  • How do you know if the solution is ready?
  • How do you know that it will scale to accommodate future needs?
  • How do you know that you can actually get the business flexibility that SOA promises?
These are all questions testing should answer, but many test teams aren't experienced yet in testing service-oriented solutions.

This article contains a set of recommendations, with a rationale, that will help you to mitigate the issues that arise in testing an SOA solution. The recommendations are based on experience gained over the last three years through involvement in a number of SOA projects.

The recommendations form the main part of the article, but first we'll provide an overview of what SOA is and what challenges the test team must consider.

SOA Solutions
To think about testing SOA solutions, it's important to start with a clear idea of how a SOA solution is constructed. This is illustrated in the Figure 1, which is taken from the SOA reference architecture developed by IBM and used by The Open Group as the basis for an open standard SOA reference architecture.

Typically, a SOA solution consists of a set of services that are orchestrated into business processes using capabilities provided by middleware. Each service may be composed of other services or may be atomic.

The services are invoked by service consumers such as portlets in a portal or external applications in a business to business (B2B) solution. The individual services are likely to be called in some ordered sequence, probably involving decisions (branching) and going back to previous steps (looping), with a good chance that there will be times when handing a task to a person and then waiting for a result is required.

Services are actually facades for underlying IT assets, which may be part of existing (pre-SOA) operational systems, or may be specially created service components. These components provide the implementation or "realization" for the services, and may be newly created or may provide access to capabilities of existing operational systems. (It's often better to insert these service components between the services and the existing systems than to access the existing systems from the services directly.)

Besides the services and their implementations, an SOA solution also contains functionality relating to service and component integration, quality of service, information management, and governance.

Testing SOA Solutions
The goals of testing remain the same as for non-SOA solutions, but SOA testing requires that testers add to their skills. It also requires changes to how testers approach testing and what tools are used. There are a number of characteristics of SOA solutions that affect the nature of testing, at all levels. Besides the traditional levels of unit test, integration test, etc., SOA testing requires testing at two new levels we've not previously had to think about:

  • Testing of services, the facades in front of provider components.
  • Testing of orchestrated processes, invoking many services.

    What else is special about testing service-oriented solutions? Here are the main characteristics that make testing different for SOA:

  • Services can be independently developed, changed frequently, intended to be reusable but must still work together to provide the total solution. A service may have been unit-tested and work on its own but, when it's added to the larger system, its interaction with other components poses additional integration testing challenges.
  • Services can be "GUI-less" and testers require a mechanism to invoke and test the service without a traditional user interface.
  • Services can be implemented using different technologies, which provide performance challenges.
  • Packaged services can provide unique challenges since they've been created by a third party, and the team doesn't have total control over the design or implementation.
  • Due to the way a SOA solution is composed from various services, meeting quality of service requirements and problem determination require special consideration.
  • Because multiple services on heterogeneous platforms must work together, standards become critical.
  • SOA testers must have knowledge of multiple standards and technologies.
  • Many more combinations of use of services will be possible than the team can test. Assuming finite resources, resource/test coverage decisions have to be made. Risk-managed testing should be used.
  • Since services are also intended to be discoverable, they are likely to be used in processes and by service consumers not contemplated when the service was originally designed. Hence the service must be fully encapsulated and do no more or less than advertised.
  • Performance characteristics must be carefully considered. If a service was originally designed for 100 invocations a second, with an initial load of 10 invocations a second, what happens when other consumers discover and try to use the service? In particular, when the load exceeds the design goal, is there a mechanism for managing the overload gracefully?
  • Service providers are likely to have their own security models, with different rules for access and use. The test manager must decide how to confirm that only appropriate access to the services underlying a given business process is handled.
Each of these aspects exists in software systems today posing a significant challenge to test teams. What makes SOA unique is both the degree to which they exist and the challenge in dealing with all of these features in most, if not all, SOA projects. The recommendations are on the following page.

The Recommendations
Leveraging experience in a number of SOA projects done over the last three years, we have developed a number of suggestions for the SOA test team. These suggestions aren't intended to replace good test design, development, and execution. Instead, they're intended to supplement what the test team would be doing in any other large complex project. The recommendations are in  Table 1.

Conclusion
We hope that we've demonstrated some important issues in SOA testing, highlighting areas where testing SOA solutions bring new challenges. We also hope that our recommendations provide useful guidance for you if you are testing a service-oriented solution for the first time. We would welcome your feedback on this article and your suggestions for improving the recommendations for SOA testing.

References
•  Bryson, Brian et al. "Spotlight on IBM software solutions: Quality management for Web services-based applications."
www.ibm.com/developerworks/podcast/spotlight/st-071707txt.html.
•  IBM SOA Testing Forum.
Please Click Here !.
•  Linthicum, David S. "Adjusting Testing for SOA."
www.sdtimes.com/article/special-20070815-01.html.
•  Rose, Laura et al. "Software Testing in SOA." Internally available within IBM.
•  SOA Testing Blog. http://soa-testing.blogspot.com/
•  Joines, Stacy. "SOA Performance Best Practices."
Please Click Here !

Acknowledgements
This article owes a debt to important work by multiple IBM teams:
- SOA Design Center in Beijing
- Quality Software Engineering, within the IBM Software Group
- IBM Research's testing efforts
- IBM SOA Advanced Technology Quality & Risk Management Team.

More Stories By Tony Carrato

Tony Carrato is the worldwide chief operations architect for the SOA Advanced Technology team in IBM's Software Group, focusing on SOA delivery. In this role, he is responsible for a team of IT architects who help IBM clients define and implement SOA projects around the world. Tony has over 30 years of IT experience, concentrating in financial services and telecommunications. He has held a variety of senior technical positions in Australia, Hong Kong, and the U.S.

More Stories By Chris Harding

Dr. Chris Harding leads the SOA Working Group at The Open Group - an open forum of customers and suppliers of IT products and services. In addition, he is a director of the UDEF Forum and manages The Open Group?s work on semantic interoperability. He has been with The Open Group for over 10 years. Dr. Harding began his career in communications software research and development. He then spent nine years as a consultant, specializing in voice and data communications, before moving to his current role. Recognizing the importance of giving enterprises quality information at the point of use, he sees information interoperability as the next major challenge, and frequently speaks or writes on this topic. Dr. Harding has a PhD in mathematical logic, and is a member of the British Computer Society (BCS) and of the Institute of Electrical and Electronics Engineers (IEEE).

More Stories By Chuck Shriver

Chuck Shriver is a test architect for the SOA Advanced Technology team in IBM's Software Group, focusing on SOA test strategy. In this role, he works with a variety of organizations within IBM who help IBM clients implement SOA projects. Chuck has 19 years of IT experience, concentrating in software testing. His experience also includes software application development and beta program coordination.

More Stories By Ruo Bo Huang

Ruo Bo Huang is advisory software development manager for the China SOA Design Center of China Software Development Lab in IBM's Software Group, focusing on SOA tooling development and delivery. In this role, he is responsible for leading team engagement into SOA solutions and then using the experience/feedback from the field to enhance IBM products.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Kim Miller 11/06/07 07:16:15 PM EST

Hmmm....where is table 1??