扫二维码关注kmpro
扫二维码关注kmpro
|
Web服务内幕，第8部分：关于Soap的决策 来源： 时间:2002-08-22 09:44 作者：AMTeam.org Web服务内幕，第8部分：关于Soap的决策
顾问程序员，IBM 2001 年 8 月 万维网联盟（The World Wide Web Consortium，W3C）已经发布了 SOAP 规范及 XML
抽象模型的更新草案。请跟随 Doug Davis
深入了解导致这些新版本发行的近期会议的最新情况。 这次对 SOAP 规范的更新明确了含义模糊的内容，并简化了实现之间的互操作性问题，与此同时还关注着现有实现的向后兼容。虽然工作组为 SOAP 的演化采取了一些积极措施，但工作重点仍集中在澄清问题上。熟悉 SOAP 规范的 1.1 版本的人应该会对最新版本一见如故。抽象模型文档旨在提供一套 SOAP 规范的读者们能够使用的通用术语和概念。虽然抽象模型文档并没有提供实现 SOAP 处理器的设计，但是它确实使大家对于规范的制定者们如何预见 SOAP 处理器的不同组件之间的协同工作有了深入的了解。 随着这些文档的发布，现在似乎已是对工作组最近的一些活动、问题以及决定做一个简单概括的最佳时机了。然而，这一概述肯定无法做到面面俱到，并且当然会偏向我认为值得注意的方面。因此，我在本文的结尾处提供了更多的详细参考资料的链接。 发布会开始时，我们在法国 Dinard 举行了一次由 Cannon 主持的面对面的（F2F）会议。（请参阅参考资料，查看 Yves Lafon 拍的这次会议的照片。）如我们所愿，会议中所取得的进展要比仅仅使用电子邮件地址和电话交流取得的进展大得多。其中最明显的决策之一就是关于该协议的名称。最终的决定是：由于首字母缩写词“SOAP”在业界得到广泛认可，所以我们不想把它的名称改为其它相对不知名的词汇 — 如 XML 协议。一旦决定保留名称“SOAP”，问题就成了我们是否希望 SOAP 仍旧代表简单对象访问协议（Simple Object Access Protocol）。因此我们投票决定，“SOAP”不应再作为一个缩写词，而应该就是 SOAP 本身，如今其字母背后也不再有特殊意义。 逐步了解 清单 1：流式消息的无副作用应用 从该示例中可以清楚地看到，如果我们允许在 SOAP 处理器验证了 fireNuke 头部分已理解 getAuthorization 头部分的语义之前就对它进行处理，那么就可能最终得到一些不愿看到的结果。 工作组以 MustUnderstand 为主题，作了另外一个关于返回 MU 出错消息的关键决策。那就是开发了一种标准的选错机制（请参阅参考资料），一旦出现未被理解的 MU 头部分，返回的错误就将遵循某种格式 — 使得对于这些错误的程序性分析容易不少。基本思想是，在 MU 错误中有一个定义完好的头部分，它包含了一份所有未被理解的 MU 头部分的列表。例如，如果上述示例中的 getAuthorization 头部分未被理解，那么 MU 错误中就应该出现如清单 2 中所示的头部分。 清单 2：MU 错误的可选择性头部分 采取行动 不鼓励使用 SOAPAction。SOAPAction 是 SOAP 的可选部件，它受支持，但并不必要。服务中“也许”会需要
SOAPAction，并且任何想要访问哪些服务的软件都“必须”能够发送它。 在 F2F 会议中，我们的确对此进行了非正式投票，结果是 22 票支持，4 票反对 — 未得到一致通过。SOAP 社区本身非常真实地反映了工作组的立场（也未一致通过），因此该问题依然存在。 名称空间中的内容 多少由于新的名称空间的关系，同时还开发了一个新版本的错误模型。基本思想是，当一个 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 请求不匹配的出错消息
使用 XML infoset 头部分的本地名称 请注意，它是如何将重点集中在包含在 XML 中的实际数据上，而非数据的特定文本格式上的。在更高层次上，比如，在关于如何定义一种特定传输上的 SOAP 的定义中，其注意力就在于 XML 的实际物质表现的特定细节发生之处。 同样值得注意的还有让数据类型 boolean 接受 0、1、ture 和 false（“0”为 MU 头部分中的缺省值）的决定。 继续下一项任务 还有些什么？除了本文中提到的问题以外，XML 工作组的面前还摆着不少尚待解决的问题。想获得详尽的列表，请参阅问题列表。一些更为活跃的问题（如 SOAPAction）肯定会让您兴奋的。对于任何对 SOAP 感兴趣的人，无论是技术的热衷者还是实现者，我都建议您通过订阅并加入 xml-dist-app 邮件列表来留意工作组的发展。该工作组在一个方面是非常独特的，那就是：它大概是 W3C 工作组中最开放的一个了 — 我们的所有工作几乎都是以一种开放、公共的方式完成的，并且 SOAP 社区的参与、意见和反馈都是其工作得以成功的关键因素。 作者的免责声明：对于本文中提及的任何、或所有决策，都应视为工作组在当前时刻想法的快照。有相当多的人急切希望工作组完成其工作，因此可能会根据工作组的临时决策做出实现的选择，这是可以理解的，但请注意，工作组如今所作出的决策可能会在日后有所改变。 W3C XML 协议工作组 工作组分为抽象模型小组（Abstract Model Group）、传输绑定任务组（Transport Binding Task Force）以及 RPC 任务组（RPC Task Force）。 他们仍有一长串问题有待解决。如果您想直接向工作组提出任何技术性问题，请使用他们的邮件列表。 万维网联盟（The World Wide Web Consortium，W3C）于 2001 年 7 月 9 日宣布发布 SOAP 1.2 以及 XML 协议抽象模型文档。 您应当参阅一下补充报道，以获得有关 W3C 的 XML 协议工作组工作方面的更多信息。
|
|
|
关键词：
|
| 相关文章 |