專利名稱：可信的遠程服務(wù)熱部署方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種遠程服務(wù)熱部署方法，尤其是一種在網(wǎng)絡(luò)中通過信任協(xié)商的方法進行的可信的遠程服務(wù)熱部署方法。
背景技術(shù)：
SOA是Service Oriented Architecture(面向服務(wù)的架構(gòu))的簡稱。SOA是一個組件模型，它將應(yīng)用程序的不同功能單元(稱為服務(wù))通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口采用中立的方式進行定義，獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互。
對SOA的需求來源于需要使業(yè)務(wù)IT系統(tǒng)變得更加靈活，以適應(yīng)業(yè)務(wù)中的改變。通過允許強定義的關(guān)系和依然靈活的特定實現(xiàn)，IT系統(tǒng)既可以利用現(xiàn)有系統(tǒng)的功能，又可以準備在以后做一些改變來滿足它們之間交互的需要。
SOA本身是應(yīng)該如何將軟件組織在一起的抽象概念。它依賴于用XML和Web服務(wù)實現(xiàn)并以軟件的形式存在的更加具體的觀念和技術(shù)。此外，它還需要安全性、策略管理、可靠消息傳遞以及會計系統(tǒng)的支持，從而有效地工作。
SOA并不局限于Web服務(wù)。其他使用WSDL直接實現(xiàn)服務(wù)接口并通過XML消息進行通信的協(xié)議也可以包括在SOA中。比如，CORBA通過使用能夠處理WSDL的新特征也可以參與到SOA中來。
其中XML是eXtensible Markup Language(可擴展的標記語言)的簡稱。它是一種元標記語言，即用于定義其它語言的語言。它使用簡單靈活的標準格式，為基于web的應(yīng)用提供了一個描述數(shù)據(jù)和交換數(shù)據(jù)的有效手段。XML描述了用于創(chuàng)建其他標記語言的語法。換言之，XML要說明如何開始與結(jié)束元素，元素名稱可以使用的符號種類、如何嵌套元素、各元素要包含哪些特性等內(nèi)容。但XML本身并不規(guī)定各元素要使用哪些元素。
近年來，Web服務(wù)技術(shù)已得到快速發(fā)展和應(yīng)用，提供了面向Internet應(yīng)用的統(tǒng)一服務(wù)注冊、發(fā)現(xiàn)、綁定和集成機制，成為廣域環(huán)境下實現(xiàn)互操作的一種主要機制，并得到學(xué)術(shù)界和產(chǎn)業(yè)界的廣泛認可。
Web服務(wù)(Web service)是基于網(wǎng)絡(luò)的、分布式的模塊化組件，它執(zhí)行特定的任務(wù)，遵循具體的技術(shù)規(guī)范，這些規(guī)范使得web service能與其他兼容的組件進行互操作。
Web service體系結(jié)構(gòu)中共有三種角色Service Provider(服務(wù)提供者)對外提供服務(wù)，并且通過注冊來發(fā)布服務(wù)信息；Service Register(服務(wù)注冊者)提供服務(wù)的注冊和定位功能；Service Requester(服務(wù)請求者)通過Service Register查詢所需服務(wù)，并通過Service Provider綁定服務(wù)。
Web service技術(shù)需要一套規(guī)范來實現(xiàn)分布式應(yīng)用程序的創(chuàng)建。任何平臺都有它的數(shù)據(jù)表示方法和類型系統(tǒng)，要實現(xiàn)互操作性，web service技術(shù)必須提供一套標準的類型系統(tǒng)，用于溝通不同平臺、編程語言和組件模型中的不同類型系統(tǒng)。目前這些規(guī)范有XML它是web service技術(shù)中表示數(shù)據(jù)的基本格式。XML主要的優(yōu)點在于它既與平臺無關(guān)，又與廠商無關(guān)。
SOAPSOAP是Simple Object Access Protocol的簡稱，服務(wù)提供者和服務(wù)請求者之間通過傳遞SOAP消息來調(diào)用web服務(wù)。SOAP定義了請求和響應(yīng)消息的格式，建立在XML之上，是一種跨平臺的信息交換的簡單包裝方法。
WSDLWSDL是Web Service Description Language的簡稱，它的目的是用一種機器可讀的方式為web服務(wù)提供一個基于XML的描述文檔，用于描述web service及其操作。
UDDIUDDI是Universal Description，Discovery and Integration的簡稱。UDDI是一套基于Web的、分布式的、為web服務(wù)提供的信息注冊中心的實現(xiàn)標準規(guī)范。同時也包含一組使企業(yè)能將自身提供的web服務(wù)注冊以使得別的企業(yè)能夠發(fā)現(xiàn)的訪問協(xié)議的實現(xiàn)標準。
網(wǎng)格是近年來逐漸興起的一種Internet計算模式，其目的是為了在分布、異構(gòu)、自治的網(wǎng)絡(luò)資源環(huán)境之上構(gòu)造動態(tài)的虛擬組織，并在其內(nèi)部實現(xiàn)跨自治域的資源共享與資源協(xié)作，有效地滿足面向互聯(lián)網(wǎng)的復(fù)雜應(yīng)用對大規(guī)模計算能力和海量數(shù)據(jù)處理的需求。網(wǎng)格計算的理想目標是使網(wǎng)絡(luò)上的所有資源易于協(xié)同工作，服務(wù)于不同的網(wǎng)格應(yīng)用，實現(xiàn)資源在跨組織間應(yīng)用的共享與集成。網(wǎng)格研究源于分布式元計算，早期的網(wǎng)格研究多集中在“計算力”資源的共享和集成。目前應(yīng)用資源的多樣性為網(wǎng)格研究帶來新的機遇和挑戰(zhàn)，需要網(wǎng)格技術(shù)對異構(gòu)資源提供無縫的共享和集成支持，這些資源不僅包括計算、存儲、儀器設(shè)備等物理資源，也包括網(wǎng)絡(luò)帶寬和軟件服務(wù)等邏輯資源。將Web服務(wù)技術(shù)引入網(wǎng)格研究領(lǐng)域，有助于解決網(wǎng)格研究所面臨的應(yīng)用集成、資源共享、系統(tǒng)互操作和標準化等問題。2001年，人們提出了開放網(wǎng)格服務(wù)體系結(jié)構(gòu)(Open Grid Service Architecture，OGSA)，將Web服務(wù)的互操作模型引入到網(wǎng)格研究中，確立了Web服務(wù)作為網(wǎng)格資源的新的抽象形式和構(gòu)造基礎(chǔ)。在網(wǎng)格服務(wù)體系結(jié)構(gòu)下，網(wǎng)格中的所有軟件、硬件、計算、存儲、網(wǎng)絡(luò)和設(shè)備等各種資源都被抽象成服務(wù)的形式，通過服務(wù)屏蔽資源之間的差異，從而有效地屏蔽網(wǎng)格中資源的異構(gòu)性，為資源的共享和協(xié)同提供了有效的支持。在2003年3月的GGF7上，OGSA已經(jīng)成為目前網(wǎng)格研究的主流方向。因此，Web服務(wù)技術(shù)極大地增強了網(wǎng)格協(xié)議和服務(wù)的互操作性，也為網(wǎng)格應(yīng)用提供了一種統(tǒng)一的功能擴展機制。領(lǐng)域相關(guān)的功能可以通過引入新的應(yīng)用服務(wù)擴充到網(wǎng)格系統(tǒng)中，而新引入的服務(wù)與其他網(wǎng)格服務(wù)之間的交互則采用一致的服務(wù)交互模型。這種融合不僅解決了網(wǎng)格資源間的互操作問題，而且也使網(wǎng)格的應(yīng)用不再局限于科學(xué)計算方面。
在網(wǎng)格的應(yīng)用中，服務(wù)部署是一個重要的環(huán)節(jié)，服務(wù)部署是指把開發(fā)好的服務(wù)裝載入服務(wù)容器，使其可被用戶調(diào)用的過程。廣義的服務(wù)部署還包括服務(wù)的反部署，即將服務(wù)從服務(wù)容器中卸載的過程，以及服務(wù)的重部署，即更新已經(jīng)部署的服務(wù)的過程。熱部署是指一個服務(wù)被部署到服務(wù)容器中之后，配置會自動更新，從而不需要用戶重新啟動服務(wù)容器即可被調(diào)用的過程。遠程部署是指把要部署的服務(wù)傳輸?shù)搅硗庖慌_遠程的服務(wù)容器上并實施部署的過程。服務(wù)部署是SOA架構(gòu)中的一個普遍概念，并不局限于Web服務(wù)或服務(wù)網(wǎng)格。
可以把服務(wù)部署的概念和向計算機中安裝一個軟件的概念進行類比。一個軟件在使用之前，必須首先安裝到計算機系統(tǒng)中；同樣，一個服務(wù)在能夠被調(diào)用之前，也必須首先部署到服務(wù)容器中。有的軟件安裝完成之后需要重新啟動計算機系統(tǒng)才能使用，這就給用戶帶來了某些不方便，在有些情況下，甚至是不可接受的，比如，在同一個計算機上還有別的用戶登陸，那么，重啟系統(tǒng)必然會打斷他們的工作。在服務(wù)部署中也有類似的問題，如果部署完一個服務(wù)后就需要重新啟動容器，那么對其他服務(wù)的調(diào)用都會受到影響，因此，熱部署在服務(wù)部署中是必需的。
目前有很多支持Web服務(wù)或服務(wù)網(wǎng)格的產(chǎn)品都對服務(wù)部署提供了一定程度上的支持。Apache Axis是由Apache組織開發(fā)的一個優(yōu)秀的SOAP引擎，它需要執(zhí)行一個命令才能完成Web服務(wù)的部署，并且不支持熱部署和遠程部署。由網(wǎng)格界著名的開放源碼組織Globus所推出的網(wǎng)格中間件GlobusToolkit4，主要完成服務(wù)的運行管理功能，但它對服務(wù)部署的支持很不完善。在Globus Toolkit中，服務(wù)開發(fā)人員在進行服務(wù)封裝之后，只能通過繁瑣的命令行來將服務(wù)部署到服務(wù)容器中，而且新部署的服務(wù)只能在服務(wù)容器重啟之后才能生效。Globus Toolkit沒有提供遠程用戶的部署服務(wù)。Friese et al提出了一種在網(wǎng)格中進行熱部署的方法，為了保證安全，該方法采用了沙箱模型，但這樣就限制了服務(wù)的功能。DistAnt擴展了Apache Ant，提供了一種靈活的過程式的部署描述，并基于Globus Toolkit3提出了一種遠程熱部署解決方案，但該方案沒有提供任何安全機制。Baude et al采用ProActive(基于Java的并發(fā)，分布式和移動計算庫)寫成了一個部署方案，但該實現(xiàn)沒有考慮反部署和動態(tài)更新。
由于SOA應(yīng)用的廣域，分布的特性，面臨著很多安全問題。首先，傳統(tǒng)的訪問控制技術(shù)主要基于請求方的身份進行授權(quán)，需要設(shè)定統(tǒng)一的安全管理域。然而，在開放的互聯(lián)網(wǎng)中，由于參與主體數(shù)量的規(guī)模大、運行環(huán)境的異構(gòu)性、活動目標的動態(tài)性以及自主性等特點，SOA應(yīng)用中的各資源主體往往隸屬于不同的權(quán)威管理機構(gòu)，即處在不同的安全域中，安全域是一個具有集中管理權(quán)威和安全策略的封閉域，活動中的每個實體都可以映射為域內(nèi)控制的一種或多種主體身份，而跨安全域的聯(lián)合協(xié)作屬于組織頻繁變化的活動，這就使得基于身份的訪問控制技術(shù)在跨多安全域進行授權(quán)及訪問控制時顯得力不從心，暴露出許多弱點；其次，由于信息安全的隱患源于多個方面，對陌生方建立信任所依賴的信任狀和訪問控制策略中都可能泄露交互主體的敏感信息，特別是陌生方間很難再協(xié)定出彼此信任的第三方來協(xié)助他們建立信任關(guān)系。
傳統(tǒng)的解決SOA應(yīng)用的安全問題的方式有PKI、GSI等，下面分別介紹PKI是Public Key Infrastructure(公鑰基礎(chǔ)設(shè)施)的簡稱。這是一種利用公鑰加密技術(shù)提供一套安全基礎(chǔ)平臺的技術(shù)和規(guī)范。PKI的核心組成部分是CA(Certification Authority)，即認證中心，它是數(shù)字證書的簽發(fā)機構(gòu)。數(shù)字證書，是一個符合一定格式的電子文件，用來識別證書持有者的身份。PKI技術(shù)采用證書管理公鑰，通過第三方的可信任機構(gòu)——認證中心CA，把用戶的公鑰和用戶的其他標識信息(如名稱、e-mail等)捆綁在一起，在Internet網(wǎng)上驗證用戶的身份。
但PKI需要一個第三方的可信任機構(gòu)——認證中心CA，而對于遠程部署來說，由于各方可能處于不同的安全域中，因此很難找出一個各方都信任的第三方CA；此外，即使能找到一個CA，如果要在每次執(zhí)行遠程部署的時候都基于PKI建立跨域的信任關(guān)系，代價又過于高昂。
GSI是Grid Security Infrastructure(網(wǎng)格安全基礎(chǔ)設(shè)施)的簡稱。它是Globus Toolkit采用的安全機制。GSI基于公鑰加密、X.509證書和SSL(Secure Socket Layer，安全套接字層)等標準。GSI的一個主要概念是證書，每個網(wǎng)格服務(wù)和用戶都是通過證書來識別的，這個證書包含進行認證和識別這個用戶或者服務(wù)所使用的信息。目前，Globus Toolkit已經(jīng)發(fā)展到4.x版，安全機制存在的問題有仍然缺乏一種基于屬性的訪問控制機制；對于安全的管理仍有很大的負擔(dān)，缺乏靈活性，從而無法滿足分散式的網(wǎng)絡(luò)環(huán)境中的可擴展性的安全管理和信任建立機制；對于大規(guī)模動態(tài)協(xié)作應(yīng)用，特別是跨安全域應(yīng)用的支持還不夠。雖然支持了類似MyProxy等委托機制和基于屬性的訪問控制技術(shù)，但缺乏對信任管理技術(shù)的充分支持，不能夠運行時動態(tài)建立復(fù)雜信任鏈；GSI并沒有考慮對主體敏感信息保護的方法，不能夠維持服務(wù)請求方和目標服務(wù)的隱私信息。
對于遠程服務(wù)熱部署來說，由于缺乏合適的安全機制，存在如下的隱患一方面，部署者很可能提供一個包含惡意代碼的服務(wù)，從而對要部署的容器造成侵害；另一方面，服務(wù)容器也可能對部署者進行欺詐，從而獲取一些它不應(yīng)該知道的信息。另外，部署者和服務(wù)容器的安全策略可能是不兼容的，在一個開放的網(wǎng)絡(luò)環(huán)境中，我們不能假設(shè)部署者和服務(wù)容器會事先建立信任關(guān)系。

