Web服务内幕：关于Soap的决策

　　这次对 SOAP 规范的更新明确了含义模糊的内容，并简化了实现之间的互操作性问题，与此同时还关注着现有实现的向后兼容。虽然工作组为 SOAP 的演化采取了一些积极措施，但工作重点仍集中在澄清问题上。熟悉 SOAP 规范的 1.1 版本的人应该会对最新版本一见如故。抽象模型文档旨在提供一套 SOAP 规范的读者们能够使用的通用术语和概念。虽然抽象模型文档并没有提供实现 SOAP 处理器的设计，但是它确实使大家对于规范的制定者们如何预见 SOAP 处理器的不同组件之间的协同工作有了深入的了解。

　　随着这些文档的发布，现在似乎已是对工作组最近的一些活动、问题以及决定做一个简单概括的最佳时机了。然而，这一概述肯定无法做到面面俱到，并且当然会偏向我认为值得注意的方面。因此，我在本文的结尾处提供了更多的详细参考资料的链接。

　　发布会开始时，我们在法国 Dinard 举行了一次由Cannon主持的面对面的(F2F)会议。(请参阅参考资料，查看 Yves Lafon 拍的这次会议的照片。)如我们所愿，会议中所取得的进展要比仅仅使用电子邮件地址和电话交流取得的进展大得多。其中最明显的决策之一就是关于该协议的名称。最终的决定是：由于首字母缩写词“SOAP”在业界得到广泛认可，所以我们不想把它的名称改为其它相对不知名的词汇—如XML协议。一旦决定保留名称“SOAP”，问题就成了我们是否希望 SOAP 仍旧代表简单对象访问协议(Simple Object Aclearcase/" target="_blank" >ccess Protocol)。因此我们投票决定，“SOAP”不应再作为一个缩写词，而应该就是SOAP本身，如今其字母背后也不再有特殊意义。

　　逐步了解

　　在 F2F 会议中所作出的更为重要的决定之一，从实现者的角度来看，是关于 SOAP 处理模型的决定。在 SOAP原来的版本中，有一点不甚明确，那就是在进行过程中执行MustUnderstand(MU)检查时，每个头部分是否都能以特定的顺序得以处理，或者所有这些MU检查是否必须在处理余下的每个头部分之前执行。工作组决定，一个 SOAP 处理节点必须向其它 SOAP 节点显示在它处理任何一个头部分之前已经执行了所有的 MU 检查。因此，如果某一次实现选择在 SOAP 消息流入的时候对其进行处理，并在处理每个头部分的同时进行 MU检查，那么该实现必须支持一些取消(undo)的概念。所以，如果在处理过程中出现了MU错误，那么它应该没有先前处理过的头部分遗留下的副作用。用来说明这个“无副作用”处理方法的最好的例子(虽然有些不正常)如清单 1 所示。

　　清单 1：流式消息的无副作用应用

<env:Header xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<c:fireNuke xmlns:c="http://us.gov/potus" env:MustUnderstand="1"/>
<c:getAuthorization xmlns:c="http://us.gov/potus" env:MustUnderstand="1"/>
</env>

　　从该示例中可以清楚地看到，如果我们允许在 SOAP 处理器验证了 fireNuke 头部分已理解 getAuthorization 头部分的语义之前就对它进行处理，那么就可能最终得到一些不愿看到的结果。

　　工作组以 MustUnderstand 为主题，作了另外一个关于返回 MU 出错消息的关键决策。那就是开发了一种标准的选错机制(请参阅参考资料)，一旦出现未被理解的 MU 头部分，返回的错误就将遵循某种格式 — 使得对于这些错误的程序性分析容易不少。基本思想是，在 MU 错误中有一个定义完好的头部分，它包含了一份所有未被理解的 MU 头部分的列表。例如，如果上述示例中的 getAuthorization 头部分未被理解，那么 MU 错误中就应该出现如清单 2 中所示的头部分。

　　清单 2：MU 错误的可选择性头部分

<env:Header xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<f:Misunderstood qname="c:getAuthorization" xmlns:c="http://us.gov/potus/"
xmlns:f='http://www.w3.org/2001/06/soap-faults' >
</env>

　　采取行动

　　最近讨论的一些有较大争议的问题之一就是 SOAPAction HTTP 头部分的问题。就 SOAPAction HTTP 头部分当前的形式来说，一个被普遍(但并非一致)认同的观点是它的使用和定义有些模糊。规范中仅仅说它应包含消息的意图，并且只针对 HTTP 作了定义。对于在其它传输中该做些什么、如何处理在传输(HTTP 是其中之一)之间移动 SOAP 消息的情况，以及“意图”的含义(它是否用作路由?它是不是目标服务?)则未作规定。简言之，就是一些人想保留它，而另一些人想除去它。我们最终确定了两个建议，并将它们提交对提议持欢迎态度的 SOAP 社区：

　　不鼓励使用 SOAPAction。SOAPAction 是 SOAP 的可选部件，它受支持，但并不必要。服务中“也许”会需要 SOAPAction，并且任何想要访问哪些服务的软件都“必须”能够发送它。

　　反对使用 SOAPAction。发送方“不应该”发送 SOAPAction。接收方“不许”在 SOAPAction 头部分存在、不存在或它的值的基础上接受或拒绝接受消息。

　　在 F2F 会议中，我们的确对此进行了非正式投票，结果是 22 票支持，4 票反对 — 未得到一致通过。SOAP 社区本身非常真实地反映了工作组的立场(也未一致通过)，因此该问题依然存在。

　　名称空间中的内容

　　有一点是意料之中的，即新的 SOAP 版本还将有新的名称空间。目前，新的名称空间为 http://www.w3.org/2001/06/soap-envelope。

　　多少由于新的名称空间的关系，同时还开发了一个新版本的错误模型。基本思想是，当一个 SOAP 处理节点接收到带有它不支持的名称空间的 SOAP 消息时，它必须返回一个带有旧的 SOAP 1.1 名称空间(http://schemas.xmlsoap.org/soap/envelope)的 VersionMismatch 错误，并且应该包括一个包含受支持的 SOAP 名称空间列表的 Upgrade 头部分。例如，如果一个 SOAP 1.2 处理节点接收到一个 SOAP 1.1 消息却无法处理，因为它不支持 SOAP 1.1 语义，那么它就应该返回如清单 3 所示的出错消息。

原文转自：http://www.ltesting.net