用于多主体系统的基于中介的恢复机制的制作方法

专利名称：用于多主体系统的基于中介的恢复机制的制作方法
技术领域：
本发明涉及用于多主体系统(multi-agent system)的基于中介 (mediator)的恢复机制。更具体地，但并非唯一地，本发明涉及如下恢 复机制，其中多个软件主体在时间敏感(time-critical)应用中进行在线 交互，该时间敏感应用要求每个主体必须了解其它主体所达到的最新状 态。
背景技术：
容错多主体系统在本领域己经是公知的。例如，Staffan Hagg, "A Sentinel Approach to Fault Handling in Multi-Agent Systems", in Proceedings of the Second Australian Workshop on Distributed Al， in conjunction with Fourth Pacific Rim International Conference on Artificial Intelligence (PRICAI，96)， Claims, Australia, 1996提出了一种在多主体系 统中进行故障处理的方法，其中"Sentinel"主体监控应用主体之间所交 换的消息，以检测任何恶意的或有故障的主体。实现Sentinel主体系统通 过防止主体间活动发生故障使得多主体系统可以变得更为健壮。然而 Sentinel主体是基于应用的，并且必须为各新的应用而定制。Mark Klein, Juan Antonio Rodriguez-Aguilar禾卩Chrysanthos Dellarocas， "Using Domain-Independent Exception Handling Services to Enable Robust Open Multi-Agent Systems: The Case of Agent Death," Journal of Autonomous Agents and Multi-Agent Systems, 2001也提出了 Sentinel主体 概念。Klein等人公开了不依赖于域的Sentinel主体，从而一旦开发出 Sentinel主体，它们可以用于监控任何种类应用主体。在多主体体系结构 中，各应用主体与一 Sentinel主体绑定。这些Sentinel主体还相互协作， 以通过连续检测所绑定的应用主体来防止任何故障。Lateff. O. Ogunleye， "The state detection of a multi-agent system," Working Paper, Department of Computer Science, University of Saskatchewan, Canada公开了——禾中改进的 容错多主体系统。Ogunleye公开了基于Report Card的状态检测机制，其 中各主体具有其自己的卡，该卡每隔一段时间就被更新以表示正在如何 处理特定任务。汇报卡还可以用于检测该主体对于其正在处理的作业而 言的进展。Ogunleye还说明了一种黑板系统，其用于保持与主体可以投 标的任务有关的所有信息，这使得可以在任务级别详细地监控该主体。以上现有技术提供了容错机制，该容错机制限于防止多主体系统的 故障，而不会进行故障恢复，从而在多主体系统事实上崩溃并且需要恢 复的情况下，该容错机制并没有试图解决问题。该问题已被其它现有技术所解决，所述其它现有技术在多主体系统 出现故障的情况下指导进行恢复。例如，参见Qiming Chen， Umeshwar Dayal, "Multi-Agent Cooperative Transactions for E-Commerce"， Proc. Fifth IFCIS Conference on Cooperative Information Systems (CooplS'2000), 2000, Israel; Kumar, Sanjeev; Cohen, Philip R., "Towards a Fault-Tolerant Multi-Agent System Architecture", In Proceedings of the Fourth International Conference on Autonomous Agents (Agents 2000), ACM Press, Barcelona, Spain, June 3-7, 2000, pages 459-466; Kumar, Sanjeew; Cohen, Philip R.; Levesque, Hector J. "The Adaptive Agent Architecture: Achieving Fault-Tolerance Using Persistent Broker Teams", in Proceedings of the Fourth International Conference on Multi-Agent Systems (ICMAS 2000), Boston, MA, USA， July 7-12, 2000， pages 159-166. 2000;以及Pradeep R. Varakantham， Santosh K. Gangwani禾卩Kamalakar Karlapalem， "On Handling Component and Transaction Failures in Multi-Agent Systems," ACM SIGecom Exchanges, vol 3.1, pp.32~43, 2002。在Kumar等人(2000)的两篇参考文献中，提出了一种自适应主体 体系结构(Adaptive Agent Architecture),该体系结构通过使用持久代理 组(persistent broker teams)来支持容错多主体系统。通过该方法，具有 代理组的多主体系统可以利用除了陷入崩溃的一个或更多个代理以外的
其余代理主体的协作来恢复所述陷入崩溃的主体的一个或更多个主体程序。另一方面，Chen和Dayal对在用于多主体系统的分布式数据库中的 事务管理技术进行定制。为此，他们引入了用于委托(commit)控制和 故障恢复的多主体合作事务和对等协议。Varakantham等人提供了一种恢复机制，其通过在一个主体内使用工 作流概念并将所有工作流状态信息记录到本地存储中来恢复崩溃的多主 体系统。然而，Varakantham等人提出的方案只适于如下系统，其中参与 主体在具有足够本地存储的设备上运行以确保主体可以将他们的状态定期地保存到该本地设备。因此所提出的方案不适合于如下情况没有提 供本地存储(例如，没有或几乎没有本地存储的移动设备)，或者多个主 体要求快速表示其它主体的实时状态，例如，如果由于电池故障而失去 到因特网的无线连接，而用户正在参与在线拍卖或游戏应用程序，则可 能出现这种情况。可以利用软件体系结构来对软件系统建模。软件体系结构一词是指 具有计算组件及其交互的集合的软件系统的高级模型，计算机组件的交 互是诸如过程调用、事件广播、数据库查询和管道处理的连接处理 (connector)。软件系统的体系结构模型使得可以获得相互通信、较早的 设计决断以及系统的可转换抽象(transferable abstraction)。此外，该软件 体系结构体现在系统中的组件和组件交互之间。有利地，该体系结构使得复杂的系统更易处理、可分析以及可再用(参见Garlan,D.和Shaw, W.， "An Introduction to Software Architecture", /"/mwriowa/Tow/"""/ q/"iSb/ nwe 5Wgz'ween'"g 尺"cw/ec/ge 5)zg7'"eeWwg, Vol. 1, World Science Publishing, 1993，以及Robbin, J.E., Medvidovic， N., Redmiles, D.F.和Rosenblum, D.S,， "Integrating Architecture Description Languages with a Standard Design Method",/GS￡， Kyoto, Japan, 1998, pp.209-218以获得更多信息)。主体体系结构可以分为两类单个主体的内部体系结构以及多主体系统(MAS)的体系结构。在MAS中，多主体体系结构在规定主体之间 的关系和协调时扮演重要角色。MAS提供该技术来支持通过主体的自主 和智能交互而工作的组。该自主减轻了工作人员的信息过载并有助于管 理与其它工作人员的交互。在一组工作人员参与长期协作的情况下(例如，在诸如与拍卖或合 约网相关的时间量程上)，所述支持的利用率最大。使用已知MAS来支 持长期组协作的缺点在于该协作的大部分阶段对于使用人员是隐藏的， 这使得当在协作过程中存在任何严重故障时难于恢复协作状态。结果， 如果在长期主体交互过程中出现严重故障(如主体的崩溃)，则整个协作 必须从开始重启，这导致时间的损耗并增加了所投入的努力。此外，由 于存在多个进行协作的主体，所以一个主体的崩溃不会被立即通知给其 它主体，如果其它主体长时间没有从该崩溃主体收到响应，则其它主体可能挂起(hang)。对于这些问题的已知解决方案是受限的，包括设计需求将解决方案 限于具有本地永久存储的设备。这些己知解决方案通常涉及存储主体的协作状态(使用本地存储)，并使用所存储的信息来恢复崩溃主体的协作 状态。在所考虑的设备不具有本地存储的情况下或者如果主体平台不支 持高速缓冲功能(例如，在利用JavaTM虚拟机的某些变型的情况下)，则 这些解决方案不是可行的解决方案。例如，手持设备(如移动电话或PDA) 可能不具有任何本地存储和/或主体平台高速缓存功能。如果移动设备由于某一原因崩溃，或者要么例如由于使该移动设备 的用户能够继续进行他们与使用另一电池有电的移动设备的其它主体的 当前协作的电池没电，而使该移动设备从其通信网络突然断开，则期望 具有该本地存储和/或主体平台高速缓存功能。利用当前的MAS体系结 构无法实现这种简单的恢复机制。发明内容本发明寻求通过提供在任何具有存储能力设备上运行的并且记录 MAS中的其它组成主体的协作状态的协作中介主体，来调停和/或消除现 有技术的以上缺点。根据本发明的第一方面，提供了一种恢复多主体体系结构中的多个 组成主体之间的协作状态的方法，该方法包括处理由中介主体为各组
成主体转发协作信息；保持从各协作主体提供给所述中介主体的协作信息中导出的协作处理状态信息记录；并且在实现协作的设备遭遇如下事件，g卩，该事件导致一个或更多个组成主体丢失其协作状态的情况下， 使用一个或多个所述协作处理状态信息记录来恢复协作状态。优选地，所述中介主体通过多主体平台的管理主体来登记其中介服务。优选地，所述组成主体在所述恢复协作状态的步骤之前预订中介服务。优选地，在第一方面的方法中，如果第一组成主体将其角色(role) 委托给至少一个其它委托组成主体，则中介主体保持与至少一个其它委 托组成主体的角色有关的状态信息。优选地，所述多个主体之间的协调由包括全局设计和局部设计的交 互设计规定，其中全局设计为所有参与协作的组成主体指定全部交互步 骤，而局部设计为各参与组成主体指定特定协作活动。优选地，转发给中介主体的协作信息包括组成主体的局部设计的执 行状态。优选地，组成主体没有将该组成主体的局部设计实例的执行状态存 储在该主体所运行的设备的永久存储中。根据本发明的第二方面，提供了一种被设置为恢复多主体体系结构 中的多个组成主体之间的协作状态的装置，该装置包括至少一个处理 器，其被设置为处理由中介主体为各组成主体转发的协作信息；存储装 置，其被设置为保持从各协作主体提供给所述中介主体的协作信息中导 出的协作处理状态信息；以及信息提供装置，其在实现协作的设备遭遇 如下事件，g卩，该事件导致一个或更多个组成主体丢失其协作状态的情 况下，以适于利用当前协作状态信息来更新该事件所影响的各组成主体 的形式，提供从一个或更多个所述协作处理状态信息记录中导出的信息。优选地，在该装置包括移动电话或PDA的本发明的实施例中，由于 无需在该设备上提供存储能力来确保在MAS崩溃的情况下的恢复，所以 可以保持设备的轻质。
根据本发明的第三方面提供了一种计算机程序产品，包括一组被设 置为实现本发明的任何一方面的方法的一个或更多个计算机程序。根据本发明的第四方面提供了一种信号，包括被设置为利用组成消 息来预订中介服务的服务预订消息。根据本发明的第五方面，提供了一种网络，其包括根据本发明第二 方面的多个装置，至少两个装置互连。根据本发明的第六方面，提供了一种多主体体系结构，其包括多个 组成主体和一个中介主体，该中介主体被设置为在进行协作的所述组成 主体之间进行调停，所述体系结构被设置为执行根据本发明第一方面的 方法中的步骤。
根据本发明的第七方面，提供了一种在多主体体系结构中的被设置 为执行预定角色的第一组成主体与另一主体之间进行委托的方法，所述 组成主体和所述另一主体被设置为经由中介主体进行通信，所述方法包 括如下步骤将请求消息从第一组成主体发送到中介主体，以委托给另 一主体；由中介主体将所述委托请求消息转发给所述另一主体；在所述另一主体处接收所述委托请求处理所述委托请求并将所述委托请求己 被接受的表示提供给中介主体；从所述中介主体将来自第一组成主体的 包括局部工作流实例的信息传送到另一主体。根据本发明的第八方面，提供了一种被设置为将恢复信息提供给中 介主体的组成主体，所述组成主体具有将表示其局部交互设计状态的信 息转发给中介主体的装置。根据本发明的第九方面，提供了一种被设置为将恢复信息提供给中 介主体的组成主体，所述组成主体具有存储表示其局部交互设计状态的 信息并将关于所述交互状态的信息转发给中介主体的装置。根据本发明的第十方面，提供了一种被设置实现恢复多主体体系结 构中的多个组成主体之间的协作状态的方法的中介主体，该中介主体包 括接收并存储由各组成主体提供的协作信息的装置；更新所述协作信 息以生成至少一个处理状态信息记录的装置；以及在实现协作的设备遭 遇如下事件，即，该事件导致一个或更多个组成主体丢失其协作状态的
情况下，使用一个或更多个所述协作处理状态信息记录来恢复所述协作 状态的装置。优选地，通过提供在具有本地存储的设备上运行的协作中介主体， 在没有本地存储的设备上运行的组成主体的协作状态也可以被存储。 优选地，组成主体只经由中介主体相互进行交互。有利地，由于所有消息都由中介主体来发送，所以中介主体保持最 新的协作状态，甚至参与主体的内部状态。如果任何组成主体崩溃，则 该主体重启并从所述中介主体找到在其崩溃之前的最新状态，从而进行 恢复。有利地，包括本发明的局部和全局设计的交互模型表示通用多主体交互，然而Varakanthan等人使用Petri-net模型来只表示单主体处理和多 主体交互的问题解决处理，以解决分级问题。Varakanthan通过使多主体 交互类似于单主体行为来恢复这种类型的交互。即，发起者主体控制下 级主体的行为以解决问题。在该方法中，上级主体和下级主体具有主从 关系，其中主控主体具有对于其从属主体的完全控制。这表示， 一旦主 控主体崩溃，就不可能恢复其从属主体，并且因此不可能恢复整个系统。 这并不是适合于诸如在在线拍卖、合约网和在线游戏场景中发生的对等 主体交互的方法。根据本发明的第十一方面，提供了一种被设置为嵌入组成主体中的 工作流引擎体系结构，该工作流引擎体系结构包括调度器；任务管理 器；状态管理器；工具库；以及工作流实例库。根据本发明的第十二方面，提供了一种重启由中介主体动态给出的 局部工作流实例的方法，该方法包括验证从中介主体接收的工作流实 例的有效性；将有效工作流实例存储在局部工作流实例库中；并且通过 执行来自中介主体的缓冲消息，使所述局部工作流实例与中介主体的全 局工作流实例同步。


下面将参照只通过示例方式提供的附图来说明本发明的优选实施
例，其中图1是根据本发明的基于中介的多主体体系结构的示意图；图2是根据本发明的交互设计的示意图；图3示意性地示出了轻质工作流引擎的体系结构；图4示意性地示出了当完成了局部交互设计中的正在进行的动作时 调度和执行动作的具体过程；图5A和B示意性地示出了针对特定多主体交互的全局交互实例的 组成处理；图6示意性示出了交互恢复协议；图7示意性示出了主体内的恢复处理；以及图8A和8B分别示意性示出了根据本发明两个实施例的协作信息的 交换。
具体实施方式
以下是本发明的优选实施例的详细说明，这些优选实施例包括对于 发明人当前所考虑的本发明的最佳模式的说明。即使没有明确说明，但 是对于本领域技术人员很显然，本发明的特定特征可以由其己知等价物 代替，并且如果合适，本发明的范围旨在包括这些等价物。参照附图中的图1，示意性地示出了根据本发明一个实施例的基于 中介的多主体系统(MAS)体系结构。在图1中，体系结构1包括多个 组成主体2a、 2b、 3以及被设置为与各组成主体2a、 2b、 3相互连接的 中介主体4。中介主体4还被设置为提供到管理系统5的输入，以使得当 各组成主体试图相互协作时各组成主体能够预订该中介主体4的中介服 务，下面将详细说明。简言之，该中介提供给管理系统的输入使得当组 成主体请求从管理系统5进行索引簿搜索时中介可以将其中介服务通告 给组成主体。为此，管理系统包括主体管理系统6以及支持一个或更多 个服务描述库8的索引簿服务商7。更具体地，在图1所示的本发明的实施例中，中介主体通过将信息 提供给由诸如FIPA规范的索引簿服务商的管理主体所保持的服务描述库
来利用管理系统登记其中介服务(更具体地，参见FIPA Abstract Architecture Specification, Foundation for Intelligent Physical Agents, 2000, httr>:〃www.fba.org/specs/)。也可以使用其它通告机制，只要他们能够使 中介主体提供适当的服务描述。中介主体的服务描述包括中介服务名称、 要使用的交互协议等。组成主体得到中介主体的地址，如果服务描述符 合某一准则，则组成主体使其自己预订该中介主体的中介服务。基于预订的中介服务由中介主体提供。为了预订中介服务，组成主 体向中介主体发送包含中介服务的名称和中介服务中的预订主体的角色的预订消息。各组成主体5， 6的内部状态由局部工作流实例表示，该局部工作流 实例是局部交互设计的实例，该实例指定了应当由该主体执行以参与和 MAS中的其它主体的协调的动作。所有协调主体(为了清楚在图1中只 示出了两个)的协调状态由全局工作流实例表示，该全局工作流实例是 全局交互设计的实例，该实例指定了应当由所有参与协调的主体执行的 动作。如图l所示，该体系结构可以用于将来自组成主体2a的角色委托给 至少一个其它组成主体2b (在下文中更详细地说明)，并可以用于崩溃组 成主体的恢复。如果一个主体将其在交互设计中的角色委托给另一组成 主体，则在两个组成主体之间存在角色委托关系，在这种情况下，中介 主体将用于该授权(donor)主体的局部工作流实例发送到委托主体。该 体系结构支持主体角色的委托并在崩溃后快速恢复的能力在需要管理多 主体交互的机制的任何情形中都是有用的。该体系结构的全局和局部设 计交互模型有利地支持状态同步和角色委托，这对于由于例如在协调过 程中的电池问题而想要从一个移动设备改变到另一移动设备的移动设备 操作者而言特别有用。在图1中，用于恢复没有本地存储设施的设备上的多主体系统的基 于"协作中介"的多主体体系结构使用交互协议，该协议规定了在参与 的主体之间所交换的消息的顺序。该中介主体根据所采用的交互协议管 理组成主体之间的协作。即，所有组成主体只将消息发送到中介主体，
然后中介主体将这些消息路由到其它主体，其它主体在各阶段中调整对 这些消息的处理负责的角色。由于组成主体之间的所有消息都经过中介 主体，所以中介主体保持并更新这些组成主体的协作状态。在本发明的 优选实施例中，中介主体在具有本地存储的设备上运行，从而该中介主 体可以本地地记录协作状态以从崩溃中恢复。相反地，组成主体可以在 不具有本地存储的设备上运行。下面参照附图的图2，该图示意性地示出了根据本发明的交互设计 结构。该交互设计描述了用于交互协议的工作流。该工作流包括交互协 议的详细处理。在图2中，交互设计结构包括全局交互设计IO和局部交互设计lla、 llb。通过使用如下交互设计使参与交互的各主体(包括组成主体和中介主体)对于用于中介服务的交互协议具有相同理解中介主体13保持全局交互设计10，并且各组j^主体12a、 12b保持局部交互 设计lla、 llb。全局交互设计IO指定总体交互步骤，其中参与角色进行相同活动。 通过相应的执行者角色(actor role)、基数、输入消息和输出消息来描述 各活动。基数指定该活动是否应该被初始化为由具有相同角色的不同执 行者所同时进行的多个实例。全局交互设计具有如下限制相邻动作应该由不同角色来执行。例 如，全局交互设计10中的活动A和B (或者C和D)不能由相同主体执 行。经由消息将交互控制从一个主体转换到另一主体。即，活动A产生 消息mdp该消息被传递给另一主体以用作针对活动B的输入(对于md2 和md3的情况相同)。在图2中示出了用于全局交互设计10的两个局部交互设计lla、 1 lb。 各局部交互设计是用于在属于一个角色的全局设计中规定的活动的详细 设计。全局设计中的各活动具体地是局部交互设计中的动作(即， 一个 活动是一个或更多个动作的组合)，以表示如何处理所输入的消息(对于 B的md"对于C的md2以及对于D的md3)以创建输出消息(对于A 的m山、对于B的md2以及对于D的md3)。在图2中，组成主体12a进行全局交互设计10中的角色1并负责执
行活动A和C。另一方面，组成主体12b进行全局交互设计10中的角色2并负责活动B和D。各组成主体12a、 12b分别执行其局部交互局部设 计lla、 llb，并将其执行状态独立地发送到中介主体以记录在中介主体 所运行的本地机器中。全局交互设计10中的相邻活动不能由一个角色来进行。因此，在某 一点(从图2中的活动A (B)的最后动作到活动C (D)的第一动作) 中，针对一角色的局部设计中的多个下级活动会断开。使用特殊动作"发 送消息"和"接收消息"来连接这些下级活动(图2中的活动"S"和"R")。当一个角色产生了输出消息时，执行发送消息动作以将消息发送到中介 主体。然后，控制转到"接收消息"状态，即，等待接收针对下一阶段 的输入消息。在图2中，示意性地示出了各局部交互设计lla、 llb，作为通过转 换(由箭头表示)链接的一系列有顺序的动作(由活动(A、 B、 C或D) 内的内部矩形表示)。利用各动作的输入值、输出值、用于执行该动作的 工具以及执行后状况来描述各动作。转换链接两个相邻动作。利用前动 作、后动作来描述转换，并且可以利用根据各工作流实例来评估真假的 条件来扩充(augment)该转换。局部设计的执行产生了工作流实例。工 作流实例包含与该局部设计的设计相关的历史信息。历史信息包括工作 流实例的创建时间、完成时间以及所完成的活动实例的顺序。活动实例 包含起始时间、完成时间、执行者、输入值和输出值。例如，在拍卖中，"宣布开始拍卖"、"投标价格"、"更新最高价格" 和"结束拍卖"成为活动。用于"宣布开始拍卖"的活动的动作将为"确 定起始价"、"找出拍卖的参加者"以及"准备产品描述"等。工作流引擎嵌入式主体各组成主体12a、 12b配备有工作流引擎，以调度并执行局部交互设 计。在本发明的优选实施例中，工作流引擎是轻质工作流引擎。在本说 明书中，"轻质工作流引擎"一词是指其中工作流实例可变并且工作流实 例的状态信息因此没有存储在永久存储中的工作流引擎。这些工作流模 型不支持由工作流管理联盟(WfMC)所定义的所有建模，或者具体地，
没有实现在WfMC的工作流参考体系结构中定义的接口 4和5。接口在 根据本发明的工作流引擎的体系结构中不是必需的。关于WfMC的更多 具体情况可以从WfMC (工作流管理联盟)h加:〃www.wfmc.org和WfMC 工作流标准规范TC-1016陽P-"Interface 1: Process Definition Interchange Process Model", http:〃www.wfmc.org/standards/docs/ifl9807r3.pdf中获得。下面参照附图中的图3，该图示意性地示出了根据本发明一个实施 例的轻质工作流引擎嵌入式主体的内部体系结构。工作流引擎20包括工 作流实例库21、状态管理器22、任务管理器23、调度器24、局部设计 规定25和工具库26。当任务管理器23完成了一动作时，调度器24主要 参考局部设计规定确定随后的动作。图4示出了当完成了前一动作时要调度并执行动作的详细过程。当 请求调度器24 (参见图3)来调度接下来的动作时(步骤31)，该调度器 24找出前代(precedent)动作的后代(descendant)动作组(步骤32)。然 后，调度器24利用其前代动作评估连接各后代动作的转换的条件(步骤 33和34)。只有利用被评估为真的转换而链接的动作才被包括在调度动作组中 (步骤36)。然后调度器24通知任务管理器23执行调度动作。任务管理器26根据局部交互设计规定25分析由调度器提供的动作 规定(步骤37、 38)，并从工具库26中找出用于执行这些动作的适当工 具。该动作可以是内部动作(为一活动定义的针对应用的动作)或者协 作动作(向/从中介主体发送/接收消息的专用动作)。如果对于执行39调度内部动作，则任务管理器23从工具库26中找 出适当的工具(步骤43)，并调用该工具以得到对于该动作的输出(步骤 44到45)，并且前一动作的输出用作下一动作的输入(步骤46，引导至 步骤37)。如果调度动作不是内部动作，而是协作动作(步骤40)，则通过工 具库26中的两个通用工具消息发送器27和消息接收器28来进行该动作。 例如，如果协作动作是发送动作(步骤40),则任务管理器将包括当前工 作流实例和随后发送给中介主体的ACL消息的信息提供为到消息发送器
27的输入(步骤41)。消息发送器工具的输出是过滤信息，该过滤信息 用于标识来自其它参与主体的相应消息。然后，过滤信息用作消息接收器工具28的输入，该消息接收器工具28随后等待从中介主体接收任何 响应消息(步骤42)。各工具的执行结果由将结果通知给状态管理器22的任务管理器23 来监控，并且状态管理器22更新相应的工作流实例(步骤46)。工作流 实例21被管理和监控工具29(如用于将进度信息表示给移动工作人员的 GUI)所查询。全局交互实例的组成图5A、 B、 C示意性示出了用于特定多主体交互(例如，移动工作 人员之间的这种作业交易)的全局交互实例的构成处理。图5A示出了涉及两方或更多方之间的作业交易的本发明的一个实 施例。在图5A所示的实施例中，这些方的主体的角色包括作业给与者 48、中介49和作业承担者主体50。作业交易是移动工作人员之间的有用 的协作机制，该机制使得工作人员(具有由于时间限制或其它原因而不 能由他/她本人完成的作业)根据预定义的策略(例如，从作业地点到同 事的当前位置的距离最小)将该作业重新指派给他/她的同事，参见HLee, M Buckland 禾口 J Shepherdson, "A multi-agent system to support location-based group decision making in mobile teams". BT technical Journal: Vol. 21， No. 1,2003。此处将作业规定为包括顾客信息、诸如设备修理或 供应等的作业详情，以及作业重要性等。该作业交易的全部处理在以下 步骤中执行首先，作业给与者发送一个或更多个C0FD (距离请求)消息。各消 息包括作业给与者想要交易的作业的详情，并且该消息被发送到适当候 选者以告知这些预期候选者作业给与者寻求作业交易。然后候选者选择 适当的应用来响应该CFD。CFD消息接受者想要被分配该作业，计算从该消息接受者的当前位 置到作业位置的距离。该距离值可用于创建包含所计算出的距离的投标， 以发送到作业给与者。接下来，作业给与者评估所接收的投标，并使用
一个或更多个适当准则(通常与最接近作业的工作人员相关)选择最适 合的投标者。包含结果表示的消息被送回作业投标者，以通知作业投标 者他/她的投标被接受还是被拒绝。在本实施例中，MAS主体交互的全局交互设计包括四个活动宣布作业交易51、申请投标52、评估投标53和处理响应54。针对活动申请 投标的特定动作包括接收CFD 55、准备距离56和发送距离57。在图5A和5B中，当作业给与者主体将触发消息发送到中介主体时 (步骤62)，中介主体创建全局设计的实例(全局工作流实例58)(步骤 61)。触发消息是由全局设计的第一动作创建的第一消息(在示例交互中， 由作业承担者发送的第一消息，其中CFD是消息内容)。从组成主体(图5A中的作业给与者或作业承担者主体)发送到中介 主体的消息内容示例如下(Mediate(:sender jobgiver_name@telco.com) (:receiver MediatorAgent@telco.com) (:ontology "TeamCoordination") ( 'language "SL0") (:Protocol "interaction-mediation") (:content(local-workflow-case (uiid "mdl2121123A，，) (interaction-plan-id "give-job")(state info : (plan-name "give-job，，)(creator "Job Giver's Name") (creation-time 27-08-2002》 (Request (:sender j obgiver砂elco. com) (:language "SLO") (:protocol "FIPA一Request") (' content (action(get-distance (task (id "tal223，，)(name "ISDN provision") (post-code "IP5 3RE"))))) ))更概括地，根据本发明的消息的内容包括表示局部工作流实例的谓 词和需要转发给其它组成主体的内部消息。中介主体使局部工作流实例 构成全局工作流实例，并且该中介主体将内部消息转发到执行对全局交 互设计的下一阶段负责的角色的主体。返回到图5B，当消息到达中介主体49处时，中介主体检查该消息 是否是触发消息(步骤62)。通过简单地检查该消息是否在其字段中包含 唯一的交互标识符号码(UNIN)值。假设UNIN对于各全局工作流实例 是唯一的。如果该消息是触发消息，则中介主体通过检査包含在该消息 中的信息来识别相应的全局交互设计(步骤63)。为此，使用在以上消息 内容中的(local-workflow-case(interaction-plan-id ，，give-job，，))字段。然后， 中介主体创建全局工作流实例(基于全局交互设计)(步骤64)，并将UNIN 发配给该全局工作流实例(步骤65)。接下来，中介主体从所接收的消息 中提取局部工作流实例59，并将其复制到所创建的全局工作流实例(60， 步骤66)。如果所接收的消息不是触发消息，则中介主体从该消息中提取局部 工作流实例，并通过参照消息内容中的(local-workflow-case (interaction-plan-id "give-job"))字段来将该实例复制到适当的全局工作流 实例。中介主体还生成针对全局工作流实例的附加信息，例如，执行者 主体信息、所创建的时间和消息内容等。从这一点出发，从中介主体到 组成主体的消息使用UIIN。再次参照图5A和5B，在记录了与全局工作流实例有关的发起者和 请求详情之后，中介主体根据全局设计描述找出消息的接收者(步骤67)， 并将该消息转发给这些接收者(步骤68)。然后，响应主体执行其局部设 计并将响应消息返回到中介主体。该响应消息还包含响应主体的局部交 互设计工作流实例。然后中介主体根据所采用的交互协议将响应消息转 发给发起者主体。下面简单地返回到图3，组成主体(发起者和响应主体)的工作流
引擎将局部工作流实例交互设计以及ACL消息中的局部交互消息的输出经由消息发送器27发送到中介主体。局部工作流实例59还被复制到全 局工作流实例60。组成主体的执行状态被记录在永久存储中的时间由该 ACL消息何时被从组成主体传到中介主体来决定。中介主体每次从组成 主体接收到消息时都更新全局工作流实例(全局交互设计)，并记录相应 的全局工作流实例(全局交互设计)的最新状态。在中介主体崩溃的情 况下，所记录的信息可以用于恢复该中介主体的状态。 崩溃主体的恢复图6示意性地示出了用于根据本发明实施例的恢复处理的交互协 议。在图6中，该协议开始于崩溃主体(由图6中的"参加者"70表示) 重启并联系中介主体71以预订中介服务。这是通过将请求预订消息71 从图6所示的参与者70发送到中介71而进行的。中介主体查询其全局工作流实例库，以检査预订主体是否参与了任 何未完成的协作。然后，中介主体告知被预订的主体存在未完成的协作(如图8上部的通知消息73所示)。该通知消息包含主体所参与的协作 的UIID。如果成功地预订了所重启的主体，则该主体将中介主体登记在 其中介索引簿中，该中介索引簿将中介服务与中介主体相映射。该重启 主体可以通过发送用于状态同步处理的请求消息75来请求交互恢复处理(图6中的请求恢复消息75)，或者通过发送请求中介主体的请求消息 74来进行中止以中止未完成的协作。在后一情况下，中介主体通过将终 止消息发送到其它参与主体来启动对于未完成协作的关闭处理79。如果重启的主体请求恢复，则中介主体准备通知消息76，该通知消 息包含局部工作流实例，该局部工作流实例反映了在前一主体崩溃之前 的局部交互设计的最新状态(图6下部的通知消息76)。然后，重启的主 体使用该信息创建针对崩溃的局部交互设计的局部工作流实例。所接收 的局部工作流实例被复制到该重启主体的工作流引擎的工作流实例库 内。然后，该重启主体通知工作流引擎的调度器根据所复制的状态信息 开始调度(图6中的通知完成消息78)。随后，将工作流实例视为常规实 例，S卩，作为工作流引擎内的任何其它工作流实例。如果在恢复过程中主体通过将中止消息发送到其它参与主体将中 止消息(图6中的请求中止消息77)发送到对未完成的协作进行中止的中介主体(图6下部的请求中止消息77)。否则，该重启主体对中介主体发送通知消息，表示准备好继续协作。在图7的流程图中更详细地示出了主体内的恢复处理，该图示意性地示出了恢复处理中的步骤。如果组成主体由于其崩溃而重启，则其从中介主体接收其局部工作流(图7中的WF)实例(在其崩溃之前的最新实例)以及所缓冲的消息 (在从主体的崩溃到重启的时间段中缓冲在中介主体中的消息)(步骤 81)。然后，组成主体检查所接收的工作流实例的有效性(步骤82)。如 果该工作流实例有效(步骤83),则组成主体将该工作流实例复制到该组 成主体的局部工作流实例库中，以通过其工作流引擎进行重启(步骤84)， 另选地，组成主体中止恢复处理(步骤89，参见下文)。如果存在任何接收的缓冲消息(步骤85)，则组成主体通过将所缓 冲的消息提供为局部交互设计中的动作的输入来执行所复制的局部工作 流实例(步骤87)。如果在该同步处理过程中存在任何故障(步骤88)， 则组成主体中止恢复处理(步骤89)。否则，中介主体将成功消息(步骤 86，并参照图6中的步骤78)发送到中介主体，告知该中介主体准备好 继续进行与其它主体的原来的交互处理(步骤86)。交互角色的动态委托由于组成主体没有紧密地互相绑定，所以一个组成主体可以将其角 色委托给其它主体，以可以继续进行交互，即使组成主体由于例如主机 设备上的电源故障而不能从严重故障恢复。在移动性重要的情况下，该 功能很有用，这是因为该功能使得操作移动设备的人在执行应用时可以 使用多个设备。这些移动用户可以通过预定的交互协议将一个设备上的 主体的角色委托给另一设备。这使得移动用户可以确保当预料到设备可 能崩溃时该设备上运行的主体所进行的功能被转交给一个或更多个其它 设备上运行的一个或更多个主体。这对于移动设备特别有用，例如在电 池指示器显示该移动设备的电池源故障，或者网络拥塞指示器显示由于
高网络拥塞而使网络连接超时的情况下。在突然掉电等的情况下也可以 实现该功能，这使得由于可以找出当前的协作状态所以可以更快地进行 重新连接，并且发起者和响应者主体之间的协作从停止的状况起继续。委托交互协议开始于组成主体将委托请求消息发送到中介主体。可 以将角色委托给现存的组成主体或者不存在的组成主体。如果角色被委 托给不存在的主体，则中介主体保持转发给委托主体的所有消息，并进 行等待直到不存在的主体被投入使用并试图预订该角色。如果该新主体 预订该中介主体，则处理该预订的处理与上部分中说明的恢复处理相同。将请求消息转发给目标主体的中介主体将角色委托给现存主体。该 目标主体可以接收或拒绝该请求，并且根据该响应将局部工作流实例传 送到目标主体或中止。本发明的优选实施例提供了一种工作流系统，其使得可以自动进行 移动商业处理。由于移动工作人员喜欢携带手持设备，优选地没有或几 乎没有本地存储设置的轻质设备，所以在确保该移动设备失去连接的情 况下可以恢复时，工作流客户端系统特别有用。具体地，当多个分散的工作人员经由诸如"拍卖(Auction)"或"合约网(Contract-Net)"的预 定义交互协议进行工作协作时，使用本发明的一个实施例。本发明的另一实施例使得移动用户可以动态恢复信息，从而可以将 操作从一个移动设备切换到另一设备。当一个设备的操作员在与其它工 作人员的协作过程中由于例如电池问题或其它不可操作性原因而希望中 断到另一设备的电源时本发明同样有用。这使得系统高度可靠和健壮，即使在诸如不稳定的网络连接和低计 算能力的恶劣环境条件下。本发明是一种非常通用的技术，其可以应用于任何种类的其中客户 端主体可以根据主要境况动态地改变其本地设备的多主体系统。例如， 在用户在一个办公室中工作并与同事进行交互的情况下，可以重新安置 到另一地点或建筑物并继续与同事的交互，当继续进行时保持交互最新 状态。在图8A和8B中示出了这种情况。在图8A中，以对比的方式示出 了在发起者主体A和响应者主体C之间经由中介主体的简单交互。在图8A中，中介保持A和C的全局交互设计状态信息，并且A保持如下局 部交互设计，其包含由中介主体转发的与A的交互状态和响应者主体C 的状态有关的信息。类似地，响应者主体C保持如下局部交互设计，其 包含C的状态信息以及由中介主体转发的A的状态信息。在A失去了与 中介主体的连接的情况下，中介主体能够将全局交互设计的详情提供给 承担了 A在交互中的角色的委托主体(未示出)。该全局交互设计包含使 委托主体继续与C的交互的充分信息，似乎从未丢失与A的连接，从而 委托主体获悉在丢失连接时C的交互状态的程度与A获悉该信息的程度 相同。在图8B中，另一主体B经由中介主体初始化与C的通信。在应用 需要A获悉B与C的交互状态的情况下，例如如果正在执行在线实时拍 卖，则中介主体必须确保全局交互设计反映该事实。这确保如果A失去 其与C的连接，则中介主体可以确保全局中介设计能够使委托主体恢复 从所参与的下述A失去其连接起的交互状态，从而中介主体利用与C和 B之间的交互状态有关的最新信息更新委托局部交互设计，从而A通过 获悉该状态而确保了其的交互。本领域技术人员可以理解，本发明的许多特征都可以以软件和/或硬 件来实现，并且本发明的精神旨在覆盖任何适当的软件和/或硬件的组合 形式的实施例。
权利要求
1. 一种恢复多主体系统体系结构中的多个组成主体之间的协作状态的方法，该方法包括处理由中介主体为各组成主体转发的协作信息；保持从各协作主体提供给所述中介主体的所述协作信息中导出的协作处理状态信息记录；以及在实现协作的设备遭遇如下事件，即，该事件导致一个或更多个组成主体丢失其协作状态的情况下，使用一个或多个所述协作处理状态信息记录来恢复所述协作状态。
2、 根据权利要求l所述的方法，其中所述中介主体被设置为利用任 何多主体平台的管理主体来登记其中介服务。
3、 根据权利要求2所述的方法，其中所述组成主体在所述恢复协作 状态的步骤之前预订所述中介服务。
4、 根据以上任一权利要求所述的方法，其中如果第一组成主体将其 角色委托给至少一个其它委托组成主体，则所述中介主体保持与至少一 个其它委托组成主体中每个的角色有关的状态信息。
5、 根据以上任一权利要求所述的方法，其中所述中介主体保持与所 有委托主体的角色有关的状态信息。
6、 根据以上任一权利要求所述的方法，其中所述多个主体之间的协 作由包括全局设计和局部设计的交互设计规定，其中所述全局设计为参 与协作的各组成主体指定总的交互步骤，而所述局部设计为各参与组成 主体指定各协作活动。
7、 根据以上任一权利要求所述的方法，其中所述转发给中介主体的 协作信息包括组成主体的局部设计的执行状态。
8、 根据权利要求7所述的方法，其中所述组成主体没有将所述组成 主体的局部设计实例的执行状态存储在永久存储装置中。
9、 一种在多主体体系结构中的被设置为执行预定角色的第一组成主 体与另一主体之间进行委托的方法，所述组成主体和所述另一主体被设 置为经由中介主体进行通信，该方法包括如下步骤将请求消息从所述第一组成主体发送到中介主体，以委托给另一主体；由所述中介主体将所述委托请求消息转发给所述另一主体； 在所述另一主体处接收所述委托请求；处理所述委托请求并将所述委托请求已被接受的表示提供给所述中 介主体；从所述中介主体，将来自第一组成主体的包括局部工作流实例的信 息传送到所述另一主体。
10、 根据权利要求9所述的方法，其中在所述转发委托请求的步骤 之前，该方法还包括以下步骤将所有消息保持在所述中介主体中直到所述其它主体被投入使用；以及将所述中介主体预订给所述其它主体。
11、 一种被设置为恢复多主体体系结构中的多个组成主体之间的协 作状态的装置，该装置包括至少一个处理器，其被设置为处理由中介主体为各组成主体转发的协作信息；存储装置，其被设置为保持从各协作主体提供给所述中介主体的协 作信息中导出的协作处理状态信息；以及信息提供装置，其在实现协作的设备遭遇如下事件，即，该事件导 致一个或更多个组成主体丢失其协作状态的情况下，以适于利用当前协 作状态信息来更新由该事件影响的各组成主体的形式，提供从一个或更 多个所述协作处理状态信息记录中导出的信息。
12、 一种中介主体，被设置为提供中介服务以恢复多主体系统体系 结构中的多个组成主体之间的协作状态，该中介主体包括接收并存储由各组成主体提供的协作信息的装置； 更新所述协作信息以生成至少一个处理状态信息记录的装置；以及 恢复装置，其在实现协作的设备遭遇如下事件，即，该事件导致一 个或更多个组成主体丢失其协作状态的情况下，使用一个或更多个所述 协作处理状态信息记录来恢复所述协作状态。
13、 一种被设置为将恢复信息提供给中介主体的组成主体，该组成 主体具有将表示其局部交互设计状态的信息转发给中介主体的装置，所 述中介主体如权利要求12所述。
14、 一种被设置为将恢复信息提供给中介主体的组成主体，该组成主体具有存储表示其局部交互设计状态的信息并将关于所述交互状态的 信息转发给中介主体的装置。
15、 一种计算机程序产品，包括一组被设置为执行根据权利要求1 到10中任何一个权利要求的方法的一个或更多个程序。
16、 一种计算机程序产品，包括在线拍卖应用中的组件。
17、 一种计算机程序产品，包括在线投机应用中的组件。
18、 一种网络，包括被设置为实现权利要求1到10中任何一个的方 法的一个或更多个设备。
19、 一种网络，包括如权利要求ll所述的多个装置。
20、 一种多主体体系结构，包括多个组成主体和一中介主体，所述中介主体被设置为在进行协作的多个所述组成主体之间进行中介，所述 体系结构被设置为执行根据权利要求1的方法中的步骤。
21、 一种信号，包括被设置为将组成消息预订到由中介主体支持的 中介服务的服务预订消息，所述中介服务包括如权利要求IO所述的在多 主体体系结构中的被设置为执行预定角色的第一组成主体与另一主体之间进行委托的方法。
22、 一种被设置为嵌入组成主体中的工作流引擎体系结构，该工作 流引擎体系结构包括调度器； 任务管理器； 状态管理器； 工具库；以及 工作流实例库。
23、 一种重启由中介主体动态给出的局部工作流实例的方法，该方法包括验证从中介主体接收的工作流实例的有效性； 将有效工作流实例存储在局部工作流实例库中；以及 通过执行来自中介主体的缓冲消息，使所述局部工作流实例与中介 主体的全局工作流实例同步。
全文摘要
一种恢复多主体系统体系结构中的多个组成主体之间的协作状态的方法，该方法包括处理由中介主体为各组成主体转发的协作信息；保持从各协作主体提供给所述中介主体的所述协作信息中导出的协作处理状态信息记录；以及在实现协作的设备遭遇如下事件，即，该事件导致一个或更多个组成主体丢失其协作状态的情况下，使用一个或更多个所述协作处理状态信息记录来恢复协作状态。
文档编号G06F11/07GK101213521SQ200480007939
公开日2008年7月2日 申请日期2004年3月3日 优先权日2003年3月24日
发明者李河宾, 约翰·威廉·谢泼德森 申请人:英国电讯有限公司