CN1791117A - 基于服务与底层资源分离的服务计算系统 - Google Patents

Abstract

本发明涉及一种基于服务与底层资源分离的服务计算系统，该系统包括：资源层，设有原始服务、底层资源和已部署服务，位于所述系统的最底层；分布式服务注册库，为各类资源的组织和发现提供支持，位于所述资源层的上一层；服务浏览器，向用户提供基于Web方式的操作平台，位于所述分布式服务注册库的上一层；用户层，设有服务提供方、底层资源提供者和消费者，位于所述服务浏览器的上一层。本发明通过将服务与底层资源分离，有效地解决了当前服务与底层资源绑定的服务计算中作业处理效率及资源利用率低、潜在的较高的资源使用经济代价以及安全问题。

Description

基于服务与底层资源分离的服务计算系统

技术领域

本发明涉及一种基于服务与底层资源分离的服务计算系统，尤其涉及一种用于解决在服务计算中如何进行方便的服务提供和使用，并且保证服务的运行效率和资源利用率等问题的基于服务与底层资源分离的服务计算系统。

背景技术

基于SOA(Service Oriented Architecture的简称)结构的Internet计算称为服务计算，具体包括Web服务和服务网格等。在服务计算中如何进行方便的服务提供和使用并且保证服务的运行效率和资源利用率等问题，成为当务之急。

在服务计算中，计算、存储、网络、数据和软件资源都被抽象为服务，支持服务运行的资源，包括计算资源、存储资源和网络环境等等。在服务计算中，一般来说有三类实体，即服务提供者、服务消费者和服务注册表。服务提供者向用户提供能够处理问题的服务，将服务的相关信息发布到服务注册表中；服务消费者，即用户，从服务注册表中查找需要的服务，并在相应的资源上运行服务，和服务提供者进行交互，完成服务的使用。

现有的服务计算中，Web服务领域以Apache Axis为例，Apache Axis是Web服务领域中最著名的中间件系统，它为Web服务的运行提供了基础的运行环境。但是Axis仅限于为一个节点上的服务提供运行环境，没有分别对服务以及运行服务的底层资源进行考虑，没有提供服务到底层资源的动态部署功能，这样使得服务只能运行在所绑定的资源上。而且Axis也没有提供服务发现的功能，用户必需将Axis和UDDI(Universal Description，Discoveryand Integration的简称)等服务发现系统整合起来才能构建完整的Web服务运行支撑系统。即便这样，因为UDDI自身也存在着很多问题。UDDI是Web服务协议族的重要组成部分，它定义了描述Web服务的信息模型，并提供了一个全局统一的注册和发现服务，通过tModel这种抽象的方式描述服务的类别，并可以通过对tModel的扩充支持对QoS属性的存储和查询。UDDI在结构上仍是集中式的方式，很容易造成性能瓶颈和单点失效的问题，这不适合于服务计算的广域分布计算环境。此外，UDDI只针对已经部署好的服务的信息进行检索，不支持对运行服务的资源的检索。

在服务网格中，Globus Toolkit 4.0是典型的服务网格中间件系统。GlobusToolkit 4.0不仅为遵循Web服务资源框架(Web service resourceframework，简称WSRF)规范的服务提供了运行环境WSRF，同时还提供了用于服务发现的监控与发现服务(Monitor and Discovery Service，简称MDS)等基础功能。但WSRF core没有提供动态的服务部署功能，也就是说使用Globus Toolkit 4.0，用户不能将服务动态地部署到一个底层资源(如PC机)上，或者说Globus Toolkit 4.0中的服务和底层资源仍然是绑定在一起的，提供者要想为用户提供服务，必须事先将服务部署到指定的计算机上。另外，MDS虽然提供了服务发现的功能，而且采用了分布式的结构，但其结构是完全层次化的，信息从下层向上层逐渐汇聚，但是当网络规模变大时，MDS上层的组件的负载越来越大，效率也随之降低。更值得注意的是，MDS中没有提供底层资源的信息，用户不能通过MDS发现所需要的用于运行服务的底层资源。

现有技术存在的问题是，无论是Web服务，还是服务网格的系统实现中，都没有将服务和资源分开考虑。服务提供者必须提供运行服务的资源，服务的消费者只能调用已经部署在特定资源上的服务来处理自己的问题，没有办法自由选择服务和资源。这种服务与资源的绑定，导致了以下三个问题：

1.降低了用户作业的处理效率和资源的利用率。在作业处理效率方面，因为用户只能选择已经部署在特定资源上的服务，因此没有办法分别选择最佳的资源和服务来处理作业，这必然会降低作业的处理效率；在资源的利用率上，可能存在大量的资源因为没有服务运行，而使得其资源白白浪费，降低了总体的资源利用率。

2.在需要付费使用的真实应用环境中，用户可能会为同样的服务和资源付出更高的经济代价。在实际应用中，资源和服务都不是免费的，需要用户通过一定的方式进行购买。如果没有考虑资源和服务的分别提供，用户没有办法分别选择具有最佳性价比的资源和服务，从而潜在地导致付出更多的经济代价。

