soap协议范文
时间：2023-03-17 02:28:28
导语：如何才能写好一篇soap协议，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
关键词：J2ME soap XML嵌入式系统
1 引言
J2ME作为嵌入式系统应用平台得到了迅速的发展，JAVA语言固有的平台无关性使得基于J2ME平台的嵌入式应用系统具有广阔的前景。受限于嵌入式设备及消费类电器硬件条件的限制，J2ME平台提供的功能有限，如何能够在有限的资源下拓展J2ME的功能，使得J2ME平台能够处理SOAP协议是本文研究的重点。
目前企业应用正在向面向WEB服务的SOA架构转变，嵌入式系统与企业应用系统的连接目前还处于TCP/IP协议、HTTP协议等比较初级的阶段。随着企业应用系统提供的WEB服务日益广泛和成熟，需要J2ME平台提供处理SOAP协议的需求也越来越多。
SOA架构是目前企业应用系统广泛部署的架构，实现SOA的关键问题之一就是对SOAP协议的支持。本文分析了在J2ME平台中实现SOAP协议处理遇到的问题，提出了相应的解决方案。
2 j2ME介绍[1] [2] [3]
J2ME（Java 2 Platform Micro Edition）是为无线电子市场所设计的JAVA平台，包括JVM规范和API规范。J2ME 定义了一套类库和虚拟机技术，这些技术可以使用户、服务提供商和设备制造商通过物理（有线）连接或无线连接，按照需要随时使用丰富的应用程序。J2ME同时提供了Java语言一贯的跨平台性和安全性。
为了支持用户和嵌入式市场提出的灵活性和可定制性要求，J2ME被设计得更加模块化和可缩放化。J2ME在设备原有的操作系统上建造了3层软件来实现这种要求：
1．JVM层：这层基于宿主操作系统，按照某一种J2ME的配置实现了JVM。
2．配置层：这层对于用户可见度要低一些，但对简表层非常重要。它针对不同市场的需求，定义了Java虚拟机的最小功能集合和Java类库的最小集合。在J2ME设备中，JVM与配置层紧密相连，它们体现了每一类设备的基本功能。
3．简表层：这层对于用户和应用程序提供者来说是最常见的。它针对特定市场的需求，定义了Java虚拟机的最小功能集合和Java类库的最小集合。
J2ME组件都围绕一个中心，这些中心被称为configuration（配置），它们中间的每一个都是用于消费电子和嵌入设备的特别的类。目前配置分为CLDC和CDC两种。
Connected limited device configuration(有限连接设备配置，简称 CLDC)定义支持“devices that you hold in your hand（握在手中的设备）”的应用程序接口和技术，这类设备的代表是PDA。Connected device configuration(连接设备配置 CDC )定义支持“devices that you plug into plug into the wall（插入墙的设备）”的应用程序接口和技术，这类设备的代表是机顶盒。
这两种配置不同的地方就在于它们应用于的装置的能力，CLDC设备的处理器能力有限 (与台式机系统比较 )，并且存储器大小一般也只在128 KB到 512 KB之间。CDC系统不同，它可能有32位或64位处理器，以及有限的存储容量，不过它的下限也得超过512K。
上图解释配置和简表的体系结构。J2ME的体系结构被横向地分成三层，纵向分成两部分。配置包括一个控制配置核心类的虚拟机，具体的简表位于每个配置之上。
简表为相同消费电子设备的不同的生产商提供了标准化的 Java类库，现在五个已知简表已经有了规范：
Mobile information devices profile (MIDP) 移动电话和呼叫器 CLDC
Personal digital assistant profile Palm和Handspring的PDA 设备 CLDC
Foundation profile 用于所有不需要GUI的CDC设备的标准简表 CDC
Personal profile 替代PersonalJava的Foundation完善的简表 CDC
RMI profile 提供RMI的Foundation完善的简表 CDC
3 SOAP协议介绍[4]
SOAP（简单对象访问协议）是一种利用XML编码数据的数据传输协议。它是同类协议中要求最低的一个规范，只定义了协议所要求的最关键的部分，有意地忽略了垃圾收集、对象激活等方面的细节。像TCP/IP协议一样，SOAP协议也包括客户端和服务器两个部分。
SOAP客户端是一种创建XML文档的程序，该XML文档包含在分布式系统远程调用方法所需的信息。SOAP客户端不是传统意义上的程序，它除了用作普通的桌面应用程序外，还可以是一种Web服务器或基于服务器的应用程序。来自SOAP客户端的消息和请求一般是通过HTTP发送的。因而，SOAP文档可以穿过几乎所有的防火墙，从而能跨越不同的平台交换信息。
SOAP服务器只是用于监听SOAP消息的特殊代码，它可用作SOAP文档的分配器和解释器。外部Web服务可以与基于J2EE技术的应用程序服务器交互，这种应用程序服务器可以处理多种客户端的SOAP请求。
SOAP定义了数据编码规则，称为基准编码或“Section 5（第5节）”编码，它是出自SOAP规范中描述数据编码规则的内容。SOAP编码可以简短地描述成简单值或复合值的集合。简单值可以是简单类型，如整型、浮点型和字符型，或者是XML架构规范第2部中定义的内置类型，包括各种数据类型，如字节型数组和枚举。复合值包括结构、数组和XML架构制定组定义的复杂类型。
SOAP在标准化消息格式环境中，可以做所有它能完成的工作。消息的主体部分是“text/xml”形式的MIME类型，并且包含一个SOAP封套。该封套是一个XML文档。封套包含了报头（可选的）和报文（必须有的）。封套的报文部分总是用于最终接收的消息，而报头项目可以确定执行中间处理的目标节点。附件、二进制数字及其他项目可以附加到报文上。
SOAP提供了一种让客户端指定哪个中间处理节点必须处理报头项目的方法。由于报头与SOAP消息的主体内容是互不相关的，所以可用它们给消息添加信息，而不会影响对消息报文的处理。
4 SOAP协议在J2ME平台中的实现
如何真正地将移动设备融入到Web Services中去呢？这就需要使得PDA、手机等成为Web Services的客户端，因此这些设备至少应该具有处理XML信息的能力。在J2ME平台中实现SOAP客户端的功能，使得嵌入式设备能够连接企业的WEB服务是企业应用中比较常见的需求。J2ME的基本类库中没有提供SOAP的支持，所以需要在J2ME平台中开发实现SOAP的处理功能。
实现SOAP协议客户端的关键问题分为两个方面：J2ME不同配置的数据类型不一样，导致与SOAP协议封装的数据类型不匹配；J2ME平台没有提供对XML文件进行处理的功能。
针对第一个问题，需要注意只能使用基本类型，对不匹配的数据类型采用使用基本类型复合的方式进行处理。针对第二个问题需要在J2ME中扩展对XML文件处理的功能。目前有有两种方法对XML文件进行解析。一种是采用DOM的方式，另外一种是采用SAX的方式。操作DOM是一个与XML相互作用的简单方法，通常这个XML是一棵完整的XML树，被解析成一个存放在存储器中的节点结构，你可以遍历这棵树。它非常简单易用，但是因为整棵树存在于存储器中造成存储器的负担，而对于嵌入式系统来说存储器的资源是有限的，因此这种方法的使用具有一定局限性。第二种方法在捕捉语法分析事件中，每当语法分析程序遇到数据中的特定结构，它就会遍历XML数据，然后把结果发回前面注册的一个事件监听器中。比如说，当语法分析程序遇到一个起始标记，如＜html＞，那么事件监听器将接收一个事件，通知它这个情况，并且向它传递任何所需的信息。相对DOM方式的处理，SAX方法对存储器的要求比较低，但是效率要比DOM方式低。
Enhydra的KXML是一个只占很小存储空间的XML语法分析程序，对于J2ME应用程序非常适合。KXML支持DOM语法分析和操作，但是不支持SAX语法分析。取而代之，它使用一种稍微不同的称为“Pull”的分析方法。
下面是KXML采用DOM的方式处理XML数据的例子：
1.Document doc = new Document();
2....
3.parser = new XmlParser(abc);
4.doc.parse( parser );
第一行创建了一个文档对象，保存XML树。第三行从一个名为abc的InputStreamReader中创建一个KXML语法分析程序。第四行传送这个语法分析程序到文档，然后让文档开始分析。XML被递归分析，直到到达文档的结尾。当分析调用退出时，整个文档被装入内存，这时就可以对XML进行操作了。
1.Element root = doc.getRootElement();
2.int child_count = root.getChildCount();
3....
4.for (int i = 0; i ＜ child_count ; i++ ) {
5....
6. Element kid = root.getElement(i);
7.
8. if (!kid.getName().equals("abc")) {
9. continue;
10. }
＜abc＞元素是根元素的直接子元素，可以遍历根元素的子元素，寻找abc标记，如果子元素不是一个abc 标记，则返回。
1.int address_item_count = kid.getChildCount();
2.
3. for (int j = 0; j ＜ abc_item_count ; j++) {
4....
如果找到了abc子元素，开始遍历它的子元素，并把这些子元素的内容打印出来。
通过KXML对XML的处理，可以进一步实现对SOAP数据的处理，实现J2ME平台对SOAP协议的支持。
J2ME Web Services规范（JSR172）的制订给J2ME平台增加两大功能：一是使其能够远程访问基于SOAP/XML的Web Services；二是使其具有解析XML数据的能力。目前JSR172的标准已经制定完成，为了实现这两大功能，JSR172新定义了提供相应功能的两个可选包。这两个包占用内存非常少，XML-RPC部分大概需要25-30KB的空间，而XML解析器则需要35KB左右。
规范只对JAX-RPC的模型提供支持，也就是说仅支持同步的访问方式，使用J2ME客户端可以向服务器发送RPC请求和获得RPC响应。在JSR 172中实现的是SAX模式的解析器。能够解析XML之前首先需要创建SAXParser的实例，
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
接下来要获得XML文件的输入流，并把它作为其中一个参数传递给saxParser的parse方法，
InputStream is = this.getClass().getResourceAsStream("phone.xml");
SaxParser.parse(is，new BasicHandler(this));
DefaultHandler是SAX2默认的事件处理器基类，用于处理XML解析事件的方法如下：
startDocument()
startElement(java.lang.String uri，
java.lang.String localName， java.lang.String qName， Attributes attributes)
characters(char[] ch， int start， int length)
endElement(java.lang.String uri，
java.lang.String localName， java.lang.String qName)
endDocument()
默认情况下，DefaultHandler的上述方法什么也不做，因此必须自己扩展DefaultHandler并且覆盖上述的方法。程序中提供了一个BasicHandler用来处理xml文件。class BasicHandler extends DefaultHandler在BasicHandler类中有两个成员变量
private Vector phones = new Vector();
private Stack tagStack = new Stack();
phones用来存储我们已经解析出来的Phone对象，tagStack则用来存放我们解析到的元素名称，比如sonyericsson，phone，name，colour等。在文档解释结束后，也就是在endDocument()方法内我们把解析的结果显示在手机屏幕上，BasicHandler的几个重要方法如下：
public void startDocument() throws SAXException {}
public void startElement(String uri， String localName， String qName， Attributes attributes)
throws SAXException {
System.out.println("the qName is "+qName);
if(qName.equals("phone")) {
Phone phone = new Phone();
phones.addElement(phone);
}
tagStack.push(qName);
System.out.println("the tag stack's length is "+tagStack.size());
}
public void endElement(String uri， String localName， String qName) throws SAXException {
System.out.println("the end qName is "+qName);
tagStack.pop();
}
5 结束语
通过扩充J2ME平台对XML数据的处理，完成了J2ME平台对SOAP协议的支持。通过SOAP协议能够使得基于J2ME平台的嵌入式设备无缝的连接到企业现有的应用系统，解决了嵌入式设备数据来源不足的问题，扩展了嵌入式系统的应用范围。本文从处理XML数据出发，深入探讨了在J2ME平台中实现SOAP客户端的各种技术，对于企业应用系统的集成具有一定的推广价值。
参考文献
[1] Yuan，Michael Juntao. Enterprise J2ME. Pearson Education 2003
[2] 胡虚怀，杨志，李焕. J2ME移动设备程序设计. 清华大学出版社 2005
篇2
关键词：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消息返回给客户，完成应用程序的远程调用。
篇3
电子商务应用系统的安全要素通常包括数据的机密性、完整性、用户授权、身份的可鉴别性和不可否认性等方面。将基于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
关键词：Web服务 性能 优化
简单易用是Web服务的一个重要设计目标。简单易用性是通过对用户屏蔽复杂性和更高层的抽象来达到的，这需要更多的计算资源开销。因此，Web服务与传统的分布式计算技术（如微软的DOOM、Sun的Java RMI、CORBA）相比，性能具有一定的差距，最为突出的问题是Web服务的响应时间和吞吐率等。在多数应用中Web服务不会产生性能瓶颈，但是，在某些高负载、高吞吐率等对性能有较高要求的应用中，Web服务的性能成为决定其是否能进一步得到更加广泛应用的关键因素之一。Web服务日益成为异构网络环境下的主流分布式计算模式。基于XM L的数据传输格式在给Web服务带来跨平台性、松散耦合和良好的互操作性等优点的同时，也在一定程度上影响了其性能。本文在分析Web服务性能的基础之上，针对Web服务的额外性能开销问题，以NET平台为例，提出了使用缓存技术、SOAP压缩技术和异步Web技术等策略实现Web服务性能的优化。
一、Web服务的应用模式
Web服务的应用模式是一种基于SOAP、WS-DL、UDDI的面向服务的体系结构（Service Oriented Architecture，SOA）。Web服务所提供的最简单级别的应用是使用SOAP协议和HTTP协议使Internet上的客户端程序能够使用Web服务。具体来说，一个客户端请求是使用HTTP协议上的SOAP协议，然后经由Internet进行传递的Web服务发送响应给客户端应用程序，该响应是作为HTTP上的一个SOAP消息被发送的。客户端请求和Web服务响应的SOAP消息主要是基于XM L格式的。由于Web服务主要使用HTTP和SOAP进行通信，并且主要的供应商都支持标准协议SOAP，避免了在CORBA、DOOM及其他协议之间进行转换，从而使Web服务具有跨平台性、松散藕合和良好的互操作性。
二、影响Web服务性能的主要技术因素
通过针对Web服务基本架构的分析，可知Web服务的运行机制是建立在基于XM L的统一消息交换机制的基础之上，影响Web服务请求响应时间的主要因素是XM L消息的处理机制。因此，服务传输时间（即请求从客户端到达服务端和响应从服务端到达客户端所用的时间）和XM L消息处理时间（即XM L解析、服务调用以及最后的应答消息编码所花的时间）是影响Web服务性能的主要因素。
第一，服务传输。在Web服务调用过程中，传输协议会对服务传输的性能造成重要的影响。SOAP协议大部分应用是与HTTP协议进行绑定的。HTTP采用一个无状态的数据转发机制，它只能处理单一方式的请求或应答，这既是优点也是缺点。一方面，由于缺少状态使得HTTP累赘少，系统运行效率高，服务器应答快；另一方面，由于没有状态，协议对事务处理没有记忆能力，若后续事务处理需要有关前面处理的信息，那么这些信息必须在协议外面保存。另外，缺少状态意味着所需的前面信息必须重现，导致每次连接需要传送较多的信息，造成了它的性能消耗。随着电子商务的飞速发展，运行在网络上的用户和数据量日益增加，在有限带宽和网络资源的条件下，HTTP显然是制约Web服务性能的一个瓶颈。
第二，由于SOAP自身的特点导致在所传输数据的封装编码、解码方面存在严重的性能问题，这些问题主要表现在将浮点数转化为相应的ASCII表示、将ASCII表示转化为相应的数据及从缓存中读写转化后的数据，这些过程占据了整个通讯过程大概90%的时间。SOAP是一个基于XM L文本格式的协议，XM L虽然可读性比较好，但是比一进制实现的协议需要更多的带宽、更大存储能力和更长的处理时间，在很大程度上降低了Web服务的性能。此外，缺乏缓存或低效率缓存、低效的状态处理错误的使用线程、繁琐的调用等问题都会加剧Web服务性能问题的严重性。
三、Web服务的性能优化
第一，缓存技术。缓存（Cache）在计算机科学领域指的是一些数据副本的集合。当原始数据访问速度较慢时，可以通过使用在高速存储区域中保存原始数据的常用数据副本，从而提升访问速度。常见的硬盘缓存、CPU缓存、网页缓存等都是缓存概念的应用。由数据库驱动的Web应用程序中，那些经常被调用的并且对实时性要求不是很高的服务，使用缓存技术是一个十分有效的提高性能的方法。.NET平台的Web服务充分考虑了对Cache的击求，只要简单地设定即可启用Cache。对Web服务的调用也启用Cache的机制，可以减少服务器端不必要的开销。利用缓存技术，必须面对数据过期的问题（这也是实时系统比较少用的原因）。最典型的情况是，如果将数据库表中的数据内容缓存到服务器内存中，当数据库表中的记录发生更改时，Web应用程序则很可能显示过期的、不准确的数据。这是不可接受的。解决这个问题的关键是在删除或修改时根据Cache key来强制删除该Cache项。综上，对于一些经常被调用的并且对实时性要求不是很高的Web方法，我们可以应用这一属性，设置一个合适的缓存时间用以减少调用的次数，从而减少服务器端的开销。在一些不常调用，或者调用的参数是变换的Web方法，或者是实时性要求高的Web方法，可以减少Cache Duration属性的使用，这将会减少服务器Cache的开销。
第二，SOAP压缩技术。由于Web服务主要使用SOAP协议作为标准通讯协议，因此，SOAP消息报文的解析、验证、编码安全处理等对Web服务性能有最直接的影响。SOAP是基于XM L编码的，而XM L文档其实就是文本文档。因此，SOAP消息也能够看作一个文本流。假如采用压缩文本流的方法将会大大提高网络传输的效率（减少传输的数据量，加速SOAP消息传输），从而也达到对Web服务性能的优化。当网络传输的内容是文本的时候，通过压缩，它的尺寸能够减少70%左右（不同的压缩技术，压缩比例不同）。这就意味着在客户端和服务器之间带宽的需求也能够减少类似的白分比。所以压缩是提高传输效率的最有效的方法，当然为了压缩和解压缩，服务端和客户端会增加自身CPU的负载。SOAP消息主要包括客户端发出的SOAP请求消息和服务器端发出的SOAP响应消息。通常情况下，服务器端的SOAP响应消息要比客户端的请求消息大。因此，压缩服务器端的SOAP响应消息对于性能的优化的效果较为明显。采用压缩SOAP方式，特别是压缩SOAP响应消息的方式，降低了网络上的数据传输量，可以达到优化Web服务的性能，但同时也会带来一个负面效果，如消息的压缩和解压缩需要额外的时间开销，也会增加CPU的负载。
第三，异步Web技术。异步和同步的最主要的区分，简单地讲，就是异步没有马上返回结果，而同步则是马上返回结果。常规的客户端调用，当调用Web服务时，由于服务器处理速度、网络传输速度等各种原因会使一个Web服务从请求开始到获得响应结果之间等待一段时间，这时候线程会处于阻塞状态，程序会等待请求结果导致客户端无法进行其他的动作或处理。在.NET环境中，可以通过，asynchronism实现异步调用Web服务。即通过创建一个新的线程来执行新的Web服务请求，这对程序的主线程不会产生影响。
常规的服务器端同步Web方法：当从同步Web方法返回时，将发送对该方法的响应。如果需要较长的时间来完成清求，则处理请求的线程会一直被占用，直到方法调用结束。服务器端为响应多个请求，可能会建立多个线程，这样可能会很快耗光系统资源。为了解决这个问题，就要考虑使用线程池技术。.NET运行时提供了线程池的实现。对于异步方法调用由系统将方法提交给线程池，由线程池中的线程执行。线程完成任务后，线程不会自行销毁，而是以挂起状态返回线程池。应用程序每次向线程池发出请求，线程池会将挂起的线程激活并执行任务，而不会创建新线程。当然，在一个复杂的应用程序中，用户也许会同时请求多个Web服务，这时就得创建并控制多个线程。
综上，客户端的异步调用实现了请求和接收异步通信，解决了客户端线程阻塞的问题。既满足了调用多个Web服务的要求，又减少了响应时间。而服务器端的线程池技术也很好地解决了服务器端同步Web方法的问题。当然，多线程的控制虽然可以实现很好的应用程序，但难度是比较大的，而且很容易引起异常。
四、结束语
随着电了商务、电了政务的迅速崛起，基于Web服务的应用模式己经成为主流架构，同时这也对Web服务的服务质量（QoS，如服务的可用性、功效性和性能等）提出了更高的要求。本文在对Web服务的性能进行分析的基础上，针对Web服务的额外性能开销问题，以.NET平台为例，讨论了使用缓存技术、SOAP压缩技术和异步Web技术等策略在Web服务性能优化中的应用。Web服务性能优化本身就是一个复杂的议题。除了采用上述几种优化的方法，还必须多方面地考虑优化的问题，从系统设计到部署实现都需要考虑如何优化改善其性能。如在Web服务接口设计时要充分考虑服务的粒度，配套开发工具（如、数据库优化）的优化。
（作者单位：湖北工业大学计算机学院）
【参考文献】
1、邓海生,李军怀,刘红英.基于的Web服务性能优化[J].计算机技术与发展,2007(10).
篇5
电力经济活动分析系统是利用基于XML的WebService技术,集成企业的现有系统。通过利用Web服务,获取电力企业的财务系统和生产系统中的已有数据进行分析,完成情况分析、生产分析、经营分析和综合效益评价等项功能,从而为发电公司的生产经营决策提供智力支持。通过提供Web服务,支持用户其他系统使用电力经济活动分析系统的分析结果和数据,例如,为企业网站提供发电量、营业额等统计信息。Web服务在电力经济活动分析软件中起到关键性的作用,生产系统和财务系统所提供的Web服务,涉及生产、财务系统里的重要数据,关系到企业的安全生产和运营。所以如何在电力经济活动分析软件中构建安全的Web服务,使实施该项目需要重点考虑的问题。下面将从Web服务和其安全规范出发,来介绍在电力经济活动分析系统项目实施中,实现安全的Web服务。
1.Web服务和其安全性规范
(1)什么是Web服务
Web服务是一种完全建立在现有互联网标准之上、松散耦合的、跨语言和平台的应用程序之间通信的标准方法。XMLWebService体系结构的主要优点之一是:允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。虽然Web服务一经出现,便为各厂商接受和支持,但并没有一个关于Web服务的统一的定义。广泛接受的一个XMLWebService定义是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册。要实现一个完整的Web服务体系需要一系列的协议规范来支撑,如图1所示:其中,第1、2层是已经定义好的并且被广泛使用的传输层和网络层的标准:IP、IITTP、SMTP等。而第3、4、5层是目前开发的Web服务的相关标准协议。SOAP(SimpleObjectAc-cessProtocol)是一个协议规范,定义了传递XML-encoded的数据时的统一方式,它还定义了使用HTTP作为底层通信协议时执行远程调用(RPC)的方法。UDDI为客户提供了动态查找其它Web服务的机制。WSDL为服务提供了描述构建在不同协议或编码方式之上的Web服务请求基本格式的方法。
(2)Web服务的调用过程
利用Web服务可以建立面向服务的集成系统。即不用改变现有的各种应用,也不关心它们技术的不同(比如是Java,还是.NET),利用Web服务的消息驱动机制,让它们协同工作和交互。Web服务体系最基础的支柱是XML消息传递。XM消息传递的标准是SOAP,服务的请求者通过在传输层协议之上绑定SOAP消息来发送Web服务的请求。假设SOAP绑定在http之上,那么它就会利用http的请求/响应消息模型,将SOAP请求放在http请求里面,服务的提供者将SOAP响应的结果放在http响应里面返回给Web服务的请求着。
(3)Web-Security规范
Web的基础是简单对象访问协议(SOAP),它是在分布式环境中交换信息的简单的XML文本协议,本身不涉及安全范畴。随着各种基于Web服务应用的发展,如电子商务、网上银行等等,引出了人们对Web服务安全性的关注。WS-Security规范是构建安全的Web服务应用的基础。该规范主要提供了三种机制:安全性令牌传输、消息完整性和消息机密性。通过提供安全性令牌来实现Web服务的授权访问,安全性令牌包括普通的用户名/密码令牌以及X.509等证书令牌。后两者是通过引入XML数字签名和XML加密协议实现的。这些机制可以单独使用,也可以组合使用,以实现不同强度的安全性。
2.Web服务关键安全手段
(1)加密技术
任何Web服务考虑其安全性,首先需要的一项重要安全技术,就是在敏感数据通过开放网络传输时提供保护。加密技术可以加密消息,从而保护敏感数据免遭暴露。加密技术还能保障消息的完整性。加密技术分为两种:①秘密密钥加密。又称为“对称密钥加密”,通信双方使用同一个加密密钥来加密和解密消息。②公钥加密。使用两种不同但是在数学上相关的密钥。使用公钥加密技术时,用公钥来加密数据,私钥来解密数据,也成为“不对称加密”。公钥密码技术也可以用来创建以用户的私钥为基础的不可伪造的数字签名。正确标示公钥是公钥证书的推动因素。
(2)验证模型
Web服务安全性首先在于对用户合法性的验证,也是Web服务授权和访问控制的基础。Web安全模型并没有指明任何验证协议。用户可采用任何认为合适的方法来验证用户。就目前的技术而言,验证主要可分为三类:①直接验证客户端在使用Web服务时,直接提交凭据,例如用户名和密码,用作验证。②X.509证书验证用户身份时,另一个选择足发送X.509证书。X.509证书确切地告诉web服务提供者用户的身份。您可以使用PKI将此证书映射到应用程序中的现有用户。③Kerberos验证Kerberos验证包含客户端向服务证明身份以及服务向客户端证明身份的机制。要使用Kerberos,用户需要提供一组凭据(例如用户名/密码或X.509证书)。如果所有内容检验合格,安全系统将授予用户一个TGT(TicketGrantingTicket)。TGT是一个隐藏的数据,用户无法读取,但必须提供它才能访问其他资源。
(3)保护连接安全
保护XMLWebService安全的最简单的一种方法就是确保XMLWebService客户端与服务器之间的连接安全。根据网络的范围和交互操作的活动配置文件,可以通过多种技术来达到这一目的。最流行也最广泛使用的三种技术为:基于防火墙的规则、安全套接字层(SSL)和虚拟专用网络(VPN)。
3.电力经济活动分析系统Web服务安全功能的分析
(1)系统介绍
在给某发电企业实施的电力经济活动分析系统中,该系统使用已有生产系统、财务系统的Web服务获取基础数据,为用户提供生产指标统计分析、财务指标统计分析、成本分析、利润分析、历史比较分析等功能。用户即可通过浏览器、也可通过Web服务开发其它的用户应用来访问这些功能。该系统功能结构如图2所示:对于使用Internet浏览器访问的用户,电力经济活动分析软件通过WebForm网页作为用户接口。用户其他应用程序获取电力经济活动分析系统的各种分析数据,电力经济活动分析系统获取生产系统、财务系统的基础数据也都是通过访问生产系统、财务系统的Web服务实现的。
(2)消息流分析
电力经济活动分析、生产系统、财务系统所有Web服务都是基于XML,提供WSDL(WebServiceDescriptionLanguage)定义的接口。用户应用使用这些Web服务是通过建立在HTTP协议之上的SOAP(SimpleObjectAccessProtocol)消息来访问。图3为电力经济活动分析软件中消息流图。①用户应用通过HTTPS向电力经济活动分析软件发送一个SOAP请求。这个SOAP请求的header元素里包含用户的用户名和密码。②电力经济活动分析软件成为了Web服务的请求方,发送SOAP消息给生产系统或财务系统。SOAP消息的header元素包含有自定义的二进制令牌(一个X.509证书)。使用了X.509证书的公钥来加密和签名SOAP消息。③生产系统(财务系统)给电力经济活动分析软件返回消息。SOAP的消息体使用了X.509证书的公钥加密。④电力经济活动分析软件返回用户的消息。在用户和电力经济活动分析软件之间的SOAP消息交换,考虑到用户都为企业内员工,通过局域网访问应用,并结合响应速度效率的因素,并没有使用签名和加密技术。我们对传输层使用SSL方式,来保证消息的一致性和完整性。利用SOAP消息的header元素包含用户名和密码来对用户验证。由于生产系统、财务系统的安全对企业生产经营至关重要,它们采用更严格的安全策略来对Web服务验证、保护。这两个系统的Web服务都采用了X.509证书验证,数字签名和加密技术保证Web服务的安全性。我们通过在生产系统和财务系统Web服务器的配置文件中,设置电力经济活动分析软件的证书和公钥,便可实现电力经济活动分析系统对生产和财务两个系统的Web服务安全访问。
篇6
关键词：SOA；Web服务
中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)23-958-02
Research about Web Service Based on SOA
PENG Bo1,2
(1.School of Computer and Information,Hefei University of Technology, Hefei 230009, China; 2.Anhui Medical University,Hefei230032, China)
Abstract:First gives the concept of SOA as a whole. Then analyses the architecture of WebService,
at last discuss the development methods of WebService.
Key words: SOA; WebService
1 SOA概述
1.1 SOA的基本概念
SOA(Service Oriented Architecture)是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模－开发－整合－部署－运行－管理。SOA是分布式软件系统构造方法和环境的新发展阶段。
其基本要素是：
1）松散耦合：包括服务之间的松散耦合、接口和实现之间的松散耦合、业务组件和传输协议之间的松散耦合。
2）粗粒度：SOA服务接口应比面向对象编程的API要大一些，更接近用户的实际操作。
3）位置和传输协议透明：位置透明是指不论服务组件的实际位置URL如何变化，客户的调用程序的URL都不需改变。传输协议的透明，就是指不管服务组件的传输协议如何变化，客户端的调用程序的传输协议都不需要改变。
SOA的基本思想是面向服务，服务的本质是业务和技术的分离，它超越于一切具体的技术，又包含一切具体的技术。SOA三个基本要素能消除目前IT系统集成的障碍，从而达到SOA的目标：敏捷的，不受限制的业务集成。
1.2 SOA 和 Web Service 的根本区别
SOA是在 WebService 的基础上发展起来的；而 WebServices 实现了松散耦合的服务和粗粒度的服务。虽然两者都提供服务、服务接口都是基于开发的、接口与服务的具体实现都是分离的，但 Web Service 服务接口需要绑定具体实现服务的服务组件来实现服务，它对具体的服务实现完成了封装，如图1所示，实现了服务的透明化，客户端不需知道服务是如何实现的，但客户端调用 Web Service 组件时，还需要知道Web Service 的具置和传输协议，这将造成一定的不灵活性，因此它只是实现了一定程度上的抽象。
而SOA架构平台只和服务接口进行绑定，对服务接口实现了封装，如图2所示，实现了服务接口的透明化，服务位置的透明化，传输协议的透明化。SOA 本身也不知道服务具体是如何实现的。当客户端通过SOA调用服务时，不需要知道真正的服务提供者是谁，具体的服务位置在哪里和具体的传输协议是什么。因此SOA实现了最高程度的抽象化，为实现具有最高灵活性的服务建立了架构基础。
2Web Service体系结构
Web 服务是一种部署在 Web 上的对象或组件，Web 服务是基于 Web 服务提供者、Web 服务请求者、Web 服务中介者三个角色和、发现、绑定三个动作构建的。
服务提供者就是 Web 服务的拥有者，它向其他服务和用户提供自己已有的功能；服务请求者就是Web服务功能的使用者，它利用 SOAP 消息向 Web 服务提供者发送请求以获得服务；Web 服务中介者的作用是把一个 Web 服务请求者与合适的服务者联系在一起，充当管理者角色，一般是 UDDI。在这些角色之间使用了三种操作：、发现、绑定。
1）服务提供者(ServiceProvider)可以自己的服务，并对请求使用服务进行响应；
2）服务注册中心(Service Registry)用于注册已经的ServiceProvider，对其进行分类，并提供搜索服务；
3）服务请求者(ServiceRequester)利用服务注册中心查找所需服务，然后使用该服务。
所谓的WebService就是定义了一套标准的调用过程：
1）服务器端首先用一套标准的方法向外界描述它所提供的服务内容，这属于 WSDL；
2）客户端需要以一种标准的协议来调用此服务，这属于 SOAP (这也是WebService不同与其他组件如EJB的根本之处)
3）服务提供者将服务内容放在一个公共的网址让大家查询，这属于 UDDI。
3Web Service 三个组成部分
1）WSDL(WebServiceDescriptionLanguage)是一种基于XML格式的关于Web服务的描述语言，其主要目的在于提供者将自已的Web服务相关内容，如服务传输方式、服务方法接口、接口参数、服务路径等，生成相应的文档，给使用者。使用者通过这个WSDL文档，创建相应的 SOAP 请求，通过 HTTP 传递给提供者；Web 服务在完成服务请求后，将 SOAP 返回(response)消息传回请求者，服务请求者再根据 WSDL 文档将 SOAP 返回消息解析成自已能理解的内容。
WSDL 的目的就是告诉外界我有什么样的服务，这类似Java的Interface。
2）SOAP(SimpleObjectApplicationPropotol)是WebService的标准通信协议，是一种标准化的传输消息的XML消息格式，以便大家都用同一种格式来讲话，大家可以相互完全理解。SOAP请求(request)消息将客户端的服务请求发给服务器，例如：需要调用什么样的服务接口，以及接口参数值等。SOAP答复(respone)消息是从服务器返回给客户端的消息，如服务接口实现后的结果返回值或调用服务时的错误信息等。
3）UDDI(Universal Description Discovery and Integeration)是一种创建注册表服务的规范，以便大家将自已的 WebService 进行注册供使用者查找。当服务提供者想将自己的 WebService 注册到相应的UDDI商用注册网站时，如IBM的/。服务提供者可以 SOAP 消息格式将自已的服务到这些网站。由于WSDL文件已给定了WebService 的地址URL，外部可直接通过WSDL 提供的 URL 进行相应的 WebService 调用。所以 UDDI 并不是一个必需的WebService 组件，服务方完全可以不进行 UDDI 注册。
4Web服务的开发方式
完整的Web服务开发包括3个阶段：开发、部署、。
1）开发阶段：此阶段包括逻辑模块(Java Bean或EJB)的开发与部署，WSDL 定义文件的设计或生成。
2）部署阶段：指定 Web 服务的传输协议(绑定)，明确服务的终端地址，创建 Web 的附属文件，以平台可识别的方式将 Web 服务注册到相应服务描述部署文件。
3）阶段：将 Web 服务的接口和调用地址公开给客户端调用，常用的方式为提供WDSL链接，也可选择 UDDI。
在开发阶段，有两种可以实施的方案：自上而下(top-down)方式，即先设计WSDL，即服务接口定义，然后生成服务逻辑代码。自底向上(bottom-up)方式，即先完成业务逻辑代码的开发或使用已经存在的逻辑代码，再根据代码暴露出服务的接口WSDL,包装Web服务。这两种方式都可以实施，现阶段，自底向上的模式更常见，大多数的SOA应用都是基于当前的应用创建Web服务。
参考文献：
[1] IBM Co.Service-oriented modeling and architecture[EB/OL].[2008-04-16]./developerworks/webservices/library/ws-soa-design1/.
篇7
本文对基于移动互联网的WebService开发设计中的关键技术进行了深入的研究，其中包括WebService功能介绍与特点分析、支持手机调用的WebService服务端和客户端开发设计，同时针对目前较为流行的两大手机操作系统Andriod系统和IOS系统分别给出了客户端设计思路，提出了一整套可以支持智能手机、平板电脑友好、高效访问WebService的技术方法。实验表明，本文提出的关键技术解决方案具有较好的实际操作性，能够支持大部分基于WebService的移动网络服务，对各类移动终端系统具有良好的兼容性。
【关键词】移动互联网 WebService 网络服务端 Andriod系统 IOS系统
1 引言
随着社会进程的加快和现代化水平的提高，程序间甚至部门间的应用与数据交换需求日益显得迫切。而WebService通过web的方式向外界提供接口库API，使得外部程序和应用能够通过标准化的方法和结构进行友好调用，为跨平台的数据交换和内部多业务的集成提供了通用机制。
与此同时，伴随移动互联网和智能手机大潮的来袭，移动应用的概念应运而生。移动应用对于解决业务处理的时效性，降低管理成本，方便用户使用等各方面都具备突出优势，能够随时、随地、随手获取各类数据和服务，及时获取重要的信息并处理工作。
因此，研究如何建立一套可行的基于移动互联网的WebService开发设计方案，就有其现实意义。根据这一思想，本文从WebService特性分析、支持移动应用的服务端设计、Android客户端设计和IOS客户端设计等多个角度进行深入研究，着重解决WebService支持移动互联网平台中的关键问题。
2 WebService技术
WebService是的核心功能是实现程序在不同编程语言和运行平台下轻松交换数据。WebService定位成接口的形式，基于XML消息封装操作、执行指令和传输数据。WebService体系中有规范和相对严格的技术栈，包括信息传输和服务的标示、部署、实现等。以下是WebService的关键技术：
2.1 XML和HTTP
WebService以HTTP协议为基础，在广域网上实现信息的传输和对防火墙设备的穿透；而XML作为网络数据传输的新标准，提供了可供扩展的标记功能。
简单对象访问协议SOAP （Simple Object Access Protocol）能够在离散环境或者分布式系统中远程执行命令同时完成数据交互，它以XML协议为基础。SOAP规范由四部分组成：
（1）SOAP封装体（envelop）：包含数据的收发对象和处理流程。
（2）SOAP数据编码（encoding rules）：通过数据类型的描述来驱动应用。
（3）SOAP表达（RPC representation）：约定一种机制来执行远程调用并返回应答。
（4）SOAP底层绑定（binding），通过底层的协议来约束交换信息的类型。
2.2 Web服务描述语言WSDL
Web服务描述语言应用XML结构来描述WebService的标准，成为了Web服务的接口定义语言，通过WSDL能够描述WebService的三个基本属性：
（1）服务提供的功能――提供哪些接口和操作形式
（2）服务的访问方式――通过哪种协议和哪类结构交换数据
（3）服务的调用地址――服务提供的具体URL信息
2.3 通用描述、发现和集成协议UDDI
通用描述、发现和集成协议UDDI既作为WebService的信息注册规范，同时也作为一种规范的编程接口。开发者能够通过UDDI将自己的WebService出去。同时，其他用户能够通过查询到特定服务的具体描述信息，通过动态绑定的方式连接该服务，从而进行远程查询和调用。
3 WebService服务端
WebService服务端的作用是提供一系列方法的集合（接口），供外部用户和应用程序进行方便的交互。例如需要从某个部门获取一些业务数据，服务提供者能够通过编写接口向用户提供一套方法，从而达到数据共享的目的，而不用提供数据库的使用权限。
开发WebService服务端流程如下：
（1）编写一个对外接口。
（2）完成该接口的实现类。
（3）通过命令产生服务信息，并完成服务接口的整体描述。
随着web容器的启动，由以上配置形成的WebService应用就能够为用户提供对应的服务。
3.1 基于手机客户端的WebService服务端开发
在计算机平台的java客户端中，普遍使用成熟的SOAP库（比如CXF、XFire和Axis2，）提供创建服务器端、客户端和网关SOAP操作的基本框架，但是对于效能较低的手机客户端使用却有很多问题。本文通过使用KSOAP类库编写webService服务端，可以支持手机客户端完成webService调用。另外，对于企业级应用，webService服务端也可以采用hibernate和spring框架进一步增加效能。
3.1.1 编写webservice代码
在代码中加入"@WebService"这个注释，将类方法封装成为一个webservice接口： @WebService
public interface CellClientService{
public String userLogin（@WebParam（name = "opPhone"） String opPhone， @WebParam（name = "loginPwd"） String loginPwd）；}
此过程中，手机端通过webservice参数中@WebParam（name = "***"）获取服务。
为了提高传输的质量和效率，将服务器端返回的请求数据的数据先使用pojo类包装，最后转换为一个XML对象。
3.1.2 WebService接口实现类
接口的实现类，要加上相应注解。下面是关键代码：
@WebService（endpointInterface = ".ws.CellClientService"）
public class CellClientServiceImpl implements CellClientService {
public String userLogin（String opPhone， String loginPwd） {
}}
3.1.3 WebService接口
设置接口配置清单中的address为该服务的的真实地址。在Tomcat下创建Web应用，将类为WebService，完成之后再访问http：//host：port/webservice/services，能够在列表中发现对应的服务。
3.1.4 测试的WebService接口
推荐使用soapUI软件，它能从配置文件中解析生成对应的客户端和服务端模拟，还具有负载等全程监控功能。
3.2 基于android平台的客户端开发
首先下载KSOAP包：ksoap2-android-assembly-2.5.5-jar-with-dependencies.jar包然后新建android项目，加入对该包的编译引用，然后按照如下步骤调用：
（1）生成SoapObject 对象，根据WSDL的说明设置webService的命名空间，同时设定对应调用方法。如：
SoapObject request=new Soap Object （serviceNameSpace， getCity）；
（2）设置调用方法参数request.add Property（"参数名称"，"参数值"）：
添加Web端Tomcat生成的接口地址与方法说明，手机确保能够通过WIFI等手段连接至服 务器端。
（1）配置SOAP的请求相关信息：Soap Serialization Envelope envelope=new Soap Serialization Envelope（VER11）；
（2）注册Envelope：（new MarshalBase 64（））.register（envelope）；
构建传输对象，并指定WSDL文档存在的URL：
AndroidHttpTransport transport=new AndroidHttpTransport（serviceURL）；
（1）调用WebService：transport.call（serviceNameSpace+getWeatherbyCityName， envelope）；
（2）解析返回数据：最后从应用功能出发完成数据交互的具体方法，以XML格式进行数据的交互传输。以天气预报为例，打开天气预报服务（WSDL）的地址可以看到可供调用的方法，参照函数说明获取城市列表：getSupportProvice，启动调用并返回xml文档，通过 listview来显示。运行结果如图1所示：
图1：android客户端演示
3.3 基于IOS的客户端开发
同样使用天气预报的wsdl：
http：//.cn/WebServices/WeatherWebService.asmx？wsdl
然后根据wsdl生成SOAP消息体：
（1）添加一个类扩展，如图2DDXMLElement+WSDL.h和DDXMLElement+WSDL.m。
在配置文件设置中，提供以下几个方法：（见图3）。
（2）SoapUtility 文件用来封装soap消息。SoapUtility调用DDXMLElement+WSDL来实现。
（3）完成Soap消息的封装准备，尝试调用服务。这里分两种调用方式：同步和异步。
if （isSync） {//同步方法
ResponseData *result= [soaprequest PostSync：postData]；
[self.result setText：result.Content]；}
else{//异步请求
[soaprequest PostAsync：postData Success：^（NSString *response） {
[self.result setText：response]；
} falure：^（NSError *response） {
[self.result setText：response.description]；}]；}
（4）解析XML。由于ios自带的类解析xml比较繁琐，本文使用的是GDataXML这个类库。先添加libxml2.dylib类库，然后对GDataXml进行配置
soap调用返回的数据经常放在：XXX中[6]，在webservice调用中可以直接提取出来一个xml，然后通过xml解析类进行解析：
1.读取XXX的内容。
2.遍历xml的所有内容返回数组。
至此，IOS客户端能够成功显示服务返回的数据。
参考文献
[1]蔡月茹，柳西玲等.Web Service基础教程[M].北京：清华大学出版社，2005，1（26）.
[2]Scott Seely.SOAP：Cross Platform Web Service Development Using XML [M]. PH PTR，2002.
[3]Eric Armstrong. Java Web Service教程[M]. 北京：高等教育出版社，2006 （12）.
[4] 马兴录.嵌入式软件开发-基于Web Service的云端应用软件开发[M].北京：化学工业出版社，2012.
[5]Gail Rahn Frederick， Rajesh Lal.智能手机Web标准开发实战[M].北京：清华大学出版社，25-38，2010.
[6]饶侠，张坚，赵莉萍.彻底研究Android/iOS跨平台Web [Z].上奇科技股份有限公司，88-95，2013.
作者简介
吕梁（1983-），男，浙江省衢州市人。硕士研究生学历。现为浙江省气象信息网络中心工程师，从事信息网络和办公自动化方面的研究。
胡永亮（1984-），男，浙江省温州市人。大学本科学历。现为浙江省气象信息网络中心工程师，从事信息网络和数据库方面的研究。
肖云（1961-），男，浙江省杭州市人。大学本科学历。现为浙江省气象信息网络中心高级工程师，从事信息网络和网络安全方面的研究。
篇8
关键词：Web Services 网络在线出版
中图分类号：TP311 文献标识码：A 文章编号：1007-9416（2013）04-0053-01
1 Web Services的体系架构及核心技术
Web Services是用来描述一系列操作的接口，通过XML消息传递，网络访问这些接口。即通过WSDL描述及SOAP访问，在商业注册中心（UDDI），使得开发人员和相关的应用程序可以搜索并定位该服务。主要包括三大角色和三个操作：服务提供者（Service provider），服务（Service broker）和服务请求者（Service requester）通过（publish）、查找（find） 和绑定（bind）三类操作来将三大角色关联起来。如（图1）所示。
目前Web services的核心技术包括：XML，SOAP，WSDL与UDDI。
XML可扩展性标记语言（Extensible Markup Language）：它是Web Services技术的基础，XML作为信息描述和交换的标准格式进行Web Services的调用、界面描述和Web Services的发现。
SOAP（Simple Object Access Protocol）简单对象访问协议：它是以XML编码，包含请求服务器的方法调用和返回客户端的数据。它基于XML的简单协议，实现各种交换结构化的信息和类型信息。
WSDL（Web Services Description Language）Web Services 描述语言：使用XML进行Web Services描述。可以将其看作一组服务访问点，客户端通过这些访问点对这些服务进行访问。
UDDI（Universal Description，Discovery and Integration）统一描述、发现和集成协议：是Web Services的服务注册规范，以便被需要该服务的用户发现和使用，可将UDDI视为Web服务的搜索引擎。
2 基于Web services网络在线出版系统服务的实现
网络在线出版系统中实现的最重要的服务就是实现系统的出版发行服务，关键技术是需要网络客户端与数据库进行大量的数据交互操作。随着Web Services技术的提出和不断发展，Web Services技术为网络在线出版系统的服务实现带来了巨大改变，在客户端和数据库之间建立一种Web Service中间层，形成三层次的结构，客户端通过SOAP协议只需要访问和调用Web Service服务，就可以与应用程序数据库连接起来。基于Web Service的网络在线出版系统，不仅增强了整个应用程序的安全性和可维护性，还简化了客户端的开发编程工作，缩短了开发周期，减少了客户端代码的冗余复杂度，方便了数据在客户端和数据库之间的数据交换。
因此，本系统是基于Web Service理念和技术而建立的多层次结构的网络在线出版系统，实现了客户端、中间层、服务器数据库的三层模型。客户端和中间层之间通过XML形式的SOAP消息的请求和响应实现通信：客户端通过网页交互界面向中间层的Web Service发送SOAP消息请求，中间层的Web Service接受请求后，调用相应的Web Service方法，连接访问服务器中的数据库，获得有关数据或者对数据做进一步处理，然后通过Web Service把数据或者处理后的结果，以XML的形式保存并且返回给客户端界面。其中，中间层的Web Service定义的方法只是提供相应的服务，它并不关心调用服务的用户是作者、读者、还是出版商，而是一个可重复使用的方法库。
该系统实现的主要功能包括出版服务和系统的发行服务。出版服务包括：数字资源作者（或资源提供者）注册、登录功能；向网络在线出版系统提交出版申请、按照作者ID号或申请单号查询、修改申请单的功能；在申请单被出版商审核通过后，资源作者实现资源上传，并查看、修改上传的资源的功能；资源上传后与出版商签订出版合同，并使用作者ID或者合同编号查询合同的功能。发行服务包括：读者用户的注册、登录功能；读者用户按照资源名称、价格、编号、出版时间等条件查询、浏览网络资源的功能；用户将资源放入购物车，并提交购买、订单查询的功能，网络电子资源在线下载的功能。
在整个系统服务中，客户端的网页提供了作者出版申请和资源上传的操作界面和读者浏览资源与购买、下载资源的操作界面，而实际功能的完成方法的是处于中间层的负责数据访问和处理的Web Service服务。客户端的网站给Web Service服务端发送相应的SOAP请求，然后调用Web Service中的相应服务方法，读取和处理后端数据库中数据，最后把处理结果以SOAP消息返回客户端界面，从而实现网络在线出版系统服务。
参考文献
篇9
目前，12306电子商务平台的建成投入，对铁路货运的发展起到了弥足轻重的作用，即简化了客户办理托运的过程，更省去了托运人营业厅办理业务的繁琐手续。尤其是“五定班列”等货运专列推出后，托运人可以选取自己的发货日期、运输车型等，对于“门到门”服务托运人来说更是可以做到“人在家中坐，收发天下货”。但随着12306的出现也为铁路货物的运输组织、营销带来了新的问题：（1）五定班列满载率低，有些甚至接近于零；（2）列车回空率高；（3）内部审查认定、最新班列计划更新慢。这“一低、一高、一慢”主要就是由于推出铁路货运商务平台后，铁路原有的信息服务系统无法满足平台快速的信息交互的需求造成的。表1列出了目前铁路货物主要的信息服务系统。由此可知，由于各信息系统是在不同时期分别由不同设计人员设计实现的，其开发工具和数据库系统各不相同，因此在信息整合上存在一定的难度。传统的IT公司在处理企业信息系统融合方面，先后经历了点到点的集成、第1代企业应用集成技术（公共对象请求体系结构/分布式组件对象模型、面向消息的中间件等技术）和基于业务流程管理/业务流程改进的第2代企业应用集成技术[1]。然而，对于铁路运输这样一个信息传输量大、遗留信息系统多、后期新建或改建信息系统任务重的企业来说显然无法满足。基于SOA架构的信息服务系统，以其独特的松耦合结构可以满足铁路货运系统的需求。
2“门到门”电子商务信息服务系统分析
目前，铁路的信息系统主要存在的问题有：（1）部分信息系统“孤岛”化，严重影响了信息的畅通性，更造成了大量数据的重复输入。（2）信息流转速度缓慢，无法为铁路的调度指挥、组织等决策提供最新的数据支持，造成了决策的滞后性。（3）信息接口“死板化”，外部预留接口少。如铁水联运，需要铁路总公司商务平台与港口的商务平台拥有同步或异步的通信。“门到门”服务的实现需要信息流通道畅通、数据更新及时，这就需要一个统一的“平台”整合来自12306电子商务平台、内部运输管理与运力保障等众多信息服务系统，形成一个可在各原有模块间跨应用、跨开发语言、跨数据格式的拥有推拉结合功能的信息中间通道。图1列出了铁路内部实现“门到门”运输时的相关信息服务系统，在提供门到门服务期间这些系统各司其职又要通力合作。其中，货运服务系统主要负责“门到门”服务客户关系管理、对外信息及外部信息的汇总；运输组织主要负责在货物承运的车底安排、运行计划安排、装卸表1主要铁路货物服务系统系统名称开发工具数据库系统列车调度指挥系统TDCSVCOracle运输调度管理系统TDMSC、JavaOracle货物运输管理系统FTMSC、VC、JavaDB2，Oracle，SQLServer集装箱运输管理信息系统C、C++、VB、VC、JavaOracle货运营销辅助决策系统FMDSC、DelphiOracle办公信息系统OMISASP、.netOracle、Access车、货物短程集卡拉运等；12306电子商务平台则是一个网络信息平台，托运人通过它获取各个路局子公司的货运安排情况、预定车底，平台收集托运人车底预定情况上报后对批复结果进行回复；货运保障是铁路内部的后勤保障系统，负责承运所需的基础条件（电力、机车等）的保障。要保障“门到门”服务的实施需要综合各系统的数据，如行车组织策划系统需要结合货运服务系统中的客户季度货运需求及货运保障系统中的空闲车底状况等制定月计划与日计划；12306平台要根据日计划与月计划情况，计划班列情况。要真正实现“门到门”，需要以12306为交易平台，提供方便快捷的网络服务；以车辆为中心构建业务管理系统，精确掌握车辆信息，调配运力资源；以客户为中心构建货运管理系统，提供更加人性化的货运服务产品；结合预防为主的信息安全系统，保障铁路信息高安全级别的需求及网络电子交易的安全[2]。面向服务架构（SOA）运用开放的标准，把企业的业务功能包装成标准的服务，通过透明的、与实现无关的接口来定义，服务被松散绑定，并且可以通过强调位置透明性和互操作性的通信协议进行调用[3]。SOA没有包括特定的协议和调用服务的格式，可以应用于各种不同领域的数据整合及信息共享[4]。
3基于SOA的信息服务系统设计
企业应用集成经历了从最初的点到点连接到基于消息的中间件再到基于SOA和ESB的发展历程[5]。SOA架构在国内发展还处于起步阶段，但在国外已成为企业IT整合的首选，也已有很多的成熟的产品，如Microsoft的Indigo平台、IBM的企业服务总线（ESB，EnterpriseServicesBus）平台、SUN的“SOAPath”（SOA路径）服务导向架构。综合考虑各种SOA特点与使用场景，本文采用的是IBM的ESB平台。在SOA架构中将各系统功能封装为可重用的服务，并在企业总线上进行注册；当服务请求者需要调用服务时，总线侦听请求信息，解释并翻译为服务提供者的信息格式与数据结构，路由请求信息；服务提供者完成其提供的服务后，总线回调服务结果，解释并翻译为服务请求者的信息格式与数据结构，路由信息至原服务请求者，这样一个完整的服务调用才算完成。图2所示是一种典型的服务体系结构图。在新的“门到门”信息服务系统中，不需对原遗留系统做过多的改变，这些系统依然作为“门到门”信息服务系统的底层服务系统，负责底层的信息采集和现场的管理；12306电子商务平台基本不需要做改变，进行原先的信息与结果回复操作，所不同的只是在SOA架构下，随着信息交互效率的提高、速度的增加，可以提供给托运人更多更人性化的服务，货物位置信息、预确报等信息更新也更加快捷。“门到门”信息服务系统以铁路原有运输服务系统为基础，利用分布式结构组合已有系统的数据库和应用系统，作为SOA架构的底层信息系统。运用服务描述语言（WSDL，WebServicesDescriptionLanguage）将数据应用层的系统（铁路内部原有系统）功能封装为服务，并在通用描述发现和集成（UDDI，UniversalDescriptionDiscoveryandIntegration）注册表中进行注册。此外，在预留系统的处理上，应注意系统划分为服务时的粒度，划分的粒度过粗会影响服务调用的灵活性，粒度过细则会增加后期服务封装与调用时的任务量。服务层管理所有在注册表里注册过的服务，对相关的服务进行组合、删除或合并等操作。此外，服务层中的ESB企业总线还负责当表现层调用应用层的功能模块时，不同系统或应用程序之间的协议转换、格式变换、数据传输及智能路由等功能；数据应用层不同服务之间的通信、数据应用层向应用层信息也由企业总线完成。应用层划分的一些相对独立的功能块是服务层对底层服务进行封装后，在UDDI中心注册的服务接口，这些接口可以供表现层的平台调用，也方便服务之间的彼此调用。12306平台仍作为SOA架构下的表现层，其本身也可理解为一种特殊服务，负责信息，接收应用层的预确报等信息并显示，同时也是托运人查询信息时与表现层的接口，提供同步与异步的通信查询与反馈。在服务层企业总线的功能实现上，国内外有很多成熟的基于XML的技术，对于我国这样在铁路内部以XML为消息传输语言的信息系统尤其适合。比如进行协议转换时，运用名为桥接器的通道适配器将简单对象访问协议（SOAP，SimpleObjectAccessProtocal）消息连接；数据格式转换方面可选择XSLT语言，将不同格式的服务请求方的数据转换为XML语言，再翻译为注册表中对应的服务提供者的数据格式；智能路由方面目前运用较多的是基于地址的WS-Routing（无状态协议）和基于内容的WS-Notification（有关Web服务通知的规范）；此外，还可利用WS-BPEL（标准流程定义语言）对一些常用的造作流程或数据流程进行定义[8]；至于安全方面，可选择WS-Security规范，在SOAP的扩展报头写入例如数字签名的信息，再利用加密技术以HTTP协议传输。下文是一个简单的在服务调用时，在消息源（即消息的核心内容）报头前添加UsernameToken标签，利用用户名（Username）和密码（Password）作为服务调用时的验证依据的例子：<soap:Envelopexmlns:soap=“/2013/12/soap-envelope”soap:eneodingStyle=“/2013/12/soap-eneoding”><soap:Header><wsse:Securityxmlns:wsse="/ws/2013/12/secext"><wsse:UsernameToken><wsse:Username>JACK</wsse:Username><wsse:Password>Rose520</wsse:Password></wsse:UsernameToken></wsse:Security>//利用WS-Security规范在SOAP扩展表头写入验证信息……//消息头</soap:Header></soap:Body>……//消息本体，即内容</soap:Body></soap:Envelope>对于“门到门”服务来说，还要涉及很多与铁路外部企业的接口，如集卡公司、防疫安俭等国家监管部门。在实际应用中，可以将这些部门的需要与铁路交互的数据封装为一个数据应用服务：铁路可以通过ESB总线获取集卡公司的货物实时信息、监管部门的审批信息等；集卡公司可以取得需转运货物信息、监管部门也可以方便地实施监管。考虑到铁路数据的高安全级别，在外部接口与内部网络之间应设立足以满足铁路信息安全级别的物理防火墙，并实行严格的IP地址、身份认证。
4结束语
篇10
关键词：Web服务；SSL；安全模型
中图分类号：TP393文献标识码：A文章编号：1009-3044(2011)13-3050-02
Discusses the Problem of Safety in Web Services
HE Ting1， HUANG Dong2
(1.Guizhou University Vocational and Technical College, Guiyang 550003, China; 2.China Nuclear Power Engineering Co., Ltd, Zhengzhou 450052, China)
Abstract: This paper mainly discussed the safety problems of web, in traditional web security problems are put forward on the basis of a reliable web service security model.
Key words: web service; SSL; security model
Web服务是Internet中最重要的服务之一，根据web访问的结构，可以将web服务的安全威胁分为3类：web服务器的安全威胁、web浏览器的安全威胁以及服务器和浏览器之间通信的安全威胁。其中，web服务器和浏览器的安全问题是计算机系统自身的安全性问题，传统的web安全性问题指的是服务器和浏览器之间通信的安全，本文主要讨论了传统的web安全性问题，并在此基础上提出了构建一种可靠的Web服务的安全模型。
1 传统的web服务安全解决方案
提供web服务安全的方法一种方法是使用IPSec，网络层的IPSec对于Web 服务安全来说，是一个很重要的标准。同SSL/TLS一样，它也提供主机审计认证，数据完整性和数据机密性的功能，使用IPSec的好处是它对终端用户和应用是透明的，并能提供一种一般性的解决方案；另一种更一般的解决方案仅在TCP上实现安全，这种解决方案主要是安全套接字层（SSL）和传输层安全(TLS)协议，它们被用来提供传输层的Web服务安全，SSL/TLS在点对点（point-to-point）的会话中,可以完成包括审计，数据完整性，机密性这样的要求。
SSL可以嵌入到特殊的软件包中，例如Netscape和Microsoft Explorer浏览器都配置了SSL，大部分服务器也都实现了该协议。
1.1 SSL体系结构
SSL使用TCP提供一种可靠的端对端的安全服务。SSL不是单个协议，它由两层协议组成。SSL中定义的三个较高层次协议分别是：握手协议、密码变更规格协议和报警协议。SSL协议中两个重要的问题是SSL会话和SSL连接，会话是客户与服务器之间的一种关联，连接是一种能够提供合适服务类型的传输。
1.2 SSL记录协议的运行流程
SSL记录协议对各种更高层协议提供基本的安全服务。尤其是，超文本传输协议是为Web客户端/服务器的交互提供传输服务的协议，它可以在SSL的顶层运行。记录协议要传输应用消息是，先将数据分段成一些可操作的块，然后选择压缩或不压缩数据，再生成MAC、加密、添加头并将最后的结果作为一个TCP分组送出。对收到的数据，首先解密，然后做完完整性验证、解压缩、重组，最后把数据递送到更高层用户。
1.3 握手协议
SSL最重要的部分是握手协议。这一协议允许客户端和服务器相互认证，并协商加密和MAC算法以及用于保护SSL记录中所发送数据加密密钥。握手协议在任何应用数据被传输之前使用，由客户端和服务器之间的一系列消息交换组成。
1.4 密码计算
我们主要关注两个问题：
1) 通过密钥交换创建一个共享主密钥。共享主密钥是通过安全密钥交换方式为本次会话创建的一个一次性48字节的值。创建过程分两步完成。第一步：交换预备主密钥。第二步：双方计算主密钥。客户端和服务器都按照下面方法计算主密钥：
Master_secrect=Md5(pre_ Master_secrectOOSHA('A' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) OO
Md5(pre_ Master_secrectOOSHA('BB' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) OO
Md5(pre_ Master_secrectOOSHA('CC' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) O
其中，ClientHello.random和ServerHello.random是在初始hello消息中交换的两个现时值。
2) 密码参数产生。其方法是主密钥利用散列函数来产生安全字节序列，字节序列足够长以便生成所有需要的参数。
然而，仅有传输层和网络层的这些安全机制是远远不够的，Web服务的安全性是提供一种综合的，全方位的安全保障。
2 构建一种可靠的Web服务的安全模型
2.1 Web服务的协议栈
Web服务体系架构中不同操作与交互的实现，则需要有一系列分层的协议规范，具体协议栈如表1所示。
Web服务能够被服务请求者调用，则必须是能通过网络进行访问的，由于HTTP的普遍性，使它成为了Internet中Web服务的标准网络协议。Web服务还能够支持其它Internet协议，包括FTP与SMTP等。
2.2 Web服务的基本工作过程
要建立面向服务的集成系统可以利用Web服务。我们不用改变现有的各种应用，当然也不需要关心它们技术的不同(比如是java，还是.net),可以利用Web服务的消息驱动机制，使它们协同工作和交互。XML 消息传递是Web服务体系结构最重要的基础，XML 消息传递的行业标准协议是SOAP，服务的调用者通过在传输层协议之上绑定SOAP消息来请求服务。Web服务的基本工作过程是通过发送SOAP消息到一个由URI来鉴别的服务点（由一个SOAP server来接受消息），来请求特定的Web服务(操作)，接收到消息的响应结果或者错误提示。在传输层之外，当消息数据被接受和中转的时候，数据的完整性以及其他的安全信息就可能泄漏或者丢失。这要求Web服务的请求者/提供者必须信任那些中间节点对消息的获得和处理（那些中间节点可能需要处理消息，生成新的消息）。
2.3 Web服务的安全模型
我们把Web服务的安全模型建立在三个层次上：传输层的点对点安全、应用服务级的安全和策略和端对端的安全性。在这三个层次的基础上我们构建的Web服务的安全模型的工作流程是：
1） 服务方可以要求请求者的消息证明一组声明（例如，名称、许可、密钥、性能等等）。这一组声明和相关的信息就是端点策略。
2）请求方可以通过把安全令牌与消息关联起来发送，使得消息既证明了发送者具有要求该操作又可以要求特定的操作的声明。
3）如果请求者无法给出必需的声明，那么请求者或它们的代表可以通过与其它Web服务联系设法获得必需的声明。这里其它的Web 服务，指的是安全性令牌服务（security token service），我们接下来可以要求它们自己的一组声明。安全性令牌服务通过签发安全性令牌不同信任域之间的信任。
传统的web服务安全性中的传输层的安全协议（如SSL/TLS），只能对全部的信息进行加密，而不能选择性地对部分信息进行加密，导致在传送大量数据的时将引发严重的性能问题。我们提出的web服务安全模型中的Web服务支持对SOAP消息的指定部分进行加密或签名可以减少因安全处理而导致的性能损失，这是提高性能的另一个关键。我们可以把安全模型应用于基于Web服务的信息系统中，以期在保证安全的同时提高系统性能。
参考文献：
[1] Stallings W.网络安全基础应用与标准[M].白国强,译.3版.北京:清华大学出版社,2007:175-189.