SOAP技术

SOAP技术（共7篇）

SOAP技术 篇1

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服务的进行读取与处理,即可实现对服务使用者的身份验证。在此,以ASP NET Web服务为例,说明基于SOAP头的Web服务身份验证技术。

3.1 基本步骤

ASP.NET 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)将My ASHeader赋给MyAService.AuthSoapHeaderValue(即设置SOAP头条目),并调用Web服务的有关方法以完成相应的功能。

3.2 应用示例

如图3所示,为一系统登录表单,用于对系统用户进行身份验证,其验证过程是通过调用Web服务完成的,而用户名与密码则通过SOAP头进行传送。为简单起见,该示例假定用户名与密码均非空串时即为合法。单击“确定”按钮后,若为合法用户,则提示信息显示为“Success”,否则为“Failure”。下面,简述该示例的设计要点。

1)Web服务AuthService的设计

在Visual Studio.NET中使用ASP.NET Web服务模板新建一个Visual C#项目AuthService,并将Service1.asmx重命名为Authentication.asmx,然后在Authentication.asmx.cs中编写相应的代码。关键代码如下:

2)客户端Login.aspx的设计

(1)在Visual Studio.NET中使用ASP.NET Web应用程序模板新建一个Visual C#项目AuthClient。

(2)添加对Web服务AuthService的Web引用,并命名为Authentication。

(3)将WebForm1.aspx重命名为Login.aspx,同时设计好其界面(如图3所示),主要包括用户名文本框TB_Username、密码文本框TB_Password、提示信息标签L_Message与“确定”按钮。

(4)为Login.aspx.cs添加功能代码。

首先,引用命名空间AuthClient.Authentication:

using AuthClient.Authentication;

然后,编写“确定”按钮的单击事件代码:

4 结束语

SOAP头为Web服务及其客户端之间关键数据的传递提供了一种灵活且有效的途径,有利于实现身份验证、事务处理等特殊功能。文中所述,即为利用SOAP头对Web服务使用者进行身份验证的关键技术与与典型模式。

摘要：介绍基于SOAP头的Web服务身份验证技术,并通过具体示例说明在.NET平台下的编程模式。

关键词：Web服务,SOAP头,身份验证,ASP.NE,C#

参考文献

[1]石国志..NET Web服务实用案例教程[M].北京:清华大学出版社,2004.

[2]佛里曼,琼斯.Microsoft.NET XML Web服务程序设计[M].向璐,向祚铁,译.北京:清华大学出版社,2003.

浅析SOAP协议信息系统 篇2

不同平台之间实现互操作的传统做法是用各自的二进制代码进行转换,例如通过编写Java 应用程序可以实现使用RMI 与CORBA 应用进行连接,但与DCOM 却无法通信,因此在数据共享方面造成很大的限制。如何让不同的系统之间能够在Internet上透明地通信,便成为网络集成技术的发展目标。SOAP是一种让不同应用程序之间通过HTTP通讯协议,以XML格式实现消息互换的通用规范,SOAP协议采用的是基XML的消息通信模式,具有与平台无关性、自我描述性和可扩展性,为在松散的分布式环境中对等地交换结构化和类型化的信息提供了一个简单的轻量级机制。

简单对象访问协议SOAP以XML形式提供了一个简单、轻量的用于分散或分布环境中交换结构化和类型化信息的机制。SOAP协议本身并没有定义任何应用程序语义,如编程模型或特定语义的实现,而是通过提供打包模块和编码模块来对数据进行封装和编码,即定义了一个简单的表示应用程序语义的机制。SOAP能够用于从消息传递到RPC机制的各种系统中。SOAP协议包括SOAP封装(Envelop)、SOAP编码规则(Encoding Rules)、SOAP RPC表示(RPC Representation)和SOAP绑定(SOAP Banding)。这4个部分在功能上是独立的模块,其中SOAP封装和SOAP编码规则是在不同的命名空间中定义的,这种模块化的定义保证了SOAP的简单性。SOAP的主要设计目标是简单性和可扩展性,因此它放弃了传统的消息系统和分布对象系统的某些特性。这些特性包括:分布式碎片收集、消息的成批传送、对象引用和激活机制。

1 SOAP体系架构

SOAP 是在分布式环境中交换信息的简单协议,SOAP协议定义了一套客户端和服务器之间传输命令和参数的机制,适用于各种平台,与所使用的编程语言及目标模型所在的位置无关。下面针对SOAP消息和SOAP协议系统框架分别加以分析。

1.1 SOAP消息

SOAP的消息结构是以SOAP信封(SOAP Envelope)为根元素,内含SOAP头(SOAP Header) 和SOAP体(SOAP Body)子元素的一个XML文档,SOAP头和SOAP体则有若干SOAP块(SOAP Block)子元素组成。

SOAP信封是表示该消息的XML文档的顶层元素,元素名为Envelope。该元素必须在SOAP消息中出现,一般是根元素,并且Envelope的直接子元素Header和Body必须排列在最前面。SOAP头元素为SOAP信封元素的第一个直接子元素,元素名为Header。该元素可以在SOAP消息中出现,但并不是必须出现。如果出现,SOAP头元素必须是SOAP信封元素的第一个直接子元素。SOAP体元素名为Header,提供一个简单的用于与消息的最终接收者交换信息的机制。SOAP体元素必须在SOAP消息中出现,同时必须是SOAP信封元素的一个直接子元素。如果有SOAP头元素,SOAP体元素必须直接跟在SOA P 头元素之后,否则就必须是SOAP信封的第一个元素。

SOAP消息常以请求/应答的方式实现从发送方到接收方的单向传送过程,可以开发以HTTP应答的方式进行SOAP消息传输,并使用同一个连接返回请求。SOAP消息通过采用“消息路径”发送的方式,使在终节点之外的任何一个中间节点均可以处理消息。

SOAP应用程序处理接收消息顺序如下:第1步,通过HTTP协议或其他网络协议接收SOAP消息;第2步,识别应用程序需要的SOAP消息的所有部分;第3步,检验应用程序是否支持第2步中识别的部分,若支持,则处理此部分消息,若不支持,则丢弃此部分消息。在不影响处理结果的情况下,处理器可能忽略第2步中识别出的部分消息。如果这个SOAP应用程序不是消息的最终目的地,则在转发消息之前删除第2步中识别出来的所有部分。

1.2 SOAP系统框架

基于SOAP技术的系统框架可分为服务层、中间层、接口层和应用层4个层次,如图1所示。

① 服务层:

由数据库服务和应用服务组成。数据库服务提供业务所需数据,应用服务提供所有业务规则的实现;

② 中间层:

面向数据库服务和应用服务,用XML对数据进行包装,用SOAP封装应用服务,屏蔽掉具体数据源和服务组件之间的差异,并对用户提出的数据请求进行响应,对用户的服务应用请求进行转发;

③ 接口层:

提供数据库服务与应用服务的访问接口。SOAP请求是SOAP客户端向SOAP服务器端发出的请求。该请求是一个用SOAP包络进行封装的XML格式的字符串。SOAP响应是SOAP服务器向SOAP客户端发出的回应。采用统一XML与SOAP技术的优点在于标准化,将各种不同的服务以标准化的接口提供给用户,从而客户端的开发无需考虑平台和系统的差异;

④ 应用层:

即用户界面层,根据具体的应用和用户计算环境,访问数据服务和应用服务,如Windows应用、Java应用和Unix应用等。

2 基于SOAP协议系统实现方法

根据SOAP系统框架,可以将SOAP系统划分为SOAP服务、SOAP客户和应用客户3部分,如图2所示。其中SOAP系统框架的中间层和服务层由SOAP服务实现,提供SOAP消息处理服务和数据库服务;SOAP系统框架的接口层由SOAP客户实现,负责接收应用客户提交的请求,然后交予SOAP服务层处理,最后接收SOAP服务层的处理结果并返回应用客户进行显示;SOAP系统框架的应用层则由应用客户实现,通常应用客户为Windows、Unix等各类型操作系统提供的WEB浏览器,如Internet Explorer、Netscape、FireFox和Opera等,这里不再详细介绍。

2.1 SOAP服务

SOAP服务的任务是接收SOAP客户发送的数据并检验其正确性,然后对其做相应的数据计算处理。如果数据正确,服务器还要向客户返回一个包含编号的文档。

第1步:从SOAP请求消息Request中读取客户提交的XML文档,从此XML文档中读取包含的<Body>元素至DOMDocument对象;

第2步:在SOAP服务程序中处理SOAP客户发送的数据;

第3步:向客户返回SOAP响应消息。

根据功能SOAP服务可以划分为以下4层:

① 接收SOAP请求并发送响应结果层:由Soap服务组件(asp文件)构成。通过XMLDOM实例对象oSoapXmlDom接收SOAP客户端发来的包含SOAP请求Request的DOMDocument对象,然后用SOAP事务实例对象oSoapUtils执行SOAP请求,最后返回执行结果给SOAP客户端;

