之江实验室协同平台系统项目

　之江实验室协同平台系统 项目

　 招标文件

　 采购方式：公开招标 项目编号：CTZB-F180929BWB-ZJSYS1

　 采购人：

　之江实验室 （盖章）

　采购代理机构：

　浙江省成套招标代理有限公司 （盖章）

　二〇一八年 九月 月

　目录 目录 .................................................................................................................................................. 2 第一章

　招标公告 ............................................................................................................................. 3 第二章

　采购需求总体要求 .............................................................................................................. 5 第三章

　采购需求具体要求 .............................................................................................................. 6 第四章

　采购合同 ........................................................................................................................... 46 第五章

　评标办法 ........................................................................................................................... 50 第六章

　投标人须知 ....................................................................................................................... 54 第七章

　投标文件格式 .................................................................................................................... 67

　第一章

　招标公告 参照《中华人民共和国政府采购法》等有关规定，浙江省成套招标代理有限公司受之江实验室委托，就之江实验室协同平台系统项目进行公开招标，欢迎国内合格的供应商前来投标。

　一.项目名称：之江实验室协同平台系统项目 二.项目编号：CTZB-F180929BWB-ZJSYS1 三.招标项目概况（内容、用途、数量、简要技术要求等）：

　序号 标项内容 数量 单位 预算金额 简要技术要求 备注 1 协同平台系统 1 项 238万元 统一身份认证平台、信息标准体系、主数据管理平台、数据交换共享与业务应用集成平台、一站式服务门户、智慧移动平台、协同办公 OA 系统、EHR 人事管理系统 本项目最高限价：238 万元 四.投标供应商资格要求：

　（1）具有独立承担民事责任的能力； （2）具有良好的商业信誉和健全的财务会计制度； （3）具有履行合同所必需的设备和专业技术能力； （4）有依法缴纳税收和社会保障资金的良好记录； （5）参加政府采购活动前三年内，在经营活动中没有重大违法记录； （6）供应商未被列入失信被执行人名单、重大税收违法案件当事人名单、政府采购严重违法失信行为记录名单，信用信息以投标截止日信用中国网站（www.creditchina.gov.cn）、中国政府采购网（www.ccgp.gov.cn）公布为准； （7）单位负责人为同一人或者存在直接控股、管理关系的不同供应商，不得参加同一合同项下的政府采购活动； （8）非联合体。

　五.招标文件的发售时间及地点等：

　时间：2018 年 10

　月

　08 日起至 2018 年 10

　月

　12 日（双休日及法定节假日除外），上午：8：30-11：30，下午：14：30-17：30 地点：杭州市文晖路 42 号现代置业大厦西楼 17 层 1706 室（文晖大桥西侧下桥口）

　售价（元）：每本 500（售后不退）

　支付方式：现金、汇票、支票、银行转帐等 收款单位（户名）：浙江省成套招标代理有限公司 开

　户：中信银行杭州西湖支行 账

　号：73326385 获取方式：现场获取，或将报名资料扫描件发送至并致电采购代理机构联系人获取 六.投标截止时间：2018 年 10

　月

　22 日 09 时 30 分 七.投标地点：杭州市文晖路 42 号现代置业大厦西楼 17 层 1702 开标室 八.开标时间：2018 年 10

　月 22

　日 09 时 30 分 九.开标地点：杭州市文晖路 42 号现代置业大厦西楼 17 层 1702 开标室 十.投标保证金：

　投标保证金：40100 元

　支付方式：电汇（网银）等 收款单位（户名）：浙江省成套招标代理有限公司 开

　户：中信银行杭州西湖支行 账

　号：73326385 十一..其他事项：

　1、本项目公告期限为 5 个工作日，供应商认为采购文件使自己的权益受到损害的，可以自收到采购文件之日（发售截止日之后收到采购文件的，以发售截止日为准）或者采购文件公告期限届满之日（公告发布后的第 6 个工作日）起 7 个工作日内，以书面形式向采购代理机构提出质疑。质疑供应商对采购人、采购代理机构的答复不满意或者采购人、采购代理机构未在规定的时间内作出答复的，可以在答复期满后十五个工作日内向采购人的采购监督管理部门投诉。质疑函范本、投诉书范本请到浙江政府采购网下载专区下载。

　2、投标人购买标书时应提交的资料：

　1）介绍信或法定代表人（单位负责人）授权书（原件）； 2）被授权人身份证（原件和复印件）； 3）有效的营业执照副本（或法人证书）等复印件（复印件加盖单位公章）； 4）银行开户许可证（复印件加盖单位公章）； 3、采购项目需要落实的政府采购政策 对符合财政扶持政策的中小企业（小型、微型）、监狱企业、残疾人福利性单位给予价格优惠扶持； 4、其他事项 1）未经报名登记并获取招标文件的供应商参与本项目投标，将被拒绝； 2）招标文件发售截止时间之后潜在供应商仍然可以获取招标文件； 3）书面质疑受理地点：杭州市文晖路 42 号现代置业大厦西楼 17 层 1701 室，联系人：张女士、陈先生，联系电话：； 十二.联系方式 1、采购代理机构名称：浙江省成套招标代理有限公司 联系人：干祥平 联系电话：

　 传真：

　地址：杭州市文晖路 42 号现代置业大厦西楼 17 层 1706 室 2、采购人名称：之江实验室 联系人：钟老师 电话：

　技术联系人：

　温老师 电

　话：

　地

　址：浙江省杭州市文一西路 1818 号之江实验室 10 号楼 6 层 附：招标文件

　第二章

　采购需求总体要求 一、技术标准、规范（不限于以下）

