一种基于代理机制的通用历史数据服务的实现方法

摘要

本发明公开了一种基于代理机制的通用历史数据服务的实现方法。该方法包含了以下信息：基于标准的Web服务技术建立历史数据发布服务，能够支持各平台各语言进行调用；基于代理机制实现历史数据的发布，具体每一种历史数据对应一个代理，代理可以运行在异构的分布式环境中，使得整个系统能够满足规模庞大结构复杂的电网调度系统中历史数据发布的需求。本发明基于代理机制的方式，保证了原有系统的复用，可以在不改造已有系统的基础上进行集成；同时通过提供标准的历史数据的发布接口，简化了数据接入方式，最大程度降低了数据交换带来的子系统之间耦合，提高了历史数据交互的方便性和灵活性。

说明书

技术领域

本发明涉及基于代理框架实现的电网各调度自动化系统之间数据服务的实现技术领域，具体是一种基于代理机制的通用历史数据服务的实现方法。 

背景技术

随着电网规模的不断扩大，电网监控及运行维护工作量不断增大，各功能建立了自身领域的信息化调度子系统，例如：数据采集与监视控制系统、水调自动化系统、电能量计量系统等等。各调度子系统是电力信息化系统的必要补充，为生产、评估、分析、检修等提供专业数据。以往各调度子系统独立建设，分散运行，使得电网调度系统中各个系统之间的数据交互变得非常困难。 

历史数据的交互是实现电网调度系统中分散子系统之间数据交互的重要方式。通过历史数据的传输，各个调度子系统可以获取其他系统的运行信息，使得各个调度子系统数据互相关联、融合。例如数据采集与监视控制系统可以发布电网运行的历史数据；水调自动化系统可以发布水库历史数据、雨量历史数据；电能量计量系统可以发布电量累计历史数据等。这些历史数据被其他系统获取分析利用，实现了电网调度系统的集成与融合。 

但是，当前电网调度系统中历史数据的发布方式基本是通过直接连接各个调度子系统的历史数据库进行访问。这种紧耦合的方法当电网调度系统结构简单、历史数据库较少的时候能够满足要求历史数据发布的需求。随着电网调度 系统的发展，其结构出现了复杂化和分散化的特点，这种方式已经不能满足调度系统历史数据发布的要求，主要表现在以下几个问题： 

1.历史数据请求方必须根据不同类型的历史数据库编写不同的客户端程 

序，实现不同 

的业务逻辑，这样就增加了很多的额外工作量，也可能带来额外的错误风险； 

2.当系统结构变得非常复杂，会出现大量的历史数据库连接，这些连接结 

构复杂分布 

分散，会给后期的维护和扩展带来很大的困难。 

本发明针对以上述两个问题，提出了一种基于代理框架实现的历史数据服务的实现技术，适用于大规模复杂分散的电网调度系统环境中进行历史数据的交互。 

发明内容

本发明的目的在于：提供一种基于代理机制的通用历史数据服务的实现方法，也就是电网调度系统中各子系统之间互相获取历史数据服务的实现方法，采用基于代理机制的历史数据发布方法，通过提供通用的历史数据发布服务和可灵活部署的历史数据代理。实现了历史数据发布与传输，解决了复杂分散电网调度系统中历史数据的传输问题。通过采用代理机制，可以在不改造已有系统的基础上进行集成，通过历史数据的发布方式，最大程度降低了数据交换带来的子系统之间耦合。 

本发明解决上述技术问题的技术方案是： 

一种基于代理机制的通用历史数据服务的实现方法是通过部署历史数据发 布服务和相应的代理程序后，由历史数据发布服务和代理程序完成历史数据的传输，包含以下四个步骤： 

1.历史数据请求方获取历史数据发布服务的访问接口，并向该接口发送历史服务查询请求，该请求包含了所请求对象的名称、特征、对象GID信息、过滤条件、起始、结束时间区间、用户标识以及历史数据类型信息。 

具体步骤包括： 

1）历史数据请求方在服务注册中心查找历史数据发布服务的服务描述WSDL文件； 

2）历史数据请求方根据步骤1）得到的WSDL文件分析出历史数据发布服务的访问接口、参数类型和返回值类型； 

3）历史数据请求方编写访问客户端程序发送查询请求至历史数据发布服务，请求包含了所请求对象的名称、特征、对象GID信息、过滤条件、起始结束时间区间、用户标识以及历史数据类型信息，请求以xml文件形式封装通过HTTP协议进行传输。 

