數字化校園中應用集成研究
文章出處：http://psychicreadingswithdeb.com 作者：許鑫 蘇新寧 人氣： 發(fā)表時(shí)間：2011年11月23日
對于數字化校園的研究，比較一致的觀(guān)點(diǎn)是把數字化校園的建設分成了三大類(lèi)，第一類(lèi)的平臺的建設，正如前面系列文章中介紹的統一身份認證、統一信息門(mén)戶(hù)、共享數據中心、一卡通平臺等；第二類(lèi)是應用建設，各種各樣的MIS系統、OA系統等等，與學(xué)校的各個(gè)業(yè)務(wù)部門(mén)和流程密切相關(guān)的管理信息系統；第三類(lèi)是資源建設，包括數字圖書(shū)館、數據博物館、課件庫、資源庫等數字資源的建設。然而，究竟如何構建我們的整體的數字化校園，如何將這三者有機的聯(lián)系一起，集成便成了大家共同關(guān)注的問(wèn)題。
1 數字化校園總體方案設計
數字化校園整體解決方案一般分為數字化校園應用支撐平臺解決方案、數字化校園應用建設解決方案、數字化校園應用接入解決方案、數字化校園應用表現解決方案、數字化校園管理決策支持解決方案五大部分，如圖1所示。
圖1 數字化校園總體方案設計
其中應用支撐平臺是整個(gè)數字化校園的軟件基礎平臺，主要包括共享數據中心、統一身份認證、統一信息門(mén)戶(hù)和一卡通平臺系統（校園金融消費與電子識別解決方案）等幾個(gè)部分。
應用建設解決方案綜合了大量高校的需求調研結果，是擴展性和適用性強大的各類(lèi)管理信息系統，可以分為師生員工管理、教務(wù)事務(wù)管理、科研外事管理、后勤事務(wù)管理、財務(wù)事務(wù)管理、固定資產(chǎn)管理、辦公自動(dòng)化系統等大類(lèi)，具體細化，比如師生員工管理包括了人事管理、招生管理、迎新管理、學(xué)工管理、就業(yè)管理、校友管理等具體的管理信息系統，再如后勤事務(wù)管理也包含了食堂就餐、商場(chǎng)、超市、洗衣、復印、校巴、考勤、門(mén)禁、醫療、體育設施、上機、電控、水控、保安巡更等子系統。
而應用系統接入方案則重要依靠一些應用系統集成工具，將原有的應用系統可以方便的接入校園共享數據中心，身份認證系統、信息門(mén)戶(hù)系統和一卡通系統，這一塊的設計和考慮將是本文研究的重點(diǎn)，后面將有進(jìn)一步的探討。最后通過(guò)在共享數據中心基礎上應用數據挖掘技術(shù)提供的一系列數值分析工具實(shí)現管理決策支持等工作，進(jìn)一步提升校園管理水平。
2 數字化校園中的一體化設計
在實(shí)際的數字化校園建設中，我們可以采用接入的方式完整各類(lèi)平臺和系統的整合，但這只是一種事后的處理方法，在新開(kāi)展的數字化校園整體建設中，我們的期望的是在一開(kāi)始就能有一體化的設計，把并在后期的實(shí)施中不折不扣的實(shí)現既定的規劃和設計，在一體化設計中，貫穿于始終的是數據和流程這兩個(gè)關(guān)鍵。
2．1 數據
在數據上的考慮首先體現在信息標準的建設上，繼而體現在信息的分類(lèi)、數據的組織和數據庫的設計上[ 2,3 ]。舉例而言，如果高校缺乏對校園信息化的深入理解，那么在其構建信息標準的時(shí)候就無(wú)法根據具體學(xué)校的實(shí)際情況自主考慮。一般通用的教育部信息標準也僅僅是供參考的，只說(shuō)明信息點(diǎn)內容，并不標明主鍵信息，這就需要在實(shí)際的實(shí)施中針對學(xué)校情況進(jìn)行分類(lèi)（也就是數據庫的建表設計），在科學(xué)性、系統性等原則下，按照信息來(lái)源、組織形式或者使用范圍等幾種方法，把相同類(lèi)型的數據提煉出來(lái)，完成對信息的分類(lèi)。然后再為每張表建立一個(gè)主鍵ID，其生成為UUID（全球統一標識碼 ），實(shí)現以一張核心信息表為主，若干張附屬信息作為補充，理清表與表之間的邏輯關(guān)系（表的組織，若干主題庫等）。
同樣的一體化設計還體現在對平臺系統的深入理解上，以有鮮明特點(diǎn)的一卡通系統為例，必須對一卡通業(yè)務(wù)數據有一定的了解，才可能在數據中心設計出符合一卡通需求的類(lèi)別及庫表來(lái)，才能夠清晰地梳理出誰(shuí)是核心表誰(shuí)是主鍵，才能夠完成一卡通相應數據字段和其它應用系統字段的對應，并完成較深層次的集成……這些一體化的設計也存在于其他校園平臺的設計中。
2．2 流程
流程既體現在現有流程的實(shí)現上，又體現在校園業(yè)務(wù)流程的重組上，是否在設計上充分的考慮，關(guān)系到需求變更帶來(lái)的快速調整能否實(shí)現？也關(guān)系到各種功能擴充的高效實(shí)施。
以數字化校園整體解決方案為例，在技術(shù)架構層與層之間以及層內各組件之間定義了標準接口，達到松耦合，使應用系統的開(kāi)發(fā)及后續擴展只需要關(guān)注其中相關(guān)的部分。當某些提供服務(wù)的業(yè)務(wù)系統發(fā)生變化時(shí)，不會(huì )影響到使用服務(wù)的其他業(yè)務(wù)系統的正確運行。而且新的流程需求產(chǎn)生以后，或者學(xué)校業(yè)務(wù)流程發(fā)生了改變，事前的充分設計和各類(lèi)機制的存在就成了積極的保障。
2．3 方法
除了數據和流程的一體化設計以外，在整體的數字化校園建設中還需要注意方法。方法論的一致不僅僅體現在早期的整體統一規劃中，更體現在高校信息化應用需求的實(shí)現中。統一數據標準、統一數據交互、個(gè)性定制、統一權限、統一建設、統一表現及表現擴展、統一管理等都是數字化校園一體化設計中方法所需要的關(guān)注的。再者關(guān)于數字化校園建設中的問(wèn)題及對策在我們的本系列文章的第一篇中也有相應的研究和描述，前瞻性的規劃、統一性的設計、整體性的建設構成了我們數字化校園建設方法論的核心。
在此基礎上的擴展還體現在建設的步驟和節奏上，體現在投資上和評估上。有些學(xué)校應用建設比較完善，他們需要的可能是后期的整合；有些學(xué)校直接先上平臺等基礎設施，它們可能需要的是如何在平臺基礎上更快更方便的建設應用；也有些學(xué)校分別進(jìn)行了一些一卡通、資源庫、基礎平臺之類(lèi)的信息化建設，此時(shí)后期的集成變成了關(guān)鍵。各個(gè)學(xué)校有各個(gè)學(xué)校建設的步驟，同時(shí)對于節奏的控制也十分重要，既不能“貪多嚼不爛”，虎頭蛇尾的建設，也不能“再而衰，三而竭”，信息化進(jìn)程拖沓不可控是很?chē)乐氐膯?wèn)題。此外一體化的設計還體現的投資上的綜合考慮，比如在軟硬件部署上根據建設要求充分考慮，共享設計，避免重復投資。避免購買(mǎi)很多服務(wù)器，但大多數利用不高，或者購買(mǎi)了各類(lèi)數據庫軟件，但各個(gè)庫上跑的數據和業(yè)務(wù)都很有限等諸如此類(lèi)的問(wèn)題。
3 數字化校園中應用集成設計
數字化校園的應用集成設計主要體現在平臺和應用的對接上，同時(shí)，因為一卡通平臺涉及到硬件設備，而且又是金融化的系統，所以其集成也是有特點(diǎn)的。
3．1 校園各類(lèi)應用系統的平臺集成
3．1．1 各類(lèi)MIS與共享數據中心
對于各類(lèi)MIS與共享數據中心平臺的集成，首先要分析應用的數據結構和共享數據中心庫內的數據結構的區別。建立雙方都能認可的一個(gè)協(xié)議后，根據校園數據標準使用數據集成客戶(hù)端工具在共享數據中心庫中建立系統需要的部分或者全部數據結構。針對系統間對于某些字段的定義仍然存在著(zhù)區別，建立一種規則來(lái)達到雙方共同認可的字段對應。共享數據中心根據應用系統的業(yè)務(wù)需要，生成相應的主題庫和中間件，應用系統在進(jìn)行數據操作的時(shí)候，直接調用中間件服務(wù)操作主題庫，以達到對共享數據中心庫的操作。
對數據中心的集成接入特點(diǎn)體現在需要對要接入的每一個(gè)應用系統的數據源進(jìn)行調研，確保提供一定程度的數據接口，這個(gè)從應用系統往共享數據中心的上行過(guò)程要確定從應用系統抽取哪些數據，這些數據的含義是什么，即提供相應的數據字典，并且確定對應于數據中心的哪張表，可接入的數據接口模式分為：
模式一：直接開(kāi)放數據庫，只需要只讀的賬戶(hù)權限即可，需要在絕對保證原有系統數據安全性和完整性，不影響原有系統運行的基礎上建立觸發(fā)器。
模式二：中間文件數據源，如應用系統不能對外開(kāi)放數據庫，則可以導出差異數據文件到指定的目錄，這些文件可以是Access文件數據庫模式、excel文件模式等，格式可在實(shí)施時(shí)共同商定。
3．1．2 各類(lèi)MIS與統一身份認證
數字化校園的整體建設客觀(guān)上要求建設統一的身份認證中心，針對各個(gè)集成到身份認證系統的應用系統，提供身份相關(guān)服務(wù)。這里是最權威的用戶(hù)基本信息的集中存儲，用戶(hù)身份信息的唯一入口；對每個(gè)應用提供用戶(hù)組的定義，為權限管理提供了手段；提供了用戶(hù)身份認證服務(wù)和單點(diǎn)登陸（SSO）的方法。數據同步服務(wù)提供用戶(hù)數據同步復制的機制，支持應用建立單獨的數據庫，并保持兩邊數據的一致性和不冗余；數據訪(fǎng)問(wèn)服務(wù)提供了安全的、有權限控制的應用系統訪(fǎng)問(wèn)用戶(hù)身份信息的方法。用戶(hù)在登錄應用系統的時(shí)候，應用系統會(huì )取得用戶(hù)的用戶(hù)名和密碼，此時(shí)它把用戶(hù)名和密碼通過(guò)加密方式提交給統一身份認證系統。統一身份認證系統在得到用戶(hù)名和密碼后立即驗證其合法性，主要就是反映其是否有訪(fǎng)問(wèn)系統的權限，統一身份認證系統把得到的結果返回給應用系統。
各類(lèi)MIS和認證平臺的集成主要體現在統一身份認證給其他的應用系統提供訪(fǎng)問(wèn)者身份的驗證信息。每一個(gè)應用系統通過(guò)某種途徑訪(fǎng)問(wèn)把訪(fǎng)問(wèn)者的信息提交給統一身份認證平臺，一般是通過(guò)使用socket實(shí)現訪(fǎng)問(wèn)接口，應用系統把訪(fǎng)問(wèn)者信息按照規定的要求格式轉化為xml包，發(fā)送到統一身份認證平臺前置機上，前置機收取后經(jīng)過(guò)處理返回結果包，同樣也是采用xml格式?，F階段統一身份認證平臺能夠提供給Portal比較詳細的認證，包括權限等，但對于其他的各類(lèi)應用系統則接入層次參差不齊，這是因為一些系統內部存在著(zhù)自己的權限分配策略（非RBAC模式），沒(méi)有或者不能夠把權限分配存放在統一身份認證平臺上。若應用系統把其使用權限移交到統一身份認證平臺上，那么必須要按照要求把權限按照角色或者組織來(lái)劃分，則認證平臺在返回結果包時(shí)包含著(zhù)訪(fǎng)問(wèn)者的角色和權限信息。
3．1．3 各類(lèi)MIS與統一信息門(mén)戶(hù)
建設統一信息門(mén)戶(hù)作為個(gè)人單點(diǎn)登陸和信息發(fā)布的集中點(diǎn)，一方面面向個(gè)人用戶(hù)，如果個(gè)人不登陸，在信息門(mén)戶(hù)上可以獲取公共的信息；用戶(hù)在信息門(mén)戶(hù)登陸一次以后查詢(xún)到所有與其個(gè)人相關(guān)的信息及進(jìn)行某些業(yè)務(wù)系統的操作；提供鏈接，對于某些集成到統一身份認證系統且有單獨Web信息發(fā)布的應用，可以平滑進(jìn)入，無(wú)需再次身份認證。在面向應用開(kāi)發(fā)方面，提供了統一的應用開(kāi)發(fā)模式；提供了基于Web的統一的權限管理模式；提供了統一的界面表現形式，可以將來(lái)源于各種應用系統的數據集中發(fā)布，互不干擾。
應用系統首先按照邏輯/表示分開(kāi)的原則分析自己的結構，表示層的結構通過(guò)Portlet形式安裝在統一信息門(mén)戶(hù)系統中，應用系統自身保留對業(yè)務(wù)邏輯處理的結構，并提供給接口統一信息門(mén)戶(hù)系統訪(fǎng)問(wèn)。當用戶(hù)使用統一信息門(mén)戶(hù)系統中的某一Portlet時(shí)，統一信息門(mén)戶(hù)系統會(huì )將用戶(hù)對Portlet的操作反映給應用系統的業(yè)務(wù)處理接口，處理完畢后，會(huì )返回給統一信息門(mén)戶(hù)系統，Portlet則把這些結果反映在頁(yè)面上。對門(mén)戶(hù)平臺的接入大體上有三種方式，一種是開(kāi)發(fā)者把頁(yè)面和邏輯都卸載Portlet中，則此Portlet可以脫離開(kāi)現有的應用系統，成為現有應用系統的替代者；另外一種是開(kāi)發(fā)者可以把邏輯和頁(yè)面分離，Portlet是其頁(yè)面部分，每次把需要的信息通過(guò)POST方法提交到應用系統中，應用系統的Servlet或其它運行程序通過(guò)處理把結果返回給Portal，Portlet把得到的結果顯示出來(lái)；還有一種是其他的應用系統也可以提供相應的EJB，開(kāi)發(fā)者只需要在Portlet中直接調用具體的EJB即可。
3．2 一卡通平臺和其他平臺的集成
3．2．1 一卡通與共享數據中心
在數字化校園中，數據層面的所需信息集中存儲，并給各應用子系統共享，有效防止信息的冗余和不一致，保證數據的準確性和可靠性；可以方便的實(shí)現核心數據的集中管理、備份，提高系統的安全性，減少設備的投資和管理的人力成本。數據中心在數據級對“一卡通”和其他系統的數據進(jìn)行無(wú)縫集成，便于信息的共享、交流和各項業(yè)務(wù)的協(xié)作。
一卡通系統應該充分使用統一共享數據平臺提供的公共數據編碼、身份信息等數據。而不應該單獨維護一套獨立、非標準的信息。同時(shí)一卡通系統擁有自己的業(yè)務(wù)數據庫，將其他應用系統需要的信息納入共享數據庫的統一設計中，實(shí)現校園一卡通系統數據對整個(gè)數字化校園的共享。通過(guò)數字化校園應用建設，形成一套符合高校自身實(shí)際的管理信息化標準，也是數字化校園建設中的一項重要內容。我們根據自己的理解，結合大量的案例，會(huì )根據學(xué)校信息化現狀提出信息代碼編碼標準、軟硬件平臺標準、應用系統規范、業(yè)務(wù)流程規范和數據交換標準等，這樣為今后的應用系統的建設制定了規范。一卡通作為重要的應用系統必須符合整體標準。
一般而言為了集成，一卡通使用的公共信息字典必須遵循學(xué)校的信息編碼規范，數據模式必須遵循數據庫第三范式，一卡通使用的用戶(hù)及其信息必須和業(yè)務(wù)系統提供的信息是一致的，可以相互關(guān)聯(lián)的，以保證一卡通的數據和學(xué)校的其他信息數據能同時(shí)進(jìn)行查詢(xún)、分析、統計。針對于卡的門(mén)戶(hù)應用，共享數據中心中的數據需要既能展示相關(guān)的信息，如：校園卡選課后學(xué)生的選課課程、選課的繳費等，又能統計相關(guān)的信息，如：不同的專(zhuān)業(yè)的學(xué)生費用使用總計及平均消費情況等，這些都需要充分的集成設計。
3．2．2 一卡通與統一身份認證
數字化校園建設初期一般多注重建成以目錄服務(wù)為基礎的統一身份認證系統，而一卡通建設也有自己的身份認證和設備認證，隨著(zhù)數字校園的深入建設，CA認證中心、電子簽名、電子印章的出現，我們必須重新規劃全校的身份認證體系，卡作為統一身份認證的認證載體，不僅可以用作消費，還為統一身份認證平臺提供了基于用戶(hù)名/密碼認證、CA、指紋等存儲。
原有一卡通系統具有單獨一套的用戶(hù)管理和用戶(hù)組管理模塊，在和統一身份認證系統集成之后，統一身份認證系統作為添加用戶(hù)的唯一入口，已經(jīng)實(shí)現了這部分功能，因此一卡通系統中的這部分功能不再需要，身份信息從統一身份認證系統獲取。原有的以一卡通管理平臺集成的應用，例如圖書(shū)館系統、考勤系統，不再到一卡通管理平臺認證身份，而是直接和統一身份認證系統集成。
考慮到校園一卡通系統的特殊應用場(chǎng)景，具有專(zhuān)網(wǎng)設計、脫機使用的要求，統一身份認證中心支持一卡通系統建立自己?jiǎn)为毜臄祿?，定制開(kāi)發(fā)后臺數據復制的服務(wù)，使得校園一卡通系統可以保持和統一身份認證數據的一致；對于校園一卡通系統的Web應用部分，通過(guò)將其納入信息發(fā)布門(mén)戶(hù)體系，使用統一身份認證系統接口，自然支持單點(diǎn)登錄。
用戶(hù)信息同步
一卡通系統所有用戶(hù)信息均可以來(lái)自于統一身份認證中心，原則上要求統一認證用戶(hù)庫中的用戶(hù)基本信息數據是相對完整的、權威的，初始化時(shí)可從統一身份認證系統中批量導入數據，以后接收統一身份認證系統中的用戶(hù)變化信息，保持與二者的同步。
卡信息同步
在統一身份認證系統里面保存卡ID號、卡狀態(tài)（未發(fā)卡、已發(fā)卡、已掛失）、卡有效期等信息，一卡通系統在完成發(fā)卡、掛失、解掛、補卡、換卡等業(yè)務(wù)的同時(shí)，需要將卡信息同步發(fā)送到統一身份認證系統中。
卡權限管理
一卡通內部的權限，如卡的使用權限、管理權限應當由一卡通平臺本身來(lái)管理，但消費記錄查詢(xún)等由專(zhuān)門(mén)的Web應用處理的這部分權限可以放在統一身份系統中管理。
卡認證服務(wù)
當實(shí)現了卡認證服務(wù)時(shí)，該卡（人）在某個(gè)應用系統中的權限可以根據情況選擇應用系統單獨管理或者由統一身份認證系統分配，以完成卡認證和其它各應用的授權。
3．2．3 一卡通與統一信息門(mén)戶(hù)
門(mén)戶(hù)系統與“一卡通”系統可以方便地進(jìn)行整合，門(mén)戶(hù)系統將統一成為應用系統和“一卡通”系統地展現平臺，便與學(xué)校的統一管理。信息發(fā)布平臺包含了動(dòng)態(tài)網(wǎng)站的框架和應用系統開(kāi)發(fā)集成平臺。信息發(fā)布平臺部分欄目由平臺自身提供的工具維護，與一卡通系統相關(guān)的部分則需要二次開(kāi)發(fā)或者集成。平臺與一卡通系統的接口分為兩部分：
數據接口
一卡通系統提供數據源，數據源包括數據庫表或者視圖的結構、用戶(hù)名稱(chēng)、口令，信息發(fā)布平臺通過(guò)數據源可以獲得需要發(fā)布的所有信息，可以將數據存儲在信息發(fā)布臨時(shí)的數據庫中或者直接訪(fǎng)問(wèn)一卡通系統的數據庫，在信息發(fā)布平臺上重新開(kāi)發(fā)和配置查詢(xún)的應用。
認證接口
將一卡通原有的Web發(fā)布系統的形式集成進(jìn)信息發(fā)布平臺，這種鏈接不是簡(jiǎn)單的Web鏈接，而是需要將一卡通系統的用戶(hù)登陸進(jìn)行改進(jìn)，保證在信息平臺上登陸一次即可以進(jìn)入子系統，無(wú)需二次登陸，實(shí)現單點(diǎn)登陸。
在數字化校園環(huán)境下的信息發(fā)布平臺的形式主要有以下四種：網(wǎng)站、多媒體終端、電話(huà)、郵件。網(wǎng)站開(kāi)發(fā)基于統一信息門(mén)戶(hù)平臺，以開(kāi)發(fā)Portlet的模式進(jìn)行；另外挑選造型美觀(guān)的觸摸屏電腦，配備讀寫(xiě)器，作為校園的自助多媒體查詢(xún)終端。自助查詢(xún)終端不僅僅作為一卡通的系統的信息查詢(xún)和發(fā)布的終端，也應該用于其它應用系統如教務(wù)系統、圖書(shū)館系統、學(xué)工系統等等信息的查詢(xún)和發(fā)布終端。一卡通與統一信息門(mén)戶(hù)的集成包括：
（1） 一卡通系統提供數據源，門(mén)戶(hù)平臺通過(guò)數據源可以獲得需要發(fā)布的所有信息，可以將數據存儲在信息發(fā)布臨時(shí)的數據庫中或者直接訪(fǎng)問(wèn)一卡通系統的發(fā)布數據庫，在信息發(fā)布平臺上重新開(kāi)發(fā)和配置查詢(xún)，將各類(lèi)消費與管理的信息及需要查詢(xún)的明細發(fā)布到門(mén)戶(hù)，提供權限控制下的信息查詢(xún)與統計和分析。
（2） 在門(mén)戶(hù)上集成一卡通系統的用戶(hù)登錄，使得門(mén)戶(hù)上一卡通系統的相應欄目可以直接顯示持卡人最直接需要的統計結果，以提供最人性化的服務(wù)方式。
（3） 在原有信息服務(wù)基礎上，通過(guò)與其他應用及校園基礎網(wǎng)絡(luò )服務(wù)的整合，開(kāi)發(fā)新的服務(wù)模塊，并集成到門(mén)戶(hù)上，利用門(mén)戶(hù)提供的各種發(fā)布方式向全校師生提供增值信息服務(wù)。
（4） 通過(guò)將校園一卡通系統的信息查詢(xún)與統計集成到門(mén)戶(hù)上，可以借助門(mén)戶(hù)的Web發(fā)布、多媒體查詢(xún)終端、電話(huà)語(yǔ)音等各種發(fā)布手段，擴展校園一卡通服務(wù)的覆蓋面。
4 應用集成示例
4．1 綜合教務(wù)系統集成
綜合教務(wù)管理系統是輔助學(xué)校教師、學(xué)生進(jìn)行綜合業(yè)務(wù)管理的一個(gè)平臺，是數字化校園業(yè)務(wù)系統中的重點(diǎn)。綜合教務(wù)管理系統一般具有自己的一套數據庫標準和數據結構，但對于整體數字化校園建設的高校而言，因為已經(jīng)制定了一套統一的信息標準，所以綜合教務(wù)管理系統的數據就必須和共享數據中心有著(zhù)一個(gè)接入同步的過(guò)程。同時(shí)綜合教務(wù)管理系統的使用者是教師和學(xué)生，每個(gè)使用此系統的人都有著(zhù)不同的身份、角色、權限。例如在網(wǎng)上選課系統中，不同年級、不同專(zhuān)業(yè)的學(xué)生所能選擇的課程是不一樣的，在學(xué)生學(xué)籍管理中，不同的老師所能做的操作也是不一樣的。再者綜合教務(wù)管理系統的表示層可能是由瀏覽器或者客戶(hù)端等方式表現出來(lái)，但是其表示層也可以由統一信息門(mén)戶(hù)系統來(lái)展示，統一信息門(mén)戶(hù)的最大的優(yōu)點(diǎn)之一就是應用系統的集成。綜上所述，教務(wù)系統的集成如圖2所示。
圖2 教務(wù)系統對接總體邏輯圖
具體而言，綜合教務(wù)系統集成的需求包括：
共享數據需求
綜合教務(wù)管理系統本擁有自己的數據系統，為了適應校園數字化整體結構要求，其數據系統應該保存在共享數據中心系統中，從而避免數據冗余，達到數據利用率高的效果。
身份驗證需求
綜合教務(wù)管理系統本身在設計的時(shí)候擁有成熟的權限分配、驗證功能，但是為了適應校園數字化整體結構的要求，綜合教務(wù)管理系統需要將對登錄用戶(hù)身份的驗證交給統一身份認證來(lái)處理。統一身份認證擁有著(zhù)一整套的身份驗證方法和驗證權限的方法，如果綜合教務(wù)管理系統能夠滿(mǎn)足統一身份認證系統的權限設定要求，那么統一身份認證系統還能夠提供相應的訪(fǎng)問(wèn)權限。
門(mén)戶(hù)表示需求
現有綜合教務(wù)管理系統在表示層上已經(jīng)提供了多種方式給用戶(hù)使用，但是根據校園數字化的整體結構要求，其表示層應該無(wú)縫集成在統一信息門(mén)戶(hù)系統中，綜合教務(wù)管理系統只提供邏輯處理過(guò)程，數據的輸入和產(chǎn)生的結果都交給統一信息門(mén)戶(hù)進(jìn)行處理，統一信息門(mén)戶(hù)系統把產(chǎn)生的結果展現在用戶(hù)面前。
由于現有的各類(lèi)平臺基本具有了各類(lèi)對接的機制，所以與上述需求對應的集成也就可以方便的設計出了。綜合教務(wù)管理系統與共享數據中心的集成是首當其沖的數據級集成，數據流示意如圖3所示，綜合教務(wù)管理系統為了達到共享數據中心對接的目的，首先要分析當前的數據結構和共享數據中心庫內的數據結構區別，直到建立雙方都能認可的一個(gè)協(xié)議后，根據校園數據標準使用數據集成客戶(hù)端工具在共享數據中心庫中建立綜合教務(wù)系統需要的部分或者全部數據結構。盡管已經(jīng)建立好了數據結構，但是兩個(gè)系統對于某些字段的定義仍然存在著(zhù)區別，所以需要建立一種規則來(lái)達到雙方系統共同認可的字段對應。共享數據中心根據綜合教務(wù)管理系統的業(yè)務(wù)需要，生成相應的主題庫和中間件，綜合教務(wù)管理系統在進(jìn)行數據操作的時(shí)候，直接調用中間件服務(wù)操作主題庫，以達到對共享數據中心庫的操作。
綜合教務(wù)管理系統向統一身份認證系統服務(wù)請求示意如圖4所示，用戶(hù)在登錄綜合教務(wù)管理系統的時(shí)候會(huì )取得用戶(hù)的用戶(hù)名和密碼，此時(shí)它把用戶(hù)名和密碼通過(guò)加密方式提交給統一身份認證系統，統一身份認證系統在得到用戶(hù)名和密碼后立即驗證其合法性，主要就是反映其是否有訪(fǎng)問(wèn)綜合教務(wù)系統的權限，統一身份認證系統把得到的結果返回給綜合教務(wù)管理系統。最后還要考慮的是綜合教務(wù)管理系統和統一信息門(mén)戶(hù)系統的業(yè)務(wù)集成，示意如圖5，綜合教務(wù)管理系統首先按照邏輯－表示分開(kāi)的原則分析自己的結構，表示層的結構通過(guò)Portlet形式安裝在統一信息門(mén)戶(hù)系統中，綜合教務(wù)管理系統自身保留對業(yè)務(wù)邏輯處理的結構，并提供給接口統一信息門(mén)戶(hù)系統訪(fǎng)問(wèn)，當用戶(hù)使用統一信息門(mén)戶(hù)系統中的綜合教務(wù)Portlet時(shí)，統一信息門(mén)戶(hù)系統會(huì )將用戶(hù)對Portlet的操作反映給綜合教務(wù)管理系統的業(yè)務(wù)處理接口，處理完畢后，會(huì )返回給統一信息門(mén)戶(hù)系統，綜合教務(wù)Portlet把這些結果反映在頁(yè)面上。
4．2 身份認證接入接口示例
對于統一身份認證，為了更好的集成，一般會(huì )提供大量的第三方應用的身份接入接口[ 5 ]，如登錄名/別名認證、修改個(gè)人信息/密碼、獲取組織/角色/應用信息、獲取證書(shū)、模塊/組織/角色/應用關(guān)聯(lián)維護等，下面就以登錄名認證接口和修改個(gè)人信息接口為例予以說(shuō)明。
（1）登錄名認證
方法名
VerifyUserPassword
輸入
<?xml version="1.0" encoding="UTF-8"?>
<Input>
<Job>VerifyUserPassword</Job>
<UserID>c0000005</UserID> //用戶(hù)登錄ID
<Password>123</Password> //密碼
<SystemName>portal</SystemName>
</Input>
輸出
成功
返回用戶(hù)基本信息。
<?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）修改個(gè)人信息
方法名
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>
…… //其它用戶(hù)用戶(hù)信息
</Input>
輸出
成功
<?xml version="1.0" encoding="UTF-8"?>
<Output>
<Result>True</Result>
<Info>
<AttrName>phone</AttrName> //聯(lián)系電話(huà)
<AttrValue />
</Info>
…… //新的用戶(hù)信息
</Output>
失敗
<?xml version="1.0" encoding="UTF-8"?>
<Output>
<Result>False</Result>
<Info>錯誤信息</Info>
</Output>
5 結束語(yǔ)
雖然在上文中針對高校的業(yè)務(wù)我們對其應用集成做了一些研究，但還是遠遠不夠的，因為各個(gè)學(xué)校的流程千差萬(wàn)別，各個(gè)應用系統的底層架構和部署環(huán)境也各有特點(diǎn)，我們研究和設計出來(lái)的各種方案也只是一些比較通用的集成做法，對于具體的應用我們還得有針對性的進(jìn)行技術(shù)分析和集成設計，比如高校的里面的辦公自動(dòng)化系統（OA）架構就有很多，有基于數據庫的，也有基于Domino系統的，因為統一身份認證系統是基于標準J2EE結構，如果OA系統是基于J2EE平臺的，J2EE架構又一般采用的是關(guān)系型數據庫，那么對接的時(shí)候可以很方便的以上文描述的方法做集成。
但如果是基于Domino的OA，因為其自成一套體系，在數據存儲的格式、系統開(kāi)發(fā)環(huán)境上都和J2EE架構完全不一樣，我們要完成對接就得有一些特殊的機制，若辦公自動(dòng)化系統在對登錄用戶(hù)驗證身份的時(shí)候，需要向統一身份認證系統提交驗證請求，那么此時(shí)一般采用Domino調用DSAPI庫來(lái)訪(fǎng)問(wèn)統一身份認證系統，從而達到身份驗證的目的。DSAPI 是作為一個(gè)共享庫（Windows NT/2000/2003 上的一個(gè) DLL 文件或 UNIX/Linux 上的一個(gè)共享對象）來(lái)實(shí)現的，它由 Domino HTTP 進(jìn)程注冊和調用。有一些關(guān)鍵事件與該 HTTP 任務(wù)相關(guān)聯(lián)，并且這些事件已被 DSAPI 中的定制代碼所改寫(xiě)。由于 DSAPI 實(shí)際上代替了 Domino 身份驗證模型，它促成了廣泛的定制身份驗證需求可通過(guò)實(shí)現 DSAPI 來(lái)滿(mǎn)足。
從數據的集成到流程的集成，從身份認證的集成到門(mén)戶(hù)表現的集成，從資源的集成到應用的集成，我們在數字化校園中的集成研究任重而道遠，期望著(zhù)和諸位有致于在理論上或者實(shí)踐中建設整體數字化校園的同仁們共同努力。
（文/南京大學(xué)信息管理系，許鑫 蘇新寧）
