SOAP based WebServices and WSDL

[Joe San]

After almost six years, I had to do a small implementation that consumes SOAP based WebServices. I do not like it, but there is no other choice. I have some questions around this:

I have a SOAP based WebServices that I should consume. The WSDL file for this service contains 50 different operations and is 1000 lines in content. Out of these 50 different operations, I only use a handful of them. So here are my questions:

Can I trim this WSDL down to the set of services that I need? I can then keep a local copy of this WSDL and do the code generation when building my project.

Are there any potential dis-advatages of using this approach to trim the WSDL on the client?

[Karthik Shiraly]

One potential disadvantage is that it's easy to make mistakes while trimming the WSDL by hand. A WSDL has multiple cross references amongst its elements and you can't get even one wrong.

Another is that if the WSDL provider changes their WSDL, you'll have to redo everything again.

I don't see any benefits of doing this. What exactly is the problem with a large WSDL, especially since it's just used by the code generators?

[Joe San]

I see the point. I guess I might better use the whole WSDL as-is to avoid any potential problems!

My next question would be:

1. What framework should I consider to write my client? I'm looking forward to using a framework that I could generate the client files using the WSDL document. I have worked with apache-cxf in the past. Should I stick with this or is there a much better and lighter alternative?

2. Since I will be using it with sbt and Scala, I would need a library that is compatible to work with Scala. I already tried using scalaxb, but that sucks as I'm hitting some bugs when generating the client classes. So I do not want to trust that library anymore.

[Karthik Shiraly]

