數(shù)字化校園中應用集成研究

文章出處：http://www.hungpor.com 作者：許鑫 蘇新寧   人氣： 發(fā)表時間：2011年11月23日

    對于數(shù)字化校園的研究，比較一致的觀點是把數(shù)字化校園的建設分成了三大類，第一類的平臺的建設，正如前面系列文章中介紹的統(tǒng)一身份認證、統(tǒng)一信息門戶、共享數(shù)據(jù)中心、一卡通平臺等；第二類是應用建設，各種各樣的MIS系統(tǒng)、OA系統(tǒng)等等，與學校的各個業(yè)務部門和流程密切相關的管理信息系統(tǒng)；第三類是資源建設，包括數(shù)字圖書館、數(shù)據(jù)博物館、課件庫、資源庫等數(shù)字資源的建設。然而，究竟如何構建我們的整體的數(shù)字化校園，如何將這三者有機的聯(lián)系一起，集成便成了大家共同關注的問題。 

    1 數(shù)字化校園總體方案設計 

    數(shù)字化校園整體解決方案一般分為數(shù)字化校園應用支撐平臺解決方案、數(shù)字化校園應用建設解決方案、數(shù)字化校園應用接入解決方案、數(shù)字化校園應用表現(xiàn)解決方案、數(shù)字化校園管理決策支持解決方案五大部分，如圖1所示。 

