CN101378403B - 一种基于集合的资源通知处理系统及处理方法 - Google Patents

Abstract

一种基于集合理论的资源通知处理机制的处理系统包括：通知处理模块、资源管理模块、客户端组件和资源回调接口，处理方法包括以下步骤：A、当资源管理模块实例化一个资源时，将每个资源封装为主题并添加到主题容器中，同时向通知代理进行注册；B、通知代理收到订阅者的订阅请求后，将该订阅信息添加到订阅的主题对应的订阅队列中；C、当资源管理模块对资源状态进行更改后，触发回调接口将事件进行封装后交给通知代理，通知代理将事件内容转发给所有订阅该主题的订阅者；D、当资源管理模块销毁资源时，将资源对应的主题从主题容器中删除，并且向通知代理取消注册。E、重复执行第A～D步，实现对不同资源的通知处理。本发明全部实现了WS-BrokeredNotification协议，形成了完全独立的通知代理。

Description

一种基于集合的资源通知处理系统及处理方法

技术领域

本发明涉及一种符合WS-Notification协议的可扩展的基于主题的Web服务通知机制的处理系统及处理方法。

背景技术

在分布式计算系统中，计算系统日益复杂和庞大，越来越呈现出其松耦合、动态性、开放性等特点，这一切使得分布式系统的开发、管理和维护变得更加的复杂。因此，作为开发和使用人员，人们需要采用相关的通信技术来降低系统的复杂程度。

异步的消息交互模式在现在的计算机系统当中非常的常见。电子邮件、传真、语音邮件等等，都是基于推模式的异步消息交换形式。异步的消息交换模式能够使得用户摆脱即时响应的传统消息交换模式，允许服务端不必在请求发生之后的即时响应客户端以服务计算的结果。

在Web服务领域，随着Web服务技术的不断发展，人们也逐渐感受到对异步的消息交互模式的需求。早期的Web服务领域当中，诸如取得当前的交通信息状况、计算当前的汇率情况等服务形态通常都会采用典型的远程过程调用(RPC)的形式。在远程过程调用系统当中，服务的提供者在同一次服务连接当中返回给客户端以服务的运算结果。然而此种消息交互的形式很显然不能满足很多应用场景的需求。比如在服务端需要长时间计算的情形下，服务计算的结果信息无法即时地通过一次交互返回给用户。此种场景下，人们需要通过通过异步的消息交互模式去告诉用户最终的运算结果能够极大的提高系统的实现效率。

WSRF协议的引入对Web服务领域进行了新的变革。有状态Web服务的引入，直接导致了对服务状态信息改变的通知需求。由于Web服务器内部的资源状态在不断的更新，必然会有相应的若干实体会对资源的状态改变产生兴趣。而由于资源状态更新时间的不可预知性，若采取RPC模式或者传统的轮询机制，必然给服务器实现效率带来巨大的挑战。

在传统的分布式系统中，通常采用通知机制的发布/订阅模式来解决上述异步通信场景的需求。通知机制的发布/订阅模式以其异步通信，松耦合，匿名交互，多对多通讯以及简单的API等特点，解决了传统分布式系统中日益复杂和效率底下等缺点。在Web服务领域，发布/订阅模式的使用，能够有效的解决RPC等同步调用机制带来的缺点。它使用了中间代理机制有效的降低发布者和订阅者之间的耦合程度，并可实现多对多的通讯模式。简单API更可以方便用户的使用，并提高了系统的灵活性。

目前，存在着两种主要的Web服务发布/订阅技术规范，由Microsoft、BEA等提出的WS-Eventing和IBM、GT4、HP等公司共同提出的WS-Notification，其中WS-Notificatin相对WS-Eventing对服务接口和报文的格式描述更加详尽，易于扩展，并且已经成为OASIS标准，得到了大多数主流厂商的支持。

目前主流Web服务发布/订阅系统的实现有：

Globus Toolkit 4.0(GT 4)是美国Argonne National Laboratory实现的网格中间件。Globus的核心包括GT4-Java和GT4-C，分别基于Java语言和C语言实现。两种语言版本的实现中都包括了对WSRF当中的WSRP，WSRL，WSBF，WSSG等实现。在WS-Notification协议族方面，GT 4-C实现了WS-BaseNotification和WS-Topic的功能，对于WS-BrokeredNotification还没有相应的实现。GT 4-Java则WS-BrokeredNotification上有部分实现。

Pubscribe来自Apache开源组织。Apache上现在有两个相应的工程WSRF和Pubscribe，都是Globus组织捐给Apache的关于WSRF和WS-Notification的实现代码，它实现的基本功能最初都是来自Globus。目前Pubscribe对WS-BaseNotification，WS-BrokeredNotification和WS-Topic都有实现，为WS-BrokeredNotification提供了扩展的接口但没有实现。Pubscribe还对WS-Eventing协议进行了支持，因为WS-Eventing在功能上属于WS-Notification的子集，Pubscribe通过接口适配器对二者进行了兼容。

