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 之类的组件身上的情况一样(这些组件已经采用了绑定的方式)。