　1、国家规定的标准及规范，按最新的标准及规范执行。

　2、行业标准及规范，按最新的标准及规范执行。

　3、与服务有关的材料设备质量应符合中华人民共和国及产品品牌所在国的有关质量标准，上述标准如有不一致，执行两者中更严格的标准。

　4、其它相关标准及规范，按最新的标准及规范执行。

　二、采购内容及需求 具体要求详见招标文件的“第三章 采购需求具体要求”。

　三、工作范围 各投标人须按国家有关标准及规范完成招标文件规定的所有工作内容：

　1、履行所有规定服务； 2、服务成果须达到招标文件规定的质量标准及使用要求。

　第三章

　采购需求具体要求 一、采购内容一览表 序号 标项名称及内容 数量 单位 实施周期 备注 1 协同平台系统 1 项 130 个日历日

　二、采购需求 1 、系统服务内容 序号 服务要求 数量/单位 1 统一身份认证平台 1 套 2 信息标准体系 1 套 3 主数据管理平台 1 套 4 数据交换共享与业务应用集成平台 1 套 5 一站式服务门户 1 套 6 智慧移动平台 1 套 7 协同办公 OA 系统 1 套 8 EHR 人事管理系统 1 套 2 、总体目标 2.1 协同服务平台核心支撑系统建设的总体目标和要求如下：

　以信息安全、统一认证平台为核心基础，以移动化、数据化、国际化、生态化为总体策略方针。

　助力业务发展，为办公、行政、财务、采购、人力、法务、科研等业务提供基础技术支撑。实现办公无纸化和移动化，业务应用和数据云端化，项目管理、业务分析数据化。

　核心支撑系统建设充分考虑之江实验室“一体、双核、多点”的混合所有制开放融合特征，在整个生态体系内认证、数据、接口、应用实现安全分级、互连互通。

　2.2 具体来讲，该项目建设完成后应该实现如下目标：

　1）实现智慧园区+微服务平台建设的坚实基础框架。本次建设须建成先进、稳定、可扩展的核心支撑系统平台；该平台至少包括但不限于以下系统：统一身份认证平台、信息标准体系、主数据管理平台、数据交换共享与业务应用集成平台、一站式服务门户、智慧移动平台。要求该核心支撑系统与各个业务系统之间形成松耦合架构体系，并具备能为用户提供一站式服务的能力。

　2）实现多种方式的统一身份认证、授权和访问控制并具有可扩展性。本次建设的“统一身份认证平台”必须能实现对实验室所有系统的身份认证、授权、访问控制和单点登录管理，要求身份认证准确安全，授权和访问控制的控制粒度精细、具有柔性，其中授权粒度应能支持到具体的业务、服务或数据内容级别。

　3）实现“一站式”服务。实现对实验室主要业务应用系统进行业务应用层面的调用与整合，并把整合好的业务流程综合展现在“一站式服务门户”之上，使得最终用户只需在“一站式服务门户”进行简单填表式操作就能完成各种业务办理，从而实现“一站式”服务。同时，能够适应未来日趋复杂和动态变化的更多业务流程。

　4）实现信息标准体系、主数据管理平台建设。本项目建设完成后，所有已建成或待建应用系统均须按信息标准体系严格执行信息标准，各应用系统数据统一同步到主数据仓库，并统一由共享数据

　库提供数据共享和交换服务所需的数据。

　5）实现数据交换共享与业务应用集成平台建设。本项目建设完成后，数据共享和交换应该由业务流程驱动，实现业务流程办理到哪个节点则数据流动到哪个节点，实现业务流程和数据流动的同步及一体化。

　6）实现业务流程管理柔性化和可自定义配置。该项目建设要求能提供丰富多样的流程管理配置、流程节点与流程总体绩效统计和分析、以及实现图形化便捷配置管理和自助式二次开发。为适应实验室的业务众多且会经常发生变更，要求业务流程管理应该具备充分的柔性和可自定义配置性。流程引擎能用于“一站式服务门户”中轻应用的流程控制和开发。

　7）实现“一站式服务门户”成为综合性用户终端。要求“一站式服务门户”要成为功能强大、技术先进、美观易用的信息管理、业务/事务处理的综合性用户终端。不仅支持主流浏览器，还能支持主流的移动终端设备和主流的移动端操作系统（如 IOS 和 Android 等）。另外，上述“一站式服务门户”要求能提供完善的二次开发工具包，以保障实验室的自主开发需求。

　8）▲应用系统集成，完成当前已有系统企业钉钉、财务复旦天翼（含接口对接经费）、阿里邮箱、网络接入身份验正以及当前新增系统办公 OA、人事系统统一认证和集成。建设统一应用基础平台，统一技术标准为将来二期应用需求集成夯实基础。

　附：应用系统集成需求展示图

　 3 、项目服务要求

　3.1 总体技术要求 供应商所提供的所有各项 系统应符合如下要求：

　1）供应商提供的各项设备及系统的功能、性能应完全符合磋商文件指明的标准，并满足或高于磋商文件指出的要求。本磋商文件中未说明但国际、国家和行业标准已有建议的设备功能与性能的条款，应符合相应的最新标准与建议。

　2）供应商须承诺所提供的所有软件产品知识产权权属清晰。本次磋商文件中所涉及的第三方软件的使用权归采购人所有。其它相关权属关系双方通过合同予以明确。

　3 ）供应商提供的系统应基于 Java EE 规范的总体技术路线。

　4 ）供应商提供的系统应使用 B/S 架构实现。