pyGridWare：由美国Lawrence Berkeley National Laboratory开发的Python语言版的网格中间件。它现在对WS-BaseNotification有完整实现，而对WS-topic有部分实现，对于WS-BrokeredNotification没有实现。

WSRF::Lite：由英国Manchester大学开发的Perl语言版的网格中间件。它现在对WSRF协议族有了完整实现，但是对WS-Notification协议族还没有实现代码。

WSRF.NET：由美国Virginia大学开发的基于.NET框架的网格中间件。它现在对WS-BaseNotification，WS-BrokeredNotification有完整实现，而对WS-topic有部分实现。

IBM WebSphere Application Server V6.1：2006年8月份，WebSphere刚刚对WSRF和WS-Notification协议进行了实现。根据IBM提供的信息，它们针对WS-BaseNotification和WS-BrokeredNotifcation进行了实现，对于WS-Topic进行了部分实现。

综合以上国外研究组织对于WS-Eventing和WS-Notification典型实现，各个厂商对对Web服务通知协议实现的比较如下：

表主流系统对Web服务通知协议的实现比较

	WS-Eventing	WS-Topic	WS-BaseNofication	WS-BrokeredNotifiation
					GT4-Java	否	部分	是	部分
GT4-C	否	部分	部分	否
					ApachePubscribe	是	部分	是	否
pyGridWare	否	部分	是	否
					WSRF::Lite	否	否	否	否
WSRF.NET	否	部分	是	是
					WebSphere6.1	是	部分	是	是

可以看到包括Globus联盟在内，所有的主流研究机构对于Web服务通知协议的实现都是并不完善，并没有提供对WS-BrokeredNotification的完整实现。

发明内容

本发明的技术解决问题：克服现有技术的不足，提供一种基于集合理论设计并实现了一个符合WS-Notification协议的可扩展的基于主题的Web服务通知机制的处理系统及处理方法，全部实现了WS-BrokeredNotification协议，形成了完全独立的通知代理。

为实现上述目的，本发明的技术方案为：一种基于集合理论的资源通知处理机制的处理系统，包括：通知处理模块、资源管理模块、客户端组件和资源回调接口，其中：

通知处理模块，部署在服务层，实现发布或订阅信息的管理、主题的管理、完成发布或订阅流程的实现，其通过资源回调接口与资源管理模块完成相关事件的交互，根据资源管理模块送来的用户的订阅记录，将事件发送给客户端组件的订阅客户端中订阅此事件的用户；

资源管理模块，部署在服务层，将资源状态封装成基于集合论与数理逻辑的对象结构Metaset；将用户对资源的访问转换成对使用Metaset描述的对象的操作，通过对Metaset对象的处理产生返回的相关事件的Metaset表示，再将Metaset表示通过资源回调接口送至通知处理模块；

客户端组件包括订阅客户端和监控客户端，订阅客户端通过SOAP报文与通知处理模块交互，完成订阅消息的构造、订阅请求消息的发送及订阅响应的接收；监控客户端用于监控通知处理模块所支持的主题信息，将主题信息通过网页的形式显示给最终的用户；

资源回调接口，把资源管理模块中资源发生变化的事件进行封装，发送给通知处理模块。

本发明的基于集合理论的资源通知处理机制的处理方法，包括以下步骤：

(1)当资源管理模块实例化一个资源时，将每个资源封装为主题，通过资源回调接口发送给通知处理模块，由通知处理模块进行主题注册；

(2)通知处理模块接收到订阅客户端的订阅请求后，将该订阅信息转交给订阅管理，实现主题订阅；

(3)当资源管理模块对资源状态进行更改后，通过资源回调接口将通知事件进行封装后交给通知处理模块，通知处理模块再将此通知事件转给所有订阅该主题的订阅者；

(4)当资源管理模块销毁资源时，将通过资源回调接口将资源销毁事件封装后交给通知处理模块，由通知处理模块实现主题的销毁；

(5)重复执行步骤(1)~(4)，实现对不同资源的通知处理。

本发明与现有技术相比的优点在于：

(1)本发明基于一个符合WS-Notification协议的可扩展的基于主题的Web服务通知机制的处理系统及处理方法，全部实现了WS-BrokeredNotification协议，形成了完全独立的通知代理，且通知代理和通知发布者之间仅通过SOAP消息通信，实现了较高程度的松耦合。而且简化了资源通知处理机制的处理，提高了处理的效率。

(2)本发明将通知系统中各个角色按照其功能划分为相对独立的自治模块，通过不同的模块间的交互实现了系统的松耦合性，提高了系统的可扩展性。

(3)另外在通知系统中通过使用Metaset对资源进行封装实现了资源的快速查找和修改，以及在主题管理模块通过树形数据结构实现了主题的快速定位，其性能优于目前已有的实现。

(4)本通知系统实现了WS-BaseNotification，WS-Topic以及WS-BrokeredNotification协议，相比其它的实现对协议有较为完整的支持，并对协议中描述的标准的通知系统的接口及SOAP报文规范进行了设计与实现。