圖1 數(shù)字化校園總體方案設計

    其中應用支撐平臺是整個數(shù)字化校園的軟件基礎平臺，主要包括共享數(shù)據(jù)中心、統(tǒng)一身份認證、統(tǒng)一信息門戶和一卡通平臺系統(tǒng)（校園金融消費與電子識別解決方案）等幾個部分。 

    應用建設解決方案綜合了大量高校的需求調研結果，是擴展性和適用性強大的各類管理信息系統(tǒng)，可以分為師生員工管理、教務事務管理、科研外事管理、后勤事務管理、財務事務管理、固定資產(chǎn)管理、辦公自動化系統(tǒng)等大類，具體細化，比如師生員工管理包括了人事管理、招生管理、迎新管理、學工管理、就業(yè)管理、校友管理等具體的管理信息系統(tǒng)，再如后勤事務管理也包含了食堂就餐、商場、超市、洗衣、復印、校巴、考勤、門禁、醫(yī)療、體育設施、上機、電控、水控、保安巡更等子系統(tǒng)。 

    而應用系統(tǒng)接入方案則重要依靠一些應用系統(tǒng)集成工具，將原有的應用系統(tǒng)可以方便的接入校園共享數(shù)據(jù)中心，身份認證系統(tǒng)、信息門戶系統(tǒng)和一卡通系統(tǒng)，這一塊的設計和考慮將是本文研究的重點，后面將有進一步的探討。最后通過在共享數(shù)據(jù)中心基礎上應用數(shù)據(jù)挖掘技術提供的一系列數(shù)值分析工具實現(xiàn)管理決策支持等工作，進一步提升校園管理水平。 

    2 數(shù)字化校園中的一體化設計 

    在實際的數(shù)字化校園建設中，我們可以采用接入的方式完整各類平臺和系統(tǒng)的整合，但這只是一種事后的處理方法，在新開展的數(shù)字化校園整體建設中，我們的期望的是在一開始就能有一體化的設計，把并在后期的實施中不折不扣的實現(xiàn)既定的規(guī)劃和設計，在一體化設計中，貫穿于始終的是數(shù)據(jù)和流程這兩個關鍵。
 
    2．1 數(shù)據(jù) 

    在數(shù)據(jù)上的考慮首先體現(xiàn)在信息標準的建設上，繼而體現(xiàn)在信息的分類、數(shù)據(jù)的組織和數(shù)據(jù)庫的設計上[ 2,3 ]。舉例而言，如果高校缺乏對校園信息化的深入理解，那么在其構建信息標準的時候就無法根據(jù)具體學校的實際情況自主考慮。一般通用的教育部信息標準也僅僅是供參考的，只說明信息點內容，并不標明主鍵信息，這就需要在實際的實施中針對學校情況進行分類（也就是數(shù)據(jù)庫的建表設計），在科學性、系統(tǒng)性等原則下，按照信息來源、組織形式或者使用范圍等幾種方法，把相同類型的數(shù)據(jù)提煉出來，完成對信息的分類。然后再為每張表建立一個主鍵ID，其生成為UUID（全球統(tǒng)一標識碼 ），實現(xiàn)以一張核心信息表為主，若干張附屬信息作為補充，理清表與表之間的邏輯關系（表的組織，若干主題庫等）。
    同樣的一體化設計還體現(xiàn)在對平臺系統(tǒng)的深入理解上，以有鮮明特點的一卡通系統(tǒng)為例，必須對一卡通業(yè)務數(shù)據(jù)有一定的了解，才可能在數(shù)據(jù)中心設計出符合一卡通需求的類別及庫表來，才能夠清晰地梳理出誰是核心表誰是主鍵，才能夠完成一卡通相應數(shù)據(jù)字段和其它應用系統(tǒng)字段的對應，并完成較深層次的集成……這些一體化的設計也存在于其他校園平臺的設計中。 

    2．2 流程 

    流程既體現(xiàn)在現(xiàn)有流程的實現(xiàn)上，又體現(xiàn)在校園業(yè)務流程的重組上，是否在設計上充分的考慮，關系到需求變更帶來的快速調整能否實現(xiàn)？也關系到各種功能擴充的高效實施。 

    以數(shù)字化校園整體解決方案為例，在技術架構層與層之間以及層內各組件之間定義了標準接口，達到松耦合，使應用系統(tǒng)的開發(fā)及后續(xù)擴展只需要關注其中相關的部分。當某些提供服務的業(yè)務系統(tǒng)發(fā)生變化時，不會影響到使用服務的其他業(yè)務系統(tǒng)的正確運行。而且新的流程需求產(chǎn)生以后，或者學校業(yè)務流程發(fā)生了改變，事前的充分設計和各類機制的存在就成了積極的保障。 

    2．3 方法 

    除了數(shù)據(jù)和流程的一體化設計以外，在整體的數(shù)字化校園建設中還需要注意方法。方法論的一致不僅僅體現(xiàn)在早期的整體統(tǒng)一規(guī)劃中，更體現(xiàn)在高校信息化應用需求的實現(xiàn)中。統(tǒng)一數(shù)據(jù)標準、統(tǒng)一數(shù)據(jù)交互、個性定制、統(tǒng)一權限、統(tǒng)一建設、統(tǒng)一表現(xiàn)及表現(xiàn)擴展、統(tǒng)一管理等都是數(shù)字化校園一體化設計中方法所需要的關注的。再者關于數(shù)字化校園建設中的問題及對策在我們的本系列文章的第一篇中也有相應的研究和描述，前瞻性的規(guī)劃、統(tǒng)一性的設計、整體性的建設構成了我們數(shù)字化校園建設方法論的核心。 

    在此基礎上的擴展還體現(xiàn)在建設的步驟和節(jié)奏上，體現(xiàn)在投資上和評估上。有些學校應用建設比較完善，他們需要的可能是后期的整合；有些學校直接先上平臺等基礎設施，它們可能需要的是如何在平臺基礎上更快更方便的建設應用；也有些學校分別進行了一些一卡通、資源庫、基礎平臺之類的信息化建設，此時后期的集成變成了關鍵。各個學校有各個學校建設的步驟，同時對于節(jié)奏的控制也十分重要，既不能“貪多嚼不爛”，虎頭蛇尾的建設，也不能“再而衰，三而竭”，信息化進程拖沓不可控是很嚴重的問題。此外一體化的設計還體現(xiàn)的投資上的綜合考慮，比如在軟硬件部署上根據(jù)建設要求充分考慮，共享設計，避免重復投資。避免購買很多服務器，但大多數(shù)利用不高，或者購買了各類數(shù)據(jù)庫軟件，但各個庫上跑的數(shù)據(jù)和業(yè)務都很有限等諸如此類的問題。 

    3 數(shù)字化校園中應用集成設計 

    數(shù)字化校園的應用集成設計主要體現(xiàn)在平臺和應用的對接上，同時，因為一卡通平臺涉及到硬件設備，而且又是金融化的系統(tǒng)，所以其集成也是有特點的。 

    3．1 校園各類應用系統(tǒng)的平臺集成 

    3．1．1 各類MIS與共享數(shù)據(jù)中心 

    對于各類MIS與共享數(shù)據(jù)中心平臺的集成，首先要分析應用的數(shù)據(jù)結構和共享數(shù)據(jù)中心庫內的數(shù)據(jù)結構的區(qū)別。建立雙方都能認可的一個協(xié)議后，根據(jù)校園數(shù)據(jù)標準使用數(shù)據(jù)集成客戶端工具在共享數(shù)據(jù)中心庫中建立系統(tǒng)需要的部分或者全部數(shù)據(jù)結構。針對系統(tǒng)間對于某些字段的定義仍然存在著區(qū)別，建立一種規(guī)則來達到雙方共同認可的字段對應。共享數(shù)據(jù)中心根據(jù)應用系統(tǒng)的業(yè)務需要，生成相應的主題庫和中間件，應用系統(tǒng)在進行數(shù)據(jù)操作的時候，直接調用中間件服務操作主題庫，以達到對共享數(shù)據(jù)中心庫的操作。 

    對數(shù)據(jù)中心的集成接入特點體現(xiàn)在需要對要接入的每一個應用系統(tǒng)的數(shù)據(jù)源進行調研，確保提供一定程度的數(shù)據(jù)接口，這個從應用系統(tǒng)往共享數(shù)據(jù)中心的上行過程要確定從應用系統(tǒng)抽取哪些數(shù)據(jù)，這些數(shù)據(jù)的含義是什么，即提供相應的數(shù)據(jù)字典，并且確定對應于數(shù)據(jù)中心的哪張表，可接入的數(shù)據(jù)接口模式分為： 

 模式一：直接開放數(shù)據(jù)庫，只需要只讀的賬戶權限即可，需要在絕對保證原有系統(tǒng)數(shù)據(jù)安全性和完整性，不影響原有系統(tǒng)運行的基礎上建立觸發(fā)器。 

 模式二：中間文件數(shù)據(jù)源，如應用系統(tǒng)不能對外開放數(shù)據(jù)庫，則可以導出差異數(shù)據(jù)文件到指定的目錄，這些文件可以是Access文件數(shù)據(jù)庫模式、excel文件模式等，格式可在實施時共同商定。 

    3．1．2 各類MIS與統(tǒng)一身份認證 

    數(shù)字化校園的整體建設客觀上要求建設統(tǒng)一的身份認證中心，針對各個集成到身份認證系統(tǒng)的應用系統(tǒng)，提供身份相關服務。這里是最權威的用戶基本信息的集中存儲，用戶身份信息的唯一入口；對每個應用提供用戶組的定義，為權限管理提供了手段；提供了用戶身份認證服務和單點登陸（SSO）的方法。數(shù)據(jù)同步服務提供用戶數(shù)據(jù)同步復制的機制，支持應用建立單獨的數(shù)據(jù)庫，并保持兩邊數(shù)據(jù)的一致性和不冗余；數(shù)據(jù)訪問服務提供了安全的、有權限控制的應用系統(tǒng)訪問用戶身份信息的方法。用戶在登錄應用系統(tǒng)的時候，應用系統(tǒng)會取得用戶的用戶名和密碼，此時它把用戶名和密碼通過加密方式提交給統(tǒng)一身份認證系統(tǒng)。統(tǒng)一身份認證系統(tǒng)在得到用戶名和密碼后立即驗證其合法性，主要就是反映其是否有訪問系統(tǒng)的權限，統(tǒng)一身份認證系統(tǒng)把得到的結果返回給應用系統(tǒng)。 

    各類MIS和認證平臺的集成主要體現(xiàn)在統(tǒng)一身份認證給其他的應用系統(tǒng)提供訪問者身份的驗證信息。每一個應用系統(tǒng)通過某種途徑訪問把訪問者的信息提交給統(tǒng)一身份認證平臺，一般是通過使用socket實現(xiàn)訪問接口，應用系統(tǒng)把訪問者信息按照規(guī)定的要求格式轉化為xml包，發(fā)送到統(tǒng)一身份認證平臺前置機上，前置機收取后經(jīng)過處理返回結果包，同樣也是采用xml格式。現(xiàn)階段統(tǒng)一身份認證平臺能夠提供給Portal比較詳細的認證，包括權限等，但對于其他的各類應用系統(tǒng)則接入層次參差不齊，這是因為一些系統(tǒng)內部存在著自己的權限分配策略（非RBAC模式），沒有或者不能夠把權限分配存放在統(tǒng)一身份認證平臺上。若應用系統(tǒng)把其使用權限移交到統(tǒng)一身份認證平臺上，那么必須要按照要求把權限按照角色或者組織來劃分，則認證平臺在返回結果包時包含著訪問者的角色和權限信息。 

    3．1．3 各類MIS與統(tǒng)一信息門戶 

    建設統(tǒng)一信息門戶作為個人單點登陸和信息發(fā)布的集中點，一方面面向個人用戶，如果個人不登陸，在信息門戶上可以獲取公共的信息；用戶在信息門戶登陸一次以后查詢到所有與其個人相關的信息及進行某些業(yè)務系統(tǒng)的操作；提供鏈接，對于某些集成到統(tǒng)一身份認證系統(tǒng)且有單獨Web信息發(fā)布的應用，可以平滑進入，無需再次身份認證。在面向應用開發(fā)方面，提供了統(tǒng)一的應用開發(fā)模式；提供了基于Web的統(tǒng)一的權限管理模式；提供了統(tǒng)一的界面表現(xiàn)形式，可以將來源于各種應用系統(tǒng)的數(shù)據(jù)集中發(fā)布，互不干擾。 

    應用系統(tǒng)首先按照邏輯/表示分開的原則分析自己的結構，表示層的結構通過Portlet形式安裝在統(tǒng)一信息門戶系統(tǒng)中，應用系統(tǒng)自身保留對業(yè)務邏輯處理的結構，并提供給接口統(tǒng)一信息門戶系統(tǒng)訪問。當用戶使用統(tǒng)一信息門戶系統(tǒng)中的某一Portlet時，統(tǒng)一信息門戶系統(tǒng)會將用戶對Portlet的操作反映給應用系統(tǒng)的業(yè)務處理接口，處理完畢后，會返回給統(tǒng)一信息門戶系統(tǒng)，Portlet則把這些結果反映在頁面上。對門戶平臺的接入大體上有三種方式，一種是開發(fā)者把頁面和邏輯都卸載Portlet中，則此Portlet可以脫離開現(xiàn)有的應用系統(tǒng)，成為現(xiàn)有應用系統(tǒng)的替代者；另外一種是開發(fā)者可以把邏輯和頁面分離，Portlet是其頁面部分，每次把需要的信息通過POST方法提交到應用系統(tǒng)中，應用系統(tǒng)的Servlet或其它運行程序通過處理把結果返回給Portal，Portlet把得到的結果顯示出來；還有一種是其他的應用系統(tǒng)也可以提供相應的EJB，開發(fā)者只需要在Portlet中直接調用具體的EJB即可。 

    3．2 一卡通平臺和其他平臺的集成 

    3．2．1 一卡通與共享數(shù)據(jù)中心 

    在數(shù)字化校園中，數(shù)據(jù)層面的所需信息集中存儲，并給各應用子系統(tǒng)共享，有效防止信息的冗余和不一致，保證數(shù)據(jù)的準確性和可靠性；可以方便的實現(xiàn)核心數(shù)據(jù)的集中管理、備份，提高系統(tǒng)的安全性，減少設備的投資和管理的人力成本。數(shù)據(jù)中心在數(shù)據(jù)級對“一卡通”和其他系統(tǒng)的數(shù)據(jù)進行無縫集成，便于信息的共享、交流和各項業(yè)務的協(xié)作。 

    一卡通系統(tǒng)應該充分使用統(tǒng)一共享數(shù)據(jù)平臺提供的公共數(shù)據(jù)編碼、身份信息等數(shù)據(jù)。而不應該單獨維護一套獨立、非標準的信息。同時一卡通系統(tǒng)擁有自己的業(yè)務數(shù)據(jù)庫，將其他應用系統(tǒng)需要的信息納入共享數(shù)據(jù)庫的統(tǒng)一設計中，實現(xiàn)校園一卡通系統(tǒng)數(shù)據(jù)對整個數(shù)字化校園的共享。通過數(shù)字化校園應用建設，形成一套符合高校自身實際的管理信息化標準，也是數(shù)字化校園建設中的一項重要內容。我們根據(jù)自己的理解，結合大量的案例，會根據(jù)學校信息化現(xiàn)狀提出信息代碼編碼標準、軟硬件平臺標準、應用系統(tǒng)規(guī)范、業(yè)務流程規(guī)范和數(shù)據(jù)交換標準等，這樣為今后的應用系統(tǒng)的建設制定了規(guī)范。一卡通作為重要的應用系統(tǒng)必須符合整體標準。 

    一般而言為了集成，一卡通使用的公共信息字典必須遵循學校的信息編碼規(guī)范，數(shù)據(jù)模式必須遵循數(shù)據(jù)庫第三范式，一卡通使用的用戶及其信息必須和業(yè)務系統(tǒng)提供的信息是一致的，可以相互關聯(lián)的，以保證一卡通的數(shù)據(jù)和學校的其他信息數(shù)據(jù)能同時進行查詢、分析、統(tǒng)計。針對于卡的門戶應用，共享數(shù)據(jù)中心中的數(shù)據(jù)需要既能展示相關的信息，如：校園卡選課后學生的選課課程、選課的繳費等，又能統(tǒng)計相關的信息，如：不同的專業(yè)的學生費用使用總計及平均消費情況等，這些都需要充分的集成設計。 

    3．2．2 一卡通與統(tǒng)一身份認證 

    數(shù)字化校園建設初期一般多注重建成以目錄服務為基礎的統(tǒng)一身份認證系統(tǒng)，而一卡通建設也有自己的身份認證和設備認證，隨著數(shù)字校園的深入建設，CA認證中心、電子簽名、電子印章的出現(xiàn)，我們必須重新規(guī)劃全校的身份認證體系，卡作為統(tǒng)一身份認證的認證載體，不僅可以用作消費，還為統(tǒng)一身份認證平臺提供了基于用戶名/密碼認證、CA、指紋等存儲。
 
    原有一卡通系統(tǒng)具有單獨一套的用戶管理和用戶組管理模塊，在和統(tǒng)一身份認證系統(tǒng)集成之后，統(tǒng)一身份認證系統(tǒng)作為添加用戶的唯一入口，已經(jīng)實現(xiàn)了這部分功能，因此一卡通系統(tǒng)中的這部分功能不再需要，身份信息從統(tǒng)一身份認證系統(tǒng)獲取。原有的以一卡通管理平臺集成的應用，例如圖書館系統(tǒng)、考勤系統(tǒng)，不再到一卡通管理平臺認證身份，而是直接和統(tǒng)一身份認證系統(tǒng)集成。 