oSoapXmlDom.load(Request)

oSoapUtils.ExecuteRequestWrapper(oSoapXmlDom.xml)

② SOAP事务层:由SoapUtilsMts组件构成,该组件只有一个Utils类。SoapUtilsMts组件从绑定文件中得到与SOAP请求方法对应的ProgID等信息,然后根据ProgID信息创建出相应的封装函数的实例对象oObject,并用CallByName函数执行相应的方法,最后将执行结果加上SOAP包络形成SOAP响应;

Set oObject=CreateObject(sProgID,sObjectServer)

CallByName(oObject,sComMethodName,VbMethod)

③ 目标函数层:由SrvKy组件构成。SrvKy组件中的soapWrapper类、facObj类和UtilsObj类分别实现目标函数封装、目标函数接口和目标函数处理方法3个主要功能,针对每个SOAP请求方法编写相应的处理函数或方法,因其实现的代码较多,这里不再列举;

④ 数据访问层:由KyDataAccess组件构成。由KyDataAccess组件的DataService类实现服务层数据访问功能。

2.2 SOAP客户

SOAP客户的任务是将SOAP请求数据发送给SOAP服务。客户端的实现涉及到2个功能:① 与服务器建立连接并发送数据;② 以下根据SOAP协议的规定格式化一个文档样式和字面格式的SOAP请求消息。根据功能可以将SOAP客户划分为以下4层:

① IIS层:由ASP页面文件构成。负责接收由应用客户浏览器发出的请求,创建出SOAP请求的外观层的实例对象,并把任务转交给此对象;

② SOAP 请求外观层:由facKyWeb组件构成。实现SOAP请求的外观层,是基于Windows DNA思想设置,目的是从业务服务层的复杂性中孤立出与客户端联系紧密的部分,使客户端的开发工作更容易。在设计初期提供测试代码;