(5)主题管理模块通过树形数据结构实现了主题的快速定位，其性能优于目前已有的实现。

附图说明

图1为本发明的基于集合的资源通知处理系统的结构示意图；

图2为本发明的通知处理模块的体系结构图；

图3为本发明的主题管理模块的结构图；

图4为本发明的订阅管理器的数据结构示意图；

图5为本发明的TopicSet池的数据结构示意图；

图6为本发明的资源管理模块的体系结构图；

图7为本发明的主题订阅模块结构图；

图8为本发明的主题监控模块结构图；

图9为本发明的基于集合的资源通知处理方法的实现流程结构图；

图10为本发明的通知主题的发布过程图；

图11为本发明的通知主题的订阅过程图；

图12为本发明的通知消息的发送过程图。

具体实施方式

在阐述本发明实现方法之前，先介绍一下Metaset：

Metaset是由北京航空航天大学计算机学院ACT实验室提出的一个以集合论和数学逻辑理论为工具、以Services集为对象、以元操作为运算符的理论体系，用以构造网格计算环境下的数学模型。

该数学模型将服务的资源属性文档定义为五元组Doc_wrpd＝<S_en，S_ev，S_an，S_av，S_wrpd>。其中S_en是资源属性文档元素名集合，S_ev是资源属性文档元素值的集合，S_an是资源属性文档那个属性名集合，S_av是资源属性文档属性值的集合，S_wrpd是XML语言表示的资源属性文档的描述集合，其元素是Services集。上述定义将资源属性文档表示成为一个集合，文档中的每个子句都是集合中的元素，以Services集的形式存在。下面给出Services集几个关键元操作的定义。

定义1 Services集合的滤波函数是多态函数，其值为集合，集合的元素为Services集。Services集的滤波函数有三种形式，一种是仅有路径最为参数，另一种是以路径和路径的最后一个属性名作为参数，再一种是以路径和路径最后一个属性名和属性值作为参数。滤波函数返回值是一个集合，其集合元素是在路径上最后一个元素的Services集。

$\mathrm{filter}(S_s,p)\&RightArrow;\left\{S_s\left(e_n\right)\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right)\}$

$\mathrm{filter}(S_s,p,a)\&RightArrow;\left\{S_s\left(e_n\right)\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;...\&Superset;S_s\left(e_n\right),<e_n,a,*>\&Element;S_s\left(e_n\right)\}$

$\mathrm{filter}(S_s,p,a,v)\&RightArrow;\left\{S_s\left(e_n\right)\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;...\&Superset;S_s\left(e_n\right),<e_n,a,*>\&Element;S_s\left(e_n\right)\}$

Filter函数用λ(S，path)表示，它的功能是获取请求路径上满足某种指定条件的Metaset元素的集合。

定义2 Services集的选择函数Selector的返回值为属性值，选择函数Selectors的返回值是属性集合。

$\mathrm{Selector}(S_s,p)\&RightArrow;e\&Element;\left\{e_n\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right)\}$

$\mathrm{Selector}(S_s,p,a)\&RightArrow;v\&Element;\left\{v\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right),<e_n,a,v>\&Element;S_s\left(e_n\right)\}$

$\mathrm{Selectors}(S_s,p,a)\&RightArrow;\left\{v\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;...\&Superset;S_s\left(e_n\right),<e_n,a,v>\&Element;S_s\left(e_n\right)\}$

Selector函数用σ(S，path)表示，它的功能是获取指定路径上满足特定条件的属性值。

定义3 Services集的Add函数表示向其中插入一个元素或一个Services集，其结果仍为Services集。

$\mathrm{add}(S_s,p,<e_n,a_k,v_k>)\&RightArrow;\left\{S_s\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right),$

$S_s\left(e_n\right)\&cup;\{<e_n,a_k,v_k>\}\}$

$\mathrm{add}(S_s,p,S_s\left(e_{n+1}\right))\&RightArrow;\left\{S_s\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right),$

$S_s\left(e_n\right)\&cup;\left\{S_s\left(e_{n+1}\right)\right\}\}$

Add函数用+(S，path)表示，它的功能是增加一个Metaset子元素或添加一个属性。

定义4 Services集的Remove函数表示从Services集中移处一个元素或一个子Services集，其结果仍为Services集。

$\mathrm{remove}(S_s,p,<e_n,a_k,a_k>)\&RightArrow;\left\{S_s\right|p\&Element;P_{\mathrm{path}},\mathrm{path}=e_{n0}\backslash e_{n1}\backslash ...\backslash e_{\mathrm{nn}},$

$S_{\mathrm{ss}}\&SupersetEqual;S_{\mathrm{ss}}\left(e_{n0}\right)\&Superset;S_{\mathrm{ss}}\left(e_{n1}\right)\&Superset;...\&Superset;S_{\mathrm{ss}}\left(e_{\mathrm{nn}}\right),S_{\mathrm{ss}}\left(e_{\mathrm{nn}}\right)-\{<e_{\mathrm{nn}},{\mathrm{av}}_k,{\mathrm{av}}_k>\}\}$

