【IT168 业界新闻】 

　　2006 年中，Web 服务领域将发生翻天覆地的变化。对于 Java? 开发人员而言，这些变化将包括新 Web 服务框架和构建于 Web 服务之上的新功能层的出现。在 Dennis Sosnoski 的“Java Web 服务”系列的第 1 部分，他讨论了即将发生的变化，并为读者构想了基本的概况。

　　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 服务的互操作性。