考慮到校園一卡通系統(tǒng)的特殊應用場景，具有專網(wǎng)設計、脫機使用的要求，統(tǒng)一身份認證中心支持一卡通系統(tǒng)建立自己單獨的數(shù)據(jù)庫，定制開發(fā)后臺數(shù)據(jù)復制的服務，使得校園一卡通系統(tǒng)可以保持和統(tǒng)一身份認證數(shù)據(jù)的一致；對于校園一卡通系統(tǒng)的Web應用部分，通過將其納入信息發(fā)布門戶體系，使用統(tǒng)一身份認證系統(tǒng)接口，自然支持單點登錄。 

 用戶信息同步 

    一卡通系統(tǒng)所有用戶信息均可以來自于統(tǒng)一身份認證中心，原則上要求統(tǒng)一認證用戶庫中的用戶基本信息數(shù)據(jù)是相對完整的、權威的，初始化時可從統(tǒng)一身份認證系統(tǒng)中批量導入數(shù)據(jù)，以后接收統(tǒng)一身份認證系統(tǒng)中的用戶變化信息，保持與二者的同步。 

    卡信息同步 

    在統(tǒng)一身份認證系統(tǒng)里面保存卡ID號、卡狀態(tài)（未發(fā)卡、已發(fā)卡、已掛失）、卡有效期等信息，一卡通系統(tǒng)在完成發(fā)卡、掛失、解掛、補卡、換卡等業(yè)務的同時，需要將卡信息同步發(fā)送到統(tǒng)一身份認證系統(tǒng)中。 

    卡權限管理 

    一卡通內部的權限，如卡的使用權限、管理權限應當由一卡通平臺本身來管理，但消費記錄查詢等由專門的Web應用處理的這部分權限可以放在統(tǒng)一身份系統(tǒng)中管理。 

    卡認證服務 

    當實現(xiàn)了卡認證服務時，該卡（人）在某個應用系統(tǒng)中的權限可以根據(jù)情況選擇應用系統(tǒng)單獨管理或者由統(tǒng)一身份認證系統(tǒng)分配，以完成卡認證和其它各應用的授權。 

    3．2．3 一卡通與統(tǒng)一信息門戶 

    門戶系統(tǒng)與“一卡通”系統(tǒng)可以方便地進行整合，門戶系統(tǒng)將統(tǒng)一成為應用系統(tǒng)和“一卡通”系統(tǒng)地展現(xiàn)平臺，便與學校的統(tǒng)一管理。信息發(fā)布平臺包含了動態(tài)網(wǎng)站的框架和應用系統(tǒng)開發(fā)集成平臺。信息發(fā)布平臺部分欄目由平臺自身提供的工具維護，與一卡通系統(tǒng)相關的部分則需要二次開發(fā)或者集成。平臺與一卡通系統(tǒng)的接口分為兩部分： 

    數(shù)據(jù)接口 

    一卡通系統(tǒng)提供數(shù)據(jù)源，數(shù)據(jù)源包括數(shù)據(jù)庫表或者視圖的結構、用戶名稱、口令，信息發(fā)布平臺通過數(shù)據(jù)源可以獲得需要發(fā)布的所有信息，可以將數(shù)據(jù)存儲在信息發(fā)布臨時的數(shù)據(jù)庫中或者直接訪問一卡通系統(tǒng)的數(shù)據(jù)庫，在信息發(fā)布平臺上重新開發(fā)和配置查詢的應用。
 
    認證接口 

    將一卡通原有的Web發(fā)布系統(tǒng)的形式集成進信息發(fā)布平臺，這種鏈接不是簡單的Web鏈接，而是需要將一卡通系統(tǒng)的用戶登陸進行改進，保證在信息平臺上登陸一次即可以進入子系統(tǒng)，無需二次登陸，實現(xiàn)單點登陸。 

    在數(shù)字化校園環(huán)境下的信息發(fā)布平臺的形式主要有以下四種：網(wǎng)站、多媒體終端、電話、郵件。網(wǎng)站開發(fā)基于統(tǒng)一信息門戶平臺，以開發(fā)Portlet的模式進行；另外挑選造型美觀的觸摸屏電腦，配備讀寫器，作為校園的自助多媒體查詢終端。自助查詢終端不僅僅作為一卡通的系統(tǒng)的信息查詢和發(fā)布的終端，也應該用于其它應用系統(tǒng)如教務系統(tǒng)、圖書館系統(tǒng)、學工系統(tǒng)等等信息的查詢和發(fā)布終端。一卡通與統(tǒng)一信息門戶的集成包括： 

    （1） 一卡通系統(tǒng)提供數(shù)據(jù)源，門戶平臺通過數(shù)據(jù)源可以獲得需要發(fā)布的所有信息，可以將數(shù)據(jù)存儲在信息發(fā)布臨時的數(shù)據(jù)庫中或者直接訪問一卡通系統(tǒng)的發(fā)布數(shù)據(jù)庫，在信息發(fā)布平臺上重新開發(fā)和配置查詢，將各類消費與管理的信息及需要查詢的明細發(fā)布到門戶，提供權限控制下的信息查詢與統(tǒng)計和分析。 

    （2） 在門戶上集成一卡通系統(tǒng)的用戶登錄，使得門戶上一卡通系統(tǒng)的相應欄目可以直接顯示持卡人最直接需要的統(tǒng)計結果，以提供最人性化的服務方式。 

    （3） 在原有信息服務基礎上，通過與其他應用及校園基礎網(wǎng)絡服務的整合，開發(fā)新的服務模塊，并集成到門戶上，利用門戶提供的各種發(fā)布方式向全校師生提供增值信息服務。 

    （4） 通過將校園一卡通系統(tǒng)的信息查詢與統(tǒng)計集成到門戶上，可以借助門戶的Web發(fā)布、多媒體查詢終端、電話語音等各種發(fā)布手段，擴展校園一卡通服務的覆蓋面。 

    4 應用集成示例 

    4．1 綜合教務系統(tǒng)集成 

    綜合教務管理系統(tǒng)是輔助學校教師、學生進行綜合業(yè)務管理的一個平臺，是數(shù)字化校園業(yè)務系統(tǒng)中的重點。綜合教務管理系統(tǒng)一般具有自己的一套數(shù)據(jù)庫標準和數(shù)據(jù)結構，但對于整體數(shù)字化校園建設的高校而言，因為已經(jīng)制定了一套統(tǒng)一的信息標準，所以綜合教務管理系統(tǒng)的數(shù)據(jù)就必須和共享數(shù)據(jù)中心有著一個接入同步的過程。同時綜合教務管理系統(tǒng)的使用者是教師和學生，每個使用此系統(tǒng)的人都有著不同的身份、角色、權限。例如在網(wǎng)上選課系統(tǒng)中，不同年級、不同專業(yè)的學生所能選擇的課程是不一樣的，在學生學籍管理中，不同的老師所能做的操作也是不一樣的。再者綜合教務管理系統(tǒng)的表示層可能是由瀏覽器或者客戶端等方式表現(xiàn)出來，但是其表示層也可以由統(tǒng)一信息門戶系統(tǒng)來展示，統(tǒng)一信息門戶的最大的優(yōu)點之一就是應用系統(tǒng)的集成。綜上所述，教務系統(tǒng)的集成如圖2所示。 

