CN101291337A - 一种网格资源管理系统及管理方法 - Google Patents

Abstract

本发明揭示了一种网格资源管理系统，该系统包括网格顶层的应用程序层、网格底层的监控管理软件层；所述系统还包括Web服务层、访问中间件层；应用程序层、Web服务层、访问中间件层、监控管理软件层依次连接；Web服务层用于提供网格资源发现服务、网格资源历史状态服务、及网格资源调度服务；对应的包括网格资源发现模块、网格资源历史状态模块、及网格资源调度模块；访问中间件层提供一与平台无关的资源管理接口，用于实现网格底层监控管理软件层与Web服务层的数据访问。本发明网格资源管理系统通过设置统一的管理接口，能适应交通网格中大量动态资源的发现和管理工作。

Description

一种网格资源管理系统及管理方法

技术领域

本发明属于网络与信息技术领域，涉及一种网格资源管理系统，尤其涉及一种基于WSRF与语义网技术的网格资源管理系统，此外，本发明还涉及上述管理系统的管理方法。

背景技术

网格利用高速因特网把分布于不同地理位置的计算机、数据库、存储器和软件等资源连成整体，就像一台超级计算机一样为用户提供一体化信息服务。网格技术充分实现了资源共享，具有成本低、效率高、使用更加方便等优点。由于网格自身环境中的资源特点使得网格环境下的资源管理成为一个很有挑战性的问题。如何在大规模资源共享环境中进行资源定位，特别是在网格资源和用户规模巨大、资源具有异质性且属性多样、资源所有者的资源管理策略又各不相同的情况下，网格资源发现问题面临更加多的困难；同时，由于网格环境下资源缺乏统一的命名机制，部分资源属性又经常性的变化(如CPU负载、可用空间大小甚至是软件类型)，部分资源可能主动或由于错误退出网格环境，更增添了资源发现的复杂度。

正是由于上述实际情况，在交通网格环境中资源具有较强的分布性，异构性和动态性的条件下，寻找一种可以适应交通网格环境的资源管理模型成为必然。

发明内容

本发明所要解决的技术问题是：提供一种基于WSRF与语义网技术的网格资源管理系统。

为解决上述技术问题，本发明采用如下技术方案：

一种网格资源管理系统，该系统包括网格顶层的应用程序层、网格底层的监控管理软件层；所述系统还包括Web服务层、访问中间件层；应用程序层、Web服务层、访问中间件层、监控管理软件层依次连接；Web服务层用于提供网格资源发现服务、网格资源历史状态服务、及网格资源调度服务；对应的包括网格资源发现模块、网格资源历史状态模块、及网格资源调度模块；访问中间件层提供一与平台无关的资源管理接口，用于实现网格底层监控管理软件层与Web服务层的数据访问。

作为本发明的一种优选方案，所述网格系统中的所有资源均以虚拟组织的形式进行管理，在每个虚拟组织内部存在一个或多个集中式的资源注册结构，即存在中心服务器存储共享资源信息，所有可用资源信息被聚集在该中心服务器上。单中心服务器间模型采用分布式资源发现形式。

作为本发明的一种优选方案，所述资源按资源所有者、或/和资源类型、或/和资源性质或/和管理策略标准分组；组与组之间则通过中心服务器采用P2P的资源定位方式连接入网格，以适应大规模的动态网格环境。

作为本发明的一种优选方案，所述网格资源发现模块包括查询服务单元、通知服务单元、语义查询单元；所述查询服务单元、通知服务单元分别与语义查询单元连接；查询服务单元、通知服务单元连接Web服务层，语义查询单元连接访问中间件层。

利用上述的网格资源管理系统进行网格资源管理方法，所述方法包括语义查询步骤：

步骤1A、获取从网格资源状态采集软件收集的信息；

步骤1B、依据步骤1A所获取的信息类型，将不同的信息内容转换成相应的语义数据；

步骤1C、将步骤1B得到的所有语义数据保存在语义仓库中，并提供相应的基本语义查询接口；