set oWebfac=server.createobject (“facKyWeb.Utils")

oWebfac.getFunc1()

③ SOAP 请求主业务层:由KyWebTx组件构成。是SOAP 客户端的主要部分,负责将执行任务转交给SOAP请求的主业务层。以下代码为创建SOAP请求的主业务层对象oWebTx,并将执行任务转交给oWebTx;

Set oWebTx=CreateObject (“KyWebTx.WebTrans")

oWebTx.getFunc1()

④ 发送SOAP 请求并接收响应结果层:由SoapRequestMts组件构成。负责发送SOAP请求消息Request至SOAP服务器并接收SOAP服务器返回的响应结果。该组件只有一个名为XMLHttp的类。它把上一层传来的SOAP请求载入DOMDocument实例对象oDom,然后用XMLHTTPRequest实例对象oHttp通过HTTP协议将oDOM发到SOAP服务器端,并接收SOAP服务器端返回的响应结果,主要函数是PostRequest ()。

oDOM.loadXML(sSoapPayload)

oHttp.open “POST",mSoapServer,False

oHttp.setRequestHeader “SOAPMethodName:",

msTransactionNamespace &″# ″&sMethodNameo

3 结束语

SOAP以XML 形式提供了一个简单、轻便的用于在分散或分布环境中交换结构化和类型化信息的机制。SOAP采用了现有的2种成熟的协议HTTP和XML,HTTP用于实现SOAP客户端与SOAP服务器端的通信,而XML 是它的编码模式。从底层开始,SOAP的设计目标就是使之成为一种非常简单的协议,能够以各种不同的方式满足各种不同的需求,它突破了DCOM只能用于DCOM系统、CORBA只能用于CORBA系统的局限性。基于SOAP的系统开发方法使应用程序开发技术正发生着一次质的飞跃,从根本上大幅度提高开发人员的开发效率,开启了一道通向全新概念的应用程序的大门。

参考文献

[1]SNELLJ.SOAP Web服务开发[M].北京:中国电力出版社,2003.

[2]顾宁.Web Services原理与研究实践[M].北京:机械工业出版社,2006.

[3]孙冬冬.基于XML、SOAP的企业应用集成技术[J].计算机工程与应用,2003,40(31):205-207.

[4]施明辉,孙荣胜.用基于XML的SOAP机制构建应用系统[J].计算机应用,2002,22(2):80-83.

SOAP技术 篇3

WebServices的主要目标是方便各种应用的集成,可以是公司网络中企业应用集成的一种简单形式,也可以是不同公司之间,甚至同一公司不同部门之间B 2B(BusinesstoBusiness)应用形式。作为一种分布式软件应用,WebServices可以让公司在商业机构、顾客、合伙人以及供应商之间方便地交换数据和共享服务。更多应用和资源的集成意味着比以前更加暴露出安全问题,面临的安全威胁也就更加显著。已经存在的安全技术,比如包过滤和传输层安全不能够很好地应用在WebServices的分布式环境中,因此WebServices的安全将面临巨大的挑战。首先,WebServices依赖于建立在HTTP(S)基础之上的SOAP,而HTTP(S)采用的边界安全机制(防火墙)在SOAP/HTTP信息被允许通过域边界的情况下很容易被绕过。第二,像SSL等基于连接的安全机制也不能提供有效的安全保护,它们仅提供点到点的安全保护,而在信息经过多个中间节点的环境中不能提供端到端的安全。在这种情况下,提出了用SOAP网关来实现WebServices安全的技术,并通过研究和例证,初步达到了较理想的性能效果。

1 WebServices规范与标准

目前对于WebServices没有统一的定义,从狭义的角度来看,WebServices是由URI(Uniform ResourceI-dentifier)标识的一个软件应用,其接口和绑定可以通过XML文档定义、描述和发现,它使用基于XML的消息通过互联网协议与其它软件之间直接交互。即使理论上可以使用其它传输协议用来传输XML信息,但目前大家公认WebServices信息传递的事实标准是SOAP[2]。WebServices模型基于3种角色(服务提供者、服务注册中心和服务请求者)之间的交互,如图1所示。服务提供者提供Web服务、定义服务描述并将服务发布到服务注册中心,服务请求者使用查找操作从服务中心查找服务描述,然后使用服务描述与服务提供者进行绑定并调用Web服务。

图2说明了WS-Security怎样集成SOAP、HTTP和SSL以及怎样跟XML签名和加密相关联。该图描述了一个SOAP信息传递的概念结构,它建立在一个或多个HTTP连接之上,经过了发送者(Sender)、中间节点(intermediaries)、和SOAP信息的最终接受者(Receiver)。SOAP信息传递层次没有提供任何安全机制。在下面传输层已经存在的安全技术,比如SSL/TLS。它们能够对传输中的数据提供公钥加密鉴定、确保数据的机密性和完整性。但是,SSL/TLS仅提供直接通信双方之间的安全,比如点到点的传输。SSL应用于Web Services的主要不足有:(1)SSL仅提供点到点安全,而WebServices需要端到端安全,而端到端之间可能存在大量的中间节点,也存在大量基于XML的信息交互,SSL无法为其提供安全服务;(2)SSL在传输层级提供安全,而WebServices需要“消息级”的安全。使用SSL可以在消息传输过程中提供安全保障,但它无法确保消息后续传输的安全性。此外,由于SSL只提供传输级安全性,因此它无法实现XML文档在交互时元素级别的签名和加密;(3)SSL不能提供端到端的服务请求和响应交易的不可抵赖性。

正因为在SOAP下面的传输协议层不能够提供端到端的消息保护机制,因此该安全要不在应用层级实现,要不由SOAP层的中间件来提供。为了适应大量应用的需求,WS-Security规范为SOAP推荐了一种基于消息的安全模型[3]。WS-Security规范明确规定了在各种应用环境中提供端到端消息安全所需要的条件。从技术上来说,通过安全消息头格式的定义来达到安全的目的,因此每个消息都要能够包含所有关于它自己的安全问题以便于做出安全决策[4]。WS-Security规范也为另外一些安全标准定义了处理规则,比如XML数字签名、XML加密和安全声明语言SAML(Securityassertionmarkuplanguage),它们通过在安全头部插入安全性令牌来确保部分或全部SOAP消息安全。SAML是用于在域间交换授权和认证信息的标准,它使用XML来编码和传输域认证授权有关的信息。XML数字签名是定义如何对一个XML文件的部分或全部内容进行数字签名,以保证数据的完整性。XML加密使用事先约定的对称密钥,对一个XML文件的部分或全部进行加密,XML加密对于Web服务质量最重要的意义在于,XML加密可以选择性的加密SOAP消息的部分内容。

2 基于SOAP网关的WebServices安全模型

要实现上面所提到的安全并不是任何技术都能够做到的。为此,一种确保安全的直接的方法就是为应用程序开发者提供链接库,以便于应用软件通过编程来执行安全控制。比如,微软在其VisualStudio.NET环境里集成WebServicesEnhancement作为安全扩展[5]。然而,这种加强安全性的方法增加了应用程序开发人员的负担,而不是重点放在安全体系结构和安全管理人员身上,这样的话需要开发人员具备大量的专业知识。

这种集成了安全服务的链接库可以由服务器端的应用服务器产品来提供。服务器管理员通过对应用服务器进行安全策略的配置来提高安全性,这也有赖于客户端应用程序在安全体系结构中以适当的格式提供安全信任信息。这样客户端工具必须要选择合适的安全库来创建(也可以从第三方获得)和插入SAML断言[6],SAML为即将发出的消息插入鉴别声明。如果一个应用程序包含了配置在多个不同类型的应用服务器上的服务时,这些平台将不得不单独管理,不同平台使用的管理体系可能不同,加大了管理的难度。

为此,我们提出了一种基于SOAP网关的WebServices安全模型(WebServicesSecurityModelBasedon SOAPGateway,简写为WSS-SG),它在应用层级上使用SOAP安全网关来确保WebServices的安全,该方法克服了上面所述的缺点并只需要简单配置。SOAP安全网关能够容易地集成到现有的WebServices体系结构中,并不需要改变现有的应用程序。在应用层级上能够执行XML合法性确认和内容过滤等安全检查,这在传输层级是办不到的。除此之外,SOAP安全网关还提供了典型的应用层安全功能,比如基于角色的访问控制和审计等。像SAML等基于开放标准的组件能够跟企业的其他安全产品进行数据、信息和服务等交互。

跟其他应用层级的协议(如IIOP、SMTP、HTTP等)一样,SOAP安全网关并不是要取代已经存在的包过滤技术。包过滤技术要设置好允许相关通信量经过这些安全网关,这些通信量是根据应用层级策略进行分析和限制后取得信任的部分。

由应用服务器或SOAP工具箱提供的基于库的解决方案的主要优点是减少了管理域的过载。一个SOAP安全网关组件能够作为一个中心组件来进行管理,该方法适合简化配置和集成度,并帮助建立统一的安全管理策略。当有大量不同服务器平台时这个优势会变得更加明显。

客户端的安全管理或者分布式的信任关系将分散管理的强度,但是在客户端配置SOAP网关后可以减少这种管理的强度。这样的网关可以放置在客户端应用程序的信任域内并将SAML断言和数字签名等安全信息嵌入到即将发送出去的信息中,并转换成XML文档格式,如图3所示。

这种安全信息创建和嵌入到消息中的方法在B 2B应用中能发挥出最大的优势,B 2B应用中的合伙人互相之间并不需要完全信任就可以合作。在大型生产厂家以及不同企业之间存在有大量的依赖于不同技术和标准(比如程序设计语言、服务器架构、用户管理等等)的IT基础设施。为了跟每个合作者交互,所有客户端软件都得重新修改并发布新的信任关系,这将变得异常复杂和昂贵。而在上述提到的设置中,集中控制的安全网关将能鉴别客户端、产生新的信任域并将这些添加到外出消息中,这样不再需要任何软件的修改也不需要信任域的重新发布而能够带来巨大的效益。

3 模型的实现

我们在实验室模拟了上述安全模型,并取得了较好的效果。图4描述了该方案的体系结构,WSS-SG包含了三个组件,分别放置在网络的不同网段。网关组件是安全执行机制,放置在非军事区,因此它能够被内网或外网直接访问。图5描述了WSS-SG的三个主要应用配置,即intranet、Internet和extranet。

网关执行两个主要安全功能,即信息鉴别和授权(即访问控制)。另外,网关还需验证包含在信息头部的XML数字签名以确保信息的完整性,并且执行XML计划确认来确保信息内容是期望接受的。这个作用能够用来阻挡应用层级攻击,比如SQL攻击。最后,网关为安全威胁事件发出告示作为审计用途,也可以创建SAML断言添加到外出消息。

为了做出安全决策,网关会向策略服务器询问策略信息。安全策略服务器用来配置网关组件并保存安全策略。它是整个安全模型中高度敏感的部分:假如攻击者威胁到策略服务器的安全,重新配置网关或操纵策略库,这样对受到网关保护的资源来说再也没有安全可言。因此强烈建议不要将安全服务器配置在DMZ区域而应放置在受到更多限制的网络区域。

安全策略服务器对来自网关的策略请求进行响应并接受事件通告作为审计用途。用户、团体、角色信息跟访问和审计策略一样存储在策略服务器的文件中,或者存储在远程LDAP知识库里。最后按Java方式执行的管理控制台提供给管理员强大而便利的用户接口来管理这个安全体系结构。管理控制台可以显示配置和策略信息,并显示事件告示。GUI(GraphicsUserInterface,简写为GUI)通过WSDL描述的引入也能支持安全WebServices显示出来[7]。为了通过这种方式导入相关服务,管理控制台必须从WSDL描述中摘录安全策略信息,这得由管理员重新进行配置。在导入包含由网关地址取代原始地址等信息的过程中WSDL描述将会被修改,因此从网关获取有关WSDL安全服务的客户端将自动接收到“下一网关”寻址信息。管理控制台依赖安全CORBA传输协议(IIOPoverSSL)来跟安全策略服务器进行通信。安全服务器使用同样的传输协议跟WSS-SG网关进行对话。

4 SOAP网关的实现

4.1 XML防火墙

SOAP网关可以通过XML防火墙技术来实现。作为网络防火墙的补充,XML防火墙能够保证XML消息数据流的安全。XML防火墙封装了对所有暴露的服务端点和WSDL描述的访问,位于DMZ环境中以支持XML的网络防火墙或中间代理的方式运行。XML防火墙技术通过使用SSL/TLS、集中的安全机制和保护底层服务端点安全的访问控制来实施安全通信,从而成为所有进出站XML数据流的安全入口。

4.2 Web代理

Web代理以Web服务器或应用服务器上的一个可插入模块作为安全中介,用来保护对暴露的服务端点和WSDL描述的访问,Web服务器或应用服务器在DMZ环境中的堡垒主机上运行。Web代理与管理身份信息和访问控制策略的底层安全提供者基础设施进行交互。它拦截所有进站的服务请求和出站的响应,为所有暴露的服务端点集中实施访问控制和策略规则,从而为Web服务端点提供一个安全层。Web代理方法使用软件接口来支持安全控制,这通常需要占用大量的资源并导致处理开销,还会影响模型性能。结合使用XML防火墙和Web代理方法,有助于实现高性能和高可用性目标,尤其是在需要处理大量连接、二进制安全令牌和大型消息时。两种实现方法均应提供下列支持和服务:确保XMLSOAP消息定义良好、验证XMLSOAP模式、对内容进行病毒过滤、过滤不符合标准的消息、识别和验证用户认证令牌、对XMLSOAP消息进行数字签名和验证签名、对XMLSOAP消息进行加密和解密、实施基于XML的访问控制策略、保护WS-DL、日志和审计、支持标准的安全互操作性,以及确保符合WebServices相关的安全规范,如XML数字签名、XML数字加密、Web服务安全规范、SAML安全断言标准语言、可扩展访问控制标记语言等。

5 结束语

本文概述了由WebServices所引起的安全挑战并介绍了该领域即将或正在出现的重要标准和规范。着重讨论了基于SOAP安全网关的WebServices模型的工作原理和体现出来的优点,最后通过一个具体的实例来验证该方法的可行性。但目前仍然停留在实验阶段,下一步要做的工作将是怎么将该模型进一步推进到实际运行环境中。

摘要：研究了SOAP、WS-Security和其他相关规范集的安全模型,提出了一个基于SOAP网关的Web Services安全模型,通过模拟实验较好地实现了该模型的部分功能,能够提高Web Services应用的安全性能。

关键词：Web Services,SOAP,安全,网关

参考文献

[1]Ardagna C,Damiani E,Samarati P,et al.A Web Service Architecture for Enforcing Access Control Policies.Electronic Notes in Theoretical Computer Science,2006,142(1):47262

[2]W3C.Simple object access protocol,version1.1.W3C Note,http://www.w3.org/TR/SOAP,May2000.

[3]OASIS.Web services security:SOAP message security.OASIS TC Working Draft10,Feb.2003.

[4]刘振鹏,周冬冬,薛林雁,常晓萌,宋晓静.一个基于SOAP消息的Web服务综合安全模型.武汉大学学报,2006年,52(5):570～573

[5]Microsoft.Web services enhancements.http://msdn.microsoft.com/webservices/building/wse/default.aspx.

[6]OASIS.Assertions and protocol for the OASIS Security Assertion Markup Language.Committee Specification,May2003.

SOAP技术 篇4

随着电网商业化运营的深入开展和电网规模的扩大,电力系统的信息发布需求水平也越来越高,各方对于信息需求越来越迫切。目前的SCADA/EMS系统在实际应用中缺乏标准数据库和应用程序接口,系统扩展性较差,制约了与其他系统的数据共享和集成,而且缺乏便利的信息发布系统[1]。在通常情况下,只有少数调度、运行端电脑控制平台可以访问和调用地调所使用的SCADA/EMS系统中的数据库。同时,调度、运行端电脑控制平台必须配置专门的接收软件才能浏览从厂站端传递来的数据,而异构系统很难直接访问SCADA/EMS系统中的数据[2]。这样就使得客户端对象单一且数量有限。如今,电力市场不断发展,迫切要求电力系统中的一些数据对外开放,并且随着计算机网络技术的快速发展,电力系统中的管理人员和一些电力用户也要求能够通过网络快速、便捷地了解到电力系统中的信息。这样就会使客户端对象类型多样化且数量巨大,服务对象除了调度员外还有电力系统中的管理人员和电力用户等。同时,电力企业管理信息系统之间存在着特殊性和地域分散性,并且运行于不同平台、采用的开发语言以及数据格式也不同,系统之间不能兼容,形成企业中的“信息孤岛”,企业之间难以信息共享。如果在客户端再要求安装相应的接收软件才能浏览厂站中的数据,不仅会给用户带来很大的不便,还会造成资源的浪费。鉴于客户端数量巨大,不可能也没有必要把变电站的信息实时地传输到每个客户端,变电站只需把除了调度中心以外的其他客户端需要的信息准实时的传输即可。要达到这个目的,首先需要解决的是如何实现在电力系统中的不同平台、不同开发语言的各服务端和客户端之间信息传输的问题。而当前流行的Web Service技术可以很好地解决这个问题。Web Service只要求在客户端有浏览器即可使用户能够很方便地浏览电力系统中提供的数据,还能实现异构系统之间的数据共享。在Web Service中,所有主要供应商都支持SOAP(简单对象访问协议,Simple Object Access Protocol)这一新标准协议[3]。因此,完全可以利用SOAP来传输电力系统信息。

1 电力系统信息的XML(可扩展标记语言,Extensible Markup Language)描述

1.1 XML技术的引入

SOAP是一个轻型的通信协议,它是在分散或分布式环境中进行信息交换的简单协议。SOAP不是通过特定的协议来调用方法,而是使用一种开放性的语法来进行描述,这种语法就是成熟的XML技术。SOAP通常使用HTTP协议作为传输载体,因为这种网络协议为大多数操作系统所支持,所以使用这种方法可以方便地进行通信。因此可以简单的理解为SOAP=HTTP+XML。也就是说,在利用SOAP协议进行电力系统信息传输时,传输的信息是XML格式,这就要求首先要对电力系统信息进行XML描述。

1.2 电力系统信息的XML描述

在进行电力信息的XML描述时,首先要制定出XML文档模式。制定XML文档模式的方法有两种:DTD(文档类型定义)和W3C定义的XML Schema。和DTD相比,Schema有一致性、互换性、扩展性、规范性和易用性等优点,所以本文采用XML Schema文档模式[4]。

下面以变压器为例,介绍XML Schema文档模式的制定及XML描述,其他设备与此类似,只是其中的变量有所不同,在此不在赘述。

先建一个简单的变电站树模型,如图1所示。

图1所示的变电站树模型可分为三层:变电站(Substation)为第一层;变压器(Transformer)、断路器(Breaker)、电容器(Capacitor)、电抗器(Reactor)、母线(Busbar)、线路(Circuit)、隔离开关(Disconnector)为第二层;第二层中所有元素所包含的子元素为第三层。

XML Schema本身就是一个XML文档,故第一步要进行XML类型声明,内容包括版本、编码形式,类型声明为:。

第二步是Schema声明语句,包含Schema名称空间声明。

第三步是声明一个元素名为Substation的用户自定义的复杂数据类型,并通过嵌入复杂数据类型的定义实现用户自定义的复杂数据类型。Substation元素中包括Transformer子元素且声明了它的出现次数必须至少为一次。如下所示:

第四步是声明一个Transformer元素,在此元素内部也嵌入了复杂数据类型的定义。此过程与第三步相似,此处不再介绍。

最后,是各个独立子元素的声明,如下所示:

引用Schema的XML文档Substation.xml如下:

2 构建基于SOAP协议的电力系统信息传输模型

引入SOAP协议后的电力系统信息传输模型如图2所示,该模型可以分为三层。

(1)系统服务层

这一层将具体的功能按照Web服务的方式封装,当客户端调用服务的时候,就执行相应的操作,与数据库进行通信,并把结果以SOAP格式返回给客户端。如果用户没有通过身份认证,则直接返回错误信息;反之,则进行相应的操作,并将处理结果封装成符合SOAP格式的消息返回给客户端。

(2)数据库层

数据库层存放电力系统信息,本文采用Native-XML的SQL数据库。数据库层接收来自系统服务层的各种请求,对请求进行相应的处理,得到处理结果,并将处理结果传送给Web服务。

(3)客户端层

客户端负责响应用户的请求,对请求命令以符合SOAP协议的格式调用服务器端的Web服务。在服务器返回处理结果后,如果服务器返回的结果是状态,则直接处理;如果返回的是格式化数据,则需要经过格式转化处理,把XML格式的电力数据转化为便于显示的HTML格式。

和传统的客户机/服务器模型不同,SOAP/Web浏览器模型不需要在客户机上安装特有的客户应用程序,而可采用标准的浏览器软件来查看基于HTML语言的网页[5]。客户端只是提出请求,所有的响应都在服务器端完成,只需在服务器端进行系统维护即可,客户端无须任何维护,大大降低了系统的工作量。这就是所谓的“瘦客户”或者“零客户”模式,这种方式无疑能为信息检索、查询等服务提供很大方便。

基于SOAP协议的电力系统信息传输的工作方式可以被理解为请求/响应系列。服务器提供的服务可以抽象为若干命令,每一条命令可以完成特定的功能操作。客户端生成命令请求,并以符合SOAP协议的格式调用服务端的Web服务,同时客户端还要处理服务端返回的信息;服务端将具体的功能按照服务的方式封装,当被客户端调用时,就调用电力系统信息应用服务器执行响应操作,并把结果或者状态信息返回给客户端。

3 基于SOAP的电力系统信息传输的实现

3.1 软件的选择

本文选用Windows XP操作系统,利用Java语言进行编程实现。

首先需要安装JDK,本文选用的版本是j2sdk1.4.2.13。

其次,选用Apache SOAP 2.3.1作为SOAP服务器。随着SOAP的逐渐升温,许多大的厂商相继发布了支持SOAP的软件,而Apache SOAP是最著名的、也是实现了最多SOAP协议特性的Java实现。Apache SOAP 2.3.1是当前最新稳定版本,支持通过HTTP和SMTP传输SOAP消息,是目前比较理想的SOAP服务器[6]。

最后,选择Tomcat充当Apache SOAP应用的容器。而Apache SOAP应用充当SOAP服务的容器,Apache SOAP客户程序可以通过Apache SOAP API来发出RPC请求,访问SOAP服务,这些软件组件的关系见图3。

除了上面介绍的软件之外,数据库选择了Native-XML的SQL数据库,此数据库支持XML文档格式。

3.2 信息传输的实现

利用上述软件搭建并部署好服务器后,就可以进行信息的传输了。传输过程简单地说包括两个方面:一是SOAP客户端发出SOAP请求;二是SOAP服务器接收和响应SOAP请求。本文以客户端向服务器请求得到变压器的信息为例进行说明。

3.2.1 SOAP客户端发出SOAP请求

SOAP客户端向SOAP服务端发出的请求是一个用SOAP封套进行封装的XML格式的字符串。在客户端,Web浏览器创建一个请求并发送到SOAP服务器。这些请求以纯文本的方式编写,每个请求都有标准的HTTP格式头。在创建SOAP消息时,需要把附加信息添加到这些标准HTTP格式中。

1)SOAP请求头

传递给SOAP服务器的SOAP请求头如下所示:

2)服务器端接收到的SOAP请求的内容