　5 ）供应商提供的系统要实现与钉钉的无缝集成。本次采购的系统要基于 H5 页面响应式布局的态 方式与钉钉集成且能够自适应各种移动终端，不能以开发原生态 APP 方式实现移动终端使用；用户通过钉钉帐号、手机号与实验室账户绑定后经统一身份认证登录门户平台，实现平台消息通知推送到钉钉；采购人今后上线的微应用服务均支持无缝发布到钉钉且无需付费做二次开发。

　6 ）供应商提供的系统要求能够在采购人本地私有云 VMware Esxi5.0 及以上版本服务器虚拟化集群环境中平滑部署。

　7 ）供应商提供的系统应基于 SOA 理念，采用面向服务和基于总线的架构进行构建。

　8 ）能够基于统一的平台框架设计开发本期建设的服务平台，并开放提供本期项目所有平台及系统的源代码，提供相应的开放工具及环境，以便供采购人未来进行进一步开发使用。（供应商必须提供盖有公章的承诺函原件）

　9 ）供应商必须免费开放提供各种接口（供应商必须提供盖有公章的承诺函原件）。

　10 ）采购人在任何时候都保留和拥有对本文件的解释权。采购人有权在签订合同前，根据需完善和补充技术规范书，修改后的最终技术规范书将作为合同的附件。

　供应商应当充分理解采购人需求并为采购人提供定制化系统设计方案；如因招标文件未对相关需求做出明确约定而发生系统设计方案和项目最终交付结果无法满足采购人需求的，采购人可以补充提出需求（补充需求工作量应小于本标里 书总任务里 5% ）

　，若采购人补充提出需求后供应商不同意修改的，采购人有权无条件中止合作，并要求供应商返还采购人已支付的全部费用。

　3.2 性能规范要求 系统运行支持万级 用户量。

　持 页访问并发用户支持 1000 人同时访问。

　证 系统保证 7*24 小时运行。

　于 平均延时小于 5 秒，最大延时不超过 15 秒。

　支持负载均衡，具备可扩展性。

　支持远程管理。

　系统在异常情况下能够自动恢复，具备较强的安全保护措施和故障恢复能力。

　3.3 安全规范要求 系统提供相应数据备份/ 恢复功能，制定合理的备份策略提供保护机制。

　系统具备完善的使用授权、监控和日志管理机制，能够 对用户。

　访问及敏感数据的操作进行审计。

　持 系统支持 HTTPS 访问方式。

　系统支持对数据的正确性和完整性进行验证。

　系统支持对敏感数据进行加密。

　止 系统具备防止 SQL 等注入的攻击机制。

　所投平台的产品应具有国家或行业认可的安全评测机构评测报告。

　3.4 扩展规范要求 供应商应充分考虑本项目在后续运行、管理过程中的业务功能扩展的要求。在充分满足当前业务需求的基础上，供应商须对系统的扩展性进行认真分析与设计，提供具体的满足扩展性要求的方案，以确保系统可满足后续业务发展的需求：

　要求在不编写程序代码的情况下使用图形化界面能够进行个性化设置。

　集群部署的各节点能够弹性增加或减少。

　4 、技术要求 4.1 核心支撑系统 4.1.1 统一身份认证平台 统一身份认证平台通过构建全局性的用户身份管理、信息管理和授权管理的中心，保障实验室信息资源的有序应用，确保实验室资源和服务的安全；实现用户的统一管理，提高用户集中式管理的效率，降低维护成本；实现用户身份的统一认证，减轻用户在用户名和密码管理上的负担；建立多样化的认证方式，满足不同业务的不同安全级别要求；为应用安全在统一身份认证、授权、单点登录和数据传输/存储加密等方面提供保障。

　系统建设应达到如下目标：

　需实现便捷、多样化的认证登录方式。例如可以实现输入用户名、Email、手机号码、工作证号/学号和密码等多种方式登录。同时支持用户名密码、认证码和/或数字证书等多种认证方式。

　需实现安全的单点登录（SSO）。

　需实现符合实验室组织机构、人员、角色、岗位、权限和资源特点的权限管理、授权方式及访问控制策略。

　需建立用户身份（例如跨部门任职兼职、多重身份）管理机制，提供灵活方便的身份异动管理，例如身份异动后，相应权限自动撤销、变更和加载。为权限管理系统或其他业务系统提供一个方便的身份识别及管理服务。

　需建立灵活、方便的权限管理模型，减轻管理负担。要特别注意“岗位”、“角色”、“用户”及“资源”的关系设置。权限管理要有高度灵活性和自动性。

　能与现有系统实现无缝集成。一次性建立全局性岗位和角色后，可直接应用到所有系统中，除部分与某些信息系统有特别紧密联系的角色外，所有角色均在统一权限管理系统中进行集中式管理。用户角色、权限管理可实现各系统管理员或指定管理员分级进行管理，但角色权限信息必须统一存放在身份识别与访问控制平台中。同时，能够为未来新建信息系统的开发提供统一的认证、授权及安全标准。

　需提供完备的安全日志及审计、安全风险预警及管理功能。

　需支持负载均衡和多机备份等。

　需采用开源 CAS 作为 SSO 内核。

　需建立数据传输及存储的加密机制。

　需提供便捷的图形化管理和配置工具。

　统一身份认证平台应基于 LDAP 技术，实现统一用户身份认证和权限控制体系，利用目录服务，对用户身份信息和系统控制信息进行有效组织管理，提供高效安全的目录访问，为各应用系统提供统一身份认证和权限控制的支持。

　需支持 RADIUS 协议，能满足 VPN、入网认证等网络设备的认证需求。

　1）技术要求 应采用企业级、开源项目进行核心支撑系统的中心身份认证授权与访问控制平台的开发，具体要求如下：