3.在动态广域的网络环境下，面临较大的安全挑战。在高度分布的动态广域网络环境下，各个实体之间的信任关系没有办法事先建立，潜在的安全威胁与用户对作业安全可靠运行的需求形成尖锐的矛盾。尽管当前很多安全技术致力于解决面临的挑战，但是这些技术往往都会大大降低系统的处理效率。另一方面，在有些情况下，用户可能拥有或者事先知道一些可信的安全的资源，在这些资源上用户可以放心地处理自己的作业。但在服务与资源绑定的情况下，用户所信任的资源上可能没有服务可以运行，所以用户不得不选择运行在不可信资源上的服务，从而增加了安全的风险，并且为了获得安全牺牲了作业处理的效率。

发明内容

本发明的目的在于针对上述现有技术的不足提出一种基于服务与底层资源分离的服务计算系统，用以将服务以及运行服务的资源进行分离，提高用户作业的处理效率和资源的利用率，并且在高度分布的动态广域网络环境下降低为保障系统安全所付出的处理代价。

基于上述目的，本发明提供了一种基于服务与底层资源分离的服务计算系统，该系统包括：资源层，设有原始服务、底层资源和已部署服务，位于所述系统的最底层；分布式服务注册库，为各类资源的组织和发现提供支持，位于所述资源层的上一层；服务浏览器，向用户提供基于Web方式的操作平台，位于所述分布式服务注册库的上一层；用户层，设有服务提供方、底层资源提供者和消费者，位于所述服务浏览器的上一层。

本发明通过将服务与底层资源分离，有效地解决了当前服务与底层资源绑定的服务计算中作业处理效率及资源利用率低、潜在的较高的资源使用经济代价以及安全问题。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为本发明的一个较佳实施例的系统结构示意图；

图2为本发明中可信的服务远程热部署模块一个较佳实施例的结构示意图；

图3为本发明中信任协商代理模块一个较佳实施例的结构示意图；

图4为本发明中服务部署模块部署一个服务过程中部署模块操作的流程图；

图5为本发明中服务部署模块部署一个服务过程中反部署模块操作的流程图；

图6为本发明中服务部署模块部署一个服务过程中重部署模块操作的流程图；

图7为本发明中可信的服务远程热部署中一个基本的信任协商过程的原理图；

图8为本发明中可信的服务远程热部署中信任协商过程的一个实施例流程图；

图9为本发明实现整个可信的服务远程热部署的实施例的流程图；

图10为本发明中用于节点资源监控的节点信息监控模块一个较佳实施例的结构示意图；

图11为本发明中资源监控器的处理流程图；

图12为本发明中提供者管理器的处理流程图；

图13为本发明中DSR实施例RLDS的结构示意图；

图14为本发明中软状态管理中子节点报告状态信息的流程图；

图15为本发明中软状态管理中父节点检查状态信息的流程图；

图16为中间层节点失效前的树状拓扑示意图；

图17为失效重构后的树状拓扑示意图；

图18为中间层节点失效后树状拓扑重构的流程图；

图19为树的恢复的流程图；

图20为基于森林状拓扑结构的信息查询方法的流程图。

具体实施方式

现以服务计算中的服务网格的系统实现为例进行详细说明。

首先定义以下几个术语：

原始服务(Raw services，以下简称RS)。RS是指服务提供者设计和开发好的服务，但是还没有部署到计算机上，因此这样的服务是不能使用的。RS很类似于软件提供商提供的软件包，在软件包没有被安装之前，软件是无法被使用的。RS的具体形式体现为一个GAR(Grid Archive)格式的压缩包，GAR是由Globus Toolkit定义的一种服务文件格式。

底层资源(Underlying resources，以下简称UR)。UR指能够支持服务运行的底层资源，例如高性能服务器、集群、PC机，如果细分的化，包括计算资源、存储资源、网络资源和仪器设备等等。

已部署服务(Deployed services，以下简称DS)。DS是指将RS部署到UR以上后，得到的能够被用户使用的服务。DS很类似于已经安装在某一台计算机上的软件，这样的软件能够被用户使用。

实际上，RS、UR和DS都可以看作网络中的资源，只是它们各自的性质和形态不同，我们将服务计算中涉及到的所有资源分成RS、UR和DS这三大类别，除非特殊说明，下文中的“资源”的意义涵盖了RS、UR和DS三种资源。

图1为本发的一个较佳实施例的系统结构示意图，其结构按照层次进行划分，共分为四层。

最下层是资源层10，这里所说的是广义上的资源，包括了RS 11、UR 12和DS 13在将RS 11与UR 12分开的同时，也允许网络中存在已部署的服务，即DS 13，所以把DS 13也划在这一层。

第二层是分布式服务注册库20(Distributed Service Repository，简称DSR)。DSR类似于面向服务的体系结构(Service Oriented Architecture，简称SOA)中的服务注册表，为各类资源的组织和发现提供支持。所不同的是，DSR所支持的资源种类包括了RS、UR和DS三类资源。DSR将分布在网络上的RS、UR和DS按照一定的逻辑结构进行组织，内部实现了高效的查询方法，对外向用户提供丰富的查询接口，用户通过DSR能够找到自己所需要的资源完成作业的处理。