SOAP请求的内容如下所示:

上部分是SOAP请求的封套,对任何SOAP请求都一样,下部分是SOAP请求的主题部分。该示例是请求SOAP服务器执行浏览变压器信息模块的方法Get Transformer,即提取变压器信息的方法。

3.2.2 SOAP服务器接收和响应SOAP请求

SOAP服务器接收到SOAP客户端发来的SOAP请求以后,解析SOAP报文,从SOAP请求中提取出请求的方法(Get Transformer),根据SOAP服务端的绑定文件,找到与SOAP请求相应的信息,将其映射为本地应用服务器上的组件调用,然后调用SOAP应用服务器上真正的应用程序,执行SOAP请求。

1)SOAP服务端的绑定文件

SOAP服务端的绑定文件是一个XML格式的文件。

SOAP服务器的Web Services对象从SOAP客户端发来的请求中解析出SOAP请求方法Get Transformer,然后从绑定文件中获得SOAP请求方法Get Transformer应该在服务名为localhost:80的机器上,由Substation类对象的Get Transformer方法完成。有了这些信息,SOAP服务器上的Web Services对象就可以创建远程对象,根据WSDL文件以及WSML文件,执行SOAP请求。并将执行结果加上SOAP封套信息,形成对上述SOAP请求的SOAP响应。

