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

文章出处：http://www.ifyousmell.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 消息，能够有效地解决异构数据库系统的通信和协作问题。