CN100353713C - 可信的远程服务热部署方法 - Google Patents

Abstract

本发明涉及一种可信的远程服务热部署方法，包括如下步骤：步骤1，部署者向远程的服务容器发出服务部署请求；步骤2，部署者与服务容器进行信任协商，如果协商成功，则执行步骤3，否则，执行步骤4；步骤3，所述服务容器执行热部署操作；步骤4，结束。通过本发明提供的方法，为远程服务的热部署提供了安全保障，解决了SOA中远程服务热部署的问题以及相关的安全隐患，极大的方便了用户，避免了为了部署服务而重启服务容器给用户带来的损失和效率的降低，解决了网络环境下在跨安全域的部署者和服务容器之间建立信任关系的问题。

Description

可信的远程服务热部署方法

技术领域

本发明涉及一种远程服务热部署方法，尤其是一种在网络中通过信任协商的方法进行的可信的远程服务热部署方法。

背景技术

SOA是Service Oriented Architecture(面向服务的架构)的简称。SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，独立于实现服务的硬件平台、操作***和编程语言。这使得构建在各种各样的***中的服务可以以一种统一和通用的方式进行交互。

对SOA的需求来源于需要使业务IT***变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT***既可以利用现有***的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

SOA本身是应该如何将软件组织在一起的抽象概念。它依赖于用XML和Web服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计***的支持，从而有效地工作。

SOA并不局限于Web服务。其他使用WSDL直接实现服务接口并通过XML消息进行通信的协议也可以包括在SOA中。比如，CORBA通过使用能够处理WSDL的新特征也可以参与到SOA中来。

其中XML是eXtensible Markup Language(可扩展的标记语言)的简称。它是一种元标记语言，即用于定义其它语言的语言。它使用简单灵活的标准格式，为基于web的应用提供了一个描述数据和交换数据的有效手段。XML描述了用于创建其他标记语言的语法。换言之，XML要说明如何开始与结束元素，元素名称可以使用的符号种类、如何嵌套元素、各元素要包含哪些特性等内容。但XML本身并不规定各元素要使用哪些元素。

近年来，Web服务技术已得到快速发展和应用，提供了面向Internet应用的统一服务注册、发现、绑定和集成机制，成为广域环境下实现互操作的一种主要机制，并得到学术界和产业界的广泛认可。

Web服务(Web service)是基于网络的、分布式的模块化组件，它执行特定的任务，遵循具体的技术规范，这些规范使得web service能与其他兼容的组件进行互操作。

Web service体系结构中共有三种角色：

Service Provider(服务提供者)：对外提供服务，并且通过注册来发布服务信息；

Service Register(服务注册者)：提供服务的注册和定位功能；

Service Requester(服务请求者)：通过Service Register查询所需服务，并通过Service Provider绑定服务。

Web service技术需要一套规范来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型***，要实现互操作性，web servi ce技术必须提供一套标准的类型***，用于沟通不同平台、编程语言和组件模型中的不同类型***。目前这些规范有：

XML：它是web service技术中表示数据的基本格式。XML主要的优点在于它既与平台无关，又与厂商无关。

SOAP：SOAP是Simple Object Acces s Protocol(简单对象访问协议)的简称，服务提供者和服务请求者之间通过传递SOAP消息来调用web服务。SOAP定义了请求和响应消息的格式，建立在XML之上，是一种跨平台的信息交换的简单包装方法。

WSDL：WSDL是Web Servi ce Descr i pt ion Language的简称，它的目的是用一种机器可读的方式为web服务提供一个基于XML的描述文档，用于描述web service及其操作。

UDDI：UDDI是Universal Description，Discovery and Integration的简称。UDDI是一套基于Web的、分布式的、为web服务提供的信息注册中心的实现标准规范。同时也包含一组使企业能将自身提供的web服务注册以使得别的企业能够发现的访问协议的实现标准。

