We were in the same situation some time ago.
We opted to generate new stub code from the old xfire wsdl. The problem
is that the code really looks ugly as the wsdl is no good match for jaxb
conventions. So it can make sense to simply leave the old xfire service
as is and additionally create a new contract and service with cxf and
offer both for some time. You can then tell the clients they have some
months to switch to the new version.
So for newer services we use the aproach described by
(https://cwiki.apache.org/CXF20DOC/defining-contract-first-webservices-with-wsdl-generation-from-java.html).
This gives us a good quality wsdl to generate our code from.
In general we make sure all our wsdls are WS-I basic profile compliant.
This makes sure that many different stacks can handle the wsdls. We do
the check using the validate option in eclipse.
For the future we experiment with jaxb extensions like cxf-xjc-ts ,
jaxb-fluent-api (see
http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html).
The extensions provide a nice toString function and support for the
fluent builder pattern.
Greetings
Christian
Am 06.05.2010 00:00, schrieb Jason Horne:
I have an existing application that uses XFire 1.2.6 to expose web services via the "code
first" model. We now need to switch to a "contract first" model, without breaking
any clients that are using the existing web services.
Any suggestions on how to go about doing this?
I saved a copy of the XFire-generated WSDL and ran the CXF "wsdl2java" tool
against it, but it seems like there has to be a better way. The application has
interfaces for all of the classes exposed by XFire-can we take advantage of those?
Thanks for any help.
Jason
