***

（**大学网络智能计算实验室）

1 前言

伴随着WEB服务技术的出现，不同应用系统之间的集成变为现实。遵循松耦合的结构模型以及公共服务调用规范，WEB服务技术使得异构系统之间的集成问题变得更容易。但是，如何实现WEB服务的自动发现，组合，调用等一系列问题急需进一步研究。软件Agent技术以其自身的优点，被广泛视为一种解决上述相关问题的良药。不幸的是，WEB服务技术与Agent技术都是各自遵循相应的规范和标准发展起来的，不仅体系结构不尽相同，通信协议也完全不同。因此，WEB服务与Agent技术的集成问题备受业界关注。

本人的研究关注的是WEB服务技术与Agent技术集成众多方面中的一个，即如何将一个具有移动性质的软件Agent服务发布成一个Web Service。除非特别申明，否则下文所指的Agent即为具有移动性质的软件Agent。

2研究现状

这个领域的研究工作主要有：

文献【1】里提出了一种WEB服务与遵循FIPA规范的Agent系统之间的集成架构建议。

图表 1 WEB服务与Agent集成架构

从图中我们可以看出，一个FIPA Agent 服务到WEB服务网关在两个环境的边界，通过将ACL消息转换成WEB服务调用，使得FIPA Agent可以访问WEB服务。相反的另一方，WEB服务到FIPA Agent网关将Agent服务注册到UDDI注册服务器中，方便其它WEB服务客户端调用。

或许是受到了这个集成架构建议的启示，两个先锋组织分别设计并实现了集成架构建议中的两个重要方面问题：文献【2】能够让Agent调用现有的WEB服务；文献【3】能够将Agent发布为WEB服务。文献【3】的软件实现产品WSAI（Web Service Agent Integration）从第一个版本便被开放为开源项目。

本人的研究方向和文献【3】相同，即将Agent所提供的服务发布为WEB服务。经过分析WSAI的理论方法及技术方法发现，发现由如下不足的地方：

1、仅局限于静态的Agent，不能解决Agent移动后，WEB服务的可用性，限制了Agent的最大特点-移动性。

2、限于JADE Agent系统平台Agent单线程的特性，使得Agent异步、有状态通信与WEB服务的通信模型不能很好的集成。

3、被发布为WEB服务的Agent仅仅局限于遵循FIPA Agent规范的Agent。事实上，Agent界有主要有两大规范，其一是FIPA组织制定的，其二是OMG组织下的Agent小组。

4、从技术的角度讲，WSAI设计的网关以及WSDL接口均需要开发人员手工安装、编写，未实现自动化。

鉴于以上种种不足，本人希望在WSAI的基础上，提出一种更健壮、支持面更广的，能将Agent发布为WEB服务的框架。

3 Agent与WEB服务集成框架

图表 2 Agent与WEB服务集成框架

Agent与WEB服务集成框架的核心是WAG（Web Service Agent Gateway），它负责将Agent发布为WEB服务。而WAG的实际工作全部由GA（Gateway Agent）来承担。初步设计的GA主要结构如下图所示：

3.1 Gateway Agent

在接下来的时间里，这一部分的主要工作包括：

3.1.1 Agent Web服务的调用机制

描述从WEB服务客户端调用开始，到调用目标Agent服务后，最终返回结果的整个过程。

3.1.2目标Agent位置管理机制

当目标Agent发生移动以后，该机制负责WEB服务的可用性，也即WEB服务调用可达到目标Agent服务。

3.2 SOAP引擎

负责接收来自WEB服务客户端的调用，并将其SOAP消息转换成JAVA类的Web Service接口。此外，所有的AG将在该引擎中注册。SOAP引擎可采用现有的开源项目。

3.3 Gateway Controller

负责AG的加载，并发布为Web服务或者将AG在UDDI注册中心中注册。

4 结束语

接下来的研究工作将围绕WAG的几大组件展开。目前暂时设计了整体框架结构，当然随着研究工作的进一步深入，现有框架的结构需要进一步完善。

 参考文献

【】FIPA specification. http://www.fipa.org/specifications/index.html

