As service-oriented architecture (SOA) adoption continues apace, Peter Cole, CTO of integration specialists Green Hat, argues that it's vital not to overlook the importance of testing and that developers need to look beyond in-house built test solutions. 

The promised benefits of SOA-based deployments have dominated the IT agenda in recent months with companies as diverse as the Met Office and the BBC announcing they are laying the foundations for the standards-based framework.

Certainly, the ever-expanding capabilities of the SOA framework - offering a common way for services to communicate with each other - looks set to revolutionize enterprise architecture. Yet only by implementing a comprehensive testing process can companies ensure their SOA is robust and secure enough to form the basis of their IT infrastructure.

What are the options for testers? While SOA, from an architect's perspective, offers huge advantages in terms of operability, flexibility and functionality, for the tester it could spell significant challenges.

By definition, SOA projects will always require a testing tool as there is no human interaction with the different components; encoded messages will interface with other applications but not with end users.

The alternatives are to build a testing solution for SOA in-house or to purchase one. Traditionally, SOA testing has been developed in-house; which begs the question why are developers spending valuable time on developing new code for testing when a product can be purchased?

The burden on developers to create and maintain another deliverable with another group of users simply adds to the task.

For developers weighed down by heavy schedules, writing code for testers, or an ad hoc program, is likely to come at the end of process, which contributes further delays to the project.

And, as the number of services grows and more development is carried out, the risk for companies heightens; if a developer leaves an organization they take the knowledge with them.

Moreover, if a development team is devoting time to creating new pieces of code then they are being taken away from adding value to the business.

A structured approach to design, development and testing is obviously a necessity if teams are to avoid expensive changes once development is under way. With traditional development, developers often create their own tests, which is fine as they tend to be the users of the code they create.

With SOA, however, consumers of services will often be developed by other people, other teams or even other organizations. If a developer writes their own tests here, systematic errors can be introduced which will de-rail integration efforts when the project reaches that stage.

In the past, commercial testing tools have been limited to testing GUIs, or helping to test low-level code. The good news is that independent products are now available which test both sides of the interface and can help to eliminate these types of costly problem.
 
However, it would seem, that the majority of teams are not aware that a cost-effective, commercial solution exists for their problem.

In fact, a recent survey of senior IT professionals revealed that only 30 per cent are aware of the availability of specialist testing tools yet as many as 90 per cent claimed that inadequate testing is a major impediment to successful delivery of SOA projects.

The latest software that has emerged on the market heralds the beginning of a new era in testing. Before the arrival of specialist products, testers had to wait until all services were finished to test the interactions between messages but the new software allows users to test a service in isolation which prevents problems when integrating and savings valuable time.

These tools have been created using real experiences from real automation projects with the key aim of eliminating nasty surprises at integration time and not only significantly reduce implementation time but also enable developers to concentrate on their core function: solving real business issues. 

In terms of usability, time savings and practicality a specialist tool will far outweigh an in-house developed solution: for example, in-house development often lacks graphical user interfaces (GUIs) and certainly cannot offer the usability and rich GUI features of a commercial product; in-house developed tools are unlikely to copy-and-paste, drag and drop.

An additional problem with in-house development is that the same team that develops the testing tool also develops the code to be tested, with the result that features in the testing tool can lag behind those required by the testers, introducing further project delays. And this can translate to spiralling costs. 

There are other drawbacks; in-house development is likely to be vendor specific. The new breed of specialist SOA software can test many vendors' systems, allowing your testing team to develop a standard set of skills to test different systems.

Notwithstanding, there are several considerations when making the switch from an in-house product to a commercial one. There may be a migration and education issue from the existing in-house tool to the commercial one, however the use of XML, or clever migration aids, such as regression wizards, can help in this area if there are a large number of tests to be converted.

It's also vital to choose a suitable time to adopt a new solution. Mostly, this will be when going through a technology change for example when adopting a JMS implementation from an old middleware solution, or when embarking on a new phase of a project

Get the timing right, though, and the results of a bought solution will pay dividends in the short and long term.

So as we rush forward into an era of more widespread adoption of SOA, IT managers, CIOs, and developers should consider the benefits of specialist testing tools to save costs, reduce time and ensure SOA delivers on its promise.

Peter Cole is CTO of Green Hat, providers of the industry-leading specialist testing software for integration and SOA.

This article first appeared on the BCS website in November 2006.