　系统和用户身份管理 需提供 API，对于任何应用，均支持身份认证授权及访问控制集成。

　需提供除用户名与密码外的更多样化电子身份认证技术如 CA、园区卡、电子签章或签名、生物特征识别技术等。

　需支持通过 OpenID，SAML2，Kerberos 等协议或技术实现密钥分发，支持单点登录（SSO）

　支持内部系统和云应用程序之间的 SSO 桥接 支持跨越不同协议的证书映射 支持通过 xdas 等的审计 支持通过 OAuth 1.0a, OAuth 2.0 和 WS-Trust 等的授权 支持通过 OpenID, SAML2, and WS-Trust STS 等的联合认证 支持采用 OAuth 2.0 和 XACML 等实现 REST 安全 支持用于密钥存储和分发的 XKMS 支持基于 REST 安全的 OpenID 连接 支持可信的 SAML2 身份提供者 支持针对 OpenID，OAuth，OpenID 等的连接，SAML2，STS 的可定制化登录页面 应具有完善的身份基础信息，具备自动和手工身份信息完善与变更功能 用户和用户组定制 需支持 SCIM 等标准的用户与用户组定制 需支持用户自定义配置 用户和组管理 需提供基于 Web 的用户和用户组管理 需为用户信息存储提供灵活的支持，如内置的 LDAP（、外部的 LDAP，微软 Active Directory、Apache Cassandra、以及任何 JDBC 数据库等 需支持灵活的配置管理，可为每个用户提供多个配置文件 需支持对超过尝试失败次数的帐户进行锁定 需支持密码验证/过期策略 需支持通过电子邮件、手机和保密问题实现帐户恢复 授权管理 需实现基于角色和角色组的访问控制 需实现基于导入或自定义访问控制规则的授权 需实现通过 XACML 等实现基于访问控制规则的细粒度策略 需支持先进的授权管理和审核 需支持 REST、SOAP 等的调用授权管理 角色管理需支持单身份多角色授权。

　需实现统一授权和分级授权相结合。即平台提供统一的基本授权，而各个业务系统能根据基本授权实现更为精细的授权。

　需实现根据相关业务系统数据和访问控制规则自动给出基本授权并给出相关信息。

　需实现访问控制规则管理。

　支持 XACML2.0/3.0 需支持策略编辑的用户友好的界面

　 需支持多策略信息点（PIP）

　需支持探索策略影响效果的 Trylt 工具 需支持各种不同的策略决策点（PDP）分配政策 需支持决策和属性缓存 需支持 PEP / PDP 交互的高性能网络协议 需支持策略更新通知

　需支持使用策略管理点（PAP）来管理多个策略决策点（PDP）

　需支持可定制的策略管理界面 轻量级，对开发者友好和易于部署 需支持完整的 SOAP API，能整合/嵌入任何应用程序或系统 需支持可插拔的工作流授权操作 需具有扩展性，支持可插拔认证，可选择的用户存储，具有 XACML / SAML 扩展点 需支持高可用集群部署 需支持无需更改配置即实现本地服务器、私有云或公共云的部署选择 需支持对 ESB 的授权和产品认证集成 管理和监控 需支持安全的 Web 综合管理和监视控制 需支持内置标准的访问和性能统计采集、监控 需支持关键指标的监测和管理 需支持业务审计和 KPI 绩效的监控和管理集成 需支持集成到记录系统的灵活日志支持 需实现集中式的配置管理，通过整合注册表支持生命周期和版本控制 用户认证授权的自助服务 需实现个人信息维护：用于对个人账号信息、密码信息的维护。

　需实现密码找回：包括通过邮箱找回密码、通过回答问题找回密码、通过手机找回密码等常见的密码找回机制。

　需实现账号日志：用于查询账号的登录情况、账号的维护情况。

　需实现权限申请：用于申请基础权限及各业务系统的特有权限。

　2）功能要求 用户管理 需提供用户管理功能管理用户基本信息，主要包括：

　用户注册 账号关联 组织机构管理 岗位管理 用户管理 角色管理 权限控制 用户身份认证通过后，必须对用户的应用系统使用权限进行统一控制，主要功能包括：

　应用系统基础信息管理 模块组基础信息管理 模块基础信息管理 应用系统权限管理 用户权限管理 岗位权限管理 用户授权管理 用户身份认证 需提供身份认证的异构系统支持，提供标准的认证集成接口，供其它系统的开发商调用。标准接

　口的实现有如下几种：

　.Net 接口 JAVA 接口 ASP 接口 PHP 接口 C/C++接口 ISAPI 接口 Perl 接口 VBScript 接口 WebServics 接口 其他接口 管理操作审计 需支持对所有用户所做的权限变化过程记录日志，并提供相应的查询功能。

　认证集成服务 统一身份认证平台应包含三个部分：统一用户管理、统一身份认证和统一权限管理，在平台建设与应用系统的集成方面也应包括这三部分的集成。

　用户集成 用户集成目标 所有用户的管理需在统一身份认证平台集中进行，应用系统不再管理用户信息，所需的用户信息完全来自于统一身份认证平台。

　用户集成方式 需支持由统一身份认证平台进行身份认证 也需支持业务系统保留自己的身份认证，建立用户映射表 认证集成 认证集成目标 各应用系统的身份认证均需在统一身份认证平台集中进行，应用系统不需再对用户身份进行校验。

　认证集成方式 需支持改造应用系统，采用统一认证接口认证 需支持改造应用系统，保留系统原有认证界面 需支持不可改造应用系统，代理认证 认证集成接口 针对以后在统一身份认证平台基础上开发的新系统，需提供标准的认证集成接口，供新系统的开发商调用。标准接口的实现需具备有如下几种：

