soap协议范文

soap协议篇1

关键词：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协议篇2

 

关键词：Web　Services　网络完全　技术

1　XML技术

近年来，XML已成为数据表示和数据交换的一种新标准。其基本思想是数据的语义通过数据元素的标记来表达，数据元素之间关系通过简单的嵌套和引用来表示。若所有web服务器和应用程序将它们的数据以XML编码并到Internet，则信息可以很快地以一种简单、可用的格式获得，信息提供者之间也易于互操作。XML一推出就被广泛地采用，并且得到越来越多的数据库及软件开发商的支持。总体讲来，XML具有自描述性、独立于平台和应用、半结构化、机器可处理的、可扩展性和广泛的支持等特点。因此，XML可被广泛应用于电子商务、不同数据源的集成、数据的多样显示等各个方面。XML描述了一个用来定义标记集的方法用于规定一个标记集，填入文本内容后，这些标记和纯文本一起构成了一个XML文档。一个良好的XML文档必须满足以下几条规则：(1)有一致良好定义的结构(2)属性需用引号引起来：(3)空白区域不能忽略：(4)每个开始标签必须要有一个与之对应的结束标签：(5)有且只有一个根元素包含其他所有的结点：(6)元素不能交叉重叠但可以包含：(7)注释和处理指令不能出现在标签中：(8)大小写敏感：(9)关键词“D0CTYPE”、“ELEMENT”、“ATTRIBUTE”和“ENTITY”要大写。为了说明特定的语法规则，XMLDTD(DocumentTypeDefination)采用了一系列正则式。语法分析器(或称解析器)将这些正则式与XML文件内部的数据模式相匹配，以判别文件是否是有效。一个DTD描述了标记语言的语法和词汇表，定义了文件的整体结构以及文件的语法。在Internet中，一个最重要的问题是如何实现数据的交互，即客户端和服务器端双向数据交流。当前所面对的是一个物理上分散的、异源、异构的数据环境，能方便地从这些数据中取得所需要的信息极为重要。XML满足这一要求，它可以将各种类型的数据转换成XML文档，然后对XML文档进行处理，之后，再将XML数据转换为某种方式存储的数据。XML的数据源多种多样，但主要分为三种：第一种为本身是纯文本的XML文档、TXT文件、DAT文件等第二种来自于数据库，如关系数据库、对象数据库等：第三种是其它的带有一定格式的应用数据，如邮件、图表、清单等。针对不同的数据源可以采用不同的技术进行转换。纯文本文档是最基本也是最简单的，它将数据存储于文本文件中，可以直接方便地读取数据。另外，XML文档也可以加上CSS、XSL等样式信息在浏览器中显示，或者通过DOM、SAX编程接口同其它应用相关联。第二种来源主要利用现有的比较成功的数据库资源，是对第一种资源的扩展，可以利用数据库管理系统对数据进行管理，并用服务器编程语言对数据进行动态存取，来实现各种动态应用。第三种数据源的转换可以利用微软提出的基于OLEDB的解决方案，从数据源直接导出XML文档。

2　SOAP技术

SOAP(simple ObjectAcCess PrOtOCO1，简单对象访问协议)是由Microsoft、IBM等共同提出的规范，目的是实现大量异构程序和平台之间的互操作，从而使存在的应用程序能够被用户访问。W3C的SOAP规范主要由SOAP封装、SOAP编码规则、SOAPRPC表示及SOAP绑定四方面的内容组成：(1)SOAP封装(SOAPEnvelop)：构造了一个整体的SOAP消息表示框架，可用于表示消息的内容是什么、谁发送的、谁应当接收并处理它，以及处理操作是可选的还是必须的。信封包含了S0AP消息头部(可选)和SOAP消息体(必须)。消息体部分总是用于最终接收的消息，头部可以确定执行中间处理的目标节点。附件、二进制数字及其他项目均可以附加到消息体上。(2)SOAP编码规则(SOAPEncodingRules)：定义了一个数据编码机制，通过这样一个编码机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所衍生的实例。(3)S0AP RPC表示(S0AP RPcRepresentation)：定义了一个用于表示远程过程调用和响应的约定与HTTP相似，RPC使用请求／响应模型交换信息。使用SOAP调用远程方法的主要工作就是构造SOAP消息。SOAP请求消息代表方法调用，被发送给远程服务器，5OAP响应消息代表调用结果，返回给方法的调用者。(4)SOAP绑定(sOAPBinding)：定义了一个使用底层协议来完成在节点间交换SOAP消息的机制。SOAP消息的传输依靠底层的传输协议，与传输层的协议都能进行绑定。SOAP采用了已经广泛使用的两个协议：HTTP和XML。HTTP用于实现SOAP的RPC风格的传输，而XML是它的编码模式。SOAP通讯协议使用HTTP来发送x扎格式的消息。HTTP与RPC的协议很相似，它简单、配置广泛，并且对防火墙比其它协议更容易发挥作用。HTTP请求一般由Web服务器来处理，但越来越多的应用服务器产品正在支持HTTP XML作为一个更好的网络数据表达方式，SOAP把XML的使用代码转化为请求／响应参数编码模式，并用HTTP作传输。具体的讲，一个SOAP方法可以简单地看作遵循SOAP编码规则的HTTP请求和响应。一个SOAP终端则可以看作一个基于HTTP的URL，它用来识别方法调用的目标。SOAP不需要将具体的对象绑定到一个给定的终端，而是由具体实现程序来决定怎样把对象终端标识符映像到服务器端的对象。

3　WSDL与UDDI技术

soap协议篇3

关键词：ONVIF Web 服务 gSOAP 网络视频监控系统

中图分类号：TP277 文献标识码：A 文章编号：1007-9416（2013）06-0128-03

ONVIF致力于通过全球性的开放接口标准推进网络视频在安防市场的应用[1]。这一标准定义了网络视频设备之间信息交换的通用协议，使不同生产厂商的网络视频产品具有互通性。该协议是以Web Service为基础的，目前WebService主要通过基于C/C++编程的gSOAP开源工具、基于C#的NET：sveutil.exe开发工具和采用JAVA语言的ApacheAXIS2这几种编程工具来实现。不管是哪种编程语言，都已经有相应的工具包来定制和Web服务。