第三层服务浏览器30(Service Explorer，简称SE)。SE 30是位于DSR 20和用户层40之间的一层，SE 30为服务提供者41、底层资源提供者42提供和发布各类资源提供支持，同时支持消费者43高效方便地使用资源进行问题求解。

最上面一层是用户层40。这一层包括开放服务提供与消费环境的几类用户：服务提供者41、底层资源提供者42以及消费者43。提供者通过SE 30发布资源；消费者43通过SE 30能够查找所需要的RS 11、UR 12和DS 13，并提交自己的作业，最终获得作业处理结果。

在基于服务与底层资源分离的服务网格的系统实现中，选择WSRF规范作为服务的基本实现形式。服务的运行需要UR的支持，同时运行服务要求有软件环境的支持，对于WSRF服务来说，要建立一个支持WSRF服务的软件运行环境，一般地，将这样的运行环境称为服务容器。在基于服务与底层资源分离的服务网格计算系统中，以节点服务器(Node Server，简称NS)作为服务容器，并要求所有加入基于服务和底层资源分类的服务网格系统中的UR之上，都要安装一个NS软件环境。

NS的主要功能包括：提供WSRF服务的基本运行环境、可信的服务远程热部署(Remote & Hot Service Deployment with Trustworthiness，简称ROST)和节点资源监控。

WSRF服务的基本运行环境是指NS必须为WSRF服务提供基础运行环境，包括WSRF规范的实现和SOAP消息的处理等等，这一功能采用了GlobusToolkit 4.0内核的开源实现。

NS中设有可信的服务远程热部署模块用于实现可信的服务远程热部署功能，可信的服务远程热部署主要解决服务的部署问题，其中包括三个主要的功能特色：热部署、远程部署和部署中的安全。服务的部署本质上是RS的部署，过程类似于软件的安装过程，其主要的工作是对NS的配置进行更新，类似于将软件安装到操作系统中的过程。所谓的热部署是指将一个新RS部署之后，无需重新启动服务容器，即可以使得服务能够被调用。远程部署主要是针对网络的分布式特点，服务的部署者和NS可能分散在不同的网络节点上，因此需要提供将服务部署到远端的NS。网络环境是非常复杂的，恶意的部署者可能把包含病毒的恶意服务部署到NS上，同时恶意的NS同样可能欺骗服务的部署者对外提供虚假服务，因此在服务部署的过程中存在很大的安全风险。而由于服务的部署者和NS可能位于不同的安全自治域内，很难为网络上任何两个实体提前建立信任关系，因此必须解决在这种环境下部署中的安全。

为实现可信的服务远程热部署，本发明采用如下技术方案：在服务容器中以WSRF服务的形式实现一个远程部署服务，负责接收从部署者传输过来的要部署的服务，并把这个服务部署到服务容器中。为了使服务部署后即可使用而不需要重新启动容器，远程部署服务要实现热部署功能；为了删除网格服务容器中已经部署好的服务，远程部署服务还需要提供反部署功能；为了更新服务容器中已经部署好的服务，远程部署服务还需要提供重部署的功能。为了保证远程部署的安全可信，在部署者和目标容器两方各有一个服务协商代理(Trust Negotiation Agent，简称TNA)模块，采用自动信任协商(Automated Trust Negotiation，简称ATN)技术进行信任协商。

图2为本发明中可信的服务远程热部署模块一个较佳实施例的结构示意图，该模块包括信任协商代理模块100、远程热部署模块(Remote HotDeployment，简称RHD)200和服务容器配置模块300。

信任协商代理模块100用于建立部署者和目标服务容器之间的信任关系；RHD 200用于进行远程服务热部署以及本地的自动服务部署，与信任协商代理模块100连接。RHD 200包括远程部署模块210、本地部署模块220、基本部署模块230和部署辅助工具模块240；远程部署模块210包括用于接收远程的部署者传来的服务的服务接收器211和信任检查器212，信任检查器212，用于判断接收到的所述服务是否可信，并根据判断结果调用信任协商代理模块或基本部署模块230，与所述服务接收器211、所述信任协商代理模块100和基本部署模块230连接；远程部署模块210用于接收远程的原始服务并判断远程的部署者是否可信，根据判断结果判定是调用所述信任协商代理模块100还是调用所述基本部署模块230；所述服务接收器211与所述信任检查器212相连接，所述信任检查器212与所述信任协商代理模块100连接；本地部署模块220包括事件侦听器221和事件分析器222，用于监视本地的部署文件夹并根据监视信息调执行相应的部署操作；所述事件侦听器221与所述事件分析器222连接；基本部署模块230包括部署子模块231、反部署子模块232和重部署子模块233，这三个模块在ANT技术的基础之上，将GAR文件部署或反部署或重部署到网格服务容器内，所述远程部署模块210对接收到的远程GAR文件，基于FTP/SOAP附件实现远程部署，该基本部署模块230与远程部署模块210中的信任检查器212和本地部署模块220中的事件分析器222连接。

