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.