考虑到gSOAP是一个快速应用程序开发（RAD）环境，因为该系统在利用C和C++开发Web服务和客户端应用程序时很大程度地实现了自动化，在简化Web服务的应用程序开发上具有一系列特征。本文将研究gSOAP工具包在基于ONVIF协议的网络视频监控系统中的应用。

1 gSOAP简介

1.1 gSOAP工具包

gSOAP的工具包项目受到美国联邦政府的研究和发展项目基金的资助[2]，是一款开源的WebServices软件。该工具包提供了一个SOAP/XML关于C/C++语言的实现，一定程度上简化了使用C/C++语言开发Web服务或客户端程序的工作。gSOAP利用编译器技术提供了一组透明化的SOAPAPI，并将与开发无关的SOAP实现细节相关的内容对用户隐藏起来，故对软件开发者而言无需了解SOAP协议实现细节而只需调用这些API即可，因此非常方便。同时gSOAP能够集成C/C++和Fortran代码，跨越多个操作系统平台和语言环境，使用范围相当广泛。该工具包分析WSDL语法和XML模式，并且把XML模式类型和SOAP传递协议映射到易于理解和使用的C/C++代码。如果使用C++语言开发万维网服务，还可以选择是否支持C++的STL。

1.2 gSOAP技术

gSOAP是跨平台的万维网服务开发平台，资源要求不高，它以XML文件形式请求远程服务，再以XML文件的形式返回执行结果。在gSOAP开发Web服务的方法的过程，通过使用gSOAP中的wsdl2h命令并根据输入的WSDL文档生成相应的头文件，接着根据刚刚生成的gSOAP头文件来运行gSOAP编译器soap2cpp生成源代码来实现客户端应用程序框架，客户端应用程序则可利用RPC存根和gSOAP通信模块在网络上触发SOAP/XML服务函数。具体流程如图1所示。

需要指出的是，上面客户端开发中所使用的WSDL文档实质上是一个XML文档，它用来描述一个Web服务的定义。

2 相关ONVIF模块实现

基于ONVIF协议的网络视频监控的网络视频接口方案，是基于Web服务框架，使用了WSDL网络描述语言进行服务定义，XML语言对数据进行描述，并采用SOAP通信协议进行信息传输。其重点在于网络视频的发送端与网络视频接收端之间的接口，因而具有严格的执行过程，确保了作为统一化通用接口的兼容性与可靠性。ONVIF规范的接口功能包含网络服务框架、设备发现和管理、媒体服务和实时流传输、云台控制等。

ONVIF的相关服务模块，利用与其对应的WSDL文件来描述该服务。服务请求方可以利用该WSDL文件，通过gSOAP编译工具wsdl2h和soapcpp2产生SOAP框架代码。下面具体分析gSOAP对ONVIF规范下的媒体服务模块的应用开发。

2.1 媒体服务

2.2 具体实现

根据ONVIF规范开发流程，可以在ONVIF官方网站下载相应的媒体服务相关的media.wsdl文件，该文件主要是用来描述与媒体服务相关的Web服务交互的消息格式、数据类型、操作、协议在程序设计中我们调用的SOAP系列函数是gSOAP提供的透明化的API，通过它们，可以设置SOAP环境，并进而通过远程调用方法作为gSOAP交互模型的入口函数，发送请求。在gSOAP交互模型中，主要遵循HTTP/HTTPS通信协议来完成开发人员的需求。

3 实验结果与分析

soap协议篇4

[关键词] 电子商务 后台数据 XML

一、XML在电子商务中的作用

在电子商务应用系统中，XML简化了在制造商与消费者之间的数据交换过程，因为只要使用同样的XML语言并使用XML交换数据和元数据，他们就可不必采用同样的实现手段了。例如：XML可以被用在供应链管理环境中交换产品目录。此时，供货商使用XML作为默认的格式将他们的产品清单发送给零售商，零售商则可以将这些信息载入到自己的数据库中并能立即在他们的Web商店中显示。

XML只处理数据及其结构，而不涉及数据的表示。XSL的样式表单负责处理XML结构化数据的表现形式。XSL对于XML而言是一个天然的数据转换机制，它允许同一XML文档可以被多个设备显示，而表现形式则主要依赖于该设备所应用的样式表单。每个样式表单对于每个特殊的设备都有不同的考虑。通过使用XML和XSL，开发者可以维护单一版本的应用程序和数据源，但可以通过不同的样式表单支持各种不同的设备。所以，在电子商务应用中，使用XML，就可以实现异种数据之间的相互转换。在电子商务中进行数据交换，以前都是基于EDI（电子数据内部交换）。但是基于XML的系统比基于EDI的系统在实现和维护上都要经济的多。XML围绕异种数据源提供了虚拟层，并通过单独一个统一接口简化了数据源的集合。而Oracle XML网关可用于将Oracle电子商务套件和任何第三方的ERP系统或类似

的环境集成在一起。

二、电子商务中的XML消息传递方案

作为代表方案的SOAP采用了HTTP作为底层通讯协议，RPC作为一致性的调用途径，XML作为数据传送的格式，允许服务提供者和服务客户经过防火墙进行通讯。RPC的描叙可能不大准确，因为SOAP一开始构思就是要实现平台与环境的无关性和独立性，每一个通过网络的远调用都可以通过SOAP封装起来。SOAP的两个主要设计目标是简单性和可扩展性。这就意味着有一些传统消息系统或分布式对象系统中的某些性质将不是SOAP规范的一部分。SOAP在商业尤其是Web服务方面得到广泛的应用。

支持传递XML消息的通讯协议当然不止SOAP一种，其中包括了XML-RPC，WDDX，ebXML和JMS，等等。W3C组织的 Eric Prud'hommeaux 和 Ken Macleod 调查了这些协议，并给出一个非常好的总结。XML-RPC提供了一个非常简单使用在HTTP上传递XML的RPC机制。WDDX(Web Distributed Data Exchange)是由Allaire公司开发的，提供了一个在HTTP之上交换复杂数据结构的机制。WDDX声明的目标是“提供一个更类似Web的方法在不同的网络实体间传送结构化数据对象，而不需要将开发Web应用的编程方法从面向页面改变到面向对象。”但是WDDX序列化的方法是基于结构的而不是基于对象的。可以看出，XML-RPC、SOAP和WDDX都是基本的在HTTP上序列化和传递XML编码数据的技术，也是相对简单和现实的解决方案。

