一种基于IEC 61968标准接口测试自动化的实现方法

一种基于IEC 61968标准接口测试自动化的实现方法
【摘要】介绍了一种IEC 61968标准接口的WebServices自动化测试方法。

对IEC 61968标准接口的WebServices实现进行了介绍，使用Apache CXF作为WebServices的实现中间件，采用CXF中的拦截器来实现可定制的WebServices 输入和输出展示，可对WebServices的请求和响应消息体进行编辑和查看，从而实现对IEC 61968 WebServices接口的自动化测试。

【关键词】IEC61968CX;WebServices拦截器
1.引言
随首电力信息化系统的发展，各开发商为不同的业务部门开发了相应的业务信息化系统，由于各开发商所使用的技术不同、开发周期不同，没有采用统一的技术，从而导致各业务系统相互独立，业务系统间形成数据的壁垒，数据只能在各业务系统内流转，从而产生“数据孤岛”问题，严重阻碍了信息化建设的开展，容易形成重复建设的情况，降低了数据作为“资产”的价值。

“信息孤岛”现象不是一个个案，在电力行业乃至信息化行业内普遍存在，为了解决电力行业内的“信息孤岛”问题，国际电力标准委员会制定了IEC 61970/IEC 61968系列标准。

IEC 61970标准中定义了公共信息模型（Common Information Model，CIM[1]）和组件接口规范（Component Interface Specification，CIS[2]），为各应用系统间的交互提供了语义和语法上的依据。

IEC 61970定义的CIS接口采用CORBA（Common Object Request Broker Architecture，CORBA[3]）技术，技术门槛较高，且采用紧耦合的方式，适合以高性能进行大量数据的传输，对于一些通知消息类的小数据量传输来说，其结构过于庞大，不利于开发商的快速实现，为此IEC 61968标准在IEC 61970 CIM/CIS标准的基础之上，扩展了配电管理部分的CIM模型，并定义了业务系统信息交换模型（Information Exchange Model，IEM[4]）和另一种松耦合方式的消息传递标准，以当前流行的WebServices 技术进行实现。

本文对IEC 61968标准定义的WebServices标准接口进行了介绍，同时描述了一个采用Apache CXF[5]实现的IEC 61968标准接口的测试方法，采用JA V A 编程语言，以CXF中拦截器的方式实现对WebServices输入输出的拦截，并对输入输出XML[6]内容进行查看和编辑，可以为不同的要求配置不同的WebServices输入内容，从而实现IEC 61968标准接口的自动化测试。

2.IEC 61968 WebServices接口
IEC 61968接口可以通过多种技术方式进行实现，如WebServices、JMS等，本文对WebServices实现方式进行了说明。

IEC 61968标准定义了一个通用的接口，并以WSDL[7]的方式对接口进行了
规范化定义，其中WebServices服务名称为：Service，该服务只包含三个方法：
PublishEvent：事件发布方法，用于事件通知。

PublishEvent方法的输入参数为EventMessage，返回值为ResponseMessage。

Request：请求方法，用于查询或更新操作。

Request方法的输入参数为RequestMessage，返回值为ResponseMessage。

Response：响应方法，用于对通知消息的确认，或是对数据处理结果的反馈。

Response方法的输入参数为ResponseMessage，返回值为ResponseMessage。

3.IEC 61968消息结构
3.1 消息头结构
IEC 61968 Header（消息头）包含了一些消息基本描述与控制信息。

请求、响应、事件消息都有消息头结构。

消息头只有Verb（动词）和Noun（名词）两个必须的字段，其他的字段都是可选的，消息头包括以下元素：
Verb（动词）：描述要进行的动作，用来标识要采取的动作类型，如create （创建）、close（关闭）、cancel（取消）;created（已创建）、closed（已关闭）、changed（已更改）。

IEC 61968标准规范了一个动词列表，动词取值只能从动词列表中选择。

Noun（名词）：用来标识Payload（消息有效内容）的类型，描述消息的主题。

Revision（修订）：消息修订版本号。

ReplayDetection（重发检测）：这是一个复杂元素，包含一个timestamp（时标）和一个nonce（随机数）用于防止重发攻击。

时标由源系统生成表示消息创建的时间;随机数是一个序列号或随机生成的字符串（例如UUID），由源系统生成，并且在一天内不允许重复。

Context（上下文）：表示消息上下文，如PRODUCTION（生产）、TESTING （测试）、STUDY（研究）、TRAINING（培训）等。

Timestamp（时标）：一个遵循ISO-8601的字符串，表示消息发送的时间。

Source（来源）：消息产生的来源，系统或组织的名称，如EMS、GIS。

AsyncReplyFlag（异步应答标志）：表示应答消息是否异步发送。

ReplyAddress（应答地址）：异步应答发送消息的目标地址。

AckRequired（确认请求）：表示请求的消息是否需要一个回传的确认消息。

User（用户）：一个复杂结构表示用户以及相关的组织，包含一个UserID（用户标识）Organization（组织标识）。

有些类型的消息必须提供有效内容，如果带有动词create或change的请求消息，以及一些响应消息和一些事件消息。

有效内容一般包含遵循一个已定义了XSD[8]的XML文档。

有些情况也会有例外，例如：一些XML有效内容没有XML Schemas，如RDF文件或动态查询结果，还可能是非XML格式，如CSV和PDF。

