When investigating SOA technology, expect to get pitches for SOA-specific testing tools. Traditional testing involves working with a complete application, but because SOA services can be used in multiple combinations both now and in the future, there is no clear end state to test against. “And there are more hidden dependencies in SOA,” says analyst Manes.

That's why testing needs to be handled differently. For example, TD Ameritrade’s Neal Ruskin advises testing results and inputs one level upstream and one level downstream in the process stream where the service is expected to live. And because services typically interact with each other directly, rather than surfacing in some GUI like a conventional application, testing must be done at a different level. “You can’t have a bunch of people running the application on their screens,” observes Ruskin.

Instead, you need to develop test cases that you run each time you change the service or compose an application with it. “You need to change test processes from ‘build and then test’ to ‘build and test continually,’” Ruskin says. This means that services must be designed to take responsibility for themselves, to check the inputs and outputs at runtime to identify potential errors and avoid propagating them through a process.

But this does not require SOA-specific tools, notes Unisys’s Young. “If you have traceability, I’m not sure how it’s different from component architecture testing,” she says. But because most companies don’t actually test in this structured way, they may not have the right testing tools in place, whether they are developing for SOA or traditional architectures, Ruskin notes.

The complexity of service monitoring and change management can seem a little overwhelming as your SOA scales. But remember: as long as the service interfaces remain unchanged, you should be able to fix or improve services without breaking anything. That, after all, is part of the beauty of SOA.

Back to intro