之江實驗室協(xié)同平臺系統(tǒng)項目
發(fā)布時間:2020-07-09 來源: 入黨申請 點擊： 
之江實驗室協(xié)同平臺系統(tǒng) 項目
招標文件
采購方式：公開招標 項目編號：CTZB-F180929BWB-ZJSYS1
采購人：
之江實驗室 （蓋章）
采購代理機構：
浙江省成套招標代理有限公司 （蓋章）
二〇一八年 九月 月
目錄 目錄 .................................................................................................................................................. 2 第一章
招標公告 ............................................................................................................................. 3 第二章
采購需求總體要求 .............................................................................................................. 5 第三章
采購需求具體要求 .............................................................................................................. 6 第四章
采購合同 ........................................................................................................................... 46 第五章
評標辦法 ........................................................................................................................... 50 第六章
投標人須知 ....................................................................................................................... 54 第七章
投標文件格式 .................................................................................................................... 67
第一章
招標公告 參照《中華人民共和國政府采購法》等有關規(guī)定，浙江省成套招標代理有限公司受之江實驗室委托，就之江實驗室協(xié)同平臺系統(tǒng)項目進行公開招標，歡迎國內合格的供應商前來投標。
一.項目名稱：之江實驗室協(xié)同平臺系統(tǒng)項目 二.項目編號：CTZB-F180929BWB-ZJSYS1 三.招標項目概況（內容、用途、數(shù)量、簡要技術要求等）：
序號 標項內容 數(shù)量 單位 預算金額 簡要技術要求 備注 1 協(xié)同平臺系統(tǒng) 1 項 238萬元 統(tǒng)一身份認證平臺、信息標準體系、主數(shù)據(jù)管理平臺、數(shù)據(jù)交換共享與業(yè)務應用集成平臺、一站式服務門戶、智慧移動平臺、協(xié)同辦公 OA 系統(tǒng)、EHR 人事管理系統(tǒng) 本項目最高限價：238 萬元 四.投標供應商資格要求：
（1）具有獨立承擔民事責任的能力； （2）具有良好的商業(yè)信譽和健全的財務會計制度； （3）具有履行合同所必需的設備和專業(yè)技術能力； （4）有依法繳納稅收和社會保障資金的良好記錄； （5）參加政府采購活動前三年內，在經(jīng)營活動中沒有重大違法記錄； （6）供應商未被列入失信被執(zhí)行人名單、重大稅收違法案件當事人名單、政府采購嚴重違法失信行為記錄名單，信用信息以投標截止日信用中國網(wǎng)站（www.creditchina.gov.cn）、中國政府采購網(wǎng)（www.ccgp.gov.cn）公布為準； （7）單位負責人為同一人或者存在直接控股、管理關系的不同供應商，不得參加同一合同項下的政府采購活動； （8）非聯(lián)合體。
五.招標文件的發(fā)售時間及地點等：
時間：2018 年 10
月
08 日起至 2018 年 10
月
12 日（雙休日及法定節(jié)假日除外），上午：8：30-11：30，下午：14：30-17：30 地點：杭州市文暉路 42 號現(xiàn)代置業(yè)大廈西樓 17 層 1706 室（文暉大橋西側下橋口）
售價（元）：每本 500（售后不退）
支付方式：現(xiàn)金、匯票、支票、銀行轉帳等 收款單位（戶名）：浙江省成套招標代理有限公司 開
戶：中信銀行杭州西湖支行 賬
號：73326385 獲取方式：現(xiàn)場獲取，或將報名資料掃描件發(fā)送至并致電采購代理機構聯(lián)系人獲取 六.投標截止時間：2018 年 10
月
22 日 09 時 30 分 七.投標地點：杭州市文暉路 42 號現(xiàn)代置業(yè)大廈西樓 17 層 1702 開標室 八.開標時間：2018 年 10
月 22
日 09 時 30 分 九.開標地點：杭州市文暉路 42 號現(xiàn)代置業(yè)大廈西樓 17 層 1702 開標室 十.投標保證金：
投標保證金：40100 元
支付方式：電匯（網(wǎng)銀）等 收款單位（戶名）：浙江省成套招標代理有限公司 開
戶：中信銀行杭州西湖支行 賬
號：73326385 十一..其他事項：
1、本項目公告期限為 5 個工作日，供應商認為采購文件使自己的權益受到損害的，可以自收到采購文件之日（發(fā)售截止日之后收到采購文件的，以發(fā)售截止日為準）或者采購文件公告期限屆滿之日（公告發(fā)布后的第 6 個工作日）起 7 個工作日內，以書面形式向采購代理機構提出質疑。質疑供應商對采購人、采購代理機構的答復不滿意或者采購人、采購代理機構未在規(guī)定的時間內作出答復的，可以在答復期滿后十五個工作日內向采購人的采購監(jiān)督管理部門投訴。質疑函范本、投訴書范本請到浙江政府采購網(wǎng)下載專區(qū)下載。
2、投標人購買標書時應提交的資料：
1）介紹信或法定代表人（單位負責人）授權書（原件）； 2）被授權人身份證（原件和復印件）； 3）有效的營業(yè)執(zhí)照副本（或法人證書）等復印件（復印件加蓋單位公章）； 4）銀行開戶許可證（復印件加蓋單位公章）； 3、采購項目需要落實的政府采購政策 對符合財政扶持政策的中小企業(yè)（小型、微型）、監(jiān)獄企業(yè)、殘疾人福利性單位給予價格優(yōu)惠扶持； 4、其他事項 1）未經(jīng)報名登記并獲取招標文件的供應商參與本項目投標，將被拒絕； 2）招標文件發(fā)售截止時間之后潛在供應商仍然可以獲取招標文件； 3）書面質疑受理地點：杭州市文暉路 42 號現(xiàn)代置業(yè)大廈西樓 17 層 1701 室，聯(lián)系人：張女士、陳先生，聯(lián)系電話：； 十二.聯(lián)系方式 1、采購代理機構名稱：浙江省成套招標代理有限公司 聯(lián)系人：干祥平 聯(lián)系電話：
傳真：
地址：杭州市文暉路 42 號現(xiàn)代置業(yè)大廈西樓 17 層 1706 室 2、采購人名稱：之江實驗室 聯(lián)系人：鐘老師 電話：
技術聯(lián)系人：
溫老師 電
話：
地
址：浙江省杭州市文一西路 1818 號之江實驗室 10 號樓 6 層 附：招標文件
第二章
采購需求總體要求 一、技術標準、規(guī)范（不限于以下）
1、國家規(guī)定的標準及規(guī)范，按最新的標準及規(guī)范執(zhí)行。
2、行業(yè)標準及規(guī)范，按最新的標準及規(guī)范執(zhí)行。
3、與服務有關的材料設備質量應符合中華人民共和國及產品品牌所在國的有關質量標準，上述標準如有不一致，執(zhí)行兩者中更嚴格的標準。
4、其它相關標準及規(guī)范，按最新的標準及規(guī)范執(zhí)行。
二、采購內容及需求 具體要求詳見招標文件的“第三章 采購需求具體要求”。
三、工作范圍 各投標人須按國家有關標準及規(guī)范完成招標文件規(guī)定的所有工作內容：
1、履行所有規(guī)定服務； 2、服務成果須達到招標文件規(guī)定的質量標準及使用要求。
第三章
采購需求具體要求 一、采購內容一覽表 序號 標項名稱及內容 數(shù)量 單位 實施周期 備注 1 協(xié)同平臺系統(tǒng) 1 項 130 個日歷日
二、采購需求 1 、系統(tǒng)服務內容 序號 服務要求 數(shù)量/單位 1 統(tǒng)一身份認證平臺 1 套 2 信息標準體系 1 套 3 主數(shù)據(jù)管理平臺 1 套 4 數(shù)據(jù)交換共享與業(yè)務應用集成平臺 1 套 5 一站式服務門戶 1 套 6 智慧移動平臺 1 套 7 協(xié)同辦公 OA 系統(tǒng) 1 套 8 EHR 人事管理系統(tǒng) 1 套 2 、總體目標 2.1 協(xié)同服務平臺核心支撐系統(tǒng)建設的總體目標和要求如下：
以信息安全、統(tǒng)一認證平臺為核心基礎，以移動化、數(shù)據(jù)化、國際化、生態(tài)化為總體策略方針。
助力業(yè)務發(fā)展，為辦公、行政、財務、采購、人力、法務、科研等業(yè)務提供基礎技術支撐。實現(xiàn)辦公無紙化和移動化，業(yè)務應用和數(shù)據(jù)云端化，項目管理、業(yè)務分析數(shù)據(jù)化。
核心支撐系統(tǒng)建設充分考慮之江實驗室“一體、雙核、多點”的混合所有制開放融合特征，在整個生態(tài)體系內認證、數(shù)據(jù)、接口、應用實現(xiàn)安全分級、互連互通。
2.2 具體來講，該項目建設完成后應該實現(xiàn)如下目標：
1）實現(xiàn)智慧園區(qū)+微服務平臺建設的堅實基礎框架。本次建設須建成先進、穩(wěn)定、可擴展的核心支撐系統(tǒng)平臺；該平臺至少包括但不限于以下系統(tǒng)：統(tǒng)一身份認證平臺、信息標準體系、主數(shù)據(jù)管理平臺、數(shù)據(jù)交換共享與業(yè)務應用集成平臺、一站式服務門戶、智慧移動平臺。要求該核心支撐系統(tǒng)與各個業(yè)務系統(tǒng)之間形成松耦合架構體系，并具備能為用戶提供一站式服務的能力。
2）實現(xiàn)多種方式的統(tǒng)一身份認證、授權和訪問控制并具有可擴展性。本次建設的“統(tǒng)一身份認證平臺”必須能實現(xiàn)對實驗室所有系統(tǒng)的身份認證、授權、訪問控制和單點登錄管理，要求身份認證準確安全，授權和訪問控制的控制粒度精細、具有柔性，其中授權粒度應能支持到具體的業(yè)務、服務或數(shù)據(jù)內容級別。
3）實現(xiàn)“一站式”服務。實現(xiàn)對實驗室主要業(yè)務應用系統(tǒng)進行業(yè)務應用層面的調用與整合，并把整合好的業(yè)務流程綜合展現(xiàn)在“一站式服務門戶”之上，使得最終用戶只需在“一站式服務門戶”進行簡單填表式操作就能完成各種業(yè)務辦理，從而實現(xiàn)“一站式”服務。同時，能夠適應未來日趨復雜和動態(tài)變化的更多業(yè)務流程。
4）實現(xiàn)信息標準體系、主數(shù)據(jù)管理平臺建設。本項目建設完成后，所有已建成或待建應用系統(tǒng)均須按信息標準體系嚴格執(zhí)行信息標準，各應用系統(tǒng)數(shù)據(jù)統(tǒng)一同步到主數(shù)據(jù)倉庫，并統(tǒng)一由共享數(shù)據(jù)
庫提供數(shù)據(jù)共享和交換服務所需的數(shù)據(jù)。
5）實現(xiàn)數(shù)據(jù)交換共享與業(yè)務應用集成平臺建設。本項目建設完成后，數(shù)據(jù)共享和交換應該由業(yè)務流程驅動，實現(xiàn)業(yè)務流程辦理到哪個節(jié)點則數(shù)據(jù)流動到哪個節(jié)點，實現(xiàn)業(yè)務流程和數(shù)據(jù)流動的同步及一體化。
6）實現(xiàn)業(yè)務流程管理柔性化和可自定義配置。該項目建設要求能提供豐富多樣的流程管理配置、流程節(jié)點與流程總體績效統(tǒng)計和分析、以及實現(xiàn)圖形化便捷配置管理和自助式二次開發(fā)。為適應實驗室的業(yè)務眾多且會經(jīng)常發(fā)生變更，要求業(yè)務流程管理應該具備充分的柔性和可自定義配置性。流程引擎能用于“一站式服務門戶”中輕應用的流程控制和開發(fā)。
7）實現(xiàn)“一站式服務門戶”成為綜合性用戶終端。要求“一站式服務門戶”要成為功能強大、技術先進、美觀易用的信息管理、業(yè)務/事務處理的綜合性用戶終端。不僅支持主流瀏覽器，還能支持主流的移動終端設備和主流的移動端操作系統(tǒng)（如 IOS 和 Android 等）。另外，上述“一站式服務門戶”要求能提供完善的二次開發(fā)工具包，以保障實驗室的自主開發(fā)需求。
8）▲應用系統(tǒng)集成，完成當前已有系統(tǒng)企業(yè)釘釘、財務復旦天翼（含接口對接經(jīng)費）、阿里郵箱、網(wǎng)絡接入身份驗正以及當前新增系統(tǒng)辦公 OA、人事系統(tǒng)統(tǒng)一認證和集成。建設統(tǒng)一應用基礎平臺，統(tǒng)一技術標準為將來二期應用需求集成夯實基礎。
附：應用系統(tǒng)集成需求展示圖
3 、項目服務要求
3.1 總體技術要求 供應商所提供的所有各項 系統(tǒng)應符合如下要求：
1）供應商提供的各項設備及系統(tǒng)的功能、性能應完全符合磋商文件指明的標準，并滿足或高于磋商文件指出的要求。本磋商文件中未說明但國際、國家和行業(yè)標準已有建議的設備功能與性能的條款，應符合相應的最新標準與建議。
2）供應商須承諾所提供的所有軟件產品知識產權權屬清晰。本次磋商文件中所涉及的第三方軟件的使用權歸采購人所有。其它相關權屬關系雙方通過合同予以明確。
3 ）供應商提供的系統(tǒng)應基于 Java EE 規(guī)范的總體技術路線。
4 ）供應商提供的系統(tǒng)應使用 B/S 架構實現(xiàn)。
5 ）供應商提供的系統(tǒng)要實現(xiàn)與釘釘?shù)臒o縫集成。本次采購的系統(tǒng)要基于 H5 頁面響應式布局的態(tài) 方式與釘釘集成且能夠自適應各種移動終端，不能以開發(fā)原生態(tài) APP 方式實現(xiàn)移動終端使用；用戶通過釘釘帳號、手機號與實驗室賬戶綁定后經(jīng)統(tǒng)一身份認證登錄門戶平臺，實現(xiàn)平臺消息通知推送到釘釘；采購人今后上線的微應用服務均支持無縫發(fā)布到釘釘且無需付費做二次開發(fā)。
6 ）供應商提供的系統(tǒng)要求能夠在采購人本地私有云 VMware Esxi5.0 及以上版本服務器虛擬化集群環(huán)境中平滑部署。
7 ）供應商提供的系統(tǒng)應基于 SOA 理念，采用面向服務和基于總線的架構進行構建。
8 ）能夠基于統(tǒng)一的平臺框架設計開發(fā)本期建設的服務平臺，并開放提供本期項目所有平臺及系統(tǒng)的源代碼，提供相應的開放工具及環(huán)境，以便供采購人未來進行進一步開發(fā)使用。（供應商必須提供蓋有公章的承諾函原件）
9 ）供應商必須免費開放提供各種接口（供應商必須提供蓋有公章的承諾函原件）。
10 ）采購人在任何時候都保留和擁有對本文件的解釋權。采購人有權在簽訂合同前，根據(jù)需完善和補充技術規(guī)范書，修改后的最終技術規(guī)范書將作為合同的附件。
供應商應當充分理解采購人需求并為采購人提供定制化系統(tǒng)設計方案；如因招標文件未對相關需求做出明確約定而發(fā)生系統(tǒng)設計方案和項目最終交付結果無法滿足采購人需求的，采購人可以補充提出需求（補充需求工作量應小于本標里 書總任務里 5% ）
，若采購人補充提出需求后供應商不同意修改的，采購人有權無條件中止合作，并要求供應商返還采購人已支付的全部費用。
3.2 性能規(guī)范要求 系統(tǒng)運行支持萬級 用戶量。
持 頁訪問并發(fā)用戶支持 1000 人同時訪問。
證 系統(tǒng)保證 7*24 小時運行。
于 平均延時小于 5 秒，最大延時不超過 15 秒。
支持負載均衡，具備可擴展性。
支持遠程管理。
系統(tǒng)在異常情況下能夠自動恢復，具備較強的安全保護措施和故障恢復能力。
3.3 安全規(guī)范要求 系統(tǒng)提供相應數(shù)據(jù)備份/ 恢復功能，制定合理的備份策略提供保護機制。
系統(tǒng)具備完善的使用授權、監(jiān)控和日志管理機制，能夠 對用戶。
訪問及敏感數(shù)據(jù)的操作進行審計。
持 系統(tǒng)支持 HTTPS 訪問方式。
系統(tǒng)支持對數(shù)據(jù)的正確性和完整性進行驗證。
系統(tǒng)支持對敏感數(shù)據(jù)進行加密。
止 系統(tǒng)具備防止 SQL 等注入的攻擊機制。
所投平臺的產品應具有國家或行業(yè)認可的安全評測機構評測報告。
3.4 擴展規(guī)范要求 供應商應充分考慮本項目在后續(xù)運行、管理過程中的業(yè)務功能擴展的要求。在充分滿足當前業(yè)務需求的基礎上，供應商須對系統(tǒng)的擴展性進行認真分析與設計，提供具體的滿足擴展性要求的方案，以確保系統(tǒng)可滿足后續(xù)業(yè)務發(fā)展的需求：
要求在不編寫程序代碼的情況下使用圖形化界面能夠進行個性化設置。
集群部署的各節(jié)點能夠彈性增加或減少。
4 、技術要求 4.1 核心支撐系統(tǒng) 4.1.1 統(tǒng)一身份認證平臺 統(tǒng)一身份認證平臺通過構建全局性的用戶身份管理、信息管理和授權管理的中心，保障實驗室信息資源的有序應用，確保實驗室資源和服務的安全；實現(xiàn)用戶的統(tǒng)一管理，提高用戶集中式管理的效率，降低維護成本；實現(xiàn)用戶身份的統(tǒng)一認證，減輕用戶在用戶名和密碼管理上的負擔；建立多樣化的認證方式，滿足不同業(yè)務的不同安全級別要求；為應用安全在統(tǒng)一身份認證、授權、單點登錄和數(shù)據(jù)傳輸/存儲加密等方面提供保障。
系統(tǒng)建設應達到如下目標：
需實現(xiàn)便捷、多樣化的認證登錄方式。例如可以實現(xiàn)輸入用戶名、Email、手機號碼、工作證號/學號和密碼等多種方式登錄。同時支持用戶名密碼、認證碼和/或數(shù)字證書等多種認證方式。
需實現(xiàn)安全的單點登錄（SSO）。
需實現(xiàn)符合實驗室組織機構、人員、角色、崗位、權限和資源特點的權限管理、授權方式及訪問控制策略。
需建立用戶身份（例如跨部門任職兼職、多重身份）管理機制，提供靈活方便的身份異動管理，例如身份異動后，相應權限自動撤銷、變更和加載。為權限管理系統(tǒng)或其他業(yè)務系統(tǒng)提供一個方便的身份識別及管理服務。
需建立靈活、方便的權限管理模型，減輕管理負擔。要特別注意“崗位”、“角色”、“用戶”及“資源”的關系設置。權限管理要有高度靈活性和自動性。
能與現(xiàn)有系統(tǒng)實現(xiàn)無縫集成。一次性建立全局性崗位和角色后，可直接應用到所有系統(tǒng)中，除部分與某些信息系統(tǒng)有特別緊密聯(lián)系的角色外，所有角色均在統(tǒng)一權限管理系統(tǒng)中進行集中式管理。用戶角色、權限管理可實現(xiàn)各系統(tǒng)管理員或指定管理員分級進行管理，但角色權限信息必須統(tǒng)一存放在身份識別與訪問控制平臺中。同時，能夠為未來新建信息系統(tǒng)的開發(fā)提供統(tǒng)一的認證、授權及安全標準。
需提供完備的安全日志及審計、安全風險預警及管理功能。
需支持負載均衡和多機備份等。
需采用開源 CAS 作為 SSO 內核。
需建立數(shù)據(jù)傳輸及存儲的加密機制。
需提供便捷的圖形化管理和配置工具。
統(tǒng)一身份認證平臺應基于 LDAP 技術，實現(xiàn)統(tǒng)一用戶身份認證和權限控制體系，利用目錄服務，對用戶身份信息和系統(tǒng)控制信息進行有效組織管理，提供高效安全的目錄訪問，為各應用系統(tǒng)提供統(tǒng)一身份認證和權限控制的支持。
需支持 RADIUS 協(xié)議，能滿足 VPN、入網(wǎng)認證等網(wǎng)絡設備的認證需求。
1）技術要求 應采用企業(yè)級、開源項目進行核心支撐系統(tǒng)的中心身份認證授權與訪問控制平臺的開發(fā)，具體要求如下：
系統(tǒng)和用戶身份管理 需提供 API，對于任何應用，均支持身份認證授權及訪問控制集成。
需提供除用戶名與密碼外的更多樣化電子身份認證技術如 CA、園區(qū)卡、電子簽章或簽名、生物特征識別技術等。
需支持通過 OpenID，SAML2，Kerberos 等協(xié)議或技術實現(xiàn)密鑰分發(fā)，支持單點登錄（SSO）
支持內部系統(tǒng)和云應用程序之間的 SSO 橋接 支持跨越不同協(xié)議的證書映射 支持通過 xdas 等的審計 支持通過 OAuth 1.0a, OAuth 2.0 和 WS-Trust 等的授權 支持通過 OpenID, SAML2, and WS-Trust STS 等的聯(lián)合認證 支持采用 OAuth 2.0 和 XACML 等實現(xiàn) REST 安全 支持用于密鑰存儲和分發(fā)的 XKMS 支持基于 REST 安全的 OpenID 連接 支持可信的 SAML2 身份提供者 支持針對 OpenID，OAuth，OpenID 等的連接，SAML2，STS 的可定制化登錄頁面 應具有完善的身份基礎信息，具備自動和手工身份信息完善與變更功能 用戶和用戶組定制 需支持 SCIM 等標準的用戶與用戶組定制 需支持用戶自定義配置 用戶和組管理 需提供基于 Web 的用戶和用戶組管理 需為用戶信息存儲提供靈活的支持，如內置的 LDAP（、外部的 LDAP，微軟 Active Directory、Apache Cassandra、以及任何 JDBC 數(shù)據(jù)庫等 需支持靈活的配置管理，可為每個用戶提供多個配置文件 需支持對超過嘗試失敗次數(shù)的帳戶進行鎖定 需支持密碼驗證/過期策略 需支持通過電子郵件、手機和保密問題實現(xiàn)帳戶恢復 授權管理 需實現(xiàn)基于角色和角色組的訪問控制 需實現(xiàn)基于導入或自定義訪問控制規(guī)則的授權 需實現(xiàn)通過 XACML 等實現(xiàn)基于訪問控制規(guī)則的細粒度策略 需支持先進的授權管理和審核 需支持 REST、SOAP 等的調用授權管理 角色管理需支持單身份多角色授權。
需實現(xiàn)統(tǒng)一授權和分級授權相結合。即平臺提供統(tǒng)一的基本授權，而各個業(yè)務系統(tǒng)能根據(jù)基本授權實現(xiàn)更為精細的授權。
需實現(xiàn)根據(jù)相關業(yè)務系統(tǒng)數(shù)據(jù)和訪問控制規(guī)則自動給出基本授權并給出相關信息。
需實現(xiàn)訪問控制規(guī)則管理。
支持 XACML2.0/3.0 需支持策略編輯的用戶友好的界面
需支持多策略信息點（PIP）
需支持探索策略影響效果的 Trylt 工具 需支持各種不同的策略決策點（PDP）分配政策 需支持決策和屬性緩存 需支持 PEP / PDP 交互的高性能網(wǎng)絡協(xié)議 需支持策略更新通知
需支持使用策略管理點（PAP）來管理多個策略決策點（PDP）
需支持可定制的策略管理界面 輕量級，對開發(fā)者友好和易于部署 需支持完整的 SOAP API，能整合/嵌入任何應用程序或系統(tǒng) 需支持可插拔的工作流授權操作 需具有擴展性，支持可插拔認證，可選擇的用戶存儲，具有 XACML / SAML 擴展點 需支持高可用集群部署 需支持無需更改配置即實現(xiàn)本地服務器、私有云或公共云的部署選擇 需支持對 ESB 的授權和產品認證集成 管理和監(jiān)控 需支持安全的 Web 綜合管理和監(jiān)視控制 需支持內置標準的訪問和性能統(tǒng)計采集、監(jiān)控 需支持關鍵指標的監(jiān)測和管理 需支持業(yè)務審計和 KPI 績效的監(jiān)控和管理集成 需支持集成到記錄系統(tǒng)的靈活日志支持 需實現(xiàn)集中式的配置管理，通過整合注冊表支持生命周期和版本控制 用戶認證授權的自助服務 需實現(xiàn)個人信息維護：用于對個人賬號信息、密碼信息的維護。
需實現(xiàn)密碼找回：包括通過郵箱找回密碼、通過回答問題找回密碼、通過手機找回密碼等常見的密碼找回機制。
需實現(xiàn)賬號日志：用于查詢賬號的登錄情況、賬號的維護情況。
需實現(xiàn)權限申請：用于申請基礎權限及各業(yè)務系統(tǒng)的特有權限。
2）功能要求 用戶管理 需提供用戶管理功能管理用戶基本信息，主要包括：
用戶注冊 賬號關聯(lián) 組織機構管理 崗位管理 用戶管理 角色管理 權限控制 用戶身份認證通過后，必須對用戶的應用系統(tǒng)使用權限進行統(tǒng)一控制，主要功能包括：
應用系統(tǒng)基礎信息管理 模塊組基礎信息管理 模塊基礎信息管理 應用系統(tǒng)權限管理 用戶權限管理 崗位權限管理 用戶授權管理 用戶身份認證 需提供身份認證的異構系統(tǒng)支持，提供標準的認證集成接口，供其它系統(tǒng)的開發(fā)商調用。標準接
口的實現(xiàn)有如下幾種：
.Net 接口 JAVA 接口 ASP 接口 PHP 接口 C/C++接口 ISAPI 接口 Perl 接口 VBScript 接口 WebServics 接口 其他接口 管理操作審計 需支持對所有用戶所做的權限變化過程記錄日志，并提供相應的查詢功能。
認證集成服務 統(tǒng)一身份認證平臺應包含三個部分：統(tǒng)一用戶管理、統(tǒng)一身份認證和統(tǒng)一權限管理，在平臺建設與應用系統(tǒng)的集成方面也應包括這三部分的集成。
用戶集成 用戶集成目標 所有用戶的管理需在統(tǒng)一身份認證平臺集中進行，應用系統(tǒng)不再管理用戶信息，所需的用戶信息完全來自于統(tǒng)一身份認證平臺。
用戶集成方式 需支持由統(tǒng)一身份認證平臺進行身份認證 也需支持業(yè)務系統(tǒng)保留自己的身份認證，建立用戶映射表 認證集成 認證集成目標 各應用系統(tǒng)的身份認證均需在統(tǒng)一身份認證平臺集中進行，應用系統(tǒng)不需再對用戶身份進行校驗。
認證集成方式 需支持改造應用系統(tǒng)，采用統(tǒng)一認證接口認證 需支持改造應用系統(tǒng)，保留系統(tǒng)原有認證界面 需支持不可改造應用系統(tǒng)，代理認證 認證集成接口 針對以后在統(tǒng)一身份認證平臺基礎上開發(fā)的新系統(tǒng)，需提供標準的認證集成接口，供新系統(tǒng)的開發(fā)商調用。標準接口的實現(xiàn)需具備有如下幾種：
DotNet 接口 JAVA 接口 ASP 接口 PHP 接口 C、C++接口 其他接口 權限集成 權限集成目標
利用統(tǒng)一身份認證平臺提供的權限管理工具統(tǒng)一管理應用系統(tǒng)所需管理的是用戶的數(shù)據(jù)權限。
在權限管理體系上，需支持采用分級授權模式，即由統(tǒng)一身份認證平臺將某應用系統(tǒng)的管理權限授給該應用系統(tǒng)管理員，由該應用系統(tǒng)的管理員來管理和設置本系統(tǒng)的所有用戶使用權限，所有權限數(shù)據(jù)由統(tǒng)一身份認證平臺集中存儲。
權限集成方式 數(shù)據(jù)交換 需分析業(yè)務系統(tǒng)權限數(shù)據(jù)表結構、關系，支持通過數(shù)據(jù)交換的方式進行權限集成。業(yè)務系統(tǒng)無須改造原有系統(tǒng)的權限訪問控制代碼。但權限數(shù)據(jù)的管理，須在統(tǒng)一身份認證平臺中進行管理。
改造系統(tǒng) 統(tǒng)一身份認證平臺需提供權限操作、管理相關的接口（webservice），由業(yè)務系統(tǒng)調用這些接口并修改系統(tǒng)的權限訪問控制代碼。原有系統(tǒng)的權限數(shù)據(jù)的管理被廢除，完全在統(tǒng)一身份認證平臺中進行管理。
集成接口 針對以后在統(tǒng)一身份認證平臺基礎上開發(fā)的新系統(tǒng)，需提供多種標準的權限集成接口，供新系統(tǒng)的開發(fā)商調用。
系統(tǒng)管理與監(jiān)控 系統(tǒng)管理功能需實現(xiàn)對平臺運行起支撐作用的數(shù)據(jù)管理和功能設置，包括操作日志管理、管理員管理和配置管理功能。
系統(tǒng)管理與監(jiān)控需提供一套完整的基于 WEB 的統(tǒng)一身份認證平臺運行監(jiān)控工具，界面為中文界面，可以遠程管理身份數(shù)據(jù)。能夠監(jiān)控平臺的目錄服務、認證服務、認證接口的運行狀態(tài)，針對圍繞身份認證相關的系統(tǒng)服務進行統(tǒng)一的管理，提供對身份認證系統(tǒng)相關的服務進行“啟動/停止”控制，具有自我監(jiān)控機制，發(fā)現(xiàn)異常后可自動告警；同時還提供歷史事件的查詢和認證會話的相關操作。
系統(tǒng)管理與監(jiān)控功能需為管理員提供及時的風險預警功能，可審計出異常的帳號、不合理的認證行為和授權行為，用于發(fā)現(xiàn)系統(tǒng)可能存在的安全問題和隱患。系統(tǒng)提供對用戶數(shù)據(jù)、組數(shù)據(jù)、用戶和組關系的批量維護功能，方便用戶使用。
系統(tǒng)需提供管理控制臺，對平臺運行的所有服務進行配置、預警并響應，提供管理員管理、系統(tǒng)啟動與停止、日志管理、會話管理、數(shù)據(jù)備份恢復與導入導出和平臺參數(shù)配置功能。
系統(tǒng)需支持監(jiān)控平臺的目錄服務、認證服務、認證接口的運行狀態(tài)。
4.1.2 信息標準體系 信息標準的制定應基于國家相關標準，尊重實驗室已有標準，兼顧各個標準之間的兼容性、一致性以及標準的可擴展性。標準應充分考慮到實驗室各信息系統(tǒng)運行現(xiàn)狀，標準體系需擁有明確的標準沖突解決辦法，能夠保證新制定的信息標準完成數(shù)據(jù)的準確交換與共享，確保標準制定過程及結果的科學性。
標準規(guī)范體系的設計應遵循如下原則：
標準的兼容性 標準的實施對各職能部門信息系統(tǒng)建設、信息的交流與共享、數(shù)據(jù)的收集、分析、發(fā)布所采用的信息標準必須和國家標準相兼容。
標準的唯一性 在一個分類編碼標準中，每一編碼對象僅有一個賦予它的代碼，一個代碼只唯一表示一個編碼對象，不能具有任何二義性； 標準的可擴性 代碼結構必須能適應同類編碼對象不斷增加的需求，必須為新的編碼對象留有足夠的備用碼，以
適應不斷擴充的需求； 標準的簡單性 代碼結構應盡量簡單，長度盡量短，以便節(jié)省機器存儲空間和減少代碼的差錯率；同時，提高機器處理的效率； 標準的規(guī)范性 在一個信息編碼標準中，代碼的結構、類型以及編寫格式必須統(tǒng)一； 標準的適用性 代碼要盡可能的反映分類對象的特點，便于記憶，便于填寫； 標準的合理性 代碼結構要與分類體系相適應。
標準的全面性 信息標準不僅需包含國家及實驗室本身的業(yè)務標準集，還需在業(yè)務標準的基礎上構建用戶數(shù)據(jù)模型標準、數(shù)據(jù)分析模型標準、數(shù)據(jù)倉庫標準等，用以實現(xiàn)實驗室的業(yè)務優(yōu)化過程，充分利用好各類數(shù)據(jù)。
標準的兼容性 采用的信息標準必須嚴格遵守國家最新信息標準�？梢詫Ω髀毮懿块T信息系統(tǒng)建設、信息的交流與共享、數(shù)據(jù)的收集、分析、發(fā)布起到指導和規(guī)范作用。
標準建設內容要求 信息標準應包括參照標準、執(zhí)行標準以及參照標準與執(zhí)行標準的對比等內容。
信息標準規(guī)范 需使用國家最新的管理信息標準和規(guī)范，建立一個符合國家標準規(guī)范的行業(yè)標準，從制度上保證整個系統(tǒng)的標準化和可擴展性。
數(shù)據(jù)標準 推薦常用信息編碼規(guī)則 常用的信息編碼需包括園區(qū)編碼、組織機構編碼、工號、項目號、房間號、設施號、會議號、設備號等。
信息標準數(shù)據(jù)的 ER 圖 需提供標準標準數(shù)據(jù)的 ER 圖。
代碼標準 編碼集應采用二種編碼。第一種是國家已經(jīng)公布的國家標準代碼；第二種是實驗室自編信息代碼，二者合一最終形成實驗室的標準編碼庫。所有數(shù)據(jù)均需符合國家標準，國家沒有統(tǒng)一標準的建立實驗室的內部標準。
需支持數(shù)據(jù)打印輸出轉換標準，滿足各業(yè)務系統(tǒng)向上級或相關部門報送數(shù)據(jù)報表的需求。
業(yè)務表標準 應采用國家標準為基本標準，保證標準的兼容性。
代碼表標準 需以國家標準為基礎，在此基礎上根據(jù)實驗室的業(yè)務需求進行有限的擴充，如果需采用實驗室內部標準，則必須采用代碼對應表形式，與國家標準相匹配。數(shù)據(jù)打印輸出時需支持轉換標準，滿足各業(yè)務系統(tǒng)向上級或相關部門報送數(shù)據(jù)報表的需求。
自定義代碼表標準 需根據(jù)實驗室需構建自定義代碼表，采用標準的代碼、名稱以及類別機制，可根據(jù)業(yè)務需進行字段擴充，自定義代碼表支持標準擴充，如一位編碼擴充為兩位，要求原編碼位數(shù)標準要高于實際需求
的位數(shù)。
編碼標準 需以國家標準為基礎，根據(jù)實驗室的實際情況制定編碼規(guī)則。
交換標準 需通過建設數(shù)據(jù)交換與集成平臺，構建一個標準的、開放的實驗室業(yè)務領域通用信息模型，并提供通用的數(shù)據(jù)接口，作為集成標準。通用信息模型可以為各應用系統(tǒng)提供統(tǒng)一數(shù)據(jù)模型和編碼，通用數(shù)據(jù)接口可以消除接口與技術協(xié)議的差異性，滿足應用需求的變化，實現(xiàn)數(shù)據(jù)資源共享。
通用信息模型 CIM 需基于面向對象思想，采用統(tǒng)一建模語言 UML。
需涵蓋實驗室關注的科研、行政辦公、財務、人事等不同領域主要實體的邏輯結構和關系。
需為各個應用提供了與平臺無關的統(tǒng)一的邏輯描述，為實現(xiàn)科研一體化提供基礎信息模型。
通用的數(shù)據(jù)接口 GDA 需以標準的方式訪問公共信息或相互之間交換信息。需為應用系統(tǒng)提供使用公共 API 訪問共享數(shù)據(jù)和使用公共服務實現(xiàn)數(shù)據(jù)處理、存儲和顯示功能的機制。通用接口服務至少需包括：資源標識服務、資源查詢服務、過濾資源查詢服務、資源更新服務等，實現(xiàn)數(shù)據(jù)訪問和更新。
接口定義應采用面向對象描述方式。
未來構建的業(yè)務系統(tǒng)，將按照統(tǒng)一的信息標準、開發(fā)標準規(guī)范和數(shù)據(jù)交換標準進行規(guī)范，實現(xiàn)業(yè)務系統(tǒng)之間的流程銜接和協(xié)同工作。
交換接口標準 數(shù)據(jù)交換引擎應該是基于面向服務架構 SOA 的開放的、標準的基礎技術平臺，需支持業(yè)界絕大多數(shù)的開放標準，如 XML、BPEL、XQuery、XPath、JMS、JDBC、Web Service、WSIF、JCA、WS-Security、WS-I 等標準。需支持文件交換（XML 文件、DBF 文件、其它格式文件）、標準數(shù)據(jù)交換，應采用 XML、Web Services 作為數(shù)據(jù)傳輸?shù)臉藴�，應采用主流消息傳遞機制，幫助用戶建立統(tǒng)一的數(shù)據(jù)傳輸與數(shù)據(jù)交換規(guī)范，實現(xiàn)不同部門間、不同應用系統(tǒng)間的數(shù)據(jù)交換，應具有良好的擴展性。
數(shù)據(jù)交換規(guī)范的具體要求如下：
需提供支持 BPEL 規(guī)范的流程引擎，實現(xiàn)面向服務、流程驅動的數(shù)據(jù)交換引擎； 需提供瀏覽器的管理監(jiān)控界面； 需支持使用圖形化設計工具定義數(shù)據(jù)交換流程； 需支持使用圖形化設計工具定義數(shù)據(jù)轉換規(guī)則，支持 XSLT 映射器； 需支持使用瀏覽器界面定義與管理 Web 服務的安全策略； 所有信息均應采用標準的 XML 格式（XSD 類型或 DTD 類型）； 對于無法提供 XML 格式內容的待集成應用系統(tǒng)，至少需提供分隔符、固定位置、二進制文件等文件格式； 可直接訪問的數(shù)據(jù)庫系統(tǒng)，需支持 JDBC 標準； 不可直接訪問的數(shù)據(jù)庫系統(tǒng)，須提供代理訪問接口，如 Web 服務接口； 傳統(tǒng)應用系統(tǒng)如未提供 Web 服務接口，則應支持 JCA、Java/EJB、JMS、HTTP GET/POST、文件等接口方式； 綜合服務平臺中 Web 服務的安全與管理，應支持 WS-Security、WS-I 等 Web 服務標準； 需提供可擴展的、負載均衡的集群技術，滿足不斷增長的系統(tǒng)服務需求。
數(shù)據(jù)模型標準 需根據(jù)實驗室的全局服務模型建立元數(shù)據(jù)模型，元數(shù)據(jù)模型是按服務所需，對源業(yè)務數(shù)據(jù)進行組
合關聯(lián)的模型，它與實驗室教學、科研、管理活動的業(yè)務模型有關，是提供所有信息資源服務所需的數(shù)據(jù)模型，也是共享數(shù)據(jù)庫平臺的基本數(shù)據(jù)結構。
應用集成標準 應用集成應分為數(shù)據(jù)集成、身份集成、發(fā)布集成和門戶集成。
標準管理工具 系統(tǒng)需提供一套信息標準的管理工具，以對標準進行管理和維護。信息標準管理工具功能需覆蓋到參照標準、執(zhí)行標準的管理、代碼標準映射、數(shù)據(jù)模式的瀏覽和維護等，需具備初始化、新增、刪除、修改維護功能和分類檢索、輸出、數(shù)據(jù)展示瀏覽功能。需提供可視化的界面，對標準的各類信息進行圖表化展示。能滿足實驗室信息標準管理的需求，需具有一定的自動化、智能化特點，能通過統(tǒng)一身份認證與管理平臺，實現(xiàn)身份訪問控制、操作日志、審計和備份恢復管理功能，從而實現(xiàn)對標準的維護和完善。
4.1.3 主數(shù)據(jù)管理平臺 需建立實驗室全局的管理和業(yè)務數(shù)據(jù)模型，對數(shù)據(jù)資源進行統(tǒng)一的整理、分類和管理，實現(xiàn)實驗室信息資源的集中，并形成全局數(shù)據(jù)共享的管理、維護、處理和服務機制，實現(xiàn)實驗室信息資源的共享、集成和利用。具體而言，主數(shù)據(jù)倉庫的建設需達到以下目標：
需建立實驗室統(tǒng)一的信息資源標準； 需對數(shù)據(jù)全面可靠的整合，建立共享數(shù)據(jù)庫，實現(xiàn)實驗室核心信息資源的共享； 需在共享數(shù)據(jù)庫基礎之上對數(shù)據(jù)的進一步的加工和整理，建立數(shù)據(jù)倉庫，為實驗室領導、各級管理決策人員提供靈活度更高的多維分析和數(shù)據(jù)挖掘； 需實現(xiàn)高度模塊化的設計，建立完善的數(shù)據(jù)模型及其管理框架； 需具有良好的系統(tǒng)擴展性，滿足實驗室日益增長的業(yè)務需求； 需提供性能卓越的數(shù)據(jù)管理、系統(tǒng)監(jiān)控工具，降低系統(tǒng)維護人員的工作難度； 主數(shù)據(jù)倉庫需以元數(shù)據(jù)管理思路對共享數(shù)據(jù)進行建設和管理，由共享數(shù)據(jù)中心和管理工具組成。共享數(shù)據(jù)中心能夠建立實驗室統(tǒng)一的標準代碼集和核心數(shù)據(jù)模型，從而形成實驗室的信息資源標準。主數(shù)據(jù)倉庫還應當建立強大的數(shù)據(jù)管理、處理和維護功能，為主數(shù)據(jù)倉庫的運行提供支持。
主數(shù)據(jù)倉庫應能夠解決如下問題：
數(shù)據(jù)共享的問題 數(shù)據(jù)一致性問題 歷史數(shù)據(jù)處理問題 技術要求 主數(shù)據(jù)倉庫需通過數(shù)據(jù)交換機制的支持實現(xiàn)實驗室共享數(shù)據(jù)的集中管理，在此基礎上對業(yè)務數(shù)據(jù)進行全面清洗，是各類信息采集、加工和整合的平臺。
主數(shù)據(jù)倉庫應該是一個數(shù)據(jù)管理平臺，能夠為信息系統(tǒng)提供一致的、穩(wěn)定的共享數(shù)據(jù)源； 主數(shù)據(jù)倉庫需實現(xiàn)新舊系統(tǒng)中同構、異構數(shù)據(jù)的整合； 需再物理架構上集成一系列的工具(管理工具、數(shù)據(jù)整合工具、查詢工具)，在數(shù)據(jù)中心中可以借助關系型數(shù)據(jù)庫進行存儲； 實現(xiàn)面向用戶提供服務：如對用戶的現(xiàn)有的及歷史的信息進行分析；輔助管理層進行分析決策。
需實現(xiàn)各業(yè)務系統(tǒng)生成的業(yè)務數(shù)據(jù)通過數(shù)據(jù)交換平臺同步到數(shù)據(jù)倉庫，數(shù)據(jù)倉庫將共享數(shù)據(jù)同步到共享數(shù)據(jù)庫；需實現(xiàn)某各業(yè)務系統(tǒng)需與其他業(yè)務系統(tǒng)進行數(shù)據(jù)交互時，僅需通過數(shù)據(jù)交換平臺與共享數(shù)據(jù)庫交換數(shù)據(jù)，不再需與多個業(yè)務系統(tǒng)通過系統(tǒng)間接口交互。綜合數(shù)據(jù)應用也僅需訪問共享數(shù)據(jù)庫即可獲得所需數(shù)據(jù)。
同時，每個業(yè)務系統(tǒng)接入時，僅需與數(shù)據(jù)中心做接口交互，避免了以前可能需與每個已有應用系
統(tǒng)分別協(xié)商、改造接口的情況。
核心數(shù)據(jù)模型 數(shù)據(jù)模型是主數(shù)據(jù)倉庫的核心，它對數(shù)據(jù)源系統(tǒng)中所采集的數(shù)據(jù)進行重新組織，需建立如下幾種數(shù)據(jù)模型：
權威數(shù)據(jù)模型。是面向全局的核心基礎數(shù)據(jù)。它由唯一業(yè)務源產生和維護，采集到主數(shù)據(jù)倉庫，供各業(yè)務系統(tǒng)共享和引用的數(shù)據(jù)。比如用戶基本信息、人事管理信息、科研信息、資產信息、財務信息等。
資源數(shù)據(jù)模型。以文件等形式存儲和管理的資源數(shù)據(jù)，如文檔、照片、流媒體等。
主題數(shù)據(jù)模型。將來自于不同應用的數(shù)據(jù)按主題整合、組織的數(shù)據(jù)，便于按主題進行展現(xiàn)。
標準代碼數(shù)據(jù)模型。根據(jù)實驗室的要求的標準，建立統(tǒng)一的信息資源標準代碼集，便于全局數(shù)據(jù)的共享。
在國標基礎上，結合實際情況選擇自己的執(zhí)行標準。
數(shù)據(jù)倉庫(DDS) 數(shù)據(jù)倉庫是在共享數(shù)據(jù)庫基礎之上對數(shù)據(jù)的進一步的加工和整理，它可以為實驗室領導、各級管理決策人員提供靈活度更高的多維分析和數(shù)據(jù)挖掘。
數(shù)據(jù)倉庫建設需根據(jù) BI 應用的需求，通過關系型多維模型的建設，形成多維數(shù)據(jù)庫（DDS），或者稱為主題數(shù)據(jù)庫，為多維分析和數(shù)據(jù)挖掘應用提供數(shù)據(jù)。
數(shù)據(jù)倉庫需建設如下幾個主題數(shù)據(jù)庫：
用戶基本信息主題 人事基本信息主題 實驗室科研項目主題 實驗室資產主題 實驗室綜合情況主題 數(shù)據(jù)倉庫是多維數(shù)據(jù)庫的形式存儲，即 DDS（Dimensional Data Store），它是業(yè)務常用數(shù)據(jù)、衍生數(shù)據(jù)以及其他一些數(shù)據(jù)的數(shù)據(jù)集合。它的數(shù)據(jù)來源通常是 ODS 數(shù)據(jù)存儲，或者在業(yè)務數(shù)據(jù)比較“干凈”的情況下也可以直接從業(yè)務系統(tǒng)中抽取。DDS 通常作為 OLAP 數(shù)據(jù)的唯一數(shù)據(jù)源。DDS 多維數(shù)據(jù)存儲是數(shù)據(jù)倉庫共享、正確、高效、增值等諸多特性的體現(xiàn)。
DDS 中的數(shù)據(jù)存放必須按照一定的規(guī)則進行存放，這就是多維數(shù)據(jù)模型。整個 DDS 就是一棵結構分明的數(shù)據(jù)樹。DDS 的拓樸結構從數(shù)據(jù)主題開始，經(jīng)過若干層的子主題，到最后包含在不同子主題中的“數(shù)據(jù)單元”為止，形成一個典型的樹型結構。
平臺管理功能要求 信息標準管理工具 能夠實現(xiàn)對主數(shù)據(jù)倉庫所采用的實驗室執(zhí)行標準、所參考的國標、部標等，與業(yè)務系統(tǒng)數(shù)據(jù)字典的對應關系進行管理，并對變化情況進行跟蹤。需實現(xiàn)：
對實驗室執(zhí)行標準代碼進行管理 對各個應用系統(tǒng)所包含的代碼進行管理 管理實驗室執(zhí)行標準與應用系統(tǒng)代碼的映射。為信息交換平臺中的數(shù)據(jù)轉換提供支持。
實現(xiàn)應用系統(tǒng)代碼與執(zhí)行代碼的差異性對比，便于實驗室制訂和執(zhí)行標準時參考。
跟蹤執(zhí)行標準和應用系統(tǒng)代碼的變化，包括數(shù)據(jù)結構的變化和數(shù)據(jù)內容的變化兩種。并可通過短信、郵件等方式及時發(fā)出提醒，便于管理。
元數(shù)據(jù)管理工具 需采用元數(shù)據(jù)管理思路，對共享數(shù)據(jù)庫中的數(shù)據(jù)對象、數(shù)據(jù)模型進行管理和跟蹤。主要功能需包
括：
共享數(shù)據(jù)模型管理。管理數(shù)據(jù)模型列表。將主數(shù)據(jù)倉庫的數(shù)據(jù)模型和數(shù)據(jù)對象統(tǒng)一管理，可按照不同的樹型進行分類。
應用系統(tǒng)數(shù)據(jù)結構管理。管理各應用系統(tǒng)的數(shù)據(jù)結構，可通過信息交換平臺實現(xiàn)應用系統(tǒng)數(shù)據(jù)結構的動態(tài)采集。
數(shù)據(jù)模型映射管理。定義和管理共享數(shù)據(jù)數(shù)據(jù)模型和應用系統(tǒng)數(shù)據(jù)結構之間的關聯(lián)關系。
數(shù)據(jù)模型跟蹤監(jiān)控。跟蹤和監(jiān)控主數(shù)據(jù)倉庫數(shù)據(jù)結構、應用系統(tǒng)數(shù)據(jù)結構的變化情況以及相應造成的影響，并可與實驗室的短信網(wǎng)關或郵件服務進行集成，及時提醒系統(tǒng)運行維護人員，便于管理。
監(jiān)控中心 需實現(xiàn)對主數(shù)據(jù)倉庫的整體運行情況進行監(jiān)控的功能。具體包括以下功能：
監(jiān)控記錄查詢 需實現(xiàn)查看后臺監(jiān)控記錄的功能。
數(shù)據(jù)中心狀態(tài)監(jiān)控 需實現(xiàn)監(jiān)控數(shù)據(jù)中心運行狀態(tài)，保持數(shù)據(jù)中心與數(shù)據(jù)集標準的一致性的功能。
資源庫代碼變化監(jiān)控 需實現(xiàn)監(jiān)控資源庫代碼變化情況的功能。
資源庫數(shù)據(jù)集變化監(jiān)控 需實現(xiàn)監(jiān)控業(yè)務數(shù)據(jù)集的結構變化情況的功能。
資源庫數(shù)據(jù)交換對象監(jiān)控 需實現(xiàn)監(jiān)控資源庫數(shù)據(jù)交換對象（包括觸發(fā)器、狀態(tài)表、存儲過程狀態(tài)）的功能。
數(shù)據(jù)交換狀態(tài)監(jiān)控 能夠支持用戶通過該功能查看目前存在于數(shù)據(jù)交換共享服務上部署的數(shù)據(jù)交換任務，是否工作正常，或出錯，有異常等狀態(tài)。
錯誤日志管理 需提供錯誤日志瀏覽、查詢、清理功能。
操作日志管理 需提供操作日志查看、清理功能。
日志遷移 需提供錯誤日志、操作日志的遷移功能。
4.1.4 數(shù)據(jù)交換共享與業(yè)務應用集成平臺 數(shù)據(jù)交換與應用集成平臺需實現(xiàn)構建實驗室核心支撐系統(tǒng)項目數(shù)據(jù)交換的系統(tǒng)框架，制定園區(qū)統(tǒng)一的數(shù)據(jù)采集、維護、交換的技術規(guī)范和標準，實現(xiàn)實驗室信息資源的交換共享、信息集成管理和信息資源的充分利用。
具體而言，數(shù)據(jù)交換與集成平臺的建設要求達到以下目標：
需為各應用系統(tǒng)之間提供一個統(tǒng)一的數(shù)據(jù)交換通道和接口，使數(shù)據(jù)交換更加準確、便捷、高效、暢通，設計并實現(xiàn)各業(yè)務應用系統(tǒng)數(shù)據(jù)實時交換框架體系； 需為公共數(shù)據(jù)平臺提供一個可靠的數(shù)據(jù)采集通道； 需建立實驗室統(tǒng)一的數(shù)據(jù)交換技術規(guī)范和標準。
企業(yè)服務總線 應用集成平臺需實現(xiàn)構建應用服務協(xié)同和管理的系統(tǒng)框架，制定統(tǒng)一的服務注冊、發(fā)布、訪問、控制、管理的技術規(guī)范和標準，消除應用之間的間隙，實現(xiàn)各應用系統(tǒng)之間的協(xié)同工作。應用集成平臺應該采用開源 Activiti 實現(xiàn)，提供企業(yè)級計算能力的支撐環(huán)境如服務網(wǎng)絡、集群能力、安全機制等。
技術要求 需支持多種業(yè)務和服務系統(tǒng)集成 需支持信息、服務、API 和安全網(wǎng)關 需具有高性能、高可用性、可擴展性及穩(wěn)定性 需支持輕量級、開發(fā)者友好和易于部署 需支持可視化的管理和監(jiān)控 應用集成平臺應采用基于 SOA 體系架構的松耦合應用集成架構，在實驗室分布式、異構的應用環(huán)境中，為實驗室提供更大的靈活性，重用性和整體的反應能力。應用集成平臺需充當 SOA 中服務提供者和請求者之間的連接服務的中間層，具備靈活的連接框架，可促進可靠而安全的系統(tǒng)集成，并同時減少應用程序接口的數(shù)量、大小和復雜度。
功能要求 服務儲存庫 服務分類：服務儲存庫需支持自定義、可配置的服務分類，用戶可以從實驗室業(yè)務角度和技術角度對服務進行分類，同時對服務分類提供遵循 UDDI 規(guī)范的分類校驗服務。針對每一個自定義的分類方法，都提供了一個校驗服務，可以根據(jù)用戶自定義的服務分類法執(zhí)行服務分類正確性的校驗。
服務檢索：需提供服務檢索，用戶可以根據(jù)業(yè)務相關的分類法，方便地進行服務的導航和搜索，加速服務的發(fā)現(xiàn)。
生命周期管理：服務儲存庫還需支持服務生命周期管理，包括服務審批、變更通知和 QoS 管理。
服務變更管理：需提供服務變更管理功能，支持變更的通知和訂閱，能夠實現(xiàn)將注冊數(shù)據(jù)的變動主動地通知到管理員或者相應的流程。
服務注冊管理 服務注冊管理需實現(xiàn)集中管理實驗室各類需業(yè)務協(xié)同的應用服務。包括服務開發(fā)語義的定義、服務的注冊申請、服務的失效檢測（自動失效、過期失效等）、服務的申請審核等。
為了完全支持全面的 SOA 中所需的各種集成模式（如請求/響應、發(fā)布/訂閱和事件等），服務注冊管理需在應用集成平臺中支持三個主要集成方式：
SOA：其中應用程序需通過具有定義良好的顯式接口的可重用服務進行通信。面向服務的交互將充分利用底層消息傳遞和事件通信模型。
消息驅動的體系結構：應用程序需通過企業(yè)服務總線發(fā)送消息，以調用其他應用程序。
事件驅動的體系結構：其中應用程序需以彼此獨立的方式生成和使用消息。
服務流程協(xié)調引擎 服務流程協(xié)調引擎需支持應用以多種方式（同步、異步、發(fā)布訂閱）對服務的調用。需支持自動捕捉服務的變化、失效時間的自動判斷等。
安全管理 需提供對發(fā)布的 Web 服務進行權限控制、認證服務。包括服務發(fā)布對象、調用對象的認證、服務的調用數(shù)據(jù)控制等。
業(yè)務活動監(jiān)控 需實現(xiàn)對服務的訪問、調用、變化等進行全局的監(jiān)控。
業(yè)務流程管理與服務 技術要求 需實現(xiàn)各種業(yè)務環(huán)節(jié)整合的全面管理模式。支持跨應用、跨部門、跨人員與用戶的業(yè)務與事務運作。應具有以下特點 業(yè)務流程的執(zhí)行規(guī)范
支持 WS-BPEL 2.0 和 BPEL4WS 1.1 等流程標準 支持狀態(tài)流程和非狀態(tài)流程 支持基于消息和基于時間的觸發(fā)處理 支持 WS-Security、Kerberos 等流程安全協(xié)議 支持內容在流程節(jié)點之間安全廣播 數(shù)據(jù)維護與可擴展性 支持 XPath 1.0/2.0、XSLT 1.0/2.0、XQuery 1.0 和 E4X 等數(shù)據(jù)處理協(xié)議 支持通過 API 自定義和擴展業(yè)務流程的數(shù)據(jù)需求 工作流定義與使用者的交互 支持 WS-Human Task 1.1 和 BPEL4People 1.1 等規(guī)范進行交互行為定義 支持人與工作流程節(jié)點績效及整個流程績效的對應 支持與統(tǒng)一身份認證緊密集成而實現(xiàn)用戶在業(yè)務流程中的身份、角色和權限匹配 能夠通過友好的用戶界面自定義創(chuàng)建各業(yè)務流程任務 能夠創(chuàng)建和自定義各個業(yè)務流程及節(jié)點的關鍵性績效指標（KPI ）
多種人性化的業(yè)務流程節(jié)點和業(yè)務流程總體績效統(tǒng)計和分析報表 能過通過圖形化管理界面進行流程管理和配置 能通過圖形化管理界面進行業(yè)務流程管理，并支持可視化的 Drag-n-drop 支持按照自定義方式實現(xiàn)業(yè)務流程創(chuàng)建和管理 支持流程業(yè)務的導入和導出 支持圖形化的業(yè)務流程靈活部署、動態(tài)升級和業(yè)務流程發(fā)布 支持圖形化的業(yè)務流程終止、暫停、恢復、重試、審計、故障處理和清理 易于與現(xiàn)有信息系統(tǒng)集成 支持 MySQL、MSSQL、Oracle 和 DB2 等主流數(shù)據(jù)庫 支持多種身份認證授權與訪問控制系統(tǒng)，如 LDAP、 Microsoft Active Directory 或任何 JDBC 數(shù)據(jù)庫等 提供能與其他信息系統(tǒng)統(tǒng)進行集成的 API 高可用性，可擴展性和穩(wěn)定性 支持無狀態(tài)的服務器水平伸縮 分布式緩存以提高業(yè)務流程的處理性能 支持高可用部署 能并發(fā)支持多種應用的業(yè)務流程執(zhí)行 能在低資源消耗情況下長期穩(wěn)定運 輕量級、開發(fā)者友好和易于部署 容易進行業(yè)務流程的跟蹤測試 支持通過中間件的配置實現(xiàn)服務器功能特性定制 支持與 SVN、Maven、Ant、Eclipse 等開發(fā)、部署標準工具進行集成 具有人性化的圖形開發(fā)與配置界面 管理和監(jiān)控 支持高安全性的、基于 Web...
熱點文章閱讀