Mathias Beldame

During the performance tests of the notification implementation in Petals, I needed to send
a large amount of ws requests containing a unique id. I couldn’t generate manually thousands
of requests (each one with its unique id) before launching my soapui test case.

The easiest way I found to solve it was to include a groovy script in my soapui test case:

1) Add a “properties” step in the test case, and define a property. These property will be modified by the groovy script to be different for each request.

2) Add a groovy script in the test case, and write a script to modify your property. The value is generate using a timestamp, and the thread id, to be sure the id will be unique during the whole test, even with more than one thread launching the requests.

3) In the requests of the test case, fill the correct element or attribute with ${property name}, which will be replaced at runtime by the property’s value.

4) All the requests of the test case have now the processPath attribute correctly set.

Mathias

The WS-I:

The Web Services Interoperability Organization (WS-I) is an organization founded to write best practices about the web services interoperability. Its WS-Basic Profile and WS-Basic Security Profile documents deals with some specifications and recommendations to prevent interoperability problems.

They provide a toolkit which can be used to check if the services are compliants with the basic profile or not.

The WS-I testing toolkit contains two tools:

The monitor:
It works as a proxy for web services requests and responses. An interceptor looks at the messages, and sends some informations to a Logger which persists them.

The analyzer:
It analyses the logs generated by the monitor and analyse the traffic between the ckient and the server to determine if it is compliant.
It can analyse WSDLs to check thier compliance, and can even analyse an UDDI repository.

The tool which will interest us today is the WSDL Analyzer, and its ability to check a WSDL and generate a report about its compliance with the WSI-Basic Profile. The report contains the result of the test, and the uncompliant points if there are.

This analyzer can be integrated with Soapui, in order to validate the imported wsdls.

Integration in SOAP UI:
Once you have downloaded soapUI and installed it, you can configure it to use the WS-I analyser to check your WSDL’s compliance with the WSI-Basic Profile.

Download the toolkit:
Download the toolkit on the testing tool download page of the WS-I. Install it by unzipping the zip file in a directory of your local disk.

Configure soapui:
Launch soapUI, go to the “Preferences” box, and choose the “WS-I Settings” tab.
Here, you can configure the path to the toolkit, and some options of the analyser.

Validate a wsdl:
When it is configured, you are able to check the compliance of your WSDLs. To do it, rigth click on the WSDL you want to chack, and select “Chack WS-I Compliance”. Your WSDL will be analysed, and the report will be generated in the soapUI window.

The report:
The report tells you if all the tests have passed, or if at least one of them has failed. You can find all the tests performed on your WSDL, and the assertions verified.
If your WSDL is not compliant you can have look at the “Test Assertion Document” available on the testing tool download page of the WSI to retrieve which recommendation your failed assertion is relating.

I found this tool very usefull…

Mathias

The main goal of the modifications in easyWsdl previously described was to improve the WSDL generated by Java2easyWSDL, and its ant task.
So, the Main class of Java2easyWSDL has been modified to used normalized namespaces, and to provide the possibility to use custom namespaces. These modifications have been exposed in the Java2WSDLTask class to be used from an ant build.

I tested it from eclipse, and it worked correctly, generating the WSDL with the customized namespaces.

When I tryied to use it in my ant builds, outside eclipse, it didn’t work anymore. I had the following error:

[Java2WSDL] org.ow2.easywsdl.wsdl.api.WSDLException: SchemaException: javax.xml.bind.PropertyException: name: com.sun.xml.bind.namespacePrefixMapper value: org.ow2.easywsdl.wsdl.util.CustomPrefixMapper@17d03c5: javax.xml.bind.PropertyException: name: com.sun.xml.bind.namespacePrefixMapper value: org.ow2.easywsdl.wsdl.util.CustomPrefixMapper@17d03c5
[Java2WSDL]     at org.ow2.easywsdl.wsdl.impl.wsdl11.WSDLWriterImpl.useCustomNamespacesPrefixes(WSDLWriterImpl.java:105)[Java2WSDL]     at org.ow2.easywsdl.wsdl.impl.generic.WSDLWriterImpl.getConcreteWriter(WSDLWriterImpl.java:89)
…

The marshaller returned me a PropertyException, meaning it didn’t accept the “com.sun.xml.bind.namespacePrefixMapper” property when I tryied to set it.

I used the same JDK for eclipse, and ant (1.6.0_11); So, I suspected a versionning problem in the jaxb2-impl library. After verification, the classes declared in the classpath of my task, and the ones in eclipse were the same.
The main method of my task, called from a script (outside eclipse and ant) after setting the same classpath worked without error.

I found the solution after some tests and debugging…

The problem was caused by ant. It loaded the implementation of the marshaller from the jdk (in the rt.jar), instead of the one of the jaxb-impl-2.1.6.jar lib. And this implementation didn’t support the “com.sun.xml.bind.namespacePrefixMapper” property.

I solved it by putting explicitely jaxb-impl-2.1.6.jar at the beginning of the CLASSPATH used by ant, or by putting jaxb-impl-2.1.6.jar in the lib directory of ant.

I think it can be helpfull for the users of the Java2easyWSDL ant task…

Mathias

When using the easyWSDL toolbox, and specially the Java2easyWSDL tool provided, the namespaces prefixes are automatically generated (ns1, ns2, …). The second problem is that some namespaces, not declared in the root element are repeated in all the other elements.
The generated wsdl was totally correct, but not human readable. It does not cause any problem when the wsdl is only read by a tool (to generate stub), but becomes problematic when people want to read it directly…

The solution proposed by jaxb2, is to extend the class com.sun.xml.bind.marshaller.NamespacePrefixMapper in a custom class.
In this class, the following methods can be overwriten:
public String getPreferredPrefix(String namespaceUri, String suggestion,boolean requirePrefix) -> to return the prefered prefix for a particular namespace :

if (namespaceUri.equals(“http://schemas.xmlsoap.org/wsdl/soap12/”))
return “soap12″;

public String[] getPreDeclaredNamespaceUris() -> to specify some couples of prefix/namespace to force jaxb to declared them in the root element of the generated XML:
return new String[] {“custNS”,”http://foo.bar/”};

I can now set an instance of this class as a Property of the marshaller used:

NamespacePrefixMapper mapper = new CustomPrefixMapper();
marshaller.setProperty(“com.sun.xml.bind.namespacePrefixMapper”, mapper);

Each time the marshaller will need to get a prefix for a namespace, it will ask your CustomPrefixMapper. If this one returns a prefix, it will be used, in the other case, a generated prefix (nsX) will be used.

The end of the process was to integrate it in easyWSDL, and to provide the WSDLwriter two new methods taking avantage of this mechanism:

/**
* Use normalized prefixes for namespace declaration. Add
* some custom prefixes if needed.
*
* @param customPrefixes
*            array containing custom prefixes and namespaces to use
*            with the format : (prefix1,nsUri1,prefix2,nsUri2,…)
*/
public void useCustomNamespacesPrefixes(String[] customPrefixes)throws WSDLException ;

/**
* Use normalized prefixes for namespace declaration.
*/
public void useNormalizedNamespacesPrefixes() throws WSDLException;

Mathias

I’m working in EBM Websourcing since 2005, in the Petals team, or as consultant for some customers…