服务容器配置模块300用于辅助在部署操作中所需要的文件解析或文件解压缩等功能，与所述基本部署模块230连接。在执行部署操作过程中，服务容器配置模块300中的服务容器配置参数表动态进行更新。

图3为本发明中信任协商代理模块一个较佳实施例的结构示意图，主要有如下六部分构成：

信任票据管理器110：由访问仲裁者给请求者颁发信任票据(Trustticket)或基于本地的票据库验证请求者的信任票据是不是有效的；

策略引擎120：使用委托策略决定什么时候、怎样披露本地的证书和策略。另外，它也对委托的状态作出决定，是成功、失败还是继续，与所述信任票据管理器110连接；

一致性检查器130：决定哪个本地的证书满足请求者的策略以及请求者的证书是否满足本地的策略；

信任票据存储库140：用于存储信任票据，与所述信任票据管理器110连接；

信任证链收集器150：对于开放网络中的信任委托，当证书没有存储在本地的时候，访问控制策略通常需要找到一个从源到请求者的委托授权的证书链。信任证链收集器150的主要作用就是发现和收集必需的证书，与所述策略引擎120连接；

策略存储库160，用于存储策略，与所述一致性检查器130连接；

在实现ROST的过程中，部署者和目标服务容器上都需要有TNA。如果请求者有一个合法的信任票据，信任协商代理模块100会调用信任票据管理器110来做出决定。否则，信任协商过程就会被触发。当请求者披露他的策略时，由策略引擎120决定这次协商是否要继续下去.如果需要继续，信任协商代理模块100会调用一致性检查器130来确认需要提供哪个证书，然后再响应需要的证书和策略。如果证书不在本地的证书/策略库中，信任证链收集器150会被调用从而动态的发现需要的证书。类似的，当请求者提交他的证书时，信任协商代理模块100也会调用一致性检查器130，来确认这个证书是否满足本地的策略并作出访问决定。

为加速协商的过程，如果信任协商代理模块100认为对于不同的协商过程都需要检索同一个证书链，那么它可以把这个证书链缓存起来，从而避免了频繁的检索。

TNA采用精确的RTML(Role-Based Trust Management Language MarkupLanguage)来代表访问控制策略和基于属性的证书。当证书的存储是分布式的时候，目标指向的算法确保了所有可用的证书都能被发现和收集。在ROST的设计中，信任票据的格式为：<subject，issuer，subject，validdate，expiration date，signature>.

此外，协商信息的交换必须在安全的通信协议之上(比如SSL/TLS)，从而防止窃听，中间人攻击，重放攻击等.在ROST中，我们遵循WS-Security规范和WS-Conversation规范对SOAP消息进行保护。

图4为本发明中服务部署模块部署一个服务过程中部署模块操作的流程图，具体执行如下操作：

步骤101：查看GAR文件是否存在，如果不存在，执行步骤108；如果存在，则执行步骤102；

步骤102：如果GAR文件存在，判断ANT环境是否可用，如果不可用，执行步骤108，如果可用执行步骤103；

步骤103：解压缩GAR文件；

步骤104：将Java Class执行文件装载到服务容器；

步骤105：解析WSDD配置文档并将配置信息装载到服务容器中；

步骤106：将WSDL文件复制到特定的目录；

步骤107：解析JNDI等其他文档并配置服务容器；

步骤108：结束此次操作。

上述步骤103-107就是利用ANT工具将GAR文件部署到网格服务容器中的过程。

图5为本发明服务部署模块部署一个服务过程中反部署模块操作的流程图，具体执行以下操作：

步骤201：判断反部署的服务是否存在，若是，执行步骤202，若否，则执行步骤207；

步骤202：判断ANT环境是否可用，如果是，执行步骤203，若否，执行步骤207；

步骤203：将Java Class等可执行文件从服务容器中卸载；

步骤204：从服务容器配置中删除服务对应的WSDD配置；

步骤205：删除WSDL文件；

步骤206：从服务容器中删除JNDI等其他配置信息和其他相关文件；

步骤207：结束此次操作。

上述步骤203-206就是调用ANT工具将部署时装载到服务容器中的所有配置信息、程序文件删除的过程。

图6为本发明中服务部署模块部署一个服务过程中重部署模块操作的流程图，具体执行以下操作：

步骤301：对指定的GAR文件进行反部署，具体执行过程见图5；

步骤302：对指定的GAR文件进行部署，具体执行过程见图4；

步骤303：结束此次操作。

当GAR文件以FTP方式远程发送到本地，则RHD 200首先从FTP服务器上下载GAR文件，然后调用本地部署机制即图4、5或图6所示流程对GAR文件进行相应部署。

当GAR文件以SOAP附件方式远程发送到本地，则服务部署模块10首先从远程发送终端上下载GAR文件，然后调用本地部署机制即图4、5或图6所示流程对GAR文件进行相应部署。