發(fā)明內(nèi)容
本發(fā)明針對現(xiàn)有技術(shù)中遠程服務(wù)熱部署中缺乏合適的安全機制的缺陷，提供一種可信的遠程服務(wù)熱部署方法，通過該方法為遠程熱部署提供了安全保障，解決了SOA中遠程服務(wù)熱部署的問題以及相關(guān)的安全隱患，極大的方便了用戶，避免了為了部署服務(wù)而重啟服務(wù)容器給用戶帶來的損失和效率的降低，解決了網(wǎng)絡(luò)環(huán)境下跨安全域的部署者和服務(wù)容器之間建立信任關(guān)系的問題。
為實現(xiàn)上述發(fā)明目的，本發(fā)明提供了一種可信的遠程服務(wù)熱部署方法，包括如下步驟步驟1、部署者向遠程的服務(wù)容器發(fā)出服務(wù)部署請求；步驟2、部署者與服務(wù)容器進行信任協(xié)商，如果協(xié)商成功，則執(zhí)行步驟3，否則，執(zhí)行步驟4；步驟3、所述服務(wù)容器執(zhí)行熱部署操作；步驟4、結(jié)束。
在所述步驟1與步驟2之間還可以設(shè)有步驟11、部署者檢查是否已經(jīng)配置了信任票據(jù)，如果是，則執(zhí)行步驟12，如果不是，則執(zhí)行步驟2，其中所述信任票據(jù)為部署者與服務(wù)容器進行信任協(xié)商成功后由部署者向服務(wù)容器申請獲得的，所述信任票據(jù)中存儲了信任協(xié)商的關(guān)鍵安全信息；步驟12、部署者將所述信任票據(jù)提交給所述服務(wù)容器，所述服務(wù)容器驗證所述信任票據(jù)，如果驗證成功則執(zhí)行步驟3，如果不成功，則執(zhí)行步驟2。
所述步驟2可以具體為步驟21、所述服務(wù)容器從配置文件中獲得部署服務(wù)的訪問控制策略并發(fā)送給所述部署者；步驟22、所述部署者查看自身是否有滿足所述訪問控制策略的證書，如果有，則執(zhí)行步驟23，如果沒有，則執(zhí)行步驟4；步驟23、將所述滿足所述訪問控制策略的證書發(fā)給所述服務(wù)容器；步驟24、所述服務(wù)容器對證書進行檢驗，如果通過檢驗，則執(zhí)行步驟3，如果沒有通過檢驗，則執(zhí)行步驟4。
在步驟22與步驟23之間還可以設(shè)有步驟22a、所述部署者向所述服務(wù)容器發(fā)送查看所述證書的訪問控制策略；步驟22b、所述服務(wù)容器查看是否有滿足查看所述證書的訪問控制策略的證書，如果有，則執(zhí)行步驟22c，如果沒有，則執(zhí)行步驟4；步驟22c、將所述滿足查看所述證書的訪問控制策略的證書發(fā)送給所述部署者；步驟22d、所述部署者檢驗所述滿足查看所述證書的訪問控制策略的證書，如果通過檢驗，則執(zhí)行步驟23，如果沒有通過檢驗，則執(zhí)行步驟4。
所述步驟3可以具體為步驟31、所述服務(wù)容器接收通過SOAP附件傳輸?shù)木W(wǎng)格歸檔(GAR，GridArchive)文件或從FTP服務(wù)器上下載網(wǎng)格歸檔文件；步驟32、所述服務(wù)容器調(diào)用本地部署模塊部署所述網(wǎng)格歸檔文件。
所述步驟32可以具體為步驟321、查看網(wǎng)格歸檔文件是否存在，如果不存在，則執(zhí)行步驟4，如果存在則執(zhí)行步驟322；步驟322、判斷ANT(一種基于Java的構(gòu)建工具)環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟323；步驟323、調(diào)用ANT工具將網(wǎng)格歸檔文件部署到服務(wù)容器中。
在所述步驟2與步驟3之間還可以設(shè)有反部署指定的網(wǎng)格歸檔文件的操作。
其中所述反部署指定的網(wǎng)格歸檔文件的操作具體為步驟31a、判斷ANT環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟31b；步驟31b、調(diào)用ANT工具將部署所述指定的網(wǎng)格歸檔文件時裝載到服務(wù)容器中的所有配置信息和程序文件刪除。
通過本發(fā)明提供的方法，為遠程熱部署提供了安全保障，解決了SOA中遠程服務(wù)熱部署的問題以及相關(guān)的安全隱患，極大的方便了用戶，避免了為了部署服務(wù)而重啟服務(wù)容器給用戶帶來的損失和效率的降低，解決了網(wǎng)絡(luò)環(huán)境下跨安全域的部署者和服務(wù)容器之間建立信任關(guān)系的問題。
下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進一步的詳細描述。