【】Sommers, Frank: Publish and find UDDI tModels with JAXR and WSDL

【】Agenticities Web Services Working Grroup. Integrating Web Services into Agentcities Technical Recommendation, Http://www.agentcities.org/Srec/00006/

【】Globus Alliance, IBM, and HP,”Web service Resource Framework”, http://www.golubs.org

【】Whitestein Information Techology Group. Web service agent Integration Project

    http://wsai.sourceforge.net/index.html

【】Thang Xuan Nguyen. WS2JAE: Integrating Web Service With Jade Agents.

（**大学**实验室，** ）

摘要： 移动 Agent 平台的异构性，使得不同平台间难以实行互操作。文章浅层次的分析了移动代理系统互操作性有关的 CORBA ， MASIF 和 FIPA 规范。

关键词： 移动 Agent ，互操作性， CORBA ， MASIF ， FIPA

1 引言

移动 Agent 是结合了 Agent 的一种新型分布计算技术，由于它的智能性、移动性、自主性和协作性，已在信息检索、移动计算、电子商务及网络管理等方面得到一定的应用。许多公司和研究机构都发布了各自的移动 Agent 平台，如 IBM 的 Aglets ， Dartmouth College 的 AgentTcl, Stuttgart University 的 Mole, ObjectSpace 的 Voyager 等等。由于这些平台在体系结构和实现上有较大差异，无法实现互操作，已成为限制移动 Agent 广泛应用的主要原因之一。为此， OMG 组织已经开展有关移动 Agent 的标准化工作，并提出移动 Agent 互操作机制标准 MASIF 。本文分析了在解决互操作问题上的相关技术。

2 相关理论或技术基础

2.1 移动Agent技术介绍

2.1.1   软件 Agent

软件 Agent是运行于动态环境的、具有高度自治能力的实体，它能够接受其它实体的委托并为之服务。不难看出，软件Agent首先具有智能特性，它对环境有响应性、自主性和主动性；同时，软件Agent还具有社会特性。

自主性(Autonomy)：软件Agent在运行过程中不直接由人或其它主体控制，它能在没有与环境相互作用的情况下自主执行任务，对自己的行为和内部状态有一定的控制权。自主性是软件Agent区别于普通软件程序的基本特征。

响应性（Reactivity）：软件Agent能对来自环境的信息做出适当的响应，它能感知所处的环境，并能通过自己的行为改变环境。

自动性（Proactivity）：传统应用程序接受用户指令被动执行，而Agent不仅能对环境变化做出反应，更重要的是能在特定情况下采取主动行为。

推理性（Reasoning）：软件Agent可根据已有的知识和经验，以推理的方式进行推理。软件Agent的智能由3个主要部件来完成，即内部知识库、自适应能力以及基于知识库的推理能力。

通信/合作/协作（Communication/Cooperation）：这是在软件Agent群体中应该具有的社会属性。

2.1.2 移动 Agent

移动 Agent 技术是目前计算机科学领域中非常重要的研究技术之一。移动代理（ Mobile Agent ）是一个代替人或其它程序执行某种任务的程序，它在异构网络环境中自主地从一台主机迁到另一台主机，并可以和 Agent 或其它软件资源交互的实体。 移动Agent是一种特殊类型的软件Agent，它除了具有软件Agent的基本特性-自主性、响应性、主动性和推理性外，还具有移动性。在移动过程中能够根据要求挂起，然后转移到网络的其它地方重新开始或继续其执行，最后返回结果和消息，代表用户完成指定任务。由于移动Agent可以在异构软、硬件网络环境中自由移动，因此，这种新的计算模式能有效地降低分布式计算中网络负载、提高通讯效率、动态适应变化的网络环境，并具有很好的安全性和容错能力。

2.2 CORBA