　DotNet 接口 JAVA 接口 ASP 接口 PHP 接口 C、C++接口 其他接口 权限集成 权限集成目标

　利用统一身份认证平台提供的权限管理工具统一管理应用系统所需管理的是用户的数据权限。

　在权限管理体系上，需支持采用分级授权模式，即由统一身份认证平台将某应用系统的管理权限授给该应用系统管理员，由该应用系统的管理员来管理和设置本系统的所有用户使用权限，所有权限数据由统一身份认证平台集中存储。

　权限集成方式 数据交换 需分析业务系统权限数据表结构、关系，支持通过数据交换的方式进行权限集成。业务系统无须改造原有系统的权限访问控制代码。但权限数据的管理，须在统一身份认证平台中进行管理。

　改造系统 统一身份认证平台需提供权限操作、管理相关的接口（webservice），由业务系统调用这些接口并修改系统的权限访问控制代码。原有系统的权限数据的管理被废除，完全在统一身份认证平台中进行管理。

　集成接口 针对以后在统一身份认证平台基础上开发的新系统，需提供多种标准的权限集成接口，供新系统的开发商调用。

　系统管理与监控 系统管理功能需实现对平台运行起支撑作用的数据管理和功能设置，包括操作日志管理、管理员管理和配置管理功能。

　系统管理与监控需提供一套完整的基于 WEB 的统一身份认证平台运行监控工具，界面为中文界面，可以远程管理身份数据。能够监控平台的目录服务、认证服务、认证接口的运行状态，针对围绕身份认证相关的系统服务进行统一的管理，提供对身份认证系统相关的服务进行“启动/停止”控制，具有自我监控机制，发现异常后可自动告警；同时还提供历史事件的查询和认证会话的相关操作。

　系统管理与监控功能需为管理员提供及时的风险预警功能，可审计出异常的帐号、不合理的认证行为和授权行为，用于发现系统可能存在的安全问题和隐患。系统提供对用户数据、组数据、用户和组关系的批量维护功能，方便用户使用。

　系统需提供管理控制台，对平台运行的所有服务进行配置、预警并响应，提供管理员管理、系统启动与停止、日志管理、会话管理、数据备份恢复与导入导出和平台参数配置功能。

　系统需支持监控平台的目录服务、认证服务、认证接口的运行状态。

　4.1.2 信息标准体系 信息标准的制定应基于国家相关标准，尊重实验室已有标准，兼顾各个标准之间的兼容性、一致性以及标准的可扩展性。标准应充分考虑到实验室各信息系统运行现状，标准体系需拥有明确的标准冲突解决办法，能够保证新制定的信息标准完成数据的准确交换与共享，确保标准制定过程及结果的科学性。

　标准规范体系的设计应遵循如下原则：

　标准的兼容性 标准的实施对各职能部门信息系统建设、信息的交流与共享、数据的收集、分析、发布所采用的信息标准必须和国家标准相兼容。

　标准的唯一性 在一个分类编码标准中，每一编码对象仅有一个赋予它的代码，一个代码只唯一表示一个编码对象，不能具有任何二义性； 标准的可扩性 代码结构必须能适应同类编码对象不断增加的需求，必须为新的编码对象留有足够的备用码，以

　适应不断扩充的需求； 标准的简单性 代码结构应尽量简单，长度尽量短，以便节省机器存储空间和减少代码的差错率；同时，提高机器处理的效率； 标准的规范性 在一个信息编码标准中，代码的结构、类型以及编写格式必须统一； 标准的适用性 代码要尽可能的反映分类对象的特点，便于记忆，便于填写； 标准的合理性 代码结构要与分类体系相适应。

　标准的全面性 信息标准不仅需包含国家及实验室本身的业务标准集，还需在业务标准的基础上构建用户数据模型标准、数据分析模型标准、数据仓库标准等，用以实现实验室的业务优化过程，充分利用好各类数据。

　标准的兼容性 采用的信息标准必须严格遵守国家最新信息标准。可以对各职能部门信息系统建设、信息的交流与共享、数据的收集、分析、发布起到指导和规范作用。

　标准建设内容要求 信息标准应包括参照标准、执行标准以及参照标准与执行标准的对比等内容。

　信息标准规范 需使用国家最新的管理信息标准和规范，建立一个符合国家标准规范的行业标准，从制度上保证整个系统的标准化和可扩展性。

　数据标准 推荐常用信息编码规则 常用的信息编码需包括园区编码、组织机构编码、工号、项目号、房间号、设施号、会议号、设备号等。

　信息标准数据的 ER 图 需提供标准标准数据的 ER 图。

　代码标准 编码集应采用二种编码。第一种是国家已经公布的国家标准代码；第二种是实验室自编信息代码，二者合一最终形成实验室的标准编码库。所有数据均需符合国家标准，国家没有统一标准的建立实验室的内部标准。

　需支持数据打印输出转换标准，满足各业务系统向上级或相关部门报送数据报表的需求。

　业务表标准 应采用国家标准为基本标准，保证标准的兼容性。

　代码表标准 需以国家标准为基础，在此基础上根据实验室的业务需求进行有限的扩充，如果需采用实验室内部标准，则必须采用代码对应表形式，与国家标准相匹配。数据打印输出时需支持转换标准，满足各业务系统向上级或相关部门报送数据报表的需求。

　自定义代码表标准 需根据实验室需构建自定义代码表，采用标准的代码、名称以及类别机制，可根据业务需进行字段扩充，自定义代码表支持标准扩充，如一位编码扩充为两位，要求原编码位数标准要高于实际需求

　的位数。