为保障部署中的安全问题，在服务部署之前需要在目标服务容器和部署者进行信任协商，建立信任关系，即目标服务容器在信任部署者之前，它需要部署者出示证书并且指定一些关键属性。另一方面，在证书中可能包含敏感信息，因此必须制定相应的策略来保护这些信息。这些策略指定了证书暴露给对方之前，对方必须满足什么条件。信任协商主要就是根据各自的策略交换证书的过程。

图7为本发明中可信的服务远程热部署中一个基本的信任协商过程的原理图，部署者81在安全域A 80中，而服务容器83在安全域B 82中。部署者81向服务容器83提出一个部署请求84，容器再收到这个请求84后，根据它自身的策略85，要求部署者提供一定的证书才允许部署操作的执行。然后部署者81提供相应的证书86给服务容器83，服务容器83再对这些证书86进行验证后，把协商结果87告诉部署者81。如果证书86是合法的，则允许部署操作继续进行，否则，该操作被拒绝。

图8为本发明中可信的服务远程热部署中信任协商过程的一个实施例流程图，假设节点D即部署者需要把一个服务部署到目标服务容器T上，具体包括以下步骤：

步骤401：D向T发送一个部署请求(Deployment Request)Rdep；

步骤402：T把自己的访问策略Policies：只有同时拥有证书CA1和CA2的节点才允许执行部署操作，告诉D；

步骤403：D拥有证书CA1和CA2，但CA2中包含D的敏感信息，因此D对CA2设置了一个访问策略：只有拥有证书CB1的用户才能读CA2；D把CA1和他的策略(Policies(C_B1→C_A2))再发送给T；

步骤404：T有证书CB1，于是它把CB1发给D；

步骤405：D收到CB1后，经过验证，把CA2发给T；

步骤406：T把协商成功的结果(negotiation result(success))发给D。

经过上述几步的交互，D和T已经建立了信任关系。接下来把GAR包从D传输给T，按照图4、5和6进行相应的部署。

一次协商过程可能会花费比较长的时间。此外，在有些情况下，用户需要更新已经部署过的服务，没有必要再进行一遍协商。为了提高协商的效率，我们在ROST里提出了信任票据(TrustTicket)的概念。在一次成功的信任协商之后，部署者可以向服务容器申请一个TrustTicket，在这个TrustTicket里，存储了一些关键的安全信息。有了TrustTicket，部署者就不需要和这个容器再次进行信任协商，只需要出示他的TrustTicket就行了。为保证更高的安全性，TrustTicket由颁发的容器签名并具有有限的生命期。

为了保证协商总会终止，我们为协商设置了超时时间，当协商时间超过超时间，即会被强制终止。

图9为本发明实现整个可信的服务远程热部署的实施例的流程图，具体执行以下步骤：

步骤501：部署者向远程的服务容器发出部署请求；

步骤502：远程的服务容器收到请求后，检查自己能不能承担这个服务。如果能，执行步骤503；否则，执行步骤511；

步骤503：远程的服务容器根据本地域控制者或历史信息检查部署者是否是可信的。如果是，执行步骤504；否则，执行步骤507；触发信任协商；

步骤504：向部署者发出一个可信通知；

步骤505：部署者收到远程服务容器发来的可信通知后，检查远程的服务容器是否是可信的。如果是，执行步骤506；否则，执行步骤507；

步骤506：向远程服务容器发出一个可信通知；

步骤507：远程的服务容器和部署者之间进行信任协商；

步骤508：如果双方是可信的或者信任协商成功，双方建立起了信任关系，则执行步骤509；否则，执行步骤511；

步骤509：部署者把要部署的服务传输给远程服务容器；

步骤510：远程服务容器执行热部署操作并把结果告诉部署者；

步骤511：结束。

通过上述方案实现可信的服务远程热部署，保证了远程部署的安全可信。

图10为本发明中用于节点资源监控的节点信息监控模块一个较佳实施例的结构示意图，该模块设有资源监控器(ResourceMonitor)50，该资源监控器50设有查询接口模块51和通知接口52模块，且连接有提供者管理器(ProviderManager)54。由于网络上资源的信息是动态改变的，因此NS提供对本地的UR资源进行监控的功能，使得用户能够获得资源的当前状态。资源信息是由各种信息提供者53来收集的，根据采集的信息类型不同，可以分静态资源信息(如操作系统类型和机器类型)的提供者以及动态资源信息(如CPU负载)的提供者。信息提供者53由提供者管理器54按照配置文件的规定进行统一的管理，如信息提供者53的初始化、控制信息推送的时间间隔和终止服务等。信息提供者53将信息以拉(pull)或者推(push)模式传送到资源监控器50，资源监控器50最终封装为WSRF服务，除了提供对资源信息的查询接口51外，针对动态信息还提供了通知接口52，用户可以利用WSRF的通知机制以异步的方式获得资源信息。

在进行节点资源监控的过程中，资源监控器50和提供者管理器54分别执行以下操作流程。

图11为本发明中资源监控器的处理流程图，具体包括以下步骤：

步骤601：分析提供者(Provider)配置文件；