还有些情况，有效内容很大，必须进行压缩，否则将浪费大量带宽。

为了适应多种格式选项，有效内容提供了以下的格式（图4）：
图4 消息有效内容定义
在消息有效内容中，我们可以通过使用XML的“any”结构，来包含任何类型的XML文件。

另外，它也提供了松耦合选项，也能使用由XSD定义的特殊复杂类型。

一些情况下可能需要zip格式、Base64+编码的字符串，此时可在消息中使用“compressed”标签。

下列情况需要使用压缩方式：
一个遵循XML Schema的有效内容，超出了预定义的大小（如，1MB）。

这种情况很常见。

具有非XML格式的有效内容，如PDF，Excel表格，CSV文件，或二进制图片。

使用XML格式但没有XML Schema的有效内容，超出了预定义的大小（如，1MB）。

如作为一个SQL XML查询结果生成的动态XML。

当有效内容采用Base64编码的压缩方式时，它作为一个string存储于compressed消息元素内。

另外，为了支持二进制格式数据的高效传输，数据采用Base64编码，但不压缩。

如果XML格式不能满足性能的要求，可以对数据进行分类，通过压缩方式来实现“高速”传输。

Format标签可以用于标识特定的数据格式，比如XML、RDF、SVG、BINARY、PDF、DOC、CSV等。

该标签是可选字段，它一般只用于当有效内容的存储使用compressed消息元素时。

4.Apache CXF
Apache CXF是一个开源的WebServices框架，大大简化了WebServices的创建，并可以在多种传输协议上运行。

采用CXF构建WebServices服务非常方便，通过CXF的工具将WSDL生成为相应的JA V A编码后，只需要编写少量代码就可以实现WebServices服务的调用和发布。

作为WebServices客户端，对其他WebServices服务进行调用时，相应的主要代码如下：首先构建代理工厂JaxWsProxyFactoryBean对象，设置要调用的服务类型Operations和服务地址，创建相应的客户端对象client，构建相应的参数，调用相应的服务方法。

作为WebServices服务端，对外提供WebServices服务供其他客户端调用时，相应的主要代码如下：首先要实现对应的WebServices接口方法，通过Endpoint.publish，设置发布的地址和实现的对象即可。

5.CXF拦截器
通过Apache CXF实现WebServices的服务调用和服务发布非常简单，这些作用客户端应用进行服务调用和实现WebServices服务器发布很有用，但作为测试来讲，只能看到高层的JA V A对象是不够的，必须能够查看底层的消息并可以对消息进行随意的编辑才能实现测试的目的，这可以通过CXF的拦截器来实现。

CXF的拦截器是CXF功能最主要的扩展点。

通过自定义的拦截器，可以改变请求和响应的一些消息处理，其中最基本的原理还是一个动态代理。

当服务被调用时，一个拦截器链表被创建并调用。

每一个拦截器都有机会做他们想要处理的消息，包括：读取，转化，处理头部，验证消息，等。

拦截器可以用于CXF 的客户端和服务端。

当一个CXF客户端调用一个CXF服务端的时候，客户端有一个传出（Out）的拦截器链，服务端有一个传入（In）的拦截器链。

当服务端发送响应给客户端时，服务端有一个传出（Out）的拦截器链，客户端有一个传入（In）的拦截器链。

此外，在调用出错的情况下，一个CXF服务将创建单独的对外输出错误处理链，客户端将创建一个传入（In）的错误处理链。

创建代理工厂后分别向拦截器链表中添加相应的拦截器，其中MessageInInterceptor和MessageOutInterceptor分别对应客户端的传入拦截器和传出拦截器。

发布服务器后分别向拦截器链表中添加相应的拦截器，其中MessageInInterceptor和MessageOutInterceptor分别对应服务端的传入拦截器和传出拦截器。

代码的主要思想是将原始的消息内容XML展示出来，对其进行修改后，将修改后的内容放到消息流中，替换原来的消息内容，在发送消息时发送的就是修改后的消息内容。

测试软件的界面如图5所示：
图5 测试软件界面
6.结束语
测试工具的开发平台是Eclipse 3.6.2，采用Eclipse RCP技术开发图形化界面，使用JA V A开发语言。

这种针对IEC 61968WebServices标准接口测试方法，可针对不同的应用场景修改相应的测试消息内容，具有很好的通用性，测试效率高。

此种测试方法没有考虑IEC 61868 对Payload定义XSD限制的情况，未对
Payload的内容进一步的处理，可在此基础上对其进行改进以适应更广泛的测试要求。

参考文献
[1]IEC 61970-301 Energy management system application program interface （EMS-API）：Part 301 Common Information Model（CIM）Base[S].2004.
[2]IEC 61970-401 Energy management system application program interface （EMS-API）：Part 401 Component interface specification（CIS）f ramework[S].2005.
[3]OMG.CORBA/IIOP2.3 Specification[S].1998.
[4]IEC 61968-1 Application integration at electric utilities-System interfaces for distribution management-Part 1：Interface architecture and general requirements[C].2003.
[5]CXF，http：//.
[6]W3C.Extensible Markup Language（XML）1.0（Fifth Edition）.2008.
[7]W3C.Web Services Description Language（WSDL）1.1.2001.
[8]W3C.XML Schema Part 0：Primer Second Edition.2004.。