2)SOAP响应头

第一行包含一个状态码和一个与此状态码相关的信息。这个传输变压器信息的例子中状态码是200,消息是OK,表示请求被成功解码,并返回一个正确的响应。响应头文件如下所示:

3)SOAP响应内容

下面是SOAP服务器执行上述SOAP请求后生成的SOAP响应,也是SOAP客户端接收到的响应消息。消息如下所示:

4)SOAP消息的客户响应

SOAP响应消息被SOAP服务器生成以后,再转给HTTP服务器,由HTTP服务器将其返回给客户端。SOAP客户端接到SOAP响应以后,可以解析出SOAP响应的主体部分,再转换为HTML文档,以Web页面形式显示给用户。此时,客户端就得到了服务器中变压器的信息,完成了整个访问过程。

4 结论

SOAP是在分散或分布式环境中实现信息交换的简单协议,它仅仅定义了如何通过HTTP和XML访问与平台无关的服务、对象和服务器的协议[7]。利用SOAP协议传输电力系统中的信息,可以实现不同平台之间的通信,而且很容易通过防火墙,在接收端也不需要安装特定的接收软件,只要有浏览器即可浏览数据,节约了大量的资金。随着电力系统中客户端的不断增加,利用SOAP协议传输电力系统中的信息是十分有意义的。

参考文献

[1]曹厚继.利用SOAP技术实现电力系统信息的传输[D].保定:华北电力大学,2008.CAO Hou-ji.Realization of power system information transmission based on SOAP[D].Baoding:North China Electric Power University,2008.

[2]Hossenlopp L.Engineering perspectives on IEC61850[J].IEEE Power and Energy Magazine,2007,5(3):45-50.

[3]曾铮,吴明晖,应晶.简单对象访问协议SOAP综述[J].计算机应用研究,2002,19(2):5-8.ZENG Zheng,WU Ming-hui,YING Jing.Summary of simple object access protocol[J].Application Research of Computers,2002,19(2):5-8.

[4]Dave Mercer.XML编程起步[M].袁鹏飞,译.北京:人民邮电出版社,2001.

[5]邓昱,曾文华.SOAP的原理及实现[J].杭州电子工业学院学报,2002,22(3):19-23.DENG Yu,ZENG Wen-hua.Theory and realization of SOAP[J].Journal of Hangzhou Institute of Electronic Engineering,2002,22(3):19-23.

[6]Richard Monson-Haefel.J2EE Web Services[M].崔洪斌,王爱民,译.北京:清华大学出版社,2005.

SOAP技术 篇5

随着移动互联网和智能终端的发展, 企业对办公信息化提出了新的需求, 希望借助移动互联网和智能终端实现内部应用系统的移动信息化, 为企业在激烈的市场竞争中赢得先机。20世纪90年代, 我国相继启动了以金关、金卡和金税为代表的重大信息化应用工程。党的十六大进一步作出了以信息化带动工业化、以工业化促进信息化的战略部署。国家的信息化发展战略为中国移动推动信息化指明了方向。某省移动公司结合自身优势, 为不具备OA、邮件、ERP等信息化系统的客户提供基于移动终端的托管式信息化应用服务, 制定一套可行的行业解决方案, 命名为ADC (Application Data Center, 应用数据中心) 。提供包括企业宣传、移动办公、生产控制等在内的专业服务。

2 ADC系统结构

ADC平台和SI (System Integrator, 系统集成商) 应用系统共同组成ADC系统。通常情况下, ADC平台作为运营平台为中小企业信息化应用提供服务, 进而支撑SI系统的接入、管理和运营, 对外连接行业网关、BOSS, 以及网管系统等。SI为中国移动引入的合作伙伴, 具有成熟的产品及技术能力, 能够提供各种类型的产品及方案。

ADC平台通过业务系统接口层, 实现业务开通关闭、用户授权数据和计费信息同步功能。由于SI应用系统的异构性在业务系统接口层中, 我们采用简单对象访问协议 (Simple Object Access Protocol, SOAP) 实现异构计算机环境下的数据通信和信息共享。

3 SOAP的应用

3.1 SOAP协议

SOAP (Simple Object Access Protocol) , 是简单对象访问协议, 其特点是轻量、简单、基于XML的协议, 通常情况下在WEB上被用于交换结构化和固化的信息。可以和现存的超文本传输协议 (HTTP) 、简单邮件传输协议 (SMTP) 等多种因特网协议和格式进行结合使用。支持从消息系统到远程过程调用 (RPC) 等大量的应用程序。

SOAP协议主要包含:封装、编码规则、RPC三部分。封装描述消息的具体内容, 由谁处理以及是否可选等;编码规则对一种序列化的机制进行了定义, 通过编码将程序对象转换成XML对象;RPC表示执行远程调用 (RPC, Remote Procedure Call) 的约定。三个部分作为SOAP一个整体定义, 在功能上是相交的、彼此独立的。信封和编码规则是被定义在不同的XML命名空间 (namespace) 中, 这样使得定义更加简单。

把SOAP与HTTP进行绑定, 对SOAP的样式和分散的灵活性特点和HTTP丰富的特征库优点进行整合。在HTTP上传送SOAP, 并不是说SOAP对现有的HTTP语义进行覆盖, 而是HTTP上的SOAP语义会映射到HTTP语义上。将HTTP作为协议绑定使用时, RPC与HTTP之间隶属请求与答应的关系。然而, 在RPC上使用SOAP, 一方面不局限于HTTP协议绑定, 另一方面也可以绑定到TCP和UDP协议上。

3.2 接口描述

在ADC系统中, 我们通过采用WSDL (Web Services Description Language, Web服务描述语言) 对接口进行描述。WSDL作为一种XML语言, 主要对Web服务的属性进行定义以及对其进行调用。通常情况下, 一个服务接口和一个服务实现文档共同组成一个完整的WSDL服务描述。通过对Web服务的WSDL文档进行查阅, 开发者可以知道Web提供了哪些方法, 以及如何通过正确的参数对他们进行调用。因为服务接口的完整描述在WSDL中已经包含, 所以, 服务访问的存根我们可以通过使用WSDL的创建进行简化, 该存根为一段Java代码, 自动生成了访问Web服务的类。

3.3 消息格式

通过对消息进行SOAP封装, 其传输方向是从发送端到接收端。所有的SOAP消息都使用XM L编码。在系统中所描述的所有消息, 是基于图2所示的层次进行封装。

消息头和消息体在xml中的表现形式如下:

3.4 消息完整性

消息完整性是指确保通信过程中消息的完整和真实可信。通过采用强有力的数字签名技术、加密技术、公钥基础结构等确保消息的完整性, 进而保证文档的真实性、完整性和受认可性。

通过数字签名可以保证消息从端到端的完整性, 一方面提供消息发件人的验证信息, 另一方面在最终使用和处理消息时对签名进行验证。借助数字签名对消息内容进行完整性检查, 如果修改原始内容的某个字节, 那么验证签名就会失败。

3.5 消息安全性

为保证消息的不可阅读性, 采用DES加密。加密算法形如:Base64 (DES (MD5 (消息体) +消息体) ) 。在ADC系统中, 制定了DES加密算法规则。如:限制密钥长度、加密模式、密文和明文的编码转换等。

4 实施效果

某省ADC系统建设运营后, 先后成功地接入企业邮箱、移动OA、农信通、校讯通、行业手机报、G3商街等业务20多种, 受众用户达几百万。企业充分利用移动智能终端的网络优势, 可以方便、快捷地处理事务, 提高了办事效率。SOAP技术的引用, 解决了系统之间的兼容问题, 实现不同平台、不同数据格式和多种连接方式的支持。在通信过程中加强企业信息的安全保障。

5 结论

基于SOAP的Web服务通过Internet协议和XML格式的SOAP来实现网络服务的访问, 具有跨平台、跨语言的优点, 但是没有任何技术可以解决一切问题, SOAP技术也不例外, 它不会取代其他分布式计算机技术 (例如RM I、CORBA及DCOM) 。当前, Web服务的若干技术SOAP、WSDL以及UDDI都在不断发展和完善中, 基于SOAP的Web服务技术必将在应用系统整合方面发挥越来越重要的作用。

参考文献

[1]杨涛.SOAP:XML跨平台WebService开发技术[M].机械工业出版社, 2002.

[2]中国移动, ADC总体技术要求1.0.0[S].

SOAP技术 篇6

1 SOAP学习模式

