天津海運職業學院 郭 皓
數字化校園數據整合的設計與實現
天津海運職業學院 郭 皓
數字化校園在高校教學、科研、生活、信息服務中發揮巨大作用,是學院行政人員、教師、學生日常工作、學習必不可少的信息化工具,涉及教務系統、人事系統、OA協同辦公系統、科研系統、學工系統、迎新系統、離校系統、郵件系統、移動校園等20余個,由此產生的數據冗余問題、多用戶名密碼問題越發明顯,而數據整合勢在必行。
數據整合 數字化校園 應用
我國高校數字化校園建設已經開展了多年,但仍處于信息化基礎設施建設為主的初級階段,而且有很多學校仍然是缺乏信息化基礎設施,數據整合方面仍較弱,信息孤島的情況占多數。
1.重平臺、輕應用、重系統、輕用戶
傳統數字化校園只關注平臺的建設和應用系統建設,并沒有從以人為本的角度為校園提供有用、愛用、常用的應用服務。
2.展現程度單一
雖然大多數統一門戶系統擁有個性化的功能,但是沒有從根本的頂層設計層面上解決實際問題,無法向全校師生提供全方位、主動式服務。我們要提供一個集成所有系統的門戶平臺,解決各個子系統的孤島現象,從而為全校師生主動地提供各個業務服務,如根據教職工權限、角色不同,進入門戶平臺后,既可以顯示個人信息,還可以查閱OA文件、通知,還可以查看教學情況、科研進度等。
3.數字化校園數據整合工程有始無終
做過建設數字化校園數據整合的高校都有經驗不足的感慨,而且規劃了很多期,每一期規劃很好,落實很差。
數字化校園在高校扮演者越來越重要的作用,隨著信息系統的增多,隨之而來的數據冗余問題也越發明顯,打通各子系統數據庫,整合多業務系統的數據勢在必行。
1.信息標準、用戶名不統一問題,將眾多信息系統登錄用戶名統一成一個,方便教師、學生日常工作、學習。
2.深入解決信息系統獨立問題,建立統一身份認證,并將管理權限進行統一管理,各類信息數據進行整合,能夠盡可能小的降低數據冗余。
3.力爭建立個人門戶中心,進行統一入口登錄,隨之進行數據整合后將重要信息數據抽取進來,形成統一的整體。
4.為院領導、中層等管理人員提供各類報表查詢,并能利用統計結果進行綜合分析,同時對數據進行進一步深入挖掘,為未來學院發展起到重要作用。
SOA是采用來源于服務的設計思路,采用先進的軟件設計架構,遵循SOA相關標準與規范(服務數據對象SDO、服務組件架構SCA),解決異構系統間的集成,建立學校的服務管理平臺(SMP)和WebService服務庫,為教職工、學生提供個性化的服務。本次課題采用SOA的架構進行開發,提高系統的可維護性和軟件代碼的重用性,降低學校對IT資源的投資。
按J2EE (Java 2 Enterprise Edition) 規格,采用Java編程語言和服務器端Java技術(如EJBs、Servlet、JNDI、JDBC和 RMI)開發。采用分布式組件EJBs和Web Services實現業務邏輯;服務的定位采用JNDI/UDDI方式,支持分布式服務提供者。
1.數據源
(1)人事系統。教職工數據采集來源,信息包括工號、姓名、身份證號等;職稱類信息包括學歷、學位、畢業時間、畢業院校、職稱等;教師培訓信息包括培訓單位、培訓時間、培訓內容等。
(2)教務系統。教學數據采集來源,學生學號、學制、學分、課表、排課、學生成績、任課教師、上課地點等。
(3)學工系統。學生數據采集來源,學生信息包括姓名、身份證號、學號、獎、勤、助、貸款等信息。
(4)OA協同辦公系統。教職工辦公信息采集來源,部門組織架構、通知、公告、發文、收文、印章、各種申請、審批流程、審批權限等。
(5)迎新系統。學生信息首來源,學生入校前,教委下發數據,如學生姓名、性別、身份證號、填報專業、學制信息等。
(6)網絡教學平臺。教學資源信息來源,課件資源(視頻、文檔、附件)、精品課、作業、測驗、討論區等。
(7)離校系統。學生辦理離校手續信息來源,圖書信息、宿舍信息、學分信息、學工信息等。
(8)一卡通系統。學生在校消費記錄信息,學號、食堂刷卡信息、圖書借閱信息、超時消費信息等。
(9)移動校園。通過手機APP查詢OA、教學課程、學分、成績等信息。
2.推送范圍
數據中心抓取共性數據后進行數據推送,將以上教師類信息推送到OA辦公系統、教務系統、網絡教學平臺、學工系統等;迎新系統中的學生數據推送到教務系統、學工系統、網絡教學平臺等,具體抓取和推送描述如圖1所示。
3.定時器
業務數據庫新增、修改、刪除數據不及時,本課題定于凌晨24點進行數據抓取與同步,因為數據中轉和數據同步體現的是數據庫間的數據交換,先后順序和邏輯管理較復雜。考慮現狀后,決定在教職工操作很少的時間段進行,保證數據準確性。定時器的設定需要完善設置時間點處理事務,對于設定的時間有一個良好判斷,做最優化時間定位。與此同時,初步實現定時器智能化。
4.數據交換監控
數據交換監控主要就是為了處理數據的抽取、訂閱配置操作的監控。其中,涉及數據抽取配置和訂閱配置的審核、定時器設置、日志查看等日常管理;以便對事務處理情況有一定的掌控作用。數據抽取和訂閱設置定時器可以對抽取或訂閱的事務進行定時操作,以便實現數據的定時同步。對于用戶權限上的約束:系統管理員可以查看所有的事務配置,同時可以做相應的修改操作;業務系統數據庫管理員可以查看自己配置的數據訂閱事務狀況。

