日期：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/
规范位置
SOAP 1.2
命名空间名字
http://www.w3.org/2002/12/soap-envelope
规范位置
http://www.w3.org/TR/soap12-part0/ (原始)
