soap协议什么是SOAP啊

http是传输层协议 soap是应用层协议么

首先需要DNS服务器将这个URL的服务器IP找到，使用的应用层协议是DNS协议，传输层是UDP协议；然后得到了IP地址后就通过http协议去访问该服务器，传输层用的是TCP协议，要下载原始文件用的应用层协议是FTP，传输层用的是TCP协议。

web service 协议

没写过web service的东西，是不是提供一种以XML为传输介质的服务？ 下面是网上摘抄的 -------------------------------- 1 Web Service的传输协议概述 Web Service的传输协议概述在ASP.NET 中，XML Web Service支持3种协议来与用户交流数据。

这3种协议分别是： 1．HTTP-GET 2．HTTP-POST 3．SOAP 在这3种协议中，HTTP(Hypertext Transfer Protocol)已经是众所周知的协议了，它是XML Web Service数据传输的标准，其中包括使用SOAP传输数据。

HTTP将SOAP消息压缩,然后以HTTP传输协议的形式进行网络传输。

然而在XML Web Service下使用HTTP-GET和HTTP-POST的时候，事实上是指有关单独使用HTTP调用XML Web Service中的方法的能力，而不使用SOAP。

在HTTP中，GET和POST并不是一种协议，它们是可以用来与Web Service交互的几种方法中的其中两种。

然而，这二种方法的传送参数和数据的能力使它们变成了一种简单的，非常适合用来调用XML Web Service的工具。

SOAP是XML Web Service最常用到的连接协议。

与HTTP相比，SOAP显的更为复杂，但却拥有更强的接受能力。

SOAP是一种以XML为基础的协议，它提供一种将数据打包（Packaging）和编码（Encoding）的方法，以用于网络的数据传输。

任意一个用户都可以使用SOAP协议与任何一个XML Web Service进行通信，甚至于这个XML Web Service不是建立在.NET 平台上的，比如说Java的，都可以利用SOAP来进行数据传输。

因此可见，SOAP也是Language Independent(语言独立性)。

2 HTTP-GET和HTTP-POSTHTTP-GET 和 HTTP-POST 是使用 HTTP（超文本传输协议）谓词以及与之关联的请求语义将参数作为名称/值对编码和传递的标准协议。

每个协议都由一系列 HTTP 请求头组成，这些头与一些其他信息一起定义客户端向服务器请求的内容，而在成功时，服务器将用一系列 HTTP 响应头和所请求的数据响应。

HTTP-GET的处理特征如下： l 将数据添加到URL。

l 利用一个问号（“?”）代表URL地址的结尾与数据的开端。

l 每一个数据的元素以 名称/值的形式出现。

l 利用一个分号(“;”)来区分多个数据元素。

HTTP-POST的处理特征如下： l 将数据包括在HTTP主体中。

l 同样的，数据的元素以名称/值的形式出现。

l 但是每一个数据元素分别占用主体的一行。

3 SOAP协议SOAP（Simple Object ess Protocol）简单对象访问协议，它是轻型协议，用于分散的、分布式计算环境中交换信息。

SOAP有助于以独立于平台的方式访问对象、服务和服务器。

它借助于XML，提供了HTTP所需的扩展。

SOAP协议规范由4个主要的部分组成。

第一部分：SOAP封装（Envelop）定义了一个描述消息的内容多少、谁发送、谁应当接受并且处理以及如何处理它们的框架。

第二部分：SOAP编码规则（Encoding Rules）定义了可选数据编码规则，用于表示应用程序定义的数据类型和直接图表，以及一个用于序列化非语法数据模型统一标准。

第三部分：SOAP RPC表示（RPC Representation）定义一个远程调用风格（请求/响应）信息交换的模式。

第四部分：SOAP绑定（Binding）定义了SOAP和HTTP之间的绑定和使用底层协议的交换。

SOAP协议可以简单地理解为：SOAP=RPC+HTTP+XML，即采用HTTP作为通信协议，RPC作为一致性的调用途径，XML作为数据传送的格式，从而允许服务提供者和服务客户经过防火墙在上进行通信交互。

soap有哪些常用的协议和规范

SOAP协议规范 1. 简介 SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。

SOAP本身并没有定义任何应用程序语义，如编程 模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。

这使SOAP能够被 用于从消息传递到RPC的各种系统。

SOAP包括三个部分 SOAP封装（见第4节）结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。

SOAP编码规则（见第5节）定义了用以交换应用程序定义的数据类型的实例的一系列机制。

SOAP RPC表示（见第7节）定义了一个用来表示远程过程调用和应答的协定。

虽然这三个部分都作为SOAP的一部分一起描述，但它们在功能上是相交的。

特别的，封装和编码规则是在不同的名域中定义的，这种模块性的定义方法增 加了简单性。