There are 3 commonly used frameworks that I'm aware of - one is the standard JAXWS implementation inside the JRE itself, one is CXF and last is Axis/Axis2.
Both CXF and Axis are (or used to be and I doubt they'd have improved with time) rather heavyweight, simply because they have a lot more features, such as support for the innumerable WS-* standards.
The JAXWS implementation in the JRE is much lighter; it does just basic SOAP WS and code generation (the tool is called wsimport and should be in your JDK directory).

However, I don't know which one of these is compatible with scala and sbt.

[Joe San]

I think with wsimport, I have to manually generate the client source files and copy them to the project which all do not work when you are part of a project. I mean generating the source files from command line is good when you are experimenting, but when you are integrating this as part of a project, you would need something that does his code generation at compile time. So I'm leaning towards Apache CXF.

Do I need a Java EE server to run my Apache CXF client? or it could be run as a standalone piece of code? If so what is the underlying library in Apache CXF that does HTTP connections to call the remote WebServices?

[Karthik Shiraly]

Joe Harry wrote:I think with wsimport, I have to manually generate the client source files and copy them to the project which all do not work when you are part of a project. I mean generating the source files from command line is good when you are experimenting, but when you are integrating this as part of a project, you would need something that does his code generation at compile time. So I'm leaning towards Apache CXF.

I'm not sure I understand. Both wsimport or CXF's wsdl2java can be integrated into ant tasks (probably also into other build systems like maven) and executed automatically at compile time.
There's no need to manually generate and copy any files.

Do I need a Java EE server to run my Apache CXF client? or it could be run as a standalone piece of code? If so what is the underlying library in Apache CXF that does HTTP connections to call the remote WebServices?

JaveEE server is not needed on client side regardless of framework. It can be a regular command line or GUI application.
For HTTP, It uses both the JRE's classes and Apache HttpComponents. See http://cxf.apache.org/docs/asynchronous-client-http-transport.html.

[Joe San]

Ok! That sounds good with wsimport and the possibility to integrate it with Maven.

So supposing that I use wsimport to generate the sources, what framework would I additionally need to use the generated client to call the remote services? I mean do I need HttpCommons?

[Karthik Shiraly]

Nothing additional is necessary. JRE's implementation is self-sufficient.

[Joe San]

What implementation you mean? I did not get that? What API does JAX-WS use to make the underlying HTTP calls to the SOAP remote web service?

[Joe San]

Is there any Maven sample client project template for a JAX-WS wsimport example? I would probably need an asynchronous client template I think!

[Karthik Shiraly]

Joe Harry wrote:What implementation you mean? I did not get that? What API does JAX-WS use to make the underlying HTTP calls to the SOAP remote web service?

I meant java.net.HttpURLConnection.

I don't know about the maven template though. Try googling for it.

[Joe San]

It is a pain in the *** to work with SOAP infrastructure. Have a look at my try:

https://coderanch.com/t/657803/tools/JAX-WS-Maven-Client-Code#3049939

[Karthik Shiraly]

Maven is one tool I've never been able to wrap my head around despite several attempts. I still stick to ant and ivy.

If you are comfortable with CXF and integrating it into your pom build, then I think it's best to stick to CXF.
While it's true that JRE's JAX-WS is lightweight compared to CXF, it's pointless to select it if it takes too much effort and frustrates.

[Joe San]

I've managed so far to properly generate a jar file using WSDL and Apache-CXF!

Now I have the following question:

@WebServiceClient(name = "Weather", 
                  wsdlLocation = "file:/Users/joe/Desktop/weather-client/src/main/wsdl/weather.wsdl",
                  targetNamespace = "http://ws.cdyne.com/WeatherWS/") 
public class Weather extends Service {

The wsdlLocation points to the local machine where I build the project. How should I handle this in my different environments? I mean, the project is built on the build server and run on the production machine which might or might not have the same structure!

[Karthik Shiraly]

Bundle that WSDL somwhere inside the JAR itself and use a classpath URL.
This is fairly straightforward with wsimport and wsdl2java because it's a command line option.
But with maven in the mix, I suppose you have to do something like this

[Joe San]

Thanks for the insight Karthik.

Posting here the complete pom.xml for somebody that might have also have a similar need!

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/maven-v4_0_0.xsd">
     
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.my.myservice</groupId>
    <artifactId>myservice-client</artifactId>
    <version>1.0</version>
    <name>SOAP MyService client</name>
    <packaging>jar</packaging>
     
    <dependencies>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
            <version>3.1.4</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http</artifactId>
            <version>3.1.4</version>
        </dependency>
        <!--dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>1.5.2</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.5.2</version>
        </dependency -->
    </dependencies>
     
    <build>
        <finalName>myservice-client</finalName>
        <plugins>
            <!-- Generate Java classes from WSDL during build -->
            <plugin>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-codegen-plugin</artifactId>
                <version>3.1.4</version>
                <dependencies>
                    <dependency>
                        <groupId>commons-logging</groupId>
                        <artifactId>commons-logging</artifactId>
                        <version>1.1.1</version>
                    </dependency>
                </dependencies>
                <executions>
                    <execution>
                        <id>generate-sources</id>
                        <phase>generate-sources</phase>
                        <configuration>
                            <sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
                            <wsdlOptions>
                                <wsdlOption>
                                    <wsdl>${project.basedir}/src/wsdl/MyService.wsdl</wsdl>
                                    <wsdlLocation>classpath:wsdl/MyService.wsdl</wsdlLocation>
                                </wsdlOption>
                            </wsdlOptions>
                        </configuration>
                        <goals>
                            <goal>wsdl2java</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <!-- Add generated sources - avoids having to copy generated sources to build location -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>${basedir}/target/generated/src/main/java</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!-- Build the JAR with dependencies -->
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
            </plugin>
        </plugins>
        <!-- Build with Java 1.8 -->
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.8</source>
                        <target>1.8</target>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
     
</project>

[Karthik Shiraly]

You're welcome, and thank you for posting the solution.

[Joe San]

One other question though! My WSDL file has all throughout the location of where the service is. How can I make it dynamic. I mean, should I better remove lines with the SOAP Action in my WSDL file that has this:

 <wsdl:operation name="GetMessage">
  <soap:operation soapAction="http://1.1.1.1/MyService?WebService=GetMessage" />
  <wsdl:input>
   <soap:body use="literal" />
   <soap:header message="tns:GetMessageCredentials" part="UserCredentials" use="literal" />
  </wsdl:input>
  <wsdl:output>
   <soap:body use="literal" />
  </wsdl:output>
 </wsdl:operation>

I'm thinking of the following:

1. Have seperate WSDL files for different environments

2. Control the Maven build and specify the appropriate WSDL file when building?

Is there a better way?

[Karthik Shiraly]

Firstly, soapAction URL is not the endpoint URL.
The actual endpoint URL in WSDL is the relevant <service> element's <port> element's <address>.
That can be overridden dynamically if required without changing the WSDL, by setting the ENDPOINT_ADDRESS_PROPERTY
in code.
Search for cxf ENDPOINT_ADDRESS_PROPERTY and you'll find the code examples.

[Joe San]

I got to do this eventually to override the service end point in my WSDL file:

		val factory = new org.apache.cxf.jaxws.JaxWsProxyFactoryBean()
		factory.setServiceClass(classOf[MyServicesSoap])
		// TODO: get this from the config!
		factory.setAddress("http://1.2.3.4/myService?WebService")
		factory.getInInterceptors.add(new org.apache.cxf.interceptor.LoggingInInterceptor())
		factory.getOutInterceptors.add(new org.apache.cxf.interceptor.LoggingOutInterceptor())
		val myServiceClient = factory.create().asInstanceOf[MyServicesSoap]
		val proxy = ClientProxy.getClient(myServiceClient)

Fine! I would assume that I do not have to create the JaxWsProxyFactoryBean for each subsequent calls? Since this is a factory, I can have this instance somewhere globally and keep referring to it for every request for the WebService that comes in?

[Karthik Shiraly]

I'm not familiar with this JaxWsProxyFactoryBean or its purpose. If setting its address works the way you want, then ok.

[Joe San]

After having worked with Scala, REST, Play Frameowrk and MicroServices, doing this decade old SOAP stuff is a pain in the ***