步骤1D、将复杂的语义查询包装成简单的查询接口，简化语义数据的查询过程；

步骤1E、提供对语义数据变化的通知预订功能；

步骤1F、提供对网格资源历史数据的查询功能；

步骤1G、依据步骤1C所保存的网格资源语义信息作出网格资源调度决定进行网格资源的调度工作。

作为本发明的一种优选方案，所述网格资源管理方法包括语义信息转化步骤，该步骤根据获取信息的不同信息格式(如：XML格式，纯文本格式，二进制格式等)和不同信息源类型(如：数据库，文件等)组装成不同的数据源插件，对不同的原始数据进行语义数据的提炼；所述语义信息转化步骤包括：

步骤2A、选择不同的信息格式和不同的数据源组装成数据源插件；

步骤2B、利用数据源插件将相应的数据源数据提炼成语义数据；

步骤2C、将提炼出的语义数据保存至语义查询服务的语义仓库中。

作为本发明的一种优选方案，所述网格资源管理方法包括语义数据变化的通知预订步骤，该步骤提供给用户注册数据变化通知的功能，从而避免了用户为了获得所关心的数据状态的变化而反复查询的情况；所述语义数据变化的通知预订步骤包括：

步骤3A、用户定制所关心的数据状态变更通知；

步骤3B、通知服务告知语义查询服务在数据状态变更时通知自己；

步骤3C、语义查询服务在通知服务所关心的资源发生变化时通知通知服务；

步骤3D、通知服务再通知用户其所关心的资源状态已发生变化。

作为本发明的一种优选方案，所述网格资源管理方法包括网络资源调度步骤，该步骤利用语义查询服务中所保存的网格资源状态信息进行网格任务调度决策，并完成调度工作；所述网络资源调度步骤包括：

步骤4A、用户将任务提交给网格资源调度服务；

步骤4B、网格资源服务根据用户对任务资源的要求在语义数据查询服务中查找符合要求的资源列表；

步骤4C、在符合要求的资源列表中根据特定的资源调度算法进行资源调度决策；

步骤4D、将网格任务调度至资源调度决策所选择出的资源上；

作为本发明的一种优选方案，所述网格资源管理方法包括网络资源调度步骤，具体包括：

网格任务管理程序调用任务调度服务的任务调度接口将具体的计算任务分配给计算节点；

任务调度服务根据实际的任务调度请求，查询语义查询服务，以确定该具体任务所需的资源时候已经就绪；

当任务所需资源就绪后，任务调度服务调用访问中间层的任务调度接口；

相应的任务调度接口调用实际的本地任务调度程序完成任务的调度和运行；

在任务运行期间，本地任务调度程序通过访问中间层的任务调度接口和任务调度服务与最终发起任务分配的网格资源调度模块进行通讯，以告知网格资源调度模块任务的具体执行情况所述网格资源调度模块可以随时通过调用任务调度服务的相应接口中止或者挂起任务的执行过程。

本发明的有益效果在于：本发明网格资源管理系统通过设置统一的管理接口，能适应交通网格中大量动态资源的发现和管理工作。

附图说明

图1为本发明基于WSRF的网格资源管理系统的组成示意图。

图2为整体资源组织结构图。

图3为语义查询服务的流程图。

图4为查询服务的流程图。

图5为通知服务的流程图。

图6为资源日志服务请求步骤的流程图。

图7为访问中间层数据源插件步骤的流程图。

图8为虚拟组织内资源节点注册流程图。

图9为中心服务器注册过程流程图。

图10为中心服务器注册过程流程图。

图11为资源查询过程流程图。

图12为任务调度过程流程图。

图13为虚拟资源节点下的任务调度过程流程图。

具体实施方式

下面结合附图详细说明本发明的优选实施例。

请参阅图1，本发明揭示了一种网格资源管理系统，该系统包括网格顶层的应用程序层、网格底层的监控管理软件层(如：Ganglia、Hawkeye、任务调度器等)；所述系统还包括Web服务层、访问中间件层；应用程序层、Web服务层、访问中间件层、监控管理软件层依次连接。