圖1 數據抓取和推送流程圖
SSO(Single Sign On)單點登錄,基于用戶/會話認證的一個過程,只需一次性提供憑證(僅一次登錄)就可以訪問多個應用。單點登錄主要基于Web的多種應用程序,即通過瀏覽器實現對多個B/S架構應用的統一賬戶認證。
1.授權和認證
對登錄用戶身份信息,反復認證,提供數據庫認證、LDAP認證、USB-key(數字證書認證及串號驗證)認證等多種身份認證方式。
對已登錄用戶經行全局會話控制,認證會話超時或注銷時實現門戶及其他應用統一注銷并為單點登錄功能開發相應的認證接口。
隨著數據整合的深入,在建立數據中心的同時,對信息來源數據實現抓取操作,將抓取后的數據作為身份認證的依據,以用戶身份用戶名舉例,用戶在數據整合之前記憶多個用戶名,在增加業務系統的同時增加用戶身份的負擔。因此,建設認證服務實現統一用戶管理勢在必行,隨后權限管理和身份認證提升到日程。
2.約束與安全
(1)需求約束
①系統中跟其他系統的接口,統一使用webservice模式。
②界面要使用公司統一的軟件操作界面。
③軟件質量:
正確性:以軟件需求為準,實現所有功能模塊。
高效性:在以秒計的時間中返回用戶操作響應,避免反應時間過長的情況。
可靠性:系統中顯示的數據必須是正確的,能夠給用戶提供決策依據的數據。
安全性:跟數據庫的交互只能通過軟件進行。系統中各個部分要包含身份驗證功能,不能通過頁面直接訪問。
可維護性:系統主要采取模塊方式開發,降低不同模塊間的耦合度。
可移植性:能夠在windows、linux、Solaris等多種服務器上進行部署。
(2)隱含約束
①系統中的各個模塊中的子功能也要相互獨立,如增刪改查都要作為單獨的功能分開,便于管理員的權限分配。
②盡量減少彈出窗口的使用
擴展策略:對于不同的學校,很多系統功能都有著不同的需求,所以對于系統的可擴展性應該體現在兩個方面:一是對于同一個學校的同一功能模塊,要采用原型的開發方式,即隨著用戶需求的不斷增加,修改不斷深入;二是對于不同學校的同一功能要分開來(劃分不同的包路徑)進行開發。
個性策略:根據學校提交的統一身份認證平臺用戶需求調研單及需求管理變更表,在通用的統一身份認證平臺系統的功能基礎上進行個性化調整變更,以期達到學校的實際使用需求。
(3)安全性
從整個軟件系統的角度考慮安全問題,加強系統接口、中間件調用秘鑰的長度、復雜度的級別。
應用服務器APACHETOMCAT版本低會出現漏洞,應盡可能升級版本修復補丁。
開發中使用Struts2框架,容易被攻擊,目前已升級到2.3.16.3版本。
文件上傳插件是攻擊漏洞的主要途徑之一,應對上傳文件格式有判斷攔截,目前上傳文件僅支持圖片、swf、Word、Excel等文件格式,可執行文件上傳時均被系統攔截處理。
綜上所述,該數據整合開發根據學院綜合辦公室、教務處、人事處、學生工作處的需求進行開發,但針對目前學院信息化建設的發展規劃來說,未來的數字化校園系統要求所有系統數據進一步消除信息孤島,實現各應用系統間的數據互通,達到數據信息的單一來源,對于本次數據整合如圖書管理系統尚未整合進來。
對多系統共性數據開發的新增系統仍存在難度,如目前準備研發的請銷假系統就是挑戰,該系統需要教務系統的學號、學生姓名,一卡通系統的硬件卡號、學工系統中的輔導員信息、人事系統的組織架構和系部書記信息、道閘門禁系統等六個系統間的數據訪問互補。建立數據中心后,相信能夠將數據來源采集和數據推送做到完整,通過Web瀏覽器實現請銷假的審批流程,利用道閘門禁系統實現開關門的功能模塊,但在為進行數據整合之前,此系統勢必又成為信息孤島,給學生工作部的工作人員帶來數據維護的壓力,大大降低了數據冗余。
[1]王 巖.數字化校園建設中異構數據庫集成技術的研究與應用[J].電腦知識與技術,2010
[2]王 慧,卞藝杰.淺談數字化校園中數據中心的建設[J].大眾科技,2010
[3]劉福濤.基于Web的教務管理信息系統的設計與實現[D].大連海事大學,2012
[4]王明潔.基于SOA的復旦迎新系統的設計與實現[D].復旦大學,2012
[5]王曉東.數字化校園統一數據交換與共享平臺研究[J].價值工程,2011
[6]吳振宇.基于Web的物聯網應用體系架構和關鍵技術研究[D].北京郵電大學,2013
ISSN2095-6711/Z01-2015-08-0203