　编码标准 需以国家标准为基础，根据实验室的实际情况制定编码规则。

　交换标准 需通过建设数据交换与集成平台，构建一个标准的、开放的实验室业务领域通用信息模型，并提供通用的数据接口，作为集成标准。通用信息模型可以为各应用系统提供统一数据模型和编码，通用数据接口可以消除接口与技术协议的差异性，满足应用需求的变化，实现数据资源共享。

　通用信息模型 CIM 需基于面向对象思想，采用统一建模语言 UML。

　需涵盖实验室关注的科研、行政办公、财务、人事等不同领域主要实体的逻辑结构和关系。

　需为各个应用提供了与平台无关的统一的逻辑描述，为实现科研一体化提供基础信息模型。

　通用的数据接口 GDA 需以标准的方式访问公共信息或相互之间交换信息。需为应用系统提供使用公共 API 访问共享数据和使用公共服务实现数据处理、存储和显示功能的机制。通用接口服务至少需包括：资源标识服务、资源查询服务、过滤资源查询服务、资源更新服务等，实现数据访问和更新。

　接口定义应采用面向对象描述方式。

　未来构建的业务系统，将按照统一的信息标准、开发标准规范和数据交换标准进行规范，实现业务系统之间的流程衔接和协同工作。

　交换接口标准 数据交换引擎应该是基于面向服务架构 SOA 的开放的、标准的基础技术平台，需支持业界绝大多数的开放标准，如 XML、BPEL、XQuery、XPath、JMS、JDBC、Web Service、WSIF、JCA、WS-Security、WS-I 等标准。需支持文件交换（XML 文件、DBF 文件、其它格式文件）、标准数据交换，应采用 XML、Web Services 作为数据传输的标准，应采用主流消息传递机制，帮助用户建立统一的数据传输与数据交换规范，实现不同部门间、不同应用系统间的数据交换，应具有良好的扩展性。

　数据交换规范的具体要求如下：

　需提供支持 BPEL 规范的流程引擎，实现面向服务、流程驱动的数据交换引擎； 需提供浏览器的管理监控界面； 需支持使用图形化设计工具定义数据交换流程； 需支持使用图形化设计工具定义数据转换规则，支持 XSLT 映射器； 需支持使用浏览器界面定义与管理 Web 服务的安全策略； 所有信息均应采用标准的 XML 格式（XSD 类型或 DTD 类型）； 对于无法提供 XML 格式内容的待集成应用系统，至少需提供分隔符、固定位置、二进制文件等文件格式； 可直接访问的数据库系统，需支持 JDBC 标准； 不可直接访问的数据库系统，须提供代理访问接口，如 Web 服务接口； 传统应用系统如未提供 Web 服务接口，则应支持 JCA、Java/EJB、JMS、HTTP GET/POST、文件等接口方式； 综合服务平台中 Web 服务的安全与管理，应支持 WS-Security、WS-I 等 Web 服务标准； 需提供可扩展的、负载均衡的集群技术，满足不断增长的系统服务需求。

　数据模型标准 需根据实验室的全局服务模型建立元数据模型，元数据模型是按服务所需，对源业务数据进行组

　合关联的模型，它与实验室教学、科研、管理活动的业务模型有关，是提供所有信息资源服务所需的数据模型，也是共享数据库平台的基本数据结构。

　应用集成标准 应用集成应分为数据集成、身份集成、发布集成和门户集成。

　标准管理工具 系统需提供一套信息标准的管理工具，以对标准进行管理和维护。信息标准管理工具功能需覆盖到参照标准、执行标准的管理、代码标准映射、数据模式的浏览和维护等，需具备初始化、新增、删除、修改维护功能和分类检索、输出、数据展示浏览功能。需提供可视化的界面，对标准的各类信息进行图表化展示。能满足实验室信息标准管理的需求，需具有一定的自动化、智能化特点，能通过统一身份认证与管理平台，实现身份访问控制、操作日志、审计和备份恢复管理功能，从而实现对标准的维护和完善。

　4.1.3 主数据管理平台 需建立实验室全局的管理和业务数据模型，对数据资源进行统一的整理、分类和管理，实现实验室信息资源的集中，并形成全局数据共享的管理、维护、处理和服务机制，实现实验室信息资源的共享、集成和利用。具体而言，主数据仓库的建设需达到以下目标：

　需建立实验室统一的信息资源标准； 需对数据全面可靠的整合，建立共享数据库，实现实验室核心信息资源的共享； 需在共享数据库基础之上对数据的进一步的加工和整理，建立数据仓库，为实验室领导、各级管理决策人员提供灵活度更高的多维分析和数据挖掘； 需实现高度模块化的设计，建立完善的数据模型及其管理框架； 需具有良好的系统扩展性，满足实验室日益增长的业务需求； 需提供性能卓越的数据管理、系统监控工具，降低系统维护人员的工作难度； 主数据仓库需以元数据管理思路对共享数据进行建设和管理，由共享数据中心和管理工具组成。共享数据中心能够建立实验室统一的标准代码集和核心数据模型，从而形成实验室的信息资源标准。主数据仓库还应当建立强大的数据管理、处理和维护功能，为主数据仓库的运行提供支持。

　主数据仓库应能够解决如下问题：

　数据共享的问题 数据一致性问题 历史数据处理问题 技术要求 主数据仓库需通过数据交换机制的支持实现实验室共享数据的集中管理，在此基础上对业务数据进行全面清洗，是各类信息采集、加工和整合的平台。