步骤602：判断是否存在下一个提供者(Provider)，若是，执行步骤603，否则，执行步骤606；

步骤603：判断该提供者(Provider)采集的信息类型是否包含在资源模板中，若是，执行步骤604，否则，执行步骤605；

步骤604：加载该提供者(Provider)，创建一个提供者(Provider)对象，执行步骤602；

步骤605：加入卸载(Unload)数组，标记该提供者(Provider)未载入，执行步骤602；

步骤606：结束。

图12为本发明中提供者管理器的处理流程图，具体执行以下步骤：

步骤701：获取资源模板；

步骤702：分析资源属性模板，判断其中的资源属性是动态的还是静态的，若是动态，执行步骤703，若是静态，则执行步骤704；

步骤703：加入TopicList，执行步骤705；

步骤704：加入静态资源属性列表；

步骤705：初始化提供者管理器(ProviderManager)；

步骤706：遍历静态提供者(Provider)对象，查询静态资源属性；

步骤707：将静态资源属性汇报给信息服务；

步骤708：启动动态提供者(Provider)；

步骤709：结束。

本发明DSR以资源定位与描述服务(Resource Locating and DescriptionService，简称RLDS)模块为例进行说明。

图13为本发明中DSR实施例RLDS的结构示意图。RLDS采用森林状的拓扑结构对各种网络资源如DS 13、RS 11和UR 12等进行统一的组织管理，为用户提供资源的搜索和定位服务。采用分布式的结构，将参与服务计算的所有资源按照地理位置划分成多个自治域，每个自治域内采用树形的结构进行组织，整体上是由多棵树结构，树之间采用对等的方式进行连接。

多个RLDS 61节点按照树状的拓扑结构组成的虚拟组织--自治域。自治域内的RLDS节点共享相同信息模型、安全策略。一个RLDS节点只能有一个父RLDS节点，而每个RLDS节点可以有多个子RLDS节点；每个RLDS节点在启动后会动态保存其父RLDS节点和子RLDS节点的服务访问点，在逻辑上形成一个虚拟的树状结构。每个自治域要部署一个区域转换节点(RegionSwitch)60，用于在自治域之间转发跨域的查询请求，实现自治域之间的信息共享。

多个对等的自治域的树状拓扑结构形成一个森林状拓扑结构。各个自治域之间通过区域交换设备RegionSwitch 60以对等模式(P2P)组织在一起，由区域注册表RegionRegistry记录所有可用RegionSwitch 60的列表。RLDS森林状拓扑结构有着很好的可扩展性，具体表现为以下两个方面：

1)域间的可扩展性：管理员可以通过建立新的自治域加入网格环境，共享网格环境下的各种资源。在拓扑结构上表现为在原有森林结构上添加一棵新树；

2)域内的可扩展性：管理员也可以通过加入已存在的自治域加入网格环境，共享网格环境下的各种资源。在拓扑结构上表现为在原有森林结构的某一棵树上添加一个新枝。

RLDS拓扑结构的维护是通过软状态管理机制实现的。软状态管理机制指的是两个节点之间的信息通过定期的进行信息交互，维持彼此之间的父子关系。它包括两方面的含义：

1)子节点采用“推”模式，将自己最新的状态信息主动报告给父节点，从而使父意识到子节点的存在并将当前的父子关系保存下来。这个过程通过AliveKeeper线程实现，如图14所示，具体执行以下几步：

步骤801：判断是否进行线程运行，若是，执行步骤802，否则，执行步骤809；

步骤802：判断是否已经注册，若是，执行步骤803，否则，执行步骤804；

步骤803：向父节点注册；

步骤804：间隔一段时间；

步骤805：判断注册是否成功，若注册成功，执行步骤806，否则，执行步骤808；

步骤806：向父节点keep alive；

步骤807：判断Keep alive是否成功，若是，执行步骤802，否则，执行步骤808；

步骤808：设置为非注册状态，执行步骤802；

步骤809：结束。

2)父节点定期检查节点汇报的最新状态信息，判断其更新时间是否已经超过某个预先设定的阈值，如果超过则意味着子节点可能已经不存在，那么就要将这两个节点之间的父子关系去掉。这个过程通过软状态管理器(SoftState Manager)线程实现，如图15所示，具体执行以下几步：

步骤901：是否进行线程运行，若是，执行步骤902，否则，执行步骤906；

步骤902：检查状态信息的过期情况；

步骤903：判断状态信息是否过期，若是，执行步骤904，否则，执行步骤905；

步骤904：去掉父子关系；

步骤905：间隔一段时间，执行步骤902；

步骤906：结束。

RLDS拓扑动态维护包括三方面内容：1)RLDS节点之间关系的维护：同一自治域内的RLDS节点之间通过建立父子关系构造虚拟的树状拓扑结构，感知彼此的位置。这样就可以将以某个RLDS服务为入口的查询请求转发到域内或域间的其它RLDS节点，完成对域内多个RLDS节点或跨域的信息查询，实现信息的集成共享；2)计算节点与其所属的RLDS节点之间关系的维护：计算节点向其所属的RLDS节点注册并定期keep alive，将计算节点的信息汇聚到其所属的RLDS节点；3)RegionSwitch与RegionRegistry之间关系的维护：RegionSwitch向RegionRegistry注册并定期keep alive，使RegionRegistry能够记录所有当前存在自治域列表。