全球性网络使线上的所有设备和软件成为全球共享的浩瀚的资源，计算机环境也从集中式发展到分布式环境，开放式系统的发展使用户能够透明地应用由不同厂商制造的不同机型不同平台所组成的异构型计算资源，因此，分布式处理和应用集成自然而然地成为人们的共同要求，那么什么是分布式处理和应用集成呢？它们的功能和关键技术是什么呢？简单地讲，分布式处理和应用集成就是指在异构的、网络的、物理性能差别很大的、不同厂商的、不同语言的信息资源的基础上构建信息共享的分布式系统，并且能够有效地进行应用系统和分布式处理的集成。分布式处理的关键在于定义可管理的软件构件，即面向对象技术中的 “ 对象 ” 。应用集成的关键在于为跨平台、跨机种、跨编程语言的产品提供统一的应用接口。OMG组织针对当今信息产业的要求，公布了CORBA标准，即公共对象请求代理体系结构（Common Object Request Broker Architecture），这是一个具有互操作性和可移植性的分布式面向对象的应用标准。

CORBA的核心是对象请求代理ORB，它提供对象定位、对象激活和对象通讯的透明机制。客户发出要求服务的请求，而对象则提供服务，ORB把请求发送给对象、把输出值返回给客户。ORB的服务对客户而言是透明的，客户不知道对象驻留在网络中何处、对象是如何通讯、如何实现以及如何执行的，只要他持有对某对象的对象引用，就可以向该对象发出服务请求。CORBA允许用户以两种不同的方式提出对象请求：

1）静态调用：

通过给定接口的存根，在编译了对象代码后，进入客户端的程序。因此，静态调用必须在编译时就知道对象及其类型。

2）动态调用：

通过ORB的动态调用接口DII，在运行时生成访问对象的代码。不管客户以哪一种形式提出请求，ORB的任务是：找出所要对象的位置，激活该对象，向对象传递此请求。对象执行所请求的服务后，把输出值返回给ORB，然后再由ORB返回给客户。

3 Agent System Interoperability

3.1 CORBA 和移动Agent的结合

移动代理技术和 CORBA 技术在许多方面不同，最显著的是 CORBA 采用对象一旦被分配就一直停留在固定位置直到它在 ORB 中注册，而移动代理可以动态、自主地在执行期间移动。

第二个不同点是移动 Agent 明确自己目前的位置，而且知道所需资源的位置，具有丰富的信息来动态地决定迁移。对 CORBA 来说，当它回答客户请求时，试图隐藏服务器对象的物理位置。很显然， ORB 知道注册对象的分配，但是这个信息对客户和应用开发者来说是隐式的。

另一个不同点在于融合性（ diffusion ）， CORBA 拥有一个普遍被接受的规范，有许多的资源、系统和业务足见遵从这个规范。相反，移动 Agent 可编程范例的特性导致产生了各种不同的、不能互操作的代理平台。

1.         然而 CORBA 与移动 Agent 技术的结合，可以完全实现异构移动 Agent 平台之间的互操作性。当 MASIF 和 FIPA 都采用 CORBA 作为标准桥梁时，就可以克服两种规范之间的异构性。

3.2 MASIF                        

不同 Agent 之间的互操作性是使基于不同移动代理平台的商业化融合的关键因素。互操作性要求移动代理技术能够趋于规范化。 OMG 提出了 MASIF （ Mobile Agent System Interoperability Facilities ）规范，这是一个代理的互操作性标准，它是在 CORBA 体系中构建的，支持代理的移动和管理。 MASIF 的目标是不需要对现有各种代理平台进行大量的修改，而仅通过用 ”add-on” 模块来扩展，以实现现存不同结构的移动代理平台之间的互操作性。

MASIF 提出对代理和代理系统命名、系统种类及位置语法的标准化。 MASIF 定义了两个标准架构： MAFAgentSystem 和 MAFFinder ，通过接口定义语言对它们的属性、操作和返回值作了明确的规定。前者定义对 Agent 的操作，包括接受、创建、挂起和终止 Agent 的执行，后者定义了 Agent 的注册（去注册）以及 Agent 、 place 和 Agent 系统的定位。这些接口在 Agent 系统层上定义，因为 Agent 只能在支持同类 Agent 的 Agent 系统间流动，无需对 Agent 的接口进行定义。而 MASIF 中定义的标准化 Agent 管理操作实现 Agent 在系统间进行流动。针对 CORBA 命名服务只支持静态对象的情形， MAFFinder 则是必要的补充，它提供了动态的名址数据库接口。 MAFAgentSystem 和 MAFFinder 接口分别提供 15 和 9 个操作支持 Agent 的管理和名录服务。 OMG 的目标是使不同软件开发商所开发的产品可以在一致的分布式对象环境下协同工作， CORBA 对于 Agent 系统的支持通过上述两类接口实现。基于 MASIF 标准的移动 Agent 分布式体系结构如图 1 所示。

