软件系统总体规划

软件系统总体规划1.1.1建设目标业务目标严格按照统一规划和部署，在规范财政业务流程与管理规则的基础上，结合《财政部关于地方财政信息化建设的指导意见》，以落实全国财政“五统一”核心要素为重心，以财政业务应用为驱动，切实发挥平台的基础支撑作用，保证平台应用的实效性和可持续性。充分考虑我区财政业务应用现状和管理需求，保证现有预算一体化系统在升级过程中能够平稳过渡，继承现行预算一体化系统所有功能，以业务流程为主线，基于平台2.0对现有业务流程进行充分优化和整合，最终建成横向纵向贯通的预算管理一体化系统。1、财政局内管理一体化、业务一体化1）财政核心业务全覆盖，业务流程全部网络在线完成，管理更加规范。2）“预算编制有目标、预算执行有监控、项目完成有评价、评价结果有反馈、反馈结果有运用的”的全过程预算绩效管理。3）现代财政管理信息化方式。即实现“用数据说话、用数据决策、用数据管理、用数据创新”。“数字说话”、数据应用是财政部门“天赋秉性”，数据应用的水平决定了财政部门的管理方式和水平，大数据应用是信息化时代人必然选择。2、财政与预算单位达到纵向业务全贯通1）规范预算单位项目的申报内容和申报程序，加强项目支出预算的管理，提高项目资金的使用效益。实现预算单位项目立项日常化、规范化管理。2）实现预算单位从资金申请到资金支付的数据自动生成会计凭证，保证财务记账的准确性。3）预算单位财务决算一体化管理，实现财务与决算自动过账，自动生成决算、电子对账。达到财务账与决算表数据的一致性。4）适应未来拓展，提供数据依据综合业务系统要从结构上适应未来财政改革，系统根据管理的需要能较快速做出调整，适应财政业务和管理的需要。同时，为财政决策提供完整准确、及时合理的数据依据，充分发挥数据资源的作用。技术目标金财工程应用支撑平台2.0的建设将加强对公共基础数据规范的管理，进一步提升平台的安全性、可扩展性、易用性及运维便捷性，实现平台更广泛的应用和发展，支撑财政业务管理进一步科学化、规范化和信息化。1、依据财政部金财工程的技术路线要求，特别是金财工程应用支撑平台也是基于J2EE的构架，因此，本系统采用基于J2EE的三层架构。本项目覆盖面广，业务相对复杂，因此，本次项目建设，需要满足以下要求：系统运行的可靠性；系统运行的高效性；系统维护的方便；适应业务发展需要的可扩展性。因此本系统建设基于成熟的J2EE技术架构，采用Http协议进行数据传输，成熟可靠。2、技术实现一体化：数据集中在财政存储，预算单位数据零存储。预算核心业务统一网络在线完成。统一平台、统一数据标准。3、 业务管理一体化：预算管理业务统一规划，对系统进行一体化整合，各模块完美衔接，简化数据流程。4、 横向纵向业务一体化：充分发挥应用支撑平台的作用，满足我区与市财政之间横向业务与纵向业务的贯通。5、 实施服务一体化：系统统一实施、统一服务标准、服务统一管理、系统统一升级。1.1.2系统建设原则针对目前财政信息系统建设现状，以财政业务实际需要进行统一规划，按照“统一组织领导，统一规划实施，统一网络平台，统一标准规范，统一安全管理”的“五统一”原则，建立财政局预算综合业务系统。1、统筹规划，分步实施此次信息化建设涉及的业务面广、系统数量多，需要统筹规划，提出切实可行的实施步骤和时间节点，有序推进财政信息化建设工作的协调发展。2、标准先行，统一建设标准化是促进业务管理、系统建设规范统一的基础，是实现系统衔接、数据共享和业务协作的重要保障。3、突出重点，注重实效紧密围绕财政业务需求，从解决当前的重要问题入手，确定有效目标与实施路径，既要紧跟信息化发展趋势，又要以实际需求为导向，要把信息化融入业务流程再造和管理创新的全过程，充分挖掘现有资源潜力，坚持实事求是，讲究实效。1.1.3系统总体架构设计总体框架图根据新时期财政信息化建设总体思路，立足本市实际需求，以当前预算改革新要求，对财政生产业务流程和办公流程深度再造，借助财政部推广应用支撑平台2.0、地方预算综合管理系统的契机，构建财政业务横纵贯通、内控机制科学严谨、外部服务优质便捷、财政运行安全高效、财政信息高度共享的平台及一体化系统，为现代财政改革，提供强大信息系统支撑。财政局综合业务系统建设，将达成财政部对地方财政信息化“五统一”要求，实现全面贯通预算编制、预算执行、监督检查的全过程闭环，通过财政大数据支撑领导决策，可实现将动态监控范围拓展到所有财政资金和全部预算单位，并建立健全财政网络安全和运维保障体系。系统架构设计财政核心业务系统基于平台2.0进行构建，系统从整体上分为数据源层、应用支撑层、应用功能层、门户展现层四个层次，以及财政业务管理制度与业务规范体系、技术规范与运维管理体系两大标准规范体系。平台的总体体系架构如下所示：在数据源层，通过应用支撑平台接入人员信息库、项目信息库、预算编制数据库、预算执行数据库、政府采购数据库、工资发放数据库、会计核算数据库、决算数据库，为财政核心业务管理工作提供数据存储和应用环境。在应用支撑层，平台以服务总线为基础，面向业务应用，提供数据字典、总账管理、标准存储、数据交换、业务规则、交易凭证、工作流、报表、文件服务、安全等服务，为上层应用功能层提供有效的应用支撑。在应用功能层，平台面向财政核心业务应用，提供基础库管理、项目库管理、预算编制管理、指标管理、绩效目标管理等预算综合管理功能，国库支付管理、工资统发管理、动态监控、政府采购管理、账务管理等预算执行管理功能，以及预算执行分析、决策支持等数据挖掘和分析功能。在门户展现层，平台利用统一门户系统对外展示预算综合管理信息、预算执行管理信息、业务数据分析利用信息、协同办公信息。技术体系架构设计本项目所建系统采用J2EE架构，系统设计采用了目前业内主流的新技术，从而确保系统技术架构的先进性。系统还提供标准的接口服务，可实现与其他系统的有效集成应用，从而满足项目建设要求。J2EE体系基于组件技术的企业应用服务可以灵活地配置和组装，因而，系统可获得较好的稳定性、高可靠性、可扩展性，不受操作系统的束缚，易于移植和重用。系统采用组件化编程策略，提取和构建统一的、科学合理的公用构件。公共构件按通用程度分为与应用无关的基础性的公共构件、一般管理信息系统通用构件、财政领域相关的通用构件三种。系统的公共构件可实现接口和技术实现相分离，系统接口使用业界具有规范性和普适性的标准，系统技术实现将完全遵循接口规范，并提供多种可用的技术实现方式供选择。系统基于应用支撑平台开发，运用JavaEE框架和SSH技术、SOA/MVC的设计模式、Ajax和RSS等大量先进的技术，来增强系统的柔性和开放性，为业务应用提供一个灵活扩展、随需定制、易于整合的技术平台。系统采用业界成熟的分层结构，各层次之间功能独立且耦合度低，易于高效实现和扩展。系统各层相互独立，并通过组件化封装、面向接口开发，可有效分离不同关注点。同时，系统采用MVC框架进行封装，提高了系统的易用性、用户体验。系统的服务总线层完全遵循SOA设计理念，可降低系统的耦合性，提高了业务对象访问安全性。此外，系统通过统一的AOP、事件、消息、性能、任务等处理组件，可全面提升系统整体性能、稳定性、可扩展性。（1）数据持久层系统支持多种主流关系型数据库，可生成标准的SQL模型脚本，数据库构建脚本可自动生成。由于将业务逻辑（处理业务的逻辑程序）及业务对象（界面）完全封装在业务框架层，因而，数据库模型不依赖于具体的业务逻辑。（2）基础框架系统基于JavaEE技术，为平台框架、业务系统框架的各模块实现提供了基础技术支持。系统提供了多种可直接调用、易于使用、高效执行的类。基础框架包括JDK、WEB容器、IOC/AOP平台等三个核心部分：系统主要面向JDK6来开发，也支持与JDK6同级的其他商业级JAVA虚拟机（如：Oracle的虚拟机，以支持Weblogic；IBM的虚拟机，以支持Websphere）。系统支持Tomcat、Weblogic、Websphere等商业或开源Web容器。在IOC/AOP平台方面，系统采用了成熟度和发展性都非常优秀的Spring。（3） 平台框架1） 元数据层：提供对框架中使用到的抽象层次上的原始信息进行分类定义和统一管理，为其他层提供统一的元数据信息访问接口。2） 数据处理层：提供对业务对象与数据库之间的交互处理功能，隔离业务对象对数据访问层接口的依赖，实现对多种类型数据库的支持特性。3） 资源管理层：负责系统中资源的访问、资源的发布、资源的修改等功能，Portal框架层通过资源管理层提供的访问接口来获取资源信息，业务框架代理层进行业务处理的复杂性，实现了对不同“横切关注点”的分离与处理。（4） 业务系统框架业务系统框架采用插件化思路，开发和管理相关业务模块插件，并遵循MVC设计模式，分为业务逻辑层、流转控制层、UI交互层，在保证业务逻辑核心实现的可控性和安全性前提下，提高重用性、可维护性、可置换性。UI交互层主要完成业务系统与人机交互控制逻辑，通过独立的UI交互层，将业务模块展现给系统用户。用户通过系统终端设备获取、输入各种信息与系统进行信息上的互动。系统部署架构设计本项目将在信息中心内网部署本项目所建系统，为业务处室人员（经办人、处室领导）、预算单位（经办人）、银行（业务人员、业务领导）、维护管理员用户提供系统的统一管理、分布式应用服务，并通过业务客户端接入业务应用服务和业务信息访问服务。利用现有网络环境，统一部署数据库服务器、应用服务器、数据交换服务器、SAN存储中心磁盘阵列、光纤通道SAN交换机、虚拟磁带库（磁盘阵列）、备份服务器，并在各服务器上部署操作系统、数据库系统、应用中间件软件、相关应用支撑软件。各级、各类用户可通过业务客户端访问部署在应用服务器上的一体化系统来完成基础信息库、项目库管理、预算编制、预算调整、指标管理、预算绩效管理、国库集中支付、实拨管理等业务工作。统一门户架构设计本项目通过基于金财工程应用支撑平台统一门户实现财政核心业务信息门户，将各类应用和信息进行有机整合，方便用户使用系统。本项目采用统一身份认证、单点登录等机制来保证应用资源的访问安全，并对应用门户架构进行整体规划设计，构建财政核心业务信息门户。面向服务架构作为新一代软件架构，正以其协同高效、复用扩展、异步及松耦合等优点逐步取代传统的软件架构，成为分布式计算应用发展的趋势。将面向服务架构的思想引入应用门户架构的设计，通过一个清晰的基础框架来帮助政府用户快速构建、部署和整合一个完整的多层结构的门户系统，同时也作为新的门户架构的统一完善模式和信息化解决方案。本项目采用基于服务的、松耦合门户体系结构来构建面向服务的门户平台，该结构结合具有内部、外部两种交互方式，可以为用户提供个性化服务和统一访问入口。面向服务门户平台的体系结构采用基于Web服务的多层体系结构，由用户层访问接入层、门户服务层、业务系统层、资源层构成。该结构将主要业务服务逻辑与资源数据以业务系统和门户组件的方式进行独立部署和交互。用户的各种应用请求通过门户发送到门户服务层，由应用服务接口完成一般服务处理功能。若客户端请求需后台支撑服务或访问其他资源，则门户服务层将调用业务系统层和资源层的其他服务接口。应用门户的技术体系结构如下所示：1）用户层：按照不用类型的用户可以使用的不同门户入口，来保证访问安全性。用户终端支持多种访问载体。2）访问接入层：提供访问请求的安全接入，使用户无法直接访问后台的服务和资源。单点登录机制将保证用户在登录门户平台后可访问已经登录的其他业务系统。3）门户服务层：作为门户系统的核心层，主要为门户提供各种服务（如：内容管理、安全、扩展开发、多层整合等），并采用Portalet、EJB、Web服务方式来提供应用集成、服务资源接入的接口。4）应用系统层：主要提供一些应用系统及模块。通过多层次整合、链接引用、定制开发等方式来表现，可基于Web服务和门户服务的接口进行集成部署。5）资源层：主要包括目录信息、资源信息、数据缓存、数据库、数据仓库，是门户所需管理和整合的数据资源。其中，门户服务层和应用系统层的各类服务组件可由业务服务逻辑模型和门户组件整合设计构建而成，以保证系统的灵活性和可复用性。数据库架构设计财政局应用支撑平台升级及综合业务系统以应用支撑平台2.0为支撑，贯穿“预算-预算变动-预算执行-核算-决算”的财政主体业务管理闭环。具体数据模型图如下：工作流引擎设计本项目所建基于平台2.0的财政核心业务系统中的基础信息库、项目库管理预算编制、预算调整、指标管理、预算绩效管理等系统功能均基于工作流引擎。该工作流引擎提供了灵活的流程自定义功能，通过规则定义引擎，可灵活方便地对现有流程进行扩展，满足用户不断变化的业务需求。工作流引擎架构设计的关键在于对工作流管理模型的设计。工作流管理模型涉及业务流程的定义、管理、执行，包括工作流引擎、图表化流程定义工具、流程运行跟踪机制等要素。通过一个或多个工作流引擎来解释工作流的过程定义，并为工作流的参与者提供交互操作，还可根据需要调用其他工具或应用进行应用整合。利用工作流引擎、图表化流程定义工具、流程运行跟踪机制可以构造工作流管理的集成架构模型，通过工作流应用扩展接口与数据交换接口，可以对业务应用系统与工作流管理平台进行流程的定义、管理、执行、应用、整合等方面的应用集成，如下所示：遵循SOA设计理念，从共享访问、共享数据、共享应用、共享业务流程、共享门户等服务着手，按照不同服务粒度以及上述工作流管理、集成架构、应用集成等模型，可以设计出工作流管理的分层架构，包括：展示层、服务层、基础引擎层，1）展示层：面向访问者（角色）进行逻辑展示，基于Portalet规范实现，在运行时需门户组件的支持。展示层服务主要包括：流程跟踪查询、流程灵活配置查询、流程统计查询、流程催办、流程定义、流程设置、业务表单等。2）服务层：面向业务管理，可以组合、封装多个来自接口总线的业务系统的服务，并提供复杂的业务逻辑，是前端展示与后台逻辑引擎的接口层。服务层主要提供业务流程执行定制存取、业务表单存取、业务流程跟踪和统计查询所需的数据提取、流程执行所需业务交互数据提取等服务。3）基础引擎层：主要提供业务流程管理所需的基础服务工作，包括：业务流程流转所需的流程引擎、规则引擎，业务流程的用户权限服务，流程定义产生的业务模型和流程模型的存储，业务流程执行过程中的日志记录等。1.1.4基于平台2.0生长式开发设计财政部印发的《应用支撑平台2.0升级实施方案》要求：地方财政部门要坚持基于平台构建一体化系统。基于平台2.0生长模式开发核心业务系统，将实现财政核心业务链条一体化运行，无缝对接。生长式开发的关键设计如下：系统技术框架融合业务系统基于应用支撑平台提供的开发技术框架进行构建和开发，通过平台统一创建和管理平台域和各个业务域，使用阿里巴巴的DUBBO分布式服务架构体系，实现统一的分布式事务、分布式存储和分布式缓存管理等功能。技术结构：平台作为财政信息化的底层中间件，其技术架构提供了各种开发级公共应用框架，为业务系统提供较为通用的技术组件，开发人员可以基于该框架开发符合系统要求的功能。公共框架：公共框架定义了平台运行环境，技术环境，第三方组件。公共框架中包含了默认开发工程、建库脚本、框架源码、默认系统功能配置等。服务框架：业务系统基于平台构建，通过Dubbo(开源的分布式服务框架)与Spring容器的融合，将服务总线封装到业务域运行环境中。使平台服务可以通过服务总线直接为业务域中的业务系统提供服务，对业务系统完全透明事务框架：平台提供分布式事务框架，解决应用系统同时操作多个数据库时的事务一致性问题。业务系统开发时无需考虑事务实现问题，只要按照框架要求启用事务即可。(5)缓存框架：平台缓存框架提供全局缓存、域缓存、事务缓存三层缓存机制。为了控制缓存内容的有效性，确保缓存内容不会占用过多系统资源，在全局缓存和域缓存中都要使用淘汰算法，清空使用频度低的内容。缓存框架提供配额管理功能，对业务系统及其他系统使用缓存的大小进行控制，避免一个业务系统使用不当影响其他业务系统正常运行。版本框架：版本管理框架为业务系统提供版本管理，依赖检测，自动升级等功能。包括：版本上传、版本下载、升级脚本管理、系统备份、升级界面、升级日志、异常报告等功能。业务系统升级时，除了提供jar包，脚本包之外，还需要编写系统升级配置文件，平台框架将按配置文件的要求自动升级相关功能模块。安全框架：业务系统将遵从平台安全框架，按《信息系统安全等级保护基本要求》进行系统安全管理和安全控制，主要功能包括：访问控制、资源控制、数据加密、数据完整性、通讯保密性功能。（8）监管框架：业务系统运行监管将通过平台监管框架实现，包括系统运行环境监管、系统访问监管、关键数据监管。监管框架将依据系统设置和监管规则，从系统运行环境、关键操作节点、数据库中抽取数据，提供给日志管理使用。系统登录与安全管理业务系统的用户管理、用户授权管理、CA身份认证和单点登录等功能采用平台框架提供的权限组件和CA安全管理功能，照信息系统安全分级保护要求,实现三员分权即系统管理员、安全保密管理员和安全审计员的分别管理。（1） 系统跳转：业务系统通过平台主控域提供的统一入口访问系统页面，用户登录时，平台主控域会给每个用户授予一个唯一标识TOKENID，并从用户信息获取相关权限及菜单信息。业务系统在部署时有一个上下文（context_root），与其他业务系统不能重复，由平台统一管理。（2） 单点登录：业务系统调用平台的权限组件进行用户管理、角色管理、菜单管理等，按照平台WebService接口规范实现与门户系统衔接，实现统一用户管理和单点登录。平台存有业务系统所有用户有关信息，业务系统也存有自己的用户信息，以便数据权限控制。这样用户信息就存在不同库中。用户数据原则上只能通过一个界面进行维护（平台界面），然后同步到其他系统。（3） 系统权限管理：平台管理用户权限信息（单位，用户，角色，菜单信息，并配置关联信息。如用户和角色关联，角色和菜单关联，单位和用户关联。）平台权限管理只到菜单一级，数据权限管理由业务系统负责。系统把菜单登记到平台，由平台决定哪个菜单可以访问。（4） 系统服务监控：平台会对业务系统的HTTP请求和DUBBO调用进行监控，监控是由平台filter提供的，因此要保证filter在最外层。（5） 系统日志管理：平台会在业务系统生成日志文件。基于平台的服务调用业务系统对平台中服务的注册和调用以及对其他系统中服务调用是通过服务总线实现的。服务总线组件提供包括服务注册管理、服务发布管理、服务授权管理、服务监控管理等功能。服务提供方（平台，各表层业务系统，第三方系统）需要按照平台规范的要求设计开发服务(如查询数据服务程序)，包括接口服务方式、身份认证、数据组织形式等等。开发完成的接口服务需要到平台注册，通过平台验证后发布，供其它业务系统查询和调用。服务使用方经过平台的授权并按照平台规范的要求调用服务提供方在平台中注册的服务，获取到相应的数据。业务系统通过报文形式进行服务查询和服务调用，所有报文使用XML格式进行描述，报文结构包括报文头、报文体和认证节点。1、调用服务过程系统注册服务：提供服务的系统需在平台先注册以取得平台唯一的标识符。任何服务都有服务名，服务名必须唯一。任何服务都要注册支持邮件地址用来发送错误信息。平台管理各业务系统提供的数据服务，包括服务名称、服务地址、服务参数、数据返回值形式及意义、服务提供方(业务系统)、服务的性质和作用等内容。系统发布服务：业务系统在平台注册，平台为系统分配appid，该id作为业务系统在平台系统中的唯一标识，用于识别系统身份、管理业务系统功能的唯一识别码。系统在平台服务管理功能中注册服务内容，填写服务描述信息，并上传服务相关技术文档。平台根据服务描述文件的内容自动分析出服务的具体内容，包括方法名、参数个数、参数类型等。对服务的应用范围进行授权，并在控制界面启用服务，其他系统即可相应调用业务系统发布的服务。修改系统服务：通过平台服务总线的统一界面来修改服务参数。授权系统服务：平台统一对服务的调用权限进行管理。对于已经在平台注册的业务系统，通过服务总线设置权限功能，在授权功能中勾选业务系统后即时生效，将服务授权给业务系统调用。系统调用服务：业务系统在平台注册，获得平台分配的appid，并经过平台服务总线授权所需的服务，即可调用平台服务、其他一体化业务系统服务及第三系统的服务。2、调用服务要求基于平台的任何业务服务或第三方服务必须是同步服务。系统如果不能在指定时间内完成服务，需要返回服务超时错误，服务如不能正常结束，需给出明确错误信息以便存入日志。任何服务必须检查输入参数，如不满足条件（类型不匹配或值域不不匹配），需给出明确错误信息以便客户端修正。3、调用服务权限平台通过服务总线统一管理服务权限，并提供服务权限设置界面。4、调用服务日志业务系统调用服务的过程都会在平台服务总线记录生产日志，平台提供服务请求日志和服务操作日志。（1）服务请求日志日志涵盖每一次服务调用，包括以下内容：＞客户端信息＞调用参数＞调用时间，完成时间＞如有错误，必须提供完整错误信息＞错误信息由服务端提供，其他信息由平台提供（2）服务操作日志服务操作日志记录服务的注册，修改情况。基础数据管理业务系统使用平台基础数据规范组件、数据字典组件、标准存储组件和数据交换组件提供的功能和接口，遵守平台提供的基础数据标准规范，实现基础数据的统一下发、存储、管理和使用，基础数据统一存储于平台中，系统使用平台的基础数据。平台基础数据分成3类，财政基础数据，本级扩展和系统预设。财政基础数据由中央下发，下级不能更改，只有部分允许细化。本级扩展和系统预设允许更改，但必须在平台页面维护。平台提供基础数据接口供业务系统使用，但业务系统不能直接通过接口调用更改基础数据。平台只提供接口方式和消息方式，业务系统可以在此基础上进行封装。1、基础数据维护生长式业务系统向支撑平台传送当前系统基础数据，并同步平台对基础数据的修改，系统中所使用的基础数据均与支撑平台中所维护的基础数据一致。平台不提供自定义基础数据通过业务系统灌入接口。可通过平台界面在平台里维护业务系统使用的基础数据。业务要素修改之后会自动从平台同步到业务系统。也可通过平台域管理工具手工同步到业务系统。＞如果平台和业务系统在同一个数据库实例中，业务系统通过数据库同义词读取平台基础数据。＞如果平台和业务系统不在同一个数据库实例中。平台负责同步基础数据到业务系统数据库。对于基础数据不一致情况时，业务系统可以通过平台服务总线基础数据查询接口查询平台基础数据，并与业务系统基础数据做对照。基础数据组件不支持写入接口。业务系统如有需求，可通过平台界面把业务系统的基础数据维护进平台。如有特殊情况，业务系统还可以通过业务数据写入接口把业务系统的的基础数据写入平台的标准存储，然后由平台实施人员基于标准存储中的数据，在基础数据中建立视图型的基础数据，发布到各个业务系统中。维护的基础数据包括但不限于以下：（1） 功能科目：包括功能科目数据版本、功能科目代码、功能科目名称、功能科目唯一码、变化类型、变化序号等。（2） 经济科目：包括经济科目数据版本、经济科目代码、经济科目名称、经济科目唯一码、变化类型、变化序号等。（3） 单位信息：包括单位信息数据版本、单位代码、单位名称、单位唯一码、地址、邮编、电话、传真、联系人、机关负责人、财务负责人、经费供给方式、行政级别代码、组织机构编码、地区编码、变化类型、变化序号、单位类别等。（4） 项目类别：包括项目类别数据版本、项目类别代码、项目类别名称、项目类别唯一码、变化类型、变化序号等。（5） 资金性质：包括资金性质数据版本、资金性质代码、资金性质名称、资金性质唯一码、变化类型、变化序号等。（6） 归口处室：包括处室数据版本、处室代码、处室名称、处室唯一码、变化类型、变化序号等。7）支付方式：包括支付方式数据版本、支付方式代码、支付方式名称、支付方式唯一码、变化类型、变化序号等。（8）结算方式：包括结算方式数据版本、结算方式代码、结算方式名称、结算方式唯一码、变化类型、变化序号等。业务系统与平台衔接的基础数据详见“.基础数据衔接需求”2、基础数据横向共享基于平台生长和整合的业务系统之间的基础数据交换主要通过平台服务总线组件实现，通过调用平台注册服务、查询接口实现系统与系统的数据交互。3、基础数据纵向交换业务系统通过本级平台和上级平台的数据交换组件实现基础数据上下级交换，从而实现上下级财政的业务协同。上下级财政交换模式是异步交换模式的扩展，两级平台数据交换组件之间数据传递采用“推”和“拉”相结合的方式，下级平台数据交换组件定时从上级平台数据交换组件检索属于本级财政的基础数据包，进行下载和必要处理；下级平台数据交换组件定时将需要报送上级财政的基础数据包上传到上级平台数据交换组件。平台基础数据管理组件（数据字典）管理维护将要下发下级财政的数据元、业务要素及其代码集，设定其在下级财政的应用范围。需要进行财政业务基础数据规范下发时，平台基础数据管理组件调用数据交换组件完成基础数据的交换。平台基础数据管理组件调用交换组件完成财政业务基础数据规范下发流程图如业务数据管理1、业务数据录入与维护业务系统的业务终审数据的存储使用平台的标准存储组件，按照平台的要求统一进行注册登记，平台统一进行各类业务数据存储的分类管理，方便进行业务数据分析，以及与其他业务系统之间的数据共享与交互。由于标准存储数据量较大，为避免影响平台效率，标准存储单独设置数据源。标准存储只保存最重要的业务系统数据，一般是结果数据，不存储过程数据。标准存储保存各业务系统需要共享的数据。•平台统一管理一体化系统的标准存储信息。•中央的标准存储表结构由中央定义并下发。•地方可创建自己本级的标准存储扩展。•中央向地方标准存储数据采集。•同级财政向地方标准存储数据采集。•数据采集后可以下发给下级财政使用。标准存储组件采集业务数据可有两种方式：＞平台控制：采集任务由平台发起，业务系统需提供任务接口，由平台调用。采集控制表存储在平台。业务系统按采集表时间进行增量数据采集。A业务系统控制：米集任务由系统发起。米集控制表存储在平台。业务系统按采集表时间进行增量数据采集。业务系统使用平台的总账组件提供的接口和功能，将预算与执行核心业务数据按平台总账的规范要求记入平台总账存储中。通过总账的复式记账过程，可全面反映财政核心业务的整体运转情况。写入总账的业务数据要根据平台数据元（数据字典）进行定义。如果业务数据与总账业务要素不匹配，需要把它先转化成业务要素再写入总账。总账配置功能界定如下：＞单据定义要根据具体的业务需求和实施情况决定是在业务系统中配置还是在平台中配置＞账套，科目，记账模板，业务要素，核算要素在平台配置＞单据需与平台记账模板做关联＞单据的数据信息需参照业务要素制定＞总账写入时需要账套，记账模板，用户信息和单据数据＞平台提供总账写入和查询接口。总账科目体系需要涵盖政府的所有经济活动及核算目标，按权责发生制体系来设计,科目体系包含资产、负债、净资产、收入、支出等，同时也要考虑风险准备、成本控制、结余等要素。分为预算编制科目体系和预算执行科目体系：预算编制科目体系用于核算预算编制过程中，财政资金收入、支出的平衡关系。按照预算种类，分别对以下进行核算：＞一般公共预算＞政府性基金预算＞国有资本经营预算＞社会保险基金预算预算执行科目体系用于平衡以下关系：＞预算批复＞预算调整变动＞预算资金的计划＞收支的全过程2、业务数据横向共享基于平台生长和整合的业务系统之间的基础数据交换主要通过平台服务总线组件实现，通过调用平台注册服务、查询接口实现系统与系统的数据交互。＞数据共享实现：明确来源和去向，由哪个系统写入，哪个系统调用。＞数据分析与汇总：数据明确标识以便共享，例如：预算部门收入计划，固定资产的单位固定资产收入计划数据项。＞统一数据结构：数据字段按基础数据规范里的数据元和业务要素定义。＞按预算单位:数据表里都有预算单位,这样可按预算单位层码进行汇总。＞按时间：数据表里都采集时间和数据时间，这样可按时间轴进行汇总。3、业务数据纵向交换通过本级平台标准存储组件、数据交换组件以及上级平台标准存储组件、数据交换组件进行业务系统的上下级之间业务数据的采集与存储。各业务系统通过平台dubbo的方式调用调用交换组件发送以及查询数据。实现纵向层级间的数据交互。平台交互组件应用示意图如下：上级平台将采集频率下发到下级平台，下级平台按采集频率和时间定期启动批处理作业向上级平台发送数据。上级存储采集控制表（日志表）记录采集信息。数据采集根据采集控制表增量发送数据。采集时对数据进行校验，根据校验结果返回成功与否信息。另外，纵向采集还提供手动校验功能，在非采集时间进行表对表按时间段数据校验。业务系统与上级平台系统的业务数据交换存在同步方式和异步方式两种方式。＞同步方式：数据交换发送者构造请求数据包，并发送至平台数据交换组件；平台数据交换组件将请求数据包发送给数据交换接收者进行处理，最终向发送者返回响应数据包。发送者只有接收到响应数据包或捕获到数据交换异常后才继续往下执行，这种方式适用于数据交换量小、响应时间要求严格的情况。＞异步方式：数据交换发送者向平台数据交换组件发出请求数据包后，继续进行其他处理，而不是等待响应数据包；平台数据交换组件负责将请求数据包发送给接收者，或接收者主动从平台数据交换组件索取请求数据包；接收者在获得请求数据包后进行处理并构造响应数据包，然后发送至平台数据交换组件；平台数据交换组件负责将响应数据包发送给发送者，或发送者主动从平台数据交换组件索取响应数据包；发送者在获得响应数据包后进行处理。这种方式适用于数据交换量比较大且对响应时间要求不十分严格的情况。数据查询与统计分析业务系统使用平台报表组件提供的功能和接口，在平台中定义业务报表格式和取数方式，报表引擎既可独立运行，也可嵌入到业务系统中，方便进行系统内以及跨业务系统的统计、查询和分析工作。•支持利用平台报表组件自定义报表•支持利用平台报表组件自定义打印设置利用平台报表组件定制风格多样报表利用平台报表组件管理报表工作流程协同业务系统使用平台工作流组件提供的功能和接口，可在平台中定义系统的各类工作流程，工作流运行引擎在业务系统中，可将各类业务办理和工作流程进行结合，在系统中实现各种业务流程的流转、审批和复杂的业务处理，以满足项目不断变化的业务流程需求。平台2.0工作流组件基于流行的开源流程引擎Activiti5.X的基础上构建,扩展容易，学习成本低。平台统一针对各个业务系统进行流程建模、流程配置，本项目各业务系统只专注于自身的业务逻辑的实现，平台工作流组件负责对各业务流程进行精确管理。1.1.5基于平台2.0整合式接入设计系统整合接入方式基于平台整合接入的模式下，业务系统本身并不和平台打交道，而是和在平台之上的各种服务打交道，采用接口调用方式获取业务系统接入节点的数据。应用支撑平台2.0引入了一个新的核心组件服务总线组件统一管理平台和外界的接口。业务系统可以通过调用应用支撑平台的服务总线提供的服务实现与平台的对接。系统登录与安全管理1、系统单点登录平台可提供单点登录功能给业务系统。在这种方式下，业务系统在平台中有链接，用户只在平台登陆一次，由平台进行用户认证，业务系统信任平台认证，因此不必再在业务系统登录。平台存有各个业务系统所有用户有关信息，业务系统也存有自己的用户信息，以便数据权限控制。这样用户信息就存在不同库中。不同库中的用户可用标识位进行匹配。用户通过平台登录入口验证用户的基本信息。验证通过后用户信息缓存到平台系统中，同时平台为用户生成令牌（TokenID）。用户跳转到第三方系统时会携带TokenID,业务系统通过TokenID来识别用户身份，并可以通过TokenID从平台获取用户信息2、系统用户权限管理在整合方式下，平台统一管理各业务系统用户和单位信息。对权限的管理只到系统一级，平台一般不管理接入系统的菜单。平台提供用户查询接口，平台对外服务总线暂不提供用户维护接口。用户信息在平台页面中维护，平台提供界面维护单位，用户，角色信息，如果数据量很大，也可通过数据表直接导入。平台提供数据表导入模板。基于平台的服务调用业务系统对平台中服务的注册和调用以及对其他系统中服务调用是通过服务总线实现的，通过服务总线可以调用平台组件丰富的的服务接口。服务总线组件提供包括服务注册管理、服务发布管理、服务授权管理、服务监控管理等功能。同时，平台制定业务系统提供服务的规范，支持将业务系统的服务注册到平台并通过平台授权给其他业务系统应用。注册到平台的服务需满足服务管理、服务要求、服务权限和日志的要求。服务提供方(平台，各表层业务系统，第三方系统)需要按照平台规范的要求设计开发服务(如查询数据服务程序)，包括接口服务方式、身份认证、数据组织形式等等。开发完成的接口服务需要到平台注册，通过平台验证后发布，供其它业务系统查询和调用。服务使用方经过平台的授权并按照平台规范的要求调用服务提供方在平台中注册的服务，获取到相应的数据。1、调用服务过程系统注册服务：提供服务的系统需在平台先注册以取得平台唯一的标识符。任何服务都有服务名，服务名必须唯一。任何服务都要注册支持邮件地址用来发送错误信息。平台管理各业务系统提供的数据服务，包括服务名称、服务地址、服务参数、数据返回值形式及意义、服务提供方(业务系统)、服务的性质和作用等内容。系统发布服务：业务系统在平台注册，平台为系统分配appid，该id作为业务系统在平台系统中的唯一标识，用于识别系统身份、管理业务系统功能的唯一识别码。系统在平台服务管理功能中注册服务内容，填写服务描述信息，并上传服务相关技术文档。平台根据服务描述文件的内容自动分析出服务的具体内容，包括方法名、参数个数、参数类型等。对服务的应用范围进行授权，并在控制界面启用服务，其他系统即可相应调用业务系统发布的服务。修改系统服务：通过平台服务总线的统一界面来修改服务参数。授权系统服务：平台统一对服务的调用权限进行管理。对于已经在平台注册的业务系统，通过服务总线设置权限功能，在授权功能中勾选业务系统后即时生效，将服务授权给业务系统调用。系统调用服务：业务系统在平台注册，获得平台分配的appid，并经过平台服务总线授权所需的服务，即可调用平台服务、其他一体化业务系统服务及第三系统的服务。2、调用服务要求基于平台的任何业务服务或第三方服务必须是同步服务。系统如果不能在指定时间内完成服务，需要返回服务超时错误，服务如不能正常结束，需给出明确错误信息以便存入日志。任何服务必须检查输入参数，如不满足条件（类型不匹配或值域不不匹配），需给出明确错误信息以便客户端修正。3、调用服务权限平台通过服务总线统一管理服务权限，并提供服务权限设置界面。4、调用服务日志业务系统调用服务的过程都会在平台服务总线记录生产日志，平台提供服务请求日志和服务操作日志。（1）服务请求日志日志涵盖每一次服务调用，包括以下内容：＞客户端信息＞调用参数＞调用时间，完成时间＞如有错误，必须提供完整错误信息＞错误信息由服务端提供，其他信息由平台提供（2）服务操作日志服务操作日志记录服务的注册，修改情况。基础数据管理1、 基础数据维护整合式业务系统通过平台的外部服务总线进行基本的基础数据查询。查询方式有全量查询和增量查询两种，可以保证获取实时准确数据。同时，平台不直接提供基础数据写入接口。可通过平台界面在平台里维护业务系统使用的基础数据。＞全量查询接口说明：平台登录后，向业务系统提供请求服务，业务系统把基础数据的全量数据读取出来。＞增量查询接口说明：平台登录后，向业务系统提供请求服务，业务系统把基础数据的增量部分数据读取出来。2、 基础数据横向共享基于平台生长和整合的业务系统之间的基础数据交换主要通过平台服务总线组件实现，通过调用平台注册服务、查询接口实现系统与系统的数据交互。3、基础数据纵向交换整合业务系统可调用平台数据交换组件接口完成数据下发和数据上传，平台的交换组件为业务系统提供了上下级之间的数据交换通道。业务系统先调用文件服务器数据上传接口把数据上传到本级平台文件服务器，再调用交换组件接口把文件上传到上级平台的交换组件，文件被存储在上级平台文件服务器中。上级业务系统再调用文件服务器数据下载接口把文件下载到上级业务系统中业务数据管理1、业务数据录入与维护业务系统的业务终审数据的存储使用平台的标准存储组件，按照平台的要求统一进行注册登记，平台统一进行各类业务数据存储的分类管理，方便进行业务数据分析，以及与其他业务系统之间的数据共享与交互。由于标准存储数据量较大，为避免影响平台效率，标准存储单独设置数据源。接入平台的业务系统注册获得唯一标识，便于区分接入数据来源，由平台统一分配管理。各系统调用接入服务的权限均以此来控制。平台提供基本的写入和查询接口，以供业务系统把数据写入标准存储和从标准存储里获得数据。业务数据进入平台时，必须通过调用平台提供的接口服务进行处理，禁止直接修改平台中的数据表。标准存储组件采集业务数据可有两种方式：＞平台控制：采集任务由平台发起，业务系统需提供任务接口，由平台调用。采集控制表存储在平台。业务系统按采集表时间进行增量数据采集。A业务系统控制：米集任务由系统发起。米集控制表存储在平台。业务系统按采集表时间进行增量数据采集。业务系统使用平台的总账组件提供的接口和功能，将财政核心业务数据按平台总账的规范要求记入平台总账存储中。通过总账的复式记账过程，可全面反映财政核心业务的整体运转情况。业务系统调用平台服务总线总账查询接口查询获取账套、记账模板（交易令）和核算要素的数据。业务系统调用平台服务总线总账写入服务方法，传递的基础数据参数包括账套GUID、记账模板GUID、记账模板所属财政和财年、平台用户GUID和业务数据（包含核算要素）。写入总账的业务数据要根据平台数据元（数据字典）进行定义。如果业务数据与总账业务要素不匹配，需要把它先转化成业务要素再写入总账。总账配置功能界定如下：＞单据定义要根据具体的业务需求和实施情况决定是在业务系统中配置还是在平台中配置＞账套，科目，记账模板，业务要素，核算要素在平台配置＞单据需与平台记账模板做关联＞单据的数据信息需参照业务要素制定＞总账写入时需要账套，记账模板，用户信息和单据数据＞平台提供总账写入和查询接口。总账科目体系需要涵盖政府的所有经济活动及核算目标，按权责发生制体系来设计,科目体系包含资产、负债、净资产、收入、支出等，同时也要考虑风险准备、成本控制、结余等要素。分为预算编制科目体系和预算执行科目体系：预算编制科目体系用于核算预算编制过程中，财政资金收入、支出的平衡关系。按照预算种类，分别对以下进行核算：＞一般公共预算＞政府性基金预算＞国有资本经营预算＞社会保险基金预算预算执行科目体系用于平衡以下关系：＞预算批复＞预算调整变动＞预算资金的计划＞收支的全过程业务系统与平台衔接的业务数据详见“.标准存储衔接需求”、“.平台总账衔接需求”。2、业务数据横向共享基于平台生长和整合的业务系统之间的业务数据交换主要通过平台服务总线组件实现，通过调用平台注册服务、写入和查询接口实现系统与系统的数据交互。基于平台生长和整合的各业务系统间原则上不再建立数据接口，均通过平台实现数据共享。＞数据共享实现：明确来源和去向，由哪个系统写入，哪个系统调用。＞数据分析与汇总：数据明确标识以便共享，例如：预算部门收入计划，固定资产的单位固定资产收入计划数据项。＞统一数据结构：数据字段按基础数据规范里的数据元和业务要素定义。＞按预算单位:数据表里都有预算单位,这样可按预算单位层码进行汇总。＞按时间：数据表里都采集时间和数据时间，这样可按时间轴进行汇总。3、业务数据纵向交换通过本级平台标准存储组件、数据交换组件以及上级平台标准存储组件、数据交换组件进行业务系统的业务数据纵向采集与存储。上级平台将采集频率下发到下级平台，下级平台按采集频率和时间定期启动批处理作业向上级平台发送数据。上级存储采集控制表（日志表）记录采集信息。数据采集根据采集控制表增量发送数据。采集时对数据进行校验，根据校验结果返回成功与否信息。另外，纵向采集还提供手动校验功能，在非采集时间进行表对表按时间段数据校验。业务系统与上级平台系统的业务数据交换存在同步方式和异步方式两种方式。＞同步方式：数据交换发送者构造请求数据包，并发送至平台数据交换组件；平台数据交换组件将请求数据包发送给数据交换接收者进行处理，最终向发送者返回响应数据包。发送者只有接收到响应数据包或捕获到数据交换异常后才继续往下执行，这种方式适用于数据交换量小、响应时间要求严格的情况。＞异步方式：数据交换发送者向平台数据交换组件发出请求数据包后，继续进行其他处理，而不是等待响应数据包；平台数据交换组件负责将请求数据包发送给接收者，或接收者主动从平台数据交换组件索取请求数据包；接收者在获得请求数据包后进行处理并构造响应数据包，然后发送至平台数据交换组件；平台数据交换组件负责将响应数据包发送给发送者，或发送者主动从平台数据交换组件索取响应数据包；发送者在获得响应数据包后进行处理。这种方式适用于数据交换量比较大且对响应时间要求不十分严格的情况。数据查询与统计分析业务系统使用平台报表组件提供的功能和接口，在平台中定义业务报表格式和取数方式，报表引擎既可独立运行，也可嵌入到业务系统中，方便进行系统内以及跨业务系统的统计、查询和分析工作。工作流程协同业务系统使用平台工作流组件提供的功能和接口，可在平台中定义系统的各类工作流程，工作流运行引擎在业务系统中，可将各类业务办理和工作流程进行结合，在系统中实现各种业务流程的流转、审批和复杂的业务处理，以满足项目不断变化的业务流程需求。1.1.6系统部署及运行环境设计系统部署模式设计系统属于混合架构的业务软件模式，它与传统的B/S业务软件架构有所不同主要是多了一个公共组件层（域）供所有软件使用相同的组件模块，综合财政应用支撑平台升级及一体化升级现状应符合以下框架环境要求：平台和业务系统统一部署，不同系统间的交互通过平台的同步机制、服务总线实现，用户、角色、权限、数据字典等数据集中管理，用户通过门户统一访问平台和系统。统一部署模式实现设备集中、业务集中、数据集中，加强业务系统统建统管，实现上下级业务模式的统一、标准规范的统一、运维管理的统一，为全市数据贯通创造基础条件。利用现有网络环境，在信息中心集中部署数据库服务器、应用服务器、数据交换服务器、SAN存储中心磁盘阵列、光纤通道SAN交换机、虚拟磁带库（磁盘阵列）、备份服务器，并在各服务器上部署操作系统、数据库系统、应用中间件软件、相关应用支撑软件。各级、各类用户可通过业务客户端访问部署在应用服务器上的财政应用支撑平台及综合业务系统来完成统一门户管理、基础信息库项目库管理、预算编制、预算调整管理、指标管理、预算绩效目标管理、集中支付管理、实拨管理等业务工作。应用支撑平台在升级实施后整体部署结构如下图所示：平台升级后形成部、市、区县三级平台网络，我区平台在升级后连接到市级平台，各级平台网络通过数据交换组件和文件服务组件实现各类财政数据的互联互通；平台采用分布式框架体系，分为主控域和业务域，独立部署，实现业务系统与平台的分离，降低业务系统与平台的耦合性，提高平台可操作性。如下图所示：硬件部署环境设计1、系统部署拓扑结构本项目所建财政应用支撑平台及综合业务系统依托于现有网络环境中的相关软硬件基础设施，在信息中心进行统一部署，为财政局的业务科室室人员（经办人、科室领导）、预算单位（经办人）、银行（业务人员、业务领导）、维护管理员用户提供财政信息化平台管理与信息应用服务。系统完全适应当前的主流网络配置，采用数据通信与加密、安全控制等技术，实现安全、可靠的网络数据传输、数据交换等应用集成处理。系统的部署拓扑结构如下所示：从网络拓扑结构可知，本项目所建综合业务系统所依赖的硬件设备主要包括1） 主机设备：应用服务器、数据库服务器、数据交换服务器；2） 存储备份设备：存储备份磁盘阵列、光纤通道存储交换机。2、系统硬件环境配置建议本项目所建系统完全适应当前的主流硬件配置，并将充分利用现有的服务器存储备份设备进行硬件设备的部署，具体部署建议如下所述：财政局平台及综合业务系统基础环境配置建议如下：