$\mathrm{remove}(S_{\mathrm{ss}},S_p,e_{n+1})\&RightArrow;\left\{S_s\right|p\&Element;S_p,p=e_0\backslash e_1\backslash ...\backslash e_n,S_s\&SupersetEqual;S_s\left(e_0\right)\&Superset;S_s\left(e_1\right)\&Superset;...\&Superset;S_s\left(e_n\right),$

$S_s\left(e_n\right)-\left\{S_s\left(e_{n+1}\right)\}\right\}$

Remove函数用-(S，path)，它的功能是删除特定路径上的Metaset子元素。

定义5 Services集的Car函数表示选择其第一个元素，其结果仍为Services集。car(S_s)→S₁，S_s＝{S₁，S₂，...，S_m}，它的功能是获取当前Metaset元素的第一个子元素。

定义6push函数用↓(S，path)表示，pop函数用↓(S，path)表示。

通过使用Metaset来表示和描述Web服务资源属性文档，使用上述定义的操作对其进行统一的处理，避免了在引擎内部进行繁杂的对象强制转换过程，可以使用统一的算法处理各种类型的资源状态，从而简化了整个系统的设计和实现，缩短了整个系统的开发周期。

下面结合附图及实施例详细叙述一下本发明的实现过程。

如图1所示，本发明包括通知处理模块、资源管理模块、客户端组件和资源回调接口。本发明的通知处理模块部署在服务层，实现发布或订阅信息的管理、主题的管理、完成发布或订阅流程的实现，其通过资源回调接口与资源管理模块完成相关事件的交互，根据资源管理模块送来的用户的订阅记录，将事件发送给客户端组件的订阅客户端中订阅此事件的用户。

如图2所示，本发明的通知处理模块包括主题管理、通知消息发派器、通知发布者、订阅管理器、主题列、TopicSet池。

通知代理，负责处理订阅请求、发布主题请求和通知发布请求，同时维护主题列表TopicSet池；通知代理接收通知消息派发器转发过来的主题订阅请求，将此请求转发给订阅管理器，完成主题订阅功能，通知代理还根据通知发布者提供的通知事件信息向订阅管理器查找订阅此事件的用户，再将此事件通过通知消息发器发送给所查找到的用户；通知代理接收通知发布者的主题发布请求，将此主题发布请求发送至主题列表TopicSet池，实现主题请求的发布；通知代理同时还将主题发布请求发送给主题管理，进行主题表达式的解析；

通知消息发派器，将通知事件消息主动与订阅客户端建立连接，发送至订阅客户端，发送完后断开连接；同时它将消息转发给通知代理或接收通知代理发送来的消息；

通知事件发布者，主要负责将自己要发布的主题请求注册至通知代理，还负责来自于资源回调接口的通知事件的发送；

主题管理模块的结构图如图3所示，主题管理负责主题的组织和管理，包括主题表达式解析引擎、主题表达式解析器、主题表达式解析注册中心和主题容器；主题表达式解析引擎从通知代理接收主题请求中的表达式，并根据表达式类型从主题表达式解析器注册中心中查找对应的主题表达式解析器，主题表达式解析引擎调用所查找到的主题表达式解析器进行主题表达式解析，在解析过程中主题表达式解析器将查询主题容器，主题容器采用树状结构保存主题信息；

订阅管理器的数据结构示意图如图4所示，订阅管理器用于管理所有来自于通知代理中的主题订阅信息，订阅管理器保存了所有的主题到订阅队列的映射，并根据通知代理发送过来的订阅消息，对订阅队列进行增加或删除，以实现订阅管理功能。

TopicSet池的数据结构示意图如图5所示，TopicSet池，用于保存发布者到自己所支持的主题列表TopicSet的映射关系，通过对主题列表的增加或删除来实现发布者所支持主题的管理。

图6展示了资源管理模块的体系结构图，资源管理模块部署在服务层，将资源状态封装成基于集合论与数理逻辑的对象结构Metaset；将用户对资源的访问转换成对使用Metaset描述的对象的操作，通过对Metaset对象的处理产生返回的相关事件的Metaset表示，再将Metaset表示通过资源回调接口送至通知处理模块。资源管理模块中将用户对资源的访问转换成对Metaset封装对象结构的操作的方法，包括两个部分：

(1)资源状态获取算法，通过对Metaset对象的操作得到资源的一个或者多个属性的算法；

(2)资源状态修改算法，通过对Metaset对象的操作来删除、插入和更新资源的属性。

其具体实施步骤为：

第一步：将资源状态封装成一种可以解析操作XML的基于集合论与对象结构Metaset；

资源的状态被表示成资源属性文档，每一个资源属性文档都可被表示成一个XML文档，XML文档可以被封装成Metaset对象，将资源属性文档表示成Metaset对象就完成了对资源状态的封装，对资源状态的封装简化了资源状态的各项维护工作。

