基於服務與底層資源分離的服務計算系統的製作方法
2023-05-09 11:33:11
專利名稱：基於服務與底層資源分離的服務計算系統的製作方法
技術領域：
本發明涉及一種基於服務與底層資源分離的服務計算系統，尤其涉及一種用於解決在服務計算中如何進行方便的服務提供和使用，並且保證服務的運行效率和資源利用率等問題的基於服務與底層資源分離的服務計算系統。
背景技術：
基於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上，具體包括以下步驟步驟401D向T發送一個部署請求(Deployment Request)Rdep；步驟402T把自己的訪問策略Policies只有同時擁有證書CA1和CA2的節點才允許執行部署操作，告訴D；步驟403D擁有證書CA1和CA2，但CA2中包含D的敏感信息，因此D對CA2設置了一個訪問策略只有擁有證書CB1的用戶才能讀CA2；D把CA1和他的策略(Policies(CB1→CA2))再發送給T；步驟404T有證書CB1，於是它把CB1發給D；步驟405D收到CB1後，經過驗證，把CA2發給T；步驟406T把協商成功的結果(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定義了兩個接口getHTMLInputRenderinggetHTMLOutputRendering(Object result)針對每個WSRF，服務的提供者都要實現這兩個接口。第一個接口用於生成服務的展現界面，第二個接口用於展現處理結果，兩個接口的返回值為HTML片斷，SE會通過服務的這兩個接口進行自動的服務界面生成和結果展現。
至於資源選擇，SE可以配置多種資源選擇策略，如選擇最近資源、能力最強資源、用戶指定以及隨機選擇等，即SE是靈活可配置的，它不拘泥於某一種策略，用戶可以根據作業處理的需求，靈活選擇和配置。
本發明通過將服務與底層資源分離，有效地解決了當前服務與底層資源綁定的服務計算中作業處理效率及資源利用率低、潛在的較高的資源使用經濟代價以及安全問題。
最後所應說明的是，以上實施例僅用以說明本發明的技術方案而非限制，儘管參照較佳實施例對本發明進行了詳細說明，本領域的普通技術人員應當理解，可以對本發明的技術方案進行修改或者等同替換，而不脫離本發明技術方案的精神和範圍。
權利要求
1.一種基於服務與底層資源分離的服務計算系統，其特徵在於包括資源層，設有原始服務、底層資源和已部署服務，位於所述系統的最底層；分布式服務註冊庫，為各類資源的組織和發現提供支持，位於所述資源層的上一層；服務瀏覽器，向用戶提供基於Web方式的操作平臺，位於所述分布式服務註冊庫的上一層；用戶層，設有服務提供方、底層資源提供者和消費者，位於所述服務瀏覽器的上一層。
2.根據權利要求1所述的服務計算系統，其特徵在於所述底層資源設有節點服務容器、集群、Pc機；該節點伺服器用於提供服務運行環境、可信的遠程服務熱部署功能以及提供對本節點的底層資源的資源監控功能。
3.根據權利要求2所述的服務計算系統，其特徵在於所述節點服務容器設有用於實現服務部署的可信的服務遠程熱部署模塊和節點信息監控模塊。
4.根據權利要求3所述的服務計算系統，其特徵在於所述可信的服務遠程熱部署模塊包括信任協商代理模塊，用於建立部署者和目標服務容器之間的信任關係；遠程熱部署模塊，用於進行遠程服務熱部署以及本地的自動服務部署，與所述信任協商代理模塊連接；服務容器配置模塊，用於存儲和管理服務容器的配置參數，與所述遠程熱部署連接。
5.根據權利要求4所述的服務計算系統，其特徵在於所述信任協商代理模塊包括信任票據管理器，用於頒發或驗證信任票據；信任票據存儲庫，用於存儲信任票據，與所述信任票據管理器連接；策略引擎，用於決定策略的披露以及對協商結果成功與否進行判定，與所述信任票據管理器連接；一致性檢查器，用於確定滿足請求者策略的本地證書以及判斷請求者的證書是否滿足本地策略，與所述策略引擎連接；策略存儲庫，用於存儲策略，與所述一致性檢查器連接；信任證鏈收集器，用於發現和收集必需的證書，與所述策略引擎連接。
6.根據權利要求4所述的服務計算系統，其特徵在於所述遠程熱部署模塊包括遠程部署模塊，用於接收遠程的原始服務並判斷遠程的部署者是否可信，根據判斷結果判定是調用所述信任協商代理模塊還是調用所述基本部署模塊；所述服務接收器與所述信任檢查器相連接，所述信任檢查器與所述信任協商代理模塊連接；本地部署模塊，設有事件偵聽器和事件分析器，用於監視本地的部署文件夾並根據監視信息調執行相應的部署操作；所述事件偵聽器與所述事件分析器連接；基本部署模塊，設有部署模塊、反部署模塊和重部署模塊，用於對接收到的服務進行部署、反部署或重部署操作，該基本部署模塊與所述遠程部署模塊和所述本地部署連接；部署輔助工具模塊，用於輔助在部署操作中所需要的文件解析或文件解壓縮等功能，與所述基本部署模塊連接。
7.根據權利要求6所述的服務計算系統，其特徵在於所述遠程部署模塊包括服務接收器，用於接收遠程的部署者傳來的服務；信任檢查器，用於判斷接收到的所述服務是否可信，並根據判斷結果調用信任協商代理模塊或基本部署模塊，與所述服務接收器、所述信任協商代理模塊和基本部署模塊連接。
8.根據權利要求3所述的服務計算系統，其特徵在於所述節點信息監控模塊設有資源監控器，該資源監控器設有查詢接口模塊和通知接口模塊，且連接有提供者管理器。
9.根據權利要求1或2所述的服務計算系統，其特徵在於所述分布式服務註冊庫採用分布式的結構，將參與服務計算的所有資源按照地理位置劃分成多個自治域，每個自治域內採用樹形的結構進行組織，整體上是由多棵樹結構，樹之間採用對等的方式進行連接。
10.根據權利要求1或2所述的服務計算系統，其特徵在於所述服務瀏覽器設有用於生成服務的展現界面接口和用於展現處理結果的接口。
全文摘要
本發明涉及一種基於服務與底層資源分離的服務計算系統，該系統包括資源層，設有原始服務、底層資源和已部署服務，位於所述系統的最底層；分布式服務註冊庫，為各類資源的組織和發現提供支持，位於所述資源層的上一層；服務瀏覽器，向用戶提供基於Web方式的操作平臺，位於所述分布式服務註冊庫的上一層；用戶層，設有服務提供方、底層資源提供者和消費者，位於所述服務瀏覽器的上一層。本發明通過將服務與底層資源分離，有效地解決了當前服務與底層資源綁定的服務計算中作業處理效率及資源利用率低、潛在的較高的資源使用經濟代價以及安全問題。
文檔編號H04L29/06GK1791117SQ200510132549
公開日2006年6月21日 申請日期2005年12月26日 優先權日2005年12月26日
發明者懷進鵬, 胡春明, 孫海龍, 鍾亮 申請人:北京航空航天大學