网格是近年来逐渐兴起的一种Internet计算模式，其目的是为了在分布、异构、自治的网络资源环境之上构造动态的虚拟组织，并在其内部实现跨自治域的资源共享与资源协作，有效地满足面向互联网的复杂应用对大规模计算能力和海量数据处理的需求。网格计算的理想目标是使网络上的所有资源易于协同工作，服务于不同的网格应用，实现资源在跨组织间应用的共享与集成。网格研究源于分布式元计算，早期的网格研究多集中在“计算力”资源的共享和集成。目前应用资源的多样性为网格研究带来新的机遇和挑战，需要网格技术对异构资源提供无缝的共享和集成支持，这些资源不仅包括计算、存储、仪器设备等物理资源，也包括网络带宽和软件服务等逻辑资源。将Web服务技术引入网格研究领域，有助于解决网格研究所面临的应用集成、资源共享、***互操作和标准化等问题。2001年，人们提出了开放网格服务体系结构(Open Grid Service Architecture，OGSA)，将Web服务的互操作模型引入到网格研究中，确立了Web服务作为网格资源的新的抽象形式和构造基础。在网格服务体系结构下，网格中的所有软件、硬件、计算、存储、网络和设备等各种资源都被抽象成服务的形式，通过服务屏蔽资源之间的差异，从而有效地屏蔽网格中资源的异构性，为资源的共享和协同提供了有效的支持。在2003年3月的GGF7上，OGSA已经成为目前网格研究的主流方向。因此，Web服务技术极大地增强了网格协议和服务的互操作性，也为网格应用提供了一种统一的功能扩展机制。领域相关的功能可以通过引入新的应用服务扩充到网格***中，而新引入的服务与其他网格服务之间的交互则采用一致的服务交互模型。这种融合不仅解决了网格资源间的互操作问题，而且也使网格的应用不再局限于科学计算方面。

在网格的应用中，服务部署是一个重要的环节，服务部署是指把开发好的服务装载入服务容器，使其可被用户调用的过程。广义的服务部署还包括服务的反部署，即将服务从服务容器中卸载的过程，以及服务的重部署，即更新已经部署的服务的过程。热部署是指一个服务被部署到服务容器中之后，配置会自动更新，从而不需要用户重新启动服务容器即可被调用的过程。远程部署是指把要部署的服务传输到另外一台远程的服务容器上并实施部署的过程。服务部署是SOA架构中的一个普遍概念，并不局限于Web服务或服务网格。

可以把服务部署的概念和向计算机中安装一个软件的概念进行类比。一个软件在使用之前，必须首先安装到计算机***中；同样，一个服务在能够被调用之前，也必须首先部署到服务容器中。有的软件安装完成之后需要重新启动计算机***才能使用，这就给用户带来了某些不方便，在有些情况下，甚至是不可接受的，比如，在同一个计算机上还有别的用户登陆，那么，重启***必然会打断他们的工作。在服务部署中也有类似的问题，如果部署完一个服务后就需要重新启动容器，那么对其他服务的调用都会受到影响，因此，热部署在服务部署中是必需的。

目前有很多支持Web服务或服务网格的产品都对服务部署提供了一定程度上的支持。Apache Axis是由Apache组织开发的一个优秀的SOAP引擎，它需要执行一个命令才能完成Web服务的部署，并且不支持热部署和远程部署。由网格界著名的开放源码组织Globus所推出的网格中间件GlobusToolkit 4，主要完成服务的运行管理功能，但它对服务部署的支持很不完善。在Globus Toolkit中，服务开发人员在进行服务封装之后，只能通过繁琐的命令行来将服务部署到服务容器中，而且新部署的服务只能在服务容器重启之后才能生效。Globus Toolkit没有提供远程用户的部署服务。Friese et al提出了一种在网格中进行热部署的方法，为了保证安全，该方法采用了沙箱模型，但这样就限制了服务的功能。DistAnt扩展了Apache Ant，提供了一种灵活的过程式的部署描述，并基于Globus Toolkit3提出了一种远程热部署解决方案，但该方案没有提供任何安全机制。Baude et al采用ProActive(基于Java的并发，分布式和移动计算库)写成了一个部署方案，但该实现没有考虑反部署和动态更新。