第二步：将用户对资源的访问转换成对使用Metaset描述的对象的操作包括两部分：

(1)资源状态获取算法

资源状态获取算法负责根据用户的SOAP报文在系统内部查找ACT-Resource的属性值。可以一次只查找有状态资源一个属性的值，也可以一次查找有状态资源多个属性的值。下面给出具体的获取单个资源属性的算法。对于一次获取多个资源属性的算法，在此不再赘述。

假设S为资源属性文档，S_p为路径集合，x为待查找路径，则使用Metaset表示该算法的形式语义如下所示：

$\&Exists;x=e_0\backslash e_1\backslash ...\backslash \mathrm{qname}\&Element;S_p,\mathrm{\&lambda;}(S,x)\&RightArrow;S_s\left(\mathrm{path}\right),\mathrm{\&delta;}\left(S_s\left(\mathrm{path}\right)\right)\&RightArrow;\mathrm{value}$

当收到来自客户端的请求之后，首先从中解析出其请求的有状态资源的属性名称，如果该过程无误，则可进行下一步，如果出错则表示请求报文有问题或被损坏，构造并发送一个出错报文返回给用户。如果名称解析无误，则根据用户的请求创建一个资源上下文，并从中解析出资源的标识符。然后根据该资源标识符定位到系统中的资源实例，获取其资源属性文档。将资源属型文档中的每一个属性名称与用于请求的名称进行匹配，如果成功则返回该属性的值，如果全部失败则构造出错报文返回给用户。下面给出具体的资源状态获取算法。

资源状态获取算法中，资源状态的获取流程如下所示：

a.解析请求SOAP报文；

b.获取对应资源管理器，若为空则返回错误信息

c.从资源管理器中获取资源实例，若为空则返回错误信息

d.从获得的资源对象里查询请求的资源状态并包装成SOAP报文返回给客户。

(2)资源状态修改算法如下所示：

对资源属性的修改操作主要有三种：删除、插入和更新。删除表示删除资源实例的一个或多个属性，插入表示向资源属性文档中插入新的属性，更新则表示修改某个或多个资源属性的值。

设S为资源属性文档，S_p为路径集合，setPath是待查找路径，S_request是请求报文，则使用Metaset表示该算法的形式语义如下所示。

$\left\{\begin{array}{c}(\mathrm{\&delta;}\left(\mathrm{\&lambda;}(S_{\mathrm{request}},\mathrm{oppath})\right)\&RightArrow;\mathrm{op})\&Element;\{\mathrm{Insert},\mathrm{Update},\mathrm{Delete}\}\\ \mathrm{op}=\mathrm{Insert}\end{array}\right\}\&RightArrow;$

$+(S,\mathrm{setPath},\mathrm{op}.\mathrm{value})$

$\left\{\begin{array}{c}(\mathrm{\&delta;}\left(\mathrm{\&lambda;}(S_{\mathrm{request}},\mathrm{oppath})\right)\&RightArrow;\mathrm{op})\&Element;\{\mathrm{Insert},\mathrm{Update},\mathrm{Delete}\}\\ \mathrm{op}=\mathrm{Delete}\end{array}\right\}\&RightArrow;$

$\mathrm{\&sigma;}(S_{\mathrm{request}},\mathrm{oppath}{,}^{\&prime;\&prime;}\mathrm{ResourcePrope}{\mathrm{rty}}^{\&prime;\&prime;})\&RightArrow;v_{\mathrm{deletename}}$

$-\left({S,\mathrm{setPath},v}_{\mathrm{deletename}}\right)$

$\left\{\begin{array}{c}(\mathrm{\&delta;}\left(\mathrm{\&lambda;}(S_{\mathrm{request}},\mathrm{oppath})\right)\&RightArrow;\mathrm{op})\&Element;\{\mathrm{Insert},\mathrm{Update},\mathrm{Delete}\}\\ \mathrm{op}=\mathrm{Update}\end{array}\right\}\&RightArrow;$

$\&DownArrow;(S,\mathrm{setPath},\mathrm{op}.\mathrm{value})$

当收到来自客户端的请求之后，首先从中解析出请求的具体操作，如果是Delete则执行相应的删除操作，是Insert则执行相应的插入操作，是Update则执行相应的修改操作。对于Delete操作，首先解析出要删除的属性名称，然后将对应的属性从资源属性文档中删除；对于Insert操作，则直接将待插入的属性名及值插入到资源属性文档中；对于Update操作，首先解析出待修改的属性名及值，然后根据其更新资源属性文档。最后将执行的结果返回给客户端，通知客户此次操作执行成功或失败。

资源状态修改算法中，具体的资源状态修改流程如下：

a.解析请求SOAP报文

b.获取对应资源管理器，若为空则返回错误信息

c.从资源管理器中获取资源实例，若为空则返回错误信息

