Testing Service-Oriented Architectures: A Primer for the Real World
Along with the benefits of an interconnected system come spiraling costs if the system runs out of control. When undertaking SOA, testing is a necessary form of risk-management — and Matt Heusser describes how to do it well.
Thu, July 31, 2008
CIO — How to test service-oriented architectures is no idle question. A failure in a SOA system at Heathrow Airport's $8.6 Billion Terminal 5 caused 1.6 British Pounds (about 3.2 million U.S. dollars) of losses in one week. The error? Simply that a filter put in to ensure that the baggage handler was tested in isolation was never removed—so event messages were never passed on to other, dependent systems.
That error was pure functionality; we haven't even begun to cover orchestration, security, load or performance. In this article, I cover some of the fundamental issues with testing service-oriented architectures, expand on risks and strategies, and close with a few personal lessons learned.
So, What are We Testing?
Please allow me to introduce you to Stoic Financial Services, or SFS, as an example. Until recently, SFS was restricted to credit cards, but has decided to grow through acquisition to cover the entire financial services sector. That means that SFS will sell mortgages, insurance, investment and retirement services. When it acquires a new company, SFS will want new customer information, sales leads and account and financial information to flow into its corporate HQ system, while keeping the old system running.
Each proprietary system will be 'wrapped' in Web service capability in order to integrate these systems without re-writing them. When a change occurs on any system, the Web service will capture that change and notify the company's Enterprise Service Bus, or ESB. The ESB is responsible for communicating that change throughout the company.
What this means is that when a new customer purchases an insurance product in Schenectady, New York, the local sales office is notified, the other business units are notified of a new sales lead and the financial system records the transaction. Automatically.
But how do you test this capability?
Layers and Layers of Transactions
The new customer example above is a complex example—and that's by design. Instead of one transaction, we have a half-dozen. Ideally, all of these will track back to use cases in requirements, but, remember, SFS is going to grow through acquisition. That means that the companies it acquires will have legacy systems in place that may predate use cases or any modern programming techniques.
Somehow, somewhere, someone at the acquired company will know how to make maintenance changes, so they will know how to do traditional testing for each system in isolation. Out of those test cases, we will extract cases where we want to interact with other components and our system test plan will come out of that work.
