The new version 5.0 adds an agent that can be deployed form SOAtest, which resides back in the Java layer, which spawns the WSDL web service definitions.
The capability itself isn’t new, but the addition of the agent makes it easier to set up within SOAtest.
Under this scenario, you define a test for a complex web service, such as an order cycle that includes searching a catalog of items, placing an order, and confirming it. In a services-oriented environment, each of those steps would comprise an individual service that is orchestrated using the BPEL standard.
If the test reveals something unexpected, such as an order for two items, the next step is to see what spawned the questionable result. Before this, you would have had to open another Parasoft tool Jtest, which in turn manages Junit tests of Java classes or packages (Junit is a framework for writing Java regression tests). That would involve parsing though Java code, which is known to developers, but not necessarily those who compose the services.
With SOAtest 5.0, you could specify that an agent trace the process in question. That in turn would flat the suspect Java objects, which would prompt a Jtest developer to run some Junit tests.
SOAtest 5.0 also adds support for BEA’s new AquaLogic Repository, meaning that test artifacts and results can be associated with Java assets to provide another layer of test policy enforcement.
At this point, the new agent capabilities are only available for Java. At some point, we expect them to add support to .NET and C/C++.