ebXML是一项倡议，参与者包括很多大公司和和官方标准协会。ebXML是一个规范集，这些规范共同实现了模块化电子商务框架。ebXML的构想是实现一个全球电子市场，不同规模和不同地区的企业可以通过交换基于XML的消息来合作和进行商业活动。ebXML消息传递支持在多方交易处理中必须的高层语义。这些语义包括一对一以及一对多路由模型，对多方回路文档交换的支持，以及根据消息头属性的服务质量确定。ebXML与传输协议无关，甚至可以用SOAP。

Java消息服务（Java Message Service，JMS）API是J2EE平台的构成元素。JMS 1.0.2定义了两种类型的消息传递域（它们是相互独立的），即点对点／订阅。尽管JMS不是专门为传递XML设计，但是在实际应用中由于它对消息交换高层语义的支持使得它也可以传递XML。

三、面向对象的XML消息传递协议

为了避免一些已经存在缺陷和适应XML消息传递应用需求的复杂化，我们认为协议设计要着重考虑以下几个方面：

1.序列化的实现应当更高层

由于直接使用RPC机制会带来一些问题，如难以实现高度的交互性，在实现扩展协议编程接口时会有困难，在安全上的问题。为了可交互性序列化机制应使用高层协议实现，而不应依赖于面向RPC的实现。

2.协议应当面向对象

由于序列化的方法是基于结构而不是基于对象所以不能被用来交换具有复杂关系的对象实例，所以应采用面向对象更适合通用地表达商务逻辑，所以应采用面向对象方法来弥补这样的缺陷，以便能更通用地帮助协议实现模块化，以及提高模块的可重用性。

3.协议应当简单化，并有良好的可扩展性

在像Web环境这样的松散结构下，要求开发的简易性、系统的可扩展性，这也是对XML消息传递协议的要求。从这个角度来说，SOAP是一个典型代表。SOAP本身不解决高层的分布式对象问题，例如，对象引用、对象激活、分布式垃圾收集、成批传送消息、生命周期管理等。

基于以上的分析，所以我们认为XML消息传递协议应是一个简单的、扩展性良好的面向对象的解决方案，并能在更高层实现序列化。

四、结束语

soap协议篇5

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（extensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了[2]。

目前Web 服务已经是实现 SOA 的一种重要的方式，以至于很多人将两者的概念混淆。现在SOA要求服务间广泛的互操作性，SOA虽然能解决异构平台下Web服务的互相调用，在开发Web服务的逻辑功能时，如果把安全特性也设计进来，使其能实现SOA安全之目标，无论对理论与技术实践，都提出了挑战。

1 异构平台安全特性

SOA要求服务间广泛的互操作性。在开发Web服务的逻辑功能时，如果把安全特性也设计进来，Web服务将变得异常复杂，服务的性能与可伸缩性会大大降低。就安全需求本身分析，仅仅把各种安全措施集合在一起，不能肯定安全组件的组织是否恰当，也不能肯定能使一个系统更加安全。因而SOA中Web服务的安全问题应与服务的功能脱离，通过适当的安全配置与安全机制实现Web服务的安全需求。这样，既能保证Web服务设计与调用的简洁性，又能实现SOAP信息传递与服务调用的安全性。

一个应用系统通常是基于某个平台实现的，如基于Microsoft .NET或Apache Axis。这些服务平台都有独立的安全解决方案，如Microsoft 的WSE（Web Service Enhancement） 、Axis 的Rampart等。对于同一个安全策略，如采用证书对消息签名，服务请求方对消息签名，服务的提供方对签名验证，在相同平台中是可以实现的。但如果请求方与服务提供方处于不同的平台中，安全的互操作性通常无法保证。

每个应用平台都有自己的安全机制与安全API，这类商业软件使用自己的策略配置为安全建模。但是，在使用SOA进行企业应用集成时，不同应用系统的服务可能在不同的应用平台上，采用不同的安全策略与平台技术实现安全需求。这时需要一个处理服务安全的机制从逻辑上包装平台安全的特定实现，使异构平台下的SOAP安全信息能够被异构平台一致地理解与处理[3] [4]。

异构平台下Web服务安全处理机制提供了相关安全策略配置与SOAP消息安全的实现方法。安全服务使用WS-Security等规范实现SOAP消息安全，分为以下三个方面：

1） 消息完整性：使用XML签名对SOAP消息进行数字签名，保证SOAP消息经过中间结点时不被篡改。

2） 消息保密性：使用XML加密对SOAP消息进行加密，使消息发送方可以确保SOAP消息内容仅对预定的接收方可见，保证SOAP消息即使被监听，监听者也无法提取出有效信息。

3） 消息真实性：引入安全令牌的概念，用其代表消息发送方的身份。通过与多种数字签名结合，消息接收者可以确认SOAP消息发送者的合法性。

2 异构平台的策略框架

2.1 NET平台WSE 3.0安全策略

在WSE的安全实现框架中，针对SOAP消息从客户端发送请求、服务端接收请求、服务端发送响应和客户端接收响应设计了四个过滤器，并分为两组。在SOAP请求后和SOAP响应前截取SOAP，然后对截取的SOAP消息的数据进行处理。每个过滤器负责一项特定任务，既可以是安全事务，也可以是跟踪等管理事务。该框架结构实现了安全逻辑与业务逻辑的分离，WSE安全框架结构如图1所示。

WSE 3.0提供的安全机制保证了Web 服务的安全。实现安全的方式有两种，一是通过WSE3.0策略工具根据应用系统的安全规格为服务端和客户端设置相应的安全策略；二是用代码实现具体的安全策略相同的功能。前者方便快捷，通过简单的设置即可完成Web服务的安全。后者用户可以定义更具体的代码来扩展自己的安全策略。不论采用那种方式都可以利用WSE 3.0提供的安全机制保证Web服务的安全交互。

