基于EMIF的互操作信息平臺的設計

王義卿

0 引言

在信息化高速發展的今日，教育信息化也開始普及并發展，我國各高校已經開始采用計算機和網絡輔助教育管理工作，并建立全校各方面的管理信息系統。特別是網絡的發展，使得各類信息管理系統不再是單一集中地存在，學校內部各部門都有自己的管理系統，再通過網絡，有機組合成整個學校的管理系統。但是，由于這類校園管理系統剛起步，各方面都不成熟，特別是缺乏有關專業方面的標準和規范，造成已建成的各個子管理系統或學校與學校間的管理系統之間兼容性較差或難以兼容，因此也難以實現相互之間信息和資源的交流和共享。為此，國家教委制定出臺了《教育管理信息化標準》，該標準旨在推動教育信息化工作向規范化和健康化方向發展，最主要的是提出了教育管理信息系統之間互操作體系結構、數據和接口這3個規范。本文就在充分了解并學習教育管理信息系統之間互操作體系結構、數據和接口這3個規范的基礎上，結合當前的其它管理信息系統之間數據共享和互操作的研究現狀，設計了一個基于EMIF的互操作信息平臺。

1 系統主要技術的概括及應用

1.1 EMIF

EMIF規范是中國E-Learning技術規范，CELTS（Chinese E-Learning Technology Standards）中《教育管理信息系統互操作規范（CELTS_40）》的簡稱[1]。

SIF（School Interoperability Frame-work學校互操作框架）是針對美國中小學的教育管理，并且 SIF 在數據對象的定義方面有著濃郁的美國文化特征。我國教育部通過對SIF規范的深入研究，并且在一定程度上參考借鑒SIF規范中的體系結構和報文結構，結合了我國的文化特色和實際情況，使用《教育管理信息化標準》的第一部分（學校管理信息標準）作為EMIF的數據規范部分，制定了我國教育管理信息系統互操作框架，也即EMIF。

EMIF規范主要由3個部分組成：

(1)EMIF數據規范：是對基于EMIS的教育信息管理系統導出的數據模式進行規定，是EMIF報文規范的基礎；

(2)EMIF報文規范：建立在EMIF數據規范之上，通過報文將數據包裝起來；

(3)EMIF的體系結構：描述了構成整個互操作框架的各類組件，以及各組件自身所具備的功能和互操作的實現模式。

EMIF是一個學校管理系統互操作的解決方案，它的體系結構主要是由若干個代理程序和一個稱為 ZIS（Zone Integration Server，區域集成服務器）的中間層服務器構成，如圖1所示：

圖1 EMIF體系結構簡單示意圖

1.2 分布式異構環境

校園中的各類子系統由于對于管理數據都有自身的理解和側重，造成各個子系統數據種類、分類、范圍以及數據與數據間的關系等等各不相同。這些資源異構大致分為分類異構、描述范圍異構、描述粒度異構、關系異構、屬性類型異構、類與屬性異構以及術語描述異構等7大類，而各子系統之間的資源異構又往往并不是上述 7類異構其中單一的一種，而是多種異構交織在一起，形成一個分布式異構環境，非常復雜[2,8]。

要設計一個全校范圍內的基于EMIF的信息平臺，就必須解決分布式異構環境下異構數據的集成問題。本系統采用的是客戶端(各子系統)通過代理將數據統一封裝成XML格式，在服務器端(平臺)創建元數據庫存儲，提供元數據以及利用EMIF規范，定義元數據并通過各子系統的數據與元數據進行匹配，驗證的方法來獲得統一的數據。

1.3 XML應用

本系統所設計的報文格式采用XML語言，具有如下幾點原因：

（1）對于本系統的主要功能：整合不同的子系統，使其成為一個有機的整體。首先要解決不同子系統之間的數據異構問題，而XML本身具有DTD的標準文檔定義，這為本系統解決數據異構，提供了有效途徑，通過XML可以提供數據顯示的一致性。

（2）對于本系統的主要工作內容：報文的封裝、傳輸、存儲和處理。XML本身是一種標記語言，可非常方便地進行各種信息的標識并根據現有文檔中元素的XML標記創建新的文檔，極大地方便了本系統的工作流程設計。

（3）對于本系統的通用性和兼容性：面向校園內不同的子系統，提供各子系統之間數據共享的平臺。XML支持所有內核為IE(Internet Explorer)以及Netscape的瀏覽器，使得應用其編寫的報文能在校園內的極大多數子系統上正確顯示。

1.4 基于集群的Web服務器

集群是指一組相互連接的計算機，緊密地工作在一起，以至于在很多方面看來，它們都像是一臺機器[3,4]。使用集群技術，由局域網內通過高速網絡聯接的一組通用Web服務器（這些Web服務器可以是同構的，也可以是異構的）構成Web服務器集群系統。這個系統對外相當于一臺高性能的Web服務器。一般由一臺特殊的服務器（請求分配服務器）接受請求，并按照某種策略動態地分配到各個 Web服務器上處理。

