电子政务SOA应用模式.doc

长风联盟电子政务SOA应用模式研究报告长风开放标准平台软件联盟二七年五月目 录第一章 概述11.1 目的11.2 本书的适用对象21.3 本书与其他研究内容的关系21.3.1 与总体框架及标准规范的关系21.3.2 与解决方案的关系31.4 本书的依据3第二章 SOA应用模式研究概述42.1 应用模式概述62.2 应用模式研究目标62.3 应用模式的范围72.4 应用模式的研究方法82.5 应用模式研究的理论和依据82.6 应用模式与其他热门研领域的关系92.6.1 应用模式与现代服务业的关系92.6.2 应用模式与服务库的关系9第三章 SOA总体应用模式研究113.1 软基础设施123.1.1 名称123.1.2 问题123.1.2.1 信息孤岛现象普遍存在，难于实现信息共享133.1.2.2 业务由于系统的隔离难于实现协同143.1.2.3 建设投资居高不下，用户承担高危风险153.1.3 解决方案163.1.3.1 梳理业务形成业务及信息地图163.1.3.2 业务活动梳理和编目及查询173.1.3.2.1业务活动之间的关系梳理和编目及查询173.1.3.2.2基础信息维护与编目及查询183.1.3.2.3结构化业务数据维护与编目及查询183.1.3.2.4非结构化业务数据维护与编目及查询183.1.3.2.5应用资源类维护与编目及查询183.1.3.3 如何跟踪业务的变化193.1.3.4 业务的变化与信息化调整的关系193.1.4 关键因素193.1.4.1 业务编目203.1.4.1.1目录编辑213.1.4.1.2资源编码213.1.4.1.3资源分类213.1.4.1.4目录数据管理213.1.4.2 业务编目传送223.1.4.3 业务编目管理223.1.4.3.1元数据审核233.1.4.3.2目录管理233.1.4.3.3目录服务管理233.1.4.3.4目录发布243.1.4.4 业务编目服务243.2 虚拟数据中心253.2.1 名称253.2.2 问题253.2.2.1 整体数据与局部数据的关系无序273.2.2.2 数据的一致性问题273.2.2.3 数据共享问题273.2.2.4 全局数据分析的问题273.2.3 解决方案273.2.3.1 基础接入层283.2.3.2 信息整合层283.2.3.3 存取服务层303.2.4 关键因素313.2.4.1 联邦技术313.2.4.2 复制技术333.2.4.3 信息搜索353.3 业务协同373.3.1 名称373.3.2 问题373.3.2.1 各部门遗留系统异构自治，实现跨部门维护与交换困难383.3.2.2 传统的政务机关内部系统垂直化，不利于数据交换与业务的 协同393.3.2.3 实现跨地区、跨部门的业务协同需要新技术手段支持393.3.3 解决方案393.3.3.1 思路分析403.3.3.2 实施要点443.3.4 效果463.4 资源共享483.4.1 名称483.4.2 问题483.4.3 解决方案493.4.3.1 技术架构503.4.3.2 系统特色与优势513.4.3.3 功能体系结构523.4.3.4 系统功能模型543.4.4 实施要点543.4.5 应用模式探讨613.4.5.1 信息资源交换体系应用模式613.4.5.1.1业务需求613.4.5.1.2信息资源交换内容623.4.5.1.3信息资源交换流程623.4.5.1.4信息资源交换周期633.4.5.1.5系统主要功能633.4.5.1.6信息资源交换的重要意义643.4.5.2 信息资源目录体系应用模式653.5 多服务渠道673.5.1 名称673.5.2 问题673.5.2.1 服务展现渠道单一683.5.2.2 服务供应渠道混乱693.5.2.3 服务型政府的课题693.5.3 解决方案693.5.3.1 思路分析703.5.3.2 实施要点773.5.4 效果78第四章 SOA应用模式的分类体系研究804.1 SOA的应用模式分类体系804.2 从软基础设施的视角研究模式分类804.3 基于虚拟数据中心的模式分类824.4 基于SOA的资源共享应用模式824.5 基于SOA的业务协同应用模式864.6 基于SOA的不同服务渠道的应用模式87第五章 SOA应用模式的适用性评估905.1 软基础设施905.1.1 单节点软基础设施905.1.1.1 适用条件905.1.1.2 效果905.1.2 跨节点软基础设施905.1.2.1 适用条件905.1.2.2 效果915.2 虚拟数据中心915.2.1 单节点虚拟数据中心915.2.1.1 适用条件915.2.1.2 示例915.2.1.3 效果915.2.2 跨节点虚拟数据中心915.2.2.1 适用条件915.2.2.2 示例915.2.2.3 效果915.3 资源共享925.3.1 部门内资源共享925.3.1.1 适用条件925.3.1.2 示例925.3.1.2.1设计目标935.3.1.2.2设计思想935.3.1.2.3信息资源层总体设计935.3.1.2.4信息资源目录设计985.3.1.2.5目录体系结构设计985.3.1.2.6目录框架设计995.3.1.2.7目录功能设计1015.3.1.2.8目录服务的功能组成1015.3.1.2.9目录体系概念1015.3.1.2.10功能实现1025.3.1.2.11信息资源目录接口1045.3.1.2.12目录的工作原理1065.3.1.2.13目录管理与存储1065.3.1.2.14目录体系管理架构1065.3.1.2.15管理职责1075.3.1.2.16存储与更新1085.3.1.2.17目录服务模式设计1085.3.1.3 效果1095.3.2 跨部门资源共享1095.3.2.1 适用条件1095.3.2.2 示例1095.3.2.3 效果1135.4 业务协同1135.4.1 组织内部门间业务协同1135.4.1.1 适用条件1135.4.1.2 示例1145.4.1.2.1项目背景1145.4.1.2.2解决方案1145.4.1.2.3项目效果1165.4.2 跨地区跨部门业务协同1165.4.2.1 适用条件1165.4.2.2 示例1165.4.2.2.1项目背景1165.4.2.2.2业务现状1175.4.2.2.3业务涉众1185.4.2.2.4解决方案1195.4.2.2.5项目效果1225.5 渠道多样化1235.5.1 渠道整合应用服务1235.5.1.1 适用条件1235.5.1.2 示例1235.5.1.2.1项目背景1235.5.1.2.2解决方案1245.5.1.2.3项目效果1275.5.2 多种用户体验1275.5.2.1 适用条件1275.5.2.2 示例1285.5.2.2.1项目背景1285.5.2.2.2存在问题1285.5.2.2.3面向服务架构的方案129第一章 概述1.1 目的SOA是应对经济全球化、业务网络化和企业“随需应变”的社会经济变革而产生的软件“解决之道”。作为一个国际性的技术趋势，SOA被称为软件产业的伟大革命，也是我国软件产业和信息化应用领域的巨大机遇和转折焦点。随着SOA技术的不断完善，SOA理念与技术实践开始日趋深入。从国内整体市场看，越来越多的政府机构和企业已经跨过了对SOA的价值及重要性的认知阶段，开始从概念普及、局部尝试准备进入到大规模应用阶段。但是，如何基于国内的SOA需求环境让SOA真正落地，如何在各行业构建满足SOA特征的应用成为是目前我国软件企业与服务提供商正在面对的一大难题。正是基于此，SOA应用模式研究尤为显得重要，只有SOA的应用模式被深刻理解， SOA应用推广工作才会有据可依，大力推进SOA在中国的成功应用才会有坚实的基础。应用模式研究的主要目的在于：1) 对行业业务的应用状况进行深入研究，确定行业业务下一步需求的方向，指出传统软件开发方式的解决方案以及带来的局限性，定位SOA在这些方向的应用前景2) 根据对行业业务的应用状况的了解，对SOA的应用模式进行分类体系研究，并指出在各分类应用模式下SOA如何解决相应的业务问题3) 建立各类应用模式下SOA应用特征，主要是指基于各类应用模式下的应用构建思路。4) 研究各分类应用模式的适用条件，并对各类应用模式的产生客观的应用评价本部分的主要工作放在2006年完成，2007年将根据后续的实践工作，对SOA应用模式进行验证与修订工作。1.2 本书的适用对象本书主要适用于：1) 致力于SOA应用模式的应用人员2) 致力于SOA应用模式研究的有关人员3) 致力于基于SOA架构应用的咨询人员4) 致力于基于电子政务应用的需求人员5) 致力于基于SOA架构应用的设计人员6) 致力于基于SOA架构应用的开发人员1.3 本书与其他研究内容的关系SOA的应用模式描述了在应用SOA的实践中，为了解决各种不同类型问题的独立于各种应用、领域、平台与标准的解决方案。包括：名称、问题、方案、适用范围、案例等内容。该子任务的研究处于整个研究项目的基础地位，具体表现在以下几个方面：1.3.1 与总体框架及标准规范的关系应用模式的研究为总体框架提供了独立于各种应用、领域、平台与标准的各种应用模式，也即为总体框架的研究提供了精确的需求。总体框架的研究应该根据应用模式总体研究确定的适合SOA解决的领域问题，提出切实满足SOA总体应用模式的应用框架，并以应用模式分类研究为基础，针对每一类应用模式提出与之对应的组合或定制的SOA应用框架。同时，应用模式并不仅限于需求的层面，应用模式是独立于各种应用、领域、平台与标准的总体框架，其有关体系结构与评价指标等方面的内容可以供总体框架研究参考、借鉴与深化。应用模式的研究也为标准规范的研究提供基础，在制定标准规范的时候应充分考虑SOA总体应用模式中对SOA所能解决问题的界定，使所制定的标准以切实指导基于SOA的应用开发为标尺。同时，制定标准的时候应充分考虑对不同的SOA分类应用模式的情况。1.3.2 与解决方案的关系应用模式的研究为解决方案提供了精确的需求。解决方案的研究应该根据应用模式总体研究确定的适合SOA解决的领域问题，提出切实满足SOA总体应用模式的解决方案，并以应用模式分类研究为基础，针对每一类应用模式提出与之对应的具体的解决方案。同时，应用模式并不仅限于需求的层面，应用模式是独立于各种应用、领域、平台与标准的解决方案，其有关体系结构与评价指标等方面的内容可以解决方案研究参考、借鉴与深化。1.4 本书的依据中办发200611号-20062020年国家信息化发展战略.doc中办发200217号关于我国电子政务建设指导意见.doc国信20062号-国家电子政务总体框架.doc2005年北京市电子政务总体技术框架（试行）.doc长风联盟SOA电子政务总体技术架构与解决方案(20061212)终稿.doc长风联盟SOA参考架构与技术-V4.doc长风联盟电子政务标准化指南（20060604）.doc第二章 SOA应用模式研究概述上章对SOA应用模式工作目标的分析同样适用于电子政务领域，经过多年的建设，电子政务资源建设取得了很大成果，各级政府部门相继建立了各类基础的数据库，也有部门初步构建了数据仓库。但与信息化进展情况相比较，存在明显的问题。一是资源开发建设明显滞后，突出表现在有价值的信息匮乏和信息结构不合理，缺乏指导性和权威性；二是资源开发建设标准不统一、不规范，已有资源共享性差；三是信息采集处理分析手段落后、力量薄弱，资源开发先天不足。解决上述问题，传统IT系统以技术为关注点，基本采取定制化解决方式，导致信息资源共享与交换严重受阻，协同效率低下，因此在传统资源共享的方案上，也通常沿袭IT系统的专有技术，采用专用的数据格式以及私有接口提供资源共享的方式，这样不同系统间资源的共享都有用特定的方式去完成，因此不同政务系统访问不同的资源都需要花费大量的人力物力解决一个私有化的接口转化为另一个私有化接口的过程。那么如何解决上述电子政务建设过程中所面临的主要问题呢？又如何在解决这些现有问题的同时还能为未来电子政务建设更长远的发展打下良好的基础呢？一个开放的、基于标准的面向服务应用架构提供了这样的基础，利用基于SOA架构的目录体系和交换体系它不但可以将现有各类资源整合到统一的资源服务平台中，还可以为电子政务的长久发展提供一个可持续发展的基础架构。资源服务层包括了现有政务系统中的不同类型数据源，除了传统的关系型数据外，还会有文件型数据，或者实时产生的数据流。众多分散的数据无论是数据源存储位置，还是数据访问方式都是复杂多样的。另外分散的数据形成了数据孤岛，导致上层应用产生矛盾的业务处理结果。资源服务层通过数据集成消除了数据孤岛，实现了分布数据源的统一管理，无论底层数据源有多复杂，通过将基于SOA的目录体系和数据交换体系使数据访问变为服务，所有上层应用都可以使用统一的方式进行数据访问。通过基于SOA的目录体系和交换体系形成的数据访问，解决了政务信息访问不标准、不规范的问题，而且通过服务的方式提高了信息的共享性。此外资源服务层还可以实现不同地域范围的政务信息的交换需要，通过数据交换服务，数据信息可以被及时地传送到其他系统或应用当中，这样就有效地提高了政务信息的使用范围。将SOA应用模式的分类研究体系研究做如下分类： 1） 利用SOA搭建业务应用运行软基础设施的应用模式a) 如何利用SOA建立组织机构业务活动库，从而构建政务的信息资源目录体系和服务体系，做为构件政务应用的软基础设施b) 如何利用SOA的观点建立业务主题库框架2） 虚拟的逻辑统一数据库是未来电子政务的应用模式之一3） 利用SOA建立业务间的资源共享的应用模式a) 如何基于信息资源目录体系、服务体系以及主题库框架，建立起不同机构、部门、人员间的资源共享应用以及服务4） 利用SOA建立业务间的协同应用模式a) 如何基于信息资源目录体系、服务体系以及主题库框架、资源共享建立业务间的协同应用模式5） 利用SOA建立基于针对受众的不同服务渠道方式的应用模式2.1 应用模式概述一般而言，一个模式有四个基本要素：1) 模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。应用模式允许我们在较高的抽象层次上对应用场景进行描述。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流特定应用场景及在某个应用场景下实际应用结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。2) 问题(problem)    描述了应该在何时使用模式。它解释了应用问题和问题存在的前因后果，它可能描述了特定的应用问题，如传统应用场景的效率、复杂性等。也可能描述了导致不方便应用的原因。有时候，问题部分会包括使用模式必须满足的一系列先决条件。3) 解决方案(solution)    描述了应用的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的应用，而是提供应用问题的抽象描述和怎样用一个具有一般意义的元素组合（业务流程或业务对象组合）来解决这个问题。4) 效果(consequences)    描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述应用决策时，并不总提到模式效果，但它们对于评价应用选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是应用模式设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。综上所述，应用模式就是在应用上提供怎样的解决方案，用以解决业务上面临的问题，从而可以达到怎样的应用效果。2.2 应用模式研究目标应用模式的研究目标就是通过对行业业务的应用状况进行深入研究，并结合SOA架构的优势特征，确定行业业务下一步应用建设的方向，并指出传统软件开发方式的解决方案以及带来的局限性，定位SOA在这些应用方向的应用前景。应用模式研究目标具体定义如下：1） 根据行业业务的现状，结合SOA架构特征，发现行业业务新的应用模式2） 确定行业业务总的应用模式集成，进行分类体系研究3） 针对新的应用模式，提出各类应用模式下的解决方案4） 针对所有的应用模式，确定各类应用模式的适用条件，并评价各类应用模式的效果2.3 应用模式的范围目前，我国的基于SOA的电子政务建设需求开始成上升趋势，而从世界范围来看，SOA的成功实施案例还不多，国外厂商已有的实施也多集中在金融、电信等行业，电子政务行业涉足很少，同时，项目实施及管理方法还远未成熟。我国电子政务信息化建设近年来从广度与深度上都呈现快速推进之势，政务资源整合趋势及未来迅速适应发展变化的特色需求都开始促使IT架构设计必须与业务的发展相互促进，因此，基于SOA进行项目规划及实施已具备了基础及国家的大力支持。基于前期的电子政务行业SOA应用需求分析及应用模式分析的成果，设计符合我国电子政务行业客户应用现状的总体应用框架及实施方法，真正指导电子政务各类应用的实施推广，应用推广从电子政务行业作为切入点，因此需有针对性地走访北京市、区县各政府机关的信息化主管领导，对各单位的电子政务应用现状及应用需求进行分析，如各类信息化应用分布及总体情况、信息化建设状况、政府信息化管理（组织建设）状况和政府信息化投入现状与分析等。对于电子政务行业应用来说，目前，各个国家的“电子政务（电子政府）计划”已进入信息资源整合阶段，基于SOA的整合正在成为热潮。BEA、IBM等厂商已开始有基于SOA的电子政务方案并在加拿大、美国、新加坡、意大利等国的电子政务的建设中得以应用、为公众提供了更便捷服务。在我国，中国政府信息化发展历程经历了基础设施建设阶段，目前正从应用系统建设阶段发展到资源整合阶段，打破行政信息壁垒、实现政府机构之间的信息互连互通是电子政务发展的必然趋势。我国目前也有朝阳区等政府综合信息化开始基于SOA进行构建，但与发达国家相比，我国电子政务差距还很大，区域发展非常不均衡，基于SOA的应用需求在北京等发展较快的地区已有广泛的需求基础，而且由于我国电子政务的特殊性，无法直接借鉴国外的模式。因此急需要一些标准的应用模式和实施指南作为应用和集成厂商在电子政务行业基于SOA提供解决方案的指导。从上述分析可以看到电子政务领域是探索SOA在政务领域的很适合的应用环境，因此，将电子政务领域做为应用模式的研究范围将更有利于探索SOA的使用，从而更有利于达到应用模式的研究目标。2.4 应用模式的研究方法应用模式研究采用分层的研究方式，依据IT系统架构的分层理论，IT架构分为七层架构，他们是界面层、应用层、应用支撑层、信息资源层、IT基础平台层、支撑体系层、法律法规层，电子政务领域应用的建设也都是遵循这七层架构，因此各类的应用基本上会映射在七层架构的其中几层上，SOA架构理念提出后，对于IT系统架构的影响也会落在这七层上，因此应用模式的研究基本上也从分层体系结构出发，分别在各层建立起电子政务的应用模式。2.5 应用模式研究的理论和依据应用模式的研究从业务上遵循了中办发200611号-20062020年国家信息化发展战略.doc，应用模式的研究必须顺应业务发展的需求，通过分析全球信息化发展的趋势、我国信息化发展的趋势、我国信息化发展的重点，建立起电子政务领域的各类应用模式。应用模式的研究通过在技术研究支持SOA架构的各类技术标准，包括WebService标准、XML标准、UDDI标准以及J2EE架构体系和.Net技术体系等，从而在解决方案级别对应用模式进行支撑。2.6 应用模式与其他热门研领域的关系2.6.1 应用模式与现代服务业的关系纵观人类历史社会发展，从最近的工业时代发展到现在的信息时代，社会的发展己经越来越依赖于信息以及基于信息提供的各类服务，也正是基于信息技术的发展，信息的不对称性正在逐步变小，行业内的竞争越来越激烈。行业从业者如何利用己有的信息或者如何将业务以服务的形式提供给目标群体，并且花费最小的代价，是增强自己竞争力也是更好服务客户并创造价值需要解决的问题，也是IT界而临的一个挑战性课题。SOA 正是应对经济全球化、业务网络化和企业“随需应变”的社会经济变革而产生的软件“解决之道”。作为一个国际性的技术趋势，SOA 被称为软件产业的伟大革命，也是我国软件产业和信息化应用领域的巨大机遇和转折焦点。SOA理念的提出解决了如何以标准、开放的形式对外提供服务，而如何将这些服务对外提供运营仍有大量的工作要做，比如总的方面服务的运营体系建立；以及更细粒度上的服务的接入、服务的存储、服务的安全认证管理、服务的计费管理、服务的质量管理、服务的监控；在与服务相关的受众方面则要有服务提供者、服务消费者、中介代理的管理，所有这些都不是SOA架构本身所能够提供的，也正是基于此我们提出中国在线服务平台的概念，平台基于SOA以及服务的运营体系建立起完整的服务运营平台，解决不同行业内服务提供者和消费者的服务供需矛盾问题。中国在线服务平台的推进还将促进软件生产和应用模式的变革，使软件企业更好地面向行业应用市场、提高生产效率和市场反应能力，从而实现相关行业的整体技术应用水平跨域式发展，使得中国在线服务平台 在中国可以形成规模化服务格局，并促进中国软件产业链从“项目导向”向“服务导向”转型。2.6.2 应用模式与服务库的关系服务库是支持基于SOA架构的所有应用的技术架构中的一部分，SOA架构中很重要的元素就是服务，任何应用模式中的应用在SOA架构下都包含大量的服务，而服务的管理则是很重要的环节，服务的生命周期管理、安全管理、权限管理则都是必不可少的功能，因此从技术角度和应用角度讲，服务库都是应用模式必须的支撑之一。第三章 SOA总体应用模式研究SOA作为一种新出现的软件开发范型，相对于其它软件开发范型，有自己特有的应用模式，本部分的研究应基于SOA的具有代表性的实际软件项目为基础，并参考相关的研究文献，总结行业业务应用状况、需求与趋势；分析传统软件开发范型所面临的问题以及适用SOA范型解决领域与问题。具体的研究内容如下：¨ 行业业务应用状况、需求、趋势研究。结合国外先进的电子政务应用实践，总结我国电子政务领域的行业现状与特点、典型技术产品、面临的问题、与国外的差距、以及发展趋势。Ø 以具体的案例，描述电子政务领域中缺乏业务流程梳理，尤其是委办局间或者委办局内部各处室间的业务交互和基础业务数据共享都没有相应的软基础设施支撑Ø 基于对电子政务领域中某个具体几个委办局或者委办局内部，分析由于缺乏业务主题库类应用而造成的处理业务时的问题Ø 分析电子政务领域中的资源共享中现有模式、状况，并分析未来的资源共享模式Ø 分析电子政务领域中业务协同的现有模式状况，并分析未来业务协同的模式Ø 分析电子政务领域中对受众的服务模式、状况，并分析未来理想的服务模式¨ 传统软件开发范型所面临的问题。在参考相关文献的基础上，研究传统的软件开发范型对于解决当前行业业务需求所面临的问题与不足，为SOA范型的推广找到现实依据。Ø 分别针对行业业务应用状况、需求、趋势中五类的分析，指出原有的软件开发范型在解决上述几类问题时的局限性¨ 适合SOA范型解决的领域与问题。在参考相关文献的基础上，结合电子政务行业的实际情况，总结适合SOA解决的领域特征与问题类型。Ø 针对传统的软件开发范型，指出SOA范型如何适应决电子政务领域几个方面的理想的业务模式。3.1 软基础设施政务领域的应用通常是基于单个或多个业务而定，考虑的基本上是单个系统或者多个系统之间的关系，一旦业务增加或者业务更新，通常意味着对服务业务的IT环境造成很大的影响，并且这种影响通常难以准确判断其影响力，而以服务的思想分析业务，并且基于服务架构的思想建立整个业务的总体规划图，并且以可管理的方式维护业务、业务对象、业务流程，使业务与业务之间的关系不只是体现在应用系统中，而是首先体现在政务领域的软基础设施中，那么IT系统的变化则不是无规律和无节制的，而首先由软基础设施变化，从而直接指导IT系统变化，使整个IT系统升级变成一个可管理的过程，这就是SOA架构带给政务领域的最大突破。3.1.1 名称简称：软基础设施解释：随着信息化应用的爆炸式增长，人们越来越觉得信息化的应用越来越难以管理，进而人们开始思考，在硬基础设施管理己经比较规范的情况之下，我们是否缺乏管理信息化应用的软基础设施。3.1.2 问题信息化的需求基本上是根据业务信息化的紧迫性或重要性而成为某个信息化阶段关注的重点，从电子政务十几年的建设来看，信息化过程可如下图表示：从上图可以看出，信息化的过程基本上是随着业务需求的深度和广度不断变化的过程，而信息化的过程的管理并没有得到系统级别的支撑，从而导致了如下一系列的问题：3.1.2.1 信息孤岛现象普遍存在，难于实现信息共享传统的电子政务系统主要针对各部门自身的业务需求来实现，造成应用系统独立建设、缺乏统一的标准，各个部门自成体系的应用现状。信息资源分割严重，信息孤岛大量存在，资源获取与可用性差，信息交换共享十分困难。l 数据描述局部有序，整体规范欠缺，严重影响资源使用与共享政务部门在各自的信息系统建设中，多从自身业务出发来构建信息系统，业务数据固化于软件实现中，且信息资源单独管理，造成了业务与数据的相对自我封闭。对需要跨部门共享的业务信息，因其描述格式、描述方式均不统一，标准化程度低，导致大量事实性信息孤岛出现，且不同孤岛间的数据获得与使用较为困难。如何建立起电子政务应用的标准化数据体系，保证数据表达、处理、展现的规范化已经成为电子政务建设亟待解决的重要问题。l 资源共享模式单一、可扩展性不强，信息组织与发现步履艰难基于传统技术构建形成的电子政务应用，因技术手段制约，共享实现常以点对点的信息共享和交换方式为主，这种模式存在方法欠灵活、系统瓶颈明显、可扩展性弱，并且部署与实施复杂程度高，不利于各取所需要求下的业务开展需要。如何构建灵活、易扩展的资源共享模式，以保证合法用户能够及时发现所需的共享信息资源，需要有效的信息组织方式作为支撑。但是客观上由于这些信息来源于不同地域、不同部门，必然导致数据处理的不一致性问题，所以，有关信息的组织与发现成为资源利用与共享中的又一个难点。l 应用系统多自成体系，信息资源获得与使用机制僵硬现有应用系统中，用户通过凝集在业务软件实现中的信息资源视图方式来实现对业务功能的满足，不同的应用系统受政务部门职能分割影响，重复管理、重复维护，不仅使工作量的大大增加，而且极易产生数据的不一致现象；其次，当因部门重组等原因导致网络状况变化、硬件设备或系统升级的情况时，极易引发信息资源的重新组织乃至废弃，不可避免地陷入重复建设的泥潭。现有信息资源的重复设置、强行割裂、应用系统扩展能力不强等弊端已经成为影响信息资源获得与使用的关键问题之一。3.1.2.2 业务由于系统的隔离难于实现协同近年来各地、各部门相继独立建设了一批电子政务应用系统，在大力提升政务业务能力的同时，也造成政务部门之间的业务应用无法很好互联互通，在很大程度上制约着电子政务应用水平的进一步提升。信息系统的技术实现滞后于业务变革，无形中制约和阻碍了政务业务协同与发展。l 软件与业务存在“鸿沟”，导致应用系统协同支持乏力在以往建设的应用系统中，基本上是采取定制化解决方式，按照给定的业务需求进行建设，系统一旦建成之后则通常保持一个相对固定的体系结构形态。这种固定结构形态下的应用系统将资源与业务紧密绑定，呈现固化与静止状态，一旦业务需求发生变化，初始的相对静止的体系结构便难以再与之相匹配，系统往往需要进行大的改造或重新开发。要实现业务协同，往往需要采用复杂的软件技术，并需要扩充、改造已有应用系统才能完成，工程量较大，无法紧跟业务变革步伐！l 业务对技术依赖性过高，业务受技术影响程度过重在电子政务建设中，多数业务功能的实现要通过复杂的技术手段来完成，技术选型一旦确定，技术对业务的依赖关系也成为现实。导致业务功能的实现受到技术因素的影响越来越大，用户缺少根据业务需要灵活选择技术的空间与余地，信息系统不但不能更好支撑业务发展，反而成为业务变革与深化的束缚，业务对技术的依赖已经成为影响用户业务变革和创新的制约要素，这一现实若不改观，则很难根本性改善业务深化条件与业务变革环境。l 部门间协同基础薄弱，整合型、协同型业务应用面临窘境各政务部门现有的信息系统通常是基于不同的软硬件平台开发的，这样的结果导致建成系统难以互联互通、实现互操作。在实际应用中，许多环节需要通过人工干预甚至手工转换来完成。面对以“一站式”服务为代表的协同业务需求，部门间的薄弱协作基础成为要害制约因素，尽管通过EDI或EAI可以进行集成，但因为受到统一标准缺失限制，所得效果与预期理想尚有差距。因此，跨地区、跨部门的业务协同急需新的技术手段来实现。3.1.2.3 建设投资居高不下，用户承担高危风险传统情况下，协同系统的各组成部分由若干软件供应商来实施，由于技术手段的限制，导致重复建设严重，为了维护系统，保障正常运行，政府对系统的投资也在持续增长，用户承担着高危风险，主要表现为：l 现实需求与未来发展脱节，建设成果浪费现象时有发生传统技术中，由于实施过程中用户的需求受供应商的产品技术限制非常大，无法完全随用户意愿而进行，实施的结果从某种意义上讲往往是用户的需求和供应商产品固定功能妥协的产物。这样，应用往往由于技术的局限而不能真正有效地实现用户的需求，对未来发展的适应能力较脆弱，建设成果的搁置、废弃在所难免。l 应用功能重复开发，运维成本难于控制政务部门职能的不断变革，对应用系统提出了较强的变动需求。而传统系统基本采用面向过程、面向对象及面向组件的思路进行开发，耦合度均较为紧密，灵活性较差，应用功能复用程度低下。为了满足新需求，往往是在原来系统上不断地打补丁，或不得不根据业务重新开发新系统，致使系统维护与更新难度越来越大，系统复杂性与日俱增，运维成本居高不下。l 建设开发周期长成本高，投资潜在风险巨大传统的系统开发基本是在数据库和软件语言开发平台（如VB、VC、Java等）基础之上研发的。整个软件开发过程周期长、成本高，而且这些软件均存在两个无法解决的矛盾：一是用户的个性化需求与系统的通用性之间的矛盾，二是用户实施系统后需求的快速变化性与系统的相对稳定性之间的矛盾。这两个矛盾使得产品软件提供商的开发成本与实施成本无法下降，同时，用户高投入下的信息成果与IT设施也伴随着巨大风险，能否支撑未来应用，能否适应未来业务变革发展需要，成为客户的沉重包袱与重要负担。上述电子政务建设中存在的问题，是我国电子政务建设发展过程中必然经历的阶段。长风联盟认为：目前在电子政务建设中，网络与软硬件基础设施、部门级应用和局部信息资源建设已经或正在完成，急需构建新的高层次骨干枢纽框架，突破现有技术限制，保护已有应用成果，实现现有资源的有效整合与充分利用，满足与支持业务发展需要。SOA的成熟与使用，不仅为构建政务高层次骨干枢纽框架提供了条件，更为突破信息孤岛、整合信息资源、协同政务应用、缩短开发周期、降低开发成本的电子政务应用带来了新的曙光。3.1.3 解决方案基于服务思想建立软基础设施的基本思想是以服务的观点看待业务中的业务对象、业务与业务的交互，对政务业务中各类元素进行标准化编目，并对产生的元数据进行集中化的管理和维护，从而更好的提供政务业务资源的查询、检索和定位服务，依据这些政务业务资源的基础描述，开展电子政务的建设工作，每一步的建设，相当于基于这些业务资源的一部分或全部构建起若干标准的服务，从而使后续的工作可以在以前建设的基础上推进。3.1.3.1 梳理业务形成业务及信息地图业务资源梳理的目的在于利于部门间的资源共享和业务协同，分析业务与业务之间的关联，预测业务的变化，而不仅仅是从单个业务分析，更具备全局性，因此将业务所从属的组织结构、部门职责做为梳理的起点，各部门的业务活动做为业务资源梳理的脉络，业务对象和业务流程做为业务资源的关键点，业务活动之间的关系做为寻找和判断业务资源中信息如何共享和业务活动如何协同的依据。依据上述业务资源的分类和梳理业务资源的思路，具体的业务资源梳理的内容主要包括如下内容：1）组织结构2）工作职责3）业务活动4）业务流程5）业务与业务的交互关系6）业务与业务之间的制约关系7）基础信息8）结构化业务数据9）非结构化业务数据10）应用资源类3.1.3.2 业务活动梳理和编目及查询通过管理组织的组织结构和工作职责，从而细分和梳理组织的所有业务活动，而所有这些业务活动就是未来信息化工作的来源，按照标准对这些业务活动进行梳理和编码，从而使整个组织的所有业务得到了统一的管理，在信息化的过程中，业务活动的状态需要得到标注，从而使各类用户可以通过业务梳理活动以及标注活动了解当前信息化的现状，未信息化的业务以及哪些交互业务未得到信息化的支撑。3.1.3.2.1 业务活动之间的关系梳理和编目及查询业务活动之间关系包括业务与业务之间的流程关系和前后制约关系，信息化建设中经常被忽略的就是这部分工作，信息的孤岛和业务的孤岛就是因为忽略业务活动之间的关系造成的。梳理完业务活动之间各类的关系，并将这些关系进行编目和查询，更深层次保障了信息化的全面性，而不是片面性。3.1.3.2.2 基础信息维护与编