　主数据仓库应该是一个数据管理平台，能够为信息系统提供一致的、稳定的共享数据源； 主数据仓库需实现新旧系统中同构、异构数据的整合； 需再物理架构上集成一系列的工具(管理工具、数据整合工具、查询工具)，在数据中心中可以借助关系型数据库进行存储； 实现面向用户提供服务：如对用户的现有的及历史的信息进行分析；辅助管理层进行分析决策。

　需实现各业务系统生成的业务数据通过数据交换平台同步到数据仓库，数据仓库将共享数据同步到共享数据库；需实现某各业务系统需与其他业务系统进行数据交互时，仅需通过数据交换平台与共享数据库交换数据，不再需与多个业务系统通过系统间接口交互。综合数据应用也仅需访问共享数据库即可获得所需数据。

　同时，每个业务系统接入时，仅需与数据中心做接口交互，避免了以前可能需与每个已有应用系

　统分别协商、改造接口的情况。

　核心数据模型 数据模型是主数据仓库的核心，它对数据源系统中所采集的数据进行重新组织，需建立如下几种数据模型：

　权威数据模型。是面向全局的核心基础数据。它由唯一业务源产生和维护，采集到主数据仓库，供各业务系统共享和引用的数据。比如用户基本信息、人事管理信息、科研信息、资产信息、财务信息等。

　资源数据模型。以文件等形式存储和管理的资源数据，如文档、照片、流媒体等。

　主题数据模型。将来自于不同应用的数据按主题整合、组织的数据，便于按主题进行展现。

　标准代码数据模型。根据实验室的要求的标准，建立统一的信息资源标准代码集，便于全局数据的共享。

　在国标基础上，结合实际情况选择自己的执行标准。

　数据仓库(DDS) 数据仓库是在共享数据库基础之上对数据的进一步的加工和整理，它可以为实验室领导、各级管理决策人员提供灵活度更高的多维分析和数据挖掘。

　数据仓库建设需根据 BI 应用的需求，通过关系型多维模型的建设，形成多维数据库（DDS），或者称为主题数据库，为多维分析和数据挖掘应用提供数据。

　数据仓库需建设如下几个主题数据库：

　用户基本信息主题 人事基本信息主题 实验室科研项目主题 实验室资产主题 实验室综合情况主题 数据仓库是多维数据库的形式存储，即 DDS（Dimensional Data Store），它是业务常用数据、衍生数据以及其他一些数据的数据集合。它的数据来源通常是 ODS 数据存储，或者在业务数据比较“干净”的情况下也可以直接从业务系统中抽取。DDS 通常作为 OLAP 数据的唯一数据源。DDS 多维数据存储是数据仓库共享、正确、高效、增值等诸多特性的体现。

　DDS 中的数据存放必须按照一定的规则进行存放，这就是多维数据模型。整个 DDS 就是一棵结构分明的数据树。DDS 的拓朴结构从数据主题开始，经过若干层的子主题，到最后包含在不同子主题中的“数据单元”为止，形成一个典型的树型结构。

　平台管理功能要求 信息标准管理工具 能够实现对主数据仓库所采用的实验室执行标准、所参考的国标、部标等，与业务系统数据字典的对应关系进行管理，并对变化情况进行跟踪。需实现：

　对实验室执行标准代码进行管理 对各个应用系统所包含的代码进行管理 管理实验室执行标准与应用系统代码的映射。为信息交换平台中的数据转换提供支持。

　实现应用系统代码与执行代码的差异性对比，便于实验室制订和执行标准时参考。

　跟踪执行标准和应用系统代码的变化，包括数据结构的变化和数据内容的变化两种。并可通过短信、邮件等方式及时发出提醒，便于管理。

　元数据管理工具 需采用元数据管理思路，对共享数据库中的数据对象、数据模型进行管理和跟踪。主要功能需包

　括：

　共享数据模型管理。管理数据模型列表。将主数据仓库的数据模型和数据对象统一管理，可按照不同的树型进行分类。

　应用系统数据结构管理。管理各应用系统的数据结构，可通过信息交换平台实现应用系统数据结构的动态采集。

　数据模型映射管理。定义和管理共享数据数据模型和应用系统数据结构之间的关联关系。

　数据模型跟踪监控。跟踪和监控主数据仓库数据结构、应用系统数据结构的变化情况以及相应造成的影响，并可与实验室的短信网关或邮件服务进行集成，及时提醒系统运行维护人员，便于管理。

　监控中心 需实现对主数据仓库的整体运行情况进行监控的功能。具体包括以下功能：

　监控记录查询 需实现查看后台监控记录的功能。

　数据中心状态监控 需实现监控数据中心运行状态，保持数据中心与数据集标准的一致性的功能。

　资源库代码变化监控 需实现监控资源库代码变化情况的功能。

　资源库数据集变化监控 需实现监控业务数据集的结构变化情况的功能。

　资源库数据交换对象监控 需实现监控资源库数据交换对象（包括触发器、状态表、存储过程状态）的功能。

　数据交换状态监控 能够支持用户通过该功能查看目前存在于数据交换共享服务上部署的数据交换任务，是否工作正常，或出错，有异常等状态。

　错误日志管理 需提供错误日志浏览、查询、清理功能。

　操作日志管理 需提供操作日志查看、清理功能。

　日志迁移 需提供错误日志、操作日志的迁移功能。

　4.1.4 数据交换共享与业务应用集成平台 数据交换与应用集成平台需实现构建实验室核心支撑系统项目数据交换的系统框架，制定园区统一的数据采集、维护、交换的技术规范和标准，实现实验室信息资源的交换共享、信息集成管理和信息资源的充分利用。

　具体而言，数据交换与集成平台的建设要求达到以下目标：

