If you’ve been using Axis over the years, all of this is old news. You’ve probably seen dozens of WSDDs and used the AdminClient on a regular basis. It works great and is reliable – that’s a big part of why Axis has been such a huge success. Still, Web Services have evolved and you need more than Axis to take advantage of these advances. For a simple service like the one in Listing 1, it might not be too hard to change the code to get it to work on a newer Web Service stack. It would still take some work. That work only goes up for more complicated services. This is where WSAS comes in. Let’s take a look at just how easy the upgrade is with WSAS.

Redeploying to WSAS: Using WSDD
You can upgrade your Axis service with WSAS very easily. There’s no code to change. There’s no code to generate or regenerate. There’s no configuration file to alter or add. All you need is a WSDD and JAR file with the classes for the service. That’s it. If you’ve been using Axis, there’s a good chance you already have both of these laying around already.

For the Axis bid-buy sample we’re using, all we have to do is put the class files in a JAR. To do this we move them into a directory structure reflecting the package structure (samples.bidbuy) and then run Java’s jar command as shown in Listing 2.

Now we’re ready to get started with WSAS. Load up the Management Console. Go to the Services tab and you should see something similar to Figure 1. Notice the Upload Axis1 Service (.wsdd) Option. That’s exactly what we want to do. Go ahead and choose that and you’ll see a screen similar to Figure 2.

This is a straightforward interface. Simply use the Browse buttons to locate the deployment descriptor for your Web Service and the .jar file you created for your service. Then click upload. You should get a confirmation screen similar to Figure 3. The upload is asynchronous, but shortly afterwards your list of Service Groups should show a “deploy.wsdd” (that was the name of the deployment descriptor from the bidbuy sample) similar to Figure 4.

That’s all you have to do! Your crusty old Axis Web Service is now running on the super-modern WSAS Web Service stack. Your Web Service is going to benefit greatly even if this is where you stop. Since it’s running on WSAS (and thus Axis2), you’ll get great performance benefits. WSAS uses a powerful combination of a StAX parser and the Axis Object Model (AXIOM) for parsing SOAP. This is much more efficient in terms of both speed and memory usage than Axis1. The Axis2 architecture also lets you plug in whatever data binding you want, such as JAXB. It also enables Message Transmission Optimization (MTOM) for your service, by default. This allows for much more efficient transport of binary data if your service accepts or receives binary data. Of course you probably don’t want to stop here, as now there’s a whole new world of options that you’ve just enabled by migrating to WSAS. Let’s take a look at those now.

Examining the Service on WSAS
In our list of services, click on the WSDL 2.0 link for the Bid Service, as shown in Figure 5. This should bring a graphical representation of the WSDL file that WSAS has created to describe your service. It should look similar to Figure 6.

One thing to notice here is the “invokeAxis1Service” section. The bid-buy sample we picked was an RPC-encoded service, a style of SOAP that’s been deprecated because of its brittleness. So what has WSAS done here?

First, just because RPC-encoding is far from a best practice doesn’t mean that your service isn’t using it. You could very well have partners, both internal and external, that are using this format when invoking your service. No migration path can simply leave those partners high and dry by telling them to re-code their client code. So WSAS has deployed a fully backward-compatible version of your service. Anybody using RPC-encoding to invoke your Web Service can continue to do so. Not only do you not have to change any code to upgrade to WSAS, your clients don’t either.

Second, WSAS has created more modern bindings for your service. This is for either existing clients that can be re-coded or new clients who want to take advantage of new Web Service standards. Again, you didn’t have to write any code, yet now there’s a SOAP 1.2 binding to your service. This is important, because now we can start enabling other SOAP-based technologies, i.e., various WS-* technologies.