soap协议范文
时间：2023-03-22 14:43:36
soap协议范文第1篇
关键词：Web Service;soap;xml
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)04-10950-02
1 Web Service及相关技术
1.1 Web Service概述
Web Service作为当前在计算机网络应用领域最热门的技术，已经有了许多成功的应用。但到底是什么是Web Service呢？从表面上看，Web Service就是一个应用程序，他向外界暴露出一个能够通过Web进行调用的API,这就是说，你能够用编程的方法同过Web调用来实现某个功能的应用程序。从深层次看，Web Service是一种新的Web应用程序分支，它们是自包含，自描述，模块化的应用，可以在网络(通常为Web)中被描述，，查找以及通过Web来调用。
Web Service是基于网络的，分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这么规范使得Web Service能与其他兼容的组件进行互操作，它可以使用标准的互联网协议，像HTTP和XML,将功能体现在互联网和企业内部网上，Web Service平台是一套标准，它定义了应用程序如何在Web上实现互操作性，你可以用你喜欢的任何语言，在你喜欢的任何平台上写Web Service.
1.2 Web Service的技术支持
Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据
表示方法和类型系统。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台，编程语言和组件模型中的不同类型系统。目前这些协议有：
(1)XMl
可扩展标记语言XML(extensible Markup Language)是一门新兴的面向Internet应用的
标记语言,它是WWW联合会(W3C)于1998年2月制定的一种通用语言规范。作为一种可用来制定具体应用语言的元语言，XML既具有强大的表述能力，又具有适合网络应用的简洁性；作为对SGML语言标准的一种改良，XML具有适于异构应用间数据共享，可以进行数据检索和提供多种语种支持等优点。
(2)SOAP
Soap(Simple Object Access Protocal)是在分散或分布式环境中交换信息的简单协议，它基于XML协议，soap以xml形式提供了一个简单且轻量的用于在分散或分布环境交换结构化和类型信息的机制，其本身并没有定义任何应用程序语义，如编程模型或特定语义的实现，而是通过提供一个有标准组件的包模型和在模块中编码数据的机制定义了一个简单的表示应用程序语义的机制，使其能够用于从信息传递到RPC的各种系统。
(3)UDDI
统一表述，发现和集成协议，是一套基于Web的，分布式的。为Web Service 提供信息
注册中心的实现标准，同时包含一组使企业能将自身提供的Web service注册使得别的企业能够发现的访问协议。
(4)WSDL
Web Service描述语言，是一套基于XML的语法，用于将Web Service描述为能够进行
消息交换的Services访问点的集合。
Web Service面向服务的架构(SOA)如图
Web Service系统结构是基于Services Provider(服务提供者)，Services Requestor(服务请求者)，Services Registry(服务注册中心)3个角色和Public()，Find(发现)，Bind(绑定)3个动作构建的，服务提供者利用WSDL描述自己的Web Service，并将服务到UDDI；服务请求者利用SOAP消息向服务提供着发送使用服务的请求；服务注册中心的作用是通过在UDDI中查找满足服务请求者要求的服务。
2 Web Service安全机制
2.1 Web Service中存在的安全问题
Web Service的基础是soap(简单对象访问协议),soap协议的2个主要设计目标是简单性和可扩展性，因此，soap协议在制定时并没有过多考虑安全性，而是尽可能地利用现有的标准和协议来实现相应的安全功能，利用现有的SSl和HTTPS协议，就可以很容易的获得连接过程中的安全。然而这种安全实现方法有两个方面的不足，一是它只能保证数据传输的安全，而不是数据本身的安全，数据一旦到达某地，那么就可以被任何人查看。而在Web Service中，一份数据可能到达很多地方，而这份数据却不该被所有的接收者查看。二是它提供的是要么全有要么全无的保护，你不能选择哪部分数据要保护，而这种选择也是在Web Service中所常要用到的。所以单一的传输解决方案或者普通的防火墙是无法确保服务安全的，一个完整的Web Service安全解决方案应该通过利用Web Service模型核心组件的可扩展性，建立一整套的安全规范，这些规范建立在一些基础技术如soap，wsdl，xml数字签名(xml Digital Signature)，xml加密(xml Encryption)和SSL/TCL的基础之上。
所以，WebService仍然要解决以下的安全问题：
(1)数据的机密性。如何保证传送信息不被未经许可的第三方看到；
(2)数据的完整性。如何保证收到的信息没有被篡改过；
(3)身份认证。如何鉴别通信双方的身份；
(4)授权和访问控制。如何保证用户的操作没有超越它的权限。
2.2 解决方案
WebService的基础是soap,而soap的基础是xml,W3C在XML-Signature Syntax and Processing 和 XML Encryption Syntax and Processing中分别定义了数字签名，加密等如何在XML中表示。
2.2.1 XMl加密
XML加密不同于其他传统方法，它可以根据不同要求对电子文档的不同部分进行加密，而传统方法只能加密文件的全部内容。XML加密有三种方法：加密整个XMl文件；加密XML文件中的元素；加密XML文件中元素的内容。
XMl加密分为对称加密和非对称加密。所谓对称加密是一种使用相同的密钥来进行加密和解密的加密算法。对称密码包括分组密码和流密码。分组密码加密固定分组长度的明文，分组长度与具体的对称密码以及密钥长度有关。流密码利用密钥推导函数来产生一个密钥流，然后在明文的每一字节和密钥流的每一字节之间进行异或操作来生成密文。
3DES通常被称为3DES EDE，意思是加密、解密、在加密，即执行DES算法三次。3DES算法的密钥空间大小为2168基本可以认为这种密码是安全的。明文分组输入到密码算法中，使用DES算法对明文进行加密，密钥为，92比特3DES密钥的前64比特(开头的8字节)。然后使用，92比特的3DES密钥的中间64比特密钥对密文进行解密。最后，使用，92比特的3DES密钥的最后64比特对分组进行加密，整个加密过程结束。
所谓非对称加密，它使用不同的密钥进行加密和解密操作。这与对称密钥密码形成对比，后者使用相同的密钥进行加密和解密操作。非对称密码中，一个密钥用于加密，但该密钥对于解密是完全无用的。同样，仅仅有一个密钥可用于解密，并且该密钥对于加密也是无用的。最常用的非对称密钥加密算是RSA算法，它是由Rivest，Shamir和Adleman提出的。尽管还有其他一些非对称加密方案，但是RSA算法是当前XML安全标准中规定的唯一一种这样的加密方案。
RSA的工作原理：首先随机生成一个公钥和私钥对，然后使用生成的公钥通过RSA算法加密数据；最后用生成的私钥解密被加密的数据。
2.2.2 XML签名
XML签名的语法和处理规范是由W3C和IETF联合制定的。自2002年2月以来，他一直是正式的W3C推荐规范，并得到了广泛的应用。XML数字签名可以提供完整性，并可用于进行发证人验证，一个数字签名的消息包含验证消息来源和消息内容的信息，因而数字签名能够非常有效地用于SOAP消息认证。
SOAP消息有一个由SOAP标题和SOAP体最后组成的信封。当用于一个RPC调用时，消息中的真实信息就存在于SOAP体内。数字签名特别利用了存在于SOAP标题内的SOAP消息扩展；发送方通过获得密钥对来做准备；被签名的内容储存在SOAP体之内；发送方的私有密钥被用来签名SOAP体；最后，签名被放在SOAP标题中。当处理SOAP消息时，发送方处理SOAP标题并在兑现SOAP请求之前验证签名。
数字签名可以对我们制定的内容提供完整性检查。如果原始内容的某个字节已经被修改，那么签名验证将失败。下面是它的工作原理：
数字签名的工作方式
验证数字签名的过程
3 结论
随着WebService的应用日益广泛，应用程序拓扑发展到支持防火墙，负载平衡和消息传递中心之类的中介并且人们对服务的安全理解更加深刻，对WebService 增加安全性规范的需要就变得更加明显了，本文对目前WebService安全方面存在的问题进行了分析，通过扩展和利用现有的安全性技术和规范提出了安全模型，使用户更加快速地开发安全的，客户操作的WebService.。
参考文献：
[1]马忠贵,叶斌,曾广平,涂序彦.基于SOAP的软件人通信模型研究[J].计算机工程,2006年第9期.
[2]金丽娜,将兴浩,李建华.基于属性证书的Web Services访问控制模型[J].计算机工程,2006年第9期.
[3]陈荦祺,陈克菲.高性能可信的Web Service 研究[J].计算机工程,2006年第10期.
[4]朱一群,张全海,李建华.基于XML安全的电子公文系统研究与设计[J].计算机工程,2006年第9期.
[5]曾昭毅,张南平,钟珞.Web Service安全机制研究[J].武汉理工大学学报,2004年11期.
soap协议范文第2篇
关键词：Web服务；简单对象访问协议；数字签名；可扩展标记语言
中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)06-1pppp-0c
Study on SOAP Security Expansion-Based of Web Services
FAN You-lei1,ZHANG Ya-zhen2
(1.A0513 Class,Faculty of Information Science&Technology,Jiujiang University,Jiujiang 332005,China;(2.Faculty of Information Science&Technology,Jiujiang University,Jiujiang 332005,China)
Abstract: SOAP is a XML-based communication protocol.In this article,we discuss Web Services architecture of SOAP-based and SOAP message construct,a way to solve safety of Web Service is provided through SOAP based Digital Signature that ensures the integrity and security of Web Services.
Key words: Web Services;SOAP;Digital Signature;XML
1 引言
Web服务是一种通过统一资源指示符(URI)标识的软件应用，其接口及绑定形式可以通过XML标准定义、描述和检索，Web服务能够通过XML消息及Internet协议完成与其它软件应用的直接交互。Web服务可以不用改变现有的各种应用，也不用关心它们技术的不同，利用Web服务的消息驱动机制，就可以让它们协同工作和交互。Web服务体系结构中最基础的支柱是XML消息传递。目前XML消息传递的行业标准协议是SOAP，通常服务的调用者通过在传输层协议之上绑定SOAP消息来请求服务。 随着Web服务技术的飞速发展，其在电子商务、企业应用集成(EAI),B2B应用及电子政务等多个领域正发挥着越来越重要的作用。同时在这些领域也面临着各种各样的安全威胁，如信息窃取、恶意欺骗、伪装、非法修改以及各种扰乱破坏等。为保证Web服务能够在Internet上得到广泛应用，必须保证Web服务的安全，而Web服务通信是利用SOAP消息进行的，因此Web服务安全的核心就是SOAP消息的安全。
2 Web服务的技术框架
Web服务不是一个孤立的概念或者技术，它是由一系列相关的协议来组成的，这些协议之间相互依赖、相互影响。它是计算机应用中的一个重要而崭新的体系，并在此基础上形成了一个协议互操作栈。它从开放性着眼，克服了以前电子商务的封闭性，试图解决Web服务界面层的一致性和和集成平台的开放性。
协议互操作栈[1]是新一代的协议互操作技术，它是由一系列的协议所组成，从而形成了整个Web服务的体系。这些协议包括SOAP、WSDL、UDDI等多种协议。Web服务的体系结构是一个层次结构，由网络层、接口层、描述层、平台服务层以及Web服务工作流等组成，而每层都有相应的标准协议，从而形成了一个Web服务的标准协议互操作栈。图1给出了Web服务的技术框架：
图1 Web服务的协议栈
位于协议栈最底层的为各种现有的网络协议，如 HTTP 协议，FTP 协议等，它们是与 Web 服务通信的基础。SOAP 为在不同系统之间实施平台无关的交互定义了一套基本的元规则，SOAP 是 Web 服务体系架构中服务交互的基础。WSDL 则是描述 Web 服务界面的基本工具。依靠 WSDL，Web 服务的交互界面就能被系统自动处理。UDDI 则是在动态服务集成解决方案中的首次尝试。这组技术使得底层平台对应用交互透明，应用的互操作能力得到了前所未有的提升。位于最高层的 WSFL 是Web 服务工作流协议，它是 Web 服务组合运行、互操作方面的规范。安全机制对于松散耦合的对象环境非常重要,因此需要我们对诸如授权认证、数据完整性(如签名机制)、消息源认证以及事务的不可否认性等进行详细研究。
3 Web服务中SOAP消息安全规范
3.1 SOAP协议研究
SOAP即简单对象访问协议(Simple Object Access Protocol),在最新的SOAP1.2规范[2]中，其正式的定义如下:SOAP是一种轻量级协议，用于在分散型、分布式环境中交换结构化信息。SOAP利用XML技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。这种框架的设计思想是独立于任何一种特定的编程模型和其他特定实现的语义。
3.1.1 SOAP消息交换模式
SOAP消息从发送方到接收方是单向传送，并经常以请求应答的方式实现。SOAP实现可以通过开发特定网络系统的特性优化，例如HTTP绑定使SOAP应答消息以HTTP应答的方式传输，并使用同一个连接返回请求。而忽略SOAP被绑定到的协议，SOAP消息采用所谓的“消息路径”发送，使得在终节点之外的中间节点可以处理消息。一个接收SOAP消息的应用程序必须识别应用程序需要的SOAP消息的所有部分，检验应用程序是否支持前面识别的其他消息中的必需部分并处理。如果该SOAP应用程序不是消息的最终目的地，则在转发消息之前删除前面识别的所有部分。为正确处理一条消息或者消息的一部分，SOAP处理器需要理解使用的交换方式(单向、请求位答和多路发送等)、接收方的任务、使用的RPC(如果有的话)、数据的表现方法或编码.以及其它必需的语义。
3.1.2 SOAP消息的构成
SOAP消息包含一个SOAP信封Envelope，该信封是一个XML文档。Envelope XML文档的顶级元素，它包含了两个子元素―SOAP消息头部Header和SOAP消息体Body。 SOAP:Header元素是这个对象模型中的一个可选项，这个信息是用户自定义的，用来承载与应用关系不大而需底层环境平台处理的信息，例如:公共密钥加密信息、事务处理顺序标识符、参与处理的各方所需的信息、以及远程SOAP处理程序在管理远程请求时将会需要的其它元数据。SOAP:Body元素是信封的第二个子元素。对于SOAP请求来讲，请求体中包括被调用方法定义的标签，这些标签中包含方法完成其工作所需要的信息，是SOAP消息的必不可少的部分。对于SOAP响应文档来讲，SOAP:Body元素包含作为消息结果的数据。信封中的消息体部分总是用于最终接收的消息，而头部项目可以确定执行中间处理的目标节点。附件、二进制数字及其他项目可以附加到消息体上。 如图2所示：
图2 SOAP消息的结构
3.2 WS-Security规范
为了更好地将XML安全技术适应于Web 服务环境，提出了WS（Web Services）-Security规范。WS-Security规范草案最初由Microsoft公司提出，之后由IBM公司和Microsoft公司共同更新。2002年6月，WS-Security被提交给结构化信息标准促进组织(OASIS,Organization for the Advancement of Structured Information Standards)，以促进WS-Security的标准化工作。微软和 IBM 在了第一个 Web 服务安全规范 WS-Security 后，又了一系列后续规范计划。这组规范以 WS-Security 为基础，建立一个初始规范，包括：Web 服务端点策略(WS-Policy)、一个信任模型(WS-Trust)和一个隐私权模型(WS-Privacy)。
在这个基础上又建立了后续，包括:安全会话(WS-SecureConversation) 、联合信任 (WS-Federation)、授权(WS-Authoriza-
tion)。描述如何向SOAP 消息附加签名和加密报头。另外，它还描述如何向消息附加安全性令牌（包括二进制安全性令牌，如 X.509 证书和 Kerberos 票据）。如图3所示：
图3 Web-Security层次模型
(1)WS-Policy
描述中介体和端点上的安全性(和其它业务)策略的能力和限制(例如，所需的安全性令牌、所支持的加密算法和隐私权规则)。WS-Policy用于Web服务的组织为其Web服务指定安全需要。
(2)WS-Trust
用于建立自接和信任关系(包括第三方和中介体)的模型。模型描述如何通过创建安全性令牌，保证服务把现有的自接信任关系用作信任的基础。
(3)WS-Privacy
创建、管理和使用Web服务的组织将经常需要声明它们的隐私权策略，并要求进来的请求声明发送者是否遵守这些策略。
(4)WS一SecureConversation
描述Web服务如何认证请求者消息、请求者如何认证服务以及如何互相建立认证的安全性上下文，以及描述如何建立会话密钥、派生密钥和消息令牌密钥。
(5)WS-Federation
这个规范定义如何使用WS-Security，WS-Policy,WS-Trust,WS-SecureConversation规范构建联合信任案例。例如，它将描述如何把Kerberos和PKI基础架构联合起来。同时还引入一个信任策略来指出并限制和确定被的信任类型。
(6)WS-Authorization
这个规范将描述如何指定和管理Web服务的访问策略。它将特别描述如何在安全性令牌内指定声明，以及这些声明在端点处将如何被解释。
WS-Security规范本身并没有定义新的安全协议，而是在己存在的安全标准和规范中强调安全性。它提供了一个可扩展的框架，用来在SOAP消息中嵌入安全性机制包含数字签名、消息摘要和数据加密等。这些安全性信息都是作为附加的控制信息以消息的形式传递的，不依赖于任何传输协议。因而WS-Security规范具有传输中立性，能保证端到端的安全性。消息级安全模型相对于传统平台/传输级(点到点)的安全模型而言，更适合用于异构环境中，还能有效地防止消息在经过中间节点时遭到第三方的破坏。
4 SOAP消息安全性扩展
Web服务的安全性问题涉及的议题虽然相当广泛，但是首先要解决的基本问题是Web服务通信安全问题，即基于XML的SOAP消息的安全性问题。Web服务的通信安全首先要保证通信中传输的数据的安全，抵抗窃听、篡改、假冒、重放、业务否认等安全攻击，确保数据的机密性、完整性、可用性、消息源认证性和不可否认性。其中，机密性是指消息接收者能够识别消息内容，而入侵者无法识别消息内容；完整性是指消息接收者能够验证传输过程中消息没有被篡改；可用性是指消息接收者能够正确获取所需的消息内容；消息源认证性是指消息接收者能够确认消息的确来源于消息发送者，且入侵者不可能伪装成消息发送者发送同样的消息:不可否认性是指消息发送者无法否认他己经发送过的消息，消息接收者也无法否认他己经接收到的消息。这些安全需求仅依靠SSL的安全机制不能解决所有的问题。SOAP信息封套(Envelope)包括两个部分：SOAP信息头(Header)和SOAP信息体(Body) 。SOAP信息头主要包含与请求相关的元数据，而SOPA信息体封装了服务调用及其相关的参数。通常，认证信息是作为元数据和SOAP消息一起发送的，而且数字签名也可以被容纳在SOAP信息头中.因此，SOAP信息头在SOAP安全中起着重要的作用。因此必须是通过对soap消息头进行安全的扩展，而对于SOAP进行安全性扩展，数字签名(Digital Signature)又是一个很好的解决方案。
4.1 SOAP消息头数字签名的实现
数字签名技术是使用加密算法制成的数字标签，此标签通过密钥制成，而且不访问密钥，就不可能仿制标签。通常使用私钥签名文件,并使用同一私钥打开别人发送来的加密文件。具体将要满足如下三个要求：
(1)接收者能够核实发送者对消息的签名；
(2)发送者事后不能抵赖对消息的签名；
(3)接收者不能伪造对消息的签名。
现在对SOAP进行扩展,在SOAP的头元素的扩展命名空间中加入数字签名。下面是一个包含数字签名的SOAP信息[3]:
＜ SOAP-ENV: Envelope
xmlns: SOAP-ENV = " schemas. xmlsoap. org/soap/envelope/ "＞
＜ SOAP-ENV: Header ＞
＜ SOAP-SEC: Signature
xmlns: SOAP-SEC = " schemas. xmlsoap. org/ soap / security/2000-12"＞
＜ ds: Signature xmlns: ds = " http: //www. w3. org/2000 /09 /xmldsig#"＞
＜ ds :SignedInfo ＞
＜ ds :CanonicalizationMethod
Algorithm =“http :// www. / TR/ 2000/CR-xml-c14n-20001026＞ ”
＜/ds :CanonicalizationMethod ＞
＜ ds :SignatureMethod
Algorithm =“http :// www. /2000/9/ xmldsig # dsa =“sha1“/ ＞
＜ ds: Reference UR I= "#Body"/＞
＜ ds : SignatureValue ＞ iPUoju1hu4o7UTYJKL
＜ /ds : SignatureValue＞
＜/ds :SignedInfo ＞
……
＜ ds : SignatureValue ＞ ioikUERii47yukjkdk
＜ /ds : SignatureValue＞
＜/ds: Signature＞
＜/SOAP-SEC: Signature ＞
＜/SOAP-ENV: Header＞
＜ SOAP-ENV: Body
xmlns: SOAP-SEC = schemas. xmlsoap. org/ soap / security/2000-12
SOAP-SEC: id = "Body"＞
＜m: GetFirstStudent xmlns:m = “some-URI“＞
＜m:symbol ＞ BeiJing University＜/m:symbol＞
＜/m: GetFirstStudent ＞
＜/SOAP-ENV: Body ＞
＜/SOAP-ENV: Envelope ＞
SOAP头元素的扩展命名空间中加入安全特征，通过扩展，在方案中加入一个新的元素,这个元素在Schema中可以不用改变。如果要在SOAP1.1协议中进行加密性扩展,可以在命名空间中引入适当的标准实现，如XML加密算法(XML Encryption)等。SOAP头元素SOAP-SEC使用的XML命名空间[4]如下：http: ///soap/security/2000-12,命名空间的前缀“SOAP-SEC”就指向这里。
5 结束语
随着B2B、B2C电子商务的发展，企业要求能够与它的业务伙伴、顾客和供应商实现跨边界的、快速的、无缝的整合，而Web服务的通信是利用SOAP消息进行的，SOAP 消息常常跨越 Internet进行传递，因此消息的完整性显得尤为重要。作者在基于WS-Security规范的基础上，采用数字签名方式对SOAP消息头进行安全扩展,确保消息的完整性，但是web服务安全方面，仍有许多值得探索和研究的地方，相信随着W3C标准化进程的发展，SOAP的技术标准也会不断得到补充和完善，SOAP应用必定会更加广阔。
参考文献：
[1]李安渝,等.Web Services技术与实现.北京:国防工业出版社,2003:8-11.
[2]W3C Recommendation Version 1.2 Part0:Primer.[EB/OL]./TR/2003/REC-soap12-part0-20030624/.
[3]W3C SOAP Security Extensions: Digital Signature[EB/OL]./TR/2001/NOTE-SOAP-dsig-20010206.
[4]XML-Signature Syntax and Processing[EB/OL]./TR/2000/CR-xml-dsig-core-20001031,2000-10.
收稿日期：2008-01-08
soap协议范文第3篇
[关键词]XMLSOAP互操作分布式
中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)1210057-01
在企业的信息化进程中,信息资源具有多源海量性、分布异构性、时间动态性等特点,原有的异构分布式系统难以满足信息化进程快速发展的要求,如何实现企业异构系统的资源共享,应用程序的跨平台、跨语言、跨硬件的无缝集成是目前企业集成亟待解决的问题。
一、传统模式的分布式对象互操作存在问题
传统的分布式平台,如Microsoft的DCOM以及Microsoft之外的CORBA
或Java RMI都依赖于周密管理的环境。两台任何的计算机使得DCOM或CORBA在环境之外被成功调用的几率是很低的。特别是在考虑安全性的时候尤其如此。
DCOM和CORBA都依赖于高技术的运行环境。这两个协议都有复杂的规则来处理数据排列、类型信息和位操作。这增加了移植到其他平台的难度。由于存在以上问题,导致这两种系统之间很难实现互操作,而XML和SOAP技术的产生和发展使Internet上分布式对象间的互操作称为可能。
二、基于SOAP实现异构分布式对象互操作的主要任务
1.必须定义一个完整的XML文档语义,使得嵌入在SOAP报文中的XML文档能够被无二义地解析成对特定组件的调用。该定义必须适合各种主流的分布式组件协议,并且是可扩充的,以适合将来新的组件技术。
2.必须实现一个能够接受并处理SOAP报文的SOAP适配器。由于使用标准的HTTP协议,我们需要监听网络的8080端口,接收含有XML文档的SOAP报文。
3.必须实现一个可以接收服务器端返回的SOAP报文的客户端组件,该组件可以使用各种语言开发,使得用户可以容易地处理分布式组件调用的结果。
三、关键技术
(一)标准的数据格式:XML。XML(Extensible Markup Language)是W3C开发的一种可扩展的标记语言,以用于那些目前HTML无法满足要求的应用。它提供了一种新的数据交换的标准,使得为特定的应用制定特殊的数据格式,在各系统之间传递结构化数据成为可能。XML具有以下特征:
1.可扩展性强。XML的层次较高,是一种可用来“设计语言的语言”,引用范围广,并可随着人们的想象空间而无限自由的扩展。
2.异构系统兼容性好。借助XML,异构系统之间可以方便地进行信息交流。XML格式简单易读,对各种类型的数据都能加以标注。只要系统安装有XML解析器,便可解读来自其他系统的信息,进而加以利用。
3.网络应用灵活性强。XML格式的数据文件既能通过网络传送到其他应用软件、对象或中间服务器做进一步的处理,亦可由浏览器进行浏览,为灵活的分布式应用软件的开发提供了支持。
(二)简单对象存取协议SOAP。SOAP以XML形式提供了一个简单、轻量的用于在分散或分布式环境中交换结构化和类型信息的机制。它通常将HTTP作为底层的传输协议,采用XML格式来封装调用请求和回应信息。特别适合面向对象的网络应用系统。SOAP由四部分组成:
1.SOAP信封。它构造定义了一个整体的表示框架,可用于表示在消息中是什么,谁应当处理它。
2.SOAP编码规则。定义了一个数据的编序机制,通过这样一个编序机制来定义应用程序中需要使用的数据类型,并可用于交换由这些应用程序定义的数据类型所衍生的实例。
3.SOAP RPC表示。定义了一个用于表示远端过程调用和响应的约定。
4.SOAP绑定。定义了一个使用底层传输协议(如HTTP\SMTP等)来完成在节点间交换SOAP消息的约定。
四、基于XML和SOAP技术的互操作模型
(一)互操作模型体系结构。在基于Web的异种分布式对象平台的互通中,关键在于双方的异构系统与SOAP报文的转化,使得不同的分布式对象技术可以与SOAP交互通信,因此必须使不同的异构系统支持SOAP,能够与SOAP进行互相通信。为此本文提出一个基于SOAP的分布式对象远程调用系统模型,即以XML为数据表现形式,以SOAP为应用间的通讯协议,通过对服务的统一描述达到共享,实现异构分布式对象的互操作。
SOAP分布式调用系统沿用了DCOM的proxy/stub结构,在客户端和服务器端分别增加了SOAP客户和SOAP服务器一层,原有的调用机制发生了变化,本地内核接收到消息后,不直接发给远程内核,而是发往本地的SOAP客户端,由SOAP客户端发往远程的SOAP服务器。相对而言,COM和CORBA对象的服务器端对象会保持不变,而客户端应用则是千变万化的,并且客户程序与服务器端对象是完全独立的。SOAP客户端提供了相应的API函数接口供客户端调用,即客户端应用程序显示的调用SOAP客户端的API接口,将请求直接发往SOAP客户端。在服务器端,SOAP服务器接到请求后,向服务器端对象发出调用请求,请求的结果直接返回到服务器端SOAP层。
(二)互操作模型的工作原理。当客户端的应用程序需要从网络中某个节点处获得一定的数据或服务时,发现这些数据和服务可能处于一个运行着和客户端不同的操作系统的服务器上,客户端应用程序中负责查找数据的那一部分只要通过调用SOAP客户端提供的API函数,SOAP客户端将完成到网络中查找数据源或服务,并进而传输客户请求、组装应答消息,最后将结果送回应用程序的任务。
SOAP客户端完成的功能包括接收客户程序发出的调用请求,将之转化为SOAP消息格式,并将SOAP请求消息发送到服务器端,服务器端对象执行这个请求,再由SOAP服务器端将执行结果返回到客户端。即SOAP既作为一个HTTP消息,也作为一个SOAP服务器,创建和解开SOAP消息。
这个互操作模型有效的解决了不同类型的对象之间的互相调用的问题,客户只要知道提供服务的对象的URI和对象接口的XML描述,就可以自由的进行远程过程调用,而无需知道对象使用什么机制实现的,调用方和被调用方之间是透明的。
(三)基于XML和SOAP实现异构分布式对象互操作模型分析。基于XML和SOAP实现异构分布式对象互操作模型的优点:
我们在调用各种分布式组件时,可以不受限于其特定的编程框架。具体的组件协议对用户来说时透明的,简化了用户分布式组件的开发。
由于采用了标准的HTTP协议与SOAP协议,在分布对象环境中实现信息资源的重用、重构和共享,实现面向协同应用的相信共享与应用互操作是低成本的,在未来的应用中,也会产生相当大的作用。
由于这种技术可以推广到其他各种分布式组件协议上,也就是说,基于标准的XML解析,使得对各种分布式组件协议的集成成为可能。
五、结束语
随着计算机网络技术的发展,利用网络技术实现信息共享、管理和提
供信息服务的系统越来越称为研究的热点。本文提出了一个基于XML和
SOAP的异构分布式对象互操作模型,一定程度上实现了跨平台的组件通讯以及组件重用的思想,解决了DCOM和CORBA难以在Internet上互相调用、互相通信的局限性,解决了广域、异构信息的互联、互通和互操作问题,达到消除信息孤岛现象,以满足各个组织信息共享需求的目标。
参考文献:
[1]王小非、张鸿海,海上网络战[M].北京:国防工业出版社,2006.
[2]曾宇、查杰民,基于Web服务的应用程序集成的研究[J].计算机工程与设计,2006,27(2).
[3]鞠彦辉,基于Web Services技术的企业信息集成系统架构研究[J].中国管理信息化,2007,10(2).
[4]夏厚德,基于SOAP协议的分布式应用研究[J].武汉科技大学学报,2003,25(3):298-300.
作者简介:
soap协议范文第4篇
关键词：Web Service； XML； SOAP； 嵌入式系统
中图分类号：TN91934； TP311文献标识码：A文章编号：1004373X(2011)22006104
Implementation of Web Service Technology in Embedded Environment
WANG Haili, ZHOU Xingpeng
(School of Automation, Southeast University, Nanjing 210096, China)
Abstract： To cope with the interoperability and integration between embedded system and other heterogeneous systems, a new approach of applying Web Service technology in lowend embedded equipments is proposed. Based on ARM CortexM3 microcontroller, miniature realtime operating system and embedded TCP/IP protocol stack, the implementation process of Web Service is elaborated, including HTTP message reception, XML/SOAP protocol parse and service function bind. Special care is taken to minimize resource consumption in this resource constrained environment. Load test performed by dedicated test tool proved the good feasibility and stability of the proposed approach.
Keywords： Web Service; XML; SOAP; embedded system
收稿日期：201106070引言
近年来随着网络化概念的不断推广，嵌入式系统也摆脱了以往“信息孤岛”的封闭局面，相互之间逐渐形成了分布式的协作关系。然而嵌入式系统在网络的应用层上常常采用自定义的传输协议，加之各系统之间巨大的平台差异性，给系统间的互访以及企业级信息的集成带来了困难［1］。Web Service技术具有良好的跨平台和松耦合特性，能够实现不同平台的分布式系统之间的无缝集成，降低了企业进行设备升级和服务重组时的投入［2］。本文以32位微处理器ARM CortexM3为核心，借助于嵌入式TCP/IP协议栈和实时操作系统，在嵌入式环境下实现了Web Service技术。
1Web Service与SOAP协议
Web Service是网络化应用的一种，可以将其看成一种函数调用，只不过这个函数的实体存在于某个服务器上，而对函数的调用在客户端进行，客户端只要接入装有服务的机器所在的网络即可调用函数。为了实现这种远程调用，需要对传输的数据格式采取一些约定措施，简单对象访问协议（Simple Object Access Protocol，SOAP）很好地应对了这种需求［3］。SOAP协议以XML形式提供了一个简单、轻量的机制，用于在分布环境中交换结构化信息。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个模块化的封包模型和在模块中进行数据编码的方法，定义了一个简单的表示应用程序语义的机制［4］。
SOAP消息是由Envelope，Header和Body三部分组成的XML文档，其中Envelope是SOAP消息的根元素，必须在SOAP消息中出现；可选的Header元素包含有关 SOAP 消息的应用程序专用信息；必需的Body元素包含打算传送到消息最终端点的实际SOAP消息 ［5］。最后，为了进行基于SOAP的远程调用，需要一种低级传输协议。SOAP规范允许使用HTTP，SMTP甚至原始的TCP/IP套接字，其中HTTP协议最为常用。
2Web Service在嵌入式环境下的实现
2.1底层软硬件结构
本文中所使用的硬件基于ST公司推出的ARM CortexM3 32位微处理器STM32F107VC［6］。CortexM3是针对价格敏感但又有高系统效能需求的嵌入式应用而设计的ARM内核，作为ARM7的后继者，大刀阔斧地改革了设计架构，显著简化了编程和调试的复杂度，处理能力也更加强大［7］。STM32F107VC工作频率最高为72 MHz，带有256 KB的片上FLASH和64 KB的SRAM，以及以太网MAC控制器，因此外接一片PHY芯片RTL8201，完成与以太网的物理通信。
为了达到实时任务管理，本文选用嵌入式实时操作系统FreeRTOS和轻量级TCP/IP协议栈lwIP组成底层软件开发平台。FreeRTOS作为一个免费开源的小型实时内核，主要用于建立和管理各个模块的任务［8］；lwIP则为数据的TCP/IP封装提供了一个良好的软件基础［9］。
2.2SOAP消息的处理
目前已经有许多成熟的SOAP工具，例如针对C++的gSOAP、针对Java的kSOAP等，但是这些实现方案均是为PC机或者带有高级操作系统的嵌入式系统设计的，对资源的消耗较多。对于低端的嵌入式环境，需要更轻量型的处理方法。
由前文可知，SOAP可以简单的理解为HTTP+XML+远程调用规则，因此SOAP消息的处理也分为3步：HTTP协议的实现、XML解析、具体服务实现。其总体结构如图1所示。
图1总体实现框架SOAP在HTTP上的远程调用的具体实现过程大致如下：客户端通过SOAP工具生成基于XML文档的SOAP消息，在该SOAP消息里包含有客户请求的服务名称及调用服务程序所需的参数，并使用HTTP POST方法通过网络向应用程序所在的服务端发送 SOAP请求；另一方面，当服务端接到HTTP信息之后，又从中提取出SOAP 消息，启动XML文档解析器进行解析，获取客户需要调用的方法名及其参数，以此来调用相应的服务程序，之后以类似的方法将运行结果打包成SOAP消息返回给客户，完成应用程序的远程调用。
2.2.1HTTP协议的简单实现
soap协议范文第5篇
论文摘要：随着计算机网络的迅猛发展．现代企业和政府部门要求网络信息系统能够是松散耦合的、有良好的跨平台性，并且设计简单。soap正是基于此类需要而产生的协议。但是soap的特点使得基于其上的应用在效率的表现上较为低下。通过分析soap的请求响应机制．对这一过程中的某些方面优化的可能进行了一些探讨。
0引言
soap协议往往生成冗长的请求与应答, http并不是有效率的通信协议，除此以外，基于文档的开放的无状态的协议处理客户端请求必须做更多的工作，其中包括必须对请求和结果进行语法分析，传输的内容的要进行序列化，xml需要文件解析等等，所有这些都需要耗费大量时间。因此，soap调用的等待时间往往高于corba调用的等待时间，基于soap的网络信息系统也显得效率低下。因此，必须找出不足的原因.并找出提高效率的对策。
1 soap服务分析
soap是一个在分散化的分布式环境中用来交换信息的轻便协议。一个典型的soap服务通常包含以下组件:soap客户机、soap服务器、实际服务(如图1)。
2讨论和优化
作为简单性和可伸缩性的代价，soap的调用过程耗费了大量的时间在序列化(对象到xml)、解析(xml到对象)、将用户的请求传输给后端服务器以及网络传输上，以下针对这些方面进行进一步讨论和优化处理。
2.1硬件扩充
从硬件的角度来看，可以从“内缩放”和“外缩放”来改进等待时间。内部缩放，即可以通过为服务器使用更多的或更好的硬件来改进软件的性能，例如采用更多的cpu、内存以及更高的网络带宽、增加传输的高速缓存器等。外部缩放，即通过把负载分布到多台服务器上来改进系统的性能。这时要求分布式网络系统要么是无状态的，要么在多台计算机之后共享状态。
2.2解析的考虑
有两种处理xml数据的模型:使用语法分析器产生的语法事件序列，直接输人到用户的处理中;或者首先把嵌套的节点、xml源结构构造成一个表示该程序的树中，然后通过与这些树形的数据类型相关的api来操作xml数据。这两种模型导致了两个不同的xml解析标准:
(1)基于事件的解析器sax(simple api for xml)
(2)基于树型的解析器dom (document object model )
(3)选择和改进
采用sax或者dom实际上是各有利弊的。
如果在soap body中包含了大量的数据，可以在具体应用中进行合适的分段解析(见图2)，在body中将这些数据分成适当大小的数据块，然后发送出去。而soap消息的接受端的处理程序将会把每个块元素视为一个原子，利用sax进行解析。处理中，将视每个块元素被成功处理与否，而将相应的确认加入到soap响应中去。当soap请求消息被处理完毕之后，soap响应消息的生成处理也同时被完成。因此，消息的处理和响应的生成是交错进行的，这样做可以有效地提高了处理的时间。
当然，也可以适当对dom分析器做一些改进氏在文档很庞大的情况下，采用一种基于“拉”的技术的dom，也就是说，可以仅创建出要访问的那部分xml文档的基于dom的内存结构。具体操作是，在解析中，只有遇到感兴趣的那部分的节点，才将该节点相关的部分读人成为完整的dom树结构，即将其整个拉人内存中，然后可以调用常规的dom方法进行处理。这种做法将有助于克服dom的低效性，同时利用了dom能允许代码直接读和修改xml文档各部分的特性。
2.3利用高速援存技术
使用高速缓存技术的好处在于它改进了应用系统的响应时间，避免重复执行相同的计算操作，或是避免当结果集在一段时间内持续有效的前提下，重复执行后台复杂的数据库访问，因为一系列针对相同信息的请求可以使用被高速缓存的版本来响应，而无需重复地处理并占用系统开销。高速缓存机制的另一个好处则是针对数据的传输，应用了高速缓存机制之后，数据的副本可以存于叶节点服务器以方便本地的服务，而无需重复地访间中央信息库。这样，不仅加快了对信息的访间，同时缩减了对网络带宽的占用，减轻了中央服务器的负载。此外，高速缓存技术改进了soap服务中的瓶颈，降低了序列化对象到xml文档上所花费的时间。
2.4网络传抢
soap消息的传输是通过绑定相应的传输协议来实现的。尽管soap可以采用其他传输协议，但它通常都是通过http协议来完成网络传输工作的。
在使用http进行soap消息的传输时，必须在消息头指定消息体的长度。在http1.0中，这个值要在序列化后才能决定下来，然后填人消息头等待发送。所以在传输soap消息之前，系统中要有两个以供发送的缓冲器来分别存放消息头和消息体。并且要序列化完整的soap消息后以后才能完成消息头，再开始传输。这样做会增加系统调用，在消息很大时耗费大量的内存，并且在完成整个消息后才发送也延长了传输时间。
解决的办法是采用分块传送机制。可以将soap的消息体被分成适当大小的块以流的形式被传输.这时候不再需要计算整个消息体的大小.因为块大小是确定的，soap的接收者在处理消息时就能根据块的大小决定每块消息体在哪里结束。去掉消息体的长度意味着soap的发送者不用将整个soap消息放人缓冲区等待发送，而是将整个消息分块分批进行处理和传送，这样就允许网络传输和序列化能重叠进行，减少系统开销。同时，采用永久连接的方式，这将减少为每一个消息产生新连接的开销。
3结语
soap协议范文第6篇
关键词：Web服务；SOAP头；身份验证；ASP.NE；C#
中图分类号：TP393文献标识码：A文章编号：1009-3044(2009)04-0849-02
Authentication Technology of Web Services Based on SOAP Header
LU Shou-dong
(Department of Computer And Information Management, Guangxi University of Finance and Economics, Nanning 530003, China)
Abstract: This paper introduces the authentication technology of Web Services based on SOAP header, and explains its programming pattern under .NET plat through the concrete example.
Key words：Web Services; SOAP Header; Authentication; ; C#
Web服务（Web Services）是目前最为流行的应用于异构环境的分布式组件开发技术。作为一种部署在Web上的可编程访问的对象，如何确保其安全性是在具体应用中必须考虑的一个重要问题。为控制对Web服务的合法访问，对服务使用者的身份进行验证是很有必要的。本文主要介绍一种基于SOAP头的Web服务身份验证技术，并通过具体示例说明其编程模式。
1 Web服务简介
Web服务是一种通过网络进行、发现、调用的自描述的服务器端软件组件，其实现依赖于一系列的标准协议或规范（如图1所示），包括HTTP、XML、SOAP、WSDL、UDDI等。简言之，Web服务以XML与XML Schema为数据编码格式与数据类型标准，使用WSDL进行描述，使用UDDI进行与发现，使用SOAP进行访问，并通过HTTP等进行传输。Web服务的上层核心标准都是基于XML的，具有优异的跨平台特性，这为Web服务在异构平台上进行系统的集成与交互提供了充分的保证。
2 SOAP协议概况
SOAP即简单对象访问协议（Simple Object Access Protocol），是一种基于XML的、简单的、轻量级的通信协议，用于在客户端与Web服务之间传递消息（包括请求消息与响应消息）。
SOAP协议使用XML描述消息。一个SOAP消息其实是一个XML文档，包括Envelope（SOAP信封）、Header（SOAP头）、Body（SOAP体）3个元素。其中，Envelope是整个SOAP消息的根元素，是必须的；Header是SOAP消息是可选元素，若存在，则必须是Envelope的第一个直接子元素；Body是SOAP消息必须有的元素，而且是Envelope的直接子元素，用于包含Web服务的调用信息（如所调用方法的名称及有关参数等）或响应信息以及相关的错误信息。SOAP消息的结构如图2所示。
在SOAP消息中，SOAP体的使用是由SOAP协议规定，而SOAP头的使用则较为灵活，可由用户根据需要进行定制。通常，可在SOAP头中添加一些条目，以包含具体应用所必须的重要信息（如账户信息、事务标识等），并据此实现相应的功能。
3 基于SOAP头的身份验证
通过在SOAP头中添加适当的验证信息，并由Web服务的进行读取与处理，即可实现对服务使用者的身份验证。在此，以 Web服务为例，说明基于SOAP头的Web服务身份验证技术。
3.1 基本步骤
Web服务允许定义并处理SOAP头条目，其基本步骤为：
1) 创建一个继承自SoapHeader的类AuthSoapHeader，该类的名称与公共成员变量即为SOAP头条目元素的名称与内容子元素。
2) 在Web服务类中声明一个AuthSoapHeader类的公共变量MyASH。
3) 为Web服务的有关方法应用SoapHeader属性，并将其MemberName属性设置为MyASH。
4) 在应用了SoapHeader属性的Web服务方法中访问MyASH的成员变量，并完成相应的处理过程。
相应地，在调用Web服务的客户端，可通过以下基本步骤设置SOAP头条目：
1) 创建一个Web服务的实例变量MyAService。
2) 创建一个AuthSoapHeader类的实例变量MyASHeader，并为其成员变量赋值。
3) 将MyASHeader赋给MyAService.AuthSoapHeaderValue（即设置SOAP头条目），并调用Web服务的有关方法以完成相应的功能。
3.2 应用示例
如图3所示，为一系统登录表单，用于对系统用户进行身份验证，其验证过程是通过调用Web服务完成的，而用户名与密码则通过SOAP 头进行传送。为简单起见，该示例假定用户名与密码均非空串时即为合法。单击“确定”按钮后，若为合法用户，则提示信息显示为“Success”，否则为“Failure”。下面，简述该示例的设计要点。
1) Web服务AuthService的设计
在Visual Studio .NET中使用 Web服务模板新建一个Visual C#项目AuthService，并将Service1.asmx重命名为Authentication.asmx，然后在Authentication.asmx.cs中编写相应的代码。关键代码如下：
……
using System.Web.Services.Protocols;
namespace AuthService {
public class AuthSoapHeader : SoapHeader {
public string Username;
public string Password; }
[WebService(Namespace="/webservices")]
public class AuthService : System.Web.Services.WebService {
……
public AuthSoapHeader MyASH;
[WebMethod]
[SoapHeader("MyASH")]
public string AuthenticateUser() {
if (MyASH==null)
return "Failure!";
if (VerifyUser(MyASH.Username,MyASH.Password))
return "Success";
return "Failure"; }
private bool VerifyUser(string Username,string Password) {
if ((Username!="")&&(Password!=""))
return true;
return false;
} } }
2) 客户端Login.aspx的设计
① 在Visual Studio .NET中使用 Web应用程序模板新建一个Visual C#项目AuthClient。
② 添加对Web服务AuthService的Web引用，并命名为Authentication。
③ 将WebForm1.aspx重命名为Login.aspx，同时设计好其界面（如图3所示），主要包括用户名文本框TB_Username、密码文本框TB_Password、提示信息标签L_Message与“确定”按钮。
④ 为Login.aspx.cs添加功能代码。
首先，引用命名空间AuthClient.Authentication：
using AuthClient.Authentication;
然后，编写“确定”按钮的单击事件代码：
AuthService MyAService=new AuthService();
AuthSoapHeader MyASHeader=new AuthSoapHeader();
MyASHeader.Username=TB_Username.Text;
MyASHeader.Password=TB_Password.Text;
MyAService.AuthSoapHeaderValue=MyASHeader;
L_Message.Text="提示信息:"+MyAService.AuthenticateUser()+".";
4 结束语
SOAP头为Web服务及其客户端之间关键数据的传递提供了一种灵活且有效的途径，有利于实现身份验证、事务处理等特殊功能。文中所述，即为利用SOAP头对Web服务使用者进行身份验证的关键技术与与典型模式。
参考文献：
[1] 石国志 Web服务实用案例教程[M].北京:清华大学出版社,2004.
soap协议范文第7篇
WebServices的基本元素是可扩展标记语言（ExtensibleMarkupLanguage，XML）、SOAP、Web服务描述语言（WebServicesDescriptionLanguage，WSDL）。XML用来编解码数据，SOAP用来传输数据，WSDL用来描述WebServices及如何访问WebServices。XML与超文本标记语言（HypertextMarkupLanguage，HTML）一样，都是标准通用标记语言（StandardGeneralizedMarkupLanguage，SGML）。XML是Internet环境中跨平台的依赖于内容的技术，是当前处理结构化文档信息的有力工具。SOAP是一种简单的基于XML的协议，使应用程序通过超文本传送协议（hypertexttransportprotocol，HTTP）交换信息。WSDL是基于XML的用来描述WebServices及如何访问WebServices的一种语言。WSDL可描述WebServices，用于WebServices的消息格式和协议的细节。使用WebServices技术作为接口技术的基础有以下优点。1）数据交换。WebServices使数据交换更方便，实现跨防火墙的通信，以一种最简单的方式实现异构系统间的互通信和数据交换，且能跨平台。2）数据封装。WebServices使用XML对数据封装，使用者能且仅能看到该对象提供的功能列表。3）应用程序集成。不同编程语言编写的应用程序通常都有一定的应用环境，集成起来会有很多技术壁垒，需要花费较多资源才能实现。通过WebServices，应用程序可用标准的方法把功能和数据“暴露”出来，供其他应用程序使用，简单方便。4）低成本。在实际项目中的开发成本最低，无论从软件开发人员的培训和WebServices产品的购买都较廉价。
2接口的技术方案
2.1采用基于中间数据库视图方式
根据需要对外发送的数据，组织SQL语句，把结果以数据库视图的方式建立。其他系统的接口程序通过分配具有一定权限的账户，访问中间数据库视图获取数据。该方式的优点：程序可自由访问数据库，访问的内容和访问的组合方式均可由应用程序自定义，并且可自定义SQL语句组织查询结果。缺点：数据库安全性差，非系统内部程序可直接接触到数据库层面，对信息保密有隐患。
2.2采用基于REST风格服务方式
表述性状态转移（RepresentationalStateTrans-fer，REST）代表了分布式超媒体系统的体系结构风格，是一种针对网络应用的设计和开发方式，可降低开发的复杂性，提高系统的可伸缩性。REST提出一些设计概念和准则：①网络上的所有事物都被抽象为资源；②每个资源对应一个唯一的资源标识；③通过通用的连接器接口对资源进行操作；④对资源的各种操作不会改变资源标识；⑤所有操作都是无状态的。该方式的优点：可利用缓存提高相应速度。通信本身的无状态性能使不同的服务器处理一系列请求中的不同请求，提高服务器可扩展性。浏览器可作为客户端，简化软件需求。缺点：安全性比SOAP低。对HTTP的依赖性高，需要通过HTTP的返回码区分返回结果。
2.3用基于SOAP协议的WebServices调用方式
SOAP可以和现存的多种因特网协议和格式结合使用，包括HTTP，简单邮件传输协议（SimpleMailTransferProtocol，SMTP），多用途网际邮件扩充协议（MultipurposeInternetMailExtensions，MIME）。还支持从消息系统到远程过程调用协议（RemoteProcedureCallProtocol，RPC）等大量的应用程序。该方式具备以下优点。1）具有可扩展性。SOAP客户端、服务器和协议自身均能吸纳新技术不断发展，而且升级更新时也不必中断已有的应用程序。2）SOAP调用简单。客户端只需发送一个请求，服务器获取请求后调用相应的对象，然后把调用的结果返回给客户端，完成一次调用交互。3）SOAP完全和厂商无关，与编程语言、平台无关。缺点：较复杂，对于大量并发应用，效率不高。根据以上方案的比较，结合智能电网通信管理系统对接口方面的要求，综合利弊，采用基于SOAP的WebServices方式实现接口功能。
3接口的设计与解析
3.1功能结构
智能电网通信管理系统接口软件（以下简称接口）采用接口调用方主动发起数据请求，接口提供方返回相应请求数据的应答模式。接互示意如图1所示。
3.2技术约定
为保证不同厂家开发的接口服务端和客户端软件能顺利实现接口调用，对WebServices具体接口实现过程作出如下规范及版本约定：1）整个接口消息基于XML语言，必须符合XMLV1.0（及更高版本）规范和XMLSchema（及更高版本）规范；2）接口实现必须使用SOAP协议，接口描述必须使用WSDL语言；3）接口实现方必须向接口调用方提供本端服务的WSDL文件，建议使用WebURL方式实时提供；4）接口实现必须符合SOAPV1.1版本规范，高版本SOAP协议必须保证与1.1版本的兼容性；5）接口实现必须至少支持SOAP在HTTPV1.0协议上的传输；6）接口实现必须符合WSDLV1.1版本规范，高版本WSDL语言必须保证与1.1版本的兼容性；7）接口描述必须至少支持WSDL在SOAPV1.1协议上的绑定；8）接口实现必须支持WS-IBasicProfileV1.0（及更高版本）互联互通协议。
4结语
智能电网通信管理系统接口的设计和实现是一个多技术的融合，还包括了账户登录验证技术、数据加密技术等，限于篇幅不一一详述。系统接口技术就是把互相独立的系统之间建立沟通桥梁，使数据和信息能够共享，使系统的功能和应用范围扩大，系统间不再孤立。从软件的接互过渡到软件与人的接互。不管接口使用何种技术、何种实现方式，最终目的都是提高工作效率，使繁杂的工作简单化，使各种系统应用更加方便。
soap协议范文第8篇
关键词：Android；Web Service；ksoap2
中图分类号：TP393文献标识码：A文章编号：1009-3044(2012)20-4904-03
In the Development of Android Web Service Network Programming Research
WU Zhi-yong
(Guangdong Female Polytechnic College, Guangzhou 511450, China)
Abstract: This paper describes the implement of Web Services functionality on Android platform. And design a program for inquiries to phone numbers attribution, to show the way to remote calls Web Service function.
Key words: Android; Web Service; ksoap2
Web Service是一种面向服务架构（Service-oriented architecture，SOA）的技术，目的是实现不同平台的应用服务之间的相互调用。Android作为一个市场占有率第一的移动操作系统，其网络功能是最重要的特性之一。在Android开发中通过Web Service可以方便地实现不同平台之间的方法调用，从网上获取数据信息和实现功能扩展。Web Service通过标准的Web协议提供服务。
通过Web Service实现远程方法调用，获取数据信息，最关键的问题是数据访问和传输的协议规范。
SOAP协议（Simple Object Access Protocal，简单对象访问协议），它是一个分布式网络环境下用于信息交换的通讯协议。在此协议下，应用程序和软件组件可以通过标准的Web协议进行通讯。SOAP使用基于XML的可扩展消息格式，需同时绑定一个传输用协议。这个协议通常是HTTP或HTTPS，但也可以使用SMTP或XMPP。
WSDL是一个XML格式文档，用以描述服务端口访问方式和使用协议的细节。通常用来辅助生成服务器和客户端代码及配置信息。
UDDI是用来和搜索WEB服务的协议，应用程序可藉由此协议在设计或运行时找到目标WEB服务。
Java开发中的Web Service有很多种实现方式，如XML-RPC、XFile、Axis等等，可是这些库并不适合资源有限的Android手机客户端。在Java ME版本中，广泛使用的是KSOAP。虽然Android并不使用Java ME，但是KSOAP也有Android下的可用版本ksoap2-Android。
2.1 ksoap2-Android
kSOAP是的一个开源作品，是EnhydraME项目的一部分。ksoap2-Android是ksoap2在Android下的一个移植版本，利用它可以非常方便地访问Web Service。ksoap2的常用接口有：
org.ksoap2. SoapObject
org.ksoap2. SoapEnvelope
org.ksoap2. SoapSerializationEnvelope
org.ksoap2.transport. HttpTransport
SoapObject用于创建SOAP对象，实现SOAP调用；
SoapEnvelope实现了SOAP标准中的SOAP Envelope，封装了head对象和body对象。
SoapSerializationEnvelope是ksoap2中对SoapEnvelope的扩展，支持SOAP序列化(Serialization)格式规范，可以对简单对象自动进行序列化(Simple object serialization)。
HttpTransport用于进行Internet访问/请求，获取服务器SOAP。
2.2 ksoap2-Android的编译配置
图1
＜TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content" android:text="@string/phonenumber" /＞＜EditText
android:id="@+id/EditTextPhoneNumber" android:layout_width="match_parent" android:layout_height="wrap_content" android:inputType="phone" ＞
＜requestFocus /＞＜/EditText＞＜Button
android:id="@+id/btnCheck"
android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/btnCheck" /＞
3.2查询的代码
soap协议范文第9篇
电子商务应用系统的安全要素通常包括数据的机密性、完整性、用户授权、身份的可鉴别性和不可否认性等方面。将基于SOAP协议的WebServices[1]技术应用到电子商务，虽然很好地解决了电子商务的应用集成和分布式应用，但由于SOAP协议是一个基于XML的轻量级协议，其设计目标在于它的简单性和可扩展性，在制定时并没有过多考虑安全性要求，加之SOAP协议规范本身没有提供安全解决方案，因此在不安全的公用网络传输时，SOAP消息中的敏感信息很容易被人窃听、篡改或伪造，从而造成数据的泄密和数据完整性的破坏。电子商务中整个WebServices的通信，都是通过SOAP消息来实现的，若不能很好地解决SOAP消息的安全问题，则将极大阻碍WebServices在电子商务领域的应用。
2SOAP消息安全性改进
在电子商务应用中，通信双方常常通过交换商务文档来进行电子商务交易。发送方会将一个或多个文档包装在一个请求消息中，然后发送给接收方；接收方处理该消息的内容后响应发送方。当一些业务应用被调用后，一个包含业务文档的请求将从SOAP发送者发送给SOAP接收者，而位于SOAP接收者端的业务应用将处理这个请求并生成响应，这个响应被回送给发出该请求的SOAP发送者。商务文档的网络传输路径上存在许多恶意的攻击者，它们可以监视网络中传输的消息，并可能按照传输消息的协议格式发送欺骗性的假消息或者对原消息的内容进行更改。比如攻击者中途截取消息，对该消息进行处理之后再转发，这对电子商务的安全构成极大的威胁。
通过对SOAP消息安全性研究发现，所有的攻击都是对SOAP消息的修改，或者在SOAP消息的首部或实体删除一些部分以及在后面附加一些内容，或者添加一些全新的元素[2]。SOAP消息中的XML元素可能被处理而导致一些意外的修改，这会使得原SOAP消息中某些元素的前驱后继关系被改变。而且意外的修改还可能导致SOAP消息中各元素的前驱、后继以及兄弟元素的数量被改变，这样原SOAP消息元素的层次结构也被改变了。SOAP消息可以在传送的过程中被扩展，而在SOAP首部中没有包含与SOAP消息的结构相关的信息，而攻击者利用最多的恰恰是SOAP的层次化结构。所以，本文引入一个称为SOAPRECORDER的数据结构概念，它用来保存SOAP消息的动态结构信息。SOAPRECORDER的基本作用是在其中保存SOAP消息的各元素的结构（例如：首部元素的个数、签名对象的个数以及签名对象的层次信息等等）。这些信息可以在SOAP消息的发送程序创建该SOAP消息的同时进行计算，因此不会引起额外的开销。
2.1SOAPRECORDER结构
SOAPRECORDER信息的结构如图1所示。SOAPRECORDER中包括的内容有：根结构下的子元素的个数、首部元素的个数、签名元素的参考项的个数、签名对象之间的前驱、后继以及兄弟关系和扩展的部分。电子商务文档在网络传输时所受到的攻击主要是利用SOAP消息结构化语法的漏洞，所以解决这一问题的有效的手段就是在SOAP消息中添加SOAPRECORDER信息。消息的接收方在接收到SOAP消息的同时对消息的结构信息进行计算，然后与消息中的SOAPRECORDER信息进行比较，如果两者出现差异，则说明SOAP消息在传送的途中受到了篡改攻击。SOAP消息的发送者如果在消息中添加了SOAPRECORDER信息，那么在发送消息前必须对SOAPRECORDER信息也进行签名，以保证SOAPRECORDER信息在消息传送途中不被篡改。
2.2SOAP消息加密传输
由于SOAP消息在网络传输时受到威胁，所以要对其消息进行加密传输。本文采用一种加密和数字签名技术保证SOAP信息在公开网络上的安全传输[3]。SOAP消息请求者先用哈希函数从原始信息和扩展信息的组合信息中得到信息摘要SHash(M,W,Ex)，其中M为原始信息，W为需要嵌入的加密信息，Ex为扩展信息。并用自己的私密钥对信息摘要加密'()userSKSES，接着利用自己的对称密钥对三者的组合信息加密'(,,)userSSKWEMWEx，然后用服务提供者的公开密钥对请求者的对称密钥加密''()userPKserverWESSK，这样数字签名的正确性就可以由任何请求者公开密钥的人来验证；而加密后的对称只有服务提供者能够用私有密钥解开，这样就保证了SOAP信息在Internet传输过程中的安全。具体步骤如下：（l）数字签名SHash(M,W,Ex)；'()userSKSES；（2）信息加密'(,,)userSSKWEMWEx；''()userPKserverWESSK；（3）数据传输''''UserServer:{S,W,W}；（4）Server信息解密''()serveruserSKSSKDW；（5）Server签名验证（用得到的组合信息与哈希函数计算信息摘要，与解密后的信息摘要比较）''SHash(M,W,Ex)；'()userPKSDS；''?SS（比较两者是否完全一致，如果一致，说明签名正确，反之说明签名无效）；服务请求者构造SOAP消息，消息的Body部分包括上述三个方面的组合信息和服务的访问参数。为保证消息不会被网络上恶意破坏者篡改和伪造，对SOAP信息签名和加密是必需的步骤。加密按照WS-Security中的XMLEncryption规范[4]，通过扩展SOAP消息的Header的方式来实现。消息接收端在收到加密的SOAP请求后，解析SOAP消息的Header部分，得到服务请求者的X.509证书并验证其合法性。同时用私有密钥解密SOAP消息中加过密的对称密钥W，并用对称密钥解密加过密的组合信息W，然后用哈希函数和得到的组合信息重新计算信息摘要，并与解密后的信息摘要比较。在成功判断数字签名的正确性后，从消息中取出原始数据。
3SOAP消息安全性实现
本文设计一个称为SendSOAPRECORDER的模块向在Web服务间进行交互的SOAP消息中加入SOAPRECORDER信息。每一个SOAP消息的处理节点也都有一个相应的CheckSOAPRECORDER模块用来检查接收到的SOAP消息的安全性。如图2所示：当处理节点接收到SOAP消息时，先把该SOAP消息发送到本节点的CheckSOAPRECORDER模块进行检测，在经过节点的所有检测之后还要把该消息发送到本节点的SendSOAPRECORDER模块添加本处理节点的SOAPRECORDER信息。于是每经过一个处理节点，都会增加额外的两条进行SOAPRECORDER处理的消息。在一个节点传送SOAP消息前，首先计算出该消息的SOAPRECORDER信息，并在SOAP消息的首部或实体中将该信息添加到一个作为SOAP信封元素形式存在的首部下面，然后对它进行签名和加密。SOAP消息传送路径上的每个中间节点也对SOAP消息做同样的处理。SendSOAPRECORDER负责添加SOAPRECORDER信息。为了检测网络攻击，CheckSOAPRECORDER模块在接收到SOAP消息后会做一些常规的检测。一旦有SOAP消息到达，CheckSOAPRECORDER模块就会立即检测SOAP消息中是否有作为SOAP首部存在的SOAPRECORDER首部。因为在新伪造的首部下拷贝的SOAPRECORDER信息已经不再是作为一个独立的SOAP首部而存在，所以CheckSOAPRECORDER模块会立即抛出一个异常，警告消息接收者SOAPRECORDER信息已经被人攻击。如果包含该首部，CheckSOAPRECORDER模块将校验SOAPRECORDER的签名。如果SOAP消息传送途中经过了若干个中间处理节点，那么这些中间节点会在该消息中添加它们自己的SOAPRECORDER信息，这样SOAPRECORDER的签名可能出现嵌套的情况。如果签名校验不正确，就说明SOAP消息已经被恶意攻击。
4结束语
soap协议范文第10篇
[关键词]Web Service；SOAP消息；WSDL
中图分类号：TM743 文献标识码：A 文章编号：1009-914X（2016）08-0317-01
1.绪论
随着互联网络的广泛应用和发展，特别是.NET技术的升温和市场的日渐成熟，微软公司的.NET框架和SUN公司的J2EE框架均可作为开发平台和工具。只有少数有实力的公司具备开发两套独立的产品的实力，以满足不同的客户需求。更多的厂商则希望自己开发的产品能相互移植，并能更容易的与其他有需要的业务系统接口。
Web Service[1]的出现在一定程度上实现了上述所需要的功能。狭义的说：Web Service就是XML与HTTP相结合。HTTP是一个在Internet上广泛使用的协议。XML[2]是一种元语言，你可以用它书写特定的语言来描述客户和服务之间或者组件和复杂服务之间的交互。在通过Web Service之后，XML格式的消息被转变成中间件的请求，返回的结果也会转化成XML格式。
可见Web Service并不是一种新的技术，它是将 XML、Internet等网络软件技术有机结合后，所产生的一种新的web应用程序分支。它是一种包括自包含、自描述、模块化的应用，可以、定位、通过web调用。它可以执行从简单的请求到复杂商务处理的任何功能，一旦部署以后，其他Web Service应用程序就可以发现并调用它部署的服务。
2.Web Service 结构分解
因此，可以从两个角度分解 Web Service 结构：
1、 从每个单独的Web Service 使用者的角度：
服务的请求者：即任意 Web Service 的消费者，通过网络连接和发送XML 请求使用一个实际可用的Web Service。
服务的提供者：负责维护Web Service和提供相应的服务。
服务注册中心：即一个Web Service的“黄页”，使提供者可以新的服务，请求者可以找到需要的服务。
2、 从Web Service协议层的角度
Web Service的协议层仍在不断发展中。当前，一般将其分为4层
传输层：该层位于协议堆栈的最底层，主要负责在应用程序间传输信息。当前该层使用包括 HTTP、FTP、SMTP 协议在内的多种传统网络传输协议。
XML 消息层：该层负责将信息编码为通用XML格式，当前该层使用XML-RPC、SOAP（简单对象访问协议）。
服务描述层：该层负责描述指定Web Service的公用接口，当前该层使用 WSDL（Web Service Description Language，Web 服务描述语言）。
查找发现层：该层负责将Web Service集中到一个公用的注册中心，相当于一个Web Service
的“黄页”，并提供和查找功能，当前使用 UDDI（Universal Description，Discovery， and Integration，统一描述、发现和集成）。
不难看出，Web Service是建立在一些通用协议的基础上，如HTTP、SOAP、XML、XML-RPC、WSDL、UDDI等。这些协议在涉及到操作系统、对象模型和编程语言的选择时，没有明显的倾向，因此将会有较强的生命力。
3.SOAP
SOAP，简单对象访问协议[3]：用于分散或分布的环境中交换信息的简单的协议，它是一个基于XML的协议，通过 XML Schema 定义了传递数据时的统一方式。包括三个部分：
1、 描述消息中包含什么内容以及如何处理它们。
2、 用于表示应用程序数据类型的编码规则，主要使用 XML Schema 数据类型，并添加了 Array 和Struct，用于表示复杂的数据结构。
3、 表示 Request和 Response的协定。
Envelope：是每个 SOAP 消息的根元素。
Header：可选的Header 元素提供了一个可扩展的框架用于定义应用程序所需的额外信息。
Body：Body 元素是所有 SOAP 消息所必须的，一个典型的 Body 元素包含 RPC 请求和响应。
Fault：当发生错误时，Body元素将包括一个 Fault 元素，包含了该错误的所有详细信息。
WSDL，Web 服务描述语言
UDDI（Universal Description， Discovery， and Integration，统一描述、发现和集成）：
Web服务描述语言 （WSDL） 使用XML语法，用来描述一个Web Service能做什么，它的位置在哪里，如何调用它等等。当在以SOAP/HTTP/MIME作为远程对象调用机制的情况下，WSDL会发挥其最大作用[4]。
UDDI则描述了Web Service的绝大多数方面，包括服务绑定等细节。因此，WSDL可以看作是UDDI服务描述的子集。
4.结论与展望
当前的 Web Service 仍然不很成熟，主要表现在以下几个方面：
1、 由于Web Service的基础是 XML，SOAP、WSDL、XML-RPC、UDDI 都是通过 XML作为元语言定义的。但是XML定义仍不统一，虽然 W3C 在2001 年 XML Schema，用于代替 DTDs，但微软也抛出了自己的XML 定义模式-“XDR”。而且 DTDs 也还有一定的市场，所以对于“跨平台使用”，这个 Web Service 最大的优势，有所制约。
2、 Web Service本身不提供加密机制，这对使用者的安全性是一个巨大的挑战。而使用SSL机制加密，则对性能有很大的影响，保守估计下降 20%-30%。
瑕不掩瑜，作为 Internet的一个革命性进步，Web服务必将开创一个分布式应用程序开发的新时代。
参考文献
[1] 王建斌，胡小生，李康君， 赵靓，REST风格和基于SOAP的Web Services的比较与结合 [J]，计算机应用与软件，2010，27（9）：298-300
[2] 周军锋，孟小峰，XML关键字查询处理研究[J]，计算机学报 ， 2012，35（12）：2459-2478
[3] 刘志都，贾松浩，詹仕华，SOAP协议安全性的研究与应用[J]， 计算机工程，2008，34（5）：142-144