Web服务层用于提供网格资源发现服务、网格资源历史状态服务、及网格资源调度服务；对应的包括网格资源发现模块、网格资源历史状态模块、及网格资源调度模块。所述网格资源发现模块包括查询服务单元、通知服务单元、语义查询单元；所述查询服务单元、通知服务单元分别与语义查询单元连接；查询服务单元、通知服务单元连接Web服务层，语义查询单元连接访问中间件层。

访问中间层是该系统中负责网格底层监控管理软件与模型核心组件实现数据访问的关键部分。由于网格资源的多样性和复杂性，一个成功的资源管理系统需要收集和发布多种资源属性，访问中间层可以提供一套统一的且又平台无关资源管理接口，使网格资源管理系统方便的采集网格底层监控管理软件所产生的网格资源状态信息成为可能。

请参阅图2，在整个基于WSRF的网格资源管理系统中，资源采取了集中式与分布式相结合的资源组织形式。所述网格系统中的所有资源均以虚拟组织(Virtual Organization，VO)的形式进行管理，在每个虚拟组织内部存在一个或多个集中式的资源注册结构，即存在中心服务器存储共享资源信息，所有可用资源信息被聚集在该中心服务器上。单中心服务器间模型采用分布式资源发现形式。所述资源按资源所有者、或/和资源类型、或/和资源性质或/和管理策略标准分组；组与组之间则通过中心服务器采用P2P的资源定位方式连接入网格，以适应大规模的动态网格环境。整体资源组织结构如图2所示，图中标记为C的节点是虚拟组织中作为中心服务器的资源节点。

以下介绍本系统涉及的服务及步骤。

(1)语义查询服务

语义查询服务是整个基于WSRF的网格资源管理系统的核心服务，在系统中起到承上启下的关键作用。由于网格资源类型的多样性和复杂性，一个成功的网格资源发现模型需要收集和发布多种资源属性，需要理解各类网格资源组织结构，然而网格的动态性决定了网格的底层资源组织结构是多变的，这就使得网格资源管理系统的通用性与该模型对网格资源组织结构的适应能力成为一对不可调和的矛盾。

造成这对矛盾的主要原因是，网格管理系统需要了解网格底层结构，而这种了解大大减少了网格资源管理系统的通用性。当需要网格资源管理系统回答诸如：“当用户执行某个任务时，请告诉我那些网格节点会参与该任务的执行”之类的问题时，这对矛盾显的尤为突出。如果使用目前的技术(比如：关系型数据库，普通的网格管理系统)去回答这类问题，用户需要编写大量的代码来使得网格资源管理系统明白网格的底层结构，比如：网格中各个节点的类型、网格节点的层次关系(谁是谁的父节点)、各个网格节点的技术参数和状态、任务是如何在网格环境中传递的。但这样会使得网格资源管理系统成为一个只能工作在特定网格环境中的定制的系统。当网格环境发生改变时，用户不得不从新修改代码，从新编译程序。如果该网格管理系统被部署在很多网格节点上，那用户还需要进行繁琐而有容易产生错误的系统部署工作。

如果使用语义网技术，网格资源管理系统可以变得更“轻”，即网格资源管理系统本身并不需要了解网格的具体底层结构，而将这类本来需要写在程序中的“语义”放到数据中。也就是说网格资源管理系统通过读取语义数据，理解语义数据中的含义，从而了解网格的底层结构。使用这种方法，如果网格底层结构发生改变时，用户只需要一次性的改变数据，而不用从新修改，编译和部署新的系统。

本文所提出的基于WSRF的网格资源管理系统中的语义查询服务主要包括两个子模块：语义查询接口和语义数据库，如图3。

语义数据库主要用来接受和保存访问中间层收集并提炼出的语义数据。语义数据库中所有数据均以三元组形式保存在内存中，同时语义数据库提供数据的修改接口，方便动态数据(如：CPU利用率、空闲内存数等)的实时修改。

语义查询接口主要负责与语义查询服务的上层服务进行交互，将语义数据库中的语义数据作为源数据，运行上层服务所提供的SPARQL，并将查询结果整理后返回。

