一种基于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标准接口的测试方法，采用JAVA编程语言，以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（组织标识）。

MessageID（消息ID）：消息的唯一标识，两个消息不允许有相同的MessageID。

CorrelationID（关联ID）：该字段用于将消息连接在一起。该字段可以在请求中提供，因此客户端可以关联对应的应答消息。服务器段会将应答消息的CorrelationID设置为源消息的CorrelationID取值。

Comment（注释）：任何描述性的文字。

Property（性质）：复合类型允许客户以键/值对的方式扩展传输的信息，包含一个Name（名称）和Value（取值）。

other（其他）：其他的客户扩展，由开发商自行定义扩展。

IEC 61968标准规范了一个动词列表，Verb（动词）只能为下表的取值。

表1 IEC 61968推荐动词表

请求动词 回复动词 事件动词 使用场景

Get Reply 无 查询

Create Reply Created 事务

Change Reply Changed 事务

Cancel Reply Canceled 事务

Close Reply Closed 事务

Delete Reply Deleted 事务

Execute Reply Executed 事务

Request（请求动词）的使用方法如下：

Get用于查询消息名词中指定类型的对象。

Create用于创建消息名词中指定类型的对象。

Delete用于删除对象，为了维持修订历史，有时目录系统并不是真正删除对象。

Close和Cancel用于与业务处理相关的动作，如关闭一个工作订单或取消了控制请求。

Change用于更改对象，但需注意，当通过业务规则进行表示时会模棱两可，尤其是在复杂数据集的情况下（复杂数据集一般具有N：1的关系）。

Execute用于使用操作集进行传输的复杂事务，可能包含一个以上的动词。

每个Request（请求）都使用Reply（回复动词）进行回复。Event（事件动词）常常是请求的结果，一个Create可导致一个Created事件的产生。事件中使用的动词为相应请求动词的“过去式”。

消息头的定义如图1所示：

图1 消息头定义

3.2 消息请求结构

IEC 61968Request（消息请求）结构只用于请求消息中，用于存放请求消息的请求参数，请求结构中的元素都不是必须的，在实际应用中可以根据实际情况进行选用。消息请求结构包括的元素描述如下：

StartTime（起始时间）：当一个请求需要起始时间作为过滤条件时使用。

EndTime（结束时间）：当一个请求需要结束时间作为过滤条件时使用。

Option（配置）：名值对方式，在查询请求时可作为过滤条件，可用于规定超时时间或规范化响应模式等，在具体实现时作为自定义的扩展。

ID（标识）：在查询请求时，可以作为过滤条件标识一个或多个对象，可以在“close”、“delete”、“cancel”事务中标识特定的对象。每个ID都有一组属性，“kind”用于说明标识的类型，如名称、UUID、事务ID或其他类型，UUID默认采用对象的mRID属性取值;如果取值为名称，“idType”和“idAuthority”需要提供。

Other：其他的自定义扩展。

消息请求的定义如图2所示：

图2 消息请求定义

3.3 消息回复结构

Reply（消息回复）作为对其他消息的响应，包括的元素描述如下：

Result（结果）：消息回复的结果，取值为以下之一：

OK：没有错误，返回所有的结果，“Error”元素不需要。

PARTIAL：部分，返回部分结果，有一个或多个“Error”元素。

FAILED：错误，没有返回结果，有一个或多个“Error”元素。

Error（错误）：错误描述。

ID（标识）：错误对象ID。

Other（其他）：其他的自定义扩展。

OperationId（操作ID）：操作ID，与请求的操作相同，用于描述是对哪个请求的回复。

消息回复的定义如图3所示：

图3 消息回复定义

Error元素描述处理的错误信息，其元素描述如下：

code（错误代码）：用来描述错误的类型。

level（严重级别）：分为：INFORM（信息）、WARNING（警告的）、FATAL（严重的）、CATASTROPHIC（灾难的）。

reason（错误原因）：一般为人可读的错误名。

detail（详细信息）：自由格式描述错误具体的信息。

xpath（出错路径）：XPath表达式标识具体的出错的XML元素，

stackTrace（异常堆栈）：软件产生的异常堆栈。

Location（异常位置）：软件产生异常的位置。

ID（事务ID）：对应的事务ID。

relationID（关联ID）：出错的关联对象，用于描述两个对象间的关联出错。

opertionId（操作ID）：与请求的操作相同，用于描述是对哪个请求的回复。

3.4 消息有效内容结构

Payload（消息有效内容）可以看作是CIM模型的一个子集，通过定义包含在该消息中的IEC TC57 CIM模型的类和属性实现。并不是所有的消息都需要有效内容，例如get，close，cancel，reply操作等只需要消息头，有效内容可以为空。

有些类型的消息必须提供有效内容，如果带有动词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生成为相应的JAVA编码后，只需要编写少量代码就可以实现WebServices服务的调用和。作为WebServices客户端，对其他WebServices服务进行调用时，相应的主要代码如下：首先构建工厂JaxWsProxyFactoryBean对象，设置要调用的服务类型Operations和服务地址，创建相应的客户端对象client，构建相应的参数，调用相应的服务方法。作为WebServices服务端，对外提供WebServices服务供其他客户端调用时，相应的主要代码如下：首先要实现对应的WebServices接口方法，通过Endpoint.publish，设置的地址和实现的对象即可。

5.CXF拦截器

通过Apache CXF实现WebServices的服务调用和服务非常简单，这些作用客户端应用进行服务调用和实现WebServices服务器很有用，但作为测试来讲，只能看到高层的JAVA对象是不够的，必须能够查看底层的消息并可以对消息进行随意的编辑才能实现测试的目的，这可以通过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技术开发图形化界面，使用JAVA开发语言。这种针对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.