Why We Want to Migrate:
1. XFire Project itself has been discontinued
Accoring to XFire and Celtix Merge FAQ, XFire Open Source Project has been discontinued, Apache CXF is a continuation of the XFire project and is considered XFire 2.0, which has many new features and a ton of bug fixes.
2. Using Spring 2.5 to develop Java Middle-tier Server
Spring 2.5 has become a de facto standard for Java Middle-tier Server Development, and it is also adopted internally as standard framework to build Java Middle-tier Servers. But, XFire is built and bundled with old Spring 1.0, which becomes a road block preventing us from using some new Spring 2.5 features, such as Spring AOP. Migrating to Apache CXF 2.1.1 will immediately solve this problem since Apache CXF is built on top of Spring 2 and can work with SPring 2.5 without any problem.
3. Using new CXF Features, which are not available in XFire:
- Since Apache CXF is JAX-WS compliant, it is safe to use CXF JAX-WS Front-end, developing Web Services using JAX-WS Annotations
- We want to inject certain HTTP Headers at both Client and Server side for network routing and load balancing, and this should be separated from the business logic of Web Services. CXF Interceptor Framework is a perfect tool to implement this kind of features
- CXF supports both dynamic Javascript WS Client and statically generated Javascript client, this actually enables us to build a simple soapUI-like tool inside web browser and is working perfectly with our light-weight jQuery based Admin Tool/Console for monitoring and debugging
Obviously, there were some CXF issues we have to resolve:
1. Light-weight SOAP Message Validattion
For the backward compatability with existing XFire Client/Server, we are using CXF JAX-WS Front-end with Aegis Data Binding, we want to have a simple light-weight SOAP Message Validation as alternative to full-fledged Schema Validation. This actually is achived by adding a "XML Validation Interceptor" to the right place in the CXF Interceptor Chain. You can find more detail here from the CXF User Mailing List
2. WS Client Connection Pool
XFire WS Client is built on top Commons HTTP Client 3.0, which allows us to set up a connection pool to control the concurrent requests and the load at the client side. But, since CXF is not using Commons HTTP Client as Client Transport Layer, this is not available from CXF anymore.
This problem was partially resolved by building a simple CommonsHttpClientTransportFactory with a simple CommonsHttpClientConduit. It would be nice that CXF can provide a full-fledged CommonsHttpClientConduit. More detail can be found here and here from the CXF User Mailing List
Apache CXF Actually Performs Better:
To evaluate the performance of CXF, We did one round of load testing by puting two WS Servers behind one Load Balancer, one using XFire and another using Apache CXF, the results show that the performance of CXF is compatable with XFire.
We also run the similar deployment in the real production environment to compare the performance, and our new servers using CXF are wroking very well. We actually see the CPU Utilization on the Servers using CXF is less than the existing servers using XFire. This is a little good surprise for us since we originally expect CXF should consume more resources given the fact that CXF has to build two intercept chains, "in" and "out", for each request.