由于SOA应用的广域，分布的特性，面临着很多安全问题。首先，传统的访问控制技术主要基于请求方的身份进行授权，需要设定统一的安全管理域。然而，在开放的互联网中，由于参与主体数量的规模大、运行环境的异构性、活动目标的动态性以及自主性等特点，SOA应用中的各资源主体往往隶属于不同的权威管理机构，即处在不同的安全域中，安全域是一个具有集中管理权威和安全策略的封闭域，活动中的每个实体都可以映射为域内控制的一种或多种主体身份，而跨安全域的联合协作属于组织频繁变化的活动，这就使得基于身份的访问控制技术在跨多安全域进行授权及访问控制时显得力不从心，暴露出许多弱点；其次，由于信息安全的隐患源于多个方面，对陌生方建立信任所依赖的信任状和访问控制策略中都可能泄露交互主体的敏感信息，特别是陌生方间很难再协定出彼此信任的第三方来协助他们建立信任关系。

传统的解决SOA应用的安全问题的方式有PKI、GSI等，下面分别介绍：

PKI是Public Key Infrastructure(公钥基础设施)的简称。这是一种利用公钥加密技术提供一套安全基础平台的技术和规范。PKI的核心组成部分是CA(Certification Authority)，即认证中心，它是数字证书的签发机构。数字证书，是一个符合一定格式的电子文件，用来识别证书持有者的身份。PKI技术采用证书管理公钥，通过第三方的可信任机构——认证中心CA，把用户的公钥和用户的其他标识信息(如名称、e-mail等)捆绑在一起，在Internet网上验证用户的身份。

但PKI需要一个第三方的可信任机构——认证中心CA，而对于远程部署来说，由于各方可能处于不同的安全域中，因此很难找出一个各方都信任的第三方CA；此外，即使能找到一个CA，如果要在每次执行远程部署的时候都基于PKI建立跨域的信任关系，代价又过于高昂。

GSI是Grid Security Infrastructure(网格安全基础设施)的简称。它是Globus Toolkit采用的安全机制。GSI基于公钥加密、X.509证书和SSL(Secure Socket Layer，安全套接字层)等标准。GSI的一个主要概念是证书，每个网格服务和用户都是通过证书来识别的，这个证书包含进行认证和识别这个用户或者服务所使用的信息。目前，Globus Toolkit已经发展到4.x版，安全机制存在的问题有：仍然缺乏一种基于属性的访问控制机制；对于安全的管理仍有很大的负担，缺乏灵活性，从而无法满足分散式的网络环境中的可扩展性的安全管理和信任建立机制；对于大规模动态协作应用，特别是跨安全域应用的支持还不够。虽然支持了类似MyProxy等委托机制和基于属性的访问控制技术，但缺乏对信任管理技术的充分支持，不能够运行时动态建立复杂信任链；GSI并没有考虑对主体敏感信息保护的方法，不能够维持服务请求方和目标服务的隐私信息。

对于远程服务热部署来说，由于缺乏合适的安全机制，存在如下的隐患：一方面，部署者很可能提供一个包含恶意代码的服务，从而对要部署的容器造成侵害；另一方面，服务容器也可能对部署者进行欺诈，从而获取一些它不应该知道的信息。另外，部署者和服务容器的安全策略可能是不兼容的，在一个开放的网络环境中，我们不能假设部署者和服务容器会事先建立信任关系。

发明内容

