Mercury Formalizes SOA Strategy: The Details

By Tony Baer

Waiting for the other shoe to drop, Mercury Interactive Corp, whose acquisition by HP is still pending, has at long last disclosed its strategy for managing the SOA life cycle.

The highlights are that Mercury is releasing the first new version of the Systinet UDDI registry since it acquired the company earlier this year. The new version, Systinet 2.1, now integrates with several of Mercury testing and Business Technology Optimization (BTO) product families.

Additionally, Mercury has added some services-specific tests to its Quality Center stable under what's called Mercury Service Test Management, and extended is SLA management capabilities to support web services.

Up until now, Mercury's Quality Center tools could test web services in the same way that it tests normal software applications. And with last winter's acquisition of Systinet, Mercury added an obvious focal point for its SOA strategies. But until now, that strategy has been a blank slate.

Until now, rivals like Parasoft, iTKO, and Green Hat Consulting have taken the lead in checking web service headers for compliance with WS-I interoperability, XML schema, and to some degree, semantics (to ensure that SOAP headers properly map to WSDL service descriptions), and web page regression tests that isolate parameters.

But SOA adds more touch points that typically are not exposed in a user interface. The dynamic nature of SOA environments means that one or more services can be requested at run time in permutations that cannot always be fully simulated.

For instance, if you have 300 services in production, each of which exposes five interfaces, you start with a universe of 1500 permutations. But then, given the fact that web services are supposed to interoperate across different platforms, the permutations can be practically infinite.

And with web services standards a moving target, checking the correctness, completeness, and functionality contained in headers, plus the actual content of the message, can be similarly complex.

To plug the gap, Mercury is adding a service test management tool that uses a wizard that is prompted when as service is being registered into Systinet. The wizard asks whether you want to test for functionality, performance, or compliance, and then automatically generates test cases. Based on the metadata inside the Systinet registry.

With the test plan in place, you can then fire up Mercury Service Test, a new product, for compliance tests (to check if the service is properly formed and complies with relevant standards). Or if you want to test using specific events, you can use LoadRunner to check performance or QuickTest Pro to vet functionality.

Additionally, Mercury has extended its application mapping tool for vetting services in a couple ways. First, it inspects containers on middleware servers to identify so-called "rogue" services that have slipped into the system without being properly registered inside Systinet. For now, IBM WebSphere and BEA WebLogic are supported, with Microsoft .NET planned in a forthcoming release.

And, just as the mapping tool is used to chart infrastructure dependencies of software applications, in the new release, it can do so for web services. Of course, this leads to the question of when Mercury is planning to address services in its recently released change management solution. That's not in this release, but is on the roadmap.

All of these capabilities apply to design time. At runtime, Mercury is relying on Systinet's existing interfaces, also known as the "Governance Interoperability Framework" where it interacts with run-time governance tools like AmberPoint. But of course, there is also overlap with some of Mercury's BTO run time dashboards.

Mercury has not announced a release date for all of these offerings.

About Datamonitor