SOAP：简单对象访问协议
（SOAP：Simple Object Access Protocol）
简单对象访问协议（SOAP）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。 SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。
SOAP 包括三个部分：
SOAP 封装：它定义了一个框架 , 该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。
SOAP 编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。
SOAP RPC 表示：它定义了用于表示远程过程调用和应答的协定。
SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求 / 应答的模式。所有的 SOAP 消息都使用 XML 编码。一条 SOAP 消息就是一个包含有一个必需的 SOAP 的封装包，一个可选的 SOAP 标头和一个必需的 SOAP 体块的 XML 文档。
把 SOAP 绑定到 HTTP 提供了同时利用 SOAP 的样式和分散的灵活性的特点以及 HTTP 的丰富的特征库的优点。在 HTTP 上传送 SOAP 并不是说 SOAP 会覆盖现有的 HTTP 语义，而是 HTTP 上的 SOAP 语义会自然的映射到 HTTP 语义。在使用 HTTP 作为协议绑定的场合中， RPC 请求映射到 HTTP 请求上，而 RPC 应答映射到 HTTP 应答。然而，在 RPC 上使用 SOAP 并不仅限于 HTTP 协议绑定。
SOAP - 消息格式
SOAP在标准化消息格式环境中，可以做所有它能完成的工作。消息的主体部分 是“text/xml”形式的MIME类型，并且包含一个SOAP封套。该封套是一个XML文 档。封套包含了报头（可选的）和报文（必须有的）。封套的报文部分总是用于 最终接收的消息，而报头项目可以确定执行中间处理的目标节点。附件、二进制 数字及其他项目可以附加到报文上。
SOAP提供了一种让客户端指定哪个中间处理节点必须处理报头项目的方法。由
于报头与SOAP消息的主体内容是互不相关的，所以可用它们给消息添加信息，而 不会影响对消息报文的处理。
例如，报头可用于为报文中包含的请求提供数字签名。在这种情形下，身份验
证/授权服务器可以处理报头项目独立于报文可以剥离信息以验证签名。
一旦通过验证，封套的其余部分将被传递给SOAP服务器，它将对消息的报文进行
处理。深入研究一下SOAP封套，有助于明了SOAP报头和报文元素的位置和用途。
SOAP - 剖析SOAP封套
SOAP 1.1规范提供了下面的封套示例：SOAP-ENV:mustUnderstand="1" 5DEF
在这个例子中，GetLastTradePrice请求被传送给网络上某个位置的一个存储
-引用服务。
该请求带有一个字符型参数，一个订单符号，并在SOAP响应中返回一 个浮点数。SOAP封套是表示SOAP消息的XML文档的顶层元素。XML命名空间用于将SOAP标识 符与应用程序的特定标识符区分开。XML命名空间在SOAP中使用很频繁，以把消息 的元素的作用域限制在一个特定的领域。理解SOAP命名空间有助于熟悉XML命名空 间规范。如果您没有理解命名空间，也可以简单地把它看作一种邻近的标识符， 它通过把SOAP元素与特定的位置（真实的或想像的）相关联，从而有助于惟一地 标识SOAP元素。
命名空间
上面例子中的第一个命名空间参照了在SOAP消息中定义元素和属性的SOAP模式。
第二个命名空间参照了SOAP编码，即前文中讨论过的“Section 5”数据类型。 由于没有指定额外的通用元素编码，这种编码将适用于整篇文档。
报头
在SOAP封套报头示例中标识的第一个元素是一个transaction（交易）元素，它 带有一个命名空间属性和一个值为1的mustUnderstand属性。既然mustUnderstand的属性值设为1 ，接受该消息的服务器必须在该transaction节点上执行中间处理。您可以对此 作这样的解释：服务器与客户端事先已就管理该报头元素处理的语义达成了一 致，因而服务器确切地知道要处理的元素的内容，本例中元素的内容是“5”。 如果接收消息的服务器不理解transaction报头的语义，它就会拒绝请求并抛出 一个错误。错误元素是SOAP报文和定义良好的机制的一个特殊部分，用于把错误信 息送回给客户端。
像这样的中间处理节点是SOAP可扩展性的一个例子。客户端在SOAP消息中包含 这样的节点，以在可以处理消息的报文内容前，指示要发生的特殊的处理需要。 要保证向后兼容不能提供这种处理的现有的服务器，只需把mustUnderstand 属性设置为0，它使操作是可选的。除了定义像上例中所示的transaction节点外，SOAP消息还可包含报头项目， 它们用于指定节点执行身份验证处理、加密、状态的永久性、业务逻辑处理等。 报头有助于把SOAP构建成一种可扩展的模态包模型。只需记住报头处理是完全独 立于SOAP消息的报文的。
报文
上面例子中的SOAP报文包含一个XML载荷，我们可以推测RPC没有为我们对其作
详细解释。SOAP不仅是一种模态包模型，它还是一种相当神秘的包模型。没有什么迹象清楚地显示RPC将要开始做什么。我们在报文中所看到的是几个 XML元素，其中一个用命名空间进行了限制。它取决于SOAP服务器理解文档语义并 执行正确的处理。事实上，服务器提供了一种架构，以有意义的方式处理XML载 荷。这里的“有意义”意味着服务器在某些后台数据库上调用远程过程，以为消 息报文中包含的股票-符号元素接收股票价格。所有这些魔术般的操作都是在SOAP RPC幕后发生的。
SOAP - SOAP-RPC
SOAP消息本质上是一种从发送方到接收方的单向传输，但是SOAP经常组合到实 现请求/响应机制中。要让RPC使用SOAP，必须遵循几条规则。首先，请求和响应 消息必须被编码成结构类型。对一个操作的每一个输入参数，都必须有一个同名 元素（或输入结构的成员）作为参数。对每一个输出参数，都必须有一个名称匹 配的元素（或输出结构的成员）。
基于RPC的观点，会省略一些更早一点显示的SOAP消息。只带有报文部分的 SOAP请求与响应封套如下所示：
请求 DEF响应 22.50请求要调用GetLastTradePrice方法。注意响应定义了 GetLastTradePriceResponse操作。对附加响应到响应操作尾部的 一个常用的SOAP调用规则是：创建响应结构。这种输出结构包含一个名称为 price的元素，它返回方法调用的结果，假定为浮点型。
在SOAP封套中没有什么地方的数据类型是显式声明的，注意到这一点很重要，
这样如果只查看SOAP消息，就不会知道符号类型或结果参数price（价格）的类 型。客户端应用程序一般通过“Section 5”编码定义数据类型，或通过与服务器 私下达成的协议来定义数据类型。在任何一种情况下，这些包含在SOAP消息中的 定义都不是显式的。
最后，为了进行RPC，需要一种低级协议如HTTP。尽管SOAP 1.0规范强制要求 使用HTTP作为传输协议，但SOAP
1.1规范（及其姊妹规范“带有附件的SOAP消息” ）允许使用FTP、SMTP、甚至（可能）原始的TCP/IP套接字。所有这些对SOAP通用
的序列化和编码规则，也适用于RPC参数。
SOAP - SOAP用例
Internet上某些地方的客户端应用程序使用Web服务。
Web服务（通过SOAP）显示对象方法。
对象方法访问Web上任意位置的远程数据。
对这些网络命题应用传递逻辑，我们可以为Web服务和SOAP下一个总的结论：
某些位置的客户端可以使Web上任意位置的数据。这就是所要证明的。
下面是更加详细一点的用例。
SOAP客户端使用UDDI注册来查找Web服务。不用直接操作WSDL，大多数情况下SOAP应用程序将硬连接到使用特定类型的端口和特定样式的绑定，并且它将 通过UDDI动态配置要调用的、与发现的Web服务匹配的服务地址。
客户端应用程序创建SOAP消息，它是一个可执行想要的请求/响应操作的 XML文档。
客户端把SOAP消息传送给监听SOAP请求的Web服务器上的JSP或ASP页面。
SOAP服务器解析SOAP包并在其领域调用合适的对象方法，在SOAP文档中包
含的参数中传递。在SOAP服务器接收消息之前，中间处理节点可以执行SOAP报 头指示的特殊功能，可视情况确定是否执行这步操作。
请求对象执行指示的功能，并返回数据给SOAP服务器，它把响应打包到
SOAP封套中。服务器把SOAP封套包裹在要发送回请求机器的响应对象中，如 servlet或COM对象。
客户端接收对象，剥离出SOAP封套并把响应文档发送给最初发出请求的程 序，完成请求/响应循环。
SOAP - 小结
SOAP是一种基于XML的协议，它用于在分布式环境中发送消息，并执行远程过 程调用。使用SOAP，不用考虑任何特定的传输协议（尽管通常选用HTTP协议）， 就能使数据序列化。用SOAP来构建平台与语言中性的互操作系统是一个好的选择。总之，SOAP和 Web服务已为在XML上构建分布式应用程序基础结构所需的一切都考虑好了。通过
解决COM和Java组件对象模型之间的冲突，SOAP把多个平台在访问数据时所出现的 不兼容性问题减至最少。先把这些讨论放在一边，SOAP是一种适用于所有类型的对象实体的理想的媒介 即使对于像Brad Pitt和Edward Norton之类的好莱坞电影角色也可用作 一种通信媒介。就像在电影中一样，期待着这种新技术带来震撼世界的效果。
RPC-----------------------------
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
目录
编辑本段基本简介
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。
编辑本段工作原理
运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：
1.调用客户端句柄；执行传送参数
4.服务器句柄得到消息并取得参数
5.执行远程过程
6.执行的过程将结果返回服务器句柄
7.服务器句柄返回结果，调用远程系统内核
8.消息传回本地主机
10.客户接收句柄返回的数据
RPC OVER HTTP
Microsoft RPC-over-HTTP 部署(RPC over HTTP)允许RPC客户端安全和有效地通过Internet 连接到RPC 服务器程序并执行远程过程调用。这是在一个名称为RPC-over-HTTP 代理，或简称为RPC 代理的中间件的帮助下完成的。
RPC 代理运行在IIS计算机上。它接受来自Internet 的RPC 请求，在这些请求上执行认证，检验和访问检查，如果请求通过所有的测试，RPC 代理将请求转发给执行真正处理的RPC 服务器。通过RPC over HTTP，RPC客户端不和服务器直接通信，它们使用RPC 代理作为中间件。
编辑本段协议结构
远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。信息流程如下所示：
RPC：远程过程调用流程
RPC 调用信息：每条远程过程调用信息包括以下无符号整数字段，以独立识别远程过程：
程序号（Program number）
程序版本号（Program version number）
过程号（Procedure number）
RPC 调用信息主体形式如下：
struct call_body {
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;
opaque_auth verf;
1 parameter
2 parameter . . . }；
RPC 答复信息：RPC 协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。答复信息请求包括区别以下情形的各种信息：
RPC 成功执行调用信息。.
RPC 的远程实现不是协议第二版，返回 RPC 支持的最低和最高版本号。
在远程系统中，远程程序不可用。
远程程序不支持被请求的版本号。返回远程程序所支持的最低和最高版本号。
请求的过程号不存在。通常是呼叫方协议或程序差错。
RPC答复信息形式如下：
enum reply_stat stat
{MSG_ACCEPTED = 0,
MSG_DENIED = 1 }；