2.历史发布服务接受到历史数据请求方的请求，分析该请求并向远方具体实现特定历史数据发布的代理程序发出具体的历史数据获取请求。 

具体步骤包括： 

1)历史数据发布服务接收到步骤1中发送的请求进行解析，分析请求方的权限和其所请求的历史数据类型是否匹配，不匹配的话返回错误，匹配则进行步骤2）； 

2)历史数据发布服务维护了所有历史数据代理程序的列表，该列表中每一种具体的历史数据对应了一个代理程序，根据请求中的历史数据类型请求的 名称，历史数据发布服务查询其对应的代理程序的地址和端口； 

3）历史数据发布服务重新封装数据请求，通过socket连接发送给2）所查询到的代理程序。 

3.代理程序收到请求，在本地完成历史数据的查找与处理，并将结果返回给历史发布服务。 

具体步骤包括： 

1）代理程序启动后一直在监听特定端口socket连接，收到历史数据发布服务的请求后进行解析，判断该请求是否能够处理，不能返回错误结果，能处理进行步骤3.2）； 

2）代理程序将请求分配给空闲线程进行处理，每一种历史数据的查询过程根据每一个历史数据代理程序的业务逻辑而不同，基本特征都是通过查询符合请求中条件的数据，通过socket连接返回给历史数据发布服务； 

3）处理线程返回之后恢复空闲状态，继续等待下一个请求。 

4）历史发布服务收到代理程序返回的结果再进行解析，生成最终返回结果返回历史数据请求方。 

具体步骤包括：历史数据发布服务收到代理程序返回的结果，其中主要包括了查找到的历史数据，历史数据发布服务对这一结果进行解析并以xml文件形式进行封装，通过HTTP协议返回给历史数据请求方，历史数据请求方解析返回结果，得到所请求的历史数据。 

本发明的有益效果是：本发明通过一种方便、灵活、统一的方式，提供电网调度系统中各子系统之间互相获取历史数据的方法，通过采用代理机制，可以在不改造已有系统的基础上进行集成，通过部署相应的代理程序，屏蔽了底 层的操作系统和网络的异构性，实现该系统历史数据的发布，最大程度降低了数据交换带来的子系统之间耦合，适用于分散复杂的电网调度系统的集成。 

附图说明

图1为本发明的系统架构示意图。 

图中，服务器1，调度子系统A2-1，调度子系统B2-2，调度子系统A网络协议3-1，调度子系统B络协议3-2。 

图2为本发明的代理机制结构示意图。 

图中，代理框架4，第一代理线程5-1，第二代理线程5-2，第三代理线程5-3，第四代理线程5-4，第五代理线程5-5，第六代理线程5-6。 

图3为本发明的基于代理机制的历史数据发布过程示意图。 

图中，水库历史数据请求客户端6，历史数据发布Web服务7，历史数据代理配置列表8，水库历史数据代理框架9，水库历史数据代理线程10。 

具体实施方式

下面结合附图和实施对本发明作进一步说明。 

本发明的系统架构如图1所示，图中，服务器1，调度子系统A2-1，调度子系统B2-2，调度子系统A网络协议3-1，调度子系统B络协议3-2。 

系统架构包括了服务器1、调度子系统A2-1以及调度子系统B2-2。服务器中包括了历史数据发布服务、Tomcat、JVM以及Windows、Linux或者AIX操作系统。调度子系统A2-1或调度子系统B2-2包含了代理程序、Oracle、SQLServer、DB2以及Windows、Linux或者AIX操作系统。历史数据发布服务 部署在Tomcat服务器中，通过底层Java虚拟机JVM的屏蔽，可以适用于Windows、Linux或者AIX等各个不同的操作系统平台。调度子系统A2-1中部署了代理机制，通过网络协议3-1与服务器1相连；调度子系统B2-2中部署了代理机制，通过网络协议3-2与服务器1相连。 

整个方案包括了历史数据发布服务的建立、调度子系统中代理机制的建立以及完成历史数据发布的交互过程三个部分内容。 

一、建立历史数据发布服务 

对于各不同的历史数据请求方，其操作系统、网络环境和编程语言往往各不相同，为此我们采用标准的Web服务方式来建立历史数据服务。这一解决方案的益处在于，历史数据请求方不需要关心其底层的操作系统和网络环境的特点，只需要通过HTTP协议获取历史数据发布服务的服务描述文件——WSDL文件，并根据这一文件编写客户端程序。 

