背景介绍
从 SOAP 1.0 规范发布到今天，已经六年多了。在 SOAP 规范发布之前，开发人员早就在通过 Internet 协议交换 XML 消息了，但 SOAP 的推出承诺对此技术进行规范化，并实现更好的互操作性。SOAP 还提供了各种挂钩 (hook) 机制，以方便扩展，从而可以添加高级基础结构功能，以增强未来的 XML 消息交换。WSDL 规范在 SOAP 推出后不久发布，添加了 Web 服务元数据的标准表示方法。主要软件供应商很快看到了将 SOAP 和 WSDL 结合使用的潜力，在接下来的几年里，SOAP Web 服务似乎成了不可阻挡的发展潮流。
SOAP 和 WSDL 挑战
尽管在整个行业中 SOAP+WSDL 快速崛起，但仍然在很多方面存在问题，会妨碍 SOAP 达到很多人所期望的完全成功。第一个方面就是互操作性。尽管 SOAP 最诱人的一个重要方面就是它的互操作性承诺，但实际进展却并不明显。这最初是由于对 rpc/encoded 样式的 Web 服务（也称为 rpc/enc）的强调所造成的，在此情况下，对象模型将序列化为 XML 然后再在接收端重新构造。此自动序列化/反序列化功能使得 rpc/enc 非常易用（只要使用其支持的相对简单的数据结构），但却会导致生成无法用于任何目的的 XML。更糟糕的是，语言和平台支持的差异导致了实现之间大量的不兼容现象。
被广泛接受的 Web 服务最佳实践现在正倾向于使用 document/literal 样式 (doc/lit) 替代 rpc/enc 样式。在 doc/lit 中，XML 消息格式是由 W3C XML Schema 定义所定义的。就理论上来说，这应当能消除互操作性方面的任何问题，因为模式实例定义 XML 的实际结构，而每个平台负责恰当地处理该 XML。在实际中，对极为复杂的 W3C Schema 标准的支持程度参差不齐，且又带来另外一些互操作性问题。
较早的 rpc/enc 互操作性问题和最近的 doc/lit 互操作性问题都会因缺乏认识而进一步加重。对于 doc/lit，各种框架支持不同的模式标准子集，却没有列出缺少的特性，从而使得这种情况尤为尖锐。即使不同的框架声称支持特定的模式特性，实现也经常 不完整，从而导致使用这些特性时出现互操作性问题。转向 doc/lit 的部分原因是希望能利用企业或行业标准模式。此类标准模式的设计通常没有考虑会在 Web 服务中使用，因此它们常常使用 SOAP 框架不能提供良好支持的特性。
SOAP Web 服务的另一个问题是基础结构扩展和基本 SOAP 处理――添加的可在一系列 Web 服务上应用的处理层――之间不断的混淆不清。SOAP 的设计运行方便地添加此类扩展，但这些扩展通常仅在其为受多个框架支持的标准时才有用。这要求整个行业进行协作，但通常很难办到。即使最基础的扩展（如附 件和安全性），也需要若干年进行开发，但仍然不受所有框架支持。
SOAP 的阻力
前一部分中详细讨论的互操作性和标准化问题限制了 SOAP Web 服务的适用性，同时，SOAP 框架本身也通常很复杂，难于使用。优势有限以及潜在的复杂性让很多开发人员转而采用比 SOAP 更简单的替代方法。SOAP 的大部分阻力都来自与一项称为 REST 的技术相关的方面。严格来说，REST 是可应用到 Web 服务的 HTTP 协议的基本规则的规范化技术。在实际中，REST 活动经常将规范化搁置在一边，而在其中包含所有在不使用 SOAP 包装的情况下在 HTTP 上传输 XML 文档的所有东西，基本上与出现 SOAP 之前进行的直接 XML 文档方式一样。
REST 远不如 SOAP 雄心勃勃。REST 自然被限制为使用 HTTP 作为传输层（尽管可以使用类似的方法进行其他传输），而 SOAP 从理论上来说是独立于传输层的（尽管到目前为止只广泛使用 HTTP 传输进行部署）。REST 并不包含任何直接添加基础结构扩展的方法――但在 SOAP 真正开始提供此类扩展前，此限制都可以被视为无足轻重的方面。
由于 REST 的功能承诺并比不上 SOAP，因此通常不需要使用任何框架代码来实现客户机或服务器，因此开发人员无需处理框架的复杂性。不太方便的一面是，此技术的确 需要直接实现 HTTP 和 XML 处理，不过很多开发人员都已经习惯处理这些技术了。直接处理 XML 甚至可以算得上是一个优势，因为与 SOAP 框架提供的选择相比，开发人员在这种情况下的选择空间更大。
那么，是不是应该丢掉 SOAP 而开始采用更简单的 REST 呢？对很多 Web 服务应用程序的表单而言，这可能都是一个很实际的选择，因此我并不反对这样的想法。不过，有很多其他应用程序（特别在企业级）需要 SOAP 所承诺的基础结构扩展和传输独立性。转向 REST 则意味着这些应用程序将需要直接实现安全、事务处理和协作等功能，而不是通过框架提供这些功能。大多数企业应用程序将可能选择完全避免使用 Web 服务，而不去花这份心思。
但就像电影中一样，即使 SOAP 的前途看起来真的很灰暗，但仍然会有新的希望。这个希望来自即将推出的新一代框架。这些框架的目标是最终发掘 SOAP 的全部潜能，使实现全新的 SOAP Web 服务应用程序变成现实，同时大幅度提高 doc/lit Web 服务的互操作性。
Indigo 的重要性
尽管本系列是关于 Java 技术的，但我要提到的第一个新框架却是来自开发人员打心底里认为是 Java 技术的竞争对手：Microsoft? .NET。这个新框架是 Windows Communication Foundation (WCF)，也称为 Indigo。Indigo 最初是打算作为即将推出的 Windosw “Longhorn”版本的一部分，但 Microsoft 已宣布将以 WCF 的形式提供给较老的 Windows 版本使用。WCF 有望在推出后替代较旧的 .NET 框架。
WCF 之所以对 Web 服务重要，其原因在于 Microsoft 台式机系统占有率的绝对优势（不是完全 占有――像很多和我一样的人就在使用 Linux? 进行所有工作，Macs 也很受欢迎――但在 90% 以上）。台式机系统占用率的绝对优势意味着，当 Microsoft 推出新框架时，它就会有着巨大的影响。Microsoft 所支持的技术将自动成为大部分其他框架支持的目标，那些不受 Microsoft 支持的技术可能会成为“二等公民”，只有在客户机和服务器均不使用 Microsoft 系统的情况下才能使用。
通过 WCF，Microsoft 将向基本 .NET 平台添加主要的新技术（虽然其中一些当前已通过 WSE 3.0 加载项提供给基本 .NET）。这些技术包括 XOP/MTOM、WS-Addressing、WS-Trust、WS-SecureConversation、WS- ReliableMessaging、WS-Coordination、WS-AtomicTransaction 和 WS-Policy。XOP 和 MTOM 是支持将二进制数据作为附件包含在 SOAP 消息中传递的标准，这可最终实现主要 SOAP 框架上可互操作附件（以前 Microsoft 仅支持一项称为 DIME 的附件技术，而大部分框架都支持 Microsoft 的一项称为 SwA 的早期建议方案）。WS-Addressing 提供了消息标识符、目标地址和操作的标准格式；标识符部分是多项其他技术所要求使用的部分，因此很重要，而地址和操作部分需用于支持后备传输（除 HTTP 之外）和异步操作。WS-Trust 和 WS-SecureConversation 对较旧的（已有广泛支持）WS-Security 进行补充，支持性能更高的对称加密。WS-ReliableMessaging 支持消息交付和序列保证。WS-Coordination 管理 Web 服务的分布式网络中的操作序列。WS-AtomicTransaction 使用两阶段提交协议支持 SOAP 上的事务处理。最后，WS-Policy 定义 WSDL 的扩展，以便服务声明其对使用所有这些技术的要求。这些 WCF 技术代表了使用 Web 服务构建企业应用程序所必要的大部分支持服务。
如果 WCF 中包含的技术的确 得到了广泛的支持且具有很好的互操作性，我们就将有足够的理由以 SOAP 为核心构造企业 Web 服务。现在，这变成现实的可能性很大。Microsoft 于 2005 年 11 月举行的 WCF Interoperability Plug 盛会上展示了大部分主要 SOAP 框架，其中包括我将要在本文其余部分集中讨论的 Java 备选框架。这些早期的测试结果非常有限，实现完全互操作性仍然有一些问题（包括要支持仍在不断变化的 WS-* 标准的特别版本），但整个行业的方向无疑是将 WCF 技术作为下一代 SOAP 框架的核心部分加以支持。
Sun 和 Java 标准
JAX-RPC 1.0 是 Java 方面的 Web 服务的原始标准。虽然 JAX-RPC 的设计思想是可以为实际 Web 服务实现使用不同的协议实现，但在实践中，仅将其用于 SOAP 服务。已经开发了多个不同的 JAX-RPC 实现，其中使用最广泛的可能就是 Apache 框架了，其次是 Sun Microsystems 作为 Java Web Services Developer Pack 的一部分分发的 Reference Implementation。
在开发 JAX-RPC 1.0 时，行业中的很多人认为 rpc/enc 样式的 SOAP 将成为最方便和易用的 Web 服务。JAX-RPC 1.0 规范要求对 rpc/enc 和 doc/lit 样式进行支持，但并不要求对很多模式特性进行支持。这样就带来了一个很不幸的副作用，使 doc/lit SOAP（此技术是基于模式的）事实上成了一个二流选项。
JAX-RPC 1.0 对 Web 服务功能的认识也有一定的局限。从其名称可以看出，最初的目的是为了支持使用 XML 的远程过程调用（Remote Procedure Call，RPC）操作。Java 当时已经有了一项面向 Java 应用程序间的 RPC 调用的现有技术，即远程方法调用（Remote Method Invocation，RMI）。该规范团队选择了在现有 RMI 接口上对 JAX-RPC 进行建模。只要通过请求-响应操作使用 rpc/enc SOAP，此模型就可相当接近地进行匹配，不过映射到异步操作或其他传输的效果并不理想。到 2003 年底，有关人员认识到，总要对 JAX-RPC 进行大幅修订，以处理这些问题和其他问题，因此 Sun 组成了一个专家组开始进行 JAX-RPC 2.0 规范的开发。
JAX-*
JAX-RPC 2.0 开发工作的主要目标是对各项标准进行更新，以支持 JAX-RPC 1.X 的强制要求（基于 Java 5 特性，如 Annotation 和泛型），改进消息传递支持（包括除 HTTP 外的异步操作和传输），并通过使用 JAXB 2.0 绑定替代 JAX-RPC 1.X 的简单（但局限性很强）内置绑定来改进模式支持。出于对更改范围的强调和其他原因，这个后续标准的名称更改成了 JAX-WS 2.0。JAX-WS 2.0 现在已经提供了预发布版本，其生产版本预计将在 2006 中期推出。
JAX-WS 2.0 成功实现了对 JAX-RPC 1.X 的各种期望，甚至还提供一些额外的功能，如有限的 REST 支持。因为 JAX-WS 2.0 大量使用了 Annotation 和其他 Java 5 特性（这样就不能使用较旧的 JVM），因而一些开发人员可能会在使用时遇到一些问题，但对于很多开发人员而言，依赖 Java 5 特性将是一大优势。一个较为突出的顾虑是，JAX-WS 2.0 并不支持 Web 服务配置的 Annotation 的任何后备选项，这样就可能限制该框架的灵活性和长期优势。
JAX-WS 2.0 和 JAXB 2.0 都在准备绑定到 J2SE 规范的发布 Java 5 版本中。将这些组件作为标准 JVM 安装的一部分将无疑增加对开发人员的吸引力，因为这将避免在各个应用程序中包含大量框架的需求。将大量框架包含在标准 JVM 中的缺点在于（除了会增加基本下载大小外），在需要进行错误修复时，可能会导致很难进行版本控制，就像已经发生在 JAXP 之类的组件身上的情况一样（这些组件已经采用了绑定的方式）。
向互操作性进发
JAX-WS 2.0 直接支持 XOP/MTOM，而并不是其他新的 WCF 技术。不过，在 Sun 声明的与 Microsoft 互操作性承诺中，他们宣布将开发 WCF 中包含的其他技术的 Java 开放源代码版本。这些开放源代码实现将作为大型项目“GlassFish”的一部分进行开发，此项目涵盖了作为 Sun 的应用服务器（包括 JAX-WS 2.0 和 JAXB 2.0 参考实现）的一部分使用的所有技术。
在这些新的开放源代码项目成形之前，我们需要拭目以待。在 Sun 所公布的时间表中，将在 2006 年中期提供一些可用的东西，因此在本系列的后续文章中将能够提供更多的详细信息。
Apache 方法
Apache 项目数年来已在 Web 服务方面进行了大量的工作，其主要精力放在 Java 平台开发上。Apache 当前的 Java SOAP Web 服务生产平台是第三代 Axis 框架。Axis 得到了广泛的使用，这既包括开发人员下载并直接使用，也包括将其作为 SOAP 引擎嵌入到若干不同的应用服务器中。Axis 通常被认为是使用最广泛的 Java SOAP Web 服务平台。
不过，Axis 也有一些缺点。首先，它是基于 JAX-RPC 1.0 标准设计的，而后者在很大程度上约束了 Axis 体系结构，限制了其灵活性。随着为了以 SOAP 处理核心为基础构建新技术而对扩展的需求的增加，这个有限的灵活性就越来越成问题了。同时，转向 doc/lit SOAP 服务也带来了对更好模式支持的需求，对 Axis 代码而言，这在当时是非常不实际的。到 2004 年中期，Axis 团队认为需要重新进行编写工作，要在进行重新编写工作中应用通过实现 Axis 获得的经验，并同时提供更好的灵活性，以便将来进行扩展。
“救世主”Axis2
Axis2 是 Axis 的后续版本。它设计为轻量 SOAP 处理引擎（尽管对于 JAX-WS 2.0，Axis2 也包含一些对 REST 的支持），可以采用很多方式进行扩展。与原来的 Axis 不同，Axis2 并不刻意对实现任何特定 API 进行约束（尽管一些 JAX-WS 2.0 支持级计划使用 Axis2 核心代码的包装）。Axis2 的开发工作已经持续了一年多，不久就将投入生产。
Axis2 最好的特性之一就是为 SOAP 消息使用的 AXIOM 对象模型。XML 对象模型存在的时间几乎和 XML 本身一样长，最早的版本是来自 W3C 的 DOM 标准。AXIOM 和其他 XML 对象模型不同的地方在于，它利用新的 XML 解析器提供的灵活性来允许按需构造对象模型。这意味着，只有为实际需要通过模型访问的 XML 文档部分构建对象模型才会带来性能损失。
另一个主要 Axis2 特性是对可插入数据绑定的支持。此特性允许您选择最简单的方式来处理 SOAP 文档的 XML 有效载荷，对生成的代码进行自定义，以使用所选择的方法。可能的选择包括，直接使用 AXIOM，使用与原来的 Axis 相似的简单数据绑定方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等专用数据绑定框架。
扩展 Axis2
尽管 Axis2 仍然在开发中，不过已经有了一系列在 Axis2 基础上实现 SOAP 扩展的项目。这些项目包括 WCF 所支持的所有主要技术以及 Microsoft 计划在加载项（即独立计价的）应用程序中的一些扩展。Axis2 的体系结构允许使用一个称为模块 的组件方便地开发此类扩展。
WS-Addressing 和 WS-Security 模块当前包含在基础 Axis2 分发中（在将来将可能作为独立部分下载，或者甚至成为独立的项目，因为这些模块和核心 Axis2 代码之间并没有紧密耦合关系）。WS-ReliableMessaging 支持正在通过 Sandesha 项目开发，而 WS-Trust 和 WS-SecureConversation 正在通过 WSS4J 项目开发（已经提供了 WS-Security 实现）。WS-AtomicTransaction 和 WS-Coordination 正在通过 Kandula 项目进行实现。
小联盟
除了 Sun 和 Apache 这些著名的组织之外，在开放源代码开发领域外仍然有一些其他创新 Web 服务项目在进行。其中一个就是我自己的 JibxSoap 项目，该项目是以我的 JiBX XML 数据绑定框架为基础构建的 SOAP 和 REST 引擎。JibxSoap 的主要优点在于其出众的速度――在以前的测试中，其使用标准 SOAP 消息的性能几乎能与 Java RMI 性能匹敌。XFire 是另一个 SOAP 引擎，该引擎允许选择使用数据绑定框架；XFire 也具有出色的性能结果。JibxSoap 和 XFire 都有可能在下一年投入生产使用。
考虑到开发源代码开发的速度，无疑将在 2006 年期间出现一些其他的新 Java 框架。即使这些框架不能达到 Sun 和 Apache 那样的受欢迎程度，但能够以更简单（或更快）的方式实现相同的目标，所以仍然具有很大的影响力。
展望
现在，我已经在本文中对 2006 年的 Java Web 服务发展进行了介绍，在后续文章中，我将更详细地对各个开放源代码 Java 框架进行讨论。下一篇文章中，我们将讨论 Axis2，对其体系结构和基础 AXIOM 对象模型进行分析。我还将讨论 AXIOM 中包含的 XOP/MTOM 附件支持以及数据绑定框架如何访问此附件。以后的文章将讨论 Axis2 数据绑定后备选项和性能，以及其他 Java Web 服务框架的详细信息和性能。敬请关注此系列的每篇新文章，以了解最新的详细信息。
?
原文：http://www.ibm.com/developerworks/cn/webservices/ws-java1.html