d.分析请求的操作如果是更新操作则创建对应的操作适配器对资源实例进行更新处理，如果是销毁操作则创建对应的销毁操作适配器对资源实例进行销毁处理，其他的操作流程类似。

e.将对资源实例的处理数据包装成SOAP报文，返回给请求者。

第三步骤，通过对Metaset封装对象结构的操作产生返回的SOAP报文，即根据要返回的报文格式，组成相应的Metaset对象；在容器的消息层，将这个Metaset对象变成文本形式发送给请求方。

如图1所示，客户端组件包括订阅客户端和监控客户端，订阅客户端通过SOAP报文与通知处理模块交互，完成订阅消息的构造、订阅请求消息的发送及订阅响应的接收；监控客户端用于监控通知处理模块所支持的主题信息，将主题信息通过网页的形式显示给最终的用户。

如图7所示，阅客户端的实现为：包括通知订阅组件和通知监听组件，通知订阅组件完成订阅消息的构造、订阅请求消息的发送及订阅响应消息的接收，通知监听组件监听通知处理模块发送过的通知事件消息；通知订阅组件根据通知处理模块发送来的订阅主题的主题表达式、端点引用信息构造订阅请求消息，然后与通知处理模块建立连接，把订阅请求消息发送至通知处理模块，通知处理模块处理完毕订阅请求消息后，将订阅响应消息返回给订阅客户端，订阅客户端根据返回订阅响应消息来判断订阅是否成功，并启动通知监听组件，通知监听组件监听通知代理发送过的通知事件消息。

如图8所示，监控客户端的实现为：包括数据获取组件和数据显示组件，数据获取组件负责向通知处理模块请求主题信息并对其进行解析、恢复主题树的组织结构，然后交给数据显示组件进行显示。

如图9所示，基于集合理论的资源通知处理机制的处理方法如下：

(1)当资源管理模块实例化一个资源时，将每个资源封装为主题，通过资源回调接口发送给通知处理模块，由通知处理模块进行主题注册；

(2)通知处理模块接收到订阅客户端的订阅请求后，将该订阅信息转交给订阅管理，实现主题订阅；

(3)当资源管理模块对资源状态进行更改后，通过资源回调接口将通知事件进行封装后交给通知处理模块，通知处理模块再将此通知事件转给所有订阅该主题的订阅者；

(4)当资源管理模块销毁资源时，将通过资源回调接口将资源销毁事件封装后交给通知处理模块，由通知处理模块实现主题的销毁；

(5)重复执行步骤(1)~(4)，实现对不同资源的通知处理。

图10展示了通知主题的发布过程。即当资源管理模块实例化一个资源时，通过资源对应的资源回调接口构造主题发布请求，向通知代理进行注册，其处理方法如下：

(a)资源管理模块创建资源后调用资源回调接口，资源回调接口根据资源的配置信息实例化通知事件发布者；

(b)通知事件发布者根据资源的部署信息构造主题发布请求并发送到通知代理；

(c)通知代理根据主题发布请求中的主题信息，向主题管理模块中添加主题；

(d)通知代理向TopicSet池中添加该发布者支持的主题列表。

图11展示了通知主题的订阅过程。当资源被实例化后，它所对应的主题信息通过通知代理进行发布，订阅者根据自己的需要订阅感兴趣的主题，构造相应的订阅请求交给通知代理，通知代理对其进行处理。其处理方法如下：

(a)订阅者的订阅请求经过传输层和消息层的处理后交给消息派发器，消息派发器根据请求的类型交给通知代理；

(b)通知代理对订阅请求中的主题表达式进行解析执行，得到主题表达式对应的主题数组；

(c)如果订阅请求中指定了通知的发布者，通知代理根据发布者的标识从TopicSet池中取得其支持的主题列表；

(d)通知代理对解析后的主题数组进行过滤，得到订阅这订阅并且发布者支持的主题；

(e)通知代理根据订阅请求创建其对应的订阅上下文，然后通过订阅管理器添加到主题对应的订阅队列中：如果订阅管理器中已经存在该主题的订阅队列，获得该订阅队列并把该订阅上下文添加到队列末尾；否则，创建一个订阅队列，并添加该订阅上下文；

(f)通知代理创建订阅响应，交给通知消息派发器，然后经过传输层和消息层返回给订阅客户端。

图12展示了通知消息的发送过程。当资源的状态被更改后，会调用相应的回调接口，将事件进行封装后交给通知代理，通知代理对其进行处理后将事件内容转发给所有的订阅者。其处理方法如下所示：

(a)资源管理模块中的资源更改后调用资源回调接口，资源回调接口将事件的内容(如资源属性更改前后的属性值)告知通知事件发布者；

(b)通知事件发布者根据事件的内容构造对应的通知消息(包括通知的主题、发布者和属性更改前后的属性值)

(c)通知代理收到通知消息后先对通知消息中的主题表达式进行解析执行，得到对应的主题数组；

(d)通知代理向TopicSet池中查询该发布者所支持的主题列表，然后对上一步得到的主题数组进行过滤，得到通知消息对应的并且该发布者支持的主题数组；

