Making Progress in a pragmatic way

Building and testing SOA organically

One of the interesting messages that normally comes out of discussions about SOA is that it gives developers and architects the environment in which they can transform the traditional "IT silo" infrastructure that is the norm in most enterprises.

Yet according to Giles Nelson, director of technology for enterprise infrastructure products at Progress Software, pragmatic exploitation of that same silo approach may just be the way enterprises can make SOA happen for real.

"Many companies see SOA as a platform that can be bought – and some vendors do sell the technology that way," he said. "But SOA has to be an organic growth within a company, it does not work like a command economy where a single platform is decided upon from above."

Extrapolating onwards from the traditional silo approach means, in his view, that enterprises can think strategically but act tactically. This will allow them to start with a single project if necessary, the type of approach that can often win senior management buy-in without breaking the bank or risking the company.

"But they should also be thinking about the integration of that project with other possible projects, and the way they will need to interoperate," Nelson said. "This way many companies will end up realising they have an SOA-based environment only after having got there, rather than having tried to plan it round a pre-conceived platform."

This pragmatic approach to building SOA environments extends, in Nelson's view, to the way SOA services need to be tested. While he acknowledges that the pre-production testing of code – be that applications or components – is an important step in the development process, the reuse of applications and code implicit in SOA changes the way developers and architects need to set about testing the services that are provided.

His view, one that obviously justifies part of the reason Progress acquired Actional last year, is that the best way to test services that are made up of pre-tested applications and components is to instrument the production systems in a non-instrusive manner. "This allows you to monitor what is happening in the production system in real time, while at the same time implementing security policies separately from any other services."

This approach also offers the scope to manage one of the possible unknowns about SOA implementations. This is where developers and architects assume that, because a code component has passed pre-production testing, it will always work correctly in every re-combination of components they bring together to build a service. This, as Nelson acknowledged, could be a seriously misplaced assumption in the wrong circumstances.

"But with non-instrusive instrumentation it is then possible to allow developers to work to a 'reasonable rules' policy when building services," he said. "They can assume that a pre-tested function can be reused in new services, while accepting that it might not work, and that the monitoring instrumentation will trap any problem before it becomes serious." ®