　需为各应用系统之间提供一个统一的数据交换通道和接口，使数据交换更加准确、便捷、高效、畅通，设计并实现各业务应用系统数据实时交换框架体系； 需为公共数据平台提供一个可靠的数据采集通道； 需建立实验室统一的数据交换技术规范和标准。

　企业服务总线 应用集成平台需实现构建应用服务协同和管理的系统框架，制定统一的服务注册、发布、访问、控制、管理的技术规范和标准，消除应用之间的间隙，实现各应用系统之间的协同工作。应用集成平台应该采用开源 Activiti 实现，提供企业级计算能力的支撑环境如服务网络、集群能力、安全机制等。

　技术要求 需支持多种业务和服务系统集成 需支持信息、服务、API 和安全网关 需具有高性能、高可用性、可扩展性及稳定性 需支持轻量级、开发者友好和易于部署 需支持可视化的管理和监控 应用集成平台应采用基于 SOA 体系架构的松耦合应用集成架构，在实验室分布式、异构的应用环境中，为实验室提供更大的灵活性，重用性和整体的反应能力。应用集成平台需充当 SOA 中服务提供者和请求者之间的连接服务的中间层，具备灵活的连接框架，可促进可靠而安全的系统集成，并同时减少应用程序接口的数量、大小和复杂度。

　功能要求 服务储存库 服务分类：服务储存库需支持自定义、可配置的服务分类，用户可以从实验室业务角度和技术角度对服务进行分类，同时对服务分类提供遵循 UDDI 规范的分类校验服务。针对每一个自定义的分类方法，都提供了一个校验服务，可以根据用户自定义的服务分类法执行服务分类正确性的校验。

　服务检索：需提供服务检索，用户可以根据业务相关的分类法，方便地进行服务的导航和搜索，加速服务的发现。

　生命周期管理：服务储存库还需支持服务生命周期管理，包括服务审批、变更通知和 QoS 管理。

　服务变更管理：需提供服务变更管理功能，支持变更的通知和订阅，能够实现将注册数据的变动主动地通知到管理员或者相应的流程。

　服务注册管理 服务注册管理需实现集中管理实验室各类需业务协同的应用服务。包括服务开发语义的定义、服务的注册申请、服务的失效检测（自动失效、过期失效等）、服务的申请审核等。

　为了完全支持全面的 SOA 中所需的各种集成模式（如请求/响应、发布/订阅和事件等），服务注册管理需在应用集成平台中支持三个主要集成方式：

　SOA：其中应用程序需通过具有定义良好的显式接口的可重用服务进行通信。面向服务的交互将充分利用底层消息传递和事件通信模型。

　消息驱动的体系结构：应用程序需通过企业服务总线发送消息，以调用其他应用程序。

　事件驱动的体系结构：其中应用程序需以彼此独立的方式生成和使用消息。

　服务流程协调引擎 服务流程协调引擎需支持应用以多种方式（同步、异步、发布订阅）对服务的调用。需支持自动捕捉服务的变化、失效时间的自动判断等。

　安全管理 需提供对发布的 Web 服务进行权限控制、认证服务。包括服务发布对象、调用对象的认证、服务的调用数据控制等。

　业务活动监控 需实现对服务的访问、调用、变化等进行全局的监控。

　业务流程管理与服务 技术要求 需实现各种业务环节整合的全面管理模式。支持跨应用、跨部门、跨人员与用户的业务与事务运作。应具有以下特点 业务流程的执行规范

　支持 WS-BPEL 2.0 和 BPEL4WS 1.1 等流程标准 支持状态流程和非状态流程 支持基于消息和基于时间的触发处理 支持 WS-Security、Kerberos 等流程安全协议 支持内容在流程节点之间安全广播 数据维护与可扩展性 支持 XPath 1.0/2.0、XSLT 1.0/2.0、XQuery 1.0 和 E4X 等数据处理协议 支持通过 API 自定义和扩展业务流程的数据需求 工作流定义与使用者的交互 支持 WS-Human Task 1.1 和 BPEL4People 1.1 等规范进行交互行为定义 支持人与工作流程节点绩效及整个流程绩效的对应 支持与统一身份认证紧密集成而实现用户在业务流程中的身份、角色和权限匹配 能够通过友好的用户界面自定义创建各业务流程任务 能够创建和自定义各个业务流程及节点的关键性绩效指标（KPI ）

　多种人性化的业务流程节点和业务流程总体绩效统计和分析报表 能过通过图形化管理界面进行流程管理和配置 能通过图形化管理界面进行业务流程管理，并支持可视化的 Drag-n-drop 支持按照自定义方式实现业务流程创建和管理 支持流程业务的导入和导出 支持图形化的业务流程灵活部署、动态升级和业务流程发布 支持图形化的业务流程终止、暂停、恢复、重试、审计、故障处理和清理 易于与现有信息系统集成 支持 MySQL、MSSQL、Oracle 和 DB2 等主流数据库 支持多种身份认证授权与访问控制系统，如 LDAP、 Microsoft Active Directory 或任何 JDBC 数据库等 提供能与其他信息系统统进行集成的 API 高可用性，可扩展性和稳定性 支持无状态的服务器水平伸缩 分布式缓存以提高业务流程的处理性能 支持高可用部署 能并发支持多种应用的业务流程执行 能在低资源消耗情况下长期稳定运 轻量级、开发者友好和易于部署 容易进行业务流程的跟踪测试 支持通过中间件的配置实现服务器功能特性定制 支持与 SVN、Maven、Ant、Eclipse 等开发、部署标准工具进行集成 具有人性化的图形开发与配置界面 管理和监控 支持高安全性的、基于 Web...

相关热词搜索：协同 实验室 项目