SOA平台范文

SOA平台范文（精选8篇）

SOA平台 第1篇

近年来,随着国家对医疗卫生改革的大力推进,医院的业务得到蓬勃发展。随着医院业务的发展,医院内运行的业务应用系统越来越多,也越来越专业化,各个应用系统之间的交流也越发频繁,对数据交换的需求也越来越迫切。而这些应用系统大部分由不同软件厂商采用不同的软件平台技术开发,这些异构系统的存在导致系统间信息的交互与互操作非常困难,形成了一个个"信息孤岛",出现了医院业务系统应用发展的瓶颈。

同时随着医院业务走出医院,对外提供网上预约、网上体检和社保结算等服务时,也面临医院业务系统与医院外部系统的交互,这些交互也对各个应用系统提出集成的需要。

针对以上问题,本文提出在采用基于面向服务架构(ServiceOriented Architectures,SOA)对医院应用系统进行集成,利用SOA松耦合的架构,在不改变现有医院业务系统的基础上,搭建各业务系统的信息框架,实现对现有医院信息化投资的保护,最大化的实现业务系统的发展。

1 面向服务的体系架构

SOA(面向服务的架构)随着各大厂商的追捧而变得炙手可热。虽然SOA本身不是一个全新的概念,但由于Web服务以及网格计算等技术的成熟,SOA具备了更好的发展条件。基于SOA的企业应用系统集成可以灵活的随着企业业务的变化而逐渐变化,能够实现"柔性化"的软件系统,从而降低了企业实施应用集成的成本和风险。

1.1 SOA的定义及其组件结构

SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过其间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应用独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务体系结构的组件包括:

1.1.1 服务提供者

服务提供者是一个或一组以无状态方式执行业务功能的组件,接受预定义的输入和输出。

1.1.2 服务使用者

服务使用者是一组有兴趣使用服务提供者所提供的一项或多项服务的组件。

1.1.3 服务储备库

服务储备库包含服务的说明。服务提供者在该储备库中注册其服务,而服务使用者访问该储备库已发现的所提供的服务。图1说明了SOA中的不同角色及其工作流程

SOA的关键是"服务"。W3C将服务定义为:"服务提供者完成一组工作,为服务使用者将会所需的最终结果。最终结果通常是使用者的状态发生变化,但也可能是提供者的状态改变,或者双方都产生变化"。服务是网络中可用的软件资源。服务提供者通过标准机制提供服务。服务使用者通过网络有计划地使用服务。服务储备库发布服务所在位置,并在使用者请求服务时定位服务。服务使用者和提供者的角色不是惟一的,服务提供者也可以是使用者,反之亦然。

1.2 SOA服务粒度

可以按基于服务的功能及发送和接收的数据数量来划分服务,如细粒度服务、粗粒度服务或组合服务。在SOA中服务粒度有两种相关的意思,即服务是如何实现的,服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能,发送和接收少量的数据。粗粒度服务执行了较大的业务功能,并交换了更多的数据。粗粒度服务提供一项特定的业务功能,而细粒度服务代表了技术组件方法。

1.3 SOA实现技术

虽然服务不仅仅是指"Web服务",但Web服务是SOA最流行的一种实现方法。Web服务(Web Service)提供了一个分布式的计算技术,通过开放的Internet标准:Web服务描述语言(WSDL,用于服务描述);统一描述、发现和集成规范(UDDI,用于服务的发布和集成);简单对象访问协议(SOAP,用于服务调用)和Web服务流语言(WSFL,用来定义工作流),Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。使用Web服务,通过松散的服务捆绑集合形式,能够快速,低代价地开发、发布、发现和动态绑定应用。

1.4 ESB企业服务总线

