`

SOAP净化有线协议(一):SOAP基础知识

阅读更多

 许多开发者都遇到过这样的情形:一个CORBA客户程序需要获得分布式组件对象模型(DCOM)客户程序的服务,或者相反。常见的解决方案是使用一个 COM/CORBA桥。然而,这种解决方案存在许多问题。假设在两个已经很复杂的系统之间(CORBA ORB和COM之间)引入了一个新的软件,在CORBA的Internet Inter-ORB Protocol(IIOP)到DCOM的Object Remote Procedure Call(ORPC)之间,繁杂的双向转换将使得中间起桥接作用的软件变得很复杂。任何对IIOP协议和ORPC协议的修改都导致修改桥接软件。如果我说 SOAP能够缓解这个问题,你会怎么想呢?感兴趣吗?

SOAP的全称是Simple Object Access Protocol,即简单对象访问协议。简单地说,SOAP是一种有线协议,类似于CORBA的IIOP、DCOM的ORPC或Java远程方法调用的 Java远程方法协议(Java Remote Method Protocol,JRMP)。你也许会怀疑,既然已经有了那么多有线协议,为什么我们还需要另外一种?事实上,这不正好导致前面所讨论的问题吗?这些问 题都有道理,但是,SOAP和其他有线协议有所不同。

我们来分析一下:

  • IIOP、ORPC和JRMP都是二进制协议,而SOAP则是一种使用XML的以文本为基础的协议。利用XML进行数据编码 为SOAP带来一些独一无二的功能。例如,调试以SOAP为基础的应用程序更容易,因为阅读XML要比阅读二进制数据容易得多。另外,由于所有的SOAP 消息都是文本格式,和IIOP、ORPC或者JRMP相比,SOAP更容易和防火墙 协作。
  • SOAP 协议以非供应商私有的协议为基础,即XML、HTTP和Simple Mail Transfer Protocol(SMTP),所有供应商都可以使用SOAP协议。例如,Microsoft和各个CORBA ORB供应商(例如Iona)一样,已经承诺支持SOAP。IBM在创建SOAP协议的过程中起到了重要的作用,它也为Java程序员创建了一个优秀的 SOAP工具包。该公司已经把工具包捐赠给Apache Software Foundation的XML Project,后者以该软件包为基础,构造出了Apache-SOAP实现。这个实现在Apache许可之下免费提供给用户。再返回来看本文开头提出的 问题,如果DCOM使用SOAP,ORB供应商也使用了SOAP,那么,COM/CORBA协同操作中出现的问题将变得不值一提。


SOAP决不只是一个漂亮的口号,它是一种即将深入渗透到未来分布式计算的技术。人们希望,SOAP结合其他技术,比如UDDI(Universal Discovery Description, and Integration)和WSDL(Web Services Description Language),在Web服务这一概念的支持下,改变未来商业应用跨越Web进行通信的方法。我甚至无法充分地表达出在开发者的工具包中加上SOAP 知识的重要程度。这是一个关于SOAP的系列文章,总共四篇。这是第一篇,介绍一些基础知识。我们将从SOAP这一思想的构思说起。

一、SOAP简介
如前所述,SOAP用XML作为数据编码格式。用XML作为数据编码格式并非SOAP的原创,实际上这是一种相当自然的选择。XML-RPC和ebXML也同样使用XML。要了解这方面的更多信息,请参见本文最后的“参考资源”。

请考虑下面的Java接口:

Listing 1

public interface Hello
{
public String sayHelloTo(String name);
}


客户程序在调用sayHelloTo()方法时提供了一个名字,它希望从服务器接收到一则个性化的“Hello”信息。现在,假定RMI、CORBA和 DCOM都不存在,开发者必须负责串行化方法调用,并把消息发送给远程机器。几乎所有的人都会说“这该使用XML”,我同意。因此,让我们先从对服务器的 请求格式开始。假设要模拟sayHelloTo("John")调用,我打算发送的请求是:

Listing 2

<?xml version="1.0"?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello>


在这里,我把接口的名字作为根结点。另外,我还把方法名字和参数名字都当作节点。接下来,我们要把这个请求发送给服务器。我们不创建自己的TCP/IP消 息,而是使用HTTP。因此,下面的步骤应该是把请求封装成HTTP POST请求格式,然后把它发送给服务器。实际创建该HTTP POST请求的详细过程在本文后面介绍,现在,我们先假定它已经创建完毕。服务器接收到了这个请求,解码XML,然后再以XML格式向客户程序发送应答。 假设应答内容如下:

Listing 3

<?xml version="1.0"?>
<Hello>
<sayHelloToResponse>
<message>Hello John, How are you?</message>
</sayHelloToResponse>
</Hello>


根节点仍然是接口的名字Hello。但这一次,原来对应着方法的节点名字不再是sayHelloTo,而是方法的名字加上“Response”字符串。客 户程序知道自己调用了哪一个方法,要找出被调用方法的返回值,它只需查看名字为方法名字加上“Response”字符串的元素。

以上就是SOAP的根本思路。Listing 4显示了同一请求用SOAP XML编码之后的结果:

Listing 4

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


看起来稍微复杂了一点,对吧?实际上,它和我们前面编写的请求类似,只是略微扩展了一些东西。首先,注意SOAP文档通过一个Envelope(根节 点)、一个Header区、一个Body区,整洁地组织到一起。Header区用来封装那些与方法本身无直接关系的数据,提供环境方面的信息,比如事务 ID和安全信息。Body区包含面向方法本身的信息。在Listing 2中,我们自己编写的XML只包含一个Body区。

第二,注意Listing 4大量地应用了XML名称空间。SOAP-ENV映射到名称空间http://schemas.xmlsoap.org/soap/envelope /,xsi映射到http://www.w3.org/1999/XMLSchema-instance,而xsd映射到http: //www.w3.org/1999/XMLSchema。这三者是所有SOAP文档都拥有的标准名称空间。

最后,在Listing 4中,接口名称(即Hello)不再象在Listing 2中那样成为节点的名字;相反,它引用了一个名称空间nsl。另外,参数的类型信息也随同参数的值一起发送给了服务器。注意信封 (Envelope)encodingStyle属性的值。这个属性值设置成了http://schemas.xmlsoap.org/soap /encoding/。这个值告诉服务器用来编码(即串行化)方法的编码方式;服务器需要这个信息,以便正确地解除方法的串行化。对于服务器来 说,SOAP文档的自我描述能力是相当完善的。

对于上面的SOAP请求,服务器的应答如下:

Listing 5

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-nstance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Listing 5与Listing 4的请求消息类似。在上面的代码中,返回值(即个性化的“Hello”消息)包含在Body区。SOAP消息文档的格式非常灵活。例如,编码方式不固定, 而是由客户程序指定。只要是客户程序和服务器都认可的编码方式,可以是任何合法的XML文档。

另外,分离调用环境信息意味着方法本身并不关心这类信息。在当前的市场上,主流应用服务器都遵从这一理念。早先,我曾经指出环境信息可以包含事务和安全方面的信息。事实上,环境可以涵盖几乎所有的东西。下面是一个SOAP消息头的例子,它带有一些事务方面的信息:

Listing 6

<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>


名称空间t映射到了与特定应用有关的URI。这里的5表示的是该方法从属于其中的事务ID。注意SOAP信封mustUnderstand属性的应用。这 个属性被设置成了1,它表示服务器要么理解并按照要求处理该事务请求,要么表示无法处理该请求;这是SOAP规范所要求的。

二、错误处理
使用SOAP并不意味着任何时候所有的请求都会获得成功。许多地方可能会出现差错。例如,服务器可能无法访问某个关键性的资源(比如数据库),因而无法顺利地处理请求。

让我们返回“Hello”实例,为它加上一个假想的约束,即“在星期二向别人说Hello不合法。”因此,星期二的时候,即使发送给服务器的请求是合法的,服务器也会把一个错误信息返回给客户端。应答内容将如下所示:

Listing 7

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
<e:myfaultdetails xmlns:e="Hello">
<message>
Sorry, my silly constraint says that I cannot say hello on Tuesday.
</message>
<errorcode>
1001
</errorcode>
</e:myfaultdetails>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


我们来分析一下http://schemas.xmlsoap.org/soap/envelope/名称空间定义的Fault元素。Fault元素总是 Body元素的直接子元素,所有的SOAP服务器必须始终通过该元素报告所有错误情况。Fault元素必须包含faultcode和 faultstring元素,不能有例外。faultcode是一个能够标识问题的代码;客户程序按照SOAP规范的要求利用faultcode进行算法 处理。SOAP规范定义了一小组错误代码供用户使用。另一方面,faultstring是供人类阅读的错误信息。

Listing 7的代码还包含了一个detail元素。由于错误在处理SOAP消息的Body区时出现,detail元素必须出现。正如你将在本文后面看到的,如果错误 在处理Header区时出现,detail元素不应出现。在Listing 7中,应用利用detail元素提供当前错误更详细、更自然的解释,即星期二不允许说Hello。SOAP还提供另外一个面向具体应用的错误代码,即半可 选的faultfactor元素,但上面的错误信息中没有显示这个元素。之所以称这个元素是半可选的,是因为如果错误消息不是由请求最终处理点的服务器发 送,即由一个中间服务器发送,则错误消息必须包含该元素。SOAP对faultcode元素不应出现的情形没有作任何规定。

在Listing 7中,错误起源于方法调用本身,处理该方法的应用导致了这个错误。现在,我们来看一下另一种类型的错误,这种错误由于服务器不能处理请求头信息而导致。举例来说,假设所有的Hello消息必须在一个事务环境之内生成,则请求类似于:

Listing 8

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI"
SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">Tarak</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


上面消息的Header区包含一个transaction元素,它指定了方法调用必须从属于其中的事务编号。这里我说“必须”是因为 transaction元素使用了mustUnderstand属性。如前所述,SOAP服务器要么遵照属性的指示处理请求,要么声明不能处理请求。假定 SOAP服务器不能处理,它必须返回一个错误信息。这时的应答应该类似于:

Listing 9

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
<faultstring>SOAP Must Understand
Error</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


上面的代码类似Listing 7显示的错误信息。但应该注意的是,detail元素不再出现。正如我在前面指出的:SOAP规范规定,如果错误在处理Header区的时候出现,则错误 消息中不应包含detail元素。事实上,我们可以根据detail元素是否出现,迅速判定错误是在处理Body区还是在处理Header区时出现。

三、SOAP与HTTP
在第一个例子中,我通过HTTP把定制的XML请求发送给服务器,但没有详细介绍这么做涉及到了哪些操作。现在我们回过头来看那个问题。怎样才能把一个 SOAP请求(而不是定制的XML)通过HTTP发送给服务器?SOAP很自然地遵循了HTTP的请求/应答消息模型。这个模型在HTTP请求中提供 SOAP请求参数,在HTTP应答中提供SOAP应答参数。实际上,SOAP 1.0特别指明HTTP作为它的传输协议。SOAP 1.1略有放松。虽然SOAP 1.1仍旧可以使用HTTP,但它也可以使用其他协议,比如SMTP。在这个系列的文章中,我只讨论通过HTTP使用SOAP的情形。

让我们返回Hello示例。如果我们通过HTTP把SOAP请求发送给服务器,则代码应该类似于:

Listing 10

POST http://www.SmartHello.com/HelloApplication HTTP/1.0
Content-Type: text/xml; charset="utf-8"
Content-Length: 587
SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">Tarak</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 


Listing 10代表的SOAP请求与Listing 4的请求基本相同,但Listing 10的开头加入了一些HTTP特有的代码。第一行代码表明这是一个遵循HTTP 1.1规范的POST请求,POST的目标是http://www.SmartHello.com/HelloApplication。下一行指示内容的 类型,在HTTP消息中包含SOAP实体时,内容类型必须是text/xml。Content-Length指明了POST请求有效载荷的长度。

第四行是SOAP特有的,而且它是必不可少的。SOAPAction HTTP请求头指明了SOAP HTTP请求的目标,它的值是一个标识目标的URI。SOAP不对该URI的格式作任何限制,实际上,这个URI甚至不必对应某个实际的位置。

SOAPAction的一个可能的应用是,防火墙 检查该请求头的值,决定是否允许请求通过防火墙

一旦服务器处理完请求,它将向客户返回一个应答。应答的内容如Listing 11所示(假设没有出现错误):

Listing 11

HTTP/1.0 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are
you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 

 


这个SOAP应答与Listing 5所显示的一样,但前面加上了一些HTTP特有的代码。由于没有出现错误,第一行代码显示应答状态是200。在HTTP协议中,200应答状态代码表示“ 一切正常”。如果在处理SOAP消息(Header区或者Body区)的时候出现了任何错误,则返回的状态代码将是500。在HTTP中,500状态代码 表示“internal server error”。此时,上述SOAP应答的第一行代码将是:

HTTP 500 Internal Server Error


四、HTTP扩充框架
许多应用对服务的需求超过了传统HTTP提供的服务。其结果就是,这类应用扩充了传统的HTTP协议。然而,这种扩充是应用本身私有的。HTTP扩充框架 试图确立一个通用的HTTP扩充机制,从而解决这个问题。HTTP扩充框架的扩充之一是增加了一个M-POST方法,其中的M表示Mandatory(必 须遵循的,强制的)。如果一个HTTP请求包含至少一个强制的扩充声明,那么这个请求就称为强制的请求。引入强制的扩充声明通过Man或者C-Man头进 行。强制请求的请求方法名字必须带有“M-”前缀,例如,强制的POST方法称为M-POST。

SOAP 1.0要求客户程序首先发送一个HTTP POST请求,只有当服务器返回错误510时才发送M-POST请求。SOAP 1.1不再对客户作这种限制,也就是说,SOAP 1.1允许客户从发送任何一种类型的请求开始。下面的请求就是迄今为止我们一直在讨论的那个请求,但它现在是M-POST格式:

Listing 12

M-POST http://www.SmartHello.com/HelloApplication HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: 587
Man: "http://schemas.xmlsoap.org/soap/envelope/"; ns=01
01-SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">Tarak</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


对于实际的SOAP消息来说,Listing 12和Listing 10没有什么不同。但请求头中有一些不同的地方,例如,现在我们发出的不是POST请求,而是一个M-POST请求。正如前面所介绍的,象M-POST这 样的强制请求至少有一个强制扩充声明。这里我们就有一个:Man域描述了一个强制性的端到端扩充声明,把头前缀01映射到了名称空间 http://schemas.xmlsoap.org/soap/envelope/。请注意这个前缀关联到SOAPAction域的方式。

一旦服务器处理完该请求,它将返回一个应答给客户。应答内容类如(假设没有出现错误):

Listing 13

HTTP/1.0 200 OK
Ext:
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are
you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


同样地,Listing 13显示的应答类似于对普通POST请求的应答(如Listing 11所示),两者的不同之处在于Ext域。

在通过HTTP使用SOAP的过程中,我们欣喜地看到,实际的SOAP消息(SOAP信封和它里面的所有内容)总是保持不变,就如消息尚未加载HTTP协 议时一样。根据这一事实可以推断出,HTTP不是能够与SOAP协作的唯一协议。例如,SOAP可以方便地和SMTP协议或者其他定制的私有协议一起运 行。唯一的要求是两者——客户端和服务器端——都理解该协议。

五、SOAP的特点:简单
至此为止,我们讨论了SOAP定义的方方面面,但有许多领域的问题SOAP没有定义。SOAP规范的创立者明确地排除了一些关系密切的领域,比如构造对象模型,还有其他许多已经确立的标准。

造成这种现象的原因可以从分析SOAP的目标理解。SOAP的目标除了扩展性之外,另一个主要的设计目标是简单。为了保持SOAP简单,SOAP规范的创 立者决定,只定义那些对于创建一个轻型协议来说绝对必须的东西。例如,SOAP没有定义/指定任何有关分布式垃圾收集、类型安全或版本控制、双向HTTP 通信、消息盒(Message-box)运输或管道处理、对象激活等方面的内容。SOAP的目标就是成为一种简单的协议——一种在任何操作系统上,单个开 发者能够用任何语言化数天时间实现的协议。考虑到这一点,SOAP在许多方面没有作出明确定义实际上是一件好事,因为在构造分布式系统时,所有现有的技术 都可以方便地采用SOAP,即使不同技术之间的差异象CORBA和DCOM的差异那样明显。

■ 结束语
在这篇文章中,我介绍了SOAP的一些基本概念,以及它之所以如此设计的一些原因。然而,相对于SOAP这座冰山来说,这只是它的一角。要查看有关 SOAP的更多信息,请查阅参考资源部分给出的SOAP规范链接。随着本系列文章的展开,我将在这里介绍有关SOAP规范所有你必须了解的知识。

在第二部分中,我将介绍Apache的SOAP实现。我们将使用该实现,创建一个利用SOAP作为有线协议的简单分布式应用

分享到:
评论

相关推荐

    SOAP资料,介绍SOAP协议

    **SOAP(Simple Object Access Protocol)协议**是一种基于XML(Extensible Markup Language)的协议,用于在Web服务中传递结构化和类型化的信息。SOAP允许应用程序通过HTTP、SMTP等传输协议进行通信,使得不同系统...

    SOAP:XML跨平台Web Service开发技术

    ### SOAP:XML跨平台Web Service开发技术 #### 1. 简介 SOAP(Simple Object Access Protocol),即简单对象访问协议,是一种用于交换结构化信息的标准协议。它是Web服务中用于远程过程调用的主要协议之一,特别是...

    SOAP协议规范——SOAP详解

    SOAP(Simple Object Access Protocol),即简单对象访问协议,是一种基于XML(Extensible Markup Language)的协议,用于在Web服务中传递结构化的和格式化的信息。SOAP允许应用程序通过HTTP(Hypertext Transfer ...

    SOAP协议样列

    #### 一、SOAP协议简介 SOAP(Simple Object Access Protocol)是一种轻量级的协议,用于实现分布式环境中不同系统之间的交互。它的主要特点是使用XML作为数据编码格式,这种选择使得SOAP具备跨平台的特性,能够在...

    soap协议规范 soap协议规范

    2. **SOAP编码规则**:SOAP编码规则定义了一套机制,用于在消息中编码应用程序定义的数据类型。这些规则允许不同类型的数据在不同系统之间进行交换,确保数据的准确性和一致性。 3. **SOAP RPC表示**:远程过程调用...

    SOAP数据传输协议

    SOAP(Simple Object Access Protocol)是一种基于XML的网络通信协议,用于在Web服务中交换结构化和类型化的信息。它允许应用程序通过HTTP等简单协议来发送和接收数据,从而实现跨平台、跨语言的通信。在“SOAP数据...

    SOAP调用webservice例子

    SOAP(Simple Object Access Protocol)是一种基于XML的协议,用于在Web服务中交换结构化和类型化信息。它允许不同系统间进行远程过程调用,即使它们运行在不同的操作系统或使用不同的编程语言。SOAP消息通常通过...

    SOAP协议规范

    它通常包含`&lt;soap:Envelope&gt;`标签。 - **Header**:可选部分,用于传递与消息处理相关的附加信息,如认证、路由指令等。它由`&lt;soap:Header&gt;`标签表示。 - **Body**:必需部分,包含了SOAP消息的主要内容,即实际的...

    SOAP协议最新规范文档

    SOAP(Simple Object Access Protocol)是一种基于XML的协议,主要用于在分散或分布的环境中交换结构化和类型化的信息。它的设计目标是简单性和可扩展性,因此它不包含一些传统消息系统和分布对象系统中的特性,如...

    soap1.1和soap1.2区别

    SOAP(Simple Object Access Protocol)是一种基于 XML 的轻量级协议,用于在网络上进行数据交换。SOAP 1.1 和 SOAP 1.2 是两个不同的版本,它们之间存在一些关键的区别。 首先,从报头信息开始,SOAP 1.1 和 SOAP ...

    soap协议规范

    SOAP(Simple Object Access Protocol)协议是一种基于XML的标准协议,用于在分散或分布环境中交换结构化和类型化的信息。它旨在为不同平台之间的通信提供一个轻量级且通用的框架,允许在异构环境下进行数据和消息的...

    SOAP协议规范(中文版).doc

    1. **SOAP消息**:SOAP消息是通过HTTP或SMTP等传输协议发送的基本单元,它是一个XML文档,包含头部(Header)和主体(Body)两部分。头部可以包含额外的信息,如安全、路由等,而主体则包含了实际的应用数据。 2. *...

    基于soap协议的post请求

    &lt;soap:Header/&gt; &lt;soap:Body&gt; &lt;Add xmlns="http://tempuri.org/"&gt; &lt;intA&gt;1 &lt;intB&gt;2 &lt;/soap:Body&gt; &lt;/soap:Envelope&gt; ``` 在这个例子中,Body内的`Add`操作表示一个加法请求,`intA`和`intB`是参数。 **iOS中...

    Laravel开发-laravel-soap Soap 协议客户端

    而`laravel-soap`是Laravel的一个扩展包,专门用于处理SOAP(Simple Object Access Protocol)协议,这是一种基于XML的网络通信协议,常用于不同系统间的远程调用和服务交互。 **SOAP协议简介** SOAP是一种轻量级的...

    soap协议规范.pdf

    - **分布式垃圾回收**:SOAP不涉及内存管理方面的内容。 - **批量消息传送**:SOAP未定义如何批量发送消息。 - **对象引用**:这通常需要分布式垃圾回收的支持。 - **激活机制**:同样依赖于对象引用的存在。 这些...

    SOAP协议规范 中文的

    2. **SOAP编码规则**:SOAP编码规则定义了如何将应用程序定义的数据类型实例化为XML格式。这使得不同系统之间可以交换复杂的数据结构。 3. **SOAP RPC表示**:这部分规定了如何表示远程过程调用和响应。SOAP允许...

    C语言版soap协议栈源代码

    3. **编码和解码机制**:SOAP协议栈需要支持数据类型的编码和解码,如基本类型(整型、浮点型等)、复杂类型(结构体、数组、枚举)以及XML Schema定义的类型。C语言版的源代码会提供这些功能的API。 4. **错误处理...

    中文Soap协议规范

    - **简单性**:SOAP协议的目的是简化分布式系统之间的通信,避免复杂的分布式对象系统特性。 - **可扩展性**:允许添加新的功能和扩展,而不影响基础协议的稳定性。 在SOAP消息的示例中,我们可以看到XML被用来创建...

    SOAP协议中文版

    SOAP(Simple Object Access Protocol)1.2是一种基于XML的协议,设计用于在分布式环境中实现结构化和类型化信息的平等交换。它强调简洁且轻量级的机制,使得不同系统间能够有效地通信。SOAP 1.2 包含四个主要组成...

Global site tag (gtag.js) - Google Analytics