SOA may or may not be dead. It may or may not be pining for the fjords. But no one can doubt that there is still a lot of unknowns surrounding what constitutes good SOA. Many vendors offer SOA Readiness tools, ostensibly to determine whether or not you are ready to adopt SOA, at what stage you are on the overall adoption curve, but are typically another way to drive vendor adoption. For instance, as the IBM assessment states:
Where does your company stand when it comes to adopting service oriented architecture (SOA)? Do you understand your current SOA level of maturity and opportunities for improvement? With targeted recommendations for improving your maturity level, the IBM SOA assessment tool can help you unlock the full value of SOA.
But once you've adopted SOA (to whatever degree) you obviously need some way of testing it. Fortunately many of the same people who brought you those handy readiness assessment tools also have a solution here. But what constitutes a good SOA testing tool(s) and do you have to be tied into specific SOA infrastructures? This is the question that Eric Roch asks. He provides some selection criteria that he uses:
- Test-aware interfaces: standardized interface and messages for testing
- Message-based test automation: record, replay and management of test scripts
- Virtualization: the ability simulate virtual service providers and consumers
- Simulation: the ability to simulate applications as part of a regression test
- Load Test: the ability to stress test applications
- Validation: pass/fail verification at the component (messaging) and application (data store) levels.
- Components: Java and/or .NET component visibility
- Introspection: WSDL and XML support to generate data and operation tests
- Management: Manage test cases, scripts, data and results
- Security: SSL, WS security federation, digital signatures
- Industry Specific Data Formats: e.g. EDI, HL7
- Continual Test: Automated build, deploy and test
A couple of years ago InfoWorld reviewed a few SOAP-based testing tools:
Fundamentally, testing a SOAP-based Web service involves three activities: constructing a SOAP request, submitting it, and evaluating the response. As easy as that sounds, it is anything but. An effective SOAP-testing tool cannot simply rely on a user-friendly mechanism for building requests. It must also enable the user to organize and arrange requests in realistic sequences, provide a means of altering request input values, and intelligently tweak requests so as to expose the Web service to a range of good and bad usage scenarios. In short, you want the tool to run the Web service through a reasonable approximation of real-world activity.
Although the industry has recognized that Web Services are just one way or approaching the technological aspects of SOA, it seems that most of the tools today still assume SOAP and WSDL.
Do you have a favourite SOA testing tool(s) or would modify Eric's criteria? Or do you know of any good tools that can be used across implementation technologies?