本系統的ZIS部分將采用基于集群的Web服務器，這樣做的好處是，可以通過設計一個有效的服務器負載算法，突破服務器的瓶頸效應，提高系統整體的工作效率。

2 平臺的設計

2.1 平臺的結構模型

本文重點研究信息平臺上的消息機制，并在其基礎上，給出一種基于分布式異構環境下的管理信息互操作平臺的方案。其整個系統的模型，如圖2所示：

圖2 消息服務集成平臺系統模型

2.2 平臺的主要功能模塊設計

如圖2所示，整個平臺主要由報文處理層、消息中間件以及報文處理層3個部分組成，另外還設計了一個元數據庫專門存儲用于驗證各子系統的數據是否符合標準的元數據以及一個CA(Certificate Authority)中心提供證書的發放和認證。

報文處理層設計有MyHttp服務器、報文預處理模塊以及相應的報文安全服務模塊。

MyHttp服務器是在HTTP協議的基礎上進行的一定擴充而成的，主要的功能是提供持久穩定的鏈接和主動服務機制。它的主動服務機制體現在當客戶端代理申明是“推”模式時，MyHttp服務器一方面主動連接客戶端，將ZIS返回的報文或者事件報文發送給客戶端代理程序；同時還進行它基本的工作，即將從客戶端代理程序接收到的報文發送給預處理模塊。從它的工作內容來看，MyHTTP在其中既扮演了服務器的角色又扮演了客戶端的角色。

報文預處理模塊是報文進入報文隊列的一個通道和關卡，其主要功能是保證進入JMS Server的報文的有效性。因此，它具備以下4個功能：

（1）報文的有效性驗證：報文預處理模塊接收到MyHttp服務器發送來的請求（報文）后，調用元數據庫中的各種報文的DTD文檔來驗證報文的有效性，并將有效的報文進行解析；

（2）報文的解析：報文預處理模塊只對報文進行初步解析，其目的主要是驗證報文的發送方和判斷報文的類型，并將此作為身份驗證的依據；

（3）報文的權限驗證：根據解析出來的數據，調用系統數據庫的身份權限設定，判斷報文發送方是否有權限對數據進行報文中所要求的操作；

（4）報文的優先級設置：報文預處理模塊的最后，還要根據解析出的報文類型進行優先級的設置，并將這些重新生成的報文發送到JMS Server的入口隊列中。

報文安全服務模塊的安全機制，通過對比目前主流的幾種加密技術如對稱加密和非對稱加密、消息摘要以及交換密鑰等加密技術，選中了SSL(Secure Socket Layer)數據安全協議作為本系統的加密技術，SSL揉合了對稱加密、非對稱加密和交換密鑰的加密算法，通過 SSL握手協議保證報文傳輸的安全。但是其對于保證非否認性方面還有所欠缺，為此，本系統還設計了一個CA中心，通過CA中心，可以進行數字證書簽名以及構建客戶端認證和服務器側認證的雙向認證體系，補充了SSL對于保證非否認性方面的不足。

消息中間件的主要作用是提供消息隊列的存儲和管理服務[5]，本系統的消息中間件的設計通過比較分布式環境下3種主要數據交換技術的優缺點，選擇了基于MOM(MOM-Message On Middleware，消息中間件)的數據交換技術，作為解決報文隊列管理的方法，并且為了降低開發難度，采用第三方提供的 JMS消息中間件，構建了 JMS Server，并使用iLinkMQ對其進行實現。

報文處理層主要的作用是對報文進行相應的處理和轉發，其中報文的轉發由消息路由器完成，報文的處理由報文處理模塊完成。

消息路由器一方面需要通過解析器進行解析，取得XML報文中的報文類型、對應的元素名、元素值、屬性名和屬性值這些數據，然后根據該報文的類型將其路由到相應的處理組件進行處理；另一方面還需要處理由處理組件完成返回的結果，并將其發送到JMS Server中對應的代理隊列。本系統設計采用Apache Xerces解析器對報文進行解析，采用IBM的XML4J對報文進行EMIF_Ack報文的XML格式封裝。

報文處理模塊設計了注冊模塊、預約模塊、提供模塊、請求模塊以及事件報文處理模塊5個子模塊，其中注冊模塊包含注冊和取消注冊兩個子功能，這兩個子功能分別通過EMIF_Register報文和EMIF_Unregister報文來完成。預約模塊：包含預約和取消預約兩個子功能，這兩個子功能分別通過EMIF_Subscribe報文和EMIF_Unsubscribe報文來完成。提供模塊：包含提供數據和取消提供數據兩個子功能，這兩個子功能分別通過 EMIF_Provide報文和EMIF_Unprovide報文來完成。請求模塊：包含請求和應答請求兩個子功能，這兩個子功能分別通過 EMIF_Request報文和EMIF_Response報文來完成。事件報告處理模塊：通過EMIF_Event報文完成。