序号类别单台配置描述数量1分布式应用服务器（含配套软件）2*E5-2650V3CPU,1*4端口千兆网卡，满配电源风扇，机架导轨,机架服务器，256GB内存，8块1.2TBSAS10K硬盘，2块双端口10GE以太网卡，4个多模万兆模块，三年保修。含Linux操作系统、Hadoop系统套件、分布式数据缓存套件。32虚拟化应用服务器机架式4颗4*E7-4820V3CPU,256GB内存,2*600GHS2.5inSAS,RAID卡,2块双端口万兆网卡（含多模万兆模块），2块8GbHBA卡（含模块），DVD，导轨，满配电源风扇。23数据库服务器选项一（16核小机）HP16核2.1GHzCPU，128GB内存小型机。可扩展到64核。2*600GHS2.5inSAS,2块双端口万兆网卡（含多模万兆模块），2块8GbHBA卡（含模块），导轨。2选项二（32核小机）HP32核2.1GHzCPU，256GB内存小型机。可扩展到64核。2*600GHS2.5inSAS,2块双端口万兆网卡（含多模万兆模块），2块8GbHBA卡（含模块），导轨。2选项三（8路X86服务器）8颗8860v316核2.2GHzCPU，512G内存，2*600GHS2.5inSAS,RAID卡，2块双端口万兆网卡（含多模万兆模块），2块8GbHBA卡（含模块），DVD，导轨，满配电源风扇。24万兆交换机24个万兆SFP+，双交流电源，20个万兆多模模块，4个千兆多模模块25SAN交换机光纤交换机-24端口（24端口激活，含24*8Gb多模SFP,含E-Port级联License）26磁盘阵列存储双控，64GB缓存，18块1.2TB10kSAS硬盘（可用容量大于15T），8个8GbFC主机接口，多路径软件许可17系统集成提供服务器及存储系统的数据移植服务，包括但不限于：新购设备安装调试，利旧设备规划调整，相关迁移数据移植。1WEB及中间件层：Linux和Windows；建议Linux系统，部分应用组件仅支持Linux（可选rhel6.5ppc64）。公共组件层：Linux。Oracle数据库层：Linux和UNIX；建议UNIX。1.1・6・3软件部署环境设计1、系统软件部署与环境配置建议本项目所建系统依赖的系统软件包括：操作系统、数据库管理系统、应用中间件、应用支撑软件，将依托于本项目的网络及硬件环境，部署在财政局信息中心内网的数据库服务器、应用服务器、数据交换服务器上。服务器端系统软件部署方案系统软件的部署信息如下所示：虚拟化软件任何支持X86系统的计算虚拟化的软件。分布式软件Hadoop2.6或之上、MongoDB2.4、REDIS3.0。数据库软件OracleDB11G和分布式NoSQL。中间件软件OracleWebLogic11G。版本(Weblogic1036)。消息中间件IBMMQ7或东方通TongLINK数据库服务器的系统软件部署在数据库服务器上部署操作系统、数据库管理系统、虚拟化软件、分布式软件，完成各类业务管理与应用信息的存储与管理，并控制系统向磁盘阵列读写业务管理和应用数据。应用服务器的系统软件部署在应用服务器上部署操作系统、应用中间件、虚拟软件、分布式软件，完成本项目所建业务应用系统的部署与运行管理，并通过数据库管理系统访问业务应用信息资源，实现相应业务管理与信息应用。数据交换服务器的系统软件部署在数据交换服务器上部署本项目所建业务应用系统的系统接口，实现与相关外部系统的数据交换与集成整合。其他应用支撑软件部署在各应用服务器上部署工作流引擎软件、报表软件、多维分析软件，为业务应用系统提供业务处理、工作流定制、报表定制、多维分析等方面的应用支撑服