(e)通知代理向订阅管理器查询主题对应的订阅队列；

(f)通知代理按照订阅列表一一将交给通知消息派发器中的并发发送模块；

(g)并发发送模块将通知消息并发发送给处于监听状态的通知订阅者。

Claims (9)

1.一种基于集合理论的资源通知处理机制的处理系统，其特征在于包括：通知处理模块、资源管理模块、客户端组件和资源回调接口，其中：

通知处理模块，部署在服务层，实现发布或订阅信息的管理、主题的管理、完成发布或订阅流程的实现，其通过资源回调接口与资源管理模块完成相关事件的交互，根据资源管理模块送来的用户的订阅记录，将事件发送给客户端组件的订阅客户端中订阅此事件的用户；

资源管理模块，部署在服务层，将资源状态封装成基于集合论与数理逻辑的对象结构Metaset；所述Metaset是一个以集合论和数学逻辑理论为工具、以Services集为对象、以元操作为运算符的理论体系，用以构造网格计算环境下的数学模型，该数学模型将服务的资源属性文档定义为五元组Doc_wrpd＝<S_en，S_ev，S_an，S_av，S_wrpd>，其中S_en是资源属性文档元素名集合，S_ev是资源属性文档元素值的集合，S_an是资源属性文档那个属性名集合，S_av是资源属性文档属性值的集合，S_wrpd是XML语言表示的资源属性文档的描述集合，其元素是Services集；将用户对资源的访问转换成对使用Metaset描述的对象的操作，通过对Metaset对象的处理产生返回的相关事件的Metaset表示，再将Metaset表示通过资源回调接口送至通知处理模块；

客户端组件包括订阅客户端和监控客户端，订阅客户端通过SOAP报文与通知处理模块交互，完成订阅消息的构造、订阅请求消息的发送及订阅响应的接收；监控客户端用于监控通知处理模块所支持的主题信息，将主题信息通过网页的形式显示给最终的用户；

资源回调接口，把资源管理模块中资源发生变化的事件进行封装，发送给通知处理模块。

2.根据权利要求1所述的基于集合理论的资源通知处理机制的处理系统，其特征在于：所述的资源管理模块中将用户对资源的访问转换成对Metaset封装对象结构的操作的方法，包括两个部分：

(1)资源状态获取算法，通过对Metaset对象的操作得到资源的一个或者多个属性的算法；

(2)资源状态修改算法，通过对Metaset对象的操作来删除、插入和更新资源的属性。

3.根据权利要求1所述的基于集合理论的资源通知处理机制的处理系统，其特征在于：所述的通知处理模块包括主题管理、通知代理、通知消息派发器、通知发布者、订阅管理器、主题列表TopicSet池，其中：

主题管理，负责主题的组织和管理，包括主题表达式解析引擎、主题表达式解析器、主题表达式解析器注册中心和主题容器；主题表达式解析引擎从通知代理接收主题请求中的表达式，并根据表达式类型从主题表达式解析器注册中心中查找对应的主题表达式解析器，主题表达式解析引擎调用所查找到的主题表达式解析器进行主题表达式解析，在解析过程中主题表达式解析器将查询主题容器，主题容器采用树状结构保存主题信息；

通知代理，负责处理订阅请求、发布主题请求和通知发布请求，同时维护主题列表TopicSet池；通知代理接收通知消息派发器转发过来的主题订阅请求，将此请求转发给订阅管理器，完成主题订阅功能，通知代理还根据通知发布者提供的通知事件信息向订阅管理器查找订阅此事件的用户，再将此事件通过通知消息派发器发送给所查找到的用户；通知代理接收通知发布者的主题发布请求，将此主题发布请求发送至主题列表TopicSet池，实现主题请求的发布；通知代理同时还将主题发布请求发送给主题管理，进行主题表达式的解析；

通知消息派发器，将通知事件消息主动发送至订阅客户端，与订阅客户端建立连接，发送完后断开连接；同时它将消息转发给通知代理或接收通知代理发送来的消息；

通知发布者，主要负责将自己要发布的主题请求注册至通知代理，还负责来自于资源回调接口的事件的发送；

订阅管理器，用于管理所有来自于通知代理中的主题订阅信息，订阅管理器保存了所有的主题到订阅队列的映射，并根据通知代理发送过来的订阅消息，对订阅队列进行增加或删除，以实现订阅管理功能；

TopicSet池，用于保存发布者到自己所支持的主题列表TopicSet的映射关系，通过对主题列表的增加或删除来实现发布者所支持主题的管理。

4.根据权利要求1所述的基于集合理论的资源通知处理机制的处理系统，其特征在于：所述订阅客户端的实现为：包括通知订阅组件和通知监听组件，通知订阅组件完成订阅消息的构造、订阅请求消息的发送及订阅响应消息的接收，通知监听组件监听通知处理模块发送过的通知事件消息；通知订阅组件根据通知处理模块发送来的订阅主题的主题表达式、端点引用信息构造订阅请求消息，然后与通知处理模块建立连接，把订阅请求消息发送至通知处理模块，通知处理模块处理完毕订阅请求消息后，将订阅响应消息返回给订阅客户端，订阅客户端根据返回订阅响应消息来判断订阅是否成功，并启动通知监听组件，通知监听组件监听通知处理模块发送过的通知事件消息。

