Java Web 服务，第 1 部分: Java Web 服务在未来一年内的发展

核心提示： 被广泛接受的 Web 服务最佳实践现在正倾向于使用 document/literal 样式 (doc/lit) 替代 rpc/enc 样式，在 doc/lit 中，Java Web 服务，第 1 部分: Java Web 服务在未来一年内的发展(2)，XML 消息格式是由 W3C XML Sch

被广泛接受的 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 文档方式一样。