由于策略由策略断言组成，并且每个断言都会在管道中插入过滤器对进入和离开终结点的SOAP消息执行预处理和后续处理。通过将断言放到策略中，可以在运行时控制构建和组织过滤器管道。在WSE 3.0中，管道是由安全策略框架驱动的。

2.2 Axis平台Rampart安全策略

Rampart的结构如图2所示，其中mod-rampart模块的作用是为Rampart和Axis2引擎提供接口。Rampart内部由Rampart引擎（Rampart Engine）、Rampart功能实体（Utile）和Rampart安全策略（Security Policy）组成[5]。

在Rampart中，Security Policy具有配置安全模块的作用。Rampart使用WS-Security Policy规范中定义的安全策

略断言进行配置，WS-Secu rity Policy中的每一个策略断言，都定义了一个断言构建器（Builders）和一个断言模型（Models）。

Rampart作为WS-Security的实现模块加载到Axis2引擎后，既可以对所有的有效服务进行安全处理，也可以选择对一个或者多个具体的服务或者某一服务中的特定方法进行安全处理。

3 异构平台Web服务安全模型

异构平台之间的安全框架、配置策略等都有较大的不同，因此实现异构平台间Web服务的安全交互必须增加一个第三方认证机构，根据客户端的请求完成相关验证，验证通过后才能发送调用Web服务的请求；根据本项目对于Web服务的安全需求.结合WS—Security和WS—Policy规范.构造了一个Web服务的安全模型系统。

3.1安全模型体系构架

该系统实现安全的基础主要是基于SOAP头的扩展.分别实现SOAP加密、SOAP签名、SOAP认证与授权、SOAP安全属性扩展（时间戳等）。对于访问控制。我们设计了Web服务访问控制器，该控制器的实现主要基于X—RBAC模型，动态的控制用户对Web服务的访问权限。遗留系统包括一个私有CA 中心，这方便了安全模型的实现，它主要负责密钥和证书的生成和管理。此外，安全日志也保证了模型系统具备审计的功能，安全策略管理器则是负责对安全策略文件的管理。安全策略库保存着Web服务所对应的特定安全

策略文件。安全模型体系架构如图3所示。

3.2安全模型组成及其功能

安全模型主要包括安全组件包（Security Utility）、访问控制器以及安全策略管理器三部分。安全组件包由若干个SOAP消息过滤器（Filter）组成。安全组件包主要功能如下：

1）消息加密：基于XML Encryption实现SOAP消息的加密以及解密功能.密钥管理基于XKMS技术。

2） 消息签名：基于XML Signature实现SOAP消息的签名以及签名验证功能。密钥管理也基于XKMS技术。

3） 认证信息处理：通过WS—Security所支持的Username/Password Token或X.509证书安全令牌实现对用户身份的认证。

4）附加安全属性：附加的安全属性主要是防止对Web服务的重传攻击，通过时间戳机制来实现。当然.附加的安全属性也可根据用户额外的安全需求进行扩展，实现更加安全可靠的S0AP消息。

3.3模型的通信过程

在介绍完整的通信过程之前，首先给出所涉及的符号及其描述，如表1所示。

通信过程说明：

·在安全通信过程开始前，服务请求者通过SOAP消息或者其他方式获得服务提供者所提供的Web方法对应的安全策略文件。

·服务请求者根据安全需求对请求消息中需要进行安全保护的部分进行签名/加密处理，然后使用服务请求者的私钥对整个消息进行签名，并使用服务提供者的公钥对整个消息进行加密，最后将结果连同证书发给服务提供者。

·服务提供者收到请求消息后，先提取消息中服务请求者的证书，验证其有效性.验证通过，利用证书所提供的公钥验证消息签名的有效性，同时解密整个消息。

·如果安全验证全部有效，则建立整个通信过程。实现对服务的调用，然后按照安全策略文件的要求对响应的消息进行安全处理后发送给服务请求者。

·服务请求者接收到经过安全处理的消息.如果通过有效的安全认证，则按照安全策略文件的要求对消息进行签名验证和解密，最终获得原始响应消息。上述通信过程都设有超时机制，若超时则重新执行整个通信过程。若在通信过程中发生致命错误，例如，认证未通过.解密、验证失败等，则终止通信，发出错误响应消息[6]。

4 研究的方向

4.1安全策略的改进

安全策略：是指在某个安全区域内（一个安全区域，通常是指属于某个组织的一系列处理和通信资源），用于所有与安全相关活动的一套规则。这些规则是由此安全区域中所设立的一个安全权力机构建立的，并由安全控制机构来描述、实施或实现的。

下一步的研究方向针对安全服务机制没有实现的安全策略，开发实现相应的安全服务。现在的安全策略都是对所有的消息进行加密，这样效率不高，资源浪费。下一步的研究准备针对部分机密消息加密，从而提高效率。

4.2 Kerberos票据

网络认证使用最为广泛的协议是Kerberos和X.504.K。Kerberos是基于对称密码机制的，X.509是基于非对称密码机制的，两者各有特色。Kerberos在分布式网络环境中得到了广泛的应用；X.509在PKI中发挥重要作用。下一步在学习研究Kerberos协议的基础之上，分析了麻省理工大学（MIT）和微软对Kerberos认证协议的实现，在此基础之上，针对Kerberos的某些局限提出并实现了一个切实可行的解决方案。

4.3通用安全模型

现阶段仅就两个具体的平台来探索了异构平台下Web服务安全交互的模型和应用。对于基于广泛平台的异构平台下的Web服务，还没有一种统一可靠的安全模式能保证SOAP消息在多平台间传输过程中的安全性，这种安全模式也是我们下一阶段研究的重点。

5 结束语

本文介绍了在 SOA构架下Web安全，具体介绍了在Microsoft .NET和Apache Axis平台下自带的不同安全策略，并且提出了在这两个异构平台一个安全模型下互相通信的模型。下一步将具体进一步研究异构平台的安全策略并验证。

参考文献：

.冉晓旻，译.北京：清华大学出版社，2003.

