|
1. Introduction
'To SOA or not to SOA' is not the question anymore. It is 'When to SOA?' With the maturity in SOA Implementations and realization of the associated benefits and challenges, increasingly Enterprises are including SOA Adoption in their Road Map.
Service-Oriented Architecture, or SOA, enables IT departments to make the transition from an application-centric view of the world to a process-centric view. Today, IT departments have the freedom to combine business services from multiple applications to deliver true end-to-end support for business processes. And, because the integration mechanism of SOA (usually Web Services) enables loosely coupled integration, IT departments can upgrade or change applications without impacting other applications.
Though SOA is being increasingly implemented both as green field (top down) and legacy modernization (bottom up), there is a clear lack of testing methodologies designed specifically for SOA applications. New approaches and methodologies are necessary to verify and validate applications based on SOA concepts.
Why is SOA testing different? The answer has many dimensions, but the bottom line is agility and flexibility. Yes, what makes SOA a very attractive, business friendly IT paradigm is the same reason why a different testing approach is required in SOA Implementations.
When it comes to testing SOA applications, one has to look beyond functionality and performance (load) testing. SOA testing requires testing of interfaces and services that might bring together diverse systems and platforms, along with other performance (latency) and security related aspects.
One of the other challenges to be tackled in SOA Testing is the availability of the environment with the dependent underlying services and/or applications. For instance, an SOA Implementation might bring together two or more autonomous internal applications/services when composing a business process. The availability of these internal applications/services becomes highly important during integration testing in parts as well as during end-to-end testing of the business process.
Starting with a brief introduction to SOA, this paper outlines an approach to testing a SOA Implementation in an effective and reliable manner. The paper further describes the various testing categories, suggested test strategy and an introduction to the available tools in the market that can be used to complement the overall Testing Approach.
1.1 Service-Oriented Architecture Overview
1.1.1 What is SOA
A concise functional definition is provided below:
Oasis (www.oasis-open.org) defines SOA as -- "An architectural style whose goal is to achieve loose coupling among interacting software agents / services."
Arasanjani, Borges and Holley define SOA as follows:
"SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions."
1.1.2 SOA Benefits & Implementation Principles
SOA provides benefits in four basic categories: l reducing integration expense l increasing asset reuse l increasing business agility l reduction of business risk
These four core benefits actually offer return at many different levels and parts of the organization, depending on the set of business problems the company is applying SOA to.
How should companies calculate the expected returns that tangible benefits provide the organization? Only by understanding the full range of SOA value propositions, can companies begin to get a hand on calculating the ROI on SOA. Even then, it may not be possible to understand SOA's true ROI before the project is complete, because SOA addresses issues of fundamentally unpredictable business changes.
The following key principles are recommended when implementing SOA:
- Document the Business Processes. Be it bottom up or top down, availability of these Business Process documentation is critical in delivering SOA in its true self instead of say, Web Services based applications
- SOA Implementation is an evolution - start with a pilot, deliver business value and incrementally add on
- The SOA Implementation must be based on loosely coupled services that provide the highest flexibility and ongoing cost reduction due to reuse and lower maintenance
- The services should have standards compliant interfaces to enable seamless integration and interoperability with other services
- The business drives the services, and the services drive the technology
- Business agility is a fundamental to SOA
|