无法用soap通信协议连接扫描仪

无法用soap通信连接扫描仪 篇一:SOAP协议 SOAP 协议 SOAP 简介SOAP 以 XML 形式提供了一个简单、轻量的用于在分散或分布环境中交换结 构化和类型信息的机制。XML 的化为平台之间的交流带来了极大的方便，而 SOAP 的实质就是把这种交流的方式标准化。SOAP 本身并没有定义任何应用程序 语义 ,如编程模型或特定语义的实现; 实际上它通过提供一个有标准组件的包模 型和在模块中编码数据的机制 ,定义了一个简单的表示应用程序语义的机制。 这 使 SOAP 能够被用于从消息传递到 RPC 的各种系统。 SOAP 采用了已经广泛使用的两个协议:HTTP 和 XML (标准通用标记语言下的 一个子集) 。 HTTP 用于实现 SOAP 的 RPC 风格的传输, 而 XML 是它的编码模式。 采用几行代码和一个 XML 解析器, HTTP 服务器( MS 的 IIS 或 Apache) 立刻 成为 SOAP 的 ORBS。SOAP 通讯协议使用 HTTP 来发送 XML 格式的信息。HTTP 与 RPC 的协议很相似,它简单、 1 配置广泛,并且对防火墙比其它协议更容易发挥 作用。HTTP 请求一般由 Web 服务器软件(如 IIS 和 Apache)来处理, 但越来越 多的应用服务器产品正在支持 HTTP。XML 作为一个更好的网络数据表达方式 ( NDR)。SOAP 把 XML 的使用代码化为请求和响应参数编码模式, 并用 HTTP 作 传输。具体地讲, 一个 SOAP 方法可以简单地看作遵循 SOAP 编码规则的 HTTP 请 求和响应, 一个 SOAP 终端则可以看作一个基于 HTTP 的 URL, 它用来识别方法 调用的目标。像 CORBA/ IIOP 一样, SOAP 不需要具体的对象绑定到一个给定的 终端, 而是由具体实现程序来决定怎样把对象终端标识符映像到服务器端的对 象。 SOAP 包括三个部分 ? SOAP 封装:结构定义了一个整体框架用来表示消息中包含什么内容 ,谁来处理这些内容以及这些内容是可选的或是必需的。 ? SOAP 编码规则:定义了用以交换应用程序定义的数据类型的实例的一系列机制。 ? SOAP RPC 表示:定义了一个用来表示远程过程调用和应答的协定。 虽然这三个部分都作为 SOAP 的一部分一起描述 ,但它们在功能上是相交 的。特别的 ,封装和编码规则是在不同的名域中定义的 ,这种模块性的定 义方 法增加了简单性。在 SOAP 封装 ,SOAP 编码规则和 SOAP RPC 协定之外 ,这个规 范还定义了两个协议的绑定 ,描述了在有或没有 2 HTTP 扩展框架的情况下 ,SOAP 消息如何包含在 HTTP 消息中被传送。SOAP 语法SOAP 构建模块 一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素: ? ? ? ? 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息 可选的 Header 元素，包含头部信息 必需的 Body 元素，包含所有的调用和响应信息 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息所有以上的元素均被声明于针对 SOAP 封装的默认命名空间中: .cn/transaction/ soap:mustUnderstand=1234</m:Trans </soap:Header... ...</soap:Envelope 上面的例子包含了一个带有一个 Trans 元素的头部，它的值是 234，此元素 的 mustUnderstand 属性的值是 1。 SOAP 在默认的命名空间中 () 定 义了三个属性。这三个属性是:actor、 mustUnderstand 以及 encodingStyle。 这些被定义在 SOAP 头部的属性可定义容器如何对 SOAP 消息进行处理。 actor 属性 通过沿着消息路径经过不同的端点，SOAP 消息可从某个发送者传播到某个接 收者。并非 SOAP 消息的所有部分均打算传送到 SOAP 消息的最终端点，不 过，另一个方面，也许打算传送给消息路径上的一个或多个端点。 SOAP 的 actor 属性可被用于将 Header 元素寻址到一个特定的端点。 语法 3 soap:actor=URI 篇二:SOAP协议介绍 一、web service 1、SOAP SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问:“SOAP是怎样激活对象的,”或“SOAP在使用什么命名服务(Naming Service),”。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式(XML Format)，如果你用一对SOAP标记(SOAP Elements)把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗, SOAP规范还定义了怎样用XML来描述程序数据(Program Data),怎样执行RPC(Remote Procedure Call)。这些可选的规范是为了构建RPC-style的应用程序(客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果)。大多数SOAP解决都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序(SOAP消息只包含XML文本信息)。Document-style 应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。 4 最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。 很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。 现在SOAP的很多另人瞩目的特性已成为现实(SOAP已经运行于不同的硬件和软件平台)，而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术(CORBA、DCE)简单易用。 安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢,对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗,不是的，你不必担心，因为已经有这方面的规范了 ( y/en-us/dnglobspec/html/ws-security.asp)。 2、 WSDL WSDL是一种XML文档，它定义SOAP消息和这些消息是怎样交换的。IDL(Interface Description Language)是用 5 于COM和CORBA的，WSDL是用于SOAP的。WSDL是一种XML文档，所以我们可以阅读和编辑，但很多时候是用工具来创建、由程序来阅读。举个例子，你要使用供应商的Web Service构建应用程序。你可以向供应商索取使用Web Service的范例，然后按照范例来构建应用程序。这样可能出现意料不到的错误，比如说，你在程序中使用的客户代码的数据类型是integer，而供应商使用的数据类型是string.。WSDL详细定义客户端消息的格式，需要什么样的参数，这样可以避免不必要的错误。 3、 UDDI UDDI可以比喻成电话本，电话本里记录的是电话信息，而UDDI记录的是Web Service信息。你可以不把Web Service注册到UDDI。但如果要让全球的人知道你的Web Service，最好还是注册到UDDI。 UDDI目录说明文件也是一个XML文档，它包括三个部分。“白页(White Paper)”说明提供Web Service的公司(人)信息，比如说名称、地址和联系方式等等。“黄页(Yellow Paper)”说明UDDI目录的分类，比如说金融、服务和印刷等等。“绿页(green Paper)”说明接口(Web Service 提供的)的详细信息。UDDI提供多种查询方式，来帮助你找到需要的Web Service。如果你查询与财务有关的Web Service，那么UDDI会提供详细的信息。 6 Figure 1. Web Service stack 其中，绿色部分是先前已经定义好的并且广泛使用的传输层和网络层的标准:IP、HTTP、SMTP等。而蓝色部分是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI，以及服务工作流描述语言WSFL。而橙色部分描述的是更高层的待开发的关于路由、可靠性以及事务等方面的协议。黄色部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成 WSDL(Web Service 定义语言)是 Web Service 的正式描述;在 AquaLogic Service Bus 中，它用于描述代理服务或业务服务。WSDL 用于描述 Web Service 的作用、所在位置以及调用方法。 二、SOA 1、注册(Registry):注册存放对事物的引用 2、组件存储库(Repository):存储库则存放事物本身 二、web service 独立的功能实体:通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。Web 服务使用元数据来描述其他的端点需要知道什么 7 才能与它们进行交互。具体来说就是，Web 服务策略(WS-Policy)描述 Web 服务的能力、需求和一般特征;WSDL 描述了 Web 服务使用的抽象消息操作、具体的网络协议和端点地址;XML 模式描述 Web 服务接收和发送的基于 XML 的消息的结构和内容。为了自举 Web 服务中的通信，这个规范定义了三个请求-响应消息对来检索这三种类型的元数据:一个检索与接收端点或特定目标名称空间相关联的 Web 服务策略(WS-Policy)，另一个检索与接收端点或特定目标名称空间相关联的 WSDL，第三个检索与特定目标名称空间相关联的 XML 模式。这些消息一起使得以增量的方式高效地检索 Web 服务的元数据成为可能。 简单的说，一个Web服务(图 2-4)就是一个能够使用XML消息通过网络来访问的接口，这个接口描述了一组可访问的操作。一个Web服务的特征是:由SOAP 和WSDL包装的对象;适应松散耦合的网络环境，可通过Web服务，手段是SOAP消息;服务的行为、输入、输出都可以使用WSDL描述。 图 2-4 Web服务示意图 Web 服务可以从多个角度来描述。从技术方面讲，一个Web Services是可以被URI识别的应用软件，其接口和绑定由XML描述和发现，并可与其他基于XML消息的应用程序交互(Castro，2004;杨涛等，2004);Web 服务是基于 8 XML的、采用SOAP 协议的一种软件互操作的基础设施(廖军等，2004)。从功能角度讲，Web Service是一种新型的Web应用程序，具有自包含、自描述以及模块化的特点，可以通过Web发布、查找和调用实现网络调用(Tsalgatidou etal， 2002;杨涛等，2004)。Web服务是基于TCP/IP、HTTP、XML等规范而定义，具备如下功能:Web上链接文档的浏览、事务的自动调用、服务的动态发现和发布(TSur S，2001)。从应用的层面来说，Web服务是用于集成应用的，将原有的面向对象、面向组件的软件系统改造为基于消息面向服务的松散耦合系统或者构建新的松散耦合系统的一种协作设施(廖军等，2004)。从组成框架及实现目标的角度讲，Web服务作为一种网络操作，能够利用标准的Web协议及接口进行应用间的交互(W3C，2002)。从网格计算(grid computing)的角度看，Web服务能用于Web上的资源发现、数据管理及网格计算平台上异构系统的协同设计，提出了网格服务的新概念(Globus OGSA)。 目前，对Web Service的概念并没有一个严格的定义，不同的组织和部门对Web Service的定义都有微小的差异。 关于Web Service 的定义，有几种不同的描述: 国际标准化组织W3C :Web Service 是一个通过URL 识别的软件应用程序，其界面及绑定能用XML 文档来定义、描述和发现，使用基于Internet 协议上的消息传递方式 9 与其他应用程序进行直接交互。 ? Microsoft :Web Service 是为其它应用提供数据和服务的应用逻辑单元，应用程序通过标准的Web 协议和数据格式获得Web Service，如 HTTP 、XML 和SOAP 等，每个Web Service 的实现是完全独立的。Web Service 具有基于组件的开发和Web 开发两者的优点，是Microsoft 的.Net 程序设计模式的核心。 ? IBM认为，Web服务是一种自包含、自解释、模块化的应用程序，能够被发布、定位、并且从Web上的任何位置进行调用。Web服务可以执行从简单的请求到错综复杂的商业处理过程的任何功能。理论上来讲，一旦对? ? ? ? ? Web服务进行了部署，其它Web服务应用程序就可以发现并调用已部署的服务。 市场研究公司Forrester以一种更加开放的方法将Web Service定义为人、系统和应用之间的自动连接，这种连接能够实现将业务功能元素转变为软件服务，并且创造新的业务价值。Web Services是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。 Gartner将Web Service定义为:松散耦合 10 的软件组件，这些组件动态地通过标准的网络技术与另一个组件进行交互。 UDDI规范中提到:所谓Web服务，它是指由企业发布的完成其特别商务需求的在线应用服务，其它公司或应用软件能够通过Internet来访问并使用这项应用服务。 Web Service的另外一个概念就是:所有东西都是服务，这些服务发布一 个API供网络中的其它服务使用，并且封装了实现细节。 总之，Web服务是在互联网上的一种服务协议，采用XML作为基本的标记语言，SOAP(Simple Object Access Protocol)作为互操作协议，WSDL(Web Service Description Language)作为服务描述语言，通过UDDI(Universal Description Discovery & Integration)可以把服务注册到互联网以便搜索，为更多的用户使用其服务。可以看出，这些定义各有侧重，但有几点是一致的。首先，它是由企业驱动和应用驱动而产生的;其次，它具有分布性、松散藕合、可复用性、开放性以及可交互性等特性。 WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。 这种技术允许网络上的所有系统进行交互。随着技术的发展，一个Web服务可以包含额外的指定功能并且可以在多个B2B应用中协作通讯。 Web服务可以理解请求中上下文的关系，并且在每一个特定的情况下产生动态的结果。这些 11 服务会根据用户的身份，地点以及产生请求的原因来改变不同的处理，用以产生一个唯一的，定制的方案。这种协作机制对那些只对最终结果有兴趣的用户来说，是完全透明的。 UDDI 在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件。所以，我们需要一种方法来发布我们的Web服务。 UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。UDDI 项目中的成员可以通过UDDI Business Registry (UBR) 来操作Web服务的调用，UBR是一个全球性的服务。 Web服务供应商可以在UBR中描述并且注册他们的服务。 用户可以在UBR中查找并定位那些他们需要的服务。 UDDI是一种根据描述文档来引导系统查找相应服务的机制。 UDDI包含标准的“白 皮书”类型的商业查询方式， “黄皮书”类型的局部查找，以及 “绿皮书”类型的服务类型查找。 UDDI利用SOAP消息机制(标准的XML/HTTP)来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。 WSDL 对于商业用户来说，要找到一个自己需要使用的服务，他 12 必须知道如何来调用。 WSDL (Web Services Description Language) 规范是一个描述接口，语义以及Web服务为了响应请求需要经常处理的工作的XML文档。这将使简单地服务方便，快速地被描述和记录。 SOAP 当商业用户通过UDDI找到你的WSDL描述文档后，他通过可以Simple Object Access Protocol (SOAP) 调用你建立的Web服务中的一个或多个操作。 SOAP是XML文档形式的调用商业方法的规范，它可以支持不同的底层接口，象HTTP(S)或者SMTP。 之所以使用XML是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用HTTP是因为几乎所有的网络系统都可以用这种协议来通信，由于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。 SOAP的强大是因为它简单。SOAP是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。从技术角度来看，SOAP详细指明了如何响应不同的请求以及如何对参数编码。一个SOAP封装了可选的头信息和正文，并且通常使用HTTP POST方法来传送到一个HTTP 服务器，当然其他方法也是可以的，例如SMTP。SOAP同时支持消息传送和远程过程调用。 13 篇三:SOAP原理分析与运用(1) SOAP的四个部分: 1协议结构 SOAP 消息格式: SOAP 标头: <SOAP-ENV: EnvelopeAttributes <SOAP-ENV:BodyAttributes </SOAP-ENV:Body </SOAP-ENV:Envelope 这种结构目前主要在web服务中运用。 2、语法规则 SOAP 消息必须用 XML 来编码 SOAP 消息必须使用 SOAP Envelope 命名空间 SOAP 消息不能包含 DTD 引用 SOAP 消息不能包含 XML 处理指令 3、SOAP的核心技术解释 SOAP采用了已经广泛使用的两个协议:HTTP 和XML。HTTP用于实现 SOAP 的RPC 风格的传输, 而XML 是它的编码模式。采用几行代码和一个XML 解析器, HTTP 服务器( MS 的 IIS 或 Apache) 立刻成为SOAP 的 ORBS。SOAP 通讯协议使用 HTTP 来发送XML 格式的信息。HTTP与RPC 的协议很相似,它简单、 配置广泛,并且对防 14 火墙比其它协议更容易发挥作用。HTTP 请求一般由 Web 服务器软件(如 IIS 和Apache)来处理, 但越来越多的应用服务器产品正在支持HTTP。XML 作为一个更好的网络数据表达方式( NDR)。SOAP 把 XML 的使用代码化为请求和响应参数编码模式, 并用HTTP 作传输。具体地讲, 一个SOAP 方法可以简单地看作遵循SOAP编码规则的HTTP请求和响应, 一个 SOAP 终端则可以看作一个基于HTTP 的URL, 它用来识别方法调用的目标。像CORBA/ IIOP一样, SOAP不需要具体的对象绑定到一个给定的终端, 而是由具体实现程序来决定怎样把对象终端标识符映像到服务器端的对象。 4、消息格式 SOAP在标准化消息格式环境中，可以做所有它能完成的工作。消息的主体部分 是“text/xml”形式的MIME类型，并且包含一个SOAP封套。该封套是一个XML文 档。 封套包含了报头(可选的)和报文(必须有的)。封套的报文部分总是用于 最终接收的消息，而报头项目可以确定执行中间处理的目标节点。附件、二进制 数字及其他项目可以附加到报文上。 SOAP提供了一种让客户端指定哪个中间处理节点必须处理报头项目的方法。由于报头与SOAP消息的主体内容是互不相关的，所以可用它们给消息添加信息，而不会影响对消 15 息报文的处理。 例如，报头可用于为报文中包含的请求提供数字签名。 在这种情形下，身份验证/授权服务器可以处理报头项目独立于报文可以剥离信息以验证签名。一旦通过验证，封套的其余部分将被传递给SOAP服务器，它将对消息的报文进行处理。 5、SOAP-RPC SOAP RPC 表示:它定义了用于表示远程过程调用和应答的协定。 SOAP消息本质上是一种从发送方到接收方的单向传输，但是SOAP经常组合到实 现请求/响应机制中。要让RPC使用SOAP，必须遵循几条规则。首先，请求和响应 消息必须被编码成结构类型。对一个操作的每一个输入参数，都必须有一个同名 元素(或输入结构的成员)作为参数。对每一个输出参数，都必须有一个名称匹 配的元素(或输出结构的成员)。 基于RPC的观点，会省略一些更早一点显示的SOAP消息。 在SOAP封套中没有什么地方的数据类型是显式声明的，注意到这一点很重 要，最后，为了进行RPC，需要一种低级协议如HTTP。尽管SOAP 1.0规范强制要求 使用HTTP作为传输协议，但 16 SOAP 1.1规范(及其姊妹规范“带有附件的SOAP消息” )允许使用FTP、SMTP、甚至(可能)原始的TCP/IP套接字。所有这些对SOAP通用的序列化和编码规则，也适用于RPC参数。 6、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文档中 17 包含的参数中传递。在SOAP服务器接收消息之前，中间处理节点可以执行SOAP报 头指示的特殊功能，可视情况确定是否执行这步操作。请求对象执行指示的功能，并返回数据给SOAP服务器，它把响应打包到 SOAP封套中。服务器把SOAP封套包裹在要发送回请求机器的响应对象中，如 servlet或COM对象.客户端接收对象，剥离出SOAP封套并把响应文档发送给最初发出请求的程 序，完成请求/响应循环。 7、SOAP的优点 (1) SOAP 是可扩展的。SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。 (2) SOAP 是简单的。客户端发送一个请求,调用相应的对象, 然后服务器返回结果。这些消息是XML 格式的,并且封装成符合HTTP 协议的消息。因此,它符合任何路由器、 防火墙或代理服务器的要求。 (3) SOAP 是完全和厂商无关。SOAP可以相对于平台、 操作系统、 目标模型和编程语言独立实现。另外,传输和语言绑定以及数据编码的参数选择都是由具体的实现决定的。 (4) SOAP 与编程语言无关。SOAP 可以使用任何语言来完成, 只要客户端发送正确SOAP 请求( 也就是说, 传递一个合适的参数给一个实际的远端服务器)。SOAP 没有对象 18 模型, 应用程序可以捆绑在任何对象模型中。 (5) SOAP 与平台无关。SOAP 可以在任何操作系统中无需改动正常运行。 8、 ( 1) SOAP与XML 的关系。所有的SOAP 消息都使用XML形式编码。即要传输的信息以SOAP 消息为载体, SOAP消息以XML格式封装, 并绑定在HTTP 协议上传递。SOAP操作是面向文件的,它把XML文件作为输入输出消息的一部分。在SOAP消息对象框架中,每个XML 文件都是一条消息的独立部分, 而这每条消息都是一个对象。如果 SOAP 消息中包括多个XML 文件,那么它就存在多个消息部对象。每个消息部对象封装一个独立的消息部或者一个XML 文件。 ( 2)SOAP 消息。假设用户要通过互联网在线查询火车票的票价,在互联网上存在一个组件, 其中的一个名为! Getting_Price的方法可完成这个功能,其接口为gettingprice。 1) SOAP 请求。客户端的SOAP 请求以HTTP 头部构架和所需的XML 格式被封装成HTTP包发送至服务器。 POST / TicketsCenter HTTP/ 1. 1 Host : www.ticketscent erserver. com Content- Type: text/ xml 19 Content- Length: nnnn SOAPMethodName: Some- Namespace- URI# Getting_Price < SOAP: Envelope xmlns: SOAP=“ urn: sche mas- xmlsoap- org: soap.v1 < SOAP: Body < m: Getting_Price xmlns:m= “ Some- Names pace- URI” < symbol T132 </symbol < /m: Getting_Price < / SOAP: Body < / SOAP: Envelope 前四行是标准的HTTP消息格式, POST 是HTTP的谓词,Host、 Content- Type和Content- Length 都是HTTP消息格式的必要内容。Content- Type 中的! text/ xml?表示发送给服务器(或者可扫描应用程序头部的防火墙)的XML 消息的有效载荷; Envelope 和Body 提供一套常规的有效载荷封装机制; < Getting_Price 包含一个< symbol 元素,用以获得所查询火车票的票价, 比如说是T132。在SOAP规范中, 要激活一个组件是由指定的URI( Uniform Resource Identifier) 中的代码来决定如何激活该组件并调用相应的方法。 2) SOAP应答。当服务器识别SOAP 请求中的 20 SOAPMethodName 后, 调用相应的具体过程并将结果封装在SOAP 应答中返回给客户端。 HTTP/ 1. 1 200 OK Content- Type: text/ xml Content- Length: nnnn < SOAP: Envelope xml ns: SOAP= “urn: sche mas- xml soap- org: soap. v1 “ < SOAP: Body < m: Getting_Pri ceResponse xmlns:m= “ Some- Namespace- URI” < return 413. 5< / return < /m: Getting_PriceResponse < / SOAP: Body < / SOAP: Envelope 前三行仍是标准的HTTP 消息格式, 其中第一行表示对上次SOAP 请求的应答。< Gett ing_PriceReesponse 包含了对查询的火车票的价格。 ( 3) SOAP 封装。一个 SOAP 消息就是一个 XML 文档, 它包括 SOAP 封装、 SOAP 头(可选) 和 SOAP 体。 即: SOAP封装是描述SOAP 消息的XML 文档中的顶层元素; SOAP 头为尚未事先约定的分散的通信各方提供了向SOAP消息中增加相关要素( feature) 的机制。同时,定义了一些属性来标明这些要素( feature)由谁来处理及是否可选; 21 SOAP 体是一个容器,它包含了消息的最终接收者所需信息。SOAP 为SOAP 体定义了一个Fault 元素用来错误信息。 1) SOAP 封装。元素名是! Envelope, 是SOAP 消息中的必需元素。当它包含了名域声明、附加属性或者附加子元素时, 那么它们必须具备名域资格, 附加子元素必须写在SOAP 体元素之后。 2) SOAP头。元素名是! Header, 它是一个可选元素。如果写明,则必须是SOAP 封装元素的第一个直接子元素。SOAP 头可包含许多头条目( headerentry) ,它们都是SOAP头元素的直接子元素, 并且都必须具备名域资格。在实际应用中,这些头条目所能完成的典型任务是做鉴定、 事物管理和债务偿还等,其编码必须遵守的规则有: 一个头条目必须能被识别, 包括名域空间URI 和局域名称。所有头元素的子元素都必须具备名域资格; SOAP 的 encodingStyle属性可用来表明头条目的编码方式; SOAP的mustUnderstand 和actor属性指出如何处理该条目及由谁来处理。 3) SOAP体。元素名是! Body, 是SOAP 消息中的必需元素而且是SOAP 封装元素的直接子元素。如果存在SOAP 头元素, 那么它必须紧跟其后;否则就是SOAP 封装元素的第一个直接子元素。SOAP 体也可包括一些体条目, 它们都是SOAP 体元素的直接子元素。并且可具备名域资格。SOAP 22 定义了SOAP Faul t 元素来指示错误信息。在实际应用中, SOAP 体元素多用来马歇尔RPC 调用和错误报告等,其编码必须遵守的规则有: 一个体条目也必须能被识别, 包括名域空间URI和局域名称。所有体元素的子元素都可以具备名域资格; SOAP的encodingStyle属性可用来表明体条目的编码方式。SOAP 头和体各自还可以包含自己的属性,具体请参考协议规范的原文。尽管SOAP 的头元素和体元素被定义为独立的元素,但它们实际上是相互关联的。当头条目和体条目都需要缺省的actor, 并且 SOAP 的 mus_tUnderstand 属性值为1 时, 两者是等价的。 相关热词搜索:扫描仪 连接 通信协议 soap soap协议详解 soap协议的不足 23