[2] http：//baike.baidu.com/view/21305.html？wtp=tt.

[3] 唐柳英，卿斯汉.混合RBAC-DTE策略的多角色管理[J].计算机学报， 2006，29（8）： 1419-1425.

[4] 王小明，赵宗涛.基于角色的时态对象存取控制模型[J].电子学报， 2005，33（9）： 1634-1638.

soap协议篇6

【关键词】WebService 中间件 考试平台

随着计算机技术和网络技术的飞速发展，以网络为基础的在线考试系统平台在越来越多的考试中被使用。但大部分的考试系统由于缺乏统一的格式标准和技术手段，没有统一的试题资源库设计和相关开发规范，在不同的考试系统中使用不同的数据存储方式，各个系统各自设计独立的试题资源系统，这将直接导致这些试题资源内容难以被共享和重用。由此，本文利用WebService和XML技术为我系软件技术专业构建一个分布式、多层次、信息共享、跨平台和代码重用的课程在线考试平台。

一、WebService技术

WebService平台是一套定义了应用程序如何在Web上实现互操作性的标准，是解决应用程序之间相互通信操作的接口。它采用简单易懂的标准Web协议作为组件协同描述和表示层界面描述规范，通过SOAP、WSDL、XML、UDDI等技术手段进行开发和运行。此外，WebService接口具有良好的跨平台性，开发者可以用任何喜欢的编程语言，在任何自己喜欢的平台上进行WebService开发，只要访问请求可以通过这些WebService接口进行查询和访问就行。

下面简单介绍下与WebService相关的几个关键技术。

（一）XML。XML（Extensible Markup Language）全称为可扩展标记语言，它具有形式和内容分离的特点，是目前Web应用领域的一种通用数据标准。WebService的通讯基础是通过XML进行消息传递，其传递是基于HTTP之类的标准网络协议，这对任何编程语言、软件平台和中间件来说都是很容易实现的通讯机制，使得系统的协同工作能力变得更加轻松和方便。

（二）SOAP。SOAP（Simple Object Access Protocal）是简单对象访问协议的简称，它定义了传递XML数据时的统一方式和使用HTTP作为底层通讯协议时执行远程调用的方法，是一种基于XML的协议。SOAP可以在不同的操作系统和不同的体系结构中进行通讯。

（三）WSDL。WSDL（WebService Description Language）是WebService的描述语言，它定义了WebService以及如何被调用。WSDL文档可以用于动态、查找和绑定WebService。

（四）UDDI。UDDI（Universal Description，Discovery and Integration）是通用描述、发现和集成协议的简称，它提供了一套对WebService的标准化描述和动态、查找、调用的机制，是分布式WebService的信息注册规范。WebService可以按照这个规范进行注册并提供查询服务，我们开发的各个不同的在线考试系统可以通过UDDI机制发现并集成不同的WebService，从而减少系统的重复开发，达到共享和写作的目的。

（五）WebService技术的优势和特点。WebService的优势和特点主要表现如下：首先，WebService的优点主要体现在它的平台无关性和互操作性两方面，WebService是使用SOAP协议来调用和回调的，开发者不用再为开发平台不同和协议的不同而建立不同的连接程序了，因为SOAP协议本身就是与开发平台无关的。另外，不同的WebService之间可以进行交互操作体现出其良好的互操作性。其次，WebService基于HTTP协议通过XML进行通讯的，由于目前绝大部分应用都是基于HTTP协议的，并且XML也已经被广泛的使用，所以只要支持这两种技术的平台都可以承载和访问WebService，实现系统的最高可以集成性。还有，开发者可以通过使用WebService技术实现网页的无刷新与服务器交互；使用SOAP、XML等技术将使得开发难度和成本降低；使用HTTP协议通讯能够很方便穿透防火墙等特性也都是在在线考试系统中应用WebService技术的优势。

二、构建系统平台模型

本文是以我院软件技术专业的课程考试为例，按照该专业的应用需求对在线考试系统的模型进行构建。经过研究分析，我们设计的在线考试系统模型主要包括考试综合管理接口（对管理员、学生帐号信息，系统配置信息的管理）、试卷管理接口、题库管理接口、组卷接口、登录和身份验证接口、系统信息加载接口、试卷评分接口，文件上传接口和数据库访问接口等。

系统模型逻辑结构如图1所示：

主要功能模块说明如下：

（一）考试综合管理。本模块主要包括系统管理员管理、学生帐号信息管理、系统配置信息管理等功能，是整个考试系统的综合管理模块。

（二）试卷管理。该模块主要负责的是考生试卷信息的综合管理，包括保存，查询等功能。

（三）题库管理。题库管理主要包括考试系统试题的添加、修改、删除、查询等操作。

（四）组卷。组卷是很重要的一个模块，该模块主要负责按照系统提供的信息进行组卷，其中智能组卷包括按照难度、分值、考试内容等进行综合评定随机组卷。

（五）登录和身份验证。考生、监考老师和管理员的帐号信息验证都要通过这个模块的接口去访问数据库，信息有效则进入系统，无效则返回登录界面。

（六）试卷评分。考生提交完考试数据后，系统将试卷信息转交给试卷评分模块进行综合评定，返回评定结果给调用者。

（七）文件上传。文件上传模块主要负责的是考试结束后考试数据或者作品的上传，该接口的调用只需要请求者传入文件信息和保存目录即可。

（八）系统信息加载。该模块主要负责的是考试系统的系统信息加载和配置。

三、系统架构研究与设计

基于以上系统的功能模块，我们在对系统进行设计的时候应当随时考虑系统模块的重用性，越多的组件被重用，那么表现出来的就是开发代价越少、系统维护成本越低、系统可扩展性越好。以WebService方式一些系统中提供公共服务、业务规则的应用，我们只需要指定访问权限，哪些是提供公开访问的，哪些是私有即可。

上图2中各个WEB服务即为在线考试系统所提供的服务，也就是图1中左边的各个功能模块接口，这些服务采用多层思想进行设计，提供WebService接口，在UDDI中进行注册，同时可以整合应用服务提供的WebService形成新的业务逻辑。在线考试系统客户端访问层可以采用任意支持HTTP协议和XML技术的平台进行开发，具有完全的跨平台性。