本发明针对现有技术中远程服务热部署中缺乏合适的安全机制的缺陷，提供一种可信的远程服务热部署方法，通过该方法为远程热部署提供了安全保障，解决了SOA中远程服务热部署的问题以及相关的安全隐患，极大的方便了用户，避免了为了部署服务而重启服务容器给用户带来的损失和效率的降低，解决了网络环境下跨安全域的部署者和服务容器之间建立信任关系的问题。

为实现上述发明目的，本发明提供了一种可信的远程服务热部署方法，包括如下步骤：

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

步骤2、部署者与服务容器进行信任协商，如果协商成功，则执行步骤3，否则，执行步骤4；

步骤3、所述服务容器执行热部署操作；

步骤4、结束。

在所述步骤1与步骤2之间还可以设有

步骤11、部署者检查是否已经配置了信任票据，如果是，则执行步骤12，如果不是，则执行步骤2，其中所述信任票据为部署者与服务容器进行信任协商成功后由部署者向服务容器申请获得的，所述信任票据中存储了信任协商的关键安全信息；

步骤12、部署者将所述信任票据提交给所述服务容器，所述服务容器验证所述信任票据，如果验证成功则执行步骤3，如果不成功，则执行步骤2。

所述步骤2可以具体为：

步骤21、所述服务容器从配置文件中获得部署服务的访问控制策略并发送给所述部署者；

步骤22、所述部署者查看自身是否有满足所述访问控制策略的证书，如果有，则执行步骤23，如果没有，则执行步骤4；

步骤23、将所述满足所述访问控制策略的证书发给所述服务容器；

步骤24、所述服务容器对证书进行检验，如果通过检验，则执行步骤3，如果没有通过检验，则执行步骤4。

在步骤22与步骤23之间还可以设有：

步骤22a、所述部署者向所述服务容器发送查看所述证书的访问控制策略；

步骤22b、所述服务容器查看是否有满足查看所述证书的访问控制策略的证书，如果有，则执行步骤22c，如果没有，则执行步骤4；

步骤22c、将所述满足查看所述证书的访问控制策略的证书发送给所述部署者；

步骤22d、所述部署者检验所述满足查看所述证书的访问控制策略的证书，如果通过检验，则执行步骤23，如果没有通过检验，则执行步骤4。

所述步骤3可以具体为：

步骤31、所述服务容器接收通过SOAP附件传输的网格归档(GAR，GridArchive)文件或从FTP服务器上下载网格归档文件；

步骤32、所述服务容器调用本地部署模块部署所述网格归档文件。

所述步骤32可以具体为：

步骤321、查看网格归档文件是否存在，如果不存在，则执行步骤4，如果存在则执行步骤322；

步骤322、判断ANT(一种基于Java的构建工具)环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤323；

步骤323、调用ANT工具将网格归档文件部署到服务容器中。

在所述步骤2与步骤3之间还可以设有反部署指定的网格归档文件的操作。

其中所述反部署指定的网格归档文件的操作具体为：

步骤31a、判断ANT环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤31b；

步骤31b、调用ANT工具将部署所述指定的网格归档文件时装载到服务容器中的所有配置信息和程序文件删除。

通过本发明提供的方法，为远程热部署提供了安全保障，解决了SOA中远程服务热部署的问题以及相关的安全隐患，极大的方便了用户，避免了为了部署服务而重启服务容器给用户带来的损失和效率的降低，解决了网络环境下跨安全域的部署者和服务容器之间建立信任关系的问题。

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

附图说明

图1为本发明的可信的远程服务热部署方法的流程图；

图2为本发明的ATN的工作原理示意图；

图3为本发明的服务部署模块的结构示意图；

图4为本发明的部署服务的流程图；

图5为本发明的反部署服务的流程图；

图6为本发明的ROST的信任协商原理示意图；

具体实施方式

参见图1，其为本发明的可信的远程服务热部署方法的流程图，包括如下步骤：

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

步骤2、部署者与服务容器进行信任协商，如果协商成功，则执行步骤3，否则，执行步骤4；