在SOAP封装，SOAP编码规则和SOAPRPC协定之外，这个规范还定义了两个协议的绑定，描述了在有或没有HTTP扩展框架[6]的情 况下，SOAP消息如何包含在HTTP消息[5]中被传送。

1.1 设计目标 SOAP的主要设计目标是简单性和可扩展性，这意味着传统的消息系统和分布对象系统的某些性质不是SOAP规范的一部分。

这些性质包括： 分布式碎片收集 成批传送消息 对象引用（要求分布式碎片收集） 激活机制（要求对象引用） 1.2 符号约定 这篇文章中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和"OPTIONAL"的解释在RFC-2119 [2]中。

这篇文章中用到的名域前缀 "SOAP-ENV" 和"SOAP-ENC"分别与"/soap/envelope/" 和"/soap/encoding/"关联。

整篇文档中，名域前缀“xsi”被假定为与 URI"/1999/XMLSchema-instance“（在XMLSchema规范[11]定义）相连。

类似 的，名域前缀”xsd“被假定为与URI"/1999/XMLSchema"（在[10]中定义）相连。

名域前 缀”tns“用来表示任意名域。

所有其它的名域前缀都只是例子。

名域URI的基本形式”some－URI“表示某些依赖于应用程序或上下文的URI[4]。

这个规范用扩展BNF（在RFC－2616[5] 描述）描述某些结构。

1.3 SOAP消息举例 在这个例子中，GetLastTradePrice SOAP 请求被发往StockQuote服务。

这个请求携带一个字符串参数和ticker符号，在SOAP应答中返回一个浮点数。

XML名域用来区分SOAP标志 符和应用程序特定的标志符。

这个例子说明了在第6节中定义的HTTP绑定。

如果SOAP中管理XML负载的规则完全独立于HTTP是没有意义的，因为事实 上该负载是由HTTP携带的。

在Appendix A中有更多的例子。

例1 在HTTP请求中嵌入SOAP消息 POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="/soap/envelope/" SOAP-ENV:encodingStyle="/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 下面是一条应答消息，包括HTTP消息，SOAP消息是其具体内容 ： 例2 在HTTP应答中嵌入SOAP消息 HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="/soap/envelope/" SOAP-ENV:encodingStyle="/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> . SOAP消息交换模型 SOAP消息从发送方到接收方是单向传送，但正如上面显示的，SOAP消息经常以请求/应答的方式实现。

SOAP实现可以通过开发特定网络系统的特 性来优化。

例如，HTTP绑定（见第6节）使SOAP应答消息以HTTP应答的方式传输，并使用同一个连接返回请求。

不管SOAP被绑定到哪个协 议，SOAP消息采用所谓的”消息路径“发送，这使在终节点之外的中间节点可以处理消息。

一个接收SOAP消息的SOAP应用程序必须按顺序执行以下的动 作来处理消息：识别应用程序想要的SOAP消息的所有部分 （见4.2.2节）检验应用程序是否支持第一步中识别的消息中所有必需部分并处理它。

如果不支持，则丢弃消息（见4.4节）。

在不影响处理结果的情况下， 处理器可能忽略第一步中识别出的可选部分。

如果这个SOAP应用程序不是这个消息的最终目的地，则在转发消息之前删除第一步中识别出来的所有部分。

为了正 确处理一条消息或者消息的一部分，SOAP处理器需要理解：所用的交换方式（单向，请求/应答，多路发送等等），这种方式下接收者的任务，RPC机制（如 果有的话）的使用（如第7节中所述），数据的表现方法或编码，还有其它必需的语义。

尽管属性（比如SOAP encodingstyle，见4.1.1节）可以用于描述一个消息的某些方面，但这个规范并不 强制所有的接收方也必须有同样的属性并取同样的属性值。

举个例子，某一特定的应用可能知道一个元素表示一条遵循第7节约定的RPC请求，但是另外一些应用 可能认为指向该元素的所有消息都用单向传输，而不是类似第7节的请求应答模式。

（译者注：交互双方的SOAP消息并不一定要遵循同样的格式设定，而只需要以一种双方可理解的格式交换信息就可以了） 3. 与XML的关系 所有的SOAP消息都使用XML形式编码（更多有关XML的信息请见[7]）一个SOAP应用程序产生的消息中，所有由SOAP定义的元素和属性中 必须包括正确的名域。

SOAP应用程序必须能够处理它接收到的消息中的SOAP名域（见4.4节），并且它可以处理没有SOAP名域的SOAP消息，就象 它们有正确的名域一样。

SOAP定义了两个名域（更多有关XML名域的信息请见[8]） SOAP封装的名域标志符是"/soap/envelope/" SOAP的编码规则的名域标志符是"/soap/encoding/" SOAP消息中不能包含文档类型声明，也不能包括消息处理指令。

