數字化校園中應用集成研究

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

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

    1 數字化校園總體方案設計 

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

圖1 數字化校園總體方案設計

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

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

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

    2 數字化校園中的一體化設計 

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

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

    2．2 流程 

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

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

    2．3 方法 

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

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

    3 數字化校園中應用集成設計 

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

    3．1 校園各類應用系統的平臺集成 

    3．1．1 各類MIS與共享數據中心 

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

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

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

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

    3．1．2 各類MIS與統一身份認證 

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

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

    3．1．3 各類MIS與統一信息門戶 

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

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

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

    3．2．1 一卡通與共享數據中心 

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

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

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

    3．2．2 一卡通與統一身份認證 

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

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

 用戶信息同步 

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

    卡信息同步 

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

    卡權限管理 

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

    卡認證服務 

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

    3．2．3 一卡通與統一信息門戶 

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

    數據接口 

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

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

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

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

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

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

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

    4 應用集成示例 

    4．1 綜合教務系統集成 

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

圖2 教務系統對接總體邏輯圖 

    具體而言，綜合教務系統集成的需求包括： 

    共享數據需求 

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

    身份驗證需求 

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

    門戶表示需求 

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

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

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

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

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

    （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> //聯系電話
    <AttrValue />
    </Info>
    …… //新的用戶信息
    </Output>
    失敗
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>False</Result>
    <Info>錯誤信息</Info>
    </Output> 

    5 結束語 

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

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

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