图 1 基于 MASIF 标准的移动 Agent 分布式体系结构

3.3 FIPA

FIPA 明确了服务于代理与其他实体（管理员、其它代理、非代理软件和物理世界）交互的不同组件的接口。因为主要涉及到智能代理领域， FIPA 把重点放在代理间通信的标准化问题上， FIPA 提出一个专门的代理通信语言（ Agent Communication Language ， ACL ）来解决遵从 FIPA 的所有代理之间的通信问题。

FIPA 定义了为代理平台服务的三种基本业务：代理管理系统（ Agent Management System,AMS ）、 Directory Facilitator(DF) 和代理通信信道 (Agent Communication Channel,ACC) 。 AMS 提供类似 MAFAgentSystem 的管理功能，但是，不同点在于 FIPA 的 AMS 不能解决在异构移动代理平台之间代理的移动问题。

FIPA 代理可以为其它代理提供服务，而且它们的服务内容可以在网络黄页上通过 DF 搜寻到。在一个代理平台中，在 DF 中的注册是任意的，而在 AMS 中的注册则是必须的。

ACC 能够促使在同一个代理平台上代理之间的通信，也可以通过提供一个消息转发机制来使代理在异构平台之间通信。

平台之间的互通性通过 CORBA ORB 的转发业务可以实现，与 CORBA 的结合对遵从 FIPA 的移动代理平台来说是必需的，代理的消息传递通过 CORBA IIOP 实现。

因为 AMS 和 DF 业务提供类似于 MASIF MAFAgentSystem 和 MAFFinder 的功能，对于 FIPA 标准化的建议是提出通过一个共同使用的 ACL 来实现代理之间的通信。

4 结论及未来工作

已经有人研究发现， MASIF 制定的移动 Agent 平台之间的互操作性，没有定义域间移动 Agent 的定位操作。对于移动 Agent 平台之间的互操作方面，还有很多问题，有待研究，解决，完善。在接下来的两周里，将着重对 MASIF 、 FIPA 的关于通信语言，互操作规范进行研读，并了解 CORBA 在解决异构 Agent 平台方面的 Solutions 。

参考文献

[1]           张颖江，吴珊 移动代理在分布式计算中的应用和实现。

[2]           偶晓娟，雷霖，李建华 移动代理互操作性研究。

[3]           欧阳晔，姜浩，潘顺 移动 Agent 域间发现机制研究。

[4]           Object Management Group TC Document Orbos Mobile Agent System Interoperability Facilities Specification.

近两个星期以来，我所读的材料，主要是关于 Agent 方向的。读了几篇综述性的文章，对 Agent 概念和相关知识，有了初浅的认识。现就先前读过的材料进行个回顾和小结：

读过的文章如下： 移动 Agent 系统的研究、移动 Agent 研究、移动 Agent 在分布式计算中的应用、移动 Agent 综述、多 agent 协同系统的分布式数据访问、基于多移动代理的分布式协同控制研究、移动多 agent 在移动电子商务系统中的应用、移动代理在分布式计算中的应用和实现。

记录自己觉得比较重要的点：

1 、 Mobile agent 是一个代替人或其他程序执行某种任务的程序，它在异构网络环境中自主地从一台主机迁到另一台主机，并可以和 agent 或其他软件资源交互的实体。移动 agent 的基本特性：自主性（ autonomy ）、响应性（ reactivity ）、自动性（ proactivity ）和推理性（ reasoning ）外，还具有移动性。在移动过程中能够根据要求挂起，然后转移到网络的其他地方重新开始或继续其执行，最后返回结果和消息，代表用户完成指定任务。