步骤3、所述服务容器执行热部署操作；

步骤4、结束。

可信的远程服务热部署(ROST，Remote & Hot Service Deployment withTrus twor thiness)包含两方面的含义：一是要支持服务的热部署和远程部署；二是要使这个远程部署过程是可信的，即要提供有效的安全机制。

为实现上述目的，本发明采用如下技术方案：在服务容器中以web服务的形式实现一个远程部署服务，负责接收从部署者传输过来的要部署的服务，并把这个服务部署到服务容器中。为了使服务部署后即可使用而不需要重新启动容器，远程部署服务要实现热部署功能；为了删除服务容器中已经部署好的服务，远程部署服务还需要提供反部署功能；为了更新服务容器中已经部署好的服务，远程部署服务还需要提供重部署的功能。为了保证远程部署的安全可信，在执行部署之前要进行信任协商，本发明中采用ATN(AutoTrust Negotiation，自动信任协商)技术进行信任协商，参见图2，其为本发明的ATN的工作原理示意图，其中主体A和主体B处在两个不同的安全域中。ATN是指通过信任状和访问控制策略的交互披露，使资源的提供方和请求方自动建立信任关系的机制。ATN是一种在开放的环境中进行访问控制的新技术，它尤其能在信任协商的过程中保护敏感信息。采用ATN技术，任何一方都可以是匿名的，双方可以根据各自的策略交换证书从而建立信任关系。相对于传统的机制，ATN技术有如下优势：

1)不在同一个安全域中的双方的信任关系能够根据各自的属性自动建立起来；

2)任何一方都可以制定自己的策略从而控制对敏感信息的访问；

3)不需要除证书颁发者之外的第三方就可以直接建立信任关系。

服务部署是由服务部署模块来完成的。参见图3，其为本发明的服务部署模块的结构示意图，该模块具有部署、重部署、反部署、热部署和远程部署功能，该模块是针对网格归档格式的文件的一系列操作过程，它包括本地文件夹监视接口、部署子模块、反部署子模块、重部署子模块和容器配置参数表；本地文件夹监视接口用于接收远程传输过来的网格归档文件，并将接收到的文件交给部署子模块、反部署子模块和重部署子模块；部署子模块、反部署子模块和重部署子模块在ANT技术的基础之上，将网格归档文件部署或反部署或重部署到服务容器内，在执行这些操作的过程中，容器的配置会动态进行更新；所述服务部署模块对接收到的远程网格归档文件，基于FTP/SOAP附件实现远程部署。

通常，一个网格归档文件包含了支持服务运行的若干个文件和配置信息，主要包括如下内容：

1)服务逻辑的执行程序，比如Java Class；

2)服务的WSDL描述文件；

3)针对服务容器所描述的服务配置信息WSDD(Web service DeploymentDescriptor，Web服务部署描述符)文档；

4)JNDI(Java Naming and Directory Interface，Java命名和目录服务接口)文件，描述服务所使用的WSRF资源的相关信息；

5)描述服务访问控制和授权信息的安全配置文件；

6)描述组合服务定义的BPEL(Business processs Execution Language，业务流程执行语言)文件；

7)其他文件，比如描述说明性质的文档。

这些文件中只有1、2和3是必需的，它们均由服务的开发人员提供，利用Java中的Jar命令将所有的文件压缩为一个网格归档文件，通过部署服务对网格归档文件的操作完成服务的部署。

参加图4，其为本发明的部署服务的流程图，包括如下步骤：

步骤321、查看网格归档文件是否存在，如果不存在，则执行步骤4，如果存在则执行步骤322；

步骤322、判断ANT环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤323；

步骤323、调用ANT工具将网格归档文件部署到服务容器中，具体工作包括解压缩网格归档文件、装载Java Class执行文件、解析WSDD配置文档并将配置信息装载到服务容器中、复制WSDL文件、解析JNDI配置文档；