圖1為本發(fā)明的可信的遠程服務(wù)熱部署方法的流程圖；圖2為本發(fā)明的ATN的工作原理示意圖；圖3為本發(fā)明的服務(wù)部署模塊的結(jié)構(gòu)示意圖；
圖4為本發(fā)明的部署服務(wù)的流程圖；圖5為本發(fā)明的反部署服務(wù)的流程圖；圖6為本發(fā)明的ROST的信任協(xié)商原理示意圖；具體實施方式
參見圖1，其為本發(fā)明的可信的遠程服務(wù)熱部署方法的流程圖，包括如下步驟步驟1、部署者向遠程的服務(wù)容器發(fā)出服務(wù)部署請求；步驟2、部署者與服務(wù)容器進行信任協(xié)商，如果協(xié)商成功，則執(zhí)行步驟3，否則，執(zhí)行步驟4；步驟3、所述服務(wù)容器執(zhí)行熱部署操作；步驟4、結(jié)束。
可信的遠程服務(wù)熱部署(ROST，Remote&Hot Service Deployment withTrustworthiness)包含兩方面的含義一是要支持服務(wù)的熱部署和遠程部署；二是要使這個遠程部署過程是可信的，即要提供有效的安全機制。
為實現(xiàn)上述目的，本發(fā)明采用如下技術(shù)方案在服務(wù)容器中以web服務(wù)的形式實現(xiàn)一個遠程部署服務(wù)，負責(zé)接收從部署者傳輸過來的要部署的服務(wù)，并把這個服務(wù)部署到服務(wù)容器中。為了使服務(wù)部署后即可使用而不需要重新啟動容器，遠程部署服務(wù)要實現(xiàn)熱部署功能；為了刪除服務(wù)容器中已經(jīng)部署好的服務(wù)，遠程部署服務(wù)還需要提供反部署功能；為了更新服務(wù)容器中已經(jīng)部署好的服務(wù)，遠程部署服務(wù)還需要提供重部署的功能。為了保證遠程部署的安全可信，在執(zhí)行部署之前要進行信任協(xié)商，本發(fā)明中采用ATN(AutoTrust Negotiation，自動信任協(xié)商)技術(shù)進行信任協(xié)商，參見圖2，其為本發(fā)明的ATN的工作原理示意圖，其中主體A和主體B處在兩個不同的安全域中。ATN是指通過信任狀和訪問控制策略的交互披露，使資源的提供方和請求方自動建立信任關(guān)系的機制。ATN是一種在開放的環(huán)境中進行訪問控制的新技術(shù)，它尤其能在信任協(xié)商的過程中保護敏感信息。采用ATN技術(shù)，任何一方都可以是匿名的，雙方可以根據(jù)各自的策略交換證書從而建立信任關(guān)系。相對于傳統(tǒng)的機制，ATN技術(shù)有如下優(yōu)勢1)不在同一個安全域中的雙方的信任關(guān)系能夠根據(jù)各自的屬性自動建立起來；2)任何一方都可以制定自己的策略從而控制對敏感信息的訪問；3)不需要除證書頒發(fā)者之外的第三方就可以直接建立信任關(guān)系。
服務(wù)部署是由服務(wù)部署模塊來完成的。參見圖3，其為本發(fā)明的服務(wù)部署模塊的結(jié)構(gòu)示意圖，該模塊具有部署、重部署、反部署、熱部署和遠程部署功能，該模塊是針對網(wǎng)格歸檔格式的文件的一系列操作過程，它包括本地文件夾監(jiān)視接口、部署子模塊、反部署子模塊、重部署子模塊和容器配置參數(shù)表；本地文件夾監(jiān)視接口用于接收遠程傳輸過來的網(wǎng)格歸檔文件，并將接收到的文件交給部署子模塊、反部署子模塊和重部署子模塊；部署子模塊、反部署子模塊和重部署子模塊在ANT技術(shù)的基礎(chǔ)之上，將網(wǎng)格歸檔文件部署或反部署或重部署到服務(wù)容器內(nèi)，在執(zhí)行這些操作的過程中，容器的配置會動態(tài)進行更新；所述服務(wù)部署模塊對接收到的遠程網(wǎng)格歸檔文件，基于FTP/SOAP附件實現(xiàn)遠程部署。
通常，一個網(wǎng)格歸檔文件包含了支持服務(wù)運行的若干個文件和配置信息，主要包括如下內(nèi)容1)服務(wù)邏輯的執(zhí)行程序，比如Java Class；2)服務(wù)的WSDL描述文件；3)針對服務(wù)容器所描述的服務(wù)配置信息WSDD(Web Service DeploymentDescriptor，Web服務(wù)部署描述符)文檔；4)JNDI(Java Naming and Directory Interface，Java命名和目錄服務(wù)接口)文件，描述服務(wù)所使用的WSRF資源的相關(guān)信息；5)描述服務(wù)訪問控制和授權(quán)信息的安全配置文件；6)描述組合服務(wù)定義的BPEL(Business processs Execution Language，業(yè)務(wù)流程執(zhí)行語言)文件；
7)其他文件，比如描述說明性質(zhì)的文檔。
這些文件中只有1、2和3是必需的，它們均由服務(wù)的開發(fā)人員提供，利用Java中的Jar命令將所有的文件壓縮為一個網(wǎng)格歸檔文件，通過部署服務(wù)對網(wǎng)格歸檔文件的操作完成服務(wù)的部署。
參加圖4，其為本發(fā)明的部署服務(wù)的流程圖，包括如下步驟步驟321、查看網(wǎng)格歸檔文件是否存在，如果不存在，則執(zhí)行步驟4，如果存在則執(zhí)行步驟322；步驟322、判斷ANT環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟323；步驟323、調(diào)用ANT工具將網(wǎng)格歸檔文件部署到服務(wù)容器中，具體工作包括解壓縮網(wǎng)格歸檔文件、裝載Java Class執(zhí)行文件、解析WSDD配置文檔并將配置信息裝載到服務(wù)容器中、復(fù)制WSDL文件、解析JNDI配置文檔；其中ANT是一種基于Java的構(gòu)建工具，用于對Java項目進行編譯，打包，測試，發(fā)布等。
當(dāng)需要重部署某個服務(wù)時，首先要反部署指定的網(wǎng)格歸檔文件，然后再部署指定的網(wǎng)格歸檔文件；參見圖5，其為本發(fā)明的反部署服務(wù)的流程圖，包括如下步驟步驟31a、判斷ANT環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟31b；步驟31b、調(diào)用ANT工具將部署指定的網(wǎng)格歸檔文件時裝載到服務(wù)容器中的所有配置信息和程序文件刪除。
遠程的服務(wù)部署可以通過FTP方式和SOAP附件方式來進行，當(dāng)基于FTP方式進行遠程部署時，部署過程為服務(wù)容器從FTP服務(wù)器上下載網(wǎng)格歸檔文件，然后所述服務(wù)容器調(diào)用本地部署模塊部署所述網(wǎng)格歸檔文件。
當(dāng)基于SOAP附件方式進行遠程部署時，部署過程為服務(wù)容器接收通過SOAP附件傳輸?shù)木W(wǎng)格歸檔文件，然后服務(wù)容器調(diào)用本地的部署模塊部署所述網(wǎng)格歸檔文件。
在ROST中，服務(wù)容器在信任部署者之前，它需要部署者出示證書并且指定一些關(guān)鍵屬性。另一方面，如前所述，在證書中可能包含敏感信息，因此必須制定相應(yīng)的策略來保護這些信息。這些策略指定了證書暴露給對方之前，對方必須滿足什么條件。因此，信任協(xié)商主要就是根據(jù)各自的策略交換證書的過程。
本發(fā)明的步驟2的信任協(xié)商的具體過程為步驟21、所述服務(wù)容器從配置文件中獲得部署服務(wù)的訪問控制策略并發(fā)送給所述部署者；步驟22、所述部署者查看自身是否有滿足所述訪問控制策略的證書，如果有，則執(zhí)行步驟23，如果沒有，則執(zhí)行步驟4；步驟23、將所述滿足所述訪問控制策略的證書發(fā)給所述服務(wù)容器；步驟24、所述服務(wù)容器對證書進行檢驗，如果通過檢驗，則執(zhí)行步驟3，如果沒有通過驗證，則執(zhí)行步驟4。
為了保護部署者的證書中的敏感信息，在步驟22與步驟23之間還設(shè)有步驟22a、所述部署者向所述服務(wù)容器發(fā)送查看所述證書的訪問控制策略；步驟22b、所述服務(wù)容器查看是否有滿足查看所述證書的訪問控制策略的證書，如果有，則執(zhí)行步驟22c，如果沒有，則執(zhí)行步驟4；步驟22c、將所述滿足查看所述證書的訪問控制策略的證書發(fā)送給所述部署者；步驟22d、所述部署者檢驗所述滿足查看所述證書的訪問控制策略的證書，如果通過檢驗，則執(zhí)行步驟23，如果沒有通過檢驗，則執(zhí)行步驟4。
下面進一步說明本發(fā)明的信任協(xié)商過程，參見圖6，其為本發(fā)明的ROST的信任協(xié)商原理示意圖，部署者在安全域A中，而服務(wù)容器在安全域B中。部署者向服務(wù)容器提出一個部署請求，容器在收到這個請求后，根據(jù)它自身的策略，要求部署者提供一定的證書才允許部署操作的執(zhí)行。然后部署者提供相應(yīng)的證書給服務(wù)容器，服務(wù)容器在對這些證書進行驗證后，把協(xié)商結(jié)果告訴部署者。如果證書是合法的，則允許部署操作繼續(xù)進行，否則，該操作被拒絕。
下面通過一個具體的例子來說明部署中的信任協(xié)商過程。我們假設(shè)部署者D需要把一個服務(wù)部署到服務(wù)容器T上。信任協(xié)商的步驟如下1)D向T發(fā)送一個部署請求Rdep。
2)T把自己的訪問策略(只有同時擁有證書CA1和CA2的節(jié)點才允許執(zhí)行部署操作)告訴D。
3)D擁有證書CA1和CA2，但CA2中包含D的敏感信息，因此D對CA2設(shè)置了一個訪問策略只有擁有證書CB1的用戶才能讀CA2。D把CA1和他的策略再發(fā)送給T。
4)T有證書CB1，于是它把CB1發(fā)給D。
5)D收到CB1后，經(jīng)過驗證，把CA2發(fā)給T。
6)T把協(xié)商成功的結(jié)果發(fā)給D。
經(jīng)過上面幾步的交互，D和T已經(jīng)建立了信任關(guān)系。接下來就可以把網(wǎng)格歸檔包從D傳輸給T，進行部署了。
一次協(xié)商過程可能會花費比較長的時間。此外，在有些情況下，用戶需要更新已經(jīng)部署過的服務(wù)，沒有必要再進行一遍協(xié)商。為了提高協(xié)商的效率，我們在ROST里提出了信任票據(jù)的概念。在一次成功的信任協(xié)商之后，部署者可以向服務(wù)容器申請一個信任票據(jù)，在這個信任票據(jù)里，存儲了一些信任協(xié)商的關(guān)鍵安全信息。有了信任票據(jù)，部署者就不需要和這個服務(wù)容器再次進行信任協(xié)商，只需要出示他的信任票據(jù)就行了。因此本發(fā)明的方法在所述步驟1與步驟2之間還設(shè)有步驟11、部署者檢查是否已經(jīng)配置了信任票據(jù)，如果是，則執(zhí)行步驟12，如果不是，則執(zhí)行步驟2；步驟12、部署者將所述信任票據(jù)提交給所述服務(wù)容器，所述服務(wù)容器驗證所述信任票據(jù)，如果驗證成功則執(zhí)行步驟3，如果不成功，則執(zhí)行步驟2。
為保證更高的安全性，信任票據(jù)可由頒發(fā)的服務(wù)容器簽名并具有有限的生命期。
在ROST中，我們采用精確的RTML(Role-Based Trust ManagementLanguage Markup Language，基于角色的信任管理標記語言)來描述訪問控制策略和基于屬性的證書。當(dāng)證書的存儲是分布式的時候，目標指向的算法確保了所有可用的證書都能被發(fā)現(xiàn)和收集。在ROST的設(shè)計中，信任票據(jù)的格式為<subject，issuer，subject，valid date，expiration date，signature>。
此外，協(xié)商信息的交換必須在安全的通信協(xié)議之上(比如SSL/TLS(SecureSocket Layer/Transport Level Security，安全套接字層/傳輸層安全))，從而防止竊聽，中間人攻擊，重放攻擊等。在ROST中，我們遵循WS-Security規(guī)范和WS-SecureConversation規(guī)范對SOAP消息進行保護。
最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管參照較佳實施例對本發(fā)明進行了詳細說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，可以對本發(fā)明的技術(shù)方案進行修改或者等同替換，而不脫離本發(fā)明技術(shù)方案的精神和范圍。
權(quán)利要求
1.一種可信的遠程服務(wù)熱部署方法，其特征在于包括如下步驟步驟1、部署者向遠程的服務(wù)容器發(fā)出服務(wù)部署請求；步驟2、部署者與服務(wù)容器進行信任協(xié)商，如果協(xié)商成功，則執(zhí)行步驟3，否則，執(zhí)行步驟4；步驟3、所述服務(wù)容器執(zhí)行熱部署操作；步驟4、結(jié)束。
2.根據(jù)權(quán)利要求1所述的可信的遠程服務(wù)熱部署方法，其特征在于在所述步驟1與步驟2之間還設(shè)有步驟11、部署者檢查是否已經(jīng)配置了信任票據(jù)，如果是，則執(zhí)行步驟12，如果不是，則執(zhí)行步驟2，其中所述信任票據(jù)為部署者與服務(wù)容器進行信任協(xié)商成功后由部署者向服務(wù)容器申請獲得的，所述信任票據(jù)中存儲了信任協(xié)商的關(guān)鍵安全信息；步驟12、部署者將所述信任票據(jù)提交給所述服務(wù)容器，所述服務(wù)容器驗證所述信任票據(jù)，如果驗證成功則執(zhí)行步驟3，如果不成功，則執(zhí)行步驟2。
3.根據(jù)權(quán)利要求1所述的可信的遠程服務(wù)熱部署方法，其特征在于所述步驟2具體為步驟21、所述服務(wù)容器從配置文件中獲得部署服務(wù)的訪問控制策略并發(fā)送給所述部署者；步驟22、所述部署者查看其自身是否有滿足所述訪問控制策略的證書，如果有，則執(zhí)行步驟23，如果沒有，則執(zhí)行步驟4；步驟23、將所述滿足所述訪問控制策略的證書發(fā)給所述服務(wù)容器；步驟24、所述服務(wù)容器對證書進行檢驗，如果通過檢驗，則執(zhí)行步驟3，如果沒有通過檢驗，則執(zhí)行步驟4。
4.根據(jù)權(quán)利要求3所述的可信的遠程服務(wù)熱部署方法，其特征在于在步驟22與步驟23之間還設(shè)有步驟22a、所述部署者向所述服務(wù)容器發(fā)送查看所述證書的訪問控制策略；步驟22b、所述服務(wù)容器查看是否有滿足查看所述證書的訪問控制策略的證書，如果有，則執(zhí)行步驟22c，如果沒有，則執(zhí)行步驟4；步驟22c、將所述滿足查看所述證書的訪問控制策略的證書發(fā)送給所述部署者；步驟22d、所述部署者檢驗所述滿足查看所述證書的訪問控制策略的證書，如果通過檢驗，則執(zhí)行步驟23，如果沒有通過檢驗，則執(zhí)行步驟4。
5.根據(jù)權(quán)利要求1至5任一所述的可信的遠程服務(wù)熱部署方法，其特征在于所述步驟3具體為步驟31、所述服務(wù)容器接收通過SOAP附件傳輸?shù)木W(wǎng)格歸檔文件或從FTP服務(wù)器上下載網(wǎng)格歸檔文件；步驟32、所述服務(wù)容器調(diào)用本地部署模塊部署所述網(wǎng)格歸檔文件。
6.根據(jù)權(quán)利要求5所述的可信的遠程服務(wù)熱部署方法，其特征在于所述步驟32具體為步驟321、查看網(wǎng)格歸檔文件是否存在，如果不存在，則執(zhí)行步驟4，如果存在則執(zhí)行步驟322；步驟322、判斷ANT環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟323；步驟323、調(diào)用ANT工具將網(wǎng)格歸檔文件部署到服務(wù)容器中。
7.根據(jù)權(quán)利要求1所述的可信的遠程服務(wù)熱部署方法，其特征在于在所述步驟2與步驟3之間還設(shè)有反部署指定的網(wǎng)格歸檔文件的操作。
8.根據(jù)權(quán)利要求7所述的可信的遠程服務(wù)熱部署方法，其特征在于所述反部署指定的網(wǎng)格歸檔文件的操作具體為步驟31a、判斷ANT環(huán)境是否可用，如果不可用，則執(zhí)行步驟4，如果可用，則執(zhí)行步驟31b；步驟31b、調(diào)用ANT工具將部署所述指定的網(wǎng)格歸檔文件時裝載到服務(wù)容器中的所有配置信息和程序文件刪除。
全文摘要
本發(fā)明涉及一種可信的遠程服務(wù)熱部署方法，包括如下步驟步驟1.部署者向遠程的服務(wù)容器發(fā)出服務(wù)部署請求；步驟2.部署者與服務(wù)容器進行信任協(xié)商，如果協(xié)商成功，則執(zhí)行步驟3，否則，執(zhí)行步驟4；步驟3.所述服務(wù)容器執(zhí)行熱部署操作；步驟4.結(jié)束。通過本發(fā)明提供的方法，為遠程服務(wù)的熱部署提供了安全保障，解決了SOA中遠程服務(wù)熱部署的問題以及相關(guān)的安全隱患，極大的方便了用戶，避免了為了部署服務(wù)而重啟服務(wù)容器給用戶帶來的損失和效率的降低，解決了網(wǎng)絡(luò)環(huán)境下在跨安全域的部署者和服務(wù)容器之間建立信任關(guān)系的問題。
文檔編號H04L29/06GK1791024SQ20051013253
公開日2006年6月21日 申請日期2005年12月26日 優(yōu)先權(quán)日2005年12月26日
發(fā)明者懷進鵬, 胡春明, 孫海龍, 劉萬濤, 許海東 申請人:北京航空航天大學(xué)