SOAP学习模式的主旨思想是模拟在真实环境下的学习过程, 让学习者在不断受挫、纠错的过程中逐步学习到相关技能。SOAP的4个字母分别代指情境 (Situation) 、障碍 (Obstacle) 、帮助 (Aid) 和输出 (Production) 4个在学习过程中的重要因素。情境 (Situation) 指的是运用知识点的具体环境和语境, 在这个情境中学习者得到具体的任务;在完成任务的过程中, 学习者遇到困难, 即障碍 (Obstacle) ;而后学习者通过各种途径获取帮助 (Aid) , 获取帮助的过程就是知识输入的过程。学习者在完成任务的过程中可能不止一次遇到障碍并获得帮助, 在不断地“遇到障碍—获得帮助—清除障碍”的过程中, 学习者最终掌握了知识点的运用方法, 完成任务的过程即是输出。SOAP学习模式具有以下几个主要特点:1) 学习过程最大程度地贴近实际运用知识的情境。传统的课堂大都是侧重知识点的讲解, 在很大程度上脱离真实的运用场景, 学生即使掌握了知识点也不清楚这个知识点在实际工作中如何运用的。创设情境, 在情境中引出任务最大程度, 让学习者了解知识点的真实运用环境[2]。2) 教学活动主体发生了变化。传统授课主要是通过教师讲解、学生操练的方式, 学生被动接受知识。学生在学习过程中并不能真正理解知识运用的场景。SOAP学习模式要求教师创设实际情境将学生引向现实生活, 引导学生从中去感受和体验。学生在获得相应知识的同时其他方面的能力也得到提升。学生在课堂上成了主体, 而教师担当起指导者的角色, 一步步引导学生在特定的场景中完成相应的任务, 从而掌握住相关知识点。3) 考核方式的不同。传统的课程考核主要通过笔试或辅以口试来考察学生对知识点的掌握情况;而在SOAP学习模式下对学生的考核则侧重于对知识点的应用。教师可以通过创设情境, 让学生以单个或小组分工形式完成在该情境下的任务, 从而完成对学生的考核。

2 基于SOAP学习模式的外贸函电“翻转课堂”的实现

2.1 微课视频的录制

随着移动互联网技术的不断发展, 学习者的学习方式也发生了很大变化。慕课、微课及“翻转课堂”等逐渐影响着教育模式。微课是指以视频为主要载体在较短的教学时间内 (以5~10 min为宜) , 教师针对某个知识点进行针对性的、优势的、趣味性的、综合性的教学活动[3]。从微课概念的提出到现在, 虽然学界对微课仍未形成统一的定义, 但学者和实践者在不断地完善其内涵, 丰富其形式, 以达到最佳的教学效果[4]。

在实施“翻转课堂”的过程中, 教师要提前录制微课视频供学生课前学习并为“翻转课堂”提供条件。基于SOAP学习模式的外贸函电微课视频拍摄步骤如下:1) 创设情境 (Situation) 。模拟外贸函电运用场景, 一人扮演新手业务员接到外贸函电写作任务。2) 演示障碍 (Obstacle) 。在写作过程中遇到困难, 在视频中通过扮演者的陈述或文字描述将遇到的问题呈现出来。3) 获得帮助 (Aid) 。业务员扮演者主动向他人求助或被动得到帮助, 从而使遇到的问题得到解决。4) 写作输出 (Production) 。学习者在遇到一次或数次困难并得到有效帮助的过程中逐渐掌握该函电写作技能, 从而写出符合要求的函电。教师在教授过程中只有注重发展学生综合素质能力, 才能保障学生的知识应用水平得到不断提高[5]。

微课拍摄的过程符合了学习者在实际工作中运用知识的过程。学习者通过课前观看微课视频能够在掌握相关章节重点、难点的同时了解SOAP学习模式的构建过程, 为顺利实施“翻转课堂”提供了条件。基于SOAP学习模式的外贸函电微课拍摄需要注意以下几点:1) 将课程分解成若干微单元, 为微课拍摄做准备;2) 微课内容设计围绕某个外贸函电内容的重点、难点展开, 内容短小精悍 (10 min以内) , 形式新颖活泼, 教学过程完整, 最终形成可视化、情境化、趣味性的数字化学习资源;3) 微课内容的教学环节设计符合SOAP教学模式;4) 微课视频里的角色扮演环节尽可能贴近外贸函电的真实运用情境。

为了使“翻转课堂”达到最佳效果, 教师除了要给学生提供微课视频, 还应该给学生提供其他形式的资料, 例如课件、练习测试、教学反思、作业点评等。教师将这些资料根据学生学习规律逐步提供, 给学生营造自主学习的环境。

2.2“翻转课堂”的实现

随着信息技术的不断发展, 教育领域也出现了一些新的教学模式。“翻转课堂”便是近年来比较受欢迎的一种模式, 也是变革传统课堂的有效途径。“翻转课堂”起源于美国科罗拉多州林地公园高中的化学课, 也被译为“颠倒课堂”, 对课堂教学产生了重大影响, 已成为全球教育界关注的教学模式[4]。“翻转课堂”指的是在信息化环境中, 课程教师将某些知识点制作成以教学视频为主要形式的学习资源, 并辅以其他学习资料让学生在课下观看和学习。教师在课堂上通过小组讨论、作业答疑、模拟演示、探究协作等形式完成对知识点的内化。“翻转课堂”颠覆了传统课堂以教师讲授为主的模式, 强调了学生在课堂上的主体地位, 教师转为幕后指导, 把知识传授以课上听讲为主, 知识内化以课下作业为主“翻转”为知识传授以课下自学为主, 知识内化以课上活动为主。学生的学习方式发生了变化, 学习场地变得宽松, 时间增多, 不再被固定场所和时间所限制[6]。

外贸函电作为实用性很强的课程, 实施“翻转课堂”来培养学生的实践能力尤其必要。根据“翻转课堂”的特征和设计原则, 笔者在借鉴国内外“翻转课堂”的实际应用案例后, 逐步形成适合外贸函电课程实际的基于SOAP学习模式的“翻转课堂”应用模式。该模式通过用微课指导学生学习, 从而实施“翻转课堂”, 符合掌握学习理论和建构主义学习理论的观点[7]。

2.2.1 实施方案

为检验基于SOAP学习模式的外贸函电“翻转课堂”教学模式的可操作性, 笔者选取2013级英语专业 (商务方向) 学生作为受试对象, 在大二上学期外贸函电课程的授课过程中, 笔者选取了外贸函电课程中的4个知识点 (建立贸易关系、询盘、发盘及还盘) 实施基于SOAP学习模式的“翻转课堂”教学, 其余知识点按照传统教学模式授课。为进一步探究基于SOAP学习模式的“翻转课堂”教学模式的有效性, 笔者将实施“翻转课堂”和传统课堂的学习效果进行了对比, 在实践中收集数据进行分析, 运用调查问卷和访谈的方法了解学习者的学习效果和对新模式的认可度, 并分析其与传统模式相比学生学习兴趣的变化[4]。

2.2.2 实施过程

试验班级共由30人构成, 该班级前期已接触过网络辅助课程, 并初步具备了网络自主学习的能力。教师对该班级尝试过“翻转课堂”教学, 故学生对微课、慕课、“翻转课堂”较为了解, 为实施外贸函电课程的“翻转课堂”教学准备了条件。笔者首先为所选取的4个知识点制作了时长7~8 min的微课视频, 并辅以课件、习题等作为学生课前学习资料, 实施基于SOAP学习模式的“翻转课堂”, 其余知识点则按照传统教学模式授课。

课堂前准备阶段:教师首先要根据总体教学目标将课程分解成相应的微单元[8], 并重新安排每个单元的教学内容, 把课程的重点、难点分离出来制作成微课并辅以相关练习题, 搜集其他学习资源, 从而完成学生课前自主学习的教学设计;然后制作基于SOAP学习模式的微课视频, 并把微课视频及其他学习资料通过网络平台或其他途径分发给学生, 在网络平台上进一步搭建在线答疑、在线讨论等信息化学习环境[4]。

课堂内内化阶段:根据相关内容创设应用场景, 从场景中引出任务。学生以小组角色扮演、研讨等方式完成任务。在此过程中, 学生会遇到各种困难, 这些困难可以通过获得小组组员的帮助来解决, 例如扮演完成任务的业务员可以通过咨询扮演他 (她) 朋友的人 (组员之一) 来解决问题。问题在小组内得不到解决, 可以向教师请教从而解决问题。在不断遇到困难并得到帮助解决困难的过程中, 扮演完成任务的人最终完成任务, 写出一篇外贸信函。在这个过程中, 教师向学生提供指导或答疑, 针对普遍存在的问题进行集体讲解。教师最后就学生提交的学习作品进行评论并提出需要改进的方面。

课堂后巩固阶段:教师通过课后分析评比, 把优秀的学习作品在网络教学平台上展示;教师还可以将与教学内容相关的拓展学习资源设置成拓展任务, 作为课堂效果测试题。学生课后完成测试, 实现对知识 (技能) 的巩固和强化。教师通过分析学生的课堂作品及课后测试进一步反思教学效果, 发现在教学中存在的问题[4]。

需要指出的是, “翻转课堂”的顺利实施受到很多条件的限制, 例如学生接受程度、知识点难易程度、学生学习基础等。教师应根据具体情况对实施方案进行适当调整以达到最佳效果。

3“翻转课堂”的实施效果