圖2 教務系統(tǒng)對接總體邏輯圖 

    具體而言，綜合教務系統(tǒng)集成的需求包括： 

    共享數(shù)據(jù)需求 

    綜合教務管理系統(tǒng)本擁有自己的數(shù)據(jù)系統(tǒng)，為了適應校園數(shù)字化整體結構要求，其數(shù)據(jù)系統(tǒng)應該保存在共享數(shù)據(jù)中心系統(tǒng)中，從而避免數(shù)據(jù)冗余，達到數(shù)據(jù)利用率高的效果。 

    身份驗證需求 

    綜合教務管理系統(tǒng)本身在設計的時候擁有成熟的權限分配、驗證功能，但是為了適應校園數(shù)字化整體結構的要求，綜合教務管理系統(tǒng)需要將對登錄用戶身份的驗證交給統(tǒng)一身份認證來處理。統(tǒng)一身份認證擁有著一整套的身份驗證方法和驗證權限的方法，如果綜合教務管理系統(tǒng)能夠滿足統(tǒng)一身份認證系統(tǒng)的權限設定要求，那么統(tǒng)一身份認證系統(tǒng)還能夠提供相應的訪問權限。 

    門戶表示需求 

    現(xiàn)有綜合教務管理系統(tǒng)在表示層上已經(jīng)提供了多種方式給用戶使用，但是根據(jù)校園數(shù)字化的整體結構要求，其表示層應該無縫集成在統(tǒng)一信息門戶系統(tǒng)中，綜合教務管理系統(tǒng)只提供邏輯處理過程，數(shù)據(jù)的輸入和產(chǎn)生的結果都交給統(tǒng)一信息門戶進行處理，統(tǒng)一信息門戶系統(tǒng)把產(chǎn)生的結果展現(xiàn)在用戶面前。 

    由于現(xiàn)有的各類平臺基本具有了各類對接的機制，所以與上述需求對應的集成也就可以方便的設計出了。綜合教務管理系統(tǒng)與共享數(shù)據(jù)中心的集成是首當其沖的數(shù)據(jù)級集成，數(shù)據(jù)流示意如圖3所示，綜合教務管理系統(tǒng)為了達到共享數(shù)據(jù)中心對接的目的，首先要分析當前的數(shù)據(jù)結構和共享數(shù)據(jù)中心庫內的數(shù)據(jù)結構區(qū)別，直到建立雙方都能認可的一個協(xié)議后，根據(jù)校園數(shù)據(jù)標準使用數(shù)據(jù)集成客戶端工具在共享數(shù)據(jù)中心庫中建立綜合教務系統(tǒng)需要的部分或者全部數(shù)據(jù)結構。盡管已經(jīng)建立好了數(shù)據(jù)結構，但是兩個系統(tǒng)對于某些字段的定義仍然存在著區(qū)別，所以需要建立一種規(guī)則來達到雙方系統(tǒng)共同認可的字段對應。共享數(shù)據(jù)中心根據(jù)綜合教務管理系統(tǒng)的業(yè)務需要，生成相應的主題庫和中間件，綜合教務管理系統(tǒng)在進行數(shù)據(jù)操作的時候，直接調用中間件服務操作主題庫，以達到對共享數(shù)據(jù)中心庫的操作。

    綜合教務管理系統(tǒng)向統(tǒng)一身份認證系統(tǒng)服務請求示意如圖4所示，用戶在登錄綜合教務管理系統(tǒng)的時候會取得用戶的用戶名和密碼，此時它把用戶名和密碼通過加密方式提交給統(tǒng)一身份認證系統(tǒng)，統(tǒng)一身份認證系統(tǒng)在得到用戶名和密碼后立即驗證其合法性，主要就是反映其是否有訪問綜合教務系統(tǒng)的權限，統(tǒng)一身份認證系統(tǒng)把得到的結果返回給綜合教務管理系統(tǒng)。最后還要考慮的是綜合教務管理系統(tǒng)和統(tǒng)一信息門戶系統(tǒng)的業(yè)務集成，示意如圖5，綜合教務管理系統(tǒng)首先按照邏輯－表示分開的原則分析自己的結構，表示層的結構通過Portlet形式安裝在統(tǒng)一信息門戶系統(tǒng)中，綜合教務管理系統(tǒng)自身保留對業(yè)務邏輯處理的結構，并提供給接口統(tǒng)一信息門戶系統(tǒng)訪問，當用戶使用統(tǒng)一信息門戶系統(tǒng)中的綜合教務Portlet時，統(tǒng)一信息門戶系統(tǒng)會將用戶對Portlet的操作反映給綜合教務管理系統(tǒng)的業(yè)務處理接口，處理完畢后，會返回給統(tǒng)一信息門戶系統(tǒng)，綜合教務Portlet把這些結果反映在頁面上。 

    4．2 身份認證接入接口示例 

    對于統(tǒng)一身份認證，為了更好的集成，一般會提供大量的第三方應用的身份接入接口[ 5 ]，如登錄名/別名認證、修改個人信息/密碼、獲取組織/角色/應用信息、獲取證書、模塊/組織/角色/應用關聯(lián)維護等，下面就以登錄名認證接口和修改個人信息接口為例予以說明。 

    （1）登錄名認證
    方法名
    VerifyUserPassword
    輸入
    <?xml version="1.0" encoding="UTF-8"?>
    <Input>
    <Job>VerifyUserPassword</Job>
    <UserID>c0000005</UserID> //用戶登錄ID 
    <Password>123</Password> //密碼
    <SystemName>portal</SystemName>
    </Input>
    輸出
    成功
    返回用戶基本信息。
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>True</Result>
    <Info>
    <AttrName>SessionID</AttrName> //SessionID
    <AttrValue>1082255488284@1400964957810505343@3</AttrValue>
    </Info>
    <Info>
    <AttrName>cname</AttrName> //姓名
    <AttrValue>許鑫</AttrValue>
    </Info>
    <Info>
    <AttrName>ename</AttrName> //英文名
    <AttrValue />
    </Info>
    ……
    </Output>
    失敗
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>False</Result>
    <Info>錯誤信息</Info>
    </Output>
    （2）修改個人信息
    方法名
    ModifyUser
    輸入
    <?xml version="1.0" encoding="UTF-8"?>
    <Input> 
    <Job>ModifyUser</Job> 
    <SessionID>1082266005586@472673864587841191@4</SessionID>
    <SystemName>portal</SystemName>
    <Attr>
    <AttrName>cname</AttrName> //姓名
    <AttrValue>許鑫</AttrValue>
    </Attr>
    <Attr>
    <AttrName>sex</AttrName> //性別
    <AttrValue>1</AttrValue>
    </Attr>
    <Attr>
    <AttrName>alias</AttrName> //別名
    <AttrValue>c0000008</AttrValue>
    </Attr>
    …… //其它用戶用戶信息
    </Input>
    輸出
    成功
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>True</Result>
    <Info>
    <AttrName>phone</AttrName> //聯(lián)系電話
    <AttrValue />
    </Info>
    …… //新的用戶信息
    </Output>
    失敗
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>False</Result>
    <Info>錯誤信息</Info>
    </Output> 

    5 結束語 

    雖然在上文中針對高校的業(yè)務我們對其應用集成做了一些研究，但還是遠遠不夠的，因為各個學校的流程千差萬別，各個應用系統(tǒng)的底層架構和部署環(huán)境也各有特點，我們研究和設計出來的各種方案也只是一些比較通用的集成做法，對于具體的應用我們還得有針對性的進行技術分析和集成設計，比如高校的里面的辦公自動化系統(tǒng)（OA）架構就有很多，有基于數(shù)據(jù)庫的，也有基于Domino系統(tǒng)的，因為統(tǒng)一身份認證系統(tǒng)是基于標準J2EE結構，如果OA系統(tǒng)是基于J2EE平臺的，J2EE架構又一般采用的是關系型數(shù)據(jù)庫，那么對接的時候可以很方便的以上文描述的方法做集成。

    但如果是基于Domino的OA，因為其自成一套體系，在數(shù)據(jù)存儲的格式、系統(tǒng)開發(fā)環(huán)境上都和J2EE架構完全不一樣，我們要完成對接就得有一些特殊的機制，若辦公自動化系統(tǒng)在對登錄用戶驗證身份的時候，需要向統(tǒng)一身份認證系統(tǒng)提交驗證請求，那么此時一般采用Domino調用DSAPI庫來訪問統(tǒng)一身份認證系統(tǒng)，從而達到身份驗證的目的。DSAPI 是作為一個共享庫（Windows NT/2000/2003 上的一個 DLL 文件或 UNIX/Linux 上的一個共享對象）來實現(xiàn)的，它由 Domino HTTP 進程注冊和調用。有一些關鍵事件與該 HTTP 任務相關聯(lián)，并且這些事件已被 DSAPI 中的定制代碼所改寫。由于 DSAPI 實際上代替了 Domino 身份驗證模型，它促成了廣泛的定制身份驗證需求可通過實現(xiàn) DSAPI 來滿足。
 
    從數(shù)據(jù)的集成到流程的集成，從身份認證的集成到門戶表現(xiàn)的集成，從資源的集成到應用的集成，我們在數(shù)字化校園中的集成研究任重而道遠，期望著和諸位有致于在理論上或者實踐中建設整體數(shù)字化校園的同仁們共同努力。 

（文/南京大學信息管理系，許鑫 蘇新寧）