由于网格环境下网络和节点的不可靠性，需要RLDS拥有相对稳定和健壮的拓扑结构，尽可能的整合所有可用的网格资源，避免形成虚拟组织的信息孤岛。在RLDS构成的树状拓扑结构中，一旦中间层节点失败将导致下层节点构成的虚拟组织无法接入网格系统。这就需要一种机制，使得这些下层节点构成的虚拟组织能够继续驻留在网格环境中，并且保证其结构不发生变化。我们把这个过程称为树的重构，如图16和17所示，图16为中间层节点72失效前的树状拓扑示意图，父节点71通过软状态管理机制发现RLDS节点72的状态信息过期时，将其反注册，并将失效节点72的直接子节点73、74、75构成的虚拟组织提升为自己的直接子节点，图17为失效重构后的树状拓扑示意图。

图18为中间层节点失效后树状拓扑重构的流程图，具体执行以下几步：

步骤A01：检查失效子节点是否还有下层子节点，若有，执行步骤A02，否则，执行步骤A04；

步骤A02：将失效子节点的直接子节点提升为父节点自己的直接子节点；

步骤A03：保存和失效子节点相关的拓扑结构；

步骤A04：结束。

在RLDS拓扑维护过程中，父节点可能由于如下两种原因认为子节点失效：一是子节点的服务不可用；二是由于网络不稳定导致其父节点没有收到其keep alive消息而误认为其失效。由于节点或网络的恢复，失效的节点很可能很快重新加入虚拟组织。为此，我们提出了一种弹性拓扑结构，使得重构后的拓扑结构能够自动恢复到节点失效前的拓扑结构。我们把这个过程称为树的恢复。

图19为树的恢复的流程图，具体执行以下几步：

步骤B01：检查注册节点是否有相关的历史拓扑结构，若有，执行步骤B02，否则，执行步骤B05；

步骤B02：按照历史拓扑进行树的恢复；

步骤B03：归还该节点原来的直接子节点；

步骤B04：删除和该节点相关的拓扑结构；

步骤B05：结束。

当父RLDS节点通过软状态管理机制发现子RLDS节点的状态信息过期并将其反注册的同时，会将和这个失效节点相关的拓扑结构记录下来。当失效的节点重新向父节点注册时，父节点会查看失效前的和失效节点相关拓扑结构，按照这个拓扑结构进行树的恢复。通过执行上述操作，父节点按照失效前的拓扑结构实现树的恢复。

为了减少分布式组织结构造成的频繁的信息交互，在服务网格中，我们提出了基于森林状拓扑结构的信息查询方法，它可以有效地满足用户对网格环境下海量信息的查询要求。

图20为基于森林状拓扑结构的信息查询方法的流程图，查询过程具体执行以下几步操作：

步骤C01：判断是否可以缓存查询，若可以，执行步骤C02，否则，执行步骤C04；

步骤C02：进行查询本地缓存；

步骤C03：是否缓存命中，若是，执行步骤C13，否则执行步骤C04；

步骤C04：查询本地数据库；

步骤C05：是否进行本地查询，若是，执行步骤C13，否则，执行步骤C06；

步骤C06：是否结果集满足，若是执行步骤C13，否则，执行步骤C07；

步骤C07：是否进行子树查询，若是，执行步骤C13，否则，执行步骤C08；

步骤C08：是否结果集满足，若是执行步骤C13，否则，执行步骤C09；

步骤C09：本地节点是否是根节点，若是，执行步骤C10，否则，执行步骤C12；

步骤C10：是否跨域查询，若是，执行步骤C11，否则，执行步骤C13；

步骤C11：查询其他域，执行步骤C13；

步骤C12：向父节点转发查询请求；

步骤C13：结束。

该查询方法是在满足用户查询要求的前提下，尽可能把查询限定在合理可控的范围内，减少分布式查询造成的消息通信代价。首先，用户将查询请求提交给某个RLDS，我们称之为入口RLDS。如果入口RLDS的本地信息能够满足用户的查询请求，则查询结束，否则查询以入口RLDS为根的子树范围，如果还不能满足用户的查询请求，则继续向入口RLDS的上层节点转发查询请求。如果已经到了自治域最上层的根RLDS，仍然不能满足用户的查询请求，则将查询请求转发各其他的自治域。

由此可见，该查询方法合理地限定了查询请求的扩散方向和范围，有着较高的查询效率。

本发明中服务浏览器SE是面向用户的中间件，其实现有两种方式：基于传统GUI的客户端工具和基于Web的GUI工具。考虑到Web的广泛应用以及人们都Web界面的广泛接受程度，SE采用了基于Web的GUI形式。