(2)查询服务

语义查询服务虽然提供非常强大的语义查询能力，但是却需要使用者熟悉SPARQL和语义数据的具体内容，这对普通使用者来说是一个不小的挑战，同时也会降低上层网格应用程序的通用性。为了解决这个问题，本文提出的基于WSRF的网格资源管理系统特别在语义查询服务上层提供了一组查询服务。该组服务包装了网格资源管理中的常用查询(如：资源状态查询、资源结构查询等)，从而避免了上层网格应用程序使用相对较为复杂的SPARQL进行常用的数据查询。

由于所需支持查询的多样性，查询服务包括了一组提供不同子查询功能的子服务。目前本文所提出的模型只提供了：资源状态查询服务(Resource Status Service)和资源图形查询服务(Resource Graph Finder Service)两类。

一次典型的查询服务使用过程如图4示：

首先，上层网格应用程序调用查询服务接口。比如如果用户需要知道某个VO的具体资源组织形式(例如：资源的隶属关系、资源的类型和资源的基本信息)，该用户就需要调用查询服务中的资源图形查询服务，同时提供相应的参数。资源图形查询服务在收到用户请求后会将该请求转换成相应的SPARQL再提交给语义查询服务查询，并将语义查询服务返回的结果整理成接口约定的返回格式返回给用户。

(3)通知服务

资源通知服务是本文所提出的基于WSRF的网格资源管理系统中的一个辅助Web服务。该服务利用Web Service Notification规范所提供的事件通知机制，为上层网格应用程序提供基于条件的网格资源状态提醒服务。

由于网格资源的动态性，在每次任务调度过程中，无法保证所需资源在任务调度时是可使用的。在没有通知服务的情况下，用户可能需要自己定期查询所需资源状态(如图5(a)所示)，直到感兴趣的资源就绪为止，这么做首先会增加用户端的工作量，其次这种方法会增加网格信息服务的请求流量，从而严重影响网格信息服务的效率。

使用通知服务后，用户不需要频繁的向语义查询服务或查询服务请求资源状态信息(如图5(b)所示)。用户只需要向通知服务发送一个订阅(subscribe)请求，并给出条件。语义查询服务在每次资源状态发生改变时都会告知通知服务，通知服务在收到语义查询服务的资源状态改变的消息后，会自动判断用户订阅的通知条件是否满足，如果条件被满足，通知服务会通知用户所需资源已经可用。

(4)资源日志服务

资源日志服务是基于WSRF的网格资源管理系统所提供的第二类服务类型。改功能相对独立于其他主要的Web服务，也不是每个网格节点所必须部署的Web服务。该服务主要提供对网格资源的历史信息的查询和数据统计功能，一般主要部署在主要的网格节点上(如：中心服务器)，从而方便资源使用者或网格管理员对该资源节点的历史数据进行查询、分析和参考。

资源日志服务主要利用访问中间层所提供的数据库访问接口对保存在数据库中的网格状态历史信息进行分析和挖掘，并以图形，表格等方式返回给上层网格应用程序(如图6)。该服务所依赖的历史数据主要是在访问中间层收集提炼语义查询服务所需数据时保存入数据库的。

(5)访问中间层

访问中间层是本文所提出的基于WSRF的网格资源管理系统中负责网格底层监控管理软件与模型核心组件实现数据访问的关键部分。由于网格资源的多样性和复杂性，一个成功的资源管理系统需要收集和发布多种资源属性，访问中间层可以提供一套统一的且又平台无关资源管理接口，使网格资源管理系统方便的采集网格底层监控管理软件所产生的网格资源状态信息成为可能。

访问中间层解决网格底层数据异构性的主要方式是使用数据源插件技术。该技术主要通过一套统一的接口框架以及大量的符合框架规范的数据源插件构成模型的访问中间层。

图7显示的是两个网格中间层数据源插件：

