日期： 2003 － 03
适用于：全局 XML Web 服务架构 (GXA)
远程过程调用（ RPC ）
SOAP 1.1 SOAP 1.2 规范
传输协议： TCP, HTTP, SMTP, 和 MSMQ
Microsoft® .NET Web Services Enhancements 1.0 SP1
XML Schema
** 摘要 ** ** **
SOAP 在分布异构环境中提供一种简单，可扩展，和丰富的 XML 消息框架（ messaging framework ） , 对定义高层的应用协议提供更强的互操作性（ interoperability ） .
** 内容 ** ** **
介绍
SOAP 版本
消息框架
扩展性
处理模型
协议绑定
HTTP 绑定
RPC 与编码
SOAP 样式
总结
** 介绍 ** ** **
在昨天 SOAP 好像只不过是一种清洁产品。现在大多数开发者无法理解没有尖括号的信息（ can't hear the word without seeing angle brackets. 译注：我理解成现在数据大多以 XML 表现）。 SOAP 最初代表 " 简单对象访问协议 " 。如果你几年以前问人询问 SOAP 的意思，他们会或许说“在 internet 上与 DCOM 和 Corba ( 如 RPC 调用 ) 做类似工作 ”。它的原作者们承认他们集中于“对象访问”然后返回，随着时间发展，使 SOAP 服务于更广泛的应用变得合乎需要。因此，规范的焦点迅速从对象移向通用 XML 消息框架。
焦点的变化在缩写词 SOAP 的字母 ’O’ 上产生了一个细微的问题。有趣的是， SOAP1.2 工作组仍保留 ( 迄今 ) SOAP 这个名字 ( 它太应用的太普遍，很难改变它 ) ， 但是决定依靠（ against ）清楚地说明来避免误解开发者。最新的 SOAP1.2 规范中正式的 SOAP 定义，甚至没有涉及对象：
_ SOAP _ _ 是一种在分散，分布环境中用来交换结构化信息的轻量级协议。 _ _ SOAP _ _ 使用 _ _ XML _ _ 技术来定义一个可扩展的消息框架，这个消息框架提供了一个能在多种下层（ _ _ underlying _ _ ）协议上进行交换的消息构造。框架被设计成独立于任何特定的编程模型和其他实现的具体语义。 _ _ _
_ _
现在，这个定义真正的描叙了 SOAP 的实质。 SOAP 定义了一个方法来将 XML 消息从 A 点传送到 B 点（见图 1 ）。这是靠 SOAP 提供了一个基于 XML 的消息框架，它有以下几个特点：
① 可扩展（ extensible ）
② 能使用 多种下层网络协议
③ 独立于编程模型
现在来依次讨论这三个特点的更多细节。
图 1. 简单 SOAP 消息
首先， SOAP 的关键是可扩展性（ extensibility ）。当 SOAP 代表一些东西的时候，“ S ”意为“简单（ Simple ）”。如果有一件事我们能从 web 上学到，那就是简单（ Simplicity ）总能争取 (wins over) 效率或工业纯度 (technical purity) 。而且当互操作性处于得失攸关（ at stake ）时，简单就是绝对的需要。 SOAP 缺乏多种分布式系统的特点，如安全、路径选择和命名一些可靠性，印证了 SOAP 保持了最初设计目标――简单。 SOAP 定义了一个通信框架来允许这些特点作为分层扩展加进来（ to be added down the road as layered extensions ）。 Microsoft 、 IBM 和其他软件商正积极着手于一套通用的 SOAP 扩展， 它将增加大多数开发者期望的一些特点。初始阶段作为全局 XML Web 服务架构 (GXA) 而涉及。 Microsoft 已经发布一个 GXA 规范的参考实现， 并称为 Microsoft® .NET Web Services Enhancements 1.0 SP1 。
其次， SOAP 能够基于任何传送协议使用，例如 TCP ， HTTP ， SMTP 甚至 MSMQ( 参阅图 1) 。不过，为了保持互操作性需要定义标准协议绑定来略述（ outline ）适合每个环境的规定 (rule) 。 SOAP 规范提供一个灵活的框架来定义任意的协议绑定，而且，因为 HTTP 协议已被广泛使用，现在已经明确定义了一个 HTTP 协议的绑定。
第三， SOAP 允许任何编程模型并且并不依赖 RPC 。实际上，大多数开发者直接将 SOAP 等同于在分布式对象上使用 RPC 调用（因为最初 SOAP 是关于“访问对象”），基本的 SOAP 模型象 MSMQ 一样更近似于传统消息系统。 SOAP 定义了一个单独处理的单向消息模型。你可以将多条消息合并成一个整体信息进行交换。图 1 说明了一条简单的发送者接收不到 response 的单向消息，不过，接收者可以把 response 发回给发送人 ( 参阅图 2) 。 SOAP 允许任意数量的消息交换模式 (message exchange patterns － MEPs) ， 每个消息交换模式的 request/response 仅仅只有一个。其他例子包括 solicit/reponse( 和 request/reponse 相反 ) ，通知，和长时间运行的点对点会话（ peer-to-peer conversations ）。
图 2. Request/response 消息交换模式
开发者经常将 request/response 与 RPC 相混淆，而实际上它们非常不同。 RPC 使用请求 / 反应，但是请求 / 反应不一定是 RPC 必需的。 RPC 是允许开发者与方法调用合作的一种编程模型。 RPC 需要一个方法签名到 SOAP 消息的转换。由于 RPC 的普及性， SOAP 略述了一个以 SOAP 来使用 RPC 的协定（见下文的 RPC 和编码这一部分）。
有了这三大特征， SOAP 消息框架就能在异构的环境中方便的发送 XML 消息了，而互操作性在这些异构的环境中早就是一个挑战了。
** SOAP ** ** 版本 ** ** **
** ** 从最初发布 SOAP 规范对今天的广泛实现的 SOAP1.1 ，很多东西已经改变，从小的细节到主要的思想变化。 SOAP1.1 被提交到 W3C ，并在 2000 年 5 月返回作为备忘录（ note ）发布。 "W3C 备忘录（ Note ） " 状态使得 SOAP 1.1 仅仅是一个好的想法，因为它还没有通过 W3C 的严格程序，在这个程序中它会最终达到实现的“建议书（ Recommendation ）”状态 。虽然如此，现在在如此广泛的大或小的应用提供商支持下， SOAP1.1 仍然被认为为实际上的标准。
W3C 使用 SOAP1.1 建议书作为原本（ seed ）来让一个新的 XML 协议工作组负责生成下一个 SOAP 版本， 目前命名为 SOAP1.2 。在目前， SOAP1.2 是 " 候选建议书 " ，这表明它在实现阶段内而且离完成不远。 一旦 SOAP1.2 成为 " 建议书 " ，它可能会迅速得到应用提供商的支持。
在 SOAP1.2 实现之后，应用提供商会为向后兼容而继续支持 SOAP1.1 。 SOAP 版本化（ versioning ）是基于 XML 命名空间。 SOAP 1.1 对应于 ** http://schemas.xmlsoap.org/soap/envelope ** 命名空间，而 SOAP 1.2 对应于 ** http://www.w3.org/2002/12/soap-envelope ** 命名空间 （尽管在它成为建议书时会有改变）。
参阅表格 1 来快速参考每个命名空间的名字和规范的位置。在整个余下的文章中，我们将覆盖 SOAP 中最重要的地方。在两个版本的广泛的变更列表中检查当前的 SOAP 1.2 规范。
** 表 1.SOAP 版本信息 **
**
** SOAP 1.1 **
|
---|---
命名空间名字
|
http://schemas.xmlsoap.org/soap/envelope/
规范位置
<TD style="BORDER-RIGHT: gray 0.75pt solid; PADDING-RIGHT: 3.75pt; BORDER-TOP: #d4d0c8; PADDING-LEFT: 3.75pt; PADDING-BOTTOM: 3.75pt; BORDER-LEFT: #d4d0c8; WIDTH: 74.98%; PADDING
**