SE的功能包括获取RS、提供资源、资源选择、调用服务、生成服务调用界面、监控用户作业以及作业执行结果展现。SE可以看作传统的Web门户的一种技术和理念的延伸，用户通过Web浏览器来使用SE。SE的实现是基于很多传统的Web编程技术，其独特之处在于通过这一方式为提供者以及最终用户提供了便捷的参与服务计算的方式。

其中获取RS和提供资源是访问RLDS服务的过程，调用服务、监控用户作业可以通过Web编程技术实现，并非SE的特有内容。而服务调用界面的自动生成和作业处理结果的展现以及资源选择是SE一项突出的技术特点，下面详细阐述。

SE定义了两个接口：

getHTMLInputRendering()

getHTMLOutputRendering(Object result)

针对每个WSRF，服务的提供者都要实现这两个接口。第一个接口用于生成服务的展现界面，第二个接口用于展现处理结果，两个接口的返回值为HTML片断，SE会通过服务的这两个接口进行自动的服务界面生成和结果展现。

至于资源选择，SE可以配置多种资源选择策略，如选择最近资源、能力最强资源、用户指定以及随机选择等，即SE是灵活可配置的，它不拘泥于某一种策略，用户可以根据作业处理的需求，灵活选择和配置。

本发明通过将服务与底层资源分离，有效地解决了当前服务与底层资源绑定的服务计算中作业处理效率及资源利用率低、潜在的较高的资源使用经济代价以及安全问题。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1、一种基于服务与底层资源分离的服务计算系统，其特征在于包括：

资源层，设有原始服务、底层资源和已部署服务，位于所述系统的最底层；

分布式服务注册库，为各类资源的组织和发现提供支持，位于所述资源层的上一层；

服务浏览器，向用户提供基于Web方式的操作平台，位于所述分布式服务注册库的上一层；

用户层，设有服务提供方、底层资源提供者和消费者，位于所述服务浏览器的上一层。

2、根据权利要求1所述的服务计算系统，其特征在于所述底层资源设有：节点服务容器、集群、Pc机；该节点服务器用于提供服务运行环境、可信的远程服务热部署功能以及提供对本节点的底层资源的资源监控功能。

3、根据权利要求2所述的服务计算系统，其特征在于所述节点服务容器设有用于实现服务部署的可信的服务远程热部署模块和节点信息监控模块。

4、根据权利要求3所述的服务计算系统，其特征在于所述可信的服务远程热部署模块包括：

信任协商代理模块，用于建立部署者和目标服务容器之间的信任关系；

远程热部署模块，用于进行远程服务热部署以及本地的自动服务部署，与所述信任协商代理模块连接；

服务容器配置模块，用于存储和管理服务容器的配置参数，与所述远程热部署连接。

5、根据权利要求4所述的服务计算系统，其特征在于所述信任协商代理模块包括：

信任票据管理器，用于颁发或验证信任票据；

信任票据存储库，用于存储信任票据，与所述信任票据管理器连接；

策略引擎，用于决定策略的披露以及对协商结果成功与否进行判定，与所述信任票据管理器连接；

一致性检查器，用于确定满足请求者策略的本地证书以及判断请求者的证书是否满足本地策略，与所述策略引擎连接；

策略存储库，用于存储策略，与所述一致性检查器连接；

信任证链收集器，用于发现和收集必需的证书，与所述策略引擎连接。

6、根据权利要求4所述的服务计算系统，其特征在于所述远程热部署模块包括：

远程部署模块，用于接收远程的原始服务并判断远程的部署者是否可信，根据判断结果判定是调用所述信任协商代理模块还是调用所述基本部署模块；所述服务接收器与所述信任检查器相连接，所述信任检查器与所述信任协商代理模块连接；

本地部署模块，设有事件侦听器和事件分析器，用于监视本地的部署文件夹并根据监视信息调执行相应的部署操作；所述事件侦听器与所述事件分析器连接；

基本部署模块，设有部署模块、反部署模块和重部署模块，用于对接收到的服务进行部署、反部署或重部署操作，该基本部署模块与所述远程部署模块和所述本地部署连接；

部署辅助工具模块，用于辅助在部署操作中所需要的文件解析或文件解压缩等功能，与所述基本部署模块连接。

7、根据权利要求6所述的服务计算系统，其特征在于所述远程部署模块包括：

服务接收器，用于接收远程的部署者传来的服务；

信任检查器，用于判断接收到的所述服务是否可信，并根据判断结果调用信任协商代理模块或基本部署模块，与所述服务接收器、所述信任协商代理模块和基本部署模块连接。

8、根据权利要求3所述的服务计算系统，其特征在于所述节点信息监控模块设有资源监控器，该资源监控器设有查询接口模块和通知接口模块，且连接有提供者管理器。

9、根据权利要求1或2所述的服务计算系统，其特征在于所述分布式服务注册库采用分布式的结构，将参与服务计算的所有资源按照地理位置划分成多个自治域，每个自治域内采用树形的结构进行组织，整体上是由多棵树结构，树之间采用对等的方式进行连接。

10、根据权利要求1或2所述的服务计算系统，其特征在于所述服务浏览器设有用于生成服务的展现界面接口和用于展现处理结果的接口。

Images