经过1个学期的学习, 学生对实施基于SOAP学习模式的“翻转课堂”反映良好, 授课教师选取两个知识点 (一个为实施“翻转课堂”授课的知识点, 另一个为传统授课知识点) 改编成情境写作让学生在规定的时间内完成。通过分析学生的作文发现学生对实施“翻转课堂”讲授的知识点掌握得更好 (平均错误点为6个) , 而对用传统方法授课的知识点掌握不够好 (平均错误点为8个) 。笔者通过调查问卷及访谈的方式对学生进行调查, 进一步分析学生对基于SOAP学习模式的接受程度及学习兴趣提升情况, 见表1。

从表1结果可以看到, 学生对基于SOAP学习模式的“翻转课堂”教学认可度较高, 认为这种模式学习效果较好的学生占63.3%, 愿意继续实施此教学模式的占53.3%, 而认为此教学模式对学习外贸函电的兴趣有很大提高的占60.0%。在随机访谈过程中, 有的学生提出由于基础较差在课下预习环节存在困难, 希望能够多些指导类的材料。

4 结语

实施基于SOAP学习模式的“翻转课堂”教学的一个很大优势就是充分发挥了学生的主观能动性进行自主学习, 而课堂变成了师生以协作探究的方式内化知识的平台。对于外贸函电这类实践性很强, 需要学生动手充分发挥能动性去思考、去写作的课程, 学生在课下学习微课等其他资料, 在课堂上就有更多的时间动手写作, 有利于提高学生的知识运用能力, 也更容易发现在学习中存在的问题。但在实施的过程中也存在一些问题, 例如有的学生自主学习能力不强, 课前不能按时完成微课、微练习等其他资料的学习, 就使“翻转课堂”效果大打折扣。情境设计也有待进一步提升, 以达到最大程度接近外贸函电真实的运用环境。教师应当适时监督、引导学生在课前完成微课学习, 并在实践中不断分析学生的知识需求, 精心设计情境及课堂活动, 充分了解学生在学习过程中存在的问题并及时解决以达到最佳教学效果。

摘要：SOAP (Situation、Obstacle、Aid、Production) 学习模式是一种全新的学习模式, 对于实践性较强的课程尤其适用。实施基于SOAP学习模式的“翻转课堂”符合一般学习规律, 侧重于培养学生的实践能力, 是科学有效的教学模式。笔者以外贸函电课程为例实施基于SOAP学习模式的“翻转课堂”教学, 并对学习效果进行分析, 对存在的问题进行探讨, 以期找到最佳教学效果。结果表明:实施基于SOAP学习模式的“翻转课堂”对学生外贸函电写作能力有很大提高。

关键词：SOAP,翻转课堂,微课,外贸函电,实证研究

参考文献

[1]张维维, 王歆.浅析外贸函电课程特点及课堂教学[J].商场现代化, 2006 (9上) :42.

[2]肖燕, 崔晓红.模拟公司教学法在商务函电教学中的应用[J].山东女子学院学报, 2014 (6) :87-90.

[3]刘桂花.微课在高校课堂教学中的应用[J].中国成人教育, 2014 (06) :122-124.

[4]刘锐, 王海燕.基于微课的“翻转课堂”教学模式设计和实践[J].现代教育技术, 2014, 24 (5) :26-32.

[5]郭哲男.翻转课堂哪些不能翻转[J].教学与管理, 2014 (9) :35-36.

[6]黎健慧, 陈少娟.高职高专院校商务英语专业实践教学模式初探[J].中国成人教育, 2009 (3) :147-148.

[7]张福涛.基于学生自主发展的“翻转课堂”探索与实践[J].中国教育信息化, 2014 (7下) :12-14.

SOAP技术 篇7

网络已经遍及整个世界, Web也成了全人类使用最多的网络应用。Web上的资源可谓应有尽有, 各行各业都可以建立自己的Web站点, 发布他们的信息和资源。第一代Web对于所有人来说, 已几乎没有了技术门槛, 所以Web站点遍地开花。

“Web 2.0”概念[1]的提出虽然引发了不少争议, 但人们已开始期待下一代Web的出现了, 然而要迎来Web 2.0的鼎盛时代, 可能需要5年、10年甚至更长。在Web 2.0提出之前, Web Services技术雏形在1999年已出现[2]。Web Services是一项被寄予厚望的技术, Web 2.0不能少了它。目前提供Web资源的站点数不胜数, 但是同时提供Web Services的却很少。由于基于SOAP的Web Services (SOAP Web Services) 技术上的复杂性和不成熟等原因, 降低了开发人员的热情, 阻碍了Web Services的推广和应用。而REST风格的Web Services (RESTful Web Services) 技术的出现, 给推广和应用Web Services带来了新的活力。

1 RESTful Web Services的发展

近年兴起的RESTful Web Services技术源于REST概念。REST是Roy Thomas Fielding在他的博士论文中的第五章提出的一种架构风格 (主要用于Web) 。在REST中, 很重要的一个概念是Resource, Resource可以是:文档、图片、一个短暂的服务, 甚至可以是真实的人等[3]。

2005年11月Restlet API的首发, 引起开发人员对REST架构的关注。面对逐渐增多的REST API, Roy Thomas Fielding于2008-10-20在博客中撰文《REST APIs must be hypertext-driven》, 表示他的看法。他认为那些号称REST的API只是基于HTTP的API, 并非真正的REST API, 并对构建真正符合REST风格的网站 (及API) 定义了六条规则:

(1) REST API不应依赖于某个特定的通信协议;

(2) REST API不应该去修改通信协议 (除了填充或修正标准协议中被指明的位) ;

(3) REST API应将几乎所有的精力用于定义媒体类型, 媒体类型是用于表示资源和驱动应用状态的;

(4) REST API一定不能定义固定的资源名称或层次;

(5) REST API定义资源的类型不应对客户端有特别含义 (媒体类型除外) ;

(6) REST API, 应该只需知道初始URI (书签) 和一套适合于预期用户 (即可被任何使用该API的客户端所理解) 的标准媒体类型[4]。

目前所有的API都不符合上述定义, Roy Thomas Fielding本人也没有指出或设计出符合上述规则的REST API。Roy只给出了抽象规则, 所以我们很难知道如何去实现。并且有些规则是不太现实的, 如定义标准媒体类型, 这个超出REST API应考虑的范围。HTML作为Web页面的格式, 最终成为让所有人接受的标准经历了艰难的过程, 如果让媒体类型都要变成标准的媒体类型, 那要付出的努力不可想象, 而且也不是那么迫切。

严格的讲, RESTful Web Services不能称为RESTful, 但是如果大家都接受这个很酷的名称, 要改变不是件容易的事。RESTful Web Services把Web Services看成Resource, 每个Resource都由一个URL来标识。我们知道, 普通的资源是通过HTTP协议中的GET和POST两个方法来访问和操作的, RESTful Web Services还使用了PUT和DELETE 两个方法。通过这四个方法, RESTful Web Services实现类似数据库的CRUD (Create、Read、Update、Delete) 操作[5]。

目前有三种URL格式用来标识Resource, 用得较多的一种是以“/”分割参数的方式[6], 假如中国期刊网实现了RESTful Web Services, 则可以这样去访问一个资源 (一个Web Service) :

访问某个编号 (可变) 的文章:http://dlib.cnki.net/kns50/papers/{paper-id};

访问《计算机科学》2008年6月的文章:http:// dlib.cnki.net/kns50/papers/jsjkx/2008/06。

最好有一些通用性的图标, 告知用户可以进行何种操作。RSS/Atom用图标来表示feed, 方便我们的收藏。RESTful Web Services也可以借鉴该思路, 在页面中添加如下的图标, 来区分Services资源和一般性资源:

R图标 RESTful Web Services标志, 默认GET操作;

绿色的R图标 对资源的Post操作 (创建) ;

红色的R图标 对资源的Update操作;

R图标+垃圾桶图标 对资源的Delete操作。

尽管RESTful Web Services的API不是Roy Thomas Fielding所说的REST API, 但有些目标是一致的。Roy谈到的Resouce可以是文档、图片以及服务, 其中的隐含意思就包括服务和其它资源可以很好地混合在一起, 而RESTful Web Services也正有这样的目的, 它可以简化Web服务的开发和部署 (甚至不需要配置) 。这样Web Services看上去和网页、图片、多媒体等资源是类似的, 用文件系统和超链接的组织方式就可以了。

2 REST和SOAP两种Web Services的比较

SOAP协议从1998年提出到现在的SOAP1.2, 已经走过十年的时间, 相比其他的技术, SOAP Web Services的发展并不算快, 当然和SOAP Web Services相关发布了很多的协议, 俗称WS-*协议, 但是应用的情况不令人乐观。REST的出现, 确实可以帮助快速开发Web Sevices, 但并不会取代SOAP。下面主要从耦合度去比较REST和SOAP系统。

打个比喻, 分别用REST和SOAP去实现119火警系统。