2 、分布式环境下，为了完成共同的目标，多个移动 Agent 在自治的基础上需要相互协同、实时交互和通信，它们之间既竞争又合作，表现出自治性、社会性和动态性等属性。有关分布式计算环境中多移动 agent 的协同、交互和并行控制等问题的研究和实现方法很少见。

 3 、移动 Agent 的效率很大程度决定于路由策略的优化。目前，在路由策略中引入 Qos 是一个研究重点 。

4 、移动 Agent 天生就具有分布式的特点，一个基于移动 Agent 的应用由一组移动 Agent 构成，每一个 Agent 根据自身的目标和环境的状况移动到拥有计算所需资源的节点上进行计算。在进行计算时可能需要与其他 Agent 进行通信协作，而整个计算过程则可能会分成多个步骤进行，每一步完成之后，移动 Agent 都将自主地决定下一步的动作，直至其任务全部完成后才自动消亡。

5 、移动 Agent 技术，用户可以将整个任务而不是单个请求提交给多个 Agent 去执行，这些 Agent 被发送到网上之后，可以独立于发送它们的程序，异步地、自主地、协作地完成任务，它们的生命周期可以长于创建它们的程序。

6 、目前移动 Agent 技术的研究热点包括：将移动 Agent 技术和已有实现系统进行集成的集成框架研究、移动 Agent 的编程模型的研究、移动 Agent 的应用系统开发方法的研究等。

7 、移动 Agent 系统是一种中间件，位于操作系统和应用程序之间，封装了低层网络协议，提供移动、通信、容错和安全等基本功能，开发人员无须了解低层实现即可开发网络应用。

思考的问题：

1、          移动 Agent 易于定制个性化服务：服务提供可以只提供一些基本的底层的服务，服务请求者根据自己的需求将高层的功能代码发送到服务提供者，实现个性化服务的定制，增加了分布式应用的可伸缩性。定制服务和 Webservices 有什么区别？都可以采用哪些服务定制机制？

2、          通常情况下，一个 MAE （ MA 环境）只位于网络中的一台主机上，但如果主机间是以高速网络进行互联的话，一个 MAE 也可以跨越多台主机而不影响整个系统的运行效率。一个 MAE 也可以分布在不同机器上，来完成一种协作式的 MAE ？

3、          移动 agent 迁移到网络目的节点，自主完成任务，执行结果异步返回，使得分布式用户可以不必持续在线联网，实现断续的异步通信，有效地节约了带宽。当 Agent 完成任务之后，通过转接机制（ Docking ）监视用户是否在线，当它发现用户在线时，就返回计算结果。那么，当 Agent 返回结果集时，用户离线时如何处理这些结果集呢？

4、          文章：基于多移动代理的分布式协同控制研究，提到：任务等待队列（ wait-list ）是等待执行任务的移动 Agent 事务列表，它与共享区中的工作片具有一一对应的关系。 Wait-list 中的移动 Agent 事务根据优先级降序排列；对具有相同优先级的事务，根据到达的先后顺序进行排列。移动 Agent 调度组件每次从 Wait-list 中取出优先级最高的移动 Agent 事务，进入执行状态。移动 Agent 共享工作区里，如果此时需要几个 Agent 一起协作，优先级如何处理？

5、          文章：移动 Agent 系统的研究，提到：在一个网络节点失效之前，在其上工作的移动 Agent 可以立即感知，并完成相应的备份工作，然后移动到其他节点，继续原来的工作。只有原来的节点上才有所需要的资源，如何应对呢？尽管移动到了其他节点上，可没有执行所需要的资源，这个 Agent 还有作用？

以上遇到的一些问题，显得比较初级。就读了以上文章的感觉，移动 AGENT 是个很大的方向，里面有很多东西可以挖，可究竟要挖什么点，还是没有头绪，我想，原因更多的可归结为文章还读的不够多，资料还看的不够细致。所以，在接下来的时间里，还需要大量的阅读相关资料。同时，学习移动 AGENT ，需不需要掌握一些人工智能方面的知识？此外，对于“ 3D image retrieval ”，还是没查到有价值的资料，而对于“数据和文档管理系统”，总感觉很宽泛，不知道究竟该怎么入手？究竟是研究？还是做实际的系统？模糊不清。