整个系统的工作流程为：应用服务器收到访问者的请求后，先到UDDI注册中心查询是否存在该服务，如果存在则通过WSDL绑定定位到提供服务的应用服务，调用相关WebService进行处理，整个访问过程都是基于SOAP交互进行的。最后，不同应用服务的WebService在应用服务器中进行整合，以Web页面的形式返回给访问者。

四、结论

本系统借助我院校园网，使用WebService技术构建软件架构，按照软件技术专业实际课程考试的需求进行设计与开发。该考试系统投入使用后，克服了以前软件技术专业课程考试的一些缺点，大大提高了考试的工作效率和管理水平，解决了一些实际问题，达到了预期的研究目的。

参考文献：

[1]Vincent Ryan（美）.Web服务的革新[J].CIO Today Magazine，2010（9）：90-95

[2]柴晓路.架构WebService为什么需要Web服务[G].IBM：deverloperWorks，2009

[3]穆丹.集成JavaEE架构构建MIS系统的研究与实现[D].长安大学硕士论文，2008

（此文用于湖南省教育厅课题11C0274《基于移动Agent的无线WebService中间件应用研究》结题）

soap协议篇7

关键词：JavaTM EE；WebService；大型物流；信息系统

中图分类号：TP315文献标识码：A文章编号：1009-3044(2008)34-1578-03

Implementation of Logistic Information System Based on JavaTM EE and WebService Technology

ZHAO Jie

(School of Information Security Engineering, Shanghai Jiaotong University, Shanghai 200240, China)

Abstract: With being widely used in modern logistics,JavaTMEE and WebService technology is becoming the main technology in distributed-web software developing. This thesis introduced and analyzed JavaTMEE and WebService technology. This paper has designed a model of secure logistic information system, and also provides the scheme of realization based on JavaTMEE platform.

Key words: JavaTM EE; webservice; logistic information system

1 前言

互联网技术、数据库技术和软件工程技术的高速发展带动了传统物流向现代物流的转变。在当今经济全球化的社会，信息化的程度成为了判定现代物流企业成熟度的关键因素。软件工程技术的发展，使得人们可以设计并构建出灵活、功能强大和高质量的信息系统。JavaTMEE (Java2 Enterprise Edition)是SUN公司定义的一个开发分布式企业级应用的规范。J2EE是在分布式环境中的一种体系结构，它提供了一种基于组件的设计、开发、集成、部署企业应用系统的方法。作为当前企业构建应用平台的首选架构，它是目前主流的企业分布式架构平台。WebServices是一种用于分布式应用程序之间通信的接口技术，它构建于通行的Internet标准协议栈之上，提供了一种B2B应用程序的耦合方式。Web Services的基本思想是把软件当作一种服务。开发者可以使用JavaTMEE平台、WebServices技术开发出设计良好的系统。

2 J2EE体系架构概述

从整体上讲，J2EE 是使用 Java 技术开发企业级应用的一种事实上的工业标准而不是现成的产品，它是一种利用 Java2 平台来简化诸多与企业解决方案的开发、部署和管理相关复杂问题的体系结构。他的主要技术目标是：为企业应用系统提供具有高度可移植性和兼容性的安全平台。J2EE 为企业应用系统的开发提供了一个企业级的计算模型和运行环境，他通过提供企业计算环境所必需的各种服务,使部署在 J2EE 平台上的多层应用实现高可用性、安全性、可扩展性和可靠性。J2EE 平台应用各种不同的应用组件(如 Servlet，JSP，EJB)，它们构成了应用的主体。J2EE 平台提供的应用服务(如 JDBC，JTS，JNDI)，这些服务保证并促进组件的良好运行。J2EE 的应用通信技术(如 RMI，JMSJavaMail)在平台底层实现机器和程序之间的信息传递。J2EE 平台应用多层分布式结构来构造企业应用。企业应用的逻辑根据其功能而分布到不同的 J2EE组件中，组成 J2EE 应用程序的各种 J2EE 组件根据它所在的层被到不同的机器上。在 J2EE 的应用平台中一般分为以下四层：

1) 客户层：客户层组件运行在客户机上；

2) cWeb 层：Web 层组件运行在 J2EE 服务器上；

3) 业务逻辑层：作为解决或满足某个特定业务领域的需要的逻辑的业务代码由运行在业务层的 EJB 来执行；

4) 企业信息系统层（EIS）：运行在 EIS 服务器上。EIS 服务器运行企业信息系统软件，如企业资源计划((ERP)、大型事务处理、数据库系统及其他遗留信息系统。J2EE 组件可以通过访问 EIS 来取得数据库连接，这也是 EIS 层应用最多的一种形式。

J2EE 平台的层次结构如图1所示。

作为企业分布式应用的开发标准，J2EE由一系列的企业应用开发技术实现。J2EE技术框架可以分为三部分:组件技术、服务技术和通信技术。整个J2EE技术框架体系如图2 所示。

3 WebService核心技术及Web安全技术

3.1 WebService核心技术

WebServices是一个面向服务的环境，从体系结构上看，服务提供者、服务请求者、服务者通过三种基本操作有机的联结在一起协同工作。三种基本操作用Web Services技术组件实现，Web Services的组件基本部分包括HTTP，XML，SOAP，UDDI，WSDL。服务使用UDDI，查找使用UDDI和WSDL的组合，绑定服务使用WSDL和SOAP。数据交换和表示的标准语言XML与UDDI，WSDL,SOAP标准实现了WebService 。图3描述了WebServices所使用的核心技术。

WebServices核心技术包括：

UDDI（Universal Description Discovery &Integration）：UDDI(统一描述、发现和集成)标准定义了Web服务的与查找的方法。UDDI提供了一种基于分布式的商业注册中心的方法，UDDI注册中心由UDDI规范的一种或多种实现组成，它们可以相互操作以共享注册中心数据，合在一起就形成了UDDI业务注册中心。该业务注册中心维护了一个企业和企业提供的Web服务的全球目录，其中的信息描述格式是基于通用的XML格式的。业务注册是UDDI的核心组件，它用一个XML文档来描述企业及其提供的Web服务。在UDDI协议中，注册信息包含四种数据结构:Business Entity，Business Service，Binding Template，Tmodel。

WSDL（Web Services Description Language）：WSDL(Web服务描述语言)用于描述Web服务的接口和功能。一个WSDL文档将服务定义为成一个能交换消息的通信端点的集合，或者端口的集合。在WSDL中，作为一个网络端点的集合，Web服务的端点及消息的抽象定义与它们具体的网络实现和数据格式绑定是分离的。这样就可以重用这些抽象定义：1) 消息，需要交换的数据的抽象描述；2) 端口类型，操作的抽象集合。针对一个特定端口类型的具体协议和数据格式规范构成一个可重用的绑定。一个端口定义成网络地址和可重用的绑定的联接，端口的集合定义为服务。

