教育管理信息系統(tǒng)互操作通信模型設計與實現(xiàn)(編輯修改稿)
2025-05-16 03:42 本頁面
【文章內(nèi)容簡介】 冊中心返回查詢結果，接著EISP將查詢到的該數(shù)據(jù)對象服務的所有提供者作為應答者，并將請求報文傳遞給它們。在整個區(qū)域中，每一類數(shù)據(jù)對象都可以有多個應答者，并且非提供者也可以成為應答者。數(shù)據(jù)對象的每一個應答者都有權等待和處理請求，并返回一個或一組應答報文，通過EISP轉(zhuǎn)發(fā)給原請求者。DEA在發(fā)送請求報文時也可以明確指定某DEA作為請求的應答者。這時請求方DEA應在它的請求報文中指定應答者。EISP在收到請求報文時會檢查請求報文中是否存在指定信息，如果存在，還要檢查指定的應答者是否具有應答權限。只有當上述條件滿足，ZISC才會將請求報文轉(zhuǎn)發(fā)給這個指定的應答者。下面舉例說明請求—應答機制的實現(xiàn)。假設已有學生管理系統(tǒng)、圖書館管理系統(tǒng)和教學管理系統(tǒng)等三個數(shù)據(jù)交換節(jié)點，現(xiàn)在圖書館管理系統(tǒng)和教學管理系統(tǒng)需要從學生管理系統(tǒng)中獲取學生數(shù)據(jù)，那么它們之間的報文傳遞關系如下所述（見圖2）：a、 注冊服務：各DEA通過EISP向發(fā)送注冊服務報文，注冊成為服務使用者。（已注冊則不必重復此過程）b、 提供：DEA3通過ZISC向服務注冊中心發(fā)送提供服務注冊報文（其中必須包含關于此服務的WSDL文檔描述或其URL地址），成為學生數(shù)據(jù)服務的提供者。（已成為提供者則不必重復此過程）c、請求：DEA1和DEA2分別向EISP發(fā)送請求報文，請求獲取學生數(shù)據(jù)。d、 轉(zhuǎn)發(fā)：EISP接收DEA1的請求報文1，通過查詢服務注冊中心，指定DEA3為應答者，并將請求報文1傳遞給它（同樣處理請求報文2）。e、 應答：DEA3處理請求報文1（包括了和學生管理系統(tǒng)的數(shù)據(jù)轉(zhuǎn)換過程），返回應答報文1給EISP（同樣處理請求報文2）。f、 轉(zhuǎn)發(fā)：EISP接收DEA3的應答報文1，將該報文轉(zhuǎn)發(fā)給DEA1（同樣處理應答報文2）g、 轉(zhuǎn)換：DEA1將接收到的基于SOAP標準格式的應答報文1轉(zhuǎn)換為本系統(tǒng)的內(nèi)部的數(shù)據(jù)格式（同樣處理應答報文2）請求報文1請求報文2應答報文1應答報文2EISP注冊服務圖書館管理系統(tǒng)教學管理系統(tǒng)服務注冊中心（UDDI）本地數(shù)據(jù)和制定的標準數(shù)據(jù)格式轉(zhuǎn)換DEA1DEA2同上DEA3 圖2請求—應答機制學生管理系統(tǒng)DEA3事件報文事件報文預約報文1預約報文2EISP搜索服務提供者服務注冊中心（UDDI）本地數(shù)據(jù)和制定的標準數(shù)據(jù)格式轉(zhuǎn)換DEA2DEA1同上圖3 發(fā)布—預約機制學生管理系統(tǒng)教學管理系統(tǒng)圖書館管理系統(tǒng)（2）發(fā)布—預約機制數(shù)據(jù)對象的更新事件包括數(shù)據(jù)的添加、修改和刪除。當應用系統(tǒng)更新了它的數(shù)據(jù)對象時，應通過事件報文將更新事件傳遞給EISP。數(shù)據(jù)對象的使用者（其它應用程序）如果希望及時獲取數(shù)據(jù)的更新情況，應向EISP預約數(shù)據(jù)對象的更新事件。預約通過向EISP發(fā)送預約報文實現(xiàn)。事件發(fā)布者將數(shù)據(jù)對象的更新事件傳遞給EISP后，EISP負責將它傳遞給所有預約該數(shù)據(jù)對象更新事件的預約者。EISP轉(zhuǎn)發(fā)事件報文時不會通知原事件發(fā)布者，因此事件發(fā)布者在完成事件發(fā)布后，就無需關心將有哪些應用程序接收更新事件，以及更新事件是否已傳遞給預約者。在整個體系中，每一類數(shù)據(jù)對象都可以有多個事件發(fā)布者，但誰可以取得事件發(fā)布權限則取決于EISP的訪問控制管理。下面舉例說明發(fā)布—預約機制的實現(xiàn)。假定已有學生管理系統(tǒng)、圖書館管理系統(tǒng)和教學管理系統(tǒng)三個數(shù)據(jù)交換節(jié)點，現(xiàn)在圖書館管理系統(tǒng)和教學管理系統(tǒng)需要與學生管理系統(tǒng)的數(shù)據(jù)更新同步，那么它們之間的報文傳遞關系如下所述（見圖3）：a、 預約：DEA1和DEA2分別發(fā)送預約報文給EISP，預約學生數(shù)據(jù)的更新事件。b、 發(fā)布：DEA3在更新學生數(shù)據(jù)后即向EISP發(fā)送事件報文，發(fā)布學生數(shù)據(jù)的更新事件。c、 轉(zhuǎn)發(fā)：EISP將DEA3的事件報文分別轉(zhuǎn)發(fā)給各預約者——DEA1和DEA2d、 轉(zhuǎn)換：各個DEA負責把網(wǎng)絡傳輸中標準的SOAP格式通信的報文轉(zhuǎn)換為各個本系統(tǒng)內(nèi)部的數(shù)據(jù)格式。3 通信模型的實現(xiàn)與測試針對前面設計的通信模型，筆者對其中的核心問題進行了編程實現(xiàn)，主要包括Web服務的發(fā)現(xiàn)與注冊模塊、基于SOAP[6]和WSDL[8]的通信模塊兩大部分。而后，分別對兩大模塊進行了實驗測試與分析。，而選擇的開發(fā)語言是Microsoft公司專為網(wǎng)絡開發(fā)定制的C語言。 基于UDDI的服務發(fā)現(xiàn)模塊實現(xiàn)作為一個完整的通信模型，首先需要對現(xiàn)有的Web服務進行發(fā)現(xiàn)與定位，找到對應的WSDL文檔，再由此解析WSDL文檔，從而構造相應的SOAP消息實現(xiàn)通信。因此，我們首先設計了服務發(fā)現(xiàn)模塊。本模塊的實現(xiàn)涉及到UDDI規(guī)范[9]。它通過向UDDI接
公司管理相關推薦
鄂ICP備17016276號-1