其中ANT是一种基于Java的构建工具，用于对Java项目进行编译，打包，测试，发布等。

当需要重部署某个服务时，首先要反部署指定的网格归档文件，然后再部署指定的网格归档文件；

参见图5，其为本发明的反部署服务的流程图，包括如下步骤：

步骤31a、判断ANT环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤31b；

步骤31b、调用ANT工具将部署指定的网格归档文件时装载到服务容器中的所有配置信息和程序文件删除。

远程的服务部署可以通过FTP方式和SOAP附件方式来进行，当基于FTP方式进行远程部署时，部署过程为：

服务容器从FTP服务器上下载网格归档文件，然后所述服务容器调用本地部署模块部署所述网格归档文件。

当基于SOAP附件方式进行远程部署时，部署过程为：

服务容器接收通过SOAP附件传输的网格归档文件，然后服务容器调用本地的部署模块部署所述网格归档文件。

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

本发明的步骤2的信任协商的具体过程为

步骤21、所述服务容器从配置文件中获得部署服务的访问控制策略并发送给所述部署者；

步骤22、所述部署者查看自身是否有满足所述访问控制策略的证书，如果有，则执行步骤23，如果没有，则执行步骤4；

步骤23、将所述满足所述访问控制策略的证书发给所述服务容器；

步骤24、所述服务容器对证书进行检验，如果通过检验，则执行步骤3，如果没有通过验证，则执行步骤4。

为了保护部署者的证书中的敏感信息，在步骤22与步骤23之间还设有

步骤22a、所述部署者向所述服务容器发送查看所述证书的访问控制策略；

步骤22b、所述服务容器查看是否有满足查看所述证书的访问控制策略的证书，如果有，则执行步骤22c，如果没有，则执行步骤4；

步骤22c、将所述满足查看所述证书的访问控制策略的证书发送给所述部署者；

步骤22d、所述部署者检验所述满足查看所述证书的访问控制策略的证书，如果通过检验，则执行步骤23，如果没有通过检验，则执行步骤4。

下面进一步说明本发明的信任协商过程，参见图6，其为本发明的ROST的信任协商原理示意图，部署者在安全域A中，而服务容器在安全域B中。部署者向服务容器提出一个部署请求，容器在收到这个请求后，根据它自身的策略，要求部署者提供一定的证书才允许部署操作的执行。然后部署者提供相应的证书给服务容器，服务容器在对这些证书进行验证后，把协商结果告诉部署者。如果证书是合法的，则允许部署操作继续进行，否则，该操作被拒绝。

下面通过一个具体的例子来说明部署中的信任协商过程。我们假设部署者D需要把一个服务部署到服务容器T上。信任协商的步骤如下：

1)D向T发送一个部署请求R_dep。

2)T把自己的访问策略(只有同时拥有证书CA1和CA2的节点才允许执行部署操作)告诉D。

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

4)T有证书CB1，于是它把CB1发给D。

5)D收到CB1后，经过验证，把CA2发给T。

6)T把协商成功的结果发给D。

经过上面几步的交互，D和T已经建立了信任关系。接下来就可以把网格归档包从D传输给T，进行部署了。

一次协商过程可能会花费比较长的时间。此外，在有些情况下，用户需要更新已经部署过的服务，没有必要再进行一遍协商。为了提高协商的效率，我们在ROST里提出了信任票据的概念。在一次成功的信任协商之后，部署者可以向服务容器申请一个信任票据，在这个信任票据里，存储了一些信任协商的关键安全信息。有了信任票据，部署者就不需要和这个服务容器再次进行信任协商，只需要出示他的信任票据就行了。因此本发明的方法在所述步骤1与步骤2之间还设有：

步骤11、部署者检查是否已经配置了信任票据，如果是，则执行步骤12，如果不是，则执行步骤2；