[7] SOAP使用"ID"类型"id"属性来指定一个元素的唯一的标志符，同时该属性是局部的和无需校验的。

SOAP使用"uri-reference"类型 的"href"属性指定对这个值的引用，同时该属性是局部的和无需校验的。

这样就遵从了XML规范[7]，XMLSchema规范[11]和XML连接语 言规范[9]的风格。

除了SOAP mustUnderstand 属性(见4.2.3节）和SOAPactor属性(见4.2.2节）之外，一般允许属性和它们的值出现在XML文档实例或Schema中（两者效果相 同）。

也就是说，在DTD或Schema中声明一个缺省值或固定值和在XML文档实例中设置它的值在语义上相同。

4. SOAP封装 SOAP消息是一个XML文档，包括一个必需的SOAP封装，一个可选的SOAP头和一个必需的SOAP体。

在这篇规范剩余部分中，提到SOAP消息时就是指这个XML文档。

这一节中定义的元素和属性的名域标志符为： "/soap/envelope/" 。

一个SOAP消息包括以下部分：1.在表示这个消息的XML文档中，封装是顶层元素。

2.应用SOAP交换信息的各方是分散的且没有预先协定，SOAP 头提供了向SOAP消息中添加关于这条SOAP消息的某些要素(feature)的机制。

SOAP定义了少量的属性用来表明这项要素（feature）是 否可选以及由谁来处理。

（见4.2节）3.SOAP体是包含消息的最终接收者想要的信息的容器（见4.3节）。

SOAP为SOAP体定义了一个Fault 元素用来报告错误信息。

语法规则如下所示： 封装 元素名是 "Envelope" 在SOAP消息中必须出现。

可以包含名域声明和附加属性。

如果包含附加属性，这些属性必须限定名域。

类似的，"Envelope"可以包含附加子元素，这些也必须限定名域且跟在SOAP体元素之后。

SOAP头 （见4.2节） 元素名是"Header" 在SOAP消息中可能出现。

如果出现的话，必须是SOAP封装元素的第一个直接子元素。

SOAP头可以包含多个条目，每个都是SOAP头元素的直接子元素。

所有SOAP头的直接子元素都必须限定名域。

SOAP体 （见4.3节） 元素名是"Body" 在SOAP消息中必须出现且必须是SOAP封装元素的直接子元素。

它必须直接跟在SOAP头元素（如果有）之后。

否则它必须是SOAP封装元素的第一个直接子元素。

SOAP体可以包括多个条目，每个条目必须是SOAP体元素的直接子元素。

SOAP体元素的直接子元素可以限定名域。

SOAP定义了SOAPFault元素来表示错误信息。

4.1.1 SOAP encodingStyle属性 EncodingStyle全局属性用来表示SOAP消息的序列化规则。

这个属性可以在任何元素中出现，作用范围与名域声明的作用范围很相似，为这 个元素的内容和它的所有没有重载此属性的子元素。

SOAP消息没有定义缺省编码。

属性值是一个或多个URI的顺序列表，每个URI确定了一种或多种序列化 规则，用来不同程度反序列化SOAP消息，举例如下： "/soap/encoding/" "http://my.host/encoding/restrictedhttp://my.host/encoding/" "" 第5节中定义的序列化规则由URI"/soap/encoding/" 确定。

使用这个特定序列化规则的消息应该用encodingStyle属性说明这一点。

另外，所有 以"/soap/encoding/"开头的URI中的序列化规则与第5节中定义的SOAP编码规 则相一致。

一个零长度的URI（""）明确显示所含元素没有任何编码形式。

这可以用来取消上一级元素的所有编码声明。

4.1.2 封装版本模型 SOAP没有定义常规的基于主版本号和辅版本号的版本形式。

SOAP消息必须有一个封装元素与名 域"/soap/envelope/"关联。

如果SOAP应用程序接收到的SOAP消息中的 SOAP封装元素与其他的名域关联，则视为版本错误，应用程序必须丢弃这个消息。

如果消息是通过HTTP之类的请求/应答协议收到的，应用程序必须回答一 个SOAP VersionMismatch 错误信息（见4.4节）。

4.2 SOAP头 SOAP为相互通信的团体之间提供了一种很灵活的机制：在无须预先协定的情况下，以分散但标准的方式扩展消息。

可以在SOAP头中添加条目实现这种 扩展，典型的例子有认证，事务管理，支付等等。

头元素编码为SOAP封装元素的第一个直接子元素。

头元素的所有直接子元素称作条目。

条目的编码规则如下： 一个条目有它的完整的元素名（包括名域URI和局部名）确定。

SOAP头的直接子元素必须有名域限制。

SOAP encodingStyle属性可以用来指示条目所用的编码形式（见4.1.1节） SOAP mustUnderstand属性（见4.2.3节）和SOAPactor属性（见4.2.2节）可以用来指示如何处理这个条目以及由谁来处理。

（见4.2.1节） 4.2.1 使用头属性 这一节中定义的SOAP头属性确定了SOAP消息的接收者应该怎样按第2节中所述的方式处理消息。

产生SOAP消息的SOAP应用程序，应该仅仅在 SOAP头元素的直接子元素中使用这些SOAP头属性。

SOAP消息的接收者必须忽略所有不在SOAP头元素的直接子元素中SOAP头属性。

下面的例子是 一个SOAP头，包括一个元素标志符"Transaction"，"mustUnderstand"取值为"1"和数值5。

这应该以如下方式编码： <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> 4.2.2 SOAP actor属性 一个SOAP消息从始节点到终节点的过程中，可能沿着消息路径经过一系列SOAP中间节点。

一个SOAP中间节点是一个可以接收转发SOAP消息的 应用程序。

中间节点和终节点由URI区分。

可能SOAP消息的终节点并不需要所有部分，而在消息路径上的一个和几个中间节点可能需要这些内容。

头元素的接 收者扮演的角色类似于一个过滤器，防止这些只发给本接受者的消息部分扩散到其它节点。

即一个头元素的接收者必须不转发这些头元素到SOAP消息路径上的下 一个应用程序。

同样的，接收者可能插入一个相似的头元素。

SOAP actor全局属性可以用于指示头元素的接收者。

SOAP actor属性的值是一个URI。

URI "/soap/actor/next"指出了第一个处理这个消息的SOAP应用程序需要这个头元 素。

这类似于HTTP头中用Connection域表示hop-by-hop范围模型。

省略SOAP actor属性表示接收者是SOAP消息的终节点。

如果这个属性要生效，它必须出现在SOAP消息实例中。

（见第3节和4.2.1节） 4.2.3 SOAP mustUnderstand属性 SOAP mustUnderstand全局属性用来指示接受者在处理消息时这个条目是否必须处理。

条目的接收者由SOAP actor属性定义（见4.2.2节）。

MustUnderstand属性的值是"1" 或 "0"。

缺少SOAP mustUnderstand属性在语义上等同于它的值为"0"。

如果一个头元素的SOAP mustUnderstand属性的值是"1",那么条目的接受者必须或者遵守语义（如以元素的全名传送）并按照语义正确的处理，或者放弃处理消息（见 4.4节）。

SOAP mustUnderstand 属性考虑了消息演变的准确性（robust evolution）。

必须假定包含SOAP mustUnderstand属性且值为"1"的元素以某种方式修改了它们的父元素或同层元素的语义。

以这种方式连接元素确保了语义上的变化不会被那些不 能完全理解它的接收者忽略。

如果这个属性要生效，它必须出现在SOAP消息实例中。

（见第3节和4.2.1节） 4.3 SOAP体 SOAP体元素提供了一个简单的机制，使消息的最终接收者能交换必要的信息。

使用体元素的典型情况包括配置RPC请求和错误报告。

体元素编码为 SOAP封装元素的直接子元素。

如果已经有一个头元素，那么体元素必须紧跟在头元素之后，否则它必须是SOAP封装元素的第一个直接子元素。

体元素的所有 直接子元素称作体条目，每个体条目在SOAP体元素中编码为一个独立的元素。

条目的编码规则如下： 一个条目由它的元素全名（包括名域URI和局部名）确定。

SOAP体元素的直接子元素可能是名域限制的。

SOAP encodingStyle属性可能用来指示条目（见4.1.1节）的编码方式。

SOAP定义了一个Fault条目用来报告错误信息。

（见4.4节） 4.3.1 SOAP头和体的关系 虽然头和体定义为独立的元素，它们实际上是有关系的。

体条目和头条目的关系如下：体条目在语义上等同于actor属性为缺省值且mustUnderstand属性值为"1"的头条目。

不使用actor属性则表示缺省的actor。

/inter999/article/details/3282408

简述soap的主要内容有哪些

SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。

SOAP本身并没有定义任何应用程序语义，如编程 模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。

soap协议和rpc协议的区别

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。

在XML远程过程调用 (XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。

　　XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。

人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。

之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

　　XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。

同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。

如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

　　随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。

W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。

与Web服务有关的标准化成果(从某种程度上说与SOAP相关或者依赖于SOAP)的数量已经倍增了到了令人惊讶的程度。

　　最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。

现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。

无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的

什么是SOAP啊

SOAP原意为Simple Object ess Protocol，是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议，可以认为SOAP是XML RPC的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML规范不同，SOAP也是Webservice采用的服务调用协议标准，因此在此就不多加阐述了