Converting a Web App Into a SOAP Client: Part II

DZone 's Guide to

Converting a Web App Into a SOAP Client: Part II

This time, let's continue exploring this command-line app. We can apply the same thing when we convert the web application.

· Web Dev Zone ·
Free Resource

We Continue...

In Part I, we took our first stab at converting the command-line application, previously tightly coupled to the Shape Calculator, into a SOAP client.

Even though we do have a working application, there a couple of things we can explore and perhaps improve upon.

  • the generated classes are all dumped into the same package
  • the generated types are in a different package from the service-side types
  • if the SOAP service has had new ShapeNames added, we won't know unless we hit an error condition,
  • and since the app's local ShapeName list is not up-to-date, the new shape(s) are not selectable in the menu

The above issues can be our motivation to dig somewhat deeper into the SOAP service and client(s).

Get Latest Code

Get the very latest code in this current (SOAP-client) version of the command-line application here.

You'll need the core Shape Calculator project, if you do not already have a working combo SOAP-REST web service.

If you have any questions, please review the previous articles.

Scenario: New Shape Added

Someone in department A adds a new ShapeName (with associated calculation classes, etc) to the child Shape Calculator project, and in turn rebuilds and deploys a newer version of the SOAP service to the runtime environment.   However, not all client applications have taken those changes into account.

Let's explore this a bit.

Shape Calculator Project Changes

So we begin by adding a new shape, and it will be exposed via the SOAP-REST service.  This image below is not complete - I just wanted to highlight some of the new classes.  You can compare all of the changes between release #1 and release #2 of the Shape Calculator project.

Image title

Build, Deploy, Start Updated SOAP Service

Since we made a change to the Shape Calculator project, we need to re-build/re-deploy the SOAP-REST service that exposes it.  For purposes of these articles, I created a new dynamic web project in Eclipse and just copied all of the SOAP-REST service's files.

Image title

So now we have two different releases of the SOAP service running. For now, 1-cmdline-soap-rest-ws (newer) is pretty much the same as 1-ws-rest-p3 (older) with the exception that it contains the newer shape-calc (rel2) jar.

One motivation for having the two (duplicate) services running is that I can use the older (current) one as the go-to when re-generating the command-line client, but if I want to expose any deficiencies in that command-line client, I can point it to use the newer service at runtime.

In a real scenario, we could run both version 1 and version 2 for a while, to give other departments an opportunity to move over to using version 2.

Run/Test Command-Line App

In Part I, we proved we had a working app when hitting the older SOAP service.  If you open the main class, you'll see the URL is hard-coded (remember we just cut-pasted from the generated code to our main app class).

However, we can run the app with another WSDL URL as a command-line argument.

 java -jar cmdline-shape-calc-app-p2.jar http://localhost:8080/1-cmdline-soap-rest-ws/services/soap/shapecalc?wsdl

Test #1:

Let's try to queue a new calculation, with the new shape (HEXAGON).

Image title

Selecting #8 brings us to the Shape menu.

Image title

And there is our first issue - we are missing the HEXAGON.  However, the application is running... no errors. It didn't bomb... and as a user, we may not be aware of the new shape.

Test #2:

For this test, let's pretend that SOAPUI is just another client, however, this one IS updated, and hits version 2 of the running SOAP service.

We request to queue a new calculation.

Image title

And we verify that we have queued the HEXAGON (it's the same database for all our running apps and services).

Image title

Now let's go back to our command-line app, and request any pending calculations to be run...

Image title

Image title

Oops, that doesn't tell us anything.  We run the debugger, ..and we realize the problem.  It is possible to get a null ShapeName, because the local definition doesn't match the SOAP service's definition (since we added HEXAGON).

Here is the change to the command-line app...


        // since this report helper class is now part of a SOAP client, it is possible
        // that the local definition of ShapeName may not contain all of the shape names
        // of the incoming results from the SOAP service..
        //  thus, 'shapeName' might be NULL..
        for (ShapeName shapeName : resultShapeNames) {

            //new code to handle possibility of NULL shape name
            if (null==shapeName) {
                throw new RuntimeException(
                        "\n\nNULL ShapeName. It seems local ShapeName list might not match incoming ShapeName(s).\n"
                        +"Perhaps this application needs an update (re-build requesting new WSDL.\n\n");


We repeat Test #2 where we attempt to select menu option #9 in our command-line app (Run Pending Requests...) ... and this time the result is better, of course,  ....  more informative.

Image title

More Improvements

It would be nice if when the application starts up, that it immediately knows if there has been a ShapeName change..  so we could add a new SOAP operation to the service that is  getShapeNames() ..  and the application could do a comparison...  and either shutdown or at least warn the user.

Another improvement might be to make the app more robust so it will continue to run even if it can not connect to the SOAP service.

I won't go into any of that, but you can get the latest code at the end of this article.


This time, let's change the command-line application's POM to reflect the newer URL, and rebuild/deploy.... so now our app's generated classes (especially ShapeName) will have been re-defined to include the new HEXAGON shape.  We repeat Test #2 (from above), 

Image title

And it works. If we wish to queue a calculation.

Image title

It also works.

Latest Code


One generated class that we didn't touch is the ShapeCalculatorWebServiceImplService, located in the  com.eli.calc.shape.service.ws.impl  package. 

You'll notice it has a hard-coded URL, pointing to the SOAP service running in our local Tomcat.

We're going to leave that alone, as it is out of the scope (for now) of these articles.

We are on a long software development journey, trying to cover a lot of technologies, but we can't stop and do everything to the nth correct degree all the time.

When the need arises, we'll make the necessary changes.

Next Time

Notice that even though the client-side classes(types) are a different package from the SOAP service side, everything works.  But suppose you want them to match the service-side.  Or, at the very least, not all jumbled together in the same package.

That will be our motivation to explore how to make our runtime-generated WSDL more expressive, thus improving our client's generated code.

However, let's do this with the web application since we need to convert it to a SOAP client, too.

Stay tuned!

java, soap, web app, web dev, wsdl

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}