步骤12、部署者将所述信任票据提交给所述服务容器，所述服务容器验证所述信任票据，如果验证成功则执行步骤3，如果不成功，则执行步骤2。

为保证更高的安全性，信任票据可由颁发的服务容器签名并具有有限的生命期。

在ROST中，我们采用精确的RTML(Role-Based Trust ManagementLanguage Markup Language，基于角色的信任管理标记语言)来描述访问控制策略和基于属性的证书。当证书的存储是分布式的时候，目标指向的算法确保了所有可用的证书都能被发现和收集。在ROST的设计中，信任票据的格式为：<subject，issuer，subject，valid date，expiration date，signature>。

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

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

Claims (8)

1、一种可信的远程服务热部署方法，其特征在于包括如下步骤：

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

步骤2、部署者与服务容器进行信任协商，如果协商成功，则执行步骤3，否则，执行步骤4；

步骤3、所述服务容器执行热部署操作；

步骤4、结束。

2、根据权利要求1所述的可信的远程服务热部署方法，其特征在于在所述步骤1与步骤2之间还设有：

步骤11、部署者检查是否已经配置了信任票据，如果是，则执行步骤12，如果不是，则执行步骤2，其中所述信任票据为部署者与服务容器进行信任协商成功后由部署者向服务容器申请获得的，所述信任票据中存储了信任协商的关键安全信息；

步骤12、部署者将所述信任票据提交给所述服务容器，所述服务容器验证所述信任票据，如果验证成功则执行步骤3，如果不成功，则执行步骤2。

3、根据权利要求1所述的可信的远程服务热部署方法，其特征在于所述步骤2具体为：

步骤21、所述服务容器从配置文件中获得部署服务的访问控制策略并发送给所述部署者；

步骤22、所述部署者查看其自身是否有满足所述访问控制策略的证书，如果有，则执行步骤23，如果没有，则执行步骤4；

步骤23、将所述满足所述访问控制策略的证书发给所述服务容器；

步骤24、所述服务容器对证书进行检验，如果通过检验，则执行步骤3，如果没有通过检验，则执行步骤4。

4、根据权利要求3所述的可信的远程服务热部署方法，其特征在于在步骤22与步骤23之间还设有：

步骤22a、所述部署者向所述服务容器发送查看所述证书的访问控制策略；

步骤22b、所述服务容器查看是否有满足查看所述证书的访问控制策略的证书，如果有，则执行步骤22c，如果没有，则执行步骤4；

步骤22c、将所述满足查看所述证书的访问控制策略的证书发送给所述部署者；

步骤22d、所述部署者检验所述满足查看所述证书的访问控制策略的证书，如果通过检验，则执行步骤23，如果没有通过检验，则执行步骤4。

5、根据权利要求1至5任一所述的可信的远程服务热部署方法，其特征在于所述步骤3具体为：

步骤31、所述服务容器接收通过简单对象访问协议SOAP附件传输的网格归档文件或从FTP服务器上下载网格归档文件；

步骤32、所述服务容器调用本地部署模块部署所述网格归档文件。

6、根据权利要求5所述的可信的远程服务热部署方法，其特征在于所述步骤32具体为：

步骤321、查看网格归档文件是否存在，如果不存在，则执行步骤4，如果存在则执行步骤322；

步骤322、判断ANT环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤323；

步骤323、调用ANT工具将网格归档文件部署到服务容器中。

7、根据权利要求1所述的可信的远程服务热部署方法，其特征在于在所述步骤2与步骤3之间还设有反部署指定的网格归档文件的操作。

8、根据权利要求7所述的可信的远程服务热部署方法，其特征在于所述反部署指定的网格归档文件的操作具体为：

步骤31a、判断ANT环境是否可用，如果不可用，则执行步骤4，如果可用，则执行步骤31b；

步骤31b、调用ANT工具将部署所述指定的网格归档文件时装载到服务容器中的所有配置信息和程序文件删除。

Images