资源目录
压缩包内文档预览：
编号：516510
类型：共享资源
大小：176.04KB
格式：RAR
上传时间：2015-11-12
上传人：QQ28****1120
认证信息
个人认证
孙**（实名认证）
辽宁
IP属地：辽宁
6
积分
- 关 键 词：
-
机械毕业设计
- 资源描述：
-
tx092XML 解析器分析研究,机械毕业设计
- 内容简介：
-
江苏大学 1 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) 请参考这个文档的勘误表 ,里面包括了一些标准修正 . 这个规范的英文版本是唯一的标准版本 .当然也存在非标准的翻译版本 . 版权 2003 W3C (麻省理工学院 , ERCIM, Keio),版权所有 .W3C责任 ,商标 ,文件使用权 ,适用许可的软件 . 摘要 SOAP1.2版本 部分 0:初级版是一个非标准的文档 ,试图提供一本易于理解 SOAP1.2版本规范的指南 .特别是 ,它通过各种各样的使用情形描述 SOAP的特征 ,而且试图补充包含在SOAP1.2规 范的部分 1 和部分 2中的标准正文 . 文档状况 这个部分描述了这个文档在出版阶段的状况 .其他文档也许能代替这个文档 .这个文档系列最近的状况由 W3C 保持 . 这个文档是 W3C 推荐 .由 XML 协议工作组 (XML Protocol Working Group)制作出来的 ,工作组是网络服务活动的一部分 .这个文档是被 W3C 成员和其他为之感兴趣的团体反复检查的 ,并被最高执行者担保为 W3C 推荐 .它是稳定的文档 ,可以作为参考资料或者 被另一个文档引用为标准参考 .W3C 的作用是推荐以引起大家注意这个规范和促进它的普遍使用 .这个能增加网络的功能和互用性 . nts江苏大学 2 欢迎发表关于这个文档的评论 .请把评论送到公共邮件列表 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。致谢 nts江苏大学 3 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 信息的时候所采取的行动的完整描述。 nts江苏大学 4 这个文档的第 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 一般形式 /. 和 /.代表nts江苏大学 5 一个应用依赖和文本依赖的 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 nts江苏大学 7 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消息图示如下： nts江苏大学 8 在例 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提供增值服务以数据为基础。在nts江苏大学 9 例 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 nts江苏大学 10 ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind ke Jgvan yvind nts江苏大学 11 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与每一条消息涉及到的附加元素具有相同价值，nts江苏大学 12 因此需要提供一种方法，使在申请水平的消息交换相互关联。 Example 3 uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:36:50.000-05:00 ke Jgvan yvind LGA EWR nts江苏大学 13 Response to the message in Example 2 continuing a conversational message exchange 2.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 中所说的 ,适当的指定目标和分派 .这nts江苏大学 14 个部分的目的是突出 RPC请求的句法部分和在 SOAP消息中携带的返回值 . Example 4 5 FT35ZBQ ke Jgvan yvind 123456789099999 2005-02 SOAP RPC request with a mandatory header and two input (or in) parameters RPC 本身被当做 env:Body 元素的一个子元素被携带，在这个 chargeReservation 的例子中作为一个程序和方法名的 struct模型。（ struct 是来自于 SOAP数据建模中的概念，在SOAP Part2 中定义，是发生在一些共同的程序设计语言中的模型结构和记录类型。） RPC 设计在这个例子中（没有正式的确切定义）取两个 input（或“ in”）参数，对应这次有计划的nts江苏大学 15 行程预定由预定代码鉴定，还有信用卡信息 。后者也是一个 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 nts江苏大学 16 FT35ZBQ /reservations?code=FT35ZBQ RPC response with two output (or out) parameters for the call shown in Example 4 RPCs经常这样描述，在哪一个特殊的 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 绑定规范在底层协议的一个方面关于限定怎nts江苏大学 18 样显示差错，如果有的话。剩下来的部分假定一种传输机制可用，它在处理接收到的消息时产生显示差错，集中讨论 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 nts江苏大学 19 Sample SOAP message indicating failure to process the RPC in Example 4 在例 6a 中，最高层的的 env:Value 使用一个标准的 XML合格命名 （ xs:Qname类型 ） 来鉴定那是一个 env:Sender差错 ， 表明它是相关的一些语法错误或是在消息中发送的不恰当信息。（当发送者收到一个 env:Sender错误，希望能在相似的消息再次发送以前采取一些行动纠正错误。） env:Subcode 元素是可选的
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号