SOAP（Simple Object Access Protocol）：SOAP定义了如何使用XML在分布式环境中传递结构化信息。它本身没有定义任何应用程序语义(如编程模型和特定语义的实现)，但通过提供模块化的打包模型和模块中数据的编码规则，定义了一个可以表示应用程序语义的简单机制。就是这种与特定语义无关的机制使得SOAP能够用于从消息传递到RPC的各种系统。SOAP由三部分组成:消息框架、编码规则和RPC机制。SOAP消息包括以下三部分：1) EnvelopeEnvelope元素是SOAP消息的最上层元素。2) Header 可选元素，它提供了一种扩展机制，除Body元素传输的消息语义外，允许任何类型的信息存在，WS Security的元素便是放在SOAPHeader:中。3) Body Body元素用于包含SOAP请求或应答。 SOAP还定义了下面几个属性：1) encodingStyle指定SOAP消息的串行化规则（数据元素的编码规则），它可出现在任何一个元素中，作用于该元素及其没有指定encodingStyle的子元素。2) Actor一个SOAP消息在到达最终接收点之前，可能会经过多个中间处理者，Actor属性用于指示Header元素的接收者。3) mustUnderstand用来指示一个Header元素对于接收者是强制性的还是可选的，若为强制性的，接收者必须能够处理此Header元素，否则处理必须失败;若为可选的，则接收者可选择对此Header元素是否进行处理。

3.2 Web服务安全技术

安全的Web服务是Web服务成功的必要保证。但众所周知的是，Web服务使用XML来进行数据交换，而XML在默认情况下是明文编码的;同时，大部分Web服务使用HTTP协议作为传输协议，同样，HTTP也是使用明文方式来传输数据的。这就造成了在不加密的传输协议上传输不加密的信息，从而使信息传输的保密性受到威胁。作为企业级的应用，以上的方式不能满足下列安全性基本要求：

1) 数据在因特网上传播时不应该被第三方看到；

2) 双方必须能够确定消息的来源；

3) 双方必须能够确定被传送的数据没有被篡改。

为保证Web服务的完整性和保密性，IBM和Microsoft共同定义了一个Web服务安全模型，WS-Security则为此安全模型的核心。模型结构如图4所示。

WS-Security 描述了如何为SOAP消息附加签名和加密头部，以及如何为SOAP消息附加二进制编码的安全令牌。XML签名和安全令牌联合保证了数据完整性。SOAP消息的保密性则由XML加密和安全令牌共同提供。

1) WS-Policy WS-Trust描述了建立直接或间接信任关系模型（包括在第三方和中介体之间）。

2) WS-Privacy 定义了Web服务中如伺表述个人隐私政策。

3) WS-ScureConversation记述相互交换的信息的管理及认证方法。

4) WS-Federation记述在不同环境下管理及从中协调信赖关系的方法。

5) WS-Authorization定义Web服务管理认证数据及政策的方法。

4 基于安全的物流信息系统模型

系统模型如图5所示。

系统针对物流帐务信息的安全性问题建立一个安全的物流信息系统。模型中牵涉到物流信息管理中心、物流企业、政府统计局、信任服务中心、UDDI服务器等五个实体。在模型中假设模型中牵涉到物流信息管理中心、物流企业、政府统计局、信任服务中心都应分别拥有一对密钥，在信任服务中心进行了注册，利用PKI来解决企业之间的身份认证问题。

系统是基于XML技术的Web服务体系结构。安全性上是基于PKI的，在PKI的访问和集成上采用了XKMS规范，将许多个PKI协议和数据格式替换成一个基于XML的协议，以此来确保用户的身份有效性。

5 系统设计

5.1 系统功能分析

系统针对成都市大型物流信息的统计与管理，其用户为成都市各大中小型物流企业、成都市统计局。系统功能构成模块如图6所示。

系统实现的功能有：

1) 物流企业信息上报对物流企业信息上报要求系统能够提供以下功能：对企业自身的注册及信息具体化、对物流统计年月周报表的填报提交、按照审核意见在所得权限内修正或重提交。

2) 针对物流企业的管理对物流企业的管理要求系统能够提供以下功能：市政府相关部门对物流企业的注册管理、提供对物流企业的通知功能。

3) 对物流信息的统计管理对物流信息的统计管理要求系统能够提供以下的功能：对统计报表的设计改动、对上报信息的审核批准、对已有信息的数学统计、公共查询功能。

4) 对客户身份的安全性认证

5.2 系统数据库设计

系统选用Miicrosoft SQLSERVER-2000作为系统后台数据库支持。

系统数据库结构：

1) 基础资料表：物流企业信息表、客户身份表、管理员身份表。

2) 报表设计表：对应于15种报表的字段设计表15张。

3) 报表数据表： 对应于15种报表具体存储企业财务信息的数据表15张。

5.3 系统实现

系统的开发是基于JavaTMEE的，J2EE1.4新增加的技术大部分和Web服务相关。在J2EE 1.4平台下，开发、部署、发现Web服务变得非常方便。J2EE平台的优点(可扩展性、可靠性、开放性)尤其适用于Web服务的开发。因此本系统采用了J2EE平台来开发。