整個平臺的設計均采用模塊化的設計思想，各功能模塊之間松散耦合，具有較好的系統開放性。

3 實驗過程及結果分析

本文重點是建設基于EMIF的消息平臺，EMIF規范通過 3類報文來實現數據的共享和互操作：EMIF_Event、EMIF_Request和EMIF_Response。實驗的目的就是要實現上述兩種傳遞模式，包括報文的“推”和“拉”傳輸模式的測試。

3.1 實驗環境

首先進行客戶端代理的設置，如表1所示：

表1 客戶端代理列表

本實驗中共設置了3個代理，一個采用“拉”模式通信，另兩個采用“推”模式通信，這3個客戶端代理和ZIS的通信協議均是HTTPS，狀態均是激活狀態。并且默認這3個客戶端代理已通過ZIS的驗證。

數據對象提供者設置，如表2所示：

表2 數據提供者列表

上面一共有4個數據對象：課程基本信息、學生基本信息、學生注冊信息和收文處理基本情況，分別由上述3個客戶端代理提供。本實驗以“學生基本信息”這個數據對象為例進行，如圖3所示：

圖3 應用系統與ZIS數據交換信息流示意圖

數據對象預約者設置，如表3所示：

表3 預約者數據列表

在表3中，客戶端代理WSJSCLS預約了數據對象：學生基本信息和學生注冊信息，在本次試驗中將以學生基本信息為例進行測試。這里默認客戶端代理加入區域時已由提供的注冊報文和預約及提供者報文來交付的運行前信息，并且客戶端在注冊后，已通過ZIS系統管理員的身份認證，能相互之間交換信息。

3.2 實驗過程和分析

3.2.1 實驗一：請求與應答模式

代理A向ZIS發出一個獲取滿足條件的學生基本信息的請求，ZIS將請求轉發給代理B，代理B解析請求，將結果用XML封裝后發送到ZIS，ZIS再將結果反饋給代理A。

3.2.2 實驗二：發布與預約模式

代理B如果對數據對象學生基本信息進行操作：添加、修改或者刪除，若作為數據提供者，則必須發出一個事件報文給ZIS，ZIS收到這一事件報文，將這一事件報文復制發送到對這一數據對象進行預約過的客戶端代理，在本測試報告中應該是代理A。

3.3.3 實驗過程分析

該工作流程圖為圖3，工作流程為：

(1)課程管理系統通過Agent A向ZIS發送請求數據（已經過報文預處理封裝成通用的XML格式）；

(2)ZIS向Agent B轉發數據（已經過報文預處理封裝成Agent B的格式）；

(3)學生管理系統通過Agent B接收到該請求，并根據條件返回相應的數據；

(4)ZIS向Agent A返回數據；

(5)課程管理系統接收數據。

4 結束語

本文“分布式異構環境下基于 EMIF的互操作信息平臺設計”初步探討了EMIF兩種結構體系中的單區域結構以及該結構下的系統之間互操作問題，首先，是初步設計了一個基于EMIF單區域結構的互操作消息平臺，然后對其中的主要組成部分：報文傳輸層、消息中間件以及報文處理層進行了進一步的研究和設計。

Agent 都具有自主性，在求解過程中都按照自己的目的、知識進行，因此由Agent參加的交互活動常會出現①彼此雙方在服務描述與需求描述無法互相理解②無法量化需求目標與候選者間的符合程度。矛盾的突顯使得自動協商成了Multi-Agent System研究中亟待解決的重要問題。解決的基本思路是基于語義Web實現多Agent間的智能交互，本體（Ontology）作為語義 Web的基礎是某領域知識概念化和模型化的方法，利用本體描述多Agent自動協商模型中代表各方利益的Agent的語義信息，變無序數據為有序知識，從而豐富Agent服務發現、匹配和組合，提高自動化程度[6,7]。這在下一步研究工作中，將作為重點研究的方向。

[1]教育管理信息系統互操作規范——教育管理互操作框架EMIF[S]，CELTS-40 WD1.0，教育部教育信息化技術標準委員會 發布，2002,(8).

[2]殷萇茗 何桂華 龔紅仿.分布式異構數據庫系統的設計與實現.[J]長沙電力學院學報.2001,(8).

[3]羅清 羅宇.網絡應用系統服務器集群技術研究 .[J]計算機工程與科學.2004,(7).

[4]姚自明 趙岳松 柳異青.WWW 服務器集群技術 .[J]計算機工程.2000,(7).

[5]高建斌 董傳良 謝莉 夏恩詢.數據集成中消息中間件的設計.[J]計算機工程.2003,(10).

[6]王祥瑞,李力東.語義網的產生與發展.[J]吉林建筑工程學院學報,2007,(03).

[7]李潔,丁穎.語義網、語義網格和語義網絡.[J]計算機與現代化,2007,(07).

[8]Clustering works its way down[C].Alan Radding,23 Jun 2005 | SearchWinSystems.c