数据源1(Data source 1)在网格中间层中有自己对应的数据源插件1(Data Source 1Plug-in)，该数据源插件定期向数据源1请求数据并将返回数据转换成语义数据提交给语义查询服务(3.1)，同时由于网格资源日志服务的需要，数据源插件1还将该部分信息保存入数据库。数据源2(Data Source 1)的数据不需要在数据库中保存，所以数据插件2(Data Source2 Plug-in)在从数据源2中获得有用信息后仅将该信息转换成语义数据提交给语义查询服务(3.2)。

除了为上层语义查询服务提供数据支持外，访问中间层还为资源日志服务提供访问底层数据库的接口以及调用本地网格资源调度程序的接口。

总之，访问中间层是本文所提出模型中确保网格底层数据无关性的关键模块，也是上层Web服务正常运行的保障。

(6)网格资源发现

由于在基于WSRF的网格资源管理系统中使用了集中式和分布式相结合的资源发现机制，资源节点加入和离开网格环境也就存在着两种情况。

当某虚拟组织内的资源节点需要加入网格环境时，资源节点根据管理员手工配置的资源节点层次关系向其上层节点发送更新自己及其下层节点的资源状态请求。每次状态更新都有生命周期，因而每个资源节点都需要不断的定期更新在其上层节点中的自己的状态信息。当节点发生断电或系统崩溃时，该节点的信息将因无法得到更新而很快过期。若节点需要主动离开网格环境时，节点也可以主动向其上层节点发送离开消息，提示上层节点取消自己的状态信息。虚拟组织内资源节点的注册流程图如图8。

当某个中心服务器或者某组集中式管理的资源需要加入网格环境时，模型采用一种在点对点系统中经常使用的软状态协议，中心服务器使用该协议加入网格环境。具体步骤如图9所示：1、VO2中心服务器联系全局注册服务器；2、全局注册服务器返回现有点对点网络中已注册的VO1中心服务器地址；3、VO2中心服务器向VO1中心服务器发送加入点对点网络请求；4、VO1中心服务器在收到请求后将该节点地址加入自己的邻居列表中，并发送确认消息；5、VO2中心服务器在接受到确认消息后将VO1中心服务器地址也加入到自己的邻居列表中，至此完成点对点网络的加入工作。

点对点网络中的各节点也需要定期发送在线通知至自己邻居列表中的其他节点，从而不断更新他们各自的邻居列表，如果收到不在邻居列表中的节点的信息，该陌生节点也会被加入到邻居列表中。同样的，当某中心服务器由于故障或者需要主动退出网格环境时，只需要停止发送在线通知即可离开网格环境。图10为中心服务器的注册流程图。

基于WSRF的网格资源管理系统的资源查询过程也体现了集中式与分布式相结合的特点。当一个资源查询请求产生后，请求会被传递至各组织内的中心服务器，中心服务器将首先在自己的网格资源中查询所要找的资源，如果找到所请求资源，则将查询结果返回给查询节点，一次查询结束，如图11(1)所示。

如果中心服务器找不到所查询的资源或者达不到所要求的查询数量，它将会将查询请求按照特定的请求传递策略(本模型中采用了Adriana Iamnitchi与Ian Foster所提出的基于经验的随机请求传递策略，其他分布式的请求传递策略也可以使用)发送至其他中心服务器上，直到找到查询资源。查询结果首先会返回发起P2P资源查询的中心服务器，再由其将结果传给查询节点，一次查询结束。查询过程如图11(2)所示。

中心服务器上的查询过程伪码如下：

输入：查询条件集C，所需资源最小数量N

输出：查询结果集R

[1]    BEGIN

[2]    在本组资源中查找符合条件C的资源集Rlocal；

[3]    IF找到本地符合条件C的资源且n(Rlocal)≥N THEN

[4]    R＝Rlocal；

[5]    ELSE

[6]    R＝Rlocal；

[7]    根据传递策略发送查询条件C，并等待返回结果资源集Rp2p；

[8]    IF超时或未找到THEN

[9]    R＝R_local∪Null；

[10]   ELSE

[11]   R＝R_local∪R_p2p；

[12]   ENDIF

[13]   ENDIF

[14]   返回R；

