基于soa的水利枢纽信息系统的功能划分与层次设计

《基于soa的水利枢纽信息系统的功能划分与层次设计》由会员分享，可在线阅读，更多相关《基于soa的水利枢纽信息系统的功能划分与层次设计（6页珍藏版）》请在金锄头文库上搜索。

1、http:/ -1- 1基于基于 SOA 的水利枢纽信息系统的功能划分与层次设计的水利枢纽信息系统的功能划分与层次设计1 高伟 河海大学计算机及信息工程学院，南京（210098） E-mail： 摘摘 要：要： 本文分析了我国目前水利枢纽信息系统集成中存在的问题， 介绍了面向服务的设计 思想与标准，说明了 SOA（Service oriented architecture，面向服务架构）在水利枢纽信息化 集成设计中的作用，提出了基于 SOA 的水利枢纽信息系统设计层次，表明了充分用已有的 信息系统，复用现有的服务，进行基于 SOA 的水利枢纽信息系统集成的优势。 关键词：关键词：SOA，水利枢

2、纽，信息系统集成 1引言引言 水利枢纽信息系统经过多年的发展在水利监测控制、 事务管理、 防汛信息广域网等方面的信息技术应用是相对独立的，信息系统缺少统一规划, 信息不能共享的矛盾日益突出。已有的信息系统中的多个应用之间有很多信息与数据相互交叉,甚至重复。这造成了相互之间信息与数据的更新不同步、不一致，不便于信息的操作与管理1。 解决以上矛盾, 一种办法是推倒当前已有系统重头再来, 但那成本太高, 实现周期过长, 不符合实际。从整体来考虑我国水利枢纽信息化需求, 根据实际情况对各个信息系统进行总体规划, 选择合适的集成平台, 将其集成起来, 这种方法不管是从实施难度还是实施成本还是技术上考虑都

3、是可行的。 传统的企业应用集成(EAI)是基于消息总线/代理或者中间件的, 它们一般采用了DCOM/CORBA/EJB/MOM 等分布式技术。其缺点是与原有体系结构耦合过于紧密, 不具灵活性, 高成本且实现复杂。 采用面向服务架 SOA(Service Oriented Architecture)的集成可很好解决这些问题。SOA是基于 Web Service 的最新系统继承模型。SOA 是在原有组件化和 EDI（电子数据交换）的基础上，进一步将可重复利用的软件资源抽象化和标准化，换句话说，就是抽取软件基因，建立互通的管道， 达到重复利用和信息流畅的目的， 解决业务最头疼的“适应业务变化”和“集

4、成”问题。与过去的组件化模式相比，SOA 变过去的技术组件为业务组件（即服务） ，强调的是技术无关性， 关注的是实现这样的业务功能在业务请求与响应之间随时搭建快速通道，同时，变过去的紧耦合为松耦合2，既保证系统弹性，又不失系统效率，进而实现重复利用软件资源、快速响应市场需求变化和提高生产力等目标3。 2面向服务架构面向服务架构SOA 1996年，Gartner Group提出了SOA的设想，在当时仅仅是个“预言”，那时软件发展水平和信息化程度还不足以使这样的概念走进实质性应用阶段。2002年12月，Gartner又提出了SOA是“现代应用开发领域中最重要的课题”，并且认为到2008年，SOA将

5、成为占有绝对优势的软件工程实践方法。 SOA是在计算机环境下设计、 开发、 应用和管理分散的逻辑 （服务） 的单元的一种规范。开发者利用定义好的机构封装应用， 可以将单一的应用加入到一个服务的集合中， 封装的过程创建了一个抽象的层，屏蔽了应用中的复杂的细节。面向服务架构模型如图1所示。 1本课题得到水文水资源与水利工程科学国家重点实验室开放研究基金（项目编号：2005407911）的资助。 http:/ -2- 2图1 SOA模型 SOA包含三个角色：服务注册库、服务请求者和服务提供者。 （1）服务注册库（Service Registry） 服务提供者在服务注册库发布服务描述，并允许服务请求者

6、搜索注册库所包含的服务描述。服务注册库就是服务提供者与服务请求者之间的中介。 （2）服务请求者（Service Requestor） 服务请求者查找分布在一个或多个服务注册库中的服务描述，并利用服务描述绑定或调用服务提供者提供的服务。服务请求者可以是用户人，也可以是程序。 （3）服务提供者（Service Provider） 服务提供者负责创建并在服务注册库发布服务描述，同时接受一个或多个服务请求者的调用消息，并向其提供服务。 3基于基于SOA的水利枢纽信息化集成的功能划分与层次设计的水利枢纽信息化集成的功能划分与层次设计 3.1 需求分析与功能划分需求分析与功能划分 水利枢纽信息系统总任务一

7、般是建设一个以水情采集传输系统、运行监控系统为基础，计算机通信网络和综合数据库为支撑环境， 防洪决策支持， 水资源优化配置和调度运行监控系统为核心任务的水资源多目标管理调度的决策支持系统工程， 是一个多层次、 多环节和多专业的相互关联的复杂系统4。 根据水利枢纽调度实际应用需求，我们抽象出了一般水利枢纽信息系统基本元素5个主要的子系统：防洪调度及水资源配置分系统、调度管理分系统、安全保障分系统、综合信息服务分系统和系统管理分系统。 （1）防洪调度及水资源配置分系统包括：防洪调度及水资源配置查询模块，防洪调度及水资源配置仿真与优化模块，防洪人力、物资查询及值班记录处理模块，防洪调度与水资源管理决

8、策支持模块，水文信息及气象信息处理模块和调度运行模块。 防洪调度及水资源配置查询模块主要功能：提供实时水雨情、工情、气象、上级通报及调度等信息的查询。 水文信息及气象信息的处理模块主要功能： 水文信息是保证枢纽安全和枢纽正常运行的重要资料。 收集与处理水文信息是水文站工作的主要内容。 调度管理系统对水文站现有的自动观测数据与现有的人工采集数据集成到一起， 对历史水文信息提供了管理手段， 使水文数据能更好的为枢纽调度运行服务。 防洪人力、 物资查询及值班记录处理模块主要功能： 为防洪值班机构提供防洪人员安排Service Registry 服务注册库 Service Requestor 服务请求

9、者 Service Provider 服务提供者 服务 查找 服务 发布 服务绑定 http:/ -3- 3表建立与查询，防洪调度物资管理查询以及防洪值班记录功能。 防洪调度与水资源管理决策支持模块主要功能： 提供洪水生成及演进模型， 根据区域水雨情信息、上游来水等情况对枢纽水情做出预报，为枢纽的调度运行提供参考，为调度人员提供服务。 防洪调度及水资源配置仿真与优化模块主要功能： 提供多种手段把抽象的洪水演进过程按时间顺序以形象的方式展示出来，使调度人员可以直观地了解洪水发生、发展的情况，利于枢纽的安全运行。 运行调度模块主要功能： 实现运行调度管理， 原则上以防办为核心并以操作票的形式下达调

10、度任务。 （2）调度管理分系统包括：仓库管理模块，人员管理模块和工程项目管理模块等。主要功能：负责综合服务中心仓库的管理，提供当前库存信息；实现整个管理处人员基本资料的管理和实现工程申报书等。 （3）安全保障分系统包括：汛前、汛期检查模块和安全生产管理模块。主要功能：记录水利枢纽各设备、设施在汛前、汛期的检查检修情况。 （4）综合信息服务分系统包括：全局数据查询模块，全局数据维护模块，Web 信息发布模块，GIS 模块，报表展示模块，OLAP 模块和数据挖掘模块。主要功能：提供全局信息的查询、GIS 观察、报表、OLAP、数据挖掘中用到的灌区数据、船闸等数据；对内信息发布的 Web 平台管理。

11、 （5） 系统管理分系统包括： 数据安全管理模块， 数据字典维护模块， 系统日志维护模块，数据抽取与刷新模块，邮件管理模块和菜单管理和系统参数设置模块。主要功能：管理本系统所有操作人员的帐号和权限； 数据字典的维护； 数据库备份， 恢复的记录， 查询系统日志，根据系统日志掌握系统运行情况； 从各分系统抽取数据建立综合数据库， 在综合数据库基础上建立综合数据仓库和数据集市； 邮件的发送， 邮件的接受和邮箱的管理和系统菜单的管理和系统初始参数的设置。 32 设计层次设计层次 综合来看，系统集成需要整合现有的业务组件，实现上述常规功能，提供开放性的数据接口给其他相关单位，进行能动查询和继承。此外，还

12、要集成其他单位（如气象局）的信息到本系统中。这是个典型的跨部门、跨平台的水利枢纽信息化集成系统，需要解决防火墙间的数据通讯和异构系统间的互操作性等方面的问题。 基于SOA的水利枢纽信息化集成设计示意图如图2所示。 （1）UDDI(Universal Description Discovery and Integration) UDDI即通用描述、 发现和集成是为实现广泛环境的服务的发现与集成而制定的Web服务规范。 （2）私有UDDI注册库(Private UDDI Registry) 为内部系统调用的服务被发布到这一类UDDI节点。这类UDDI节点位于防火墙后，允许服务发布者对它们的服务注册

13、库的访问权、可用性及发布有更多的控制。使用J2EE等应用服务器都提供这种功能的私有注册库，也可以下载一些专门的软件。 （3）公有UDDI注册库（Public UDDI Registry ） 一般由大的公司或个人发布，可以在互联网上查找和使用的Web Services,使用公有 http:/ -4- 4图2 基于SOA的水利枢纽信息化集成体系设计示意图 UDDI注册库。在水利枢纽信息集成系统中也可以设置，通过它来实现各水电站间的信息交互与Web服务获取。 （4）WSDL(Web Service Description Language) WSDL即网络描述语言，用于描述web服务及其函数、参数和

14、返回值。它将Web服务描述定义为一组服务访问点， 客户端可以通过这些服务访问点对面向文档信息或面向过程调用的服务进行访问。 开发者将单一的应用加入到一个服务的集合中， 与其相关的是服务所描述的接口。 在不用修改现有系统架构的情况下，SOA可以将信息系统迅速转换为服务。在面向服务架构中，服务是封装成用于业务流程的可重用组件的应用程序函数， 目标是在软件代理交互中获得松散耦合。封装的过程创建了一个抽象的层，屏蔽了应用中复杂的细节。服务提供者响应服务请求者的命令并为服务请求者的请求提供高质量的服务。 上述标准将水利枢纽的管理职能划分为防洪调度及水资源配置、调度管理、安全保障、综合信息服务、系统管理员

15、等多个分系统，将各分系统与相对应的服务绑定。各分系统之间Private UDDI Registry WSDL 绑定信 息 外部 Web 用户其他服务防洪调度及 水资源配置 Web 服务 用户Public UDDI Registry WSDL 绑 定信息 Web 防 火 墙 调度管理 Web 服务 安全保障 Web 服务 综合信息服 务Web服务系统管理员 Web 服务 调度管理分 系统 安全保障分 系统 综合信息服 务分系统 系统管理员 分系统 安全保障数 据库 综合信息服 务数据库 系统管理员 数据库 防洪调度及 水资源配置 分系统 调度管理数 据库 防洪调度及 水资源配置 数据库 http

16、:/ -5- 5通过内部的私有 UDDI 注册库发布、 查找并调用相互之间的服务。 各分系统既是服务提供者为其他分系统提供数据信息服务， 同时又作为服务请求者获得自身所需的数据信息服务。 同时该系统作为一个整体通过公有水电站 UDDI 注册库发布该系统对外的服务， 外部的服务请求者可以是人（其他水利枢纽机构人员等）也可以是程序（其他水利枢纽信息系统应用程序等） 。服务的信息包括与所需服务交互所必要的信息如服务定位、传输协议、消息格式等。服务请求者提供服务标准，服务注册库根据服务请求者提供的标准在所发布的 Web 服务中进行匹配，查找与标准相匹配的服务并将结果通知服务请求者。当然，外部的服务请求者不需要知道系统内部的情况，只要通过公有 UDDI 注册库发现所需的服务并与该服务进行绑定，就如同客户机服务器模式。 在该信