这次对 SOAP 规范的更新明确了含义模糊的内容，并简化了实现之间的互操作性问题，与此同时还关注着现有实现的向后兼容。虽然工作组为 SOAP 的演化采取了一些积极措施，但工作重点仍集中在澄清问题上。熟悉 SOAP 规范的 1.1 版本的人应该会对最新版本一见如故。抽象模型文档旨在提供一套 SOAP 规范的读者们能够使用的通用术语和概念。虽然抽象模型文档并没有提供实现 SOAP 处理器的设计，但是它确实使大家对于规范的制定者们如何预见 SOAP 处理器的不同组件之间的协同工作有了深入的了解。
随着这些文档的发布，现在似乎已是对工作组最近的一些活动、问题以及决定做一个简单概括的最佳时机了。然而，这一概述肯定无法做到面面俱到，并且当然会偏向我认为值得注意的方面。因此，我在本文的结尾处提供了更多的详细参考资料的链接。
发布会开始时，我们在法国 Dinard 举行了一次由Cannon主持的面对面的(F2F)会议。(请参阅参考资料，查看 Yves Lafon 拍的这次会议的照片。)如我们所愿，会议中所取得的进展要比仅仅使用电子邮件地址和电话交流取得的进展大得多。其中最明显的决策之一就是关于该协议的名称。最终的决定是：由于首字母缩写词“SOAP”在业界得到广泛认可，所以我们不想把它的名称改为其它相对不知名的词汇—如XML协议。一旦决定保留名称“SOAP”，问题就成了我们是否希望 SOAP 仍旧代表简单对象访问协议(Simple Object Access 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 所示的出错消息。
清单 3：SOAP 1.2 与 1.1 请求不匹配的出错消息
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<V:Upgrade xmlns:V="http://www.w3.org/2001/06/soap-upgrade">
<envelope qname="ns1:Envelope"
xmlns:ns1="http://www.w3.org/2001/06/soap-envelope"/>
</V:Upgrade>
</env:Header>
<env:Body>
<env:Fault>
<faultcode>env:VersionMismatch</faultcode>
<faultstring>Version Mismatch</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
使用 XML infoset
近来，关于 infoset 的课题被提了出来。Infoset 是这样一个机制，通过它，不必使用空白、尖括号以及单、双引号等琐碎的细节符号就能描述 XML 文档。它允许对包含在 XML 中的实际数据而不是 XML 的特定格式进行更为抽象的讨论。这一机制的一种令人感兴趣的用途，就是它使新的 XML 格式(比如拥有更简洁的句法的二进制 XML)的出现成为了可能。在调查 Infoset 及其在 SOAP 规范中可能的用途的过程中，Martin Gudgin 根据 XML infoset 重写了规范的第 4 部分。因此，从 Martin 所完成的工作中抽取一个片断来看，一个 Infoset 定义的头部分元素示例可能包含以下内容：
· 头部分的本地名称
· “http://www.w3.org/2001/06/soap-envelope/”的名称空间名称
· 零或更多个符合名称空间条件的属性信息项目(Attribute Information Items)
· 零或更多个符合名称空间条件的元素信息子项目(Element Information Item children)。
请注意，它是如何将重点集中在包含在 XML 中的实际数据上，而非数据的特定文本格式上的。在更高层次上，比如，在关于如何定义一种特定传输上的 SOAP 的定义中，其注意力就在于 XML 的实际物质表现的特定细节发生之处。
同样值得注意的还有让数据类型 boolean 接受 0、1、ture 和 false(“0”为 MU 头部分中的缺省值)的决定。
继续下一项任务
XML 协议组现在有两个新的下属机构：传输绑定任务组(Transport Binding Task Force)和 RPC 任务组(RPC Task Force)。这两个任务组的目标主要是决定涉及各个课题的SOAP规范的语法和语义。传输绑定任务组关于最基本的问题(诸如“什么是绑定?”这样基本的问题)已经有了不少讨论。如果您对其中的任何课题感兴趣的话，我建议您浏览一遍邮件列表文档，并查看一下该工作小组的 Web 页。让我来对如此广泛多样的选项作总结可能反而会对原意造成不可思议的损害。那么我们暂且假设它涉及的不同观点相当多。RPC 任务组刚刚成立，现仍处于收集问题的阶段。
还有些什么?除了本文中提到的问题以外，XML工作组的面前还摆着不少尚待解决的问题。想获得详尽的列表，请参阅问题列表。一些更为活跃的问题(如 SOAPAction)肯定会让您兴奋的。对于任何对 SOAP 感兴趣的人，无论是技术的热衷者还是实现者，我都建议您通过订阅并加入 xml-dist-app 邮件列表来留意工作组的发展。该工作组在一个方面是非常独特的，那就是：它大概是 W3C 工作组中最开放的一个了 — 我们的所有工作几乎都是以一种开放、公共的方式完成的，并且 SOAP 社区的参与、意见和反馈都是其工作得以成功的关键因素。
作者的免责声明：对于本文中提及的任何、或所有决策，都应视为工作组在当前时刻想法的快照。有相当多的人急切希望工作组完成其工作，因此可能会根据工作组的临时决策做出实现的选择，这是可以理解的，但请注意，工作组如今所作出的决策可能会在日后有所改变。
参考资料
万维网联盟(The World Wide Web Consortium，W3C)于 2001 年 7 月 9 日宣布发布 SOAP 1.2 以及 XML 协议抽象模型文档。
您应当参阅一下补充报道，以获得有关 W3C 的 XML 协议工作组工作方面的更多信息。
一些法国Dinard面对面会议的照片。
关于作者
Doug Davis 是 IBM 的软件开发人员和 W3C XML 协议工作组的代表。您能通过 dug@us.ibm.com 与 Doug 联系。
文章来源于领测软件测试网 https://www.ltesting.net/