[15]   ENDBEGIN

(7)网格资源调度

由于网格环境的异构性，在网格环境中也存在着异构的网格任务调度程序。在基于WSRF的网格资源管理系统中的任务调度服务主要提供一种统一的网格任务的调度接口，从而屏蔽由于本地任务调度程序的异构性所造成的网格任务调度困难。

具体的做法是，使用访问中间层的任务调度接口包装本地任务调度程序，由访问中间层的任务调度接口代理实际的本地任务调度程序接受实际的任务调度请求，并同时负责将任务的实际执行情况返回给上层组件。而任务调度服务则负责对访问中间层的任务调度接口进行再次包装，使之能够以Web服务的形式公开，方便其他网格应用程序调用。

一次典型的网格任务调度过程如图12所示：

1、网格任务管理程序调用任务调度服务的任务调度接口将具体的计算任务分配给计算节点；

2、任务调度服务根据实际的任务调度请求，查询语义查询服务，以确定该具体任务所需的资源时候已经就绪；

3、当任务所需资源就绪后，任务调度服务调用访问中间层的任务调度接口；

4、相应的任务调度接口调用实际的本地任务调度程序完成任务的调度和运行；

5、6、7、在任务运行期间，本地任务调度程序通过访问中间层的任务调度接口和任务调度服务与最终发起任务分配的网格任务管理系统进行通讯，以告知后者任务的具体执行情况，后者也可以随时通过调用任务调度服务的相应接口中止或者挂起任务的执行过程。

本文所提出模型的组织结构是集中式与分布式相结合的网格资源组织形式。在通过资源发现过程找到所需要的网格资源后，任务调度程序的调度过程也体现了集中式与分布式相结合这一特点。在模型中每个VO采用了虚拟资源节点的方法进行资源的组织和管理，对于每个子树的根节点，其所有子节点均被认为是自己的资源，每个资源也就相应的有了各自的任务调度程序，这种虚拟资源节点方法也大大方便了任务的调度过程。

如图13所示，在任务调度程序发现所需的网格资源后，具体的任务调度请求首先被发送到VO的中心服务器上，由于使用虚拟资源节点方法，中心服务器会将资源所在子树的根节点的任务调度服务作为“本地任务调度程序”调用，以此类推直至实际资源的本地任务调度程序被调用为止，从而完成一次任务调度。任务的具体执行情况也会使用相应的逆过程回溯至任务调度的发起者。

综上所述，本发明的有益效果如下：

(1)利用Web服务资源框架实现了有状态的网格资源管理服务。

(2)利用语义网技术提高了网格资源管理服务的通用性。

(3)利用集中式与分布式相结合的方式提高了在大量资源状况下网格资源发现的效率。

(4)利用虚拟资源节点技术实现了利用Web服务调度网格任务的功能。

以上实施例仅用以说明而非限制本发明的技术方案。不脱离本发明精神和范围的任何修改或局部替换，均应涵盖在本发明的权利要求范围当中。

Claims (10)

1、一种网格资源管理系统，该系统包括网格顶层的应用程序层、网格底层的监控管理软件层；其特征在于：所述系统还包括Web服务层、访问中间件层；应用程序层、Web服务层、访问中间件层、监控管理软件层依次连接；

Web服务层用于提供网格资源发现服务、网格资源历史状态服务、及网格资源调度服务；对应的包括网格资源发现模块、网格资源历史状态模块、及网格资源调度模块；

访问中间件层提供一与平台无关的资源管理接口，用于实现网格底层监控管理软件层与Web服务层的数据访问。

2、根据权利要求1所述的网格资源管理系统，其特征在于：所述网格系统中的所有资源均以虚拟组织的形式进行管理，在每个虚拟组织内部存在一个或多个集中式的资源注册结构，即存在中心服务器存储共享资源信息，所有可用资源信息被聚集在该中心服务器上。

3、根据权利要求2所述的网格资源管理系统，其特征在于：单中心服务器间模型采用分布式资源发现形式。

