Testing service-oriented architectures: A primer

How to test service-oriented architectures is no idle question. A failure in a SOA system at Heathrow Airport's US$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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine