SOA信息平台（共7篇）
SOA信息平台 篇1
摘要：针对当前医疗信息系统的整合重点, 建立协同的医疗信息共享平台, 设计了基于SOA的医疗信息共享平台架构, 并讨论了实现方法。对构建区域型的医疗信息系统共享提供参考。
关键词：SOA,医疗信息共享
1、引言
现有的医院信息系统大多采用面向对象模型的3层体系架构, 甚至还有部分系统停留在双层体系架构之上。这些体系架构都属于紧耦合的应用系统集成方式, 由于各个集成系统之间紧密集成, 降低了应用系统的灵活性和扩展性, 增加了整个系统维护的难度, 阻碍业务的流程调整和优化, 不利于医院业务长期发展, 而基于SOA的医疗信息系统集成结构具有松耦合、定制灵活的特点.并且由于统一的集成模式, 使得信息共享的一致性成为可能。
2、面向服务的体系结构SOA
面向服务的体系结构 (SOA) 是一个组件模型, 它将应用程序的不同功能单元 (服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
3、医疗信息共享平台方案设计
如何设计一个横向能够有效地承载不断增加的多个医院异构系统在同一平台上的信息交换与共享, 纵向能够承载应用的不断深化和提升, 是技术上需要考虑的核心问题。
3.1 框架设计
在设计中, 基于SOA理念设计的医疗信息共享平台, 其技术架构为一个六层的分层服务组合框架, 包括:医院信息访问网关、企业服务总线、基于HL7 RIM的临床数据存储模型、工作流引擎、公用基础服务组件和业务服务组件、应用服务项目和信息访问门户组成。每个服务都是相对独立的应用, 并采用基于消息的松耦合技术, 通过服务总线实现应用之间的业务协作。
最底层是部署在各家医院的前置机, 作为医院信息访问网关, 负责与医院各业务系统的交互。基于IBM适配器技术的医院信息访问网关由应用适配器、前置服务代理、消息传递服务三部分核心模块组成。应用适配器是通过业务对象来描述系统的交互接口模型。由适配器方式采集后的数据, 通过前置服务代理模块实施数据的清洗, 封装为XML消息格式;然后通过IBM的MQ传输链路, 实现前置机至中心端的消息传递服务, 完成数据上传工作。针对医学影像传输, 是在中心端架设FTP服务器, 由前置机将影像定期传至中心端服务器, 并以文件形式存储。
第二层企业服务总线作为整个架构的核心, 负责聚合应用接口层接入的整合点, 进行服务之间的协调中介。本项目是采用IBM的MB (Web Sphere Message Broker) 产品作为共享平台的企业服务总线解决方案, 其主要功能:一是提供消息转换功能, 对MQ上传的数据进行清洗和标准化处理;二是路由, 对转换的数据指定输出, 决定每一个具体的业务操作或数据究竟连接到哪里, 如何配置到指定的数据库或应用服务等;三是内嵌对Web Service的支持, 支持访问已有服务 (Web Service) 的交互, 支持把消息处理流程暴露成Web Service, 并且内嵌对服务注册和管理中间件交互和访问的支持:四是统一的消息监控、日志管理, 可以在MB处理流程中增加监控节点, 日志节点, 以MB为依托做到统一管理, 目前的MB平台提供一些基本的监控和日志查看功能, 将各类服务管理起来。
第三层是在企业服务总线基础上, 采用基于HL7 RIM的Oracle HTB (Healthcare Transaction Base) 产品作为临床数据存储模型, 负责管理和存储不断发展变化的临床数据。整体模型分为三部分, 每一部分自成体系, 通过每次医疗卫生活动进行关联。核心部分为临床医疗活动, 一方面, HL7 V3 RIM模型对医疗业务做了高度抽象, 可以对任何一个具体的RMIM模型连接与加入新的属性;另一方面, 由PMI模块完成对患者与病历的关联关系管理;再一方面, 方便的在医疗活动中加入新的活动, 以适应临床数据的复杂性和不确定性。
第四层通过基于IBM Smart Workflow成熟资产的工作流引擎设计, 负责提供整合应用程序的方法, 以及提供将应用程序封装为更大粒度服务的方法。业务需求的变化有两个方面, 一是业务本身发生变化, 二是业务流程发生变化, 将这些变化管理起来, 管理可持续优化的业务模型, 是工作流引擎的关注点。
第五层在上述基础上, 提供各类组件服务。一是公共基础服务组件;二是对医疗信息共享平台涉及的业务进行分析和抽象, 形成业务服务组件, 包括:患者基本信息调度服务、患者就诊记录调度服务等, 为上层的业务功能构建提供服务。
最顶层是在服务组件之上提供基于IBM Portal/WAS技术的门户功能, 实现信息发布调阅服务及用户管理认证服务。
3.2 医疗机构应用服务封装与组合
第二层ESB (企业服务总线) 作为整个架构的核心, 负责聚合应用接口层接入的整合点, 进行服务之间的协调中介。将各医疗机构的各种业务系统需要通过ESB节点适配器组件来连接ESB总线, 通过各系统与总线的业务流程和数据交换来实现各业务系统之间交互服务。
3.2.1 应用服务分析
采用自下而上的方式, 列举出医院中实际运行的系统, 并将这些系统对应到候选服务的列表, 运用SOA的思想, 细化功能模块, 将功能模块做为服务暴露出来, 以供其它应用程序通过ESB总线调用。
在设计过程中可使用工厂模式和适配器模式, 这些模式能够有效地加强系统的结构灵活性, 减少系统后期的维护复杂性。以下举例工厂方法在SOA架构平台的应用。如图1所示:
图1是信息共享平台中工厂模式的典型应用, 图中的Service Factory类就是一个工厂类, 其功能是根据配置或输入参数制造出所需要的实体类。LISWeb Service和Hl SWeb Servlce是两个实体类, 分别是检验系统和医院信息系统暴露的类封装。
3.2.2 服务调用流程
完成医疗机构应用封装并接入ESB后, 业务系统之间就可以实现应用调用。以LIS系统通过调用HIS系统病人基本数据服务的情况为例, 调用过程如下:假设医院的HIS系统己经将病人基本数据服务注册到ESB服务总线上。服务请求者 (LIS系统通过适配器组件用WSDL描述需要访问的服务, 用SOAP消息向ESB总线发出查询病人基本数据请求;LIS系统发出的请求经系统认证授权, ESB总线会根据请求查询到总线上注册病人基本数据服务, 并将LIS系统发出的消息转换成HIS系统发布服务所要求的数据格式, 并将该服务请求向HIS系统发出相应的SOAP请求消息;经ESB总线发出的请求消息通过适配器组件传递给HIS系统, HIS系统则根据该消息将病人的结果通过适配器组件以HIS系统发布的Web服务转换成符合HL7标准的XML文档, 然后封装成SOAP消息;该SOAP消息会传递回ESB总线, ESB总线则将结果转换为LIS系统所能识别的数据格式并以SOAP消息封装传回给LIS系统。
3.2.3 新增业务绑定实例
基于SOA灵活的架构使得任何新增的业务环节, 都可以以服务的形式发布, 其它业务流程只需要经过ESB总线进行调用。以为病人转检增加审计环节为例, 如下图2是在病人转检的业务流程中增加审计环节时, 系统框架中的企业服务总线与工作流引擎的服务组合过程实例。
病人转检的业务流程中需要增加审计环节时, ESB (企业服务总线) 可配置一个对审计数据库的整合模式, 连接到相应的审计数据库后, 可按标准数据格式进行交互式操作 (读取或插入数据) ;交互过程中, 直接在基于工作流引擎的流程管理平台上配置一个节点去映射这个动作即可。
通过这种服务组合方式, 可轻松应对业务需求的变化, 直接实施IT系统的转向支撑。
4、小结
本文针对当前医疗信息系统的整合重点, 建立协同的医疗信息共享平台做了重点讨论, 设计了基于SOA的医疗信息共享平台架构, 并讨论了实现方法。对构建区域型的医疗信息系统共享提供参考。
参考文献
[1]毛新生, SOA原理方法实践[M], 北京:电子工业出版社, 2007
[2]梁爱虎, SOA思想、技术与系统集成应用详解[M], 北京:电子工业出版社, 2007
[3]陈功, 于洁, 余泰兰, 等。医疗数据集成平台的扩展功能和设计[J]。医疗卫生装备, 2009, 7 (39) :59-61。
SOA信息平台 篇2
现代发电公司防汛调度信息系统主要进行与水库和电网运行有关的监视、预报、调度、交换和管理。该系统基于对历史资料的收集整理，通过实时水文、气象、闸门控制系统、机组监控系统、水库运行信息和电网运行数据的自动采集，利用先进的计算机技术，进行在线水文预报、防洪调度、发电调度、水务综合管理、节水增发电考核、值班日志管理等，提供满足防洪、发电及其他综合利用要求的调度决策方案，同时支持水电厂和电网的经济调度，进一步搞好水能优化、防汛调度等工作。
软件平台是防汛调度信息系统的核心内容，因此本文就防汛调度信息系统的软件平台(以下简称“防汛调度信息平台”)的建设问题展开讨论。防汛调度信息平台建设过程中，主要面临以下几个方面的难点问题：
(1)数据资源分布性强，网络结构复杂，数据采集实时性要求高;
(2)已有系统建设差异性强，开发标准、数据格式不统一，系统集成难度高;
(3)防汛调度领域软件建设重复性强，可继承性差，无法满足各类复杂防汛调度应用对于软件快速组装、灵活变化的需求。
为了解决上述问题，采用了面向服务的体系结构 (S e r v i c eOriented Architecture, SOA) ，科学地分析了防汛调度信息系统的业务需求，在满足防汛调度实际需求的前提下，提高软件开发效率以及复用度，为实现防汛调度领域的信息资源高度共享、软件资源高度共享提供了实际的参考。
1 基于SOA的平台框架
在SOA体系结构中，服务提供者创建服务，并通过注册机制发布服务的描述;服务使用者通过发现机制发现服务并通过定位机制使用服务，服务的注册、发现和定位都是通过标准的XML格式进行。
SOA通过2个约束实现软件代理之间的松耦合：一是所有参与软件都遵循一个简单统一的接口集合，接口被赋予通用的语义，所有的服务提供者和服务消费者都能使用;二是通过该接口传递的参数遵循一个可扩展的消息描述规范，有特定的词汇和结构，可扩展机制允许新服务的引入不破坏已有的服务。
通过使用SOA体系框架，可以将防汛调度信息平台中的各类软件模块组件化，提供标准的访问接口，统一注册，这样既提高了软件的复用度，也提高了信息资源的共享度。
基于SOA体系框架的平台组成要素如图1所示，可以满足防汛调度信息平台建设的需求。
2 防汛调度信息平台总体功能架构
为了满足防汛调度业务的需求，防汛调度业务应用软件主要包含防汛值班台系统、Web信息发布系统、防汛会商系统、实时信息查询系统、水务管理系统、节水增发电系统、防洪调度系统、发电调度系统、资料管理系统、综合管理平台等。
通过抽取防汛调度应用软件中公共的部分，以构件化程序设计方法，形成应用支撑的各类服务组件。经过深入分析，得出了整个防汛调度信息平台软件的体系结构如图2所示。
防汛调度信息平台由数据汇集平台、数据库及应用支撑平台(“两台一库”)构成。
应用支撑平台包括资源管理、信息交换与共享、软件构件、模型和数据存取等部分，为防汛指挥和发电调度等业务处理提供信息及软件资源支撑服务。根据应用支撑平台的各种服务在应用层次上所处的逻辑位置，所有的服务又分为面向系统资源的服务要素、面向公共基础的服务单元、面向应用的服务组件3个层次。
数据库系统是防汛调度信息平台的核心部分，所有系统数据都持久化存储在数据库中，防汛调度信息平台及相关的功能也是以系统数据为中心。防汛调度信息平台数据库采用分层的设计模式，具备良好的一致性、完整性、可扩展性和易用性，在兼顾现有应用的同时，提供了对未来升级进行扩展的接口。
数据汇集平台包括分中心站和各种横向系统的数据汇集，并实现基于数据分布协议的数据管理，重点是保障数据的实时性、一致性。具体任务是完成各分中心(水雨情、气象、闸门、机组监控、大坝安全、防洪及水调)数据的采集、上传到中心站并进行预处理，数据汇集平台还要完成中心站向各分中心传输数据的功能。
3 防汛调度信息平台的实现要点
防汛调度信息平台的实现，主要使用SOA的理念，依托J2EE技术体系，结合防汛调度信息平台建设中的各类难点问题，进行有针对性的设计与实现。
(1)应用支撑平台的实现。应用支撑平台的实现，必须考虑到软件复用性、可继承性以及接口通用性的问题，考虑对于不同层次的组件提供统一的访问接口，即Web Services接口，同时兼顾效率。对于一些基础组件，也提供API接口，这样对于未来系统扩展、软件资源共享提供了极大的便利，不论是本地用户还是远程用户，都可以使用应用支撑平台提供的组件，构建新的应用。
(2)数据汇集平台的实现。数据汇集平台的实现，必须考虑数据分布、异构系统集成、数据实时性等方面的问题，考虑针对不同系统，开发对应的集成代理，提供统一的数据集成接口，包括Web Servies接口和API接口，然后以标准的数据格式将信息汇集，这样既为未来新系统提供了异构系统集成的方法，也保证了本系统数据接入的一致性。数据汇集平台的实现机制如图3所示。
防汛调度信息处理软总线集成常规的数据交换技术、数据处理技术和代理技术，为数据汇集平台提供基础架构，在防汛调度信息处理软总线的基础之上，结合具体业务需求，构建数据汇集平台，并为上层的应用支撑平台提供公共的信息交换机制。
防汛调度信息处理软总线的作用主要提供上层用户配置信息与下层数据采集传输等执行模块之间的信息交换途径，软总线将各类程序功能统一抽象为“任务”，用户对任务的配置信息以及任务的运行状态、返回信息都统一抽象为“消息”，这样，用户与系统之间就可以使用统一的数据格式进行信息交换，并且由防汛调度信息处理软总线进行统一管理、调度。数据一旦变化，即可形成任务并上传。这样不仅可以保证数据的实时性，也可以保证数据的完整性、准确性、一致性。
(4)数据库系统的实现。数据库管理系统的设计是系统建设的一个重要环节，没有准确的、实时的数据采集，就谈不上信息的加工处理，因此在设计数据库时要求数据结构分明、易于管理，以最佳方式组织数据，使数据库在逻辑上划分合理，减少数据的冗余，实现数据的共享;数据库的组织要可靠性高，便于维护、扩充与更新，便于信息查询。数据库系统的实现，需要注意以下几个问题：1)数据库系统必须层次分明，合理布局，提高数据共享程度;2)保证数据结构化、规范化、编码标准化;3)尽量做到数据库的数据具有独立性，独立于应用程序;4)避免不必要的数据重复和冗余;5)保证数据的安全可靠;6)尽量保持和其他系统的数据兼容性。数据库系统的基本逻辑结构如图4所示。
系统库负责记录数据库的结构信息、访问权限信息以及系统配置信息。基本信息库负责存储系统字典信息、计算曲线信息、水库、电厂静态信息等基本信息。应用库负责存储各类业务数据。实时信息库负责存储实时上传的数据。缓冲库存储10天的实时以及1个月的时段信息等访问频率最高的一些信息，该库对于上层应用只提供读取权限。历史信息库负责存储整理之后的历史信息。
在物理设计上，可以采用分区以及索引等技术对数据库进行一定程度的优化，以达到最优的访问效率。
4 防汛调度信息平台的实际应用
基于SOA的防汛调度信息平台在华电福建发电有限公司得到了有效应用，满足了防洪、发电及其他综合调度决策方案要求，同时支持水电厂和电网的经济调度，对进一步搞好水能优化、防汛调度等工作提供了重要的支持，经济效益和社会效益显著。该工程具有以下几个方面的显著技术特点。
(1)数据采集系统采用了分布式主动同步技术，实现了将全网数千个站点数据的快速、准确汇集;实现了面向水利水电行业用户的报表制作语言解析技术的应用，提供了所见即所得的报表制作工具。
(2)系统平台遵循J2EE架构，构建了基于SOA的B/S结构与C/S结构相结合的防汛调度信息系统平台，实现了一源多用、功能复用。
(3)水库调度应用，以分层理念进行尺度划分，建立多维模型设置，按照资源优化和市场运作规律，科学合理地组织、指挥和协调公司管辖范围内各水电站发电设备的运行和操作，在发挥防洪效益的同时兼顾发电效益的提升，实现对所属水电站的统一联合优化调度。
5 结语
防汛调度信息平台可以为各类防汛调度业务提供规范、统一的软件支撑，从而能够灵活配置功能，减少软件的重复开发，提升防汛调度领域的数据、软件共享度。有了这样一种平台，就可以建立防汛调度业务基础设施，统一各级防汛调度单位的软件开发、系统构建标准，同时，有利于建立一体化的防汛调度系统，是提升防汛调度领域软件建设水平，解决防汛调度领域数据集成、系统集成问题的有效途径。
摘要：采用面向服务的体系结构 (Service-Oriented Architecture, SOA) , 科学地分析防汛调度信息系统的业务需求, 结合组件化与构件化的分析方法, 解决防汛调度信息平台建设过程中面临的难点问题。在满足防汛调度实际需求的前提下, 提高软件开发效率以及复用度, 为实现防汛调度领域的信息资源及软件资源高度共享提供了实际的参考。
关键词：防汛调度,应用支撑,数据汇集,软总线,SOA
参考文献
[1]马增辉, 解建仓, 张永进.基于SOA的水利构件研究[J].西安理工大学学报, 2008 (4) .
SOA信息平台 篇3
当前我国电网企业发展势头迅猛,企业规模不断扩大,企业信息系统的类别及数量也呈明显的上升趋势。电网企业的各个业务系统都有着相互独立的运行机制和管理策略,过去电网企业缺少系统间的集成技术,导致电网企业的信息管理工作相对封闭,部门间缺乏紧密有效的联系,造成了传统电网企业“信息孤岛”的问题,导致电网企业管理效率低下,严重影响了电网企业综合效益的提升。随着科技的创新发展,信息化技术手段与电网企业的联系日益紧密,电网企业越来越认识到了信息集成的重要性,因此,电网企业信息集成平台项目的建设具有十分重要的意义。电网企业信息集成的发展主要经历了数据集成阶段、应用集成阶段和业务流程集成阶段。
1 SOA架构的优势分析
基于上文对电网企业信息集成发展的概述,在企业实际需求及信息技术发展的带动下,企业信息集成平台项目的建设发展势头良好,而基于SOA理念的集成模式,更是行业关注的热点。所谓SOA,指的是面向服务的体系结构,它属于组件模型中的一种,在当前应用较为普遍。基于SOA的架构,可以把应用程序的不同功能单元转化为服务,再利用定义服务之间良好的接口与契约实现系统间的联系,从而使系统可以利用统一便捷的方式实现交互。基于SOA架构的电网企业信息集成平台,可以有效解决电网企业“信息孤岛”问题,处理好信息共享及业务集成等诸多问题,推动电网企业信息化的建设与发展。
结合具体实践应用来看,SOA架构的优势有:(1)能够充分利用企业的现有设备,以业务需求带动SOA集成平台发展;(2)能够保障企业信息化项目的经济效益,减少投资成本,提升数据资源的利用效率;(3)架构部署的适应性强,便于系统集成和管理;(4)有助于推动企业业务逻辑的可持续发展。
2 基于SOA的电网企业信息集成平台设计
2.1 信息集成平台的内容
结合电网实际需求总结信息集成平台的内容,应包括以下几个方面:(1)信息资源内容。它为信息集成平台提供了数据、服务及业务资源等,同时还可作为应用系统等。(2)资源配适内容。将非标准化资源转化为标准化资源。(3)基础支撑内容。它是平台的底层保障,对外体现为API数据包。(4)核心处理内容。它是平台核心功能模块,起到了对关键数据的处理管控作用。(5)流程集成内容。基于服务方式实现信息集成应用开发。(6)平台管理内容。利用人机交互界面对平台统一管理。(7)集成应用内容。它是基于信息集成平台的对外扩展应用。
2.2 平台功能体系的设计
结合电网企业的实际需要,在平台功能结构上主要进行了以下设计:(1)集中管理控制平台设计。这部分设计实现了对整个平台的一体化管控,管理者利用人机交互界面,就能够实现一体化的管理,其范围涵盖了服务资产管理、管控流程、服务/流程监控、流程集成管理和系统管理等内容。(2)企业服务总线设计。这是企业信息集成平台的核心内容,在功能上涵盖了基础服务、数据处理等方面的内容。基于SOA架构的设计理念,把信息、服务、数据等内容交互过程抽象化、解耦,对组件方式进行灵活的流程定义,并通过Web Service支持扩展。(3)资源配适器的设计。这部分内容的设计可以实现外部的异构信息资源集成化,有助于对平台自身进行扩展。这一部分设计的关键点在于标准Web Service模式的转换过程。(4)流程集成引擎、工具的设计。这一部分的设计主要是基于企业服务总线,实现对流程的编排、调度、管理,对平台各应用流程进行集成管理,涵盖建模、设计、开发、测试、调试等诸多环节。
2.3 平台架构的设计
基于SOA架构理念,结合电网企业信息集成的需求,可将信息集成平台主要设计为以下7层架构:(1)电力信息系统层,这一层所涵盖的内容是企业现有系统资源;(2)服务层,这一层主要是利用不同的功能组件实现不同服务;(3)组件层,利用组件对底层系统进行封装;(4)业务层,利用服务来达到实际业务要求;(5)服务总线层,该层主要通过提供各种总线,来满足信息系统集成的要求;(6)表示层,通过对用户提供服务接口满足构建门户系统的要求;(7)辅助层,主要是实现信息集成平台的辅助功能。
3 基于SOA的电网企业信息集成平台的实现
就电网企业信息集成平台的实现而言,主要可以从以下几个方面入手:
3.1 对信息集成平台的数据环境进行设计
首先,结合电网企业的信息资源规划建立数据服务,在此基础上打造一个客观、科学的数据环境,进而对电网企业的公共信息模型进行开发,为开发数据服务功能提供坚实的保障。其次,包含电网企业公共信息模型的功能模块,能够完整地展示平台业务实体和服务,此外还有对应服务接口的设置。一般而言,所有系统都是由众多部分组成的复合体,各部分间既有联系,又可利用前端服务程序给用户提供对应服务。最后,在系统分析过程中也会对系统业务及数据情况进行分析,借此来明确在底层服务中发挥功效的数据与分布式组件。另外,使接口能被其他系统调用,且这一目的的实现不必建立在系统平台、实现语言等基础上。
3.2 对电网企业信息数据资源进行盘点
一方面,结合电网企业自身的实际情况,总结当前企业信息数据与系统访问资源,对于现有的全部资源,都应明确它的支撑源数据,对其做到深入细致的了解。
另一方面,要做好数据资源的管理工作,加强对企业数据信息资源的盘点,明确其来源、去向、存储区域等内容,规范数据资源的语法和语义,为企业信息集成平台的实现打好基础。
3.3 对信息集成平台的数据进行建模
这一阶段所包含的任务主要有两个方面,一是对物理数据进行建模,二是对逻辑数据进行建模,二者共同构成了平台数据建模。前者强调的是建模直接面对数据源自身,能够通过众多工具盒技术对数据源进行映射,进而满足底层细节与通信协议的抽象化和封装要求。后者的建模则主要是通过电网企业自身的统一数据模型来实现,满足对众多物理数据服务集合的管理需求。其中,数据服务主要涵盖了业务、管理、集成、数据等四方面的规则。
3.4 电网企业信息集成平台的开发与集成
在这一阶段,进行数据描述时需要用到服务数据对象统一的数据格式,具体包括数据源、数据图、数据中介服务、数据对象、变更摘要、类型、序列、属性等诸多方面的信息。
4 结语
综上所述,将SOA架构应用于电网企业的信息集成平台中,发挥SOA构架下信息集成平台的优势,可以实现电网企业信息资源的整合,有效解决电网企业在信息交互数据及系统业务流程等诸多方面的问题,有助于消除“信息孤岛”现象,构建新时期高度集约化的电网企业。电网企业的信息集成化发展是当前行业内的热点内容,同时企业信息集成平台的构建也是一项系统且复杂的工作,这就有待电网企业在实践中对信息集成平台不断进行优化,从而推动电网企业的发展不断迈向新高度。
参考文献
[1]郑声俊,何启远,郑桢,等.基于SOA的企业信息集成平台的研究与实现[J].电力信息与通信技术,2014,12(4):66-70.
[2]丘裕新.基于SOA架构的电网企业信息系统集成的研究与应用[J].电子技术与软件工程,2014(18):204.
[3]刘宁,祝唯微,卫祥.SOA架构在电力企业信息集成中的应用[J].电力信息与通信技术,2013,11(10):109-112.
SOA信息平台 篇4
铁路运输和水路运输是综合运输体系的重要组成部分,在大宗散货和长距离货物运输中发挥了重要的作用。铁水联运可以有效地优化运输通道布局、减少运输环节、缩短运输周期、提高运输效率、降低运输费用、促进节能减排。在经济全球化和电子商务环境下,信息化的铁水联运是一个在新的业务流程指导下的复杂的物流、信息流和资金流相互交织的动态随机过程。铁水联运信息系统是一个复杂的巨系统,除了一般信息系统的特点(模块化、网络化、智能化)外,还必须具有集成性、动态性、实时性等特点。现有的铁路和港口管理信息系统的发展还不是很完善,特别在业务流程整合和信息共享上,没有标准化的接口和规范。铁水联运信息系统的建设必须在充分研究现有系统的基础上,制定统一的数据和流程规范,通过信息集成与共享,提升铁水联运体系的全程信息服务质量和联运作业效率。铁水联运信息系统是铁水联运物流信息整合的关键[1]。
2 基于SOA和DDD的系统构架设计
铁水联运信息平台作为第三方信息交换和管理系统,其设计应具有开放性、模块化、适应性与及时性等特点;应尽可能兼容已有技术及已开发的系统,并与之实现无缝对接。SOA作为一个组件模型,将应用程序的不同功能单元抽象成服务,通过将这些服务之间定义良好的接口和契约进行联系。接口采用中立方式定义,独立于实现服务的硬件平台、操作系统和编程语言,使构建在不同子系统及外部系统中的服务可以以一种统一和通用的方式进行交互。SOA是目前最先进的方法论并成为提升下一代铁水联运信息平台能力的引擎,它使IT部门可以搭建灵活的可配置体系以支持随需应变的运输业务。ESB作为SOA的核心构件,对信息转换,消息路由和流程整合提供强大支持,基于配置的开发方式也为系统整合提供了极大便利性。基于DDD的建模框架通过领域分析来代替传统的开发方式,将业务内聚到领域模型,让系统设计和开发人员能够更清楚直接地关注业务本身的内容,准确地进行业务系统设计与开发,同时以非数据库为核心的构架也能够更好地实施TDD(Test Driving Development),保证系统的质量和对需求变更的敏捷性[2,3,4]。本文结合SOA提出了一个新型的、替代传统EDI方式的铁水联运信息平台架构,并且结合自主设计的Takia-DDD开发框架实现了联运信息平台的开发体系,将内部信息系统设计和外部系统的数据交换和业务协同进行了无缝集成和统一架构支持。
2.1 铁水联运信息平台构架总体结构设计
基于上述分析,铁水联运信息平台是一个典型的信息集成系统,在其建立之前必须充分考虑现有系统,不同的数据规范造成比较严重的信息交换障碍,同时联运业务的性质本身决定其是一个跨系统的分布式流程,增加了整合难度。如何在保证信息交换和集成的基础上,对联运信息平台各层次业务系统有效地解耦,是平台建设成败的关键。鉴于铁水联运体系建设中存在的这两个主要问题,本文结合SOA构架和DDD模型,提出铁水联运信息平台的整体构架方案如图1所示。
由图1可以看出,总体系统架构主要由展现层、平台业务管理层和SOA核心能力层组成,其中通过门户实现统一用户接入。该模块主要包含用户信息管理和存储、用户登录身份认证和访问请求负载均衡等部分。平台业务管理层主要包括了物流业务管理,电子商务,客户服务和物流决策等业务支撑系统[5,6]。本文与传统方式不同,业务层没有采用分层结构,而是采用以DDD为核心的总线结构进行构架设计,各业务子系统间、业务系统同SOA、GIS间均通过域模型的消息框架进行数据交换,有效实现模块解耦和异步数据处理。SOA核心能力层由企业服务总线(ESB)、服务管理、注册库以及组合服务运行引擎几部分组成。其中,企业服务总线(ESB)是SOA核心能力层的核心组件,主要完成消息转换和路由,ESB负责接入各种服务资源,通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问,以星形结构替代了原来各服务之间的点对点结构,有效地优化系统连接架构,降低系统集成的复杂度。企业服务总线下方连入的是现有内部用系统,这些系统通过局域网直接接入ESB,而右边的外部系统由于在外网,需要通过外部适配器接入到ESB与内部系统无缝对接,实现平台与其他系统的信息交换。组合服务运行引擎运行在标准的BPEL流程引擎之上,提供跨系统的流程整合支持。
基于上述结构体系,项目中采用以Oracle WebCenter 11g中间件产品[7]为核心和自主Takia DDD开发框架相结合的方式设计铁水联运信息平台的技术构架如图2所示。
根据图2可以看出,技术构架采用分层的集群结构进行设计,分层设计有助于系统的角色划分和模块解耦,Oracle的产品构架对不同层次的应用系统均能提供有效的集群支持,以保证系统的稳定性。图1中的铁水联运统一门户部署在图2的OHS和WebCenter上,OHS作为单纯的Http服务器,除了负责用户的请求响应、负载均衡以外,还要与OAM一起完成权限控制的工作,WebCenter作为门户套件,负责部署和管理从业务系统抽取到门户系统的Portlet组件。图2中的WLS主机集群作为应用服务器集群主要部署图1中业务管理层的各个业务系统,Takia是一个基于Spring的自主开发框架,其中的DDD开发插件能够有效地支持基于域模型的业务系统设计和消息交换。BPM与SOA构架一起实现跨系统的工作流整合,平台的数据库采用RAC(数据存储冗余)方式设计,分布式数据库服务器与RAC可以有效地保证平台数据的稳定性和完整性,DA/ETL用于数据分析和挖掘。在用户数据管理上,该平台采用Oracle的IDM实现平台中所有系统的SSO,基于LDAP对用户数据进行集中化管理。此外内部现存系统和外部系统之间与联运平台的数据交换均通过ESB完成。除了Oracle之外,技术构架也可以选用其他商业产品或者开源构架进行构建,结构类似。
铁水联运信息平台是一个比较复杂的分布式系统,主要的业务系统在局域网内部,相互之间直接通过局域网进行通信;而外部系统,平台用户以及移动终端均在外网,必须穿过防火墙才能接入平台。结合图2基于集群的技术构架设计和对现有SOA-ESB相关文献的分析[8,9],得出平台的网络拓扑结构如图3所示。
该网络拓扑设计主要通过防火墙对内外网进行区分以保证平台安全性,通过服务器集群体系提升平台的整体性能。外部系统和用户的访问必须通过防火墙的分析,特定端口并具有权限的访问才能进入到内部系统。内部信息平台各层次的系统均采用集群结构,并且在Web网关上通过OHS实现Failover和负载均衡,保证系统的吞吐量和健壮性。对于系统之间的数据交换,内部系统与铁水联运平台的数据交换可以直接通过ESB总线完成,支持多种协议,外部系统的数据交换必须要通过外网防火墙,所以一般通过基于Http/Https协议的Web服务进行数据交换。
2.2 铁水联运信息平台的数据交换设计
作为第三方信息平台,数据交换是平台成功的关键要素,传统的信息平大多采用EDI进行数据交换,但是由于EDI协议结构繁琐,交换过程比较复杂并且不易进行扩展,本文采用开放式的SOA构架,任何标准化的服务都可以被注册到UDDI中,被其他系统调用。作为系统SOA数据交换核心ESB,可以在图2的基础上,以联运平台为核心扩展为分区域部署形式,通过对铁路和港口信息系统进行改造,抽取出各自的ESB总线,与铁水联运平台ESB形成星形结构,系统之间的数据交换可以集中到ESB后再进行传输,以增加数据交换粒度提高交换效率。扩展后的铁水联运平台能更好地关注业务协同,而将实际的数据交换,路由和转换工作完全交由ESB完成[10]。ESB未来的体系扩展结构设计如图4所示。
由图4可以看出,ESB总线部署以铁水联运平台为中心形成星形结构。不同系统之间进行数据交换时,先将数据传输到就近的ESB总线,再通过铁水联运平台的ESB总线进行数据中转,传输到目标系统的ESB中,最后再由ESB将数据转发到目标系统。以TMIS到港口信息系统的信息交换过程为例,设计铁水联运的ESB总线结构和数据交换流程如图5所示。
由图5可以看出在ESB总线系统扩展以后,铁水联运平台的ESB总线不再直接与第三方系统进行通信,而是与系统就近的总线系统进行数据交换,这样系统的数据可以先经过一次转换,使用统一的Web服务接口与铁水联运平台ESB进行通信,减小数据转换和传输压力,提高平台的整体系能。铁水联运平台的ESB总线系统由下列模块构成:
(1)用户接口模块是用户与ESB总线的联系接口,为用户提供友好的接口和良好的人机界面,实现对消息的各种统计和查询;内部消息接口用于实现铁水联运ESB系统与平台内部业务信息系统的接口。
(2)报文生成及处理模块用于接收来自用户接口模块和内部消息接口模块的命令和信息,按照ESB的消息格式生成订单、合同、发票等各种报文和单证。经过格式化处理后,由消息路由模块经由ESB网络发给其他ESB总线。同时,自动处理来自其他ESB系统发来的ESB消息。
(3)格式转换模块通过ESB适配器和总线内核对各种消息进行标准化处理后生产统一的ESB内部消息格式以便进行业务逻辑处理。
(4)消息路由模块是ESB总线内部模块之间以及与ESB通信网的通信接口。Oracle的ESB总线产品均具备强大的声明式消息路由机制,可以通过配置来设置消息的路由目的地,也可以通过编程来实现,比较灵活方便。
以铁路TMIS系统与港口系统的数据交换为例,TMIS的货运营销系统,集装箱追踪系统、货票系统都会与铁水联运平台进行数据交换,处理来自港口的ESB消息。例如进口集装箱的装箱清单,会经过港口ESB、铁水联运平台ESB和铁道部ESB后转到车站的集装箱追踪系统。同理港口系统也可以通过ESB总线从TMIS系统的货运营销系统中提取集装箱出口的计划信息;从货票系统取得出口集装箱货票信息;从集装箱追踪系统取得集装箱装箱清单等。
2.3 基于DDD的编程模式分析
与传统的分层式系统不同,本文采用DDD方式来开发和整合业务系统,采用域模型为中心的方法进行建模。领域建模与传统的数据驱动建模相比,具有更高的业务灵活性,在组件重用方面,领域分析能够更好地把握业务需求,通过对核心领域的识别和领域细化,设计重用度更高的业务系统[11,12]。在本项目中采用的是自主DDD开发框架Takia来支持域模型建模,与普通的领域驱动开发不同的是,Takia不仅支持DDD的四个基本开发元素和相关设计模式[13],还通过扩展Spring的IoC容器,实现了域模型的透明缓存支持,并基于AOP机制实现了异步的声明式消息机制,Takia同时支持JDK Future和Disruptor两种底层消息机制,实现DDD和传统开发模式的无缝结合。铁水联运平台的业务信息系统使用如图6所示的统一DDD开发模型。
从图6中可以看出，业务管理系统的模块在本文中被划分成多个领域进行开发，领域一般由领域对象（Domain Object)、值对象（Value Object)、服务（Usecase Service)和仓储（Repository) 等组件构成,领域的外围是Takia提供的透明缓存和消息系统， 根据基于Annotation的领域模型配置，使用A0P方式注人到相关的领域对象中，缓存用于提升领域对象的性能,异步的消息模型不仅可以减小领域之间的直接耦合，还能够大幅提高系统的并发性能。Takia的DDD插件支持多种缓存实现，该项目选用hCache以支持集群结构。上图中领域与外界进行通信均通过消息代理(Message Broker)完成，消息代理支持本地消息和分布式消息两种方式，本地消息用于同一虚拟机内模块间的数据交换，如访问其他领域、使用系统的公共服务等，本地消息的底层实现选用基于Disruptor的一对多消息机制，Disruptor作为LMAX的底层组件，采用RingBuffer结构对CPU的并发锁进行了有效优化,具有很好的并发性能[14]，以保障铁水联运平台在大批量数据处理过程中充分地利用CPU性能，提高业务系统和数据交换平台的吞吐量;分布式消息用于访问外部系统。在本项目中，分布式消息基本是通过JMS和Http协议转发到铁水联运平台的ESB系统中进行处理的。由于消息代理对各领域进行了充分解耦，可以很方便地使用TDD(测试驱动开发)方式完成业务系统开发，独立的领域也很容易实施单元和集成测试。 对于需求的变更，可以方便地修改、删除现有领域或增加新领域，并通过消息代理进行系统集成[15]。
摘要：铁水联运是现代信息技术的直接产物,通过信息整合,在生产和流通领域的各个行业实现智能化、及时化,从而提高经济运行的时间和空间效益。由于我国集装箱铁水联运起步晚,基础薄弱,发展水平低,各实施主体自身的信息系统发展不均衡,未能实现有效对接而形成信息孤岛,对铁水一体化运输和服务带来直接影响。先进的信息整合和平台开发模式对铁水联运信息系统的发展至关重要。提出基于SOA(面向服务构架)和DDD(领域驱动开发)构架的铁水联运信息平台构建方案,与传统的电子数据交换(EDI)方式相比,SOA的ESB(企业总线)型构架更加灵活高效,实现跨系统流程整合;DDD构架能有效地建设业务系统,低耦合结构也能对测试和更新做出快速反应,具有较大的实践意义。
SOA信息平台 篇5
自60年代第一个地理信息系统（Geographical Information System,GIS）问世以来，GIS在资源、环境等传统应用领域，以及新的应用领域，如旅游、金融等行业，都得到了广泛应用[1](NAPA 1998）。GIS在它诞生的几十年里取得了巨大成功，但其巨大潜力在最近十几年才为人们所认识，据统计，世界上约80%的信息资源与地理位置有关，这已经引起了整个信息技术产业界的高度重视。跨越21世纪，GIS系统正朝着专业或大型化、社会化的方向不断发展[2]（鲍虎军）。“大型化”体现在系统和数据规模两个方面；“社会化”则要求GIS要面向整个社会，满足社会各界对有关地理信息的需求，简言之就是“开放数据”、“简化操作”、“面向服务”，通过网络实现从数据乃至系统之间的完全共享和互动。
Internet与GIS的结合增强了对GIS的开发利用，为地理信息科学创造了新的研究方向。短短不到10年的时间里，Internet与GIS技术的结合在研究领域里产生了诸如WebGIS、Internet GIS、Online GIS、Internet Distributed GI Services与GIS Portal等新名词。早期的WebGIS由于Internet交互能力的局限，并没有太多可利用的网络技术，仅仅是一个信息发布中心，功能实现主要集中在静态地图的发布上。1996年以后，随着Internet技术的飞速发展，客户机/服务器体系的进一步完善，地理信息服务也从地理信息分发步入地理信息共享。到了21世纪，Web Services概念、面向服务的软件体系结构思想的兴起为实现真正意义上的地理信息共享展现了一线曙光。基于Web服务技术的GIS门户已经开始具备可以进行多个异构系统交互、完成更为高级GIS处理与分布式地理信息服务等功能[3,4,5,6,7,8,9]。
1 地理信息共享
空间数据管理的工具GIS系统历经40余年的发展，从主机到桌面PC再到计算机网络，取得了巨大的成就。一直以来，GIS应用总是“小/大而全”的方式，系统的建设一般都包括：空间信息资源采集与录入、空间数据编辑与更新、空间数据存储与管理以及在此基础之上对空间信息资源的查询、分析、表达与制图输出。过去花费了大量资金建设的各种空间信息应用系统以及空间数据库从目前来看基本上都处于孤立状态，很难方便的共享和互操作。即使网络GIS的出现，也主要是向用户提供分布式的空间信息服务，用户无法灵活地运用网络GIS提供的处理功能来处理自己的本地数据，也无法获得特定的处理功能。
地理空间信息资源共享管理的目标是在政府部门间建立跨部门、跨地区和跨行业的城市级别的地理空间信息共享与交换网络服务体系，为自然资源和地理空间综合信息库、综合信息产品库、综合信息定制产品库和专题信息库、专题信息产品库提供数据交换支持，为综合信息子库提供汇集支持，为各类应用系统提供数据支撑环境，形成城市级的地理空间信息资源共享和交换的枢纽，为用户提供自然资源和空间数据的共享服务。同时也为日后国家级的地理空间信息资源共享和交换奠定基础。
地理空间信息资源目录体系是实现地理空间信息资源管理的目标与任务的有效手段，至少包括目录服务、交换服务与GIS应用服务三个部分。基于地理空间信息资源目录体系建立的系统是连接主中心综合信息库、各分中心基础性自然资源专题信息库和基础性地理空间信息专题库的分布式空间信息共享支撑系统，在多源异构的数据资源和分布式的条件下，其主要提供数据的访问、服务、发现等功能，提供有效广泛的空间数据交换与共享服务给应用系统和各类用户，消除数据孤岛，有效加快数据和信息的流通，提高空间信息资源的开发和利用效率。这意味着不仅需要空间数据库的直接共享，还需要GIS功能模块的互操作与共享，实现多点之间的协同工作。
在这种应用模式需求下，GIS应用将走向空间信息的服务[10]。例如，OGC所提出的Web地图服务，Web要素服务，Web覆盖服务。以网络为运行平台的空间信息服务，必然具有一种高效、灵活、动态地集成网络中分布式的空间数据和处理功能模块的机制，以便应用系统按需动态集成。未来的GIS用户将可能在网络上为其需要交汇所选用的数据和软件功能模块的使用费，不必购买这个数据库和整套的GIS硬软件。
2 地理空间信息资源共享服务平台
地理空间信息资源共享服务平台基本框架如图1所示：空间信息资源采用逻辑集中、物理适度分散的，从用户角度来看，空间信息资源的查找和使用的接口是一致的，但是空间信息资源的物理存储和管理的位置则可能是分散于各个部门之中。元数据只是描述了空间信息资源的使用方式和状态，与空间信息资源并没有实际物理上的联系。有关信息被目录服务从元数据里的信息资源分类等属性中抽取出来，旨在用户能够集中查找资源目录。客户端以目录服务所提供的查找结果为根据，可以访问信息资源以及交换数据。客户端包括用户和应用系统两类。用户在交换数据时通常是通过数据交换服务接口来进行，而应用系统的远程数据的调用通常是通过数据访问服务接口来实现的。数据访问服务接口除对空间数据的访问接口之外，对一般二维属性表的访问接口也是它所包括的。
地理空间信息资源目录共享服务平台是按照统一的标准和规范，为发布、发现和定位空间信息资源和各类空间信息交换服务目录而建设的信息服务，参考政务信息资源目录体系总体框架和空间信息服务框架，地理空间信息资源目录共享服务平台总体框架如图2所示：
地理空间信息资源共享服务平台主要由资源信息层、资源整合层、服务总线层与服务表现层组成，同时还具备软硬件、网络的支撑环境，以及标准与管理规范建设和安全保障，由下至上依次为：
(1)支撑与保障：主要由支撑环境、标准与管理规范、安全保障三部分组成。
a）支撑环境：包括系统的基础软件、硬件、网络和底层协议。是整个体系结构的物理支撑。各类信息资源通过政务专网或Internet，利用网络协议，如HTTP、FTP、TCP/IP等进行数据传输。对外提供服务；b）标准与管理规范：规范空间信息资源目录体系的相关标准与管理规范；c）安全保障：按照国家关于空间信息安全保障的相关标准进行操作实施。
(2)资源信息层：包含城市基础及各行业、各部门同构、异构的空间数据资源，主要包括各种比例尺地形DLG、DEM、DOM基础地理数据和各部门的专题地理数据资源。
(3)资源整合层：主要由目录元数据、服务注册管理子系统以及其产生的资源管理数据三部分组成。
a）目录元数据：主要包括描述数据资源及服务的元数据以及基于元数据生成的数据目录。b）资源服务管理子系统：负责整合空间信息资源、封装服务并在服务中心进行服务注册，对信息资源及服务元数据进行采集、归类及编目，同时也提供数据及服务的分级、分类访问控制、系统监控和用户访问日志、信息的流向分析等；c）资源服务管理子系统所产生的用户、权限、服务配置等数据。
(4)服务总线层：至少应该包括三个支持地理空间信息资源目录体系的服务子系统。
a）空间信息资源目录服务子系统：提供元数据目录服务，具体功能包括元数据查询、查询结果提取、数据编目信息查询等；b）空间信息资源交换服务子系统：通过数据交换功能，连接主中心和各分中心的数据库，完成自然资源与地理空间信息的分布式逻辑集成，构成一个虚拟逻辑总库，为用户的各种应用提供数据服务；c）空间信息资源应用服务子系统：为用户提供地理信息服务、数据处理服务、地图影像服务等，并提供统一的分布式服务调用接口，完成一站式的空间信息网络共享应用服务。
(5)服务表现层：空间信息在大部分的电子政务应用中并不是主角，而是处于背景与配角的位置。只有在防灾减灾、应急指挥、资源环境等一些特殊的应用领域，空间信息才处于比较重要的主角位置。服务表现层主要向地理空间信息资源使用者提供地理空间信息资源的发现和定位服务，为便于地理空间信息资源使用查询定位功能以及和其他应用系统的数据集成。包括：a）地理空间信息资源目录使用者：地理空间信息资源目录使用者通过地理空间信息资源门户网站使用地理空间信息资源目录和交换服务；b）应用系统的空间数据集成：提供给专业应用系统或公众系统所需的地图服务，使得各专业应用系统建立在一个数据统一的基础上，避免数据重复建设。
3 结论
地理信息本身是具有分布式特征的。这种特征要求对地理信息分布式组织与处理由集中式变为分布式。随着GIS应用由Intranet发展到Internet，特别是涉及到多数据库系统、多平台、多网络协议的异构环境，传统的将用户界面和业务逻辑、数据源以及通讯协议绑定在一起的应用系统开发方式将不再适合。
GIS传统的设计模式与构架方法无法解决企业、门户、联合GIS中遇到的异构与变更问题，而SOA体系结构支持了以往开发流程和方法无法涵盖的部分。基于B/S模型、XML/Web Services技术的自然延伸可以说是基于SOA的GIS系统。SOA可以使企业系统架构者以更具重用性、更可靠、更迅速的架构整个企业级系统，也可以使企业级架构中的各种部署形式、组件的开发站在一个新的高度得以解决。与以往相比，以SOA架构的GIS系统能够更加从容满足大型GIS系统的要求。基于SOA的GIS系统具有更好地支持工作流模型、更好的敏捷性、编码灵活性、明确开发人员角色、支持多种客户端、减少成本和增加复用、更易于集成和管理、更易维护、更好的伸缩性、更高的可用性等优点。可以实现跨部门、跨行业、跨区域的综合应用模式，解决政府关心的多部门之间信息的共享和应用系统整合难题。
摘要：地理信息具有分布式特征,这种特征要求对地理信息的组织与处理由集中式变为分布式。随着GIS应用由Intranet发展到Internet,特别是涉及到多数据库系统、多平台、多网络协议的异构环境,传统的将用户界面和业务逻辑、数据源以及通讯协议绑定在一起的应用系统建设方式将不再适合。本文从进一步提高分布式GIS能力的角度上,提出了基于SOA框架,以Web服务为技术核心,把基于Web的空间数据共享引入一个更高的层次,实现地理信息共享及互操作。
SOA信息平台 篇6
江西省电力设计院具有国家甲级电力勘察设计资质, 是一个知识密集型企业。现有职工545人, 其中:具有中、高级专业技术人员分别为164人和149人;注册建筑师和注册结构、建造、造价、电气、公用设备、咨询、监理工程师117人。2000年至今, 江西省电力设计院完成发电工程40项, 总装机容量1450万千瓦, 完成投运220—1000千伏变电所125座, 变电容量达3529万千伏安, 包括在建的共136座, 变电容量达4371千伏安。完成220千伏以上等级输电线路设计13176公里, 开展了1000千伏特高压输电线路25公里, ±800千伏直流输电线路163.5公里。
2008年落成的办公大楼进行智能化大楼建设, 建成了高速企业级计算机网络系统, 先后引进了英国PDMS和美国Bentley三维设计系统、AUTO-CAD设计系统, 通过机电土水等各专业百余项工程设计软件进行电力设计工作。建立了办公自动化系统、财务核算管理、档案管理系统、图纸管理系统、项目计划管理等管理信息系统, 2009年前这些设计系统和管理软件都是孤立运行, 信息难以共享。随着信息技术的发展, 2010年采用“十一五”国家科技支撑计划“建筑业信息化关键技术研究与应用”, 基于SOA (Service-oriented Architure, 面向服务的体系结构) 集成企业信息资源, 把我院图纸设计、业务审批流程、数据文件服务、信息交互以及项目全过程管理集成到一个集中的应用环境, 在业务架构与系统集成平台 (E-business Collaboration Architecture, 简称ECA) 上开发了“江西省电力设计院综合信息管理系统”, 达到了信息共享。
1 系统建设思路
“江西省电力设计院综合信息管理系统”确立的建设目标是:初步建成以计算机网络和数据库为支撑, 建立以项目管理模式为核心的工程全寿命周期信息管理系统。
信息系统建设需要根据企业实际进行总体设计, 分步实施。“江西省电力设计院综合信息管理系统”采用基于SOA的ECA开发, 使一个庞大系统的分步实施成为可能。
工程项目管理是设计院信息管理系统的核心。因此首先考虑工程项目管理系统建设。通过市场经营管理:建立项目客户信息, 开展招投标管理, 将确立项目进行合同管理、收费管理等;通过项目设计流程管理:设计任务下达、建立项目信息、进行项目策划、设计人员开展设计、进行设计变更管理、形成设计文档归档、成品交付, 达到工程项目的全过程管理。通过建立企业信息门户、人力资源基础数据管理以及领导综合查询管理, 达到系统结构清晰、人力资源分配合理、管理系统真正起到辅助决策的功效。
在完成以上功能的基础上实现财务管理精细化、物质管理规范化, 合理利用物质资源, 提供党群沟通渠道, 保证ISO质量管理体系真正贯穿于生产过程中。
2 系统建设内容
2.1 系统平台以信息门户形式展现
系统平台根据企业角色和关注内容的不同展示不同的界面, 以信息门户形式出现, 分别建立企业门户、部门门户、项目门户及个人门户。企业门户为整个系统平台展示一个集成和协同的个人工作环境, 把各种应用系统、数据资源和互联网资源统一集成到企业门户之下, 不同部门、参加不同的项目对应不同人员展示的内容不同, 各自在门户下处理自己的日常工作, 需要处理的工作都会在待办任务中, 新的消息、邮件和通知都以集成的方式出现在用户的面前。
2.2 完善市场经营管理信息辅助决策
建立市场经营管理模块, 首先, 对客户关系进行管理, 建立详尽的业主信息;其次, 进行招投标管理, 收集招投标信息, 归档项目招投标文件资料, 总结分析投标结果;接着, 进行合同管理, 做好工程勘测设计合同的管理以及掌握收费信息, 包含外委合同管理, 清楚外委合同的基本信息、付款情况等;再次, 进行明晰的收付费管理, 开票信息、到款情况、外委付款情况等。
通过市场经营管理各子系统信息查询、统计报表, 为院领导和经营管理人员及时提供辅助决策信息, 使决策层实时了解最新的市场情况, 对瞬息万变的市场信息进行分析和预测。
2.3 工程项目管理流程化
工程项目管理的目的就是设计与管理一体化。工程项目管理是院综合信息管理系统的核心与重点内容。建立项目及设计流程管理的集成协同应用平台, 通过规范企业管理程序, 对管理制度流程化重构。利用计算机化、网络化, 将综合办公管理、知识管理、图档子系统和企业质量管理体系子系统紧密结合。
项目管理关注的是勘察设计企业的五个管理要素:人力、进度、质量、费用和图档。工程项目管理对项目全生命周期管理的要素及其产生的各种数据信息, 进行合理配置、有效管理与控制, 使各种资源高效率地协同、运作, 以提高设计生产和管理效率, 规范管理流程, 保证产品的设计质量, 增强企业的核心竞争力。
2.3.1 区分项目大小, 确定不同功能及流程模式
针对大中小多种项目进行不同模式管理, 采用不同的流程控制。大项目、重要项目采用主流程模式, 严格的网络环境下的流程管理;小项目采用独立流程模式, 简化的流程应用模式, 在网上流转一些关键性环节;紧急项目采用无流程模式, 只记录项目信息及质量记录, 以满足项目查询分析的需要。不同的流程模式通过不同模板体现企业管理体系的思想, 在各过程中用户都能随时查看流程图、时序图, 流程节点人可以进行流程委托或任务委托等。
2.3.2 完善项目信息台账
项目信息管理是对项目进行的基本信息登记、维护、项目配置、人员任命、产值分配。项目过程中来往文件及相关资料、纸质函件均需扫描上传, 统一管理。同时可以通过项目管理台账进行项目、设计阶段的信息查询, 启动ISO质量流程, 对项目的信息进行流转审批。
2.3.3 以设计阶段为单位进行项目策划管理
项目立项之后, 下达开工单, 任命项目设总。确定项目的参与部门、参与专业、专业的负责人。对项目的工作进行任务分解。确定各项工作的设校审人员及互提计划。任命项目成员时, 可以查询被任命人员当前的工作承担情况, 方便人员的动态调度。计划分解至图纸卷册级别。项目策划可以存成模板, 在今后进行项目策划时, 可以直接调用该模板, 可以进行增删改, 形成新项目的策划书。避免重复工作。
2.3.4 互提资料进行流程化管理
互提资料是专业间配合的需要, 是设计过程中, 卷册负责人根据项目设计需要, 向其他设计专业提出本专业设计内容的信息汇总。互提资料建立审批流程:由发起方设计人提资, 经主设人校核, 专工审核, 设总确认后完成提资;接受方主设人确认后, 完成提资过程。
2.3.5 质量控制管理贯穿设计过程
设计过程管理, 系统流程简单直观, 设计人员添加相关文件和设计输入文件, 并可对添加的文件进行维护、查询。项目在操作过程中自动地、有效地进行质量控制, 项目管理人员进行实时监测;文件可以共享给其他工程、专业或人员;实现全过程的电子资料互提和校审工作。
2.3.6 图纸自动生成打印文件出版、自动归档并管理
出版管理:设计成品, 经各级校审后的最终电子版自动添加条形码、生成plt文件, 传给绘图中心打印出图。可及时统计不同项目、阶段、专业的出图量。
自动归档管理, 电子图纸和相关设计文件可通过扫描条形码自动归到图档系统中去, 通过系统完成工程原档、成品整编、归档、借阅管理等工作。
图纸的交付管理, 对成品资料工程名称、数量、送往单位和发送时间记录可及时统计和查询发送情况。
2.3.7 项目变更信息可追溯
项目变更管理是对项目过程中各种变更的管理功能。包括项目基本信息 (工程编号、工程名称等) 、项目进度计划、人员、设计、WBS任务、设计输入、互提、审批流程等变更, 系统满足项目各种变更需要。
变更的执行原则:按照岗位职能和任务发起人启动变更的原则进行变更管理。变更版本实现可追溯性管理:所有对象的变更信息都以版本的形式保留变更信息, 确保所有的变更可以追溯。
2.3.8 有效控制项目进度
系统中建立进度计划, 确定项目中各项工作的开展顺序、开始及完成时间以及相互衔接关系的计划。通过项目进度管理, 使设计项目的运作形成一个有机整体。协同管理采用公认的甘特图工具来进行计划的制订和追踪。
进度管理与质量管理完全融合, 即实际的进度完全自动采集, 不需要手工填写, 完全是通过ISO过程中自动生成。ISO质量表单通过关键控制点保证据产生于生产过程中。随时察看项目组人员的工作负载情况, 便于项目设总安排工作。
2.3.9 实时监控项目执行状况
系统建立项目监控管理模块, 方便企业决策者、项目管理人员、专业负责人、设计人员实时监控项目计划进度、执行进展、延迟、报警、控制 (项目终止、暂停、重新启动) 等, 而且对不同级别对应有相应的监控范围。监控包括全院级监控、部门信息监控、专业信息监控、图纸监控, 其他信息包括项目的详细进度信息、单个流程的完成情况、如卷册完成情况、互提完成情况、按照项目的计划出现超时的情况等。
2.3.1 0 质量管理体系落实于项目管理过程中
按ISO9000标准的要求, 建立项目质量管理。在每个工作流程中实施严格的质量控制, 确保设计质量, 缩短设计周期, 也为质量文件的认真贯彻和各设计专业间的协同设计提供有效的方式, 达到企业质量管理体系质量目标要求。
设计流程中形成质量记录, 并自动保存下来, 避免了没有或遗失质量记录需要后补的问题。在网络系统中设计流程必定会得到有效执行, 从而控制了设计成品质量。
每年贯标审核工作, 审核人员在网上查阅即可, 使审核工作简单真实有效。
3 系统应用效果
采用基于SOA的ECA开发的“江西省电力设计院综合信息管理系统”, 基本建立了以网络为支撑, 以专业CAD技术应用为基础, 以工程信息管理为中心, 以工程项目管理为主线, 使设计与管理实现一体化的集成应用系统, 项目成为“‘十一五’勘察设计行业信息化国家级示范工程”。
应用综合信息管理系统, ISO9001质量体系得到有效执行。质量表单随设计流程自动形成, 节约了大量人力, 很好地解决了质量管理体系与设计成品质量“两张皮”的问题。
项目进度得到有效监控。在项目设计过程中, 各级管理人员能够详细了解项目的进度情况, 进行质量跟踪, 合理调配资源, 对项目进行全过程控制。
综合信息管理系统成为协同设计、信息传递和共享的设计平台。可对设计过程所有资料和设计过程中产生的文件进行有效版本的管理, 开展协同设计, 避免差、错、漏、空;通过市场经营管理和工程项目管理的客户信息在系统集中展示, 市场经营部和工程项目部通过信息平台共享工程项目信息。通过报表中心查看各类统计报表, 方便管理者全面了解工程信息, 提供辅助决策信息。
综合信息管理系统信息完整准确。设计人员在设校审提交图纸时, 将图纸中提取的工程项目名称、设计阶段、图纸编号严格与系统内信息进行比对, 如不一致将无法完成设校审、无法绘图归档, 保证了图纸档案的正确性。
4 结束语
设计企业综合信息管理系统是一个较为庞大的信息系统。以往独立的信息系统不能信息共享, 而且开发大多采用的是代码式开发, 一旦系统流程需要调整, 就只有重新编制才能满足实际应用需要, 导致开发成本提高, 投资浪费, 开发周期增大。
SOA是一种优秀的架构理念, 用以更好地驱动业务流程管理。采用基于SOA的业务架构与ECA开发的“江西省电力设计院综合信息管理系统”, 从需求分析阶段建立的系统模块, 到系统实施阶段反复优化的系统模块, 以及随着企业业务发生变化需要调整的系统模块, 都不需要进行大规模的代码改动, 只需要搭建和修改模块就可以了, 大大提高实施的效率和成功率。
SOA提供给企业更好的灵活性来构建应用程序和业务流程。面对各种变化, 基于SOA开发的综合信息管理系统, 不依赖软件开发商, 可以大大减少维护成本, 很好地保护了企业信息化投入。同时, 系统速度快, 操作简便, 易于使用。
总而言之, SOA可以适应不同的标准, 建立的系统具有很好的重用性, 能够在最新的和现有的应用之上创建应用, 实现更加强大、复杂、贴切实际业务的信息化平台。
参考文献
[1]秦如玉, 李浩, 张玉微.大型工业设计院综合管理信息化建设研究与应用[J].土木建筑工程信息技术, 2010, (02) :46-49.
[2]梅钢.项目管理知识体系指南第四版修订评述[J].黑龙江对外经贸, 2011, (04) :111-113.
[3]中国软件测评中心.计算机信息系统集成项目管理基础[M].北京:电子工业出版社, 2004.
SOA服务管控平台 篇7
本项目完成了企业信息集成平台升级完善的工作方案编制, 制定了企业信息集成平台升级完善项目详细的工作计划;开展了项目前期准备工作, 完成了总体详细设计梳理;完成了平台的扩展优化及提升, 优化了服务管控过程, 提升了平台的易用性, 改进了平台平台监控功能;对平台、服务、流程等运行情况进行了全方位展示, 操作界面进行了标准化改造, 使操作更加规范合理, 全面提升了信息集成平台的技术含量、性能和稳定性;共设计绘制界面原型图335个, 开发70个界面原型程序, 覆盖了“综合管理”、“服务资产管理”、“流程管理”、“活动监控”、“服务管控”共5大功能模块538个功能点, 通过界面原型意见征集, 收集用户意见76条并全部采纳;平台进行了典型业务场景的功能测试, 且顺利通过测试, 基本满足平台升级完善项目的用户需求。
本项目的关键技术和创新点有:
(1) SOA服务化流程引擎。基于SOA架构思想, 通过对服务的组合调用, 实现了流程的流转控制和动态权限管理, 同时, 与服务总线进行了无缝的集成, 提高了流程与外部应用系统的交互能力。
(2) SOA架构应用系统开发框架。服务开发框架对服务之间的交互过程、统一数据结构、事务、安全等进行了封装, 屏蔽了各种技术细节, 开发人员只专注于业务逻辑实现。
(3) 基于Flex的界面动态展现技术。通过编写配置文件完成界面的开发, 采用类动态管理机制解析配置文件并展现, 解决了传统开发界面必须编写代码的模式, 提高了开发效率。
(4) 基于并行队列技术的海量数据采集存储方法。并行队列技术现海量实时数据的快速采集和存储, 解决了大型应用系统在海量数据采集处理方面的瓶颈问题。
(5) 基于约定规则的动态查询引擎。动态查询引擎提供了一个快速的数据查询开发方法, 仅需要按照约定的规则编写接口代码, 无需编写实现代码就能完成数据库的开发工作。