·REST 路人甲救火只需要打119, 消防队就会派人派车去现场处理, 下一次再想救火, 也只需要拨打119。

·SOAP 路人乙救火, 不仅需要打119, 还要具体找到某个负责人, 负责人再派人派车去处理, 而如果负责人发生了变动, 而路人乙不知, 则无法报告火情。

通过这个比喻, 我们能更好地对系统进行耦合度的分析。为了分析全面一些, 把119火警、REST、SOAP、RMI四种风格系统的耦合度进行了比较, 如表1所示。

这里没有考虑系统的返回结果。REST系统无论在服务定位、数据还是接口依赖方面, 耦合度都是很低的, 甚至没有。表中所示的119火警系统, 完全可以看作一个REST风格系统, 公众身边还有很多这样的便利系统。当然, 其它类型风格的系统也是存在的, 因为需要更加复杂和严格的规程。

也可以看出, 公众与REST系统的耦合度是非常小的, 只要记住119号码并报告起火位置, 系统就能发生作用了。而SOAP系统则增加了耦合度, 如果WSDL文件变更了, 客户端需要构建新结构的SOAP消息。对于RMI (属于RPC) 系统, 如果服务的Remote接口变更了, 则服务端和客户端要修改代码并通过程序的编译才能继续运行, 否则系统可能就失效了, 这几乎是完全耦合了。

虽然RPC看上去有很多弊端, 但RPC在小范围使用却是非常高效的。这就好比, 要100个人行动一致是比较容易的, 但要让10000个人行动一致, 就很困难了, 而且很自然, 我们会把10000个人分成100个组, 每组100个人。所以, 松散耦合是需要的, 但紧密耦合也是需要的。

很明显REST不是RPC, 他们之间的差异很大。但是SOAP是不是RPC (看上去比较接近) , 争议还是挺大的。在SOAP文档中, <soap:binding>元素有一个style属性, 它的值可以是rpc或document[7], 着实又增加更多的混乱。其实SOAP包含的数据类型是中性的, 独立于任何程序语言, 并且对于接口的依赖主要在程序运行阶段, 因此和RPC还是有所区别的, 但SOAP也能提供RPC功能。

REST和SOAP两类型的Web Services的重要特性, 汇总如表2 所示, 比较的目的并不是为了分出孰优孰劣, 而是更透彻地去理解他们的特性。

3 REST和SOAP两种Web服务的结合

拥护REST和拥护SOAP的人都很多, 你应该加入哪个阵营?这个问题就好比你该用Java还是用.net。其实真的很难回答。那就实行实用主义, 只要好用就可以用。于是当你构建Web Services的时候, 不需要再犹豫是用REST还是SOAP?两者都可以使用, 只要有实际的需要。下面从概念层面和设计层面来讨论REST和SOAP两种Web Services的结合。

3.1 概念层面

REST反映资源状态的转移变化, 属于状态机的范畴;SOAP是一个通信协议, 可用于分布式异构系统之间的交互。虽然两种系统都存在交互, 但交互的方式有很大不同, 如表3所示。

REST系统的交互简单、高效但不保证可靠性;SOAP系统的交互更复杂、承诺更多的保证, 但损失效率。RESTful Web Services是一种轻量级的服务, 而SOAP Web Services是一种重量级的服务, 两者适合不同的场合。在结合使用REST和SOAP系统的时候, 需要考虑的主要因素有:带宽、规模、事务、功能等。这里简单说明一下两种类型的系统适合的场合。

·REST的系统适合如下的场合

(1) Web Services完全是无状态的;

(2) 服务的消费者 (往往指人) 应能理解服务提供者的约定, 并能适应服务的变化;

(3) 占用较小的带宽, 提供更多的连接[5];

(4) 能较容易地融入已运行的站点, 服务和页面可以很好地混合。

·SOAP的系统适合如下的场合

(1) 有正式的契约精确描述Web Services提供什么接口, 服务的消费者和提供者都要能理解契约并按合同办事;

(2) 架构能应付复杂的非功能性的需求, 如事务、安全、协调等[5];

(3) 适合机机交互 (即服务器到服务器的交互, 而非人机交互) , 这一点和Jean-Jacques Dubray的观点正好一致的[9]。

REST和SOAP系统的结合处在于Web Server (App Server也可) 。

3.2 设计层面

由于REST和SOAP两种Web Serivces系统的交互方式差别很大, 因此REST系统应该处在离客户更近的地方, 而SOAP系统处在离客户更远的地方 (当然这是逻辑上的) 。图1为两种系统结合的示意图。

为了模型的简单, 图中的某些地方做了简化, 因此有必要进一步说明:

(1) API:包含接口和特定实现; (2) REST Web Services代码:包含若干资源 (服务也是一种资源) ; (3) SOAP Web Services代码:只包含服务; (4) 信封:SOAP消息; (5) SOAP API:包含SOAP、WSDL、XML等Web Services等所需API; (6) Web Server和App Server的关系:一对多的关系, 图中n表示任意一个。

这样的结合是很自然的, 没有必要做过多的解释, 而且一些公司和软件开发人员已经开始意识到这一点了[10]。

4 REST和SOAP Web Service的Java实现

RESTful Web Service服务端的Java实现, 可以有两种方式:一种利用JAX-WS 2.0, 另一种则利用JAX-RS[6]。下面对用Java实现REST和SOAP两种Web Services做一些说明:

(1) 利用JAX-RS API 1.0, 此API是SUN JSR311 (2008.9.8发布1.0最终版) 的实现, 是稳定的产品版本, 因此可以用于正式的开发;

(2) REST客户端可使用目前很热门的Ajax技术来加强客户端和服务端之间的交互, 并使用一些Javascript库如jQuery来辅助开发, 为处理json和XML数据提供更多的便利;

(3) 使用注解 (annotations) 来简化RESTful Web Services的开发, 可以减少很多模板代码, 并且可以减轻XML配置的烦恼。虽然注解的机制比较复杂, 但是使用注解对于开发人员并不困难。不过对于注解, 尚有一些担忧, JAX-RS中包含的注解 (如@GET、@POST等) , 在Servlet 3.0 (目前是早期草案) 将被重用, 最终这些注解会移动到Common Annotations specification (JSR 250) 中[11]。所以, 注解的设计将考验Java类库的设计人员, 当然也会影响我们的代码;

(4) 开发SOAP Web Services恐怕对于大多数人来说还是一个挑战。不过这个情况正在得到很大改善, 从JDK (Java的类库) 的发展来看, Java 6在Web Services方面增加了很多包, 以后还会继续加强;

(5) XQuery1.0规范也于2007年发布, 我们几乎可以像使用sql操作关系数据一样用XQuery操作XML, 有了XQuery, Java可以方便地从XML中获取数据, 这样可以减少Web Services中的Java和XML之间复杂的绑定和映射, 极大方便Web Services的开发。当然XQuery还需要完善, 如何使用XQuery和其它技术更有效地开发SOAP Web Services还需要进行更多的研究性工作。

5 展 望

在分布式计算环境中, 松散组合的系统可能比紧密耦合的系统更有前景。Web系统就是一个很好的证明。RESTful Web Services可以构造松散组合的系统, 将会得到大量应用。我们期待的Web Services时代, 在REST和SOAP的携手下, 应该不会再跳票了。

摘要：对REST风格的Web Services进行介绍, 接着对REST (Representational State Transfer) 风格和基于SOAP的两种Web Serv-ices的耦合度进行比较, 进而提出两者是可结合的。这样在构建Web Services的时候能做出合理的选择。

关键词：REST,SOAP,Web Services

参考文献

[1]Tim O′Reilly.什么是Web2.0[J].互联网周刊, 2005, 40:11-22.

[2]Uche Ogbuji.The Past, Present and Future of Web Services.part1.2002-9-28.http://www.WebServices.org/categories/enterprise/strat-egy-architecture/the-past-present-and-future-of-Web-Services-part-1/ (go) /Articles.

[3]Roy Thomas Fielding.Architectural Styles and the Design of Network-based Software Architectures[D].UNIVERSITY OF CALIFORNIA, 2000:88.

[4]Roy Thomas Fielding.REST APIs must be hypertext-driven.2008-10-20.http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyper-text-driven.

[5]Sameer Tyagi.RESTful Web Services.2006-08.http://java.sun.com/developer/technicalArticles/WebServices/restful/.

[6]袁赟.Java与RESTful Web Services[J].电脑知识与技术:学术交流, 2007, 21.

[7]陆小芳.Web服务的两种调用模型的比较及开发[J].计算机应用, 2005, 25 (1) :78-80.

[8]许卓明.基于RPC和基于REST的Web服务交互模型比较分析[J].计算机工程, 2003, 29 (20) :6-8.

[9]胡键.REST在SOA中适合哪个位置.2008-11-3.http://www.in-foq.com/cn/news/2008/11/rest-soa.

[10]Pingpangsong.SOA2006年终回顾以及2007展望 (一) .2006-12-16.http://pingpangsong.javaeye.com/blog/39348.