务，有效支持系统运行。2）客户端系统软件部署方案在财政局、业务科室人员（经办人、科室领导）、预算单位（经办人）、银行业务人员、业务领导）、维护管理员用户等机构的客户端将部署操作系统、浏览器、中间件开发包、报表插件等系统软件，其部署方案如下：一序号一系统软件名称单位数量配置说明部署位置1操作系统套1WindwosXP/Vista/7,等客户端PC机2浏览器套1支持IE6.0及以上、360安全浏览器等主流浏览器客户端PC机3中间件开发包套1JSDK1.5及以上客户端PC机4报表插件套1报表客户端运行插件客户端PC机通过在客户端PC机上部署操作系统、浏览器、中间件开发包、报表插件，提供业务管理与应用的运行支持平台，并利用浏览器完成业务信息的采集、存储、处理、加工、传输、应用，以及安全访问、系统管理。其中，利用报表插件，可以对业务表单、统计报表进行显示和打印。2、应用软件部署本项目所建系统包括统一门户管理、基础信息库、项目库管理、预算编制、预算调整、指标管理、预算绩效管理、集中支付管理、实拨管理以及相关外部系统应用集成接口，将集中部署在财政局信息网络中心的相关应用服务器上。业务应用软件系统各部分的部署方案如下所示：序号系统名称、快匚＞=t数量单位部署说明部署位置1财政应用支撑平台升级及综合业务系统1套1） 应用支撑平台2） 统一门户管理3） 基础信息库4） 项目库管理5） 预算编制6） 预算调整管理7） 预算绩效目标管理8） 指标管理9） 集中支付官理10） 实拨管理信息中心（内网）；刀片应用服务器在应用服务器的应用中间件平台上部署上述业务应用系统，以满足相关业务用户进行财务信息化平台管理和应用的要求。同时，通过统一身份认证机制，对整个系统的安全进行统一管理与控制，为系统运行提供完善、可靠的安全机制1.1.7系统技术路线面向服务的架构SOA本项目将通过SOA体系，以服务为中心来组织系统功能，从而提高服务响应速度，增强系统灵活性，更好地适应业务的需求，并提供更好的用户体验。面向服务架构（SOA）是一个典型的MVC模式的架构，其示意图如下所示：与传统方法相比，SOA更加强调以下优势：基于标准、松散耦合、共享服务、粗粒度和联合控制。通过不断地构筑业务需要的各种标准服务，实实在在地形成一个“服务仓库”，按需服务，最终实现的业务自主（最终用户编程）。服务是网络中可用的软件资源。服务提供者通过标准机制提供服务，服务使用者通过网络有计划性地使用服务。服务代理发布服务所在位置，并在使用者请求服务时定位服务。服务使用者和提供者的角色不是惟一的；服务提供者也可以是使用者，反之亦然。提供者在服务约定中以标准语言描述其服务，并向代理发布服务。客户从服务代理处（或登记处）查询所需的服务，并接收有关服务访问的约定和信息。随后，客户或使用者便可绑定到服务，并可与提供者直接通信。服务实现包含服务的功能或业务逻辑。对于服务使用者来说，服务实现应是一个“黑匣子”；用户没必要知道服务的功能实现细节。有以下五类服务：1） 数据访问-允许对不同数据源进行统一访问。2） 组件-提供对打包应用服务的访问，如ERP。3） 业务-提供使用一个以上打包应用或定制应用功能的复杂服务。4） 组合-使用以上三种类型的服务来创建包括新功能和现有功能的新服务5） 共享的或企业基础架构服务，消息日志之类的低级服务，其重用性使快速创建新的高级服务成为可能。在SOA架构下，不管是数据访问、组件访问还是业务访问，都是对服务的访问，并可在此基础上组合和共享。对此制定标准的服务规范和接口，将简化计算环境。以服务或组件形式出现的业务逻辑可以被共享、重用、配置，各系统通过标准化的服务接口连接起来。与SOA架构有关的几个关键术语及其相关实现技术和标准如下所述：1） 松散连接：可使用服务进行应用整合，而无需知道该服务的语言、平台、位置或状态。WebServices提供了到网站或应用的程序接口。可能存在几个操作，每个操作都有自己的输入和输出信息。这些操作组合起来就构成了服务的程序接口。具体的实施细节、平台和语言都被隐藏起来了。只要在调用时遵循HTTP协议，返回时遵循SOAP协议，就能利用WebService灵活集成不同应用。2） 发现：SOA的三角形关系结构说明了面向服务中注册“发现”交互循环，其目标是要实现对服务的动态发现。3） 流程：提供服务之间的信息顺序和控制顺序，包括简单的或复杂的决策制定，并通过选择和循环结构来实现。业务规则负责对流程进行指导和控制。上述关键术语说明了面向服务能够提高的生产率和敏捷性。目前，WebServices的核心标准已经相对成熟，应用服务器和供应商都有符合标准的产品面市。Web服务建立在开放标准和独立于平台的协议的基础之上。Web服务通过HTTP使用SOAP（一种基于XML的协议），以便在服务提供者和消费者之间进行通信。服务通过WSDL（WebServiceDefinitionLanguage）定义的接口来公开，WSDL的语义用XML定义。UDDI是一种语言无关的协议，用于和注册中心进行交互以及查找服务。所有这些特性都使得Web服务成为开发SOA应用程序的优秀选择。服务质量方面的一些主要标准也有了很大进展，比如安全性标准（如WS-Security）和可靠性标准（如WS-ReliableMessaging）。其他标准还有BPM标准（如BPEL）、WebServices管理（如WSDM）以及WebServices门户标准（WSRP）也都获得了许多厂家的支持，产品也成熟。SOA凭借其松耦合的特性，使得本项目所建应用软件系统可按模块化方式来添加新服务或更新现有服务，以满足新的业务需要，并通过不同渠道来提供服务，将现有或原有应用作为服务，从而保护了用户的信息化建设投资。本项目将利用信息门户技术来实现所建系统的统一业务信息门户的资源整合与内容管理、信息发布与多样化展现服务，可有力支持国库支付管理的资金支付管理、账务处理管理、预算单位管理、监控管理、现金管理、政府财务报告等工作的开展，拓展业务管理和相关信息服务的技术手段，从而有效提高工作效率、业务管理和信息应用水平，为各类业务管理人员、相关领导提供不同层次的信息服务。应用门户框架(portal)是面向服务架构直接面对用户的界面，是用户访问所有服务的统一的信息系统入口。下图是应用门户框架的示意图。政府信息系统经常使用不同种类的解决方案来经营业务。它们的工具集可能包括各种完全不同的解决方案，这时每个应用程序与其他应用程序之间都会存在数据重叠。由于多种原因，政府部门将信息存储在不同的系统中，以各种不同的方式进行格式设置和访问。对于最终用户来说，这种系统布局会降低生产力。用户必须首先了解每个应用程序的用途和操作，还必须记住多个登录信息，每个信息对应一个应用程序。此外，必须熟悉各个不同的平台。例如，某个工作环境可能包括使用Windows用户界面的客户服务器应用程序、基于Web的应用程序，甚至是在模拟窗口中执行的字符模式应用程序。这些只是最终用户在一个异类信息系统上执行日常工作必须面对的一小部分困难。每个政府部门面临的挑战就是消除这些困难，以提高服务水平和工作效率。理想解决方案是通过无缝集成平台，使用统一验证实现应用程序的统一访问和有效管理。作为通往信息访问和管理的真正网关，门户是集成政府信息系统应用程序并向用户提供高效和完善环境的最佳形式。通过政府信息系统的统一入口点，政府信息系统门户实现了从一个位置上对所有应用程序的访问。通过将政府信息系统应用程序集成到门户的方式，所有用户可统一、持续地访问信息。用户无需了解、关心信息的来源，这些信息通过“浏览器”工具“推向”用户。一次性登录(SSO)是政府信息系统门户提供的一个核心服务。使用SSO,用户登录一次即可访问多个应用程序。通过提供透明的个性化信息访问(这种信息访问独立于真正承载数据的后端应用程序），门户使信息使用更简便。政府信息系统门户的设计很直观用户能够自己查找和操作信息，无需任何培训。政府信息系统应用程序到门户的集成即利用了此特性。门户设计者的任务就是通过为每个企业需求提供相关视图并实现与最终用户交互的方式来组织内容。例如，当某个管理人员与门户连接时，主页将显示他的个性化内容，例如他的文件夹和邮件。该主页还可能包含等待他进行审批的部门支出报告。包含这些通知的Portalet会自动引导该管理人员完成查看、接受或拒绝各种支出的过程。用户还可以使用门户页面和集成数据，以有助于促进业务发展的方式提供信息。门户可使用户聚合来自不同系统的数据，并将这些数据转换为商务智能。政府信息系统应用程序到门户的集成使得信息能够用于更广泛的用户，并通过为广泛的政府信息提供个性化和相关视图，使其更加智能化。门户是提高所有工作人员（从决策者到执行者）办公效率的重要因素。运用门户定制、内容管理、通用表单处理、信息发布、信息展现等方面的信息门户技术，构建全面而完善的信息服务管理平台，主要涉及以下技术：1） 栏目管理技术：采用多层次、分布式的栏目管理技术，提供不同位置与架构层次的信息门户栏目管理。2） 模板管理技术：采用频道方式分类管理多种信息展现模板，实现通用表单处理。通过支持模板的层次嵌套，并利用不同的页面访问策略，实现静态与动态信息的发布。3） 内容管理技术：利用可视化编辑器以“所见即所得”的方式进行信息门户内容的图文混排处理，并通过语言转换平台进行信息展现的国际化语言支持。4） 信息审核技术：通过信息审核控制逻辑，对待发布的信息按照指定流程进行审批，确保信息门户中信息的有效性。5） 信息发布技术：运用数据管理和更新技术，提供信息的快速发布、定制发布、完全发布、高级发布、后台发布等多种发布方式和技术手段，从而灵活地管理所发布的内容，并有效地提高系统的性能和人员效率。6） 信息浏览技术：采用图文信息、文档、附件等复合文档的发布预览技术，在信息正式发布到Web服务器前准确感知真实效果，并在信息发布后利用信息门户的丰富展现功能进行图文信息浏览。对于本项目所有牵涉到多部门、多岗位协同处理的业务，将在业务应用系统中采用工作流方式，对数据采集、日常监督、专项监督、重点监督检查、信息通报、行政处理处罚、评价结果应用等工作进行网络化业务流程处理，并运用工作流技术来实现以下功能。1）系统支持任务自动通知、审批退回、各环节批量数据处理等功能。2）系统在各审批环节使用专用界面，并支持电子印章，提供完整的电子签章整合接口，方便工作处理。为此，本项目将采用基于J2EE技术体系开发的工作流系统，在工作流模型的描述和应用接口等方面遵循WFMC（标准化组织工作流管理联盟）提出的工作流参考模型，由一套互相独立、紧密联系的软件模块和工具构成，包括：工作流引擎、图表化流程定义工具、流程运行跟踪功能。工作流系统具有以下功能：1）对过程定义进行解释；2） 控制过程实例的创建、激活、挂起、终止等；3） 控制活动实例转换，包括串行或并行操作、工作流相关数据解释等；4） 支持分布式工作流的协同；5） 管理流程的柔性执行；6） 提供支持用户操作的接口；7） 维护工作流控制数据和工作流相关数据；8） 提供用于激活外部应用程序和访问工作流相关数据的接口；9） 提供控制、管理和监督工作流实例执行情况的功能。利用工作流定制与管理功能，可以定制出环节数量不受限制的各种日常管理审批流程，并可作为共享引擎，来支持相关管理信息的审批或流转控制。（1） 工作流定制的应用范围从通用和实用角度出发，系统的流程定制模块提供了大量的可自定义选项，具有良好的全局性、实用性、可伸缩性、适应性，可以采用非编程化管理模式，根据业务管理流程需要，自定义出完全适合本组织的多种业务流程。（2） 工作流定制的步骤和方法组织机构内各种工作事务的处理过程在各业务应用系统中表现为流程形式。流程定义步骤包括：流程定义、环节定义、流向定义。1）流程定义：定义流程的基本属性，包括流程名称、类别、应用表单、管理者、使用人、归档方式等内容。2）环节定义：每个环节均由指定的办理人按指定的办理方式和办理权限完成相应的工作处理任务。3）流向定义：指定流程各环节的流转次序、流转规则。（3）工作流定制的功能实现上述功能分三类进行实现，主要包括：工作流模型定义、图表化流程定义、表单设计，具体描述如下：1）工作流模型定义：根据已建工作流模型进行工作流程运转模型定义。2）图形化流程定义：使用图形化的方法，运用丰富的流程逻辑表达方式，来设计、修改复杂的业务工作流程。3）表单设计：通过表单、界面设计功能，完成表单的设计、部署和管理，实现表单数据、处理逻辑和表示分离，以及数据、初始值、UI组件、校验规则的定义和设置。商业智能BI技术BI（BusinessIntelligence，商业智能）是随着Intemet的高速发展和企业信息化的不断深入而产生的。BI使企业决策者能对企业信息进行有效、合理地分析和处理，为生产决策提供可靠的依据。学术界对BI有不同的定义：DataWarehouseInstitute组织认为“BI是将数据转换成知识并将知识应用到商业行为上的一个过程”：GartnerGroup则认为“BI是将数据转换成信息的过程，然后通过发现将信息转化为知识”。确切地讲，BI并不是一项新技术，它将数据仓库（Dw）、联机分析处理（OLAP）、数据挖掘（DM）等技术与客户关系管理（CRM）结合起来应用于商业活动的实际过程中，实现了技术服务于决策的目的。BI技术的应用架构如下图所示：我公司将在本项目中借鉴相关BI技术理念，在国库支付管理的数据获取、数据挖掘、数据分析、展示利用方面，合理规划相应的数据分析模型，建立业务信息资源的分级管理和应用机制，辅助实现各项国库支付业务的数据分析、数据预警、信息展现等业务应用。报表定制支持各类业务表单的数据采集、公式设置、样式设置、报表生成。通过可视化表单定制器，提供表单的定制、预览、打印、导入、导出等功能。利用报表定制机制，可以根据业务需要快速定义表单格式，并用于相关业务应用。运用报表模型机制，可以对报表模板进行文件管理、对象编辑、视图过滤、公式设置、数据采集、表格设计等报表设计和处理。报表定制的主要任务如下：（1）报表模版文件管理对已创建的报表可进行文件管理，完成以下任务：1）创建报表模版：报表定制工具与后台数据库进行无缝连接，可选择不同数据源，进行各类报表的定制。通过定制向导，只需根据提示操作来创建报表模板，并在报表模板中按需插入数据项、系统日期、计算域、图片、圆形、页数等。2）报表另存：可将报表生成文件保存到磁盘上。3）报表导入：可将保存的报表格式自动导入。报表定制机制与Word、Excel等文档格式进行无缝衔接，可将定制好的报表模板自动导入到系统中，完成对报表的定义。4）报表预览：可预览报表内容，系统自动将已录入的数据填充到报表中，实现报表数据的预览。5）报表打印：可直接将定制完的报表及其内容提交打印机，输出纸质档案。系统中通过“打印”功能自动调用报表打印功能，打印出定制的报表。（2）报表模版对象编辑对已创建的报表可进行修改。在报表中可增加数据列，并将指定数据源中的数据项拖放到报表中。编辑过程中，可对报表格式（如：字体的颜色、大小等）进行调整。报表定制工具可以对以下对象进行编辑：1）表格：输入要创建的表格