5.根据权利要求1所述的基于集合理论的资源通知处理机制的处理系统，其特征在于：所述的监控客户端的实现为：包括数据获取组件和数据显示组件，数据获取组件负责向通知处理模块请求主题信息并对其进行解析、恢复主题树的组织结构，然后交给数据显示组件进行显示。

6.一种基于集合理论的资源通知处理机制的处理方法，其特征在于包括以下步骤：

(1)当资源管理模块实例化一个资源时，将每个资源状态封装成基于集合论与数理逻辑的对象结构Metaset；通过资源回调接口发送给通知处理模块，由通知处理模块进行主题注册；所述Metaset是一个以集合论和数学逻辑理论为工具、以Services集为对象、以元操作为运算符的理论体系，用以构造网格计算环境下的数学模型，该数学模型将服务的资源属性文档定义为五元组Doc_wrpd＝<S_en，S_ev，S_an，S_av，S_wrpd>，其中S_en是资源属性文档元素名集合，S_ev是资源属性文档元素值的集合，S_an是资源属性文档那个属性名集合，S_av是资源属性文档属性值的集合，S_wrpd是XML语言表示的资源属性文档的描述集合，其元素是Services集；

(2)通知处理模块接收到订阅客户端的订阅请求后，将该订阅信息转交给订阅管理器，实现主题订阅；

(3)当资源管理模块对资源状态进行更改后，通过资源回调接口将通知事件进行封装后交给通知处理模块，通知处理模块再将此通知事件转给所有订阅该主题的订阅者；

(4)当资源管理模块销毁资源时，将通过资源回调接口将资源销毁事件封装后交给通知处理模块，由通知处理模块实现主题的销毁；

(5)重复执行步骤(1)～(4)，实现对不同资源的通知处理。

7.根据权利要求6所述的基于集合理论的资源通知处理机制的处理方法，其特征在于：所述的步骤(1)中，当资源管理模块实例化一个资源时，通过资源对应的资源回调接口构造主题发布请求，向通知代理模块进行注册，其注册方法如下：

(11)资源管理模块创建资源后调用资源回调接口，资源回调接口根据资源的配置信息构造资源创建事件发送给通知发布者；

(12)通知发布者根据资源回调接口发送来的资源创建事件构造主题发布请求并发送到通知代理；

(13)通知代理根据主题发布请求中的主题信息，向主题管理模块中添加主题，主题管理模块将根据主题信息进行主题注册；

(14)通知代理向主题列表TopicSet池中添加该发布者支持的主题列表。

8.根据权利要求6所述的基于集合理论的资源通知处理机制的处理方法，其特征在于：所述步骤(3)中当资源管理模块对资源状态进行更改后，通过资源回调接口将通知事件进行封装后交给通知处理模块，通知处理模块再将此通知事件转给所有订阅该主题的订阅者，其处理步骤如下：

(31)当资源发生变化时，资源回调接口会将根据发生变化的资源的信息构造资源变化通知事件发送到通知发布者；

(32)通知发布者接收到资源变化事件后，根据其主题构造相应的通知消息；

(33)通知发布者将构造的通知消息发送给与之关联的通知代理；

(34)通知代理收到通知事件后先对通知事件中的主题表达式进行解析执行，得到对应的主题数组和通知发布者信息；

(35)通知代理在TopicSet池中查询该通知发布者所支持的主题列表，然后对上一步得到的主题数组进行匹配，得到通知事件对应的并且该通知发布者支持的主题数组；

(36)通知代理向订阅管理器查询上步匹配后的主题对应的订阅队列；

(37)通知代理按照订阅列表将通知事件和订阅者信息交给通知消息派发器的并发发送模块；

(38)通知消息派发器的并发发送模块根据订阅者的信息将通知事件并发发送给处于监听状态的通知订阅者。

9.根据权利要求6所述的基于集合理论的资源通知处理机制的处理方法，其特征在于：所述步骤(4)中当资源管理模块销毁资源时，将通过资源回调接口将资源销毁事件封装后交给通知处理模块，由通知处理模块实现主题的销毁，其处理步骤如下：

(41)资源管理模块销毁资源后调用资源回调接口，资源回调接口构造资源销毁事件发送给通知发布者；

(42)通知发布者在接收到的资源销毁事件中加入发布者对应的主题信息，并将修改后的事件发送到通知代理；

(43)通知代理根据资源销毁事件中的主题信息发送给主题管理模块，主题管理模块将根据主题信息销毁对应的主题；

(44)通知代理根据资源销毁事件中的主题信息在TopicSet池中销毁对应的主题。

Images