基于Multi-Agent 的高校校園一卡通系統集成研究

文章出處：http://5052h112.com 作者：姚敏，郭慶   人氣： 發表時間：2011年11月15日

    0 引言

    隨著信息技術的高速發展，目前高校的信息化程度也在逐漸提升。為了提升核心競爭力，高校掀起了一場“數字化校園系統建設”（Digital Campus）的熱潮。

    在數字化校園建設中，“校園一卡通”作為基礎工程，為數字化校園提供了全面的數據采集平臺。目前高校校園一卡通中存在多個不同時期的各種信息系統，存在著異構數據庫，需要整合二級管理部門的“信息孤島”[1]，解決異構的集成問題。本文主要研究各個應用支撐系統的數據庫異構問題，并引入Mutil-Agent 技術，提出一種基于Mutil-Agent 的高校校園一卡通集成方案。

    1 Mutil-Agent 技術

    Mutil-Agent（MA）技術主要是研究多個Agent 之間如何相互協作、相互支持以完成系統共同目標的問題，其成果可應用于物理分布或邏輯上具有分布性特點的應用領域。多智能Agent 系統（Mutil-Agent System,MAS）是指由多個可執行網絡計算Agent 組成的集合。MAS 的協作求解問題的能力超過單個Agent,這是MAS 產生的最直接的原因。它能夠模擬人類社會團體、大型組織機構的群體工作，可用它解決復雜問題[2]。

    對MAS的研究主要涉及以下六個方面的內容：

    ⑴ 功能控制范圍。單個Agent 的功能控制范圍可以是全局，也可以是局部。
    ⑵ 集成系統的操作手段。系統可以通過局部功能、局部接口、應用或問題參數訪問單個Agent。
    ⑶ 系統控制位置。包括中心或分布的。
    ⑷ 系統集成機制。包括功能、語言、表示方法、應用或問題。
    ⑸ Agent 組成。包括同構、異構的。
    ⑹ 系統Agent 類型。包括人、機器、人和機器的混合。MAS 的研究歷史最早可以追溯到80 年代中期的Actors 模型，隨后Davis 和Smith 提出了合同網協議。合同網協議至今仍被認為是關于通信、MAS 研究的重要成果，主要內容包括：MAS 理論、Multi-Agent 協商和Multi-Agent 規劃等。其他比較熱門的研究是，MAS 在Internet 上的應用、移動Agent 系統、電子商務、基于經濟學或市場學的MAS等。

    2 高校一卡通系統結構及存在問題

    2.1 高校一卡通系統結構

    校園一卡通是一個全新的理念，作為學校數字化校園的基礎建設，在提升學校信息化建設和核心競爭力中起著舉足輕重的作用。按照業務功能的需要，校園一卡通平臺系統一般由支付交易系統、身份識別系統、應用系統接口、綜合應用系統四大功能系統組成。其結構圖如圖1所示。

    系統的核心是數據資源的集成共享，統一的數據平臺的目標是為了整個信息系統提供一個穩定、集成、可靠的環境，保證系統中各個業務系統可以充分集成并保持一致。利用共享數據庫平臺，可集成各個不同時期建立的業務子系統，實現整個校園管理的規范化、系統化、一體化。

    2.2 存在問題

    在高校校園一卡通系統中，學校很多部門在管理方面已經應用了一些專業生產廠家所開發的較為成熟的應用管理系統，如：控水控電系統、圖書借約系統、網上查詢系統、OA 系統等。他們采用的開發平臺各不相同。因此，目前各種類型的數據庫系統同時并存，有Foxpro、Access 等桌面型數據庫管理系統，也有SQL Server、Oracle、Sybase 之類的大中型數據庫系統。 

    同時，隨著Web 技術的發展，又出現了許多新的數據形式（如文本、音頻、圖像、動畫、視頻數據等），這些異構數據，制約了各部門間的信息傳輸和互用。

    學校本部與分校及銀行在操作系統、數據庫和網絡上的異構性，高校內部各種形式的信息系統，所形成的一個個分散的“信息孤島”[1]，使得數據無法共享和及時更新，給單位的規范管理造成了一定困難。

    為了解決數據異構問題，保護學校各部門的前期投資，促進學校與銀行的相互協作，實現學校、商戶同銀行之間的信息交換，建立一個分布異構環境下的異構數據庫集成系統是十分必要的。
    3 基于Mutil-Agent 的一卡通集成系統

    為了解決高校各種業務系統中數據庫和操作系統平臺的異構性、系統接口不統一、技術標準定義不一致、開發商不同等等問題，我們在一卡通系統中引入多Agent 技術，即引入ManagentAgent 和各個業務子系統Agent，如OA Agent、圖書借約Agent、控水控電Agent 和網上查詢Agent 等來解決校園一卡通中各子系統間互相通信與協作，以便達到異構數據庫的集成和透明共享，實現分布、異構的校園一卡通子系統間的信息共享、功能共享、互通信和互操作。圖2 為基于Mutil-AgentAgent 的校園一卡通集成系統模型。 

    Client Agent 由Web Client 組成，是用戶和系統交流的接口，它接收用戶的操作和請求并返回執行結果，并為用戶提供服務，負責向Managent Agent 提交用戶信息和服務請求。用戶只需要提出相應的要求或者作出一系列選擇，Client Agent 就能將用戶請求轉換成Agent 能識別的命令。 

    Managent Agent 是整個模型的核心，它接收Client Agent的請求任務，轉換請求格式，并分解成相應的子業務，發送給各個子業務Agent，如OA Agent、Lib Agent、Inquiry Agent 等。接收各子業務Agent 發來的處理結果，并對其進行整合后返回給Client Agent。

    元數據字典：包括各局部數據庫的模式信息、集成系統的全局視圖信息以及異構模式的轉換規則等。這些元數據主要用于記錄整個數據庫系統的全局資源、局部資源和關系資源，是數據庫中數據的描述。元數據在需求分析階段定義，需要在設計過程中不斷修改、實施、完善。元數據字典位于管理Agent所在的同一機器上，這樣對于全局數據庫的訪問只需訪問本機的數據庫。對于局部數據的訪問，相應的信息通過JDBC 從全局數據字典提取，再由Managent Agent 執行。

    各子業務Agent:對應于各子系統的數據庫服務器。它接收和解釋來自Managent Agent 的請求，檢驗其合法性以及權限；將服務通過標準接口JDBC 傳送給數據源執行；取得查詢結果后，將其組織成規范的XML 格式文件傳送給ManagentAgent。

    4 基于Mutil-Agent 的集成通信機制設計

    校園一卡通集成系統模型中一個業務的執行往往需要多個功能Agent 的交互協作。因而實現Agent 之間通信和協作，是保障校園一卡通系統高效、穩定運行的關鍵。完成協作，就需要通信。為了讓每個Agent 都能理解通信的內容并作出相應的反應，就需要為它們定義共同的通信機制。本文選擇KQML(Knowledge Query and Manipuliation Language)[3]作為開發語言，它提供了一套標準的Agent 通信原語，定義了一組Agent 之間傳遞信息的標準語法和動作，而且KQML 通信語言支持多種類型的消息通信，能夠完成控制系統中的一般信息交換、功能交互與知識共享。KQML 分為三個層次：內容層、消息層和通訊層[4]，如圖3 所示。 

     層間交互通過Inform,Request,Offer,Accept,Refuse,Command等類型的消息來實現。KQML 是一種較為成熟的Agent 通訊語言和通訊協議，但由于專業領域的封閉性和相應軟件的不足，還遠遠不能滿足當今Internet 發展的需求。XML 是一種可擴展語言，是一種跨平臺的數據交換規范，已經成為被廣泛接受的數據編碼和數據處理標準。它最重要的特征是，被標記的各個數據是保持其含義的，因此極大地提高了系統間交換數據的可能性。鑒于XML語言的可擴展性、平臺獨立性、靈活性、自描述性和簡明性[5]，本文采用XML對KQML進行封裝。

    用XML來封裝KQML語言的統一格式如下：

    <?xml version=”1.0”ecoding=”UTF-8”?>
    <message>
    <ID>消息的編號</ID>
    <sender>消息發送方</sender>
    <receiver>消息接收方</receiver>
    <type>消息類型</type>
    <content>消息的內容</content>
    </message>

    Agent 采用KQML 通信的時候，其消息可劃分為兩個層面，通信原語和通信內容層。這兩個層面是相對獨立的。如果采用KQML 來進行Agent 通信，可用XML 來封裝KQML 通信原語消息，同時也可用XML 來表示通信內容。我們將給出一個KQML 的DTD 設計，通信內容則由用戶負責設計其DTD。這種做法的優點是[6-7]：

    ⑴ 可增強不同種類的Agent 之間的通信能力；
    ⑵ 可降低通信的復雜度，使某些棘手的通信得以進行；
    ⑶ 不依賴于特定網絡通信協議；
    ⑷ 有利于Agent 技術融入萬維網環境；
    ⑸ 有利于Agent 尋址、安全性以及標準詞匯集的定義和共享；
    ⑹ 有利于Agent 協調和合作；
    ⑺ 有利于增強Multi-agent 系統的靈活性和可擴充性。 

    圖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 根據自己的知識庫經過計算或推理，利用合適的標準詞匯集生成相應的請求，將它嵌入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>

    這里給出一個數據庫查詢的實例。假設用戶執行的語句如下所示：
    SQLConnect(dsn，dsn_len，uid，uid-len，pwd，pwd_len)解析：

    假設定義的數據庫連接語句原型為SQLConnect(DSN，UID，Len(UID)，PWD，Len(PWD))，其中DSN 是數據源名，UID為用戶的ID，PWD 為用戶密碼，其余加Len()的表明為字符串的長度。
    文檔（Client Agent 向Managenent Agent 發送的文檔）
    <!—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 用于高校校園一卡通系統，較好地解決了異構數據庫系統之間的通信與協作問題，使系統更具有智能性和自學習功能。XML 具有的平臺獨立性、很好的擴展性和自描述性，能夠實現異構數據庫數據的透明互訪和共享。所以通過XML 封裝KQML 消息，能夠有效地解決異構數據庫系統的通信和協作問題。