2006 年将是 Web 服务(特别是 Java Web 服务)发展标志性的一年。新的第三代框架即将撩开面纱，这些框架将为 doc/lit SOAP 提供更好的支持，并能带来潜在的性能提高。同时，第四代 WS-* 标准也最终开始形成一组可互操作的层，对 SOAP 和 WSDL 进行扩展，以支持核心企业需求。
这篇文章是我的 Java Web 系列的第 1 部分，我将讨论以下 Web 服务目前的状态和在 2006 年即将发生的主要变化，并将简单说明新框架和技术如何相关和交互。后续文章将深入讨论其中的很多框架和技术，希望能籍此让您了解在该领域最新的发展，并关注其如何为您的编程项目提供帮助。
背景介绍
从 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 之类的组件身上的情况一样(这些组件已经采用了绑定的方式)。
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 之类的组件身上的情况一样(这些组件已经采用了绑定的方式)。
1288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