4、根据权利要求2所述的网格资源管理系统，其特征在于：所述资源按资源所有者、或/和资源类型、或/和资源性质或/和管理策略标准分组；组与组之间则通过中心服务器采用P2P的资源定位方式连接入网格，以适应大规模的动态网格环境。

5、根据权利要求1所述的网格资源管理系统，其特征在于：所述网格资源发现模块包括查询服务单元、通知服务单元、语义查询单元；所述查询服务单元、通知服务单元分别与语义查询单元连接；查询服务单元、通知服务单元连接Web服务层，语义查询单元连接访问中间件层。

6、利用权利要求1所述的网格资源管理系统进行网格资源管理方法，其特征在于：所述方法包括语义查询步骤：

步骤1A、获取从网格资源状态采集软件收集的信息；

步骤1B、依据步骤1A所获取的信息类型，将不同的信息内容转换成相应的语义数据；

步骤1C、将步骤1B得到的所有语义数据保存在语义仓库中，并提供相应的基本语义查询接口；

步骤1D、将复杂的语义查询包装成简单的查询接口，简化语义数据的查询过程；

步骤1E、提供对语义数据变化的通知预订功能；

步骤1F、提供对网格资源历史数据的查询功能；

步骤1G、依据步骤1C所保存的网格资源语义信息作出网格资源调度决定进行网格资源的调度工作。

7、依据权利要求6所述的网格资源管理方法，其特征在于：所述网格资源管理方法包括语义信息转化步骤，该步骤根据获取信息的不同信息格式(如：XML格式，纯文本格式，二进制格式等)和不同信息源类型(如：数据库，文件等)组装成不同的数据源插件，对不同的原始数据进行语义数据的提炼；所述语义信息转化步骤包括：

步骤2A、选择不同的信息格式和不同的数据源组装成数据源插件；

步骤2B、利用数据源插件将相应的数据源数据提炼成语义数据；

步骤2C、将提炼出的语义数据保存至语义查询服务的语义仓库中。

8、依据权利要求6所述的网格资源管理方法，其特征在于：所述网格资源管理方法包括语义数据变化的通知预订步骤，该步骤提供给用户注册数据变化通知的功能，从而避免了用户为了获得所关心的数据状态的变化而反复查询的情况；所述语义数据变化的通知预订步骤包括：

步骤3A、用户定制所关心的数据状态变更通知；

步骤3B、通知服务告知语义查询服务在数据状态变更时通知自己；

步骤3C、语义查询服务在通知服务所关心的资源发生变化时通知通知服务；

步骤3D、通知服务再通知用户其所关心的资源状态已发生变化。

9、依据权利要求6所述的网格资源管理方法，其特征在于：所述网格资源管理方法包括网络资源调度步骤，该步骤利用语义查询服务中所保存的网格资源状态信息进行网格任务调度决策，并完成调度工作；所述网络资源调度步骤包括：

步骤4A、用户将任务提交给网格资源调度服务；

步骤4B、网格资源服务根据用户对任务资源的要求在语义数据查询服务中查找符合要求的资源列表；

步骤4C、在符合要求的资源列表中根据特定的资源调度算法进行资源调度决策；

步骤4D、将网格任务调度至资源调度决策所选择出的资源上。

10、根据权利要求6或7或8或9所述的网格资源管理方法，其特征在于：所述网格资源管理方法包括网络资源调度步骤，具体包括：

网格任务管理程序调用任务调度服务的任务调度接口将具体的计算任务分配给计算节点；

任务调度服务根据实际的任务调度请求，查询语义查询服务，以确定该具体任务所需的资源时候已经就绪；

当任务所需资源就绪后，任务调度服务调用访问中间层的任务调度接口；

相应的任务调度接口调用实际的本地任务调度程序完成任务的调度和运行；

在任务运行期间，本地任务调度程序通过访问中间层的任务调度接口和任务调度服务与最终发起任务分配的网格资源调度模块进行通讯，以告知网格资源调度模块任务的具体执行情况所述网格资源调度模块可以随时通过调用任务调度服务的相应接口中止或者挂起任务的执行过程。

Images