企业服务总线(Enterprise Service Bus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息,以及基于事件的交互,并且具有适当的服务级别和可管理性。简而言之,ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能,以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中,ESB用于组件层以及服务层之间,它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

作为SOA基础架构的关键部分,ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控方面。在通信方面,ESB能够支持消息路由/寻址,支持多种通信技术、通信协议(如JMS、HTTP),支持发布/订阅的通信模式,能够处理请求/响应、同步以及异步的消息传递方式,并且要求以可靠的方式传递消息。服务交互方面,ESB上所发布的服务是以当前标准的Web服务描述语言(Web Service Description Language)来定义Web服务的,并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统,必须能够支持多种接入ESB的方式(例如将ESB、Web Service、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统),将接入的系统映射成Web服务。在集成不同系统的同时,必须考虑服务质量方面的问题,如事务性和消息传递的可靠性。对于关键的Web服务,ESB需要以加密的方式进行消息传递,并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统,还必须配有相应的管理和监控功能,用于ESB软件自身的系统管理、日志记录、测量和监控等。

2 基于SOA的医院应用集成方案

2.1 系统框架

国内现在大部分医院应用的系统主要包括核心业务系统和辅助业务系统。核心业务系统主要包括HIS系统、LIS系统、PACS系统和电子病历系统。辅助业务系统主要包括账务系统、人事系统、办公自动化系统等。

而医院跨行业的对外服务接口则包括跨保险行业、通信行业的服务接口以及对外信息服务平台。

其基于SOA的架构如图2所示。

如图2中的集成系统框架可分为资源层、接口层(主要包括对内服务接口层和跨行业服务接口层)和服务层共三层体系架构。三层的数据通信则基于HL7数据标准集成交互协议进行交互。

资源层包括了医院的所有业务系统、医疗资源数据库和医疗资源监管系统,医院的各业务系统提供业务资源的支持,实现服务的触发点,医疗资源数据库则将医院常用的、跨多个系统可共享使用的所有的医疗资源数据,在资源层上,医疗资源监管系统可直接监控管理医疗资源数据的使用权限和使用情况跟踪。

服务层将资源层的资源封装为服务,以便整合。根据资源信息化水平的不同,需采用不同的封装方法。一方面,将已建立了医院业务系统的资源通过连接服务、数据服务包装为服务;另一方面,对于尚未建立医院业务系统的资源,直接开发服务,如图中的就诊者远程医疗服务、就诊者就诊信息服务。所有服务都连入企业服务总线ESB(Enterprise Service Bus),并借助信息服务、流程服务、交互服务开发更复杂的服务或应用,实现信息整合。

接口层服务有两个部分,一个是医院对外的接口,包括与社保、医保的接口(支持多个地区),就诊者服务门户网站等,供与保险行业的连接和就诊者的服务,二是医院对内的接口,实现统一的医保社保服务接口,统一的检验检查服务接口等,提供给内部的ESB总线服务。

上述各层的数据格式、消息格式、接口等都要符合基于HL7的数据标准交换协议。

2.2 系统实现

按我们的设计,系统的实现如下图所示:

在系统实现上主要包括医院的内部应用集成和跨行业的应用集成。在内部应用集成上主要是对已有系统的业务流程整合,将已有的核心业务系统(包括HIS系统、LIS系统、PACS系统和电子病历系统等)和辅助业务系统(包括办公自动化系统、人事系统等)的业务流程和数据进行集成整合。在外部应用集成上则是对跨行业的服务进行集成整合,包括对保险行业的社保医保和商业保险的集成、通信行业的短信平台和Web网络应用等的集成。

在实现集成内容上主要包括以下三个方面:

(1)基于HL7的医疗数据集成存储在整个体系结构的数据集成上,存在着巨大的系统间数据集成和共享的需求。主要存在以下三类信息的集成交互。主要包括基础信息数据、患者信息数据和医嘱服务信息。这些信息涉及医院为提供基础医疗服务所涉及的各种基础医疗信息、患者服务信息和医嘱服务信息,这些需共享的数据主要包括医院的药品信息、器械信息、检验检查项目基本信息、物价信息、医疗工作者信息、患者信息、医嘱信息等数据,这些数据是医院能正常提供医疗就诊服务的基础信息数据。这些基础信息数据以基于HL7标准的数据封装存储在一个医疗资源数据仓库中;(2)基于SOA的医疗服务编排在整个体系结构中,存在大量的系统间业务流程的集成交互需求,因此必须先分析各个系统间集成交互的业务流程,提取这些业务流程,将每个系统的关键业务流程提取封装成标准的SOA服务,比如HIS系统和LIS系统间病人检验信息的调用服务,通过LIS系统将检验信息调用服务提取成标准的SOA服务。最终将这些系统间的SOA服务注册在一个统一的医疗资源服务库,在服务库内编排这些服务内容,将细粒度的服务整合成粗粒度的服务以供整个体系使用;(3)实现医院ESB总线平台通过基于HL7的医疗数据集成存储和基于SOA的医疗服务编排后,必须对这些数据服务和业务服务进行统一的调配使用,因此建立一个医院应用集成的ESB总线平台,在平台上构建标准的组件服务层,实现服务间的互联互通,ESB总线平台要实现的功能包括消息格式转换、服务管理功能、服务注册功能、服务路由功能、Qo S管理功能、安全管理功能以及事务管理功能等。

3 总结

针对当前医院系统存在的"信息孤岛"现象,医院系统内外部不能方便、低代价地实现异构系统的集成,难以适应现代医院快速的业务变化需求。本文提出了一种基于SOA架构的医院应用集成方式整合医院内部的各业务系统,以松耦合、灵活的架构实现医院ESB总线平台来服务于医院已有业务和新业务的发展,以组件化的架构方便系统的升级再造。

摘要：当前医院业务系统的应用集成问题已成为当前医院信息化乃至区域医疗信息化的关键。针对现有的医院应用系统的信息化状况,提出并设计了基于面向服务体系架构(Service-Oriented Architectures,SOA)的医院应用集成平台的解决方案。该集成平台通过基于HL7(Health Level Seven)协议提取封装医院内部的基础数据集,整合医院内部和跨行业外部的业务服务,最终建立医院的企业服务总线(Enterprise Service Bus,ESB)实现一个完整的医院集成平台架构。

关键词：面向服务的体系架构,基于HL7,医院应用集成平台

参考文献

[1]谢梅源.以面向服务体系结构(SOA)架构社区医疗信息系统.温州职业技术学院学报,2006,5(3).

[2]廖建军,胡宏涛.基于SOA实现企业应用集成.微机发展,2005,15(9).

[3]丁兆表,董传良.基于SOA的分布式应用集成研究.计算机工程,2007,33(10).

SOA平台 第2篇

〔关键词〕图书馆；应用支撑平台；SOA

〔中图分类号〕G250 〔文献标识码〕B 〔文章编号〕1008-0821(2009)04-0136-03

The Construction of Library Application

System Supporting Platform Based on SOAPan Xu1 Liu Guoqing2

(1.Library，Southwest University for Nationalities，Chengdu 610041，China；

2.Chengdu Command College of Chinese Armed Policeforces，Chengdu 610213，China)

〔Abstract〕SOA is an IT strategy，it can organize the scattered application systems to standard services which can be rapidly reused and combined，and realize the combination of applications.This paper discussed the construction and main techniques of library application system supporting platform based on SOA.

〔Key words〕library；application supporting platform；SOA

当前，图书馆应用系统种类繁多，应用复杂，按照服务不同，馆内通常建有门户网站服务系统、馆内读者网络服务系统、图书馆业务集成系统、协同办公系统、数字资源加工系统、数字资源存储管理与检索系统、虚拟参考咨询系统、视频点播服务系统、一卡通系统、电子阅览室系统、多媒体电教室系统、视障读者服务系统、多媒体导读系统等等，面对如此众多的系统和业务，单个应用程序显然无法包容各种需求，一个特定的业务需求就需要一个应用，而业务需求一旦发生变化，应用就需要重新开发和部署。由此导致了各系统之间共享性、兼容性、灵活性差，增加了人员培训的成本，降低了应用实施的效果。

那么，如何打造出满足当今随需应变图书馆业务环境所需的敏捷IT基础设施，从而提高图书馆业务流程的灵活性呢?用传统的以核心应用为中心的技术平台和开发模式，即使是一个大型的综合信息平台解决方案，仍然不能满足需求的不断膨胀和变化，只能通过不断开发新应用，扩展现有应用程序来艰难的支撑其现有的业务需求。SOA(面向服务架构)通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的流程，从而更加真实地反映出与业务模型的结合。

1 SOA简介

SOA(Service-Oriented Architecture，面向服务架构)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过他们之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。可以认为，SOA是以往面向对象模型的替代模型，虽然它并不排除使用面向对象的设计来构建单个服务，但是SOA整体设计却是面向服务的[1]。SOA的应用参考架构如图1所示。

由图可知，要将服务部署到图书馆体系架构中会涉及到许多连续统一的活动，这些活动可分成三个阶段[2]：

1.1 构建服务

在部署和运行服务以前，必须先构建服务。可通过IBM Rational等软件开发平台将各应用迁移到SOA，由此简化和加速业务流程建模以及面向服务应用系统的设计、构造、组装和测试，从而帮助图书馆获得所需的IT灵活性。

1.2 实施和运行服务

为了部署已构建的服务，在SOA运行时，需要编排业务流程，并将各种功能拼接成复合应用；需要在企业内部以及在防火墙内外使用他人提供的服务；需要基于角色的内外部用户界面以及来自多个信息源的单一信息视图；需要将所有数据库当作一个数据库进行操作以查询信息。

1.3 管理服务

在SOA成功运行后，需要一种将复合应用和SOA环境的管理纳入整体安全性和系统管理环境的方法。其中包括发现、监控、保护和管理Web服务与SOA环境的能力，以及为现有IT基础设施提供相关性管理、事件管理和服务水平管理。SOA部署的前瞻性监控和管理能够提高Web应用程序、门户解决方案和基于SOA的解决方案的可用性。

2 图书馆应用系统支撑平台建设

应用系统支撑平台即通常意义上的中间件，它在网络和基础服务之上、应用系统之下，在信息系统的软件平台中起着承上启下的作用。它架构在基础服务层，利用基础服务层的各种服务来实现自己的功能[4]。

2.1 平台设计目标

应用系统支撑平台是图书馆应用系统的基础，它支撑应用软件的开发、部署、运行及管理，为各个应用系统提供一个统一的、开放的、可伸缩的、安全的、可互操作的、数据共享的基础环境。其设计目标应包括以下几点：(1)为应用系统层提供标准的应用系统开发、运行及管理的应用框架。(2)为应用系统层提供应用系统集成、业务流程集成和数据集成的标准规范。(3)为应用系统层提供应用系统集成、业务流程集成和数据集成三大基础，以及这些基础的开发部署环境。(4)为应用系统层的各应用系统以及门户提供应用服务器容器[1]。

2.2 平台的主要构成

应用支撑平台由图书馆应用系统的统一应用运行平台、统一应用集成平台、统一数据交换平台、统一数据集成平台等系统构成。

2.2.1 统一应用运行平台

应用运行平台是应用支撑平台的基石，提供图书馆各应用系统开发、部署与运行所需的环境。采用三层逻辑结构，即：界面表现层、逻辑应用层和数据层，可实现系统集中维护共享信息，自动实现Web信息发布以及面向各类用户的查询服务及管理。

此平台使用中间件技术将中心数据库和具体的应用程序分离，提供了一个易于扩展的业务架构。应用系统的所有前端应用全部在前台应用服务器上，通过中间件建立分布式应用程序架构，数据库系统放置在后台数据库服务器上，将共享数据库和各种具体业务应用全部通过业务逻辑层进行信息的交互，达到应用与数据的完全隔离，增强系统的安全性和灵活性。

2.2.2 统一OA办公平台

基于SOA架构的数据整合平台 第3篇

关键词：大型综合能源企业,信息整合,SOA架构

1 信息化建设现状

1.1 我国矿山企业信息化建设

20世纪80年代, 一些矿山企 业 、 大中专院 校 、 科研院所 开始研究计算机技术在矿山设计和生产中的应用, 并开发出了一些应用软件系统, 如矿井通风系统、 矿山资源储量计算系统等, 为推动我国矿山信息化建设起到了积极的作用。 进入90年代后, 随着国家信息化的快速 发展和市 场环境的 变化, 矿山信息化进入了快速发展阶段, 围绕着如何提高矿山生产效率和管理效率、 降低开采成本、 提高矿山开采技术水平等开展了大量的研究, 并取得了丰硕的成果[1]:

(1) 计算机辅 助矿山规划 与设计得到 普遍应用 。

在建立矿床三维地质数字模型的基础上, 进行地质储量计算, 优化开采境界, 编制矿山生产计划, 从而提高工作效率, 降低生产成本[20]。 如江西铜 业公司在全国 矿山率先采用 了国际上普遍应用的矿山规划与设计软件———MINTEC软件, 取得了较好的效果。

(2) 与矿山生产 相关的业务 系统得到广泛 应用 。

矿山企业广泛采用计算机技术、 数据库技术建立了不同层次的管理信息系统, 并且向着集成系统的方向发展, 等使得生产过程自动化、 管理信息化, 比较有代表的是伊敏露天煤矿建立了包括人事、 档案、 计划、 消耗、 供应、 销售等功能的管理系统, 安家岭露天煤矿生产调度管理系统等。

(3) 矿山企业加 大了网络通 信设施建 设的投资 , 基础设施建设的后发优势加快了信息化的进程。

虽然我国矿山信息化建设取得了一定的成就, 但由于缺乏规划以及盲目地上各种应用系统, 所以与国外先进矿山企业相比, 我国矿山信息化总体水平还不高, 还存在诸多问题:

(1) 大型能源企 业业务系统多 , 数据源头 分散 , 缺乏统一的数据规范, 系统集成性差, 可扩充性弱。

(2) 对信息化建设 存在误区 。

企业信息化建设中有种被广泛认可的说法:“三分技术, 七分管理, 十二分数据”, 系统的实施是建立在完善的基础数据之上的。“三分技术” 中的数据组织技术尤为重要,“七分管理” 中的人员组织管理、 制度管理是关键,“十二分数据” 是指数据的准确、 及时和完整, 统计指标的统一等, 但多数企业不重视数据组织技术, 忽视组织的制度管理, 从而阻碍了信息化的进程。

(3) 对数据整合存在 误区 。

很多企业数据的整合的概念就是通过建立数据接口把各业务系统集成在一起, 但是接口的数量会随着应用系统的增加成几何级数增加, 这不仅增加了信息化建设的投资, 而且使得整体系统的可扩充性差。

1.2 信息化建设

某公司是集煤炭开采、 坑口发电、 铁路运输及粉煤灰提取氧化铝为一体的大型综合能源企业, 全集团公司建有以千兆光纤为主干、 百兆交换至桌面的局域网络, 并在吊斗铲系统和供应仓库部署了无线网络传输系统, 计算机约有1500台左右。 现有小型机13台、 PC服务器20台、 交换机228台。

公司部门众多, 业务繁杂, 信息化程度各不相同, 现建有16个业务应用系统: EAM系统、 人力资源管理系统、 用友财务管理、 OA系统、 生产调度日报系统、 哈矿生产日报、 煤炭经销公司报表系统、 露天设备调度系统、 煤质分析 系统 、 档案管理系统、 煤矿本质安全管理体系、 露天矿GPS运输车辆监督管理系统、 医疗保险管理系统、 住房公积金管理系统、 铁路运营管理信息系统、 准能矸电生产管理系统。

(1) 统一用户管理和身份 认证的问题

现有业务应用系统相互独立运行, 每套系统都有自己的用户管理和权限认证方式, 都需要单独的登录认证才能使用, 导致用户信息冗余、 数据不一致的问题严重, 没有全集团统一的用户管理和身份认证控制机制。 用户存在多份, 且在多个地方维护, 不一致的情况严重, 而且各业务应用系统都建立了各自的组织架构, 没有全集团公司统一的组织架构和用户信息, 当集团公司组织架构调整和人员变动时, 必须分别维护各业务应用系统的人员信息和权限分配。

(2) 信息访问方 便性和系统 可维护性的 问题

现有业务数据分散, 孤岛现象严重, 工作人员必须清楚知道所需信息在哪一业务系统中, 访问不同的信息需要在不同系统间进行切换、 搜索, 而且数据不一致 , 信息不透 明 , 需要耗费大量的精力去查找信息。 由于操作复杂, 用户需要多次、 重复的培训, 系统需要很多不同专业的人员更新维护, 维护成本很高。

(3) 主数据的 甄别和数 据一致性 的问题

各业务应用系统都是各自为政, 独立的维护自己的数据, 造成大量的数据冗余和不一致。 主数据不明确, 业务信息在很多系统中都存在, 不清楚哪个系统中的信息是准确的、 最新的、 可用的。 因此使得本身从业务角度来看是有相互关系的数据不能发生 “关系”, 最直接的表现就是得不到一个综合的、 多维度的管理决策信息。

(4) 全局性信息搜索 和综合服务 能力的问题

虽然我公司现有系统经过多年的运行产生了大量的信息, 但这些信息并没有沉淀固化为企业的知识而发挥应有的价值, 提供数据服务的能力不足。 现有业务数据关联困难, 集成程度很低, 缺乏全局性的信息搜索, 对关键业务数据缺少综合分析和实时动态展现, 对业务管理和领导决策的支持力度不足。

(5) 实现业务数 据报表自 动化和智能分析 的问题

数据应以不同的方式为不同层面的 业务管理 提供服务 , 现有的业务应用系统以解决执行层面数据操作为主, 要求快捷、 方便、 准确, 而管理层关注的是业务管理的过 程信息 、 结果信息, 要求数据的及时性、 准确性, 并能实现业务报表的自动化。 决策层领导关注的是各职能机构的综合统计、 分析信息, 要求能够动态、 实时地反应集团运营状态的关键业务数据, 并能够以图表、 曲线、 管理决策信息仓库等多种的形式, 直观地展现在桌面上, 同时能够在专业工具支持下进行分析, 包括从积累的数据中寻找潜在的规律, 对生产效率进行比较分析, 对各种趋势性数据进行预测等。

2 系统建设目标

系统整合平台基于SOA架构, 采用松耦合、 模块化设计, 构建一个灵活的、 稳定的、 开放的、 可扩展的数据集成框架结构。 在保持现有业务应用系统功能和运行方式基本不变的前提下, 站在公司全局的高度, 将现有业务应用系统进行信息整合, 实现生产调度业务数据的逻辑关联和智能分析, 并实现业务报表的自动化生成和可视化管理, 为领导决策和综合业务管理提供信息化支持。 具体建设目标可概括为:

(1) 统一数据 视图 , 将不同数据 源进行集 成整合 , 其概念结构如图1所示。

(2) 构建数据 仓库 : 通过对各 业务数据 的抽取 、 清洗 、 转换, 从而形成数据仓库, 从而对数据进行多维度分析, 自动形成数据报表。

(3) 完善的报表系统 : 结合我公司 露天矿 、 选煤厂 、 发电厂、 铁路运输、 维修中心及辅助生产环节的实际需求, 完善满足各级生产调度需求的报表系统。 根据现有各级单位生产调动工作需求, 系统应满足三级报表编制需求: 第一级为公司各二级生产单位调度使用; 第二级在第一级报表数据的基础上进行汇总形成, 供公司总调及相关领导使用; 第三级为集团公司生产调度报表, 经公司生产指挥中心调度人员或统计分析人员审核确定后, 可直接上传集团产运销信息系统。

3 系统规划方案比选

3.1 开发系统间接口程序

通过开发接口程序实现系统间的数据 交换 , 是最传统 、 最简单的方式。 但这种方式并不适合公司这样复杂的信息系统和众多的数据交换需求, 而且还无法实现跨系统、 跨平台、 跨部门的流程整合, 制约了信息化建设的可持续发展。

这种方式的接口开发数量非常多且复杂, 若将全公司的业务应用信息全部进行集成, 其接口程序的软件开发工作量不可想象, 而且这种方式将导致IT系统结构越来越复杂, 可扩展性差, 灵活性差。 数据和流程整合是由于跨系统、 跨平台业务协同需求而产生的, 是公司全局性、 整体性的 问题 , 只能从全局层面、 整体结构上去解决。 而开发接口程序的方法只是站在应用层面试图从局部去解决业务协同这个全局性的问题, 这不仅仅是一个技术上的差异, 更是一个分析和解决问题 “方法论” 的差别, 所以, 很多单位试图以OA系统或ERP系统为核心 去整合其他应用系统 , 不但旧的 问题没有从根本上解决, 反而将结构越弄越复杂, 新的问题也层出不穷。

3.2 重建一个“大一统”的业务系统

新建一个 “大一统” 的业务系统, 代替现有的业务应用系统, 这是一种理想主义的设想。 因为要想把公司所有业务涉及到的所有IT信息系统都整合在一起, 这不仅技术难度大、 建设成本高, 而且也无法满足未来业务扩展的需要。

3.3 基于 SOA 架构实现信息整合

面向服务体系架构 (Service-Oriented Architecture) 是一种以业务为驱动的全新的IT架构方式, 能够在保持现有业务应用系统功能和应用模式不变的前提下, 实现公司整体、 全局性的信息集成与整合。 SOA将应用程序细分为不同功能单元———服务, 一个服务定义了一个与业务功能或业务数据相关的接口, 以及约束这个接口的契约。 接口和契约采用中立、 基于标准的方式进行定义, 它独立于实现服务的硬 件平台 、 操作系统和编程语言, 这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、 相互理解。

SOA是一种架构 、 方法 、 思想 、 标准 , 它能使公司业务 标准化、 服务化、 组件化。 SOA实现的目的在于 “随需应变” 和 “灵活应对”。 这就能够将公司内部各组织之间, 以及各厂矿、 各子公司等关键要素整合在一起, 能够对瞬息万变的需求做出敏捷的反应。

通过对上述3种方案的概述, 结合公司的实际情况, 最终确定SOA架构作为最终的方案选择。

4 数据整合平台构建

数据整合是按照统一指标、 统一数据概念的要求, 对不同应用系统提供的数据源, 按照问题领域和指标设 计规范 , 将分布在不同应用系统的原始数据转换为要求的 “目的数据” 的过程, 公司数据集成整合平台从逻辑上由生产调度门户平台、 生产调度报表平台、 公司统一用户平台、 生产调度报表数据4大部分构成, 其总体架构设计方案如图2所示。

4.1 生产调度门户平台

基于IBM PORTAL构建生产调度门户平台, 在门户平台上使用表单配置工具STS为各二级单位开发配置 报表提报 、 审核、 批准界面, 并提供用户管理、 以及与其他应用系统的单点登录、 业务应用集成等功能。

4.2 公司统一用户平台

基于标准的LDAP产品构建公司统一的用户数据库, 根据公司的实际情况, 选择使用IBM Directory Server (IDS) 来实现。 统一用户管理需要考虑统一用户数据库的建立、 用户数据库的管理维护、 初始化, 统一用户数据库账号与已有系统中账号的映射, 统一用户数据库的使用等情况。

4.3 生产调度报表平台

(1) 基于IBM Data Stage开发和运行 报表数据 采集作业 , 实现从各 二级单位 的系统数 据库中采 集报表数 据 。 IBM Data Stage是一套专门对多种 操作数据 源的数据 抽取 、 转换和维护过程进行简化和自动化, 并将其装载到指定数据集或数据仓库的集成图形化开发工具。 传统的数据整合方式需要大量的手工编码, 而采用Data Stage进行数据整合可以大大减少手工编码的数量, 而且更加容易维护。 Data Stage数据采集功能图如图3所示。

(2) 基于IBM DB2构建门户数 据库 , 作为运行生 产调度门户平台的支撑环境, 并临时存储各二级单位的通过门户平台填报的报表数据。

(3) 基于Oracle数据库构 建报表数 据仓库 , 作为报表平 台的数据源。

(4) 基于IBM COGNOS构建报表 平台 , 报表平台分 为数据建模和报表制作发布两个部 分 , 使用其DATA MANAGER DEVELOPER工具进行报 表建模 , 使用其BI CONSUMER工具进行报表制作与发布。

4.4 系统各平台间逻辑关系

(1) 在生产调 度门户平台上使 用表单配置 工具STS为各二级单位开发配置报表提报、 审核、 批准界面, 各二级单位的报表数据暂存在门户数据库。

(2) 从门户数据 库 、 以及各二 级单位已 有系统的数 据库中采集报表数据。

(3) 把采集的 报表数据 , 进行数据加 工 、 转换最后 存储到报表数据仓库中。

(4) 生产调度 报表平台使 用报表数 据仓库做 为报表建 模的数据源。

(5) 生产调度 报表平台中的 报表集成到生 产调度门户中 进行集中访问。

5 结语

通过基于SOA架构的数据整合平台的建设, 可以为公司构建一个高效、 灵活和易扩展的企业级IT集成架构, 既能充分利用现有业务应用系统, 提升现有业务系统的应用 价值 , 又能方便地与未来信息系统集成, 有效降低公司的IT投资和系统整合风险、 成本, 本平台的构建所带来的价值表述如下:

(1) 能够为员 工提供一 个 “ 一站式 ” 的协同工 作中心 , 实现所需信息的方便查找、 获取及展现。 减少技术培训和系统重装、 升级、 维护等工作量, 实现业务数据的自动交换和充分共享, 达到无纸化办公的目标。

(2) 使IT架构适应 “智能准能 ” 业务模式的 变化 , 真正做到随需应变, 快速实现SOA体验。 操作简单, 动态配置, 较好地解决生产企业缺少软件开发人才和经验技能的问题。

(3) 可为决策层 领导直观 、 动态地展 现关键指标 , 以提供决策支持, 为各级管理人员和管理层领导提供自动化业务报表。

(4) 能够实现 跨部门 、 跨系统的业务流程 的自动流转 和监控, 具有完整的信息反馈, 全面支持多部门、 多项目的协同工作, 从而提高业务处理效率, 降低生产管理成本。

基于SOA的财政应用整合平台研究 第4篇

关键词：OA,金财工程,应用整合,web服务

一、引言

湖南省自2002年开始启动湖南省金财工程建设以来, 先后建成了部门预算系统、预算指标系统、国库集中支付系统、公务卡结算系统、预算外总会计系统、预算内总会计系统、财库行横向联网系统等近20个财政业务管理系统。这些业务管理系统为财政管理现代化做出了重要的贡献。但是随着湖南省金财工程的推进, 这种由不同历史时期、不同公司承担、不同业务部门使用、不同平台的不同业务系统的建设矛盾越来越突出。存在的各自为政、信息孤岛、条块分割、安全隐患等症状, 制约着“金财工程”向更高水平的发展。为此, 需要对“金财工程”进行整合, 以适应公共财政发展的需要。

为了解决财政业务系统没有统一的规范和约束问题, 管理机关提出建立统一的财政应用支撑平台, 在其上搭建核心业务系统内核, 通过地方的二次开发实现个性化要求。但该平台只是一个基于共同的业务规范, 在不同的财政业务共享方面没有更多的考虑, 并且由于财政的业务系统已有相当的积累, 要在短期内全部重构所有的系统有相当的复杂度。基于此, 本文在国家统一的财政应用支撑平台基础上, 提出基于SOA[1]的财政应用整合平台, 以解决财政信息系统中不同系统之间信息交互困难, 业务功能不能随需所变的问题, 使财政管理向敏捷性管理方向发展[2,3]。

二、面向服务的架构 (SOA)

SOA是一个基于特定标准的组织和设计方法, SOA在传统的业务层和技术层之间增加了一个服务层, 通过连接能完成特定服务的独立功能实体来实现软件系统架构。它将业务层和技术层之间的信息有效地进行沟通, 让企业应用层可以彻底摆脱技术的束缚。将注意力放在服务上, 使得应用程序能够集中起来提供更加丰富、更加灵活、目的性更强的商业流程, 使得基于SOA的企业应用系统能够更加真实地反映出与业务模型的结合。SOA的体系结构 (图1) 包括三个部分:

服务提供者, 一个可通过网络寻址的实体, 它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心, 以便服务使用者可以发现和访问该服务。

服务使用者, 一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询, 通过传输绑定服务, 并且执行服务功能。服务使用者根据接口契约来执行服务。

服务注册中心, 服务发现的支持者;它包含一个可用服务的存储库, 并允许感兴趣的服务使用者查找服务提供者接口。

三、基于SOA的财政应用整合平台框架

针对财政系统领域内复杂、异构的业务信息系统, 适合采用SOA架构来构建财政应用整合平台。本文提出的基于SOA的财政应用整合平台的框架如图2所示。该平台用来解决财政应用程序的业务逻辑或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用, 而无须理解服务的底层实现。

如图2所示, 集成框架共分为五个层次, 从下往上每层的作用和含义如下:

(一) 应用层:

各种异地异构应用系统。从地域上来说可能是财政内部的系统与一些遗留系统, 或是与财政相关的一些系统, 如财库行联网系统。从结构上来说, 这些系统彼此间没有接口可供互相调用。

(二) 构件层:

OMG对构件的定义是一个物理的、可替换的系统组成部分, 它包装了实现体且提供了对一组接口的实现方法。构件表示了系统实现体的一个物理片段, 包括软件代码, 例如脚本或命令文件。构件自身必须相容于接口且实现接口, 接口表示了驻留在构件内的成分所实现的服务。图中的web服务封装器就是构件, 它具有独立发布的功能, 能快速且平滑地集成到各种同构或异构的系统, 并将应用层系统的部分功能或组件封装成服务向外部提供, 也可以通过它的接口访问它的服务。运行时构件是一个可动态绑定的、含一个或多个程序的软件包, 它作为一个独立单位, 通过运行时可辨别的文档化接口加以管理和存取。

(三) 服务层:

服务层的注册中心将构件层提供的服务注册起来, 以便使服务能够被发布、查找和绑定。另外, 还可将服务间的组合或互操作的过程写入注册中心。

(四) 集成层:

查找服务层的服务, 并根据所需的业务流程, 将这些服务重新组合, 以实现新业务流程的组装、整合。

(五) 表示层:

可以将全局流程集成效果在某客户端完全显示出来, 供异地企业实时查询。

四、基于SOA的财政应用整合平台实现

面向服务的架构 (SOA) 被认为是用于下一代应用系统开发的架构。帮助人们在开发应用的时候能够寻找并使用已有的服务而不必重复开发某些功能;能够方便集成异构系统;能够更容易地扩展已有系统。

(一) 总体逻辑结构图

财政应用整合平台的功能包括三个部分, 第一部分是系统管理平台, 主要负责完成对应用的管理、服务总线运行参数的配置, 管理的工作包括机构用户、权限、字典、日志及业务类别管理五个内容;总线配置包括对总线初始化的配置、对服务 (总线出站服务) 的配置、对入站服务及中介策略文件的配置;第二部分是服务总线, 主要负责根据用户对总线的配置及中介策略文件, 完成对服务请求的路由、消息转换、广播、聚合操作。第三部分是UDDI注册中心, 主要负责完成对注册中心的管理, web服务的注册, 及提供用户对注册中心服务的查询。三个部分之间的关系如下:

1. 系统管理:提供基本的管理和配置功能, 负责管理和维护整个平台的基础信息, 提供服务总线正常运行的相关配置。

2. 服务总线:是平台的核心部分, 依据系统管理提供的相关配置信息, 完成对业务调度的相关操作。

3.UDDI注册中心:提供企业级服务信息存储库, 可将注册中心的服务与总线绑定作为出站服务, 也可将服务总线上的入站服务注册至注册中心, 以供消费者使用。

(二) 模块功能描述

基于SOA的财政应用整合平台每个模块的功能描述如下:

(三) 功能间的运行组合

该功能运行组合具体工作流程描叙如下:

1.作为业务调度的被调WEB服务通过UDDI的注册中心进行服务注册, 将WEB服务注册到注册中心并形成相应的语义文件。

2.注册中心将该服务利用服务总线的服务配置和服务总线上一个出站端口进行绑定。被绑定的被调服务可以被外界所查询。

3.作为业务调度的主调WEB服务通过服务总线的中介配置绑定至总线作为入站服务, 其与总线上相应的出站服务进行映射, 并制定路由转换, 广播, 组合等规则生成策略文件供总线中介使用。

4. 作为被注册的服务通过系统管理可以进行分类管理。

5.作为主调端的主调WEB服务通过UDDI的注册中心查找在UDDI注册中心注册的被调服务即出站服务, 并进行数据映射。

6.作为主调端的主调WEB服务在运行到需要调用被调端的被调流程的环节点时, 主调WEB服务通过服务调用框架调用入站服务。

7. 服务总线通过中介配置在注册中心查询并选择合适的出站服务调用绑定的被调服务。

8.激活被调服务处理业务数据完成后返回主调流程需要的相关信息给总线, 通过总线找到与被调服务相关的主调服务, 并将被调服务返回的相关业务数据返回给与主调服务绑定的入站服务。

9.总线将相关业务数据进行转换、聚合等处理为和主调服务数据类型一致的数据, 然后通过服务总线将数据给主调服务的环节点并启动主调服务。

(四) 基于SOA应用整合平台的实例

在财政国库支付系统, 对于一笔支付流程, 在启动支付之前, 必须要根据该预算单位到计划管理系统中进行额度检查, 只有支付额度要求, 才能进行成功支付。基于该应用整合平台, 具体实现的流程如下:

步骤说明:

1. 被调流程 (计划管理系统中的额度检查) 发布成服务

2. 注册中心将服务绑定至总线的一个出站端口

3. 工具节点从注册中心查找相关服务, 并进行数据映射

4. 调用服务调用框架,

5. 服务调用框架调用总线的入站服务

6. 总线通过中介选择合适的出站服务调用绑定的被调服务

7. 目标服务通过处理业务数据, 返回响应消息至总线与回调节点绑定的出站服务对应的入站服务。

8. 总线将返回消息进行相应处理, 并经由出站服务转至回调节点。

9. 回调节点接收并处理返回数据, 继续启动主调流程 (国库支付) 。

五、总结

遵照SOA架构设计的财政应用整合平台能够很好地实现各业务信息系统无缝集成, 消除了信息孤岛, 适应财政信息化的发展需求, 在一定程度上提高了现有信息系统的整体应用水平, 是对财政应用支撑平台很好的补充。

参考文献

【1】刘松付晓江面向服务的企业应用集成架构[J]吉林大学学报 (信息科学版) 2005 (6) :657-663

【2】刘翔刘家红吴泉源基于SOA架构的公安应用集成平台的研究与实现[J]计算机工程与设计200728 (18) :4519-4521

【3】徐署华江文基于WebService的企业信息集成平台设计[J]计算机工程与设计200728 (24) :59695972

基于SOA的物流平台设计与实现 第5篇

关键词：SOA,面向服务的体系结构,Web Services,网络服务,ESB,企业服务总线

1 面向服务架构

实施SOA包含3个技术理念:服务, 企业服务总线和松耦合。既然被称为面向服务架构, 那么服务也就是架构和核心, 我们该如何理解服务呢?参照在OASIS SOA Reference Model中的定义, 功能 (方法) 的提供者就是服务。这样的定义还是等于没定义, 对技术人员来说, 服务其实就是一个接口, 提供别人使用, 对程序而言就是一个方法, 但方法的定义是多种多样的, 你可以把增删改包装成一个接口, 也可以提供多个接口, 当然按照REST的Services我们还是要对每一个操作提供一个服务。因此我们尝试去寻找除了简单的方法之外, 服务还应包含的东西。

1.1 可传递性

可传递性是基于协议之上的。为了打造面向服务的体系架构, 一般我们将提供一种基础服务, 其本身用来封装底层协议的一些技术细节, 目的就是为了提供一致的功能, 这样对程序员来说也不用关心太底层的东西, 可以更加专注的提供业务实现上的支持。一般这些基础服务不包含任何的商业逻辑, 而是为上层的服务提供功能上的支持, 为的就是更好的将逻辑和实现区分开来, 以解耦合。往往我们需要多种这样的基础服务用来封装不同的协议, 伴随着可传递性, 我们还需要服务可注册和可发现, 只有有了固定的位置, 服务才能被调用。

1.2 可支配性

这是服务被关注最多的特性, 服务和服务之间必须是可交互信息的, 不管我们使用的哪种整合, 它都应该提高系统之间的交互, 使参与其中的应用系统可以协同工作。这对于整合是非常重要的, 实际上其承担了很多的任务。

首先我们需要辨别出数据来源自哪里, 来自不同服务中的数据被聚合在一起。这被称作集合。因为数据从不同的来源被收集起来以体现一个业务概念, 例如一张发票或者订单。

其次数据将会被传递。我们会再次混合已存的和新产生的系统。因为每个系统有可能采用不同语言编写的, 这样提供出来的数据格式因为语言的不同而不同, 这需要我们在各个系统中采用统一的规范, 使每个具体的应用系统都可以使用。

最后返回的结果也要一致性, 这样才能构成一个集成的整体。这个部分被成为合成, 意思是将结合成一个有意义的商业概念。

1.3 事务性

整合必须提供解决实际问题的事务性方法。也就是说, 能够处理在不同原有系统和新系统中发生的一系列操作, 还必须支持事务的ACID特性和具有赔偿性的长事务管理, 通常和商业事务是息息相关的。

安全, 整合系统应该提供系统访问权限, 虽然集成的各个子系统可能有其自身的身份验证逻辑功能, 但是集成后的系统要提供一个统一的身份验证, 也就是单点登录。这个安全系统不应该以不同的密码, 不同的应用程序, 甚至部分应用程序为基础, 而应该与所有重要的方面有关联, 例如加密技术, 鉴定, 授权和审核。

1.4 生命周期

整合结构应该提供一个可以控制所有有关应用程序生命周期的方法。通过这个方法, 可以使现有的程序实现全部或部分的替换而不会影响整合系统中的其他程序。当出现业务指令而且有足够的可用资源的时候, 可以一步一步的实现替换。这种替换应该在系统在线的时候也可以实现。这项功能通常是通过最小化应用程序之间的联系和具体化应用程序的时候实现的。

1.5 唯一性

一个标准的命名服务可以实现所在地的透明性和改变资源。命名服务通常是通过一个命名和目录来存储和查找与命名相关的信息的。理论上来说, 命名服务是统一的, 它可以为一个企业提供一个合理的图片。但是实际实施过程中通过复制和分类可以避免某一个点的错误。

1.6 可管理性

整合系统也需要一个管理方式。管理层应该为水平的和垂直的服务提供方法和工具。我们需要一个简单的可配置的, 可版本控制的管理功能。一个公开的管理系统应该能不需要修改源代码就可以改变和提高性能。远程的管理层能使管理从较远的地点实施, 从而最小化了对现场专业人员的需要。

2 集成方式

集成一般来说是指应用系统中多个层次的整合。是把一个问题, 分解为多个小的问题, 又将小问题分散到系统中的各个层次上。这样对每个小问题的解决将更加的快速和可控制。大体上可以将集成分为如下层次 (见图1) :

2.1 数据集成

数据集成关注的是在不同的应用系统中移动和共享数据库中的数据。虽然访问数据库的技术不难, 但是要实施数据集成却并不简单。问题在于数据库的复杂性。需要了解什么样的数据以什么样的形式存储在什么样的数据库中, 和什么时候及如何将这些数据提取出来。当然最重要的是对目的数据库的形式和结构的熟悉。只有这样才能将数据存储为所有应用系统都能识别的形式并且在使用这些数据时不会打破数据库的一致性。但实际的情况是, 数据库的集成在很大程度上依赖于数据库采用的技术, 并且数据库自身也因为产品的不同而造成数据结构的不一致。除非各个系统的数据存储方式的都一样否则很难真正实现数据层面上的集成。另外的一个客观因素是一般对数据的访问都是严格受限的, 为了访问到这些数据我们还是不得不去调用相应的程序接口, 如此说来仅仅依靠数据集成的方式很难达到我们的集成目的。

2.2 程序集成

程序集成面临的困难是, 不是每个系统都有预留的接口可供调用, 就算是有接口调用, 不同系统采用的不同语言, 让我们不得不寻找合适的方法去调用他们。因此程序集成面临的2个需要解决的问题:首先是理解程序本身的用途, 其次就是消除不同语言之间的隔阂。后者是通过暴露出接口APIs的服务来实现的。为此之上人们提出了建立一个ESB (Enterprise Service Bus) 企业信息总线来整合各个系统所提供的服务, 并将这些服务集合到总线中来。接口在应用系统之间建立了一个关联。只要接口保持不变, 就意味着各系统之间的关联不变。同时这也意味着接口将各个不同的信息系统连结成一个整体。这样我们可以充分发挥出针对接口编程的优势, 因为我们并不关心提供功能的具体实现是什么。只要接口保持不变, 我们可以在不改变整个信息系统和部分应用系统的情况下改变某个应用系统。

2.2.1 业务集成

当一个业务逻辑需要多个系统参与时, 我们要进行业务集成, 这需要我们将各个系统中的功能高度的抽象化。业务集成利用各个系统提供的服务功能的接口, 并根据接口组织成一个业务流程, 业务集成是我们利用系统的各个服务, 更加准确的解决实际需求中的问题, 我们不需要通盘否决历史遗留的系统, 那么肯定需要我们用新的技术对原有系统进行新的设计和封装, 才能用在我们的业务流程中, 并且为了将这些服务以自然的语言描绘出来, 通常人们使用BPEL (Business Process Execution Language) 工作流来描述实际的业务逻辑。有了更贴近自然语言的工作流, 我们就能更好的用计算机模拟现实的需求, 也能够更加专注的关注业务部分, 实现业务和技术的分离, 实现高度的松耦合。

2.2.2 显示集成

通常在完成了业务逻辑整合之后, 我们需要最后的工作就是表示层的集成。显示集成的结果就是为系统的整合提供了一个统一的显示平台, 用户可以进入这个集成系统的功能区。由于他们使用的是新开发的显示平台, 可能无法关注到现存的应用系统的多样性。显示平台通过提供商业连结, 使普通的接口也可以进入。因此, 显示平台就被隔离了并且不用关注现存应用系统的细节。

随着统一的显示层的发展, 我们隐藏了不同应用的背景, 系统遗留问题, 和其他新开发的东西。这样我们就提高了最终用户的效率, 并提供了不影响系统其他部分而改变遗留系统。

我们不应该将显示集成看成一个简单的用户接口的集成, 插入网页, 图表这类的整合, 这些我们通过应用系统的扩展就可以实现。我们也不应该将显示集成当成一种从现有的应用系统中提取数据的方式。

2.3 B2B集成

集成的最高阶段就是企业的相互集成, 企业的迅速成长使得企业间的服务也需要整合, 因为一个企业不可能行行做的出色, 当它需要其他领域的专业服务时, 他可以选择商业集成来获取更加全面和专业的信息。现在, 一个公司内部的应用系统整合已经远远不够了。企业间整合的需求越来越迫切, 这被称作B2B集成或者电子商务 (E-Business) 。在网页上发布产品分类已经过时, 现在需要的是在线的即时性信息, 和可靠性的品质。即使是知名的传统业务, 如果不付出努力, 在商务电子环境中也不能保持其地位。当然, 高效的电子商务或者B2B整合的先决条件是企业的信息集成系统的建立。现在的用户所希望的是即时的回复, 而不满足于慢节奏的等待。但事实是如果电子商务没有企业信息集成系统支持则无法成功。企业信息和显示系统是即时回复成功的关键。这看起来显而易见, 但现今的许多实例证明企业信息和显示平台的整合通常都是不充分的。这就导致了电子商务的功能不能很好的得以实现。主要的原因就是企业信息整合的不足, 这是影响电子商务是否成功的一个关键因素。另一个重要因素就是大部分显示系统都可以使用现有的和遗留的系统作为企业信息系统。使这两种系统充分的融合是成功的关键因素。为了更好的在各个层次上实现可集成, 对我们的系统提出了多层结构和高度的松耦合。

3 ESB建设和服务整合

在一个组织或者部门中谈到ESB的实施时都需要有一个对ESB管理层的总体理解。本质上来说, ESB是一个解决整合问题的技术产品。让我们从ESB的技术层面来探讨一下其优势。

下图表示的是不通过EAI和ESB如何将应用程序整合起来, 这被成为点对点结构 (见图2) :

这个应用显示的还是解决整合问题的一般方式。在这个例子中, 4个现存的应用通过点对点的方式整合到一起。点对点模型最基本的就是必须使用和保持的客户定制整合方案的数量。如果我们在应用域中增加一个新的应用, 复杂性和维护费用就会相应增加。我们要将新的应用与原有的环境整合在一起需要实施一个将三个应用整合在一起的整个方案。在这种应用环境下, 我们就应该考虑下想ESB这样的整合方案。有这样的整合应用程序的商业驱动器吗?在大多数组织中, 一个真实的商业活动都需要应用整合。新商品必须今天送达市场而不是明天, IT环境中也必须能够做到这点。ESB可以帮助提高IT环境的灵活性, 从而帮助为市场提供及时的新商品。考虑ESB的另一个原因是, 应用域在技术和协议上是世代交替的。当同时处理多个不同的协议时, 比如JMS, FTP, HTTP, SOAP, SMTP和TCP, 在应用间实施新的整合方案是很困难的。ESB提供了协议和技术更新器, 以适合IT环境的更替性。第三个原因是降低了整个应用系统的成本。在点对点模型中, 整合点的管理和维护是很耗时的, 因此很昂贵。使用ESB方案可以使管理和维护变得简单因此不那么费时。

我们已经说明了点对点模型和它的缺点, ESB的引入可以使增加和维护一个新的应用变的简单。接下来请看下面的图例 (见图3) :

从图表中可以看出, 最明显的变化就是减少了不同应用之间的整合点的数量。所有的应用都与ESB相连接。注意在上图中显示的ESB展示的是一个高层次的整合。它隐藏了整合逻辑实施的复杂性, 但是复杂性是依然存在和需要处理的。点对点模型和ESB的最大不同在于ESB的设计可以面临整合的挑战。因为ESB提供了所有整合的功能, 平台和管理环境, 实施系统间的新整合因而变的更简单了。如上图所示, 增加一项新应用也变的前所未有的简单。新应用与ESB通过输送协议和适用于这项应用的技术更新器相连结。在集成的过程中, 通过ESB可以有效的使现存的3个系统和新系统建立联系。

因此我们来总结一下一个ESB所具有的最核心的功能:

服务的位置透明–ESB要提供一个服务注册平台, 使得服务的消费者能搞定位到服务的提供者并消费服务。

不同协议的相互转换-ESB能够集成并转换不同的协议如HTTP (S) to JMS FTP to FILE SMTP to TCP

消息解析-通过使用XSLT和XPATH能够轻松解析出消息做携带的信息

消息路由-一个ESB所最重要的功能, 控制消息。

消息增强-一般针对外部进来的消息, 经常确实一部分信息, 要能搞识别和补充必要的信息。

基本安全能够支持角色权限验证, 以及支持加密解密。

消息的监控和管理一个更高层次上对消息的控制和管理。

SOA架构电子政务基础应用平台 第6篇

1 软件危机与SOA时代

二十世纪六十年代末期, 随着信息技术的发展, 一些发达国家已经开始意识到软件危机时代的到来, 软件成本不断增长, 已成为计算机系统的最大开销。软件开发周期长, 进度难控制, 质量难保证, 使得计算机科学在软件危机中挣扎。一些计算机专家们开始认识到软件开发必须以创新的方法来指导。二十世纪八十年代, 软件发展为面向对象的分析与设计方法, 形成完整的面向对象的技术体系, 这个体系的形成, 使软件的生命周期、规模、质量、应用范围有了大规模的提升。面向对象的编程方法推动了大规模工业化软件生产环境的产生。

二十世纪九十年代, 组件和构件技术逐渐成熟, 人们开始对软件复用产生需求, 并高度关注软件是否能适应业务的发展, 即软件系统的敏捷性, 组件技术的发展代表了开放、敏捷、可扩展、可组合的软件架构时代的到来, 由此面向服务的体系架构SOA (Service-Oriented Architecture) 应运而生。

2 SOA要实现的目标

SOA的重中之重是服务, 这是SOA的核心理念。SOA提供的异构服务、松耦合服务, 所带来的好处是提高应用系统敏捷性、灵活性、降低应用系统开发成本, 使异构和分布式环境中的信息共享变得更加容易。SOA所要实现的目标是构建灵活可变的应用系统, 要达到灵活性, 主要通过三个途径解决, 一是标准化封装, 一是复用, 一是松耦合可编排。

2.1 标准化封装

传统软件架构因为封装技术的不成熟, 以及对基础应用平台的依赖性, 一直不能解决异构系统互联互通问题, 传统的中间件也只是解决了访问的互操作, 即通过标准化的API实现了同类系统之间的调用互操作。

SOA则是通过一些标准的、支持Internet、与操作系统无关的SOAP协议来实现连接互操作, 服务的封装则是采用XML协议, 具有自解析和自定义的特性。SOA所实现的互操作是通过一组标准族实现访问、连接和语义等各种层面的互操作。

2.2 复用

软件的复用技术是指不经过修改, 或少量修改底层程序就可以多次使用的技术。最原始的复用是“子程序”调用, 但是这种复用范围仅限于可执行程序内复用, 静态开发期复用, 如果子程序修改, 意味着所有调用这个子程序的系统必须重新编译、测试和发布。为了有效地解决“软件复用”问题, 软件开发商们开始研究发明了组件 (控件) , “组件”将复用提升了一个层次, 目前SOA所采用的是以服务为核心的中间件产品WebService、SCA/SDO等, 采用这些技术实现实现SOA的好处在于, 使用中立平台获取服务, 这些中间件通过服务和服务组件提供更高层次的复用、解耦和互操作。

2.3 耦合关系

传统软件将软件核心分为三部分:网络连接、数据转换、业务逻辑全部耦合在一个整体中, “牵一发而动全身”, 这种软件很难适应处于不断变化的业务需求。SOA架构通过服务的封装, 实现业务逻辑与网络连接、数据转换等完全的解耦, SOA在不断解耦的过程中, 显示了它独特的松耦合性。

3 采用SOA技术架构基础应用平台

SOA时代的到来, 推动了基础应用平台的发展, 所谓基础应用平台是指在基础设施平台 (网络、服务器等) 与应用系统平台之间的一个中间件平台, 其主要功能是解决应用系统与基础设施、操作系统之间的交互、管理问题, 基础应用平台同时承担着不同应用系统之间的互联互通功能, 因此也有人可称之为“应用集成”平台。

SOA架构的基础应用平台的主要特点是其开放性和松耦合性, 平台提供的集成服务分为三个层次。

(1) 基础服务

包括基础网络、应用服务器、操作系统、集群等。

(2) 总线服务 (ESB)

包括标准服务、交互服务、信息服务、组件服务、接口服务、数据服务等。总线服务 (ESB) 是一个实现通信、互连、转换、可移植性和安全性标准接口的企业总线平台。ESB的主要功能有通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模和管理等。这种总线服务同时提供了系统集成功能, 对于应用系统来说是即插即用, 当新的应用系统需要上线时, 通过标准接口, 直接与服务总线相连即可提供服务。

(3) 应用服务

包括集成开发工具、组件接口、集成运行环境、集成开发环境等。

SOA架构体系从顶层设计上对传统应用平台理念产生了颠覆性变化, 从设计理念上分析, 传统应用平台是基于业务需求的直接映射, 这种“需求驱动”的平台 (软件) 设计理念存在的最大缺陷是对需求变化的适应性差, 这也是传统软件工程造成的“软件危机”最直接的表现, 只有采用“架构驱动”, 才能满足业务需求的柔性变化。在这种需求的驱动下, SOA以它的粗粒度、开放式、松耦合的架构体系脱颖而出, 它要求系统在开发过程中按照一定的标准体系进行分层开发, 通过这种分层设计方法, 提高平台的灵活性和敏捷性, 这就是SOA以服务为核心的灵魂。

SOA设计思想是通过对系统组件的不断扩充, 形成满足业务需求的行业“组件库”, 通过组件库在基础应用平台上组建应用系统, 从而不断丰富业务应用。

基于组件化的SOA平台创建的应用系统其优势主要表现为可复用性强、集成能力强、随需应变能力强。

例如在传统的OA系统中, 要实现某个工作流的流转, 需要在系统中提供两个基本的功能:即工作流引擎和自定义表单, 工作流引擎实现业务流转, 表单提供流程过程中的业务数据存储。但许多情况下, 系统的工作流跨越不同业务, 需要将不同业务整合到同一个工作流中, 此时若把工作流作为一种“组件”方式进行调用, 能轻松完成不同类型 (跨部门跨业务) 工作流流转。

4 需求驱动基础应用平台发展

随着国家电子政务及企业信息化的深入, 目前摆在政府部门和企业信息化中的核心需求是将同时期、不同供应商所创建的应用系统, 逐步实现规范化标准化, 使各系统之间互联互通资源共享。这种互联互通, 不只局限于政府部门内部, 更重要的是跨部门之间的业务协同。目前政府部门的政务信息化建设工作, 已逐步走向建设基础应用平台、建设数据交换中心、建设行业信息资源库方向发展, 这些需求的核心就是建设开放式的应用服务体系。

在我国信息化发展的30年中, 企业及政府部门形成的“信息孤岛”, 已经成为我国信息化发展的瓶颈, 对于各单位信息化主管部门, 它已成为“弃之可惜, 食之无味”的鸡肋, 直接阻碍了我国信息化的整体发展。近年来政府部门不断创新行政体制改革, 优化调整组织机构, 优化工作流程及管理模式, 造成业务涉及范围的变化。

传统的以需求为驱动的应用系统, 由于缺乏业务变化的适应性, 已无法满足用户需求, 系统开发商只能不断地修改底层应用程序, 造成软件成本成倍增长。正确的架构是指导政府和企业实施信息化的良好基础, SOA的架构驱动方式, 推动了我国政务信息化基础应用平台和集成平台的发展, 这种架构依据“动态重构”技术支撑, 通过信息共享平台实现业务流程协同管理, 充分显示基础应用平台的灵活性与开放性。

目前一些大型软件供应商都在研究设计基于开放平台的产品, 这种基于业务化思想实现的基础应用平台, 包含数据建模、模拟与测试、部署、运行、监控、管理。这些成型产品提供了高性能和可扩展的流程引擎, 可以支撑证具有部门特色的复杂流程模式, 以及基于Web方式的流程业务化配置与调整等功能。这种平台架构通常采用业务与技术模型一体化的建模方式, 能够快速提高用户的满意度。

云计算的应用、SOA的悄然兴起, 标志着中国电子政务与信息化建设进入一个新的时代, 业务与技术需求的并存, 把面向服务的软件架构体系SOA推向更高境界。

5 结束语

“基于网络、面向服务、流程驱动”技术为建设新一代电子政务基础应用与信息共享平台奠定了基础, 创造了条件。未来的基础应用平台的发展将会最大程度地适应用户需求变化, 最大程度复用标准化组件。各级政府及企事业单位将逐步建成自身的基础应用平台, 同时形成各具特色的专业组件库, 利用组件库与平台技术, 构建具有行业特性的业务应用系统已不再是难题, SOA将推动我国电子政务和信息化建设领域走向新的时代。

摘要：本文浅析了SOA作为面向服务的软件架构体系特点, 对比了传统概念的基础应用平台理论与SOA架构基础应用平台的区别, 分析了基础应用平台的发展历程及未来发展趋势。

SOA平台 第7篇

MIS系统已经成为企业提高信息化程度的重要依托, 但是因为缺乏统一的规划和设计, 这些MIS系统在扩展和完善的过程中采用了不同的技术, 甚至数据库, 操作系统和设计语言都可能不同, 这样就带来了数据交换和数据同步的问题。通常我们把这些MIS系统称为“信息孤岛”, 数据同步和一体化成为解决问题的重要途径。

SOA是一种架构模型, 它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA具有以业务为中心、灵活的适应变化、重用IT资源, 提高开发效率和更强调标准四个特点。因此, 它是适用于解决企业业务应用中的实际问题, 如分布式业务服务的通信, 信息资源整合等。

Web Service是现在最适合实现SOA的技术, 具有完好的封装性、松散耦合、使用协议的规范性、使用标准协议规范、高度可集成等特点, 非常适合于异构环境。

XML是一种面向应用的互联网标记文档包含内容和结构的语言。XML是可扩展的、平台独立的和容易在网络上传输, 所以它非常适合于描述数据同步和数据库集成的信息。

基于SOA的数据同步与集成解决方案

1解决方案的架构

基于SOA的Web Services体系结构有三个部分:services provider, services r egistry, services consumer。该解决方案可以被分为三层体系结构 (图1中所示) :应用层, 服务层和数据层。数据层包含各种需要集成的MIS数据库。服务层是解决方案的核心, 包括Web服务封装, 组成, 注册, 发现, 调用和数据映射模块。应用层包括应用程序客户端系统和信息门户。

2各层的功能

应用层包括应用程序、网站和客户端。该层中, 用户或客户端通过应用程序或网站发送SOAP服务请求。

服务层是为不同的用户提供统一的数据访问接口, 并完成以下功能:数据传输, 在services provider和services consumer之间进行数据交换, Web Service的注册功能, 发现和调用, 在XML和XML之间动态数据交换。

根据MIS系统集成的需求, 数据层API函数或ADO.NE T连接数据库, 然后封装成Web Service的数据, 其中包括Web服务描述 (WSDL) 和服务数据。Web服务描述定义地址, 传输协议, Web Service的接口。Web Service单元是基本实体, 基本服务不能再分割, 也不能包含其它服务。

网站和SSO的实现

网站是基于Web的应用程序, 主要是提供个性化的显示, 单点登录 (SSO) , 不同来源的内容集成和信息存储。

1跨域SSO

异构MIS系统也许在不同的域, 每个系统都有自己的认证机制, 也没有可供参考的授权信息。因此, 跨域单点登录的实现是必要的。

SSO自动授权是建立在所有分散用户帐号的集中管理系统的信任关系之上。因为所有的用户信息存储和管理是在统一模式下完成, 所有的工作管理员需要做的就是在一个统一的用户信息数据库添加、修改或删除用户。

2统一身份认证

统一身份认证 (UIA) 中 (如图2中所示) 的原理是, 在对话中当用户访问认证保护的资源, UIA服务器将生成一个称为令牌的验证凭证, 其中包含用户的身份信息和一个随机数, 从而使用户能够访问异构资源, 无需重新验证。

2.1域认证程序

一, 浏览器访问应用服务器A。

二, 应用服务器A发现没有用户登录, 然后将浏览器重定向到统一登录页面, 用户输入登录信息。

三, 登陆页面发送认证要求给身份认证服务器, 服务器调用认证Web Services。

四, 身份认证服务器生成令牌, 它记录在数据库中, 然后验证浏览器的用户令牌如果是有效的, 否则重定向到登录页面。

五, 浏览器访问应用服务器A的令牌。

六, 应用服务器A发送请求给身份认证服务器授权令牌。

七, 身份认证服务器响应身份验证信息到应用服务器A。

八, 如果验证是有效的, 应用服务器A显示浏览器请求的资源, 否则重定向到登录页面。

2.2跨域认证程序

(1) 浏览器访问应用服务器B;

(2) 应用服务器B按照自己的身份验证机制, 如果没有找到用户的登录信息, 则发送请求到身份认证服务器验证登录信息;

(3) 身份认证服务器执行数据库查询操作和响应令牌信息发送到应用服务器B, 否则重定向到登录页面;

(4) 应用服务器B将显示用户请求的资源。

Web服务封装

1支持MIS系统编程接口 (API) 的封装

根据服务标准, 第一, 封装功能组件到Web服务组件, 然后用WSDL描述服务和写入从XML文档提取的数据。整个过程可以分为以下几个阶段:API函数库引用, Web Services对象声明, Web服务方法声明, 调用API函数操作数据库和释放本地应用程序对象的引用。

2封装访问MIS系统的Active X数据对象 (ADO)

封装ADO访问Sql Server或者ORACL数据库是通过Data Set组件的Write Xml方法, 方法由Sql语言的基础上提取数据, 然后辨别XML文档。

异构数据同步和整合

数据同步的过程是将应用系统的数据当前状态和另一个的异构系统相关的数据保持一致, 这个过程忽略数据操作的细节。目前, 数据同步没有标准的定义, 本文所述数据同步是指可以实现在异构平台多数据库的数据一致性的技术方法, 可以分为单向数据同步和双向数据同步。

1数据同步

1.1单向数据同步

数据流从一个数据库到另一个数据库是单向的。在这个过程中, Node B只需要对Node A进行查询操作, 不涉及插入, 修改和删除。换句话说, Node A是主域和Node B是从域, 数据流不冲突。数据同步操作发生时, Node A的数据已经改变了。

1.2双向数据同步

Node A和Node B的数据流是双向的。这包括两种模式, 一种是Node A上需要Node B上的数据, 反之亦然。但Node A与Node B的数据必须是独立的, 并在不同方向的数据流没有交集, 数据操作只包含查询, 修改, 删除, 不涉及插入。另一种是Node A和Node B操作修改、删除、插入, Node A和Node B可以运行相同的数据, 这可能使数据不一致的, 因此在该模式中, 数据不匹配是关键的问题, 需要采取措施来防止数据冲突。

2数据同步和集成的双XML交换模型

2.1双XML交换模型

本文提出了一种双XML交换模型, 实现基于Web Service的数据同步和整合。主要是通过Web Service从源数据库将数据抽取到源XML文档, 并通过映射规则将数据映射到目标XML文档, 最后, 将目标数据写到目标数据库。

2.2 XML的映射规则

将所需的数据封装成XML格式的Web Service需要一个将XML源文档转换到目标文档的映射文档。XML文档映射结构可分为四个部分 (如图4所示) :源XML结构信息, 目标XML结构信息, 映射规则和映射规则的条件。

<synchronization>:用户定义的映射规则。“ID”属性值, 映射规则的名称, 可用于查找所需的映射规则。

<source>:描述源数据表结构。

<goal>:描述目标数据表的结构。

<dataschema>:“Name”属性值描述数据库的方法。

<mapping>:此项定义源字段和目标字段之间的对应关系。“源”的属性值等于源字段的名称, “目标”的属性值等于目标字段的名称。“ispropertymatch“定义源字段映射字段, 如果当前字段是映射字段, 则属性值为“是”, 它需要检查源表的内容是否存在选择更新操作或者插入操作。

<conditions>:此项定义了一个重要条件。

基于上述映射规则, XPath和XQuery查询语言通过查询过程的可执行功能将Web Service的XML文档转换成统一结构的XML文档, 以满足复杂的查询要求。

目标XML文档是一种联合数据集, 可以映射和转换到关系数据库和封装成粗粒度的服务和UDDI中心注册联盟的数据集。

UDDI中的Web Service操作

1 Web Service模型建立

在Web服务模型的建立之前需要确认模型文件是否存在。如果基于WSDL的Web Service存在, 则记录名称和关键键, 否则, 创建一个新的模型接口, 具备一个统一资源定位的WSDL文件名称和索引。

2转换规则

源模型 (图3) 的业务模式包含各种类模型。在此模型中的元素主要是类。

3 Web Service的注册

注册可以通过编程或用户界面实现。本文利用微软UDDI.NET SDK编程工具。

4 Web Service的发现

进度的查询可以分为以下几个步骤:创建调查对象并设置调查URL参数, 声明Find Business对象并设置查询服务名称和性质, 获得Web Service Business List对象然后搜索Business Info, Service Info Business Service, 该Binding Template反过来, 最后获得Access Point对象和调用Get Text () 方法来获取URL Web Service。

5 Webservice的调用

调查后, 服务请求得到给定的URL, 然后调用Web Service, 它通过使用SOAP消息通过防火墙, 最后绑定到应用程序流来实现数据交换。在实际应用中, 有必要建立一个代理类, 可以交流给定的网络服务。为了使用代理类, 必须生成一个CS文件并添加到应用程序项目。

实例

假设以下实例, 补贴信息系统 (系统A) 需要同步学生基本信息, 学生信息系统 (系统B) 。系统A和B连接UDDI服务器可以通过SOAP或WSDL XML消息服务组件同时发送和接收的XML消息。

当数据更新时, 数据库触发器被触发。Web Service服务器将数据封装成Web Service, 然后在UDDI注册中心发送消息到消息队列。应用系统访问Web Service的URL获取XML文档, XML映射文件处理后, 应用系统将数据写入到目标数据库。整个数据过程显示在图3, 图4中显示XML文档映射。

结论

SOA平台 第8篇

电力工程在其整个生命周期的各个阶段, 从工程设计、工程施工到工程维护阶段都会产生大量包括设计图纸在内的文档资源, 这些文档资源被分散在不同的客户端, 而同时不同客户端之间沟通协作效率低下, 造成了不少人力、物力及时间的浪费, 严重影响了工程的实施效率, 延长了工期, 增加了工程成本。

另外, 在电力系统信息化建设过程中, 由于现有的信息系统是在不同时期、不同软件开发商分别独立开发完成的, 又归属不同电力企业或业务部门使用, 缺乏从整个行业的角度进行统一规划和设计, 开发时间不同, 使用的操作系统、系统模型、数据格式等都各异, 系统间信息交互困难, 导致各部门、各企业资源没有充分共用、信息不能合理共享、部分网络和应用系统自成体系, 形成了大量分散异构的“信息孤岛”。“信息孤岛”的存在严重阻碍了信息资源的有效共享, 造成了大量的重复建设和资源浪费, 极大地限制了电力系统信息化资源的应用, 阻碍了我国电力事业的发展。

为了消除电力系统存在的“信息孤岛”, 进行信息集成已逐渐成为研究的热点, 然而当前的电力信息集成都是一种紧耦合的集成, 本文提出了构建一种基于SOA的松耦合的电力系统协同设计管理平台。

1 SOA系统与协同管理

1.1 SOA系统结构与实现技术

面向服务架构 (SOA) 的概念是Garmer Group于1996年提出的, 它是一个组件模型, 将应用程序的不同功能单元 (称为服务) 通过这些服务之间定义良好的接口和契约联系起来, 接口是采用中立的方式进行定义的, 独立于实现服务的硬件平台、操作系统和编程语言, 使得构建在各种这样的系统中的服务可以用一种统一和通用的方式进行交互[1]。

SOA架构的体系结构模型通常由服务提供者、注册中心 (UDDI) 、服务消费者组成。服务提供者与服务消费者通过事先定义好的契约进行交互[2] (见图1) 。

1.2 协同管理

协同管理是把局部力量合理地排列、组合, 来完成某项工作和项目, 它是以虚拟企业为对象的管理理论体系。虚拟企业的实质是一个由许多子系统组成的系统环境, 协同管理就是通过对该系统中各个子系统进行时间、空间和功能结构的重组, 产生一种具有“竞争-合作-协调”的能力, 其效应远远大于各个子系统之和产生的新的时间、空间、功能结构。

2 基于SOA的协同设计管理平台及其实现

2.1 平台架构

基于SOA的协调设计管理平台包括2层:内层为协同设计管理平台, 外层为服务中心 (见图2) 。

协同设计管理平台以项目基本数据为基础, 在工程项目的各个过程中, 实现对各种类型工程内容的有效管理与控制, 确保分散的工程内容的唯一性、安全性和可控制性, 使获得授权的用户能迅速、方便、准确地获得所需要的工程信息。

协同设计管理平台的协同包括以下3个层次:

(1) 上下游。实现整个工程的上下游部门间的数据共享与互操作。

(2) 专业间。实现不同专业领域间的工作与信息相互参考。

(3) 跨地域。实现远程跨地域部门和工程人员间的沟通与协同工作。

2.2 平台功能

协同设计管理平台的作用是保证各个专业的设计能够汇总到一起, 使数据和文件既可以相互独立, 又能做到有效统一, 实现精确的版本管理, 并能兼容目前业界的各种图形、文字、图像格式。

协同设计管理平台有以下功能:

(1) 出图管理:图纸设计、转换与归档;

(2) 知识管理:图文标准化制定与管理;

(3) 系统管理:包括权限管理、服务器配置、日志管理;

(4) 文档管理:包括文件夹管理和文件管理;

(5) 流程管理:包括工程流程、卷册流程、专业流程管理。

系统用户根据自己的需求向服务中心申请相应的服务功能, 而协同设计管理平台将根据不同的服务为用户提供相应的协作与管理支撑, 在保证用户服务得到最大的满足的同时实现系统资源最大的共享与最优分配。

2.3 平台实现

图3为协同设计管理平台的实现流程, 其中中间方框内为协同设计管理平台, 主要包括设计团队协作、电子文件在线管理、访问权限设置、专业提资流程和ISO体系文件流程5个协同工作模式, 这些模式在生产管理系统及FTP服务器的支撑下工作, 此平台采用.NET2.0框架, 利用C#语言实现。

基于SOA的服务中心提供以下各种服务功能。

(1) 图纸绘制。在工具菜单或系统托盘右键菜单中, 选择“插图框”菜单项。在弹出的“图框工具”窗体中, 选择图签类别、绘图比例、图幅、方向、图纸属性项 (图号、图名、工程名、设计阶段) , 轻点确定。程序会自动在当前CAD中生成一个标准图框图签, 同时图纸信息会同步填写到图签对应的位置。

(2) 图纸拆分。图纸拆分主要是将DWG文件中的多个图逐一拆分出来, 确保一个DWG文件中只包含一个图。值得注意的是, 被拆分的文件中, 图纸必须要有一个封闭的矩形框 (也可以由4根直线组成, 但必须封闭) 、各图的图框不能重叠。

(3) 图纸转换。图纸转换是依托Auto CAD环境, 利用打印驱动将DWG格式的电子文件转换为其他格式的电子文件, 支持的格式有:PDF、JPG、DWF、PLT。

(4) 图纸归档。图纸归档服务是针对图档管理系统的接口要求而开发的一个功能。档案人员在归档底图时, 用条码枪扫描底图上的条形码, 系统自动在协同平台中查找与之对应的电子图纸。

(5) 图文信息标准化模板管理。图文信息标准化模板管理用于设计院的标准化定制及发布。通过灵活快捷的定制程序, 按照企业的标准定制出不同的模板, 在设计院内发布标准化的模板规范, 在图纸拆分、分析提取、图纸转换、生成图纸目录、绘图等过程中使用图签和表格模板, 可使准确率高达100%, 同时使得企业图纸的图框标准完全符合设计院的标准规范, 达到全院图纸标准统一。

(6) 权限管理。对工程级文件夹和专业级文件夹设置用户权限。

(7) 服务器配置。包括添加/删除FTP服务器, 修改FTP服务器信息, 将工程绑定到FTP服务器, 将已绑定FTP服务器的工程重新绑定到其他FTP服务器。

(8) 日志管理。主要进行日志的查询与分类设置。

(9) 文件管理。主要包括文件的上传与导入、文件重命名、文件删除、文件的锁定与解锁、文件的下载与导出、文件共享、文件版本管理及文件操作日志记录等功能。

(10) 工程流程管理。工程级别的流程主要包括:开工通知单、设总审批、项目设计计划、项目设计计划变更通知、项目评审记录和委托项目任务书。开工通知单流程在Web平台中启动并走完, 在协同平台中只有只读权限。其他流程统一在协同平台中新建流程管理界面, 使用通行证直接调用Web平台中的相关页面。

3 平台应用

目前, 协同设计管理平台已在湖北省电力勘测设计院各分公司及管理部门使用, 用户总数约500人。该平台的使用, 提高了设计人员的设计效率, 统一了设计规范, 使各工程的设计文档归档率大幅提高, 方便了管理人员掌握各个项目设计的进展情况, 加强了监管工作的及时性, 降低了管理工作的强度, 提高了管理人员的工作效率。截止2009年11月, 湖北省电力勘测设计院输电分公司70%的工程进入该平台, 累计创造经济效益100万元以上;湖北省电力勘测设计院变电分公司85%的工程进入该平台, 降低工程管理成本数十万元;湖北省电力勘测设计院规划分公司新的设计工程已全部在该平台上设计执行, 原有的设计资料已有60%进入该平台, 通过平台的使用, 降低了工程的管理成本, 已取得了经济效益80多万元。

4 结语

基于SOA的电力系统协同设计管理平台以管理产品的思路来管理设计企业的图纸生产过程, 以协同平台作为支撑来实现上下游、专业间以及跨地域的用户间能够进行自由的数据互操作与协作, 实现服务与信息的共享。基于SOA的电力系统协同设计管理平台可以为电力系统带来如下效益:

(1) 加强设计的计划性, 使企业在设计进度中得到一定程度的确认;

(2) 规范产品数据管理, 建立企业服务规范和协作规范;

(3) 解决设计中协作频繁出错问题, 加强协作效率;

(4) 建立知识库, 提高电子图复用价值, 建立学习型组织;

(5) 解决人才流动引起的后期服务问题和知识流失问题。

参考文献

[1]李锦棠.企业SQA服务集成的研究与设计[D].广州:广东工业大学, 2006.

[2]王滨, 黄永锋, 许晓东.基于SOA的应用程序框架研究与实现[J].计算机工程与设计, 2006 (7) :1198-1201.

[3]刘松, 付晓江.面向服务的企业应用集成架构[J].吉林大学学报 (信息科学版) , 2005 (3) :657-663.

[4]史美林.CSCW计算机支持的协同工作[J].通讯学报, 1995, 16 (1) :55-61.