Setting a new standard with SOA
The service oriented architecture industry is in desperate need of a set of reliable testing and monitoring standards, warns Peter Cole
As we embark on a new era of more widespread adoption of service oriented architecture (SOA), the industry now needs to work together to develop a common set of standards to enable testing and monitoring. Without these standards, I believe that SOA will not fulfil its core promise to provide customers with improved agility, functionality and flexibility.
Standards will bring benefits to all sides: resellers will have increased flexibility in terms of which vendors’ middleware solutions can be used. Standards will also bring improved reliability and help to prevent issues arising that could damage client-reseller relationships and the associated effects incurred on time and cost.
For example, interactive debugging, designing transports with testing in mind and run-time monitoring are currently all major issues which are often not part of the selection criteria for a platform. However, they are vital to the success of a project.
One of the problems in testing an SOA is identifying where a failure has occurred in a back-end process that has been started by a service invocation. We are driving forward proposals for vendors to provide a standardised debugging interface to allow this information to be incorporated into test reports. This will enable developers to get straight on with resolving the issue, without spending time on recreating it.
An additional benefit would be the ability to debug a process that executes across multiple process engines. This is a scenario that is likely to become increasingly common as companies create composite applications, uniting previously isolated areas of their business.
Many enterprise customers are using Java messaging service (JMS) as a transport medium for their simple object access protocol invocations internally. The biggest complaint we have had from these customers surrounds their ability to observe events between processes. Unfortunately, the current JMS standard contains no provision for this type of functionality. Customers are left to use functionality provided by their JMS vendor outside of the standard. This can be very much a hit and miss affair.
The largest software vendors are letting their customers down badly by omitting this type of functionality. Unfortunately, a technology decision has been made, contracts signed, and development begun, before the issue was uncovered.
To help resolve this customers are advised to add some points on testing to their technology selection criteria.
The biggest issue that customers face is that the major vendors will say that testing is unnecessary as developers will do this as they go along. A telecommunications company, for instance, that wants to roll out a new service to customers, will want to test, regardless of what the developers say.
The winner in today's market is the business that is nimble on its feet and can make changes to its systems faster than the competition. The problem is that many people view "making changes" as altering the code and that is just part of the process. The change cannot be rolled out until it is tested. The most agile business will need to change its systems and test them faster than its competitors.
Peter Cole is chief technical officer at Green Hat