One of the proposed benefits of a specification like JAX-WS or JAX-RPC is that you can easily move your application code from an existing web-services toolkit to another - the specification-compliant APIs used in one toolkit should be compatible with those of another toolkit.
I recently put this idea to the test when I migrated a load of ObjectWeb Celtix application code to CXF. For those that don't know, Celtix, the open source ESB that originally resided at ObjectWeb, moved to Apache last year, merging with the XFire project to become CXF. CXF has an substantially different runtime to ObjectWeb Celtix, and can be considered an entirely different toolkit.
By the way, IONA's "Celtix Enterprise" product contains CXF as its JAX-WS core runtime. Just for clarity, I use the terms "Objectweb Celtix" and "Celtix Enterprise" instead of "Celtix" on its own, to distinguish between the original ObjectWeb project and the IONA offering based on CXF.
So - how did I get on? The porting turned out to be much easier than I thought: JAX-WS does have its advantages. As you'd expect, however, my porting effort was not uneventful. Here are some areas to look out for if you're attempting something similar.
Packaging, building and environment
The development environment changed (slightly) from ObjectWeb Celtix to CXF; for example, instead of a CELTIX_HOME environment variable you should set CXF_HOME. Also, an obvious difference is that the classpath has changed significantly: you need to modify your Ant files so that the new JARs are picked up.
Some other not-so-obvious issues arise: I went looking for some XML Schema definitions for configuration beans in CXF and couldn't find them under the CXF installation directory; it turns out that these schema are all held in a JAR file in the CXF distribution.
Toolkit specific APIs
While the JAX-WS specification covers the bulk of the APIs for implementing your service and creating an endpoint, every toolkit typically supplies its own APIs to do additional things such as configuration, registration of handlers, etc. ObjectWeb Celtix had the concept of a Bus, implemented by the class org.objectweb.Celtix.Bus. CXF also has a Bus concept; however, the CXF Bus is is located in a different class (org.apache.cxf.Bus) and has a different API for instance creation.
If your application relies heavily on toolkit-specific APIs then you will have to take this into account when you being a porting or migration activity
Implementation glitches
I was surprised to find some implementation differences on the interpretation of the specification. Thankfully, these were small and easily fixed; however, the experience has pointed out that there's no substitute for testing.
For example, if you call the JAX-WS getPort() API on a client side service object then, in CXF, you must specify the target namespace of the WSDL contract as the namespace of the port name, like this:
HelloWorld helloWorld = helloWorldService.getPort(
new QName("http://www.my/wsdl/target/namespace",
"SOAPOverHTTPEndpoint"),
HelloWorld.class );
In Celtix you could leave the namespace of the port name as an empty string "". If you do this in CXF then the call to getPort() will fail. It turns out that this latter behaviour (in CXF) is more in keeping with the JAX-WS specification (see Section 4.2.3 of the JAX-WS Specification).
Based on my experience, I put some notes on the "Celtix Migration Page" in the CXF user guide. If I come up with any other migration issues then I'll submit them there to keep them in the one place.