从事open source 的 web services开发是令人兴奋的。去年下半年发布了两个下一代的web services框架，他们都在Apache软件基金会下面。这两个框架分别是，在2006年四月末发布1.0的Apache Axis2，目前处在1.3的候选发布版本阶段（译注：1.3已经发布）；Apache CXF，它在2007年7月初发布了2.0版本（以CXF命名的第一个发布版本）。
这两个框架都是从已有项目中进化过来的。Axis2来自众所周知的Axis 1.x 系列。CXF按照字面来说是XFire和Celtix两个项目的后续，这两个项目融会了他们的代码库和开发团队就有了CXF。不论从哪个角度来看新旧项目之间都有显著区别。Axis2完全从头重写了Axis，使用了能够让功能更容易扩展的新模块架构。CXF从XFire和Celtix这两个起源上也做了广泛重构。
这引发了一些问题。已有使用Axis 1.x，XFire或者是Celtix的应用程序是否要移植到这些项目的新版本上呢？如果一个开发者决定要移植他（她）的应用到其中的一个新版本上，那他应该用哪个呢？相反的，如果某人正在从头开始开发新的web service又无需考虑移植，那他（她）又应该用哪个呢？是否一个框架生来就优于其他的呢？
让我们逐个处理这些问题。首先，已有应用是否需要移植？回答这个问题很大程度上依赖于你的应用到达了生命周期的哪个阶段。对于一个非常稳定成熟的项目，如果在可预计的未来很少或者根本不需要变化，那它可能就不需要移植，因为当前的框架很好的满足了需求。如果应用的性能或者功能受bug影响，那移植就值得做，特别是对使用Axis 1.x 的用户来说，因为围绕Axis的大部分开发者社区都把资源转向了Axis2。Axis 1.5 版本虽然正在进行中，但可能要数月才能完成。
对于需要移植的项目来说，最简单的就是移植到当前框架的下一个版本上。Axis2和CXF都为开发者提供了从之前版本到新版本的移植技巧指南，但他们都没有为web service从一个框架移植到另一个框架提供工具或者指南。尽管如此，对这类移植来说，查看所有可用的选择都是有价值的。在web service开发上Axis2和CXF走了不同的路子，对某些开发者来说，其中一条总比另一条需要付出更多。
这给我们带来了比较Axis2和CXF二者功过的好的角度。当然有二者很多可比较的地方，web services框架都必然地要满足所有相同需求，但因为这二者都非常年轻，都有某些领域比其他的做得更好。主要不同列在下面：
* CXF支持WS-Addressing，WS-Policy，WS-RM，WS-Security 和 WS-I 基本规范。Axis2支持除WS-Policy之外的所有协议，WS-Policy也会在即将到来的版本支持。
* CXF很容易和Spring集成，而Axis2不。
* Axis2支持范围更大的数据绑定，包括XMLBeans、JiBX、JaxMe和JaxBRI同时还有它自带的数据绑定方式－－ADB。注意对JaxME和JaxBRI的支持在Axis2 1.2中仍然处在实验阶段。CXF目前仅支持JAXB和Aegis，对XMLBeans、JiBX和Castor的支持将会在CXF 1.2中实现。
* Axsi2支持多种语言－－在java版本之外还有C/C++的版本可用。
然而在比较这些框架时，比较他们开发web services的方法与比较它们的特性同样重要。从开发者的角度看，这些框架彼此之间完全不同。Axis2走的路子在很多方面都像是一个微型的应用服务器。Axis2打包成WAR，这样它就能发布到像Tomcat之类的servlet容器中，它被设计的使web services更容易管理和发布。Axis2的Web管理模块允许Axis2在应用运行过程中动态配置－－新的服务可以上传、激活或者使其无效、他们的参数也可以改变。管理UI也允许模块在一个或者更多的正在运行的服务中生效。唯一不利的一面是，为达到这些目的使用UI所作的改变不能被持久化－－servlet容器重启之后就失效了。
Axis2有利于web services的独立，不依赖其他应用；提供了广泛多样的功能；通过模块化架构为添加新功能（随时间流逝，这总是可能的）提供了一个不错的模型。某些开发者或许会发现为实现他们的需求用Axis2有些太麻烦太笨重。这些开发者可能更喜欢Apache CXF。
CXF专注于开发者的高效和可嵌入性。大部分的配置通过API而不是繁琐的XML文件来实现，Spring的集成是个重点，包括支持Spring 2.0，CXF的API和Spring的配置映衬的相当紧密。CXF着重代码优先的设计，简单的API使从已有应用中开发服务更容易（嵌入性也有利于这点）。
不论你选择了哪个框架，你都将从活跃稳定的开源社区中受益。每个框架都有公司背景：Axis2源自WSO2，CXF源自Iona。两者都有活跃的开发者社区。Axis2已经存在很久了，但是CXF进步也很快。我的建议是：如果多语言支持是重要的，Axis2是很明显的选择。如果你在意与像Spring之类的项目紧密集成的Java实现，CXF是更好的选择，特别是对把web services嵌入其他程序的应用来说。如果这些项目中的新特性对你不太重要，而你又相对来说比较满意Axis1，那么可以考虑继续使用Axis1并紧跟最新的可用版本，直到有业务上的原因需要移植。
原文地址： http://www.theserverside.com/tt/articles/article.tss?l=AxisAxis2andCXF
btw：
翻完之后发现这篇问题题目虽然比较吸引眼球，可好像也没说出些实质性内容来，有些地方甚至有些八卦。不过既然翻译了就贴出来，说不定还能给大家带来些茶余饭后的谈资：）
新一代的 Web Services 框架如 Axis2、CXF 都是由现有的项目中逐渐演化而来的，Axis2 是由大家熟悉的 Axis 1.x 系列演化过来，而 Apache CXF 则是由 Celtix 和 XFire 项目整合而生，并且刚刚发布了 2.0.2 的最新版本，不过仍是 Apache 的一个孵化项目。
Axis2 是对 Axis 进行了彻底的重写的一个新项目了，它使用了新的模块化架构，更方便于功能性的扩展等等。
Apache CXF 则是由 XFire 和 Celtix 两个现有的项目进行了重组。
问题：如果现有的应用程序是基于 Axis 1.x、XFire 或者 Celtix 的话，那应该怎么办？都迁移到这些新的框架上去吗？但是即使是要迁移，那应该迁移到哪个框架上去呢？
如果是编写一个新的 Web Services 应用程序的话，就不存在迁移的问题了，但是哪个框架是你应当选择进行使用的呢？哪个比哪个更好呢？
对于现在的应用程序的迁移，如果你的应用程序是稳定而成熟的，并且在可预知的未来的情况下，只要很少的一些需求变更要做的话，那么保存你的体力，不要去做“劳民伤财“的迁移工作了。
如果你的现有应用程序BUG缠身，性能，功能等等都一片糟糕的话，那就要考虑迁移了，那选哪个框架呢？先比较一下它们的不同之处：
1、Apache CXF 支持 WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-I BasicProfile
2、Axis2 支持 WS-Addressing、WS-RM、WS-Security和WS-I BasicProfile，WS-Policy将在新版本里得到支持
3、Apache CXF 是根据Spring哲学来进行编写的，即可以无缝地与Spring进行整合
4、Axis2 不是
5、Axis2 支持更多的 data bindings，包括 XMLBeans、JiBX、JaxMe 和 JaxBRI，以及它原生的 data binding（ADB）。
6、Apache CXF 目前仅支持 JAXB 和 Aegis，并且默认是 JAXB 2.0，与 XFire 默认是支持 Aegis 不同，XMLBeans、JiBX 和 Castor 将在 CXF 2.1 版本中得到支持，目前版本是 2.0.2
7、Axis2 支持多种语言，它有 C/C++ 版本。
8、Apache CXF 提供方便的Spring整合方法，可以通过注解、Spring标签式配置来暴露Web Services和消费Web Services
如何抉择：
1、如果应用程序需要多语言的支持，Axis2 应当是首选了；
2、如果应用程序是遵循 Spring 哲学路线的话，Apache CXF 是一种更好的选择，特别对嵌入式的 Web Services 来说；
3、如果应用程序没有新的特性需要的话，就仍是用原来项目所用的框架，比如 Axis1，XFire，Celtrix 或 BEA 等等厂家自己的 Web Services 实现，就别劳民伤财了。
Axis和很多开源包使用的xml解析器都冲突,每次用都遇到问题,特别是再websphere下部署webservice就是恶梦. 有时间看看 CXF!
CXF通过了JAXWS2.0的TCK，目前正在进行JAXWS2.1的开发工作。
CXF的编程模型比AIXS2简单，而且在Stand alone的方式下执行效率比AXIS2要高很多。
还有就是如果你还是在使用RPC/Encoding的方式，AXIS 1.x 是你唯一的选择了。 因为XFire , CXF 以及AXIS2 都不支持RPC/Encoding的编码方式，要说原因吗？那主要是在JAXWS 规范中已经把RPC/Encoding的方式抛弃掉了，因为这种编码方式的互操作性太差了。
如果你要用JAVA开发Web Services，那用JAXWS API开发可以保证你的代码在大多数Web Services Framework上正常运行。