Introduction
This small application will help you to download the WSDL and related files after pointing to a service. The application will parse through each file it downloads, searching for new files to download and at the same time, updates the URL to a relative path. This will continue until no more files can be found.
Background
Some might ask...Why? The answer is quite simple...to save time. As a .NET developer, I was asked to develop, of all things, a Java client application.
At the end of the development cycle, I started looking at performance improvements, and found that the JAXB library in the Java code base is rather poorly developed. The library requires that the WSDL be loaded at runtime when creating the service connection.
The service I was working with was quite large. Between the transmission and the processing of the WSDL afterwards was taking up to 4 seconds. While this is rather unacceptable, I had a bigger problem. The time to dynamically create the WSDL was upwards to 5 minutes. If I had to take a onetime shot of creating the WSDL, say, on deployment, I might be able to live with it. It turns out that IIS will chuck the WSDL memory after a period of time. This means that the WSDL will constantly be re-generated, and I am forced into a situation where the service is unusable from a Java environment.
After doing some research, I found that I could improve the performance by providing static WSDL. The WSDL could be deployed on the server or on the client. Since this is a Java issue, one could make the argument that it should be created and deployed on the client side by the Java developer. The other benefit is that the files wouldn't have to be transmitted, which could clog up your network. The benefit to doing it on the server side is that the Java developer wouldn't ever have to know anything about it. This might help your technical support personnel. In my opinion, neither is very acceptable, and the Java folks should fix the library.
To implement either method requires that you save the WSDL and all referenced files and then manually modify the files to make the referenced files from a URL to a file based relative path. This got to be tedious with each change to the Web Service during development, and is what lead me to create this application.
Using the code
This very simple application was designed with a happy path in mind. If your service takes 5 minutes as in my case, make sure to load it before you try and retrieve the files. In addition, there is no error or status messages, so just check your output directory.
The last point of interest is the Data\RegEx.xml file. This file contains the expressions that will be used to search and replace the data in the WSDL files. If you need a definition beyond the two currently defined: secondary WSDL and XSD, you will have to provide your own. You can add to or replace at your discretion. The name attribute is there for reference only, and serves no real practical purpose.
Implementation of the static WSDL
In order to use the WSDL on the server side, you will have to add the externalMetadataLocation attribute. The WSDL and supporting files need to be deployed in the same directory as the Web Service. The navigation to the parent directory, as in the example below, is correct, if you deploy the files as stated.
<system.serviceModel>
<behaviors>
<serviceMetadata httpGetEnabled="true"
externalMetadataLocation="..\MyWebService.wsdl" />
</behavior>
</system.serviceModel>
To use the WSDL on the Java client, you can use the following code, or specify the WSDL location when creating your proxy objects. To specify the WDL location, you will need to see the documentation for your proxy generator.
String urlString = "file:/C:\\temp\\WSDL\\MyWebService.wsdl";
MyWebService service = new MyWebService( new URL(urlString),
new QName("http://tempuri.org/", "MyWebService"));
Conclusion
As with all my articles, I hope I have helped another developer in need.
