基于Multi-Agent 的高校校園一卡通系統(tǒng)集成研究
文章出處：http://www.hungpor.com 作者：姚敏，郭慶 人氣： 發(fā)表時間：2011年11月15日
0 引言
隨著信息技術的高速發(fā)展，目前高校的信息化程度也在逐漸提升。為了提升核心競爭力，高校掀起了一場“數(shù)字化校園系統(tǒng)建設”（Digital Campus）的熱潮。
在數(shù)字化校園建設中，“校園一卡通”作為基礎工程，為數(shù)字化校園提供了全面的數(shù)據(jù)采集平臺。目前高校校園一卡通中存在多個不同時期的各種信息系統(tǒng)，存在著異構數(shù)據(jù)庫，需要整合二級管理部門的“信息孤島”[1]，解決異構的集成問題。本文主要研究各個應用支撐系統(tǒng)的數(shù)據(jù)庫異構問題，并引入Mutil-Agent 技術，提出一種基于Mutil-Agent 的高校校園一卡通集成方案。
1 Mutil-Agent 技術
Mutil-Agent（MA）技術主要是研究多個Agent 之間如何相互協(xié)作、相互支持以完成系統(tǒng)共同目標的問題，其成果可應用于物理分布或邏輯上具有分布性特點的應用領域。多智能Agent 系統(tǒng)（Mutil-Agent System,MAS）是指由多個可執(zhí)行網(wǎng)絡計算Agent 組成的集合。MAS 的協(xié)作求解問題的能力超過單個Agent,這是MAS 產生的最直接的原因。它能夠模擬人類社會團體、大型組織機構的群體工作，可用它解決復雜問題[2]。
對MAS的研究主要涉及以下六個方面的內容：
⑴ 功能控制范圍。單個Agent 的功能控制范圍可以是全局，也可以是局部。
⑵ 集成系統(tǒng)的操作手段。系統(tǒng)可以通過局部功能、局部接口、應用或問題參數(shù)訪問單個Agent。
⑶ 系統(tǒng)控制位置。包括中心或分布的。
⑷ 系統(tǒng)集成機制。包括功能、語言、表示方法、應用或問題。
⑸ Agent 組成。包括同構、異構的。
⑹ 系統(tǒng)Agent 類型。包括人、機器、人和機器的混合。MAS 的研究歷史最早可以追溯到80 年代中期的Actors 模型，隨后Davis 和Smith 提出了合同網(wǎng)協(xié)議。合同網(wǎng)協(xié)議至今仍被認為是關于通信、MAS 研究的重要成果，主要內容包括：MAS 理論、Multi-Agent 協(xié)商和Multi-Agent 規(guī)劃等。其他比較熱門的研究是，MAS 在Internet 上的應用、移動Agent 系統(tǒng)、電子商務、基于經濟學或市場學的MAS等。
2 高校一卡通系統(tǒng)結構及存在問題
2.1 高校一卡通系統(tǒng)結構
校園一卡通是一個全新的理念，作為學校數(shù)字化校園的基礎建設，在提升學校信息化建設和核心競爭力中起著舉足輕重的作用。按照業(yè)務功能的需要，校園一卡通平臺系統(tǒng)一般由支付交易系統(tǒng)、身份識別系統(tǒng)、應用系統(tǒng)接口、綜合應用系統(tǒng)四大功能系統(tǒng)組成。其結構圖如圖1所示。
系統(tǒng)的核心是數(shù)據(jù)資源的集成共享，統(tǒng)一的數(shù)據(jù)平臺的目標是為了整個信息系統(tǒng)提供一個穩(wěn)定、集成、可靠的環(huán)境，保證系統(tǒng)中各個業(yè)務系統(tǒng)可以充分集成并保持一致。利用共享數(shù)據(jù)庫平臺，可集成各個不同時期建立的業(yè)務子系統(tǒng)，實現(xiàn)整個校園管理的規(guī)范化、系統(tǒng)化、一體化。
2.2 存在問題
在高校校園一卡通系統(tǒng)中，學校很多部門在管理方面已經應用了一些專業(yè)生產廠家所開發(fā)的較為成熟的應用管理系統(tǒng)，如：控水控電系統(tǒng)、圖書借約系統(tǒng)、網(wǎng)上查詢系統(tǒng)、OA 系統(tǒng)等。他們采用的開發(fā)平臺各不相同。因此，目前各種類型的數(shù)據(jù)庫系統(tǒng)同時并存，有Foxpro、Access 等桌面型數(shù)據(jù)庫管理系統(tǒng)，也有SQL Server、Oracle、Sybase 之類的大中型數(shù)據(jù)庫系統(tǒng)。
同時，隨著Web 技術的發(fā)展，又出現(xiàn)了許多新的數(shù)據(jù)形式（如文本、音頻、圖像、動畫、視頻數(shù)據(jù)等），這些異構數(shù)據(jù)，制約了各部門間的信息傳輸和互用。
學校本部與分校及銀行在操作系統(tǒng)、數(shù)據(jù)庫和網(wǎng)絡上的異構性，高校內部各種形式的信息系統(tǒng)，所形成的一個個分散的“信息孤島”[1]，使得數(shù)據(jù)無法共享和及時更新，給單位的規(guī)范管理造成了一定困難。
為了解決數(shù)據(jù)異構問題，保護學校各部門的前期投資，促進學校與銀行的相互協(xié)作，實現(xiàn)學校、商戶同銀行之間的信息交換，建立一個分布異構環(huán)境下的異構數(shù)據(jù)庫集成系統(tǒng)是十分必要的。
3 基于Mutil-Agent 的一卡通集成系統(tǒng)
為了解決高校各種業(yè)務系統(tǒng)中數(shù)據(jù)庫和操作系統(tǒng)平臺的異構性、系統(tǒng)接口不統(tǒng)一、技術標準定義不一致、開發(fā)商不同等等問題，我們在一卡通系統(tǒng)中引入多Agent 技術，即引入ManagentAgent 和各個業(yè)務子系統(tǒng)Agent，如OA Agent、圖書借約Agent、控水控電Agent 和網(wǎng)上查詢Agent 等來解決校園一卡通中各子系統(tǒng)間互相通信與協(xié)作，以便達到異構數(shù)據(jù)庫的集成和透明共享，實現(xiàn)分布、異構的校園一卡通子系統(tǒng)間的信息共享、功能共享、互通信和互操作。圖2 為基于Mutil-AgentAgent 的校園一卡通集成系統(tǒng)模型。
Client Agent 由Web Client 組成，是用戶和系統(tǒng)交流的接口，它接收用戶的操作和請求并返回執(zhí)行結果，并為用戶提供服務，負責向Managent Agent 提交用戶信息和服務請求。用戶只需要提出相應的要求或者作出一系列選擇，Client Agent 就能將用戶請求轉換成Agent 能識別的命令。
Managent Agent 是整個模型的核心，它接收Client Agent的請求任務，轉換請求格式，并分解成相應的子業(yè)務，發(fā)送給各個子業(yè)務Agent，如OA Agent、Lib Agent、Inquiry Agent 等。接收各子業(yè)務Agent 發(fā)來的處理結果，并對其進行整合后返回給Client Agent。
元數(shù)據(jù)字典：包括各局部數(shù)據(jù)庫的模式信息、集成系統(tǒng)的全局視圖信息以及異構模式的轉換規(guī)則等。這些元數(shù)據(jù)主要用于記錄整個數(shù)據(jù)庫系統(tǒng)的全局資源、局部資源和關系資源，是數(shù)據(jù)庫中數(shù)據(jù)的描述。元數(shù)據(jù)在需求分析階段定義，需要在設計過程中不斷修改、實施、完善。元數(shù)據(jù)字典位于管理Agent所在的同一機器上，這樣對于全局數(shù)據(jù)庫的訪問只需訪問本機的數(shù)據(jù)庫。對于局部數(shù)據(jù)的訪問，相應的信息通過JDBC 從全局數(shù)據(jù)字典提取，再由Managent Agent 執(zhí)行。
各子業(yè)務Agent:對應于各子系統(tǒng)的數(shù)據(jù)庫服務器。它接收和解釋來自Managent Agent 的請求，檢驗其合法性以及權限；將服務通過標準接口JDBC 傳送給數(shù)據(jù)源執(zhí)行；取得查詢結果后，將其組織成規(guī)范的XML 格式文件傳送給ManagentAgent。
4 基于Mutil-Agent 的集成通信機制設計
校園一卡通集成系統(tǒng)模型中一個業(yè)務的執(zhí)行往往需要多個功能Agent 的交互協(xié)作。因而實現(xiàn)Agent 之間通信和協(xié)作，是保障校園一卡通系統(tǒng)高效、穩(wěn)定運行的關鍵。完成協(xié)作，就需要通信。為了讓每個Agent 都能理解通信的內容并作出相應的反應，就需要為它們定義共同的通信機制。本文選擇KQML(Knowledge Query and Manipuliation Language)[3]作為開發(fā)語言，它提供了一套標準的Agent 通信原語，定義了一組Agent 之間傳遞信息的標準語法和動作，而且KQML 通信語言支持多種類型的消息通信，能夠完成控制系統(tǒng)中的一般信息交換、功能交互與知識共享。KQML 分為三個層次：內容層、消息層和通訊層[4]，如圖3 所示。
層間交互通過Inform,Request,Offer,Accept,Refuse,Command等類型的消息來實現(xiàn)。KQML 是一種較為成熟的Agent 通訊語言和通訊協(xié)議，但由于專業(yè)領域的封閉性和相應軟件的不足，還遠遠不能滿足當今Internet 發(fā)展的需求。XML 是一種可擴展語言，是一種跨平臺的數(shù)據(jù)交換規(guī)范，已經成為被廣泛接受的數(shù)據(jù)編碼和數(shù)據(jù)處理標準。它最重要的特征是，被標記的各個數(shù)據(jù)是保持其含義的，因此極大地提高了系統(tǒng)間交換數(shù)據(jù)的可能性。鑒于XML語言的可擴展性、平臺獨立性、靈活性、自描述性和簡明性[5]，本文采用XML對KQML進行封裝。
用XML來封裝KQML語言的統(tǒng)一格式如下：
<?xml version=”1.0”ecoding=”UTF-8”?>
<message>
<ID>消息的編號</ID>
<sender>消息發(fā)送方</sender>
<receiver>消息接收方</receiver>
<type>消息類型</type>
<content>消息的內容</content>
</message>
Agent 采用KQML 通信的時候，其消息可劃分為兩個層面，通信原語和通信內容層。這兩個層面是相對獨立的。如果采用KQML 來進行Agent 通信，可用XML 來封裝KQML 通信原語消息，同時也可用XML 來表示通信內容。我們將給出一個KQML 的DTD 設計，通信內容則由用戶負責設計其DTD。這種做法的優(yōu)點是[6-7]：
⑴ 可增強不同種類的Agent 之間的通信能力；
⑵ 可降低通信的復雜度，使某些棘手的通信得以進行；
⑶ 不依賴于特定網(wǎng)絡通信協(xié)議；
⑷ 有利于Agent 技術融入萬維網(wǎng)環(huán)境；
⑸ 有利于Agent 尋址、安全性以及標準詞匯集的定義和共享；
⑹ 有利于Agent 協(xié)調和合作；
⑺ 有利于增強Multi-agent 系統(tǒng)的靈活性和可擴充性。
圖4為基于XML的Agent 通信框架：
XML Wrapper
KQML
request
Ontology
A
Ontology
B
KB
XML Wrapper
KQML
result
Ontology
A
Ontology
B
KB
Background
Knowledge
Base
該框架的通信流程為：
設Agent A 就某問題向Agent B 詢問。Agent A 根據(jù)自己的知識庫經過計算或推理，利用合適的標準詞匯集生成相應的請求，將它嵌入KQML 的內容層，使用XML 包裝器生成XML文檔，最后通過通信服務向B 傳送。Agent B 收到該文檔后，使用XML 解析器從中分離出KQML 消息，利用自己的知識庫進行計算、推理和詮釋，并選用相應的標準詞匯集生成反饋信息；接著，將其轉換成XML 文檔；最后也通過通信服務向A 傳回XML文檔。
下面給出KQML消息的DTD定義。
<!—filename:performative.dtd-->
<!ENTITY%commadntype“ask-if|ask-all|ask-one|re-ask|streamall|
eos|tell|untell|deny|suggest|insert|uminsert|delete-one|
delete-all|undelete|achieve|unachieved|advertise|unadvertised|
subscribe|error|sorry|standby|ready|next|rest|discard|register|
unregister|forward|broadcast|transport-address|broker-one|
broker-all|recommend-one|recruit-one|recruit-all”>
<!ELEMENT performative(name,sender*，receiver*，in-reply-to？，
reply-with，language，ontology，from？，to？，content)>
<!ELEMENT name(% commandtype)>
<!ELEMENT sender (Agent-id)>
<!ELEMENT receiver (Agent-id)>
<!ELEMENT in-reply-to (#PCDATA)>
<!ELEMENT reply-with (#PCDATA)>
<!ELEMENT content (#PCDATA)>
<!ELEMENT language (#PCDATA)>
<!ELEMENT ontology (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT Agent-id(name,address?)>
<!ELEMENT name(#PCDATA)>
<!ATLIST name id ID #IMPLIED)
<!ELEMENT address EMPTY>
這里給出一個數(shù)據(jù)庫查詢的實例。假設用戶執(zhí)行的語句如下所示：
SQLConnect(dsn，dsn_len，uid，uid-len，pwd，pwd_len)解析：
假設定義的數(shù)據(jù)庫連接語句原型為SQLConnect(DSN，UID，Len(UID)，PWD，Len(PWD))，其中DSN 是數(shù)據(jù)源名，UID為用戶的ID，PWD 為用戶密碼，其余加Len()的表明為字符串的長度。
文檔（Client Agent 向Managenent Agent 發(fā)送的文檔）
<!—ask-if.xml-->
<?xml version=“1.0” encoding=“UTF-8”standalone=“no”?>
<!DOCTYPE performative SYSTEM“performative.dtd”>
<!ELEMENT content sqlconnect>
<!ELEMENT sqlconnect(dsn，dsn-len，uid，uid_len，pwd，pwd-len)>
<!ElEMENT dsn (#PCDATA)>
<!ATTLIST dsn_len (#PCDATA)>
<!ATTLIST dsn_len inquire(yes|no)no>
<!ElEMENT uid (#PCDATA)>
<!ATTLIST uid inquire(yes|no)yes>
<!ElEMENT uid_len (#PCDATA)>
<!ATTLIST uid_len inquire(yes|no)no>
<!ELEMENT pwd (#PCDATA)>
<!ATTLIST pwd inquire(yes|no)yes>
<!ELEMENT pwd (#PCDATA)>
<!ATTLIST pwd inquire(yes|no)yes>
<performative>
<name> ask-if </name>
<sender>
<Agent -id>
<name>Client Agent</name>
</Agent -id>
<content>
<dsn>dsn</dsn>
<dsn_len>dns_len</dsn_len>
<uid>uid</uid>
<uid_len>uid_len</uid_len>
<pwd>pwd</pwd>
<pwd_len>pwd_len</pwd_len>
</content>
</sender>
<receiver>
<Agent-id>
<name> Menagement Agent</name>
</Agent-id>
</receiver>
<in-reply-to/>
<reply-with>No.1</reply-with>
<content/>
<language>XML</language>
<ontology>Travel</ontology>
</performative>
5 結束語
將Mutil-Agent 用于高校校園一卡通系統(tǒng)，較好地解決了異構數(shù)據(jù)庫系統(tǒng)之間的通信與協(xié)作問題，使系統(tǒng)更具有智能性和自學習功能。XML 具有的平臺獨立性、很好的擴展性和自描述性，能夠實現(xiàn)異構數(shù)據(jù)庫數(shù)據(jù)的透明互訪和共享。所以通過XML 封裝KQML 消息，能夠有效地解決異構數(shù)據(jù)庫系統(tǒng)的通信和協(xié)作問題。
