电子化采购招投标平台系统建设项目解决方案

电子化采购招投标平台系统解决方案1.1.2.采购系统..................14....1.1.3.业务办公系统……………...18......1.1.4.电子辅助招标系统.....................................18........1.1.5.其他系统.......................19................20.............1.2.1.工作流引擎......………...21.........1.2.2.电子表单定制....……………….......21........1.2.3.多视角平台门户展现方式….......……………..........21............1.2.4.报表定制.......................22...............22............1.2.6.用户权限管理…..........................22............1.2.7.统一日志管理…...….......23.........1.2.8.统一消息管理…...........…...............23............1.2.9.统一备份管理…...................................23....................24..........1.2.11.数据分析与数据挖掘.........................................24..........1.2.12.平台监控管理……………..24......1.3.安全需求……………………1.3.1.软件安全需求……………………25..........1.3.2.操作系统安全需求…………………25............1.3.3.应用系统安全需求………………25.........1.3.4.数据传输安全需求………………26........1.3.5.数据存储安全需求…………………26..........1.3.6.访问控制安全需求…………………28...1.4.1.与原有信息系统的接口需求………29..........1.4.2.与系统软件的接口需求…1.4.3.提供二次开发数据接口……………29..,1.5.前期准备与建议………………………30..........1.5.2.结对编程…………30........2.总体设计方案……………………….......2.1.指导思想………………312.3.设计思路………………34.…....2.3.1.以框架为基石、以业务为主线………………35.........2.3.2.以数据为核心，对数据进行统一管理…………37.........2.3.3.框架跨操作系统平台，应用与设计无关，表现与业务分离………………38..........2.3.4.“微内核”+“插件”的结构，促进多种技术集成………A0............2.3.5.借鉴成功的案例，采用工业标准和成熟的主流和开源产品………………4l..........2.4.系统总体结构………………………41............2.4.1.总体逻辑结构……………………42............基础设施层……数据资源层和数据库模型设计………………44..........Ruby实现的应用支撑平台……………………45..........业务应用层………………………46........用户服务层………………………46........标准和规范体系………………47...........安全体系和运行保障机制……………………47..........2.4.2.网络拓扑………………2.5.关键技术………………49..2.5.2.SOA体系架构及ESB企业服务总线技术……49..…....2.5.3.OA、工作流引擎和业务流程定制技术………49............2.5.4.B/S和跨平台的C/S综合应用客户端相结合的多层分布式技术…………50....2.5.5.海量数据存储与管理技术………50.......2.5.6.中间件技术………………………50.........2.5.7.组件化、构件化开发技术………51............2.5.9.门户管理技术……………………51........2.6.系统数据接口设计……………………51......V2.6.1.数据接口规范设计……………51..........同步消息传送…………………52.....异步消息传送…………………52..........点对点传输…………………53......路由转发………………………53............发布/订阅……………………53.….....2.6.4.交换协议…………54...........2.6.5.数据接口模型设计………………54..........2.7.1.开放性设计……………………60.........2.7.2.可扩展性设计……………………61.........2.7.3.灵活性设计………………………62.…......2.9.系统性能设计………2.9.1.系统性能设计目标………………63............2.9.2.整体性能设计……………………63...........2.9.3.数据库性能优化……………………64......2.9.4.负载均衡方案……………………67............2.10.系统部署方案…………68..........2.10.1.使用集群技术的必要性……………68......2.10.2.集群部署方案……………………70.............镜像服务器双机……………71.............双机与磁盘阵列柜互联………72........2.10.3.Railsapp的子系统的部署………73........前端的选择……………………73..........后端的选择……………………75..............分析和小结……………………76..........2.10.4.Rails部署工具……………………72.10.5.系统集成与软件部署……………79............2.11.系统设计方案合理性…………………81..........3.系统关键技术实现方案………….....3.1.RUBY语言以及敏捷开发………………83.........3.2.RuBy工作流引擎………………………83.......3.3.OA、工作流引擎和业务流程定制技术……………84....3.4.业务流程统一调度的实现……………85............3.4.1.流程管理…………85..........3.4.2.流程调度策略……………………88............3.6.B/S和跨平台的C/S综合应用客户端相结合的多层分布式技术............91.........3.7.海量数据存储与管理技术......................................92...........3.8.中间件技术........................……......92............3.9.组件化、构件化开发技术....................93...........3.10.XML和WEBSERVICE技术…...93..........3.11.信息交换和共享的实现................................94.........3.11.1.基于集成框架和消息中间件的信息传输和转换......................94........3.11.2.应用程序接口技术.......................................95..........3.11.3.基础信息的共享..........................................95............3.12.电子表单设计..............................表单处理系统的功能设计.........................96............对数据字典和信息共享的支持功能…....…………….97.............表单打印功能..………..98.......和门户系统的集成功能………………..98..........对附件的支持功能......................99............表单处理系统的性能要求...........99........表单离线填报补充填报功能............................99..........3.12.2.表单处理系统的技术实现…..…………....99.............表单处理系统的总体结构.....................................99.............表单设计器......................................100.............表单服务器......................…….101.............表单服务器和门户系统之间的协同工作…………………101.............表单信息共享的实现……………………101..............离线填报的实现……………102..........表单人工调整与美化………102............3.13.资源管理与配置………………………102..3.13.1.主要用户及用户管理需求………103..........平台主要用户………………103..........用户管理需求………………105...........统一用户认证…………………….集中分布式授权……………106..........统一用户信息管理…………106...........提供人性化服务……………106..........3.14.2.基于角色的用户授权……………110.........3.14.3.基于用户信息的认证……………110.…......3.14.4.基于用户特征的个性化服务…………………110...........3.14.5.公共资源配置平台的引入………111.........3.14.6.功能框架及描述………………112........3.16.统一日志管理设计……………………1.14....3.18.统一监控管理设计…………………1.15….......3.19.统一备份管理设计…………………115........4.各子系统技术方案……………4.1.组织机构与权限管理系统…………116.........4.1.2.供应商管理………………………117.........4.1.3.中心用户管理……………………117.…4.1.4.采购用户和供应商帐户管理……………………117..........4.2.WER2.O门户系统……4.2.1.多种浏览门户视图………………120.........4.2.2.信息共享和抓取………………121..........4.2.3.系统管理………………122......4.2.5.领导信箱………………4.2.6.业务论坛……………………4.2.7.网上公告…………125..........4.2.8.信息资源库………………………125.........4.2.11.流量分析和系统监控子系统……………………128...........4.2.12.领导决策子系统………………133..........X敏感字过滤………………………133..........4.3.1.协议供货………4.3.3.小额采购…………137..4.3.6.网上申报采购计划………………139.......4.3.7.项目委托…………140..........收文管理………………………140...发文管理………………………141..........公文督查………………………142..........4.4.2.档案管理…………143..........4.4.3.信息管理………….会议管理…………145.........内部会议………………………145....外部会议………………………146............领导会议……………………146...........会议室管理…………………147............4.4.5.办公事务子系统…………………147...........日程安排…………147......文件管理………………………任务交办…………148.........通讯录……………148..........4.4.6.邮件管理系统……………………148......4.5.电子辅助招投标系统…………………149........4.6.跨平台FLEx综合应用客户端…………149.......应用安全设计………………………5.1.系统安全目标、策略与建设原则……………………151..........5.1.1.系统的安全目标…………………151...........5.1.2.系统的安全策略…………………152...........5.1.3.系统安全建设的原则……………152........5.2.安全体系的建设 5.2.1.基本安全防护系统 5.2.2.网络信任服务系统 5.3.1.安全服务 5.3.3.访问控制服务………………………156........5.3.4.数据保密服务………………………156.............5.3.7.禁止否认服务……………………158............加密机制………………………158............数字签名机制…………………1.59.......访问控制机制………………1.59........数据完整性机制………………160.......交换鉴别机制…………………1.60..........5.4.网络平台安全………………………161..........5.4.1.防火墙系统………………………161..........5.4.2.入侵检测系统……………………162..........5.4.3.防病毒系统………5.4.4.虚拟专用网(VPN)……………163...5.5.数据库安全……………164...........5.5.1.数据库系统安全与保密的特点………………1.64............5.5.2.数据库系统的安全措施…………164........5.6.异地容灾系统及备份策略……………166.......需求分析小载采劈期上申播外部商机构接入渠道层行政办篆统公共构件蒸筛采购业务系统外部政府机构息素统船酸标年白基理平的通信平台口P年台校换1.1.业务需求采购平台信息资源与业务密切相关的特点要求平台信息资源整合方法应适应采购业务和信息的动态产生和变化。采购平台信息资源目录体系就是从业务应用出发，梳理业务办理的流程、职责、依据等，编制信息资源目录。如针对采购单位、供应商登记注册业务，需要通过调查和梳理相关的业务环节和部门根据业务流程，梳理和分析业务相关的信息，并且根据相关的采购信息资源描述规范和分类规范描述以及标识信息资源，编制基于业务组件的采购信息资源分类目录和共享目录，在目录体系的基础上进行各类采购信息资源整合。这样的整合方法为采购信息资源的动态有机整合建立了基础，可以适应采购信息随业务处理而动态变化的特点，同时通过目录编制明确了资源提供者和共享部门，为政府采购信息资源的整合和共享建立长效机制提供一个基于业务组件的可持续发展数据交换平台能对需求进行针对性和全面的响应，同时，根据业界的经验和我们的最佳实践，我们建议按业务功能划分，分为如下几个从业务逻辑层面上看，除了前面提及的用户的几种角色(采购单位用户、供应商用户、中心用户、系统管理员用户)外，平台系统会提供用户基本的注册、修改、权限分配、用户待办任务提醒的功能外，系统还将对平台用户按组织机构进行分组来模拟真实世界的组织机构管理。通过将权限赋予角色、将角色赋予组织机构的策略。采购系统这部分是系统的核心部分，涉及到整个采购流程，并且这部分的业务复杂、子系统繁多，应该给予足够高的关注度。整个采购系统可分为如下部分：图5.5.2-1采购系统图通过我们积累的经验，这部分的各个功能点梳理如下：协议供货部分投标系统投标系统的业务流程主要为：投标商申请一—中心用户审批一一供应商应标的流程，涉及的业务有：采购厂商资料上传招标文件、中心用户产品参数搜集、中心用户审核、供应厂商对所供应的产品的信息录入、参数提供，并打印采购厂商的招标信息一览这部分的业务流程需要中心用户的大量参与，平台提供方便可靠的功能供中心用户进行供应厂商的入围评定。业务流程梳理如下：审核供应商一设置打分轮次和打分栏目一>初审一一入围评审业务需要打印入围供应商名单。公告板系统公告版系统主要以信息查询为主，提供及时在网上公布中标的产品信息、供应商信息和厂商总协调人信息。除了提供采购单位和供应商自定义的查询浏览机制外，公告板系统提供产品的横向、纵向对比、产品价格曲线图、提供产品评论和参考价格、产品降价排行、产品销售排行等功能，并能对查询的公告结果进行转储和打印。后台管理系统后台管理系统主要向中心用户提供业务上的管理流程，它能方便的管理采购方、供应方和需求采购物资之间的联系。首先以中心用户发起查询，平台提供采购、供应、物资之间的关系图表，方便中心用户及时跟踪具体某条采购工程的进展情况和采购单位、供应商的历史记录。合同验收单系统这部分的业务主要由采购方发起，流程梳理为：采购方联系某供应商—一供应商浏览采购信息—一供应商填写产品信息—>采购方进行采购一>系统生成电子签收单汽车采购空调采购两者的业务逻辑非常相似，即：都是针对一类商品的专门的采购平台。流程梳理如下：采购方填写采购委托书——中心用户审核委托书一—提交指定供应商一—供应方填写产品信息一>生成电子验收单一>中心用户审核验收单一>生成合同信息->采购人打印验收单二次竞价这部分的业务流程涉及到“竞价”的业务内容，由中心用户制定竞价规则，供应厂商参与竞价，最后通过平台系统公布竞价结果。批量采购批量采购的业务主要针对数量总数较大的某一类或某几类的产品的采购活动。流程梳理采购方征求意见--中心用户审核意见一一供应方答复征求意见一—采购方发布公告一>生成委托书一>中心用户审核委托书一>供应方报价一>采购选择供应商一>中心用户审核网上竞价部分供应厂商通过本平台，进行价格竞争，由平台系统裁定中标供应商的方式。流程梳理如采购方下单一—中心用户审核—一供应商报价一—采购方选择中标供应方一—中心用户审核一一供应方打印验收单小额采购部分这部分的业务只针对较小规模的采购，因此使用这部分平台业务只分为两类：中心用户平台：提供中心用户登录，进行采购的管理。用户平台：采购用户和供应用户均属于用户平台。小额采购的结束标志为：系统生成验收单。定点采购部分根据各种不同的采购项目，系统定制出的各种采购平台：家具、印刷、电梯、汽车、监理等专有平台。信息统计部分对系统的各类用户均提供数据的查询、统计分析和比对的功能。网上申报采购计划部分这部分的业务逻辑主要针对采购方进行，由采购方填写采购需求，中心用户围绕这部分需求进行审核。项目委托部分业务办公系统此部分业务功能主要面向中心用户，贯穿中心用户所有的日常工作和业务流程，实现中心内部OA办公自动化系统。电子辅助招标系统主要有采购人设计标书、应标人填写标书、CA认证加密标书、定时开标、电子评标等功能，和业务办公系统、公告板进行数据交换。其他系统要样系统要样系统即的道开系境短偿平台系续系烧数器续文壹系统变淘验收单真伤阐上测序图表5.5.5-1其他系统图如图示，其他系统囊括了系统比较多的功能点，这些功能点为系统提供着非常丰富的业务功能和用户体验：网上调查：提供供应商和商品的网上调查功能，方便平台用户多方位的了解商品情况和采购信息。取回密码：提供多种密码找回的途径，包括邮件通知，短信通知，传真方式等等非人工干预的方式帮助用户找回丢失的登录密码。文件下载：平台系统通过提供海量存储的文件服务器对用户提供文件的上传下载功能。文件下载的格式涵盖目前流行的多种格式：Excel表格文件、Word文件，CA证书文件，同时还提供音频和视频文件的下载。查询验收单真伪：提供采购验收单真伪的查询，保护采购业务的法律法规，对伪造的验收单，平台提供举报功能，方便采购中心人员汇总和查处。中介机构抽取及费用计算：根据采购业务提供费用计算的小功能，让用户对中介机构的费用情况透明可见。主任信箱系统：特别提供用户与采购中心主任直接对话的功能，用户可以直接通过平台向中心主任反映信息，中心主任通过信箱及时反馈给用户关注的信息。短信平台系统：定阅此功能的用户能在第一时间收到来自平台发布的最新采购信息。即时通讯系统：平台用户可利用此功能跟在线用户交谈，商榷采购事宜，或以离线的方式发送留言。邮件系统：用户可用通过自己的帐号登录进平台的邮件系统，收取采购新闻或各种订阅的采购公告，或与其他用户取得联络。此外，平台还将提供：文章系统、考勤系统、办公用品申领系统、轻松采购系统和服务热线电话记录系统。1.2.功能需求电子化采购招投标平台是采购信息化总体框架的重要构成部分，其核心的采购信息资源目录层、商品信息资源共享层在整个框架中具有非常关键的承上启下的作用，能对数据目录、应用目录、服务目录、用户目录及相关元数据库的统一管理，实现对各类采购信息资源的逻辑管理，并通过目录服务、导航服务、数据交换服务、安全服务等为上层应用系统和门户获取所需的资源提供各类统一的基础支撑服务。所以，在建设采购平台的时候，要把这个设计放在总体框架中，充分的考虑其在政府采购信息框架中的位置以及与其他电子政务构件进行整合的设计，避免使用纯粹为实现某类特殊的采购业务进行构架。电子化采购招投标平台包括工作业务流、数据表单定制、用户权限管理、日志数据管理、统一消息管理、数据分析与报表处理、平台监控管理、CA接口等几个部分。工作流引擎通过对工作流管理工具定制的流程进行解析，自动判断采购流程进行阶段，需要使用什么表单、绑定什么数据、具有什么数据和功能权限、需要关联什么图层等，同时在业务处理过程中，需要能察看和监控流程的运行情况，并智能判断流程走向，同时要提供痕迹管理工具，保留每次业务处理过程的痕迹。业务处理过程中，可能需要会审，系统要提供工具迅速准备资料，供平台系统调用。业务处理过程中，可能需要引入各种相关资料，需要支持电子签名、扫描仪、等多种外部设备。业务处理过程中，可能会产生各种函件，系统需要能自动引入OA系统，完成文件处理过程，并能通过邮件等多种方式完成函件的处理，并建立函件与业务的关联。电子表单定制采购业务流程过程中会产生许多电子表单，因此，不能分散的去设计，同时采购平台各项业务事项的表单结构都比较复杂，内容较多，如果不能够自动生成数据库，则手工设计数据库的工作量较大，因此，需要提供表单设计工具能够根据设计的表单内容自动生成数据库结构，当修改表单时，可以同步修改数据库结构。因此，系统平台要实现系统运行时，用户填报的数据自动校验，自动进入数据库的功能。简少系统的编程开发工作量，提高系统方案的可实施性，也便于系统维护和升级。多视角平台门户展现方式平台门户网站除了提供基于浏览器的访问方式外，还提供客户端展现方式，方便用户进行即时通讯和业务的离线处理。另外，随着3G时代的到来，现在互联网上的许多应用都可以移植到将来的手机上，未来的手机将会是多媒体的终端。而作为浏览互联网的必备软件手机浏览器无疑是手机终端中最重要的应用之一，因此平台专门提供针对智能终端(手机、PDA等)的用户进行的门户信息浏览，做到同一套服务，多种展现方式。报表定制使用平台提供的功能，能轻松自定制各种采购报表，不需要代码的编写和开发人员的维护，有中心人员在报表定制模块里通过对平台预定义的报表进行鼠标拖拽即可完成报表的定制工作。此项功能与工作流引擎相结合，能产生非常强大的功能：根据业务流程的执行，自动展现给用户需要填报的电子表单和打印统一定制格式的报表。利用目前系统的CA认证模块，采购平台系统将与CA证书相结合，来增强平台的安全性，通过CA服务器的安全身份认证，以实现单点登录、定时身份检查和智能权限判别。同时做到能极大限度的重用目前系统的CA模块，实现对采购平台的用户不重新颁发证书，让新旧系统平稳过渡。用户权限管理对用户的权限进行维护管理，主要包括保证用户身份信息采集的持续性、正确性、一致性等的管理规范；对用户所属机关单位的信息进行存贮、信息备份、信息使用等方面的管理规范；对信息指标登记、信息指标变更方面的管理规范。对技术平台的运行维护机制，主要包括对平台运行状况的监测、系统维护、设备维修、系统改造等活动的管理规范。对业务服务的管理规范，主要包括用户注册申请、开通冻结用户使用权限、用户权限配置、用户身份注销等活动的管理规程。对岗位职责的管理规范，主要包括岗位的设置、职责、考核等管理规范。统一日志管理日志管理的功能主要包括：用户访问记录：平台用户对平台的访问均有记录可查，包括访问时间，访问模块和操作步骤，以提供平台中心用户进行数据分析。采购流程历史记录：中心用户操作记录：对中心用户人员进行记录监控，包括采购审批的流程，采购流程定义情况，考勤，用品申领平台系统运行报告：提供详细的平台运行的图表，标识出访问量的高峰期和系统资源的变化情况。统一消息管理为了使整个系统能够有效率的运行，保证相关的业务信息能够及时传达，系统应当实现消息派发。该功能是全局服务的功能，主要负责向流程中的具体业务的处理人员发出通知，提示相应人员完成相应业务。统一备份管理平台系统提供数据备份服务。备份是保护数据的最安全的方式，对于在将来的某个时候如果发现需要某历史数据，假如没有备份机制，将是不可想象的。我们将得不花费大量的时间去重建历史数据。所以历史备份也是保证数据安全至关重要的一环。因此平台除了提供数据的整体备份功能外，还将提供对用户操作步骤的及时备份，以便出现错误时能及时回退到即时通讯服务平台消息服务提供即时通讯的交流工具，实现交流工具和系统内部用户身份的绑定，和消息群发功能。数据分析与数据挖掘统计分析是对现有的数据进行统计，从中提取有用的数据以各种直观的分析图形进行显示。统计分析还应当对于分析的结果进行科学分析，提出相应建议。科学分析的依据来源于在系统运行中对各种业务数据的提炼加工。统计报表是本系统的重要内容，系统将提供固定报表和自定义报表两种方式，固定报表根据固定格式的表样，做好后直接挂进系统，自定义报表是提供工具供用户在使用过程中自己定义报表，自己定义好的报表经过注册后可以成为固定报表。因此，平台系统提供：提供B/S结构的报表设计器报表工具类似于Excel工具统计报表可以发布平台监控管理平台监控管理可以分为以下几类：关注监控：根据用户需要，对其关注的业务进行监控；指标监控：根据业务规律，通过对数据库数据指标化，实现监控；状态和时间监控：数据库字段值等于或达到指定值，实现监控。业务督办监控：每一个业务流的每个阶段都有各自对应的完成时间，一当某个业务因为由业务人员疏忽或遗忘等原因而导致的业务滞办，系统将及时提供任务催办/督办监控基于业务规则的监控：有些业务有着明确的业务规则，政府采购平台系统涵盖了大量的业务规则与业务逻辑，此时系统应提供有关业务规则的监控信息。1.3.1.软件安全需求系统中使用的软件主要有操作系统、数据库管理系统和应用软件。作为一个大型的应用系统，必须有严密、周到的安全保护，才能保证整个系统不被人为破坏或非法使用。而服务器操作系统、数据库管理系统是应用软件运行的基础平台，它所提供的各种安全功能直接关系到应用系统的安全。所以，提供安全的支撑平台，是保障全系统安全的重要措施。1.3.2.操作系统安全需求1)操作系统的安全等级达到C2级。2)能够通过对主体(人、进程)识别和对客体(文件、设备)标注，划分安全级别和范畴，实现由操作系统对主、客体之间的访问关系进行控制。3)必须能够按照制定的安全审计计划进行审计处理，包括审计日志和对违规事件的处1.3.3.应用系统安全需求在系统安全等级必须达到二级标准(系统审计保护级)的前提条件下，平台提供如下系1)在用户注册之前，应用软件本身必须对当前的运行环境进行一系列的合法性检查，如果软件系统本身的配置数据被改动，系统要拒绝该用户注册。2)应用软件必须提供一种或几种有效的加密方式(算法),对敏感数据库的存储进行加密处理，以使得在其它任何软件环境下都无法对数据库内容进行窥视。3)应用软件对每一位使用应用软件的操作人员，都要验证其身份和权限。4)对系统对外提供的接口必须有统一的格式规范，接口传输的数据全部通过CA证书签名加密，同时对数据进行保留底稿。1.3.4.数据传输安全需求由于平台运行于Internet环境，通过HTTP协议提供用户于平台的访问途径，总所周的数据进行监控，篡改，以达到自己的目的。因此必须加强平台数据传输的安全性。例如：尽量使用Post方式向后台传递数据，不让传递参数暴露在url链接地址栏中，对每次Post的数据都要做签名加密，并且保留在数据库中，对数据库的操作语句SQL不出现在页面源代码中，并且后台的操作使用成熟的OR映射工具和数据集成框架，抵御黑客的SQL语句1.3.5.数据存储安全需求1)必须能够通过对主体(人、进程)识别和对客体(数据表、数据分片)标注，划分安全级别和范畴，实现由系统对主、客体之间的访问关系进行强制性控制。2)必须具有增强的口令使用方式限制，用户必须按规定的格式设置口令，才能进行注)能够按照最小授权原则，对数据库管理员、软件开发人员、终端用户授予各自为完成自身任务所需的最小权限。4)必须能够对与数据库安全有关的事件进行跟踪、记录、报警和处理，供有关人员进行分析。5)数据库管理系统本身的安全等级达到C2级。从三个方面提出共享库建设的安全需求：、用户的安全性系统提供和交换平台中用户认证层的接口连接，来保证用户的身份安全和访问安全。一是身份安全，只有经过身份认证的合法用户才能对系统信息资源进行访问，这通过用户认证层来保证；二是访问安全，经过了身份认证的合法用户只能读取被授权访问的信息资源，这通过信息资源目录系统来保证。2、数据自身的安全性数据对于共享库来说，是最基础的要素，它的安全性对整个系统的正常运营、使用起着重要的作用，因此系统要提供对数据库自身内容的安全备份和恢复功能，保证数据的准确性、3、应用程序的安全性采购平台业务应用系统通过用户认证系统、信息资源目录系统对共享库系统的数据访问进行安全保护。用户认证系统保证用户身份合法，信息资源目录系统保证用户信息授权访问合法，经过身份认证和授权验证，共享库数据可以通过服务形式返给应用程序。1、实现数据异地备份平台系统采用数据异地备份的策略，通过磁带机定期为生产环境数据库中的数据进行定时异地备份。数据备份采用热备的机制，保证平台生产环境数据在备份期访问控制安全需求信息的保护是在对系统中主体(人)和客体(信息)进行正确的标识与标注的基础上，通过实施主体对客体的访问控制来实现的。信息安全的需求可以分别从用户(主体)权限管理、主体对客体的访问控制以及数据的安全三个方面来定义。1)系统必须能够为用户分配用户标识符UID,并保证用户的唯一性。2)系统必须支持用户的分级和分组管理机制。3)系统必须能够提供可靠的用户身份认证手段。4)权限管理必须满足最小授权原则，使每个用户和进程只具有完成其任务的最小权限。5)系统必须能够支持主体和客体之间的多种对应关系，并提供灵活的调整手段。6)系统必须能够提供包括用户名的识别与验证、用户口令的识别与验证、用户帐号的缺省限制检查等多道安全检查。7)系统必须能够支持按照自主访问控制规则对用户进行访问控制，即按照用户与被访问对象(文件等)的关系来决定是否允许访问。8)系统必须能够支持使用强制访问控制规则对用户进行强制访问控制检查，即根据该用户在多级安全模型中所具有的安全属性(等级和范畴)、本次访问操作所涉及的客体(如文件)在多级安全模型中所具有的安全属性(等级和范畴)来确定这次访问是否被允许。9)系统必须能够防止用户经过被允许路径以外的其它访问路径，屏蔽某些越权的非法10)系统必须能够将主体对客体的每一次访问记录在日志文件中，并提供分析和审计接口需求本系统的软件接口包括与外部信息系统的接口及系统内部应用软件与系统软件之间的接口。与原有信息系统的接口需求系统必须与已有的相关系统协调运行，或取代或无缝集成。即实现各个系统间数据的集成共享，和功能的相互调用。与系统软件的接口需求系统与操作系统和数据库管理系统等系统软件的接口应满足以下需求：1。客户端的应用系统必须能够跨操作系统平台工作。2。系统必须能够支持指定数据库管理系统、安全软件以及其他相关的中间件。3。系统必须全面支持XML数据格式。提供二次开发数据接口制定标准，可用插件或WebService的方式应用扩展服务和对外数据提供等服务。前期准备与建议前期准备需要采购中心人员提前准备好业务相关的文献资料，确定接口人员，方便项目组能够有翔实的业务资料可以查阅，确定系统的业务边界。同时需要采购中心人员准备前期系统的构架图和网络拓扑图，以便区分各个现存子系统的逻辑关系。结对编程通过上述对采购平台的总体的需求分析，需要对项目复杂的业务流程进行梳理和再造，我们建议采购中心安排工作人员与项目组一起，通过“结对编程”的方式，与项目组实施人员进行搭档开发，保证需求的实时性和完整性。同时也方便业务信息的交流和反馈。总体设计方案本节主要内容包括：系统建设的指导思想和主要原则根据总体设计的思路，得出系统的总体结构系统所用到的关键技术系统接口和安全性设计有关开放性、可扩展性和灵活性等方面的设计以及系统设计的合理性根据系统设计，给出系统软硬件和系统集成、部署方面的建议2.1.指导思想率、降低采购成本，实现采购业务管理的科学化、规范化、法制化和现代化。总体设计要做到面向全局、面向整个系统、面向未来，用系统工程的思想方法把握全局。系统总体设计以需求为牵引，注重科学性、实用性、先进性、可扩展性和安全性，做到系统的一体化设计和信息资源的集成化管理，在遵循“总体规划，分步实施，分阶段建设”的过程中，不仅能支持现阶段的建设目标，还必须能在此基础上不断扩充完善，使之与后阶段的建设共同形成一个统一的整体，实现系统的总体战略目标，并最终逐步实现政府采购全流程电子化。现阶段的系统设计是以全局为出发点，“以业务为导向，以数据为核心，以集成为重点，以应用为目的”作为总的指导思想，统筹规划，严格管理。并采用面向对象、面向服务、UML、Ruby、Rails、EAI、组件化和构件化等先进技术和方法，做到技术先进，系统完整，架构统一，结构开放，可扩展性强、跨平台应用和网络安全。设计原则经济性原则系统的建设必须坚持在现有软硬件设施的基础上进行，充分利用现有网络资源、硬件设备、软件、人力资源和数据资源，确实考虑经济与成本的关系，选择高性价比的系统。尽量采用成熟开源产品，实现政府和公众利益最大化。实用性原则坚持以需求为导向，充分了解用户需求，系统设计人性化、专业化，符合用户日常习惯，易于操作、易于使用、界面友好，所有用户不培训或只需少量的培训即可使用。系统有相应的防呆措施，帮助用户避免操作上的错误。系统上所使用的所有词汇、语言要求简单明了、无歧义。语言表述和术语表达符合相应此外，系统还必须预留灵活、方便的配置方式，可按照具体的需求快速地定制新的应用或修改现有应用。易用易管理性原则界面友好统一，充分考虑操作人员的特点，使数据处理工作简单、方便、快捷。业务流程清晰，符合常规业务处理习惯。系统面向掌握不同计算机知识层次的人员，特定设计，以便容易操作使用。无须编程，业务人员就能进行采购业务及办公业务可视化定制的要求。易维护性原则系统必须提供良好的接口和完善的技术文档支持二次开发，系统开发高度模块化，方便项目交接。同时提供方便的技术支持，包括在线帮助、用户手册、管理员手册等。先进性和前瞻性原则系统所有组成要素均应充分地考虑其技术的先进性。只有广泛吸取国内电子商务和电子政务系统建设方面的成功经验，将当今世界先进、有发展前途的技术和实际应用相结合，采用目前先进而成熟的技术及设备，同时，开发或配置先进、高效实用的系统软件和应用软件，使系统建立在较高的起点上，使整个系统能协调一致地运行，才能获得最大的系统性能和效信息技术发展非常之快，软硬件更新换代迅速，在系统的设计中要有超前性，必须充分考虑技术的发展趋势。同时在硬件配置和系统设计中还充分考虑系统的发展和升级，使系统具有较强的扩展能力，处于应用系统技术领先地位，并符合当今计算机科学的发展潮流。成熟性原则应用系统设计必须符合实际需要，充分利用成熟的先进技术，选用成熟产品或成熟模块，避免把该系统当作“技术试验田”或“经验探索地”,还要避免盲目追求最新技术，以防止因应用系统在设计上的缺陷而造成系统处理能力不足等严重缺陷。开放性和可扩展性原则系统总体方案设计在体系结构、软件平台的确定方面，从选型到设计、开发都要充分考虑“标准和开放”的原则。在应用系统的设计与开发方面，要遵循国际或业界标准，依据标准化和模块化的设计思想，在此基础上建立具有灵活性和开放性的应用支撑平台。尽量采用标准化的开源产品，彻底的满足开放性和可扩展性的原则。安全可靠性原则安全性是政府采购系统建设的一个重要原则，在整体设计和系统有机集成的同时，对安全性和可靠性要有统一完整的考虑，要有完善、周密的安全体系，具有安全可靠的加密手段和加密方法，要能够支持基于证书和SSL、基于PKI平台、采用电子印章技术等多层次的安全解决方案，利用严密的身份验证、访问控制、数字证书、数字签名、多层次的保密手段等措施，可以有效的同现有CA系统集成，从物理、传输、网络、应用等多方面多层次保障系统和系统中传输的数据的安全和防篡改。同时，作为政府采购系统，必须保证信息流转和发布的严肃性、准确性和安全性。规范性原则质量管理体系或CMMI软件成熟度管理体系的要求和规范。系统的开发要从需求分析、概要设计、详细设计、编码、系统测试到正式运行的全过程，遵循软件工程规范的要求，提供详细的开发文档以供备案待查及二次开发使用。整体性原则系统的设计开发要体现面向政府采购应用需求的整体解决目标，各系统之间必须实现安全的无缝连接，在统一的应用支撑平台上整合统一的应用系统和数据资源，形成一套完整的、体现采购中心特色的政府采购系统，要做到整体规划、分布实施。设备和技术的先进性和成熟性原则系统平台所采用的设备和技术一定要体现成熟性和先进性，成熟性是指技术稳定、用户多、推广使用的时间比较长；先进性是指选用的产品和技术是目前市场上的主流技术。2.3.设计思路根据本项目的建设目标，在系统总的指导思想和建设原则的基础上，我们认为本项目的系统建设可以从以下几个方面入手：以框架为基石、以业务为主线系统建设应该采取“制定规范——搭建框架——业务开发——系统集成”的建设模式，在这其中“制定规范、搭建框架”最为重要。具体的建设模式如图所示。数据规范2畏终集成图6.3.1-1开发模式采用这种模式是出于以下几点考虑：系统建设涉及的众多数据、业务、子系统。要实现一个统一的系统必须制定完善的规范，以此作为项目开发的准绳，才能规范整个系统的开发和实施。规范性和整体性原则的招标要求也充分得到体现。系统建设是一个不断发展完善的过程。系统建设要总体规划、分步实施，分阶段建设，需要建立升级改造工程与第一期工程良好的衔接关系，使系统成为一个统一体。这就要求在升级开始阶段必须搭建一个好的承上启下的整体框架，能够满足业务和功能不断的调整和扩展，并使后续工程的实施能够而且必须在整体框架中进行，这个整体框架就是基于Ruby的工作流引擎，表单报表定制，ESB企业总线等中间件支撑平台。系统业务范围广、种类繁多、业务关系要求可变化。系统将涵盖整个采购中心业务和办公自动化，业务种类繁多，子系统类别跨度大，许多业务还包含子业务，不同业务之间还相互关联，而且系统开发的首要任务就是满足用户业务提升的需求。系统开发必须紧贴业务，对不同的业务既要展开有针对性的开发，又要抽象出业务的变化规律，把现有一期的定死的业务系统无缝迁移到升级改造后的可灵活调整的工作流引擎系统上。不同的业务通过业务流程管理和数据交换，实现数据共享与业务集成，从而组成有机的整体。系统最终面临集成问题。这包括系统与已有系统的集成、本次升级项目与后续阶段建设的集成、系统与其他机关、单位外部系统之间的集成等。为此，我们采用首先搭建框架，在框架中解决集成接口的问题，不同的业务通过框架接口与外部交互，不同的系统间也是如此，从而统一了业务间、系统间的交互界面，简化了系统的接口工作。系统建设模式中，“制定规范、搭建框架”是最重要的一环，这是因为：框架对不同业务有隔离作用。采用框架结构可以降低个别子系统出问题对整个系统的冲击，框架是将不同子系统区分为公共部分和私有部分，通过对公共部分的提取，形成业务运行的基本支撑环境，而将不同子系统特性放在私有部分，实现与其他业务的隔离，这个个别子系统与模块的改变对整个系统的影响是局部的。不过，框架的设计好坏影响是全局性的。框架是系统集成与数据共享的关键。系统的不同子系统，系统与已有系统，现阶段升级建设与后续工程，系统与外部其他系统都是通过框架与整个系统集成的，因此框架的好坏直接决定了系统的灵活性、可扩展性和集成性。框架是系统不同业务的公共运行环境。框架的功能与健壮性，将为系统业务的运行提供强有力的基础。同时良好的框架结构对业务开发具有指导作用，可以降低了业务开发的工作量与困难程度。2.3.1.以数据为核心，对数据进行统一管理数据是系统生存的基础，是系统具有有生命力的保证。在系统建设与实施过程中只有充分重视和考虑业务数据的标准和规范性，建立起业务数据生产、更新和维护的规范机制，才能保证数据的开放性和交互共享性。因此整个设计将围绕数据进行——数据标准、数据存储、数据交换、数据处理等等。由于系统数据是海量的，涉及到采购方数据、供应方数据、代理商数据、商品信息数据、项目信息数据、标书数据、规范数据等文本与非文本数据信息，这些数据具有不同特点，其中的关系十分复杂，数据在系统建设的过程还将不断的扩充、变化，因此必须建立有效的一体化数据模型，对数据进行统一管理，才能保证框架的稳定性和系统的可扩展性。管理数据人员机构资产库库其它数据项目数据图6.3.2-1系统数据间的关系业务数据关联关系OA数据数据图6.3.2-2系统数据类型间的关系我们可以将如图6.3.2-2“系统数据类型间的关系”系统数据间的关系所示的各种数据简单的划分为三种类型：业务数据、OA数据和管理数据。业务数据包含整个采购系统涉及到的所有数据，例如人员机构、商品库、项目数据、标书模板库等等。OA数据包含日常办公，资产管理等数据。管理数据包含系统日志数据，系统权限状态管理数据等等。业务数据之间通过属性字段与其他业务数据建立关系；管理数据也可以通过属性字段、存储过程、触发器等数据库方式建立起相互关系。我们仅注意这些数据本身和数据内部的关或三者间的关联关系，这样使得OA数据和业务数据紧密结合，随业务管理的规则，达到标前、标中、标后的数据标准、流程统一，实现内部办公和外部业务处理的完全整合，实现所有数据和流程一体化。例如：采购验收完成的协议供货商品自动入库。这样即可以帮助划清不同业务之间的边界，又可以方便业务之间的数据共享与系统集成。另外，一体化的数据管理还有助于数据的维护与更新，分发与共享。2.3.2.框架跨操作系统平台，应用与设计无关，表现与业务分离根据系统的特点，系统将采用以B/S为主的方式为客户提供服务，同时提供C/S方式的综合客户端，完成例如：即时通讯、离线投标、标书上传、相关控件安装、邮件收发、待办任务提醒、短信平台接口、视频会议、文件传输、网络电话、服务热线电话记录、自动更SOA架构确定了系统的骨架，是业务运行支撑框架，使得各种不同的组件能够有序地组织，并以此为纽带，按照EAI框架提供的系统集成的基本规范，将不同的产品进行整合，并通过业务总线和数据总线，实现系统数据和业务的集成。Ruby语言本身具有良好的跨平台性，EAI又具有很强的产品整合能力，这样的框架是系统长期地稳定和优良的可扩展性的保证。满足招标文件建设目标的“技术上完全开源、跨平台，实现自主创新”的要求。系统框架跨平台，还表现在框架与产品的绑定是松散的，不受具体产品的限制。系统必须考虑到集成环境的复杂性，框架应该建立在众多可选产品所必须具有的基本功能的基础上，是多个产品的共性，尽量避免采用某个产品特有的功能，完全避免采用商业专有技术，这样可能导致系统对某个产品产生依赖，从而影响系统的集成与扩展。因此，系统框架能够支持多种Ruby应用服务器、数据库和门户系统等产品。例如：系统框架既能在开源的Apacheweb应用服务器上运行，也可以在性能更好的Lighttpdweb应用服务器上运行。数据库可以采用开源数据库产品MySql。系统设计过程中始终贯穿定制和可配置的思想。从数据库设计上，将系统所用到的管理数据与业务数据分离出来，业务数据通过管理数据定制出来，这不仅表现在业务表单、业务报表上，而且表现在业务处理流程、数据交换流程等方方面面。这样定制出来的业务具有很强的灵活性，不需要修改程序就可以实现对业务表单、业务流程的修改，不仅提高了系统的适应能力，降低系统的维护成本，而且可以使业务人员更专心于业务的处理，不必顾及技术的设计。另外，在系统中广泛采用可配置的参数进行管理，实现逻辑和数据的分离，也有助于提高系统的灵活性和系统的应变能力。例如：通过对系统运行参数的进行配置来改善系统的性能，适应不同的负载需求。业务流转条件采用参数化的配置可以适应业务规则发生的变化等等。可配置的管理方式，为系统的随需应变奠定了基础。一个好的用户体验不仅要求功能上能满足用户的需求，而且在表现上也能遵循用户的使用习惯，满足用户个性化的需求。系统用户种类繁多，不同用户群所关心内容有很大的差异，例如：领导用户关心是总体的宏观的信息，而具体的业务人员关心的是办理的具体某个案件的信息，即使同一类型的用户在使用习惯方面也是不尽相同。好的设计能够处理好业务功能和个性化需求之间的关系。系统采用多层结构，将业务逻辑和表现分离出来，这样能够有针对性地处理不同用户的需要，又不至于影响整个系统的功能实现，而且还可以通过门户和界面的配置来满足用户的个性化需求。2.3.3.“微内核”+“插件”的结构，促进多种技术集成系统建设需要将多种技术融为一体，共同完成系统的建设目标。系统设计不仅要考虑不同业务不同功能间的集成之外，还应该考虑不同技术间的集成。例如系统业务涉及商品信息、采购及竞标流程和资源管理等方面，要完整地实现这些业务功能就必须实现OA和采购业务的集成。系统框架采用“微内核”+“插件”的结构，将绝对必要的功能封装为系统的内核，其他功能则依据扩展接口核规则，通过插件的方式提供，降低组件间的耦合度，在更高的层次上实现软件复用，有助于提高系统的兼容性、扩展性、灵活性、可靠性和网络支持，实现软件的无缝集成。兼容性：微内核中只包含绝对必要的功能，这些是通用的和最基本的，具体功能的实现必然要利用已有的产品和研发成果，一个好的产品必然是建立在这些通用和最基本的东西之上的，这种结构能够兼容更多的产品。扩展性：内核只提供机制，而把实现策略留给插件。可以根据接口，通过开发插件的方式来解决操作上的不便或增加一些功能。实现真正意义的“即插即用”的软件开发。灵活性：系统更容易通过插件组装进行功能定制，根据需要选够功能插件，定制软件的界面、操作流程，使系统具有伸缩性，满足用户的个性化需求。可靠性：体积较小的内核可以得到更多的测试，使系统骨架更加稳定、健壮。大部分功能都是采用插件实现的，插件与内核之间有隔离，所以一旦发生故障不至于导致系统的崩溃，避免出现“牵一发而动全身”。网络支持：微内核设计基于消息传送机制，所以能更容易支持网络通信，适应分布式的应用环境。另外，采用这种“微内核”+“插件”的结构，也有助于实现系统的分阶段实施，在第一阶段开发出来框架和接口机制，后续阶段需要对功能进行完善或增加新的功能，只需要通过对插件的局部修改和开发新的插件就可以实现，而且，插件提供的标准化接口，也能帮助用户进行二次开发。2.3.4.借鉴成功的案例，采用工业标准和成熟的主流和开源产品系统建设应该以成熟的应用和技术为基础，紧跟主流的信息技术，这样才能保证系统的稳定性、先进性和成熟性。系统采用的许多技术，如：工作流引擎、ESP、XML、SOA等都是基于工业标准，在业内得到广泛的应用，技术上已经非常成熟，资料齐全，队伍庞大，有较多的成功案例可供参考，保证了技术的先进性和稳定性的有机结合。系统选用的服务器、网络设备等硬件，以及应用服务器、数据库管理平台、中间件平台以及OA等软件皆为业内主流的平台，具体见本节后续部分(参见6.10软硬件配置建议)。这些成熟的产品经过市场的检验，在性能、接口、技术上都经过实际应用的测试，有许多经验可以借鉴，可以缩短系统开发的时间，降低开发风险。在业务建模方面，充分利用我公司已有相关案例的成功经验，尤其是财政部中国政府采购网项目的经验，总结和深化了许多业务模型及关键技术，通过多方案的比较和中和分析，在充分认证的基础上来进行系统设计。总之，充分借鉴现有的成功案例，采用工业标准、电子政务标准和成熟的开源主流产品及我公司自主研发产品，系统建设将不存在关键技术上的风险，为系统实现建设目标提供有力的保障。2.4.系统总体结构通过对招标文件的理解和系统初步的需求分析，根据我们的建设思路，提出系统的总体结构，我们从逻辑结构、网络结构和功能体系三个方面进行描述：总体逻辑结构系统的总体逻辑结构如图6.4.1-1所示，将系统划分为五个层次(基础设施层、数据资源层、中间件支撑层、业务应用层和用户服务层)以及标准和规范体系、安全体系和运行保障机制。具体描述如下：相相关法律法规标准规范门户综合客户端移动客户端采购综合跨平台综合电子辅助投标客户端手机智能终端跨平台用户服务采购中心办公系统网上采购系统的业务应用层工作流引擎单点登录CA接口全文索引资源配置XMPP服务表单定制报表定制角色权限管理日志管理备份管理缓存管理监控管理统一消息管理……其它Ruby实现的ESB企业服务总线实现的应用支撑平台SOA整合硬件基础设施(