历史数据发布服务的WSDL文件描述了本服务的接口信息，包括接口名称、参数类型、返回值类型，其定义如下： 

历史数据发布服务内部对于所有的历史数据请求做了统一的封装，包括以下数据结构： 

HDRequestWrapper（历史数据请求封装）的各个属性定义如下： 

历史数据发布服务维护了所有代理程序的列表，该列表中每一种历史数据类型对应了一个代理程序根据请求中的历史数据类型信息，历史发布服务根据请求的历史数据类型查询其对应的代理程序的地址和端口。这一列表的定义形式如下： 

二、建立调度子系统的代理机制 

调度子系统中的代理机制负责具体某一种历史数据的查询、打包、编码和传输。 

代理机制的结构如图2所示：图中，代理框架4，第一代理线程5-1，第二代理线程5-2，第三代理线程5-3，第四代理线程5-4，第五代理线程5-5，第六代理线程5-6。 

代理机制包括了代理框架4和一组代理线程：第一代理线程5-1，第二代理线程5-2，第三代理线程5-3，第四代理线程5-4，第五代理线程5-5，第六代理线程5-6。 

代理框架4是代理机制的主体，一直运行在系统中，它维护了一个代理线池，池中包含了一组代理线程：第一代理线程5-1，第二代理线程5-2，第三代理线程5-3，第四代理线程5-4，第五代理线程5-5，第六代理线程5-6。代理框架4负责监听网络socket端口，发现有请求到达就从代理线程池中取出处于空闲状态的代理线程，将历史数据请求交由其处理。 

代理线程之间彼此独立，负责某一个历史数据请求的处理。代理线程负责接收、解析、处理和返回请求。 

上述代理机制包含了以下数据结构： 

代理框架的各属性定义如下： 

代理线程的各属性定义如下： 

历史数据请求封装的各属性定义如下： 

历史数据结果封装的各属性定义如下： 

三、完成历史数据发布的交互过程 

通过建立上述两个过程，建立了实现历史数据发布的设施如图3所示： 

图中，水库历史请求客户端6，历史发布Web服务7，历史代理配置列表8，水库历史代理框架9，水库历史代理线程10。 

提供了历史数据请求方调用的Web服务接口以及代理机制的支撑。实现了历史数据发布的交互过程包含了历史数据请求方6与历史数据发布服务7之间的交互、历史数据发布服务7与代理框架9之间的交互两个过程，下面以一个实现水库历史数据发布的具体过程进行说明。水库历史数据发布包含以下四个步骤： 

1)水库历史请求客户端6获取历史数据发布Web服务7的访问接口，并向该接口发送请求水库历史数据的soap消息； 

2）历史发布Web服务7接受到请求，分析通过查找历史代理配置列表8获取水库历史数据请求对应的水库历史代理框架9，向远方水库历史代理框架9发出的历史获取请求的Socket消息。 

3）水库历史代理框架9收到请求，分配给一个水库历史数据代理线程10在本地完成历史数据的查找与处理，并将结果通过Socket消息返回给历史数据发布Web服务7； 

4)历史数据发布Web服务7收到代理返回的结果再进行解析，生成最终返 回结果通过soap消息返回水库历史数据请求客户端6。 

步骤1）中水库历史请求客户端6向历史数据发布Web服务7发送的soap（简单对象访问协议）消息是一种XML格式的数据，本例中soap消息的形式如下： 

此soap消息中主要的信息包含在<mes:Header>元素体中，包括了<mes:Verb>动词，<mes:Noun>名词，<mes:User>用户，<mes:Request>过滤条件，<mes:User>又包含了<mes:UserID>用户标识以及<mes:Organization>用户厂家，<mes:Request>又包含了<mes:StartTime>起始时间，<mes:EndTime>结束时间，<mes:ID>对象GID，<soa:HisDataType>历史数据类型，其中 <soa:HisDataType>包含了两个元素，表明要求的是每个小时的历史数据以及该数据产生的时间。 

步骤2）中历史发布Web服务7针对每一种历史数据请求分配一个历史数据代理，向其发送历史数据请求，具体的请求使用JSON对象。JSON采用完全独立于语言的文本格式，易于人阅读和编写，同时也易于机器解析和生成。本例中历史发布Web服务7发送的JSON对象消息形式如下： 

步骤3）中水库历史数据代理线程10返回的JSON消息形式如下： 

步骤4）历史发布Web服务7返回给水库历史数据客户端6的soap消息形 

式如下： 

。