资源目录
压缩包内文档预览：
编号：149922695
类型：共享资源
大小：176.04KB
格式：RAR
上传时间：2021-10-10
上传人：好资料QQ****51605
认证信息
个人认证
孙**（实名认证）
江苏
IP属地：江苏
20
积分
- 关 键 词：
-
tx092XML
解析器分析研究
解析
分析研究
- 资源描述：
-
tx092XML 解析器分析研究,tx092XML,解析器分析研究,解析,分析研究
- 内容简介：
-
江苏大学SOAP1.2版本 部分0:初级版W3C 2003年6月24日推荐这个版本:/TR/2003/REC-soap12-part0-20030624/最新的版本:/TR/soap12-part0/先前版本:/TR/2003/PR-soap12-part0-20030507/编辑:Nilo Mitra (Ericsson)请参考这个文档的勘误表,里面包括了一些标准修正.这个规范的英文版本是唯一的标准版本.当然也存在非标准的翻译版本.版权2003W3C (麻省理工学院, ERCIM, Keio),版权所有.W3C责任,商标,文件使用权,适用许可的软件.摘要SOAP1.2版本 部分0:初级版是一个非标准的文档,试图提供一本易于理解SOAP1.2版本规范的指南.特别是,它通过各种各样的使用情形描述SOAP的特征,而且试图补充包含在SOAP1.2规范的部分1和部分2中的标准正文.文档状况这个部分描述了这个文档在出版阶段的状况.其他文档也许能代替这个文档.这个文档系列最近的状况由W3C保持. 这个文档是W3C推荐.由XML协议工作组(XML Protocol Working Group)制作出来的,工作组是网络服务活动的一部分.这个文档是被W3C成员和其他为之感兴趣的团体反复检查的,并被最高执行者担保为W3C推荐.它是稳定的文档,可以作为参考资料或者被另一个文档引用为标准参考.W3C的作用是推荐以引起大家注意这个规范和促进它的普遍使用.这个能增加网络的功能和互用性.欢迎发表关于这个文档的评论.请把评论送到公共邮件列表xmlp-comments (archive).请不要把讨论的邮件送到这个地址.有关这个规范的实施信息能在这个实施报告里找到/2000/xp/Group/2/03/soap1.2implementation.html.关于这个规范的专利权能在工作组的专利权页面(patent disclosure page)上找到,与W3C政策一致.一张关于W3C推荐和其他技术报告的表能在/TR 找到.目录1导论 1.1 概述 1.2 符号约定2 基本用法 2.1 SOAP消息 2.2 SOAP消息交换2.2.1 会话式消息交换2.2.2远程调用3 SOAP处理模型 3.1 角色属性 3.2 “mustUnderstand”属性 3.3 “relay”属性4 使用不同的协议绑定 4.1 SOAP HTTP绑定4.1.1 SOAP HTTP GET使用4.1.2 SOAP HTTP POST使用4.1.3 网络架构与SOAP使用的兼容 4.2 SOAP在邮件中传送5 高级用法 5.1 使用SOAP中介 5.2 使用其他编码方案6 SOAP1.1与SOAP1.2之间的变化7 参考文献A。致谢 1 简介SOAP1.2版本部分0:初级版是一个非标准的文档,试图提供一本易于理解的关于SOAP1.2版本规范的指南.它的目的是帮助技术人员理解SOAP怎样使用,通过描述有代表性的SOAP消息结构和消息交换模型的方式.特别的,这个初级版通过各种各样的使用情形描述SOAP的特征,并且试图补充包含在SOAP1.2版本规范部分1: Messaging Framework和部分2: Adjuncts 中的标准正文.它是希望在读者对XML的基本语法熟悉的基础上,包括熟悉XML 命名空间 和 消息集的使用,还有象URIs 和 HTTP之类的网络概念.它主要面向SOAP使用者,例如应用程序设计者,而不是SOAP规范的实施者,即使后者也可能从中得到一些帮助.这个初级版目的在于突出SOAP1.2版本的本质特征,而不是着眼于每个细枝末节或者边沿问题.因此,它不能代替能完全理解SOAP的主要规范.最后，这个初级版本还提供了大量的链接，能链接到主要规范中引入和使用新概念的地方。SOAP 部分1:定义SOAP信封,即定义了描述SOAP消息内容的一个整体框架的架构,确定SOAP消息又谁全部处理或者部分处理,要处理的部分是可选的还是强制的.同时也定义了一个协议绑定框架,描述了一个如何将SOAP协议绑定到一个底层协议的规范.SOAP部分2:为SOAP定义一个数据模型.传送远程调用(RPC)的数据的一个特殊编码方案,以及在SOAP部分1定义的底层协议绑定框架的具体实现.这个绑定允许SOAP消息或者作为HTTP POST请求和响应的有效负载,或者作为在对HTTP GET的响应中的SOAP消息进行交换.这个文档(初级版)是非标准的,即它不是SOAP1.2版本的正式规范.这里提供的例子主要是为了补充正式规范,并且关于正式规范的任何解释都具有优先权.这些例子提供了可能使用SOAP的一些可能情况,在实际的使用中,SOAP最可能为整个解决方法的一部分,毫无疑问在这些例子中不可能包含全部其他的专用应用需求.1.1 概述SOAP1.2版本提供XML-based信息的定义,它能被用在交换结构化和类型化的信息位于同等的松散的、分布式环境之间. SOAP部分1指出一条SOAP消息正式指定为一个 XML Infoset,即它的内容的抽象描述. Infosets有许多不同的表达,一个普通的例子是作为一个XML 1.0文档.SOAP基本上是没有代表,单向的消息交换方式,但是应用程序能建立更加复杂的相互作用模式(例如:请求/反应,请求/多重反应,等等),通过联结这样的单向交换与由底层协议和（或）专用信息提供的特征。SOAP在传送任何专用数据语义上说是安静的，如在SOAP消息路由选择的问题，可靠数据传输，防火墙遍历等等方面。然而，SOAP提供一种框架使得专用信息也许被以一种可扩展的方式传送。还有，SOAP提供SOAP结点在接收SOAP信息的时候所采取的行动的完整描述。这个文档的第2节介绍SOAP的基本特征，从最简单的使用情形开始，即单向SOAP消息，接着是各种各样的请求-反应类型交换，包括RPCs（远程调用）。同时也描述了出差错时的情况。这个文档的第3节给出了SOAP处理模型的概述，就是描述了最初消息结构的规则，这些规则包括当中介或者是最终接收者接收时哪些消息被处理，消息的哪个部分能被中介插入删除或修改。第4节描述了SOAP消息的传输方式来实现各种各样的使用情形。它描述了指定在SOAP部分2的SOAP HTTP 绑定，还有一个关于SOAP消息怎样在邮件消息中传输的例子。作为HTTP 绑定的一部分，它介绍了两种能够应用的消息交换模式，一种是使用HTTP POST方法，另一种使用HTTP GET。同样也有关于怎样使用PRCs的例子，特别是那些表现“安全”信息检索方面的，也许能代表在SOAP消息交换中与万维网的架构原则兼容的方式。第5节说明SOAP在更复杂的使用情形中各个方面的处理。包括通过header元素使用提供的扩展机制，header元素被指定在特定中介SOAP结点以提供增值服务来传送请求，用不同的编码方案来组织在SOAP消息中的专用数据。第6节描述了在SOAP版本1.1和SOAP版本1.2之间的变化。第7节是参考文献。为了便于参考，初级版使用的术语和概念均来自主要规范的定义。1.2 符号习惯纵观全文，SOAP信封和消息范例作为XML 1.0文档。SOAP部分1指出一条SOAP消息正式指定为一个XML InfoSet,即它的内容的一个抽象描述。SOAP XML Infosets和这个文档之间的区别在于不可能让使用这个入门书作为SOAP的介绍的那些人感兴趣，那些关心的人（尤其是那些把SOAP转到新协议绑定的人使得消息具有选择代表性）应该理解这些例子作为参考相应的XML infosets。关于这一点更进一步的研究在第4节里提到。本文中使用的命名空间前缀 env, enc和rpc等关联的SOAP命名空间分别位于以下位置 /2003/05/soap-envelope , /2003/05/soap-encoding, /2003/05/soap-rpc.本文使用的命名空间前缀xs 和xsi 等关联的命名空间分别位于/2001/XMLSchema /2001/XMLSchema-instance,它们都被定义在XML Schema规范 XML Schema Part1, XML Schema Part2.注意任何另外的前缀选择都是随意的，没有明显的语义约束。命名空间URIs一般形式/. 和/.代表一个应用依赖和文本依赖的URI RFC 2396.2. 基本使用情形一条SOAP消息基本上是在SOAP结点之间的单向传输，从SOAP发送者到SOAP接收者，但是SOAP消息希望能被应用程序连结成实现更复杂的相互反应模式，从单一的请求/反应到多重，前后“会话式”交换(back-and-forth conversational exchanges)。初级版从分析一条SOAP消息的结构开始，还有简单的交换情形，以旅行预定申请为基础。关于这次申请的各个方面在整个初级版中将会用到。这种情形就是，一次旅行预定申请，是公司的一个雇员与一家旅行预定机构协商一次有计划旅行的预定服务。信息在旅行预定申请和旅行服务申请之间以SOAP消息的形式进行交换。从旅行预定申请发送来的SOAP消息的最终接收者是旅行服务申请，但是SOAP消息可能会通过一个或多个SOAP中介，它在SOAP消息中扮演不同的角色。一个简单的关于SOAP中介的例子，它可以记录审查，甚至有可能修正各自的旅行请求。更多更详细的关于SOAP中介行为作用的例子在5.1讨论。2.1节把一次旅行预定申请作为一条SOAP消息描述，提供一个机会介绍一条SOAP消息的各个方面。2.2.1节继续讨论同样的情形，另一条SOAP消息，即从旅行服务申请返回的反应，它形成了会话式消息交换的一部分，因为面临旅行请求的限制有多种选择需要协商。2.2.2节假定旅行预定的各个参数都被旅客接受，而且远程调用（PRC），在旅行预定与旅行服务申请之间确认付了订金。2.3节举出差错处理的事例。2.1 SOAP消息一条SOAP消息中一次旅行预定的数据。 Example 1 uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:20:00.000-05:00 ke Jgvan yvind New York Los Angeles 2001-12-14 late afternoon aisle Los Angeles New York 2001-12-20 mid-morning none Sample SOAP message for a travel reservation containing header blocks and a body例1的SOAP消息中包含了两个SOAP专用基本元素，一个是 env:Header，另一个是env:Body，总称为env:Envelope。这些元素的内容是申请者定义的，不是SOAP规范的一部分，虽然SOAP规范中有提到这样的元素怎样处理。一个SOAP header是可选的，但是只包含在说明SOAP的某一特性的例子中。一个SOAP header是一种扩展机制，它提供一种在SOAP消息中传输信息的方法，而不是申请的负载。象这样的“控制”信息包括：传输指令或者与消息过程相关的信息。它允许一条SOAP消息扩展为一种专用方式。 env:Header的直接子元素叫做header blocks, 表现为一个有逻辑的数据分组，如后所示，能单独的被指定在从发送者到最终接收者的SOAP消息传输路径中遇到的SOAP结点。设计SOAP headers是期望满足SOAP的各种使用，它们中许多包括参与其他SOAP过程结点（SOAP中介）顺着消息路径从最初发送者到最终接收者。它允许SOAP中介提供增值服务。Headers，如后所示，可能被沿着SOAP消息路径遇到的SOAP结点检查，插入，删除或者向前。（值得记住的是，虽然SOAP规范没有处理header元素的内容，没有说SOAP消息怎样在结点之间进行路由选择，没有决定哪种路由方式等等。这些是整个申请的一部分，也可能他规范的主题。）在env:Envelope内SOAP body是命令元素，暗示这是主要的端对端信息，它在必须被搬运的SOAP消息中传输。例1的SOAP消息图示如下：在例1中，header包括两个header blocks，每一个都有单独定义的XML空间和代表关于SOAP消息的body整个过程的各个方面。对于这次旅行预定申请，关于整个请求的“meta”信息是一个reservation header block，它保留这次示例的一个参考和时间标记，还有在passenger block中保留旅行者身份。 header blocks reservation和passenger必须被在消息路径上遇到的下一个SOAP中介处理，如果这里没有中介，则通过消息的最终接收者处理。事实上它被指定在途中遇到的下一个结点是用env:role属性的存在以及价值表示的，/2003/05/soap-envelope/role/next（此后简称“next”），它是所有结点都愿意做的。env:mustUnderstand属性的存在和价值true表示这些结点处理header必须用完全与规范一致的方式处理这些header blocks，或者根本就不去处理消息，抛出异常。注意到每当一个header block被处理，或者是因为它被标记为env:mustUnderstand=true，或者是因为这个block必须按照与规范一致的方式处理。这样的header block规范是申请定义的，不是SOAP的一部分。第三节会更详细的说明SOAP消息处理过程根据它们属性的价值。选择什么数据放在header block什么放在SOAP body是设计申请的时候决定的。最主要的一点需记住的是header blocks也许会被指定在从发送者到最终接收者整条路径上遇到的不同结点。这样的SOAP中介结点可能会在这些headers提供增值服务以数据为基础。在例1中，乘客数据被放在header block中来举例说明这个数据的使用在SOAP中介做的额外处理。例如，如后5.1节所示，他开往外地的消息是SOAP中介把属于这位旅客的旅行政策作为另外的header block添加到信息。env:Body元素和它有关的子元素, itinerary 和 lodging, 是为了在最初的SOAP发送者和SOAP结点之间交换信息，哪个结点在消息路径中假定为最后的SOAP接收者, 哪个是旅行服务申请。因此, env:Body和它的内容是暗示，期待被最后接收者理解. SOAP结点假设这样一个角色不是SOAP规范定义的，它是决定作为整个应用语义和联系消息流程的一部分。注意到一个SOAP中介也许能为了消息传送决定扮演最终接受者的角色，因此处理env:Body。然而，即使这种行为不能被防止，这也不是能被轻易对待的东西，因为它可能会曲解消息发送者的意图，而且会有不可预计的边沿反应（象是不处理header blocks可能会被指定在远离消息路径的中介）。像例1一样的一条SOAP消息可以被不同的底层协议传送和被多种消息交换模式使用。例如，对于一条旅行服务申请的基于网络的通道，它能被放在HTTP POST请求的 body部分。在另外的协议绑定中，它也许被在邮件消息中传送（看4.2节）。第4节描述SOAP消息怎样在各种底层协议中传送。暂时，我们假定这种机制存在是为了消息传送，剩下的部分集中在SOAP消息的细节和它们的处理上。2.2 SOAP消息交换SOAP1.2版本是一个为了传送信息的简单消息框架，信息为指定在最初SOAP发送者和最终SOAP接收者之间以XML infoset的形式。更多有趣的典型事例包括在两个结点之间的多重消息交换。最简单的交换是请求/反应模式。在SOAP1.1的一些早期使用中强调这种模式的使用因为这是远程调用（RPC）的方法。但重要的是注意到不是所有的SOAP请求/反应交换都能或需要象RPCS模式。使用它是当这里需要一种确定计划行为的模式，交换的信息符合预先定义的远程调用及返回的说明。比被请求/反应模式掩盖着的更大更复杂的使用情形可以看成简单的模型，作为XML-based内容在SOAP消息之间交换形成前后“会话”（ back-and-forth conversation），在语义学发送和接收申请相同水平的地方。2.2.1节包含了XML-based内容在SOAP消息中交换的例子，在旅行预定申请和旅行服务申请之间以会话式模式，而2.2.2节提供象RPC模式交换的例子。2.2.1 会话式消息交换继续刚才的旅行请求情形，例2说到一条从旅行服务返回的SOAP消息，它是例1中预定请求的反应。这个反应试图改良请求的某些信息，即离开城市机场的选择。Example 2 ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind JFK LGA EWR JFK LGA EWR SOAP message sent in response to the message in Example 1象早期的描述一样，env:Body包括消息的主要内容，在这个例子中包括了机场的各种选择，与XML命名空间的schema定义一致/reservation/travel。在这个例子中，来自于例1的header blocks返回（有些补充元素的价值改变）应答。这些允许消息在SOAP的水平上相互作用，但是这样的headers很有可能有其他的专门应用。例1与例2的消息交换是基于XML形式的例子，符合那种请求/定义模式经由SOAP消息的交换。再来，关于消息转移的方式的讨论延后至第四节。很简单的就可以知道这样的交换怎样建立成多重前后“会话式”消息交换模式。例3提到从旅行预定申请发送的一条SOAP消息回应例2的从各种可用的机场中选择一个。在这次会话中，header block reservation与每一条消息涉及到的附加元素具有相同价值，因此需要提供一种方法，使在申请水平的消息交换相互关联。Example 3 uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:36:50.000-05:00 ke Jgvan yvind LGA EWR Response to the message in Example 2 continuing a conversational message exchange2.2.2 远程程序调用SOAP1.2的其中一个设计目标是压缩远程调用的功能，利用XML的可扩展性和灵活性。SOAP第2部分第4节定义了一个在SOAP消息中运载的RPC请求和应答的统一表示法。这个部分继续旅行预定情形，举例说明SOAP消息的使用，搬运远程程序调用和它们的返回。在末尾，另一个例子说到使用信用卡付这次旅行的费用。（假定在2.2.1节中说到的那次会话式交换已经有了确定的旅程。）而且更进一步的假定付款发生在整个交易的途中，信用卡仅仅支付旅行和住宿（不是所有的例子都这样，但是可能用同样的方式预定）已确认。旅行预定申请提供信用卡信息，成功完成卡片支付的不同活动结果，还要返回一个预定代码。这种预定-支付在旅行预定申请和旅行服务申请之间的相互作用就是一个SOAP RPC模式。调用一个SOAP RPC，必须要下面的信息：1. 目标SOAP结点的地址。2. 程序和方法名称。3. 任何争执的性质和价值传到程序或方法，伴随输出参数和返回值。4. 争执的一次明显分离用来鉴定网络资源哪个是RPC的实际目标，对比那些传输数据或控制信息用来处理目标资源的调用。5. 消息交换模式被用来传输RPC，伴随一个所谓的“网络方法”的标记（哪个更接近）使用。6. 哪些数据被搬运作为SOAP header blocks的一部分是随意的。这样的信息能被很多方式表达，包括正式的接口定义语言（IDL）。注意到SOAP不支持任何IDL，正式的或非正式的。同样注意到上述的信息与一般需要调用其他过程的信息（non-SOAP RPCs）有些地方不同。关于上面的第1点，从SOAP的前景看，一个SOAP结点“包含”或“支持”RPC的目标。哪个SOAP结点(适宜)采用最终SOAP接收者的角色. 正如第一点所必须的,最终接收者能识别指定的程序和方法的目标寻找它的URI.可用来做目标URI的方式依赖于底层协议绑定.URI确定目标的一个可能性是在一个SOAP header block中被携带.一些协议绑定,例如在SOAP Part2中定义的SOAP HTTP绑定,提供一种机制在SOAP消息外面运输URI.一般说来,协议绑定规范的一个特性必须描述目标URI怎样被携带作为绑定的一部分.4.1节提供一些具体例子关于URI怎样在标准SOAP协议绑定到HTTP中被携带.上面提到的第4条和第5条必需确保RPC应用,雇用SOAP能做这些用与万维网的架构原则一致的方式.4.1.3节讨论怎样利用第4点和第5点提供的信息.剩余部分,假定RPC在SOAP消息中搬运,正如例4中所说的,适当的指定目标和分派.这个部分的目的是突出RPC请求的句法部分和在SOAP消息中携带的返回值.Example 4 5 FT35ZBQ ke Jgvan yvind 123456789099999 2005-02 SOAP RPC request with a mandatory header and two input (or in) parametersRPC本身被当做env:Body元素的一个子元素被携带，在这个chargeReservation的例子中作为一个程序和方法名的struct模型。（struct是来自于SOAP数据建模中的概念，在SOAP Part2中定义，是发生在一些共同的程序设计语言中的模型结构和记录类型。）RPC设计在这个例子中（没有正式的确切定义）取两个input（或“in”）参数，对应这次有计划的行程预定由预定代码鉴定，还有信用卡信息。后者也是一个struct，包含三个元素，卡持有者的名字，卡号，终止日期。在这个例子中， env:encodingStyle价值属性/2003/05/soap-encoding 表明chargeReservation结构的内容依照SOAP编码规则编码，例如，在SOAP第2部分第3节中定义的特殊规则。即使SOAP限定这种特殊编码规则，它的使用是可选的，而且规范清楚提到其他编码规则也能被在SOAP消息内的专用数据使用。为了这个原因，提供env:encodingStyle 属性来限制header blocks 和 body sub-elements。这个属性价值的选择是一个专用决定，访问者和被访问者之间相互作用的能力是假定安置在“带外的”（out-of-band）。5.2节说到一个使用其他编码规则的例子。正如以上第6点所示，RPCs也可能需要携带额外的信息，哪些对于在分布式环境下处理调用是重要的，而哪些不是正式的程序和方法描述的一部分。（注意到，虽然提供这样额外的上下文信息不是RPCs特定的，但是任何分布式申请的处理过程通常需要。）在这个例子中，RPC在整个交易的过程中实施，包括一些在RPC成功返回前必须完全成功的活动。例4说明一个header block直接面向最终接收者（暗示缺少env:role属性）的交易怎样用来携带这样的信息。（价值“5”是由一些交易标志符设置，对申请有意义。没有提供关于这个header的更深更详细的专用语法，因为它与SOAP RPC 消息语法方面并不是密切相关。）让我们假设RPC在这个交易的例子中被设计成有过程描述，暗示这里有两个output（或“out”）参数，一个提供这次预定的参考代码，另一个提供一个URL，在这个URL里可以看见这次预定的详细情形。RPC应答是从SOAP消息 env:Body 元素中返回的，作为一个struct模型，取过程名chargeReservation，根据惯例，附加单词Response（应答）。这两个output（或”out”）参数和应答是字符代码用来识别正被讨论的预定，这个地址的URI，看看从什么地方这个预定可以恢复。这是例5所说的，在哪里header再次识别这次交易，在RPC执行的部分。Example 5a 5 FT35ZBQ /reservations?code=FT35ZBQ RPC response with two output (or out) parameters for the call shown in Example 4RPCs经常这样描述，在哪一个特殊的output（输出）参数是不同的，所谓的return价值。SOAP RPC约定提供一种方法来区分这个return价值与在程序描述的其他output参数。为了表明，改进的charging例子这样描述一个RPC，几乎与例5a的描述一样，例如，同样有两个out参数，但是除此之外还有 一个返回值（return），即列举“证实的”和“未决的”( confirmed 和 pending )潜在的价值。RPC应答符合这个定义，在例5b 中提到，象以前的一样，在哪里SOAP header识别这次交易在RPC执行的部分。Example 5b 5 m:status confirmed FT35ZBQ /reservations?code=FT35ZBQ RPC response with a return value and two out parameters for the call shown in Example 4在例5b中，返回值是由rpc:result元素识别，包括在这个（struct）结构m:status内的另一个元素的XML合格的名称（xs:Qname类型）。接下来，包括实际返回值，“confirmed”.这项技术要求实际返回值坚决按照某些模式类型。如果缺少rpc:result元素，象例5a一样，返回值就不存在或者类型为空。虽然，原则上说，在RPC中使用SOAP与为了传输RPC调用和返回使用特殊方式的决定是相互独立的，一些支持SOAP请求/应答消息交换模式（Request-Response message exchange pattern）的协议绑定也许会更加适宜这个目的。支持这个消息交换模式的协议绑定能提供请求与应答之间的相互关系。当然，基于RPC申请的设计者能选择安置一个关于调用和返回的相互关系标志符（correlation ID）在SOAP header中，因此要使RPC和任何底层传输机制相互独立。无论如何，申请设计者不得不知道传输SOAP RPCs选择的特殊协议的所有特性，例如，等待时间（latency），同步性（synchrony），等等。在通常使用的例子中，依据SOAP第2部分第7节中的标准，使用HTTP作为底层传输协议，自然就是一个RPC申请对应一个HTTP申请，一个RPC应答对应一个HTTP应答。4.1节提供使用HTTP绑定搬运RPCs的例子。然而，最值得记住的是即使大部分SOAP例子在RPC中使用HTTP协议绑定，它并不是仅限于这一种方法。2.3 差错情形SOAP提供一种模型，处理在消息传送过程中出现差错的情形。SOAP区分不同条件下的差错，结果出错，和显示差错是来自于最初发送者或是其它结点的错误消息的能力。显示差错的能力取决于使用的消息传输机制，和SOAP绑定规范在底层协议的一个方面关于限定怎样显示差错，如果有的话。剩下来的部分假定一种传输机制可用，它在处理接收到的消息时产生显示差错，集中讨论SOAP差错消息的结构。SOAP env:Body元素具有另外不同的作用，它可以放置差错信息。SOAP差错模型（在SOAP第1部分2.6节）要求所有的SOAP专用（SOAP-specific）和申请专用（application-specific）差错使用单独不同的元素报告，env:Fault, 在env:Body 元素内携带。env:Fault 包括两个基本的子元素，env:Code 和 env:Reason, （可选地）申请专用信息在env:Detail子元素。另一个可选的子元素env:Node，鉴定经由一个URI哪个SOAP结点产生差错，它没有则暗示这个结点是消息的最终接收者。这里还有一个可选的子元素，env:Role, 用来鉴定产生差错的结点扮演的角色。env:Fault的子元素env:Code本身组成了一个基本的env:Value子元素，它的内容限定在SOAP规范（看SOAP第1部分5.4.6节），还有可选的env:Subcode子元素。例6a中是说一条SOAP消息返回，即例4中的RPC请求的应答，并指出处理RPC的一个差错。Example 6a env:Sender rpc:BadArguments Processing error Chyba zpracovn Name does not match card number 999 Sample SOAP message indicating failure to process the RPC in Example 4在例6a中，最高层的的env:Value 使用一个标准的XML合格命名（xs:Qname类型）来鉴定那是一个env:Sender差错，表明它是相关的一些语法错误或是在消息中发送的不恰当信息。（当发送者收到一个env:Sender错误，希望能在相似的消息再次发送以前采取一些行动纠正错误。）env:Subcode元素是可选的，如果目前，就象这个例子中，更进一步会限定双亲价值（parent
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号