Web服务可以使用(WSDL )Web服务描述语言)定义，也可以使用Java接口定义。在定义Web服务时，同时定义出Web服务的端点接口(Endpoint Interface )，服务端点接口是一个由JAX-RPC规范指定的Java接口，这个接口扩展javax.rmi.Remote接口，这个接口使用Java编程语言编写。

public interface CertService extends Remote

{

/*返回用户提供的信息。*/

public String cent (String Scert) throws RemoteException;

}

6 结束语

本系统是基于J2EE与WebService技术的大型物流信息管理系统，通过使用以上技术实现了松耦合系统架构，用户身份认证的安全可靠性，提高了软件的开发效率和开发质量.

参考文献：

[1] Ball J,Carson D,Evans I,et al.The JavaTM EE 5 Tutorial[Z].Sun Microsystems,Inc.

[2] Alur D,Malks D,Crupi J,et al.Core J2EE Patterns - Best Practices and Design Strategies[Z].

[3] Designing Enterprise Applications With the Java 2 Platform[M].Enterprise Edition Copyrignt Sun Microsystems,Inc.

[4] Erich G, Richard H,Ralph J,John V.设计模式[M].李英军,马晓星,蔡敏,刘建中,等,译.北京:机械工业出版社,2004.

soap协议篇8

关键词：Web Services；金融风险预警；决策支持

中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)22-703-02

Research of Financial Risk Early Warning System Based on Web Services

YANG Xin-quan

(Computer and Information Engineering Department,Heze University,Heze 274015,China)

Abstract：Web Services is a service-oriented architecture , whose advantage is the inter-operation and platform independence ,and soft-ware reused. Financial risk early warning system is a decision support System used by financial decision-making departments. In this paper, the architecture and key technologies is discussed, propose an financial risk early warning System framework based on Web Service, and provides strong technical sup-port to the system.

Key words: Web Service; financial risk early warning; decision-making

1 引言

金融风险预警，是对宏观金融运行情况进行总体的、综合的、全面的、系统的分析与判断，是对表征宏观金融运行现状的一系列指标进行的监督和量测。Web Services是近几年提出的一种新的面向服务的体系结构，能较好的满足Internet环境下松散耦合、跨平台、与具体实现语言无关等要求。开发一套基于Web Services的金融风险预警系统，不仅符合当代系统集成的发展趋势，而且有利于金融决策部门做出正确的决策。

21世纪初期，Web Services获得了巨大的发展，许多软件公司纷纷宣布了对Web Services的支持和应用，许多组织参与了Web Services标准的完善。Web Services的出现，为我们解决现代企业级应用带来了契机：Web Services是在Internet上进行分布式计算的基本构造块，开放的标准以及用户和应用程序之间的通信协作产生了一种新的环境，在这种环境下，Web Services成为应用集成的平台；应用程序通过使用多个不同来源的Web服务构造而成，不管这些服务到底位于何处或者如何实现，它们都可以互相协同工作。将Web Services技术结合到金融风险预警系统中，必然会进一步提高金融风险预警系统的性能和效率，解决金融风险预警系统在应用中所面临的诸多问题，随着Web Services技术的发展，可以预测，基于Web Services的金融风险预警系统将成为未来金融决策部门金融管理的更有效的手段。

2 Web Service技术

Web Service特指用Web服务描述语言（Web Service Description Language，WSDL）描述的、通过HTTP发送的、处理XML编码的SOAP消息的分布式服务架构（也可称作Web服务）。Web Service技术主要包括XML、SOAP、WSDL、UDDI等技术。SOAP是一种以XML为基础的信息传送协议,利用该协议并借助HTTP协议就可以调用特定程序中提供的功能。WSDL是用于描述Web服务功能的抽象化描述语言。UDDI是一项有关Web服务在网络上如何进行注册、如何查询服务的规范。Web Service的架构如图1所示。

Web Services中涉及两个部分：服务本身和对服务的描述。典型的应用过程是：服务提供者也就是最终的Web Services提供商，他开发提供一系列特定的通过网络可以被访问的软件资源的服务接口，然后将服务的描述注册到服务注册中心或者发送给服务请求者。服务请求者可看作是一个网络节点，他通过查找动作在本地或服务注册中心检索服务描述，找到后，通过绑定就可以使用该项服务。

服务注册中心是帮助查找Web Services的地方，也可以理解成一个Web Services的注册地，在这里汇集了大量的在线的Web Services。一般由服务提供者来将他的各种服务到注册中心，目前服务注册中心就是UDDI商业注册中心。

这三个角色是根据逻辑关系划分的，在实际应用中，角色之间很可能有交叉，一个Web Services角色既可以是Web Services提供者，也可以是Web Services请求者，或者二者兼有。这三个角色通过三个基本操作：、查找、绑定来相互作用。服务提供者向服务注册中心服务，服务请求者通过服务注册中心查找所申请的服务，并绑定到这些服务上。

3 基于Web Services实现本系统的优势

由于B/S构架的发展，基于Web的组件技术如：Sun的EJB, Microsoft的DCOM以及OMG（Object Manage Group）的CORBA也迅速发展起来。但是这些技术在实际应用中，存在着很多不足，如它们特定的协议难以通过防火墙，相互调用比较困难。

以应用较为广泛并提供了比较完善的异构平台中不同应用程序通信的解决方案的CORBA为主要代表来与Web Services进行比较：

1)CORBA使分布式的、面向对象的应用之间的连接通信成为可能，不管应用安装在何种平台上，但这些功能需要以额外的开销为代价。并且CORBA非常难于开发和部署，对于较小的工程而言，CORBA在代码开发上所需要的额外费用和努力通常低于其性能好处。这大大限制了CORBA大规模的应用。Web Services是新的分布式计算的实现方案，可以让程序员在任何平台下用任何自己熟悉的语言开发服务，其分布式服务的开发和部署过程都比较简单。

2)CORBA一直比较难与防火墙一起工作，其通讯的IIOP（Internet Inter-ORB Protocol）协议的实现以厂商的不同而不同，所以常常被挡在防火墙外面。Web Service体系中用SOAP通信，而SOAP一般建立在HTTP协议上，可顺利通过防火墙工作，方便了企业间实现应用集成。