專利名稱：用于多個中間件環(huán)境之間的消息流的服務質(zhì)量(qos)管理的制作方法
技術領域：
本發(fā)明一般涉及信息系統(tǒng)，更具體地說，涉及在包括多個中間件環(huán)境的信息系統(tǒng) 中的服務質(zhì)量(QoS)管理。
背景技術：
可以在網(wǎng)絡化的信息管理系統(tǒng)中實現(xiàn)QoS管理，以優(yōu)化多個并發(fā)網(wǎng)絡應用對系統(tǒng) 資源的使用。通?？梢詫⒃谛畔⒐芾硐到y(tǒng)中的工作單元視為或任務或消息。在面向?qū)ο蟮?系統(tǒng)中，基本任務可以是例如對象的執(zhí)行線程。消息典型地是各種類型的信息的封裝。系 統(tǒng)趨向于是面向任務的或面向消息的。因此，已知的QoS管理方法趨向于是或面向任務的 或面向消息的。雖然用于面向任務的系統(tǒng)和面向消息的系統(tǒng)的QoS管理概念和架構(gòu)可能是相似 的，但是實際的實現(xiàn)技術趨向于是非常不同的。在面向任務的系統(tǒng)中，QoS管理技術一般關 注區(qū)分任務執(zhí)行的優(yōu)先級來滿足應用QoS需求。在面向消息的系統(tǒng)中，QoS管理技術一般 關注消息接收、處理和交付的質(zhì)量。質(zhì)量特性(例如性能和可靠性)的含義會與面向任務 的系統(tǒng)中的那些稍微不同。例如，消息可靠性典型地意味著交付保證、消息排序和去重復的 組合。另一方面，任務可靠性典型地意味著可以成功地執(zhí)行任務而無失敗的概率。當前，QoS管理在面向任務的系統(tǒng)中用來支持計算應用，以在分布式環(huán)境中以及時 的方式完成高優(yōu)先級任務。然而，沒有給予用于面向消息的信息管理系統(tǒng)的QoS管理更多 的重視。這類系統(tǒng)包括在其中實現(xiàn)面向服務的體系結(jié)構(gòu)(SOA)的信息管理系統(tǒng)。SOA可以 是例如發(fā)布/訂閱、對象請求代理、對等體系結(jié)構(gòu)或其組合。在發(fā)布/訂閱體系結(jié)構(gòu)中，信息代理向系統(tǒng)的客戶端應用提供服務。在分布式信 息管理系統(tǒng)和網(wǎng)絡中心軍用系統(tǒng)中，信息代理在信息發(fā)布、處理和散布中扮演中心角色。被 代理系統(tǒng)的示例包括電子郵件、信息天地(information sphere)、合作、虛擬社區(qū)和組通 信。當許多并發(fā)客戶端和他們的請求競爭系統(tǒng)資源時，在被代理的系統(tǒng)中可能難以滿足關 鍵客戶端的需求。用于信息代理的已知資源管理方法不能區(qū)分具有不同QoS特性的客戶 端，使得甚至在多個中間件域之間，也可能據(jù)此管理系統(tǒng)資源。

發(fā)明內(nèi)容
通過將一致的、策略驅(qū)動服務質(zhì)量(QoS)需求應用在多個不同的面向消息中間件 (MOM)環(huán)境或域內(nèi)以及在其之間的消息流上，本發(fā)明的各種實施例可以解決上面所指出的 不足和其他不足。在一個實施例中，描述一種管理信息系統(tǒng)資源以提供在多個中間件域內(nèi)和多個中 間件域之間具有一致的服務質(zhì)量(QoS)級別的消息流的方法。該方法包括接收來自第一 QoS管理器的、表達至少一個QoS需求的QoS消息，將所述至少一個QoS需求轉(zhuǎn)化為針對 以通信方式耦合多個中間件域的消息接發(fā)服務的至少一個參數(shù)，在第一中間件域和所述消 息接發(fā)服務之間創(chuàng)建客戶端連接用于接收所述消息流，將所述QoS消息發(fā)送到第二中間件域，以及在所述消息接發(fā)服務和所述第二中間件域之間創(chuàng)建客戶端連接用于發(fā)送所述消息流。在另一實施例中，描述用于提供在多個互連的中間件域內(nèi)和多個互連的中間件域 之間具有一致的QoS級別的消息流的服務質(zhì)量(QoS)橋。所述QoS橋被配置為接收來自第 一 QoS管理器的至少一個QoS需求，將所述至少一個QoS需求傳播到第二 QoS管理器，以及 將所述至少一個QoS需求轉(zhuǎn)化為至少一個QoS參數(shù)。所述QoS橋也被配置為使用消息接發(fā) 服務來接收和使用所述至少一個QoS參數(shù)，以及協(xié)助在所述多個互連的中間件域之間的所 述消息流。在又另一實施例中，描述用于管理信息系統(tǒng)中的QoS的服務質(zhì)量(QoS)管理系統(tǒng)， 所述信息系統(tǒng)包括由至少一個處理器執(zhí)行的至少第一中間件解決方案和第二中間件解決 方案。所述QoS管理系統(tǒng)包括第一 QoS管理器、QoS橋和第二 QoS管理器，所述第一 QoS管 理器被配置為在所述至少一個處理器上執(zhí)行，使得表達至少一個QoS參數(shù)的QoS消息從所 述信息系統(tǒng)的客戶端被接收；所述QoS橋被配置為在所述至少一個處理器上執(zhí)行，使得所 述QoS消息從所述第一 QoS管理器被接收；所述第二 QoS管理器被配置為在所述至少一個 處理器上執(zhí)行，使得由所述第二 QoS管理器接收來自所述QoS橋的所述QoS消息，并且所述 QoS消息被轉(zhuǎn)發(fā)到所述信息系統(tǒng)的訂閱者，以提供在客戶端和訂閱者之間具有一致QoS的 端到端消息流。


圖1是具有面向服務體系結(jié)構(gòu)(SOA)的示例性信息系統(tǒng)的圖示；圖2是QoS管理體系結(jié)構(gòu)的示例性實施例的圖示；圖3是包括多個中間件域的示例性信息系統(tǒng)的圖示；以及圖4是圖3的信息系統(tǒng)的應用的示例性實施例的圖示。如在此使用的，術語示例 性指示示例，而不必是典型。
具體實施例方式以下描述在本質(zhì)上僅是示例性的，并且決非意在限制應用或使用。雖然參照發(fā)布 者/訂閱者信息管理面向服務的體系結(jié)構(gòu)(SOA)描述了一個或多個配置，但是配置并非如 此有限。結(jié)合其他類型的信息系統(tǒng)設想其他和另外的配置，包括但不限于其他類型和另外 類型的面向服務體系結(jié)構(gòu)，信息管理系統(tǒng)和/或網(wǎng)絡化系統(tǒng)。通常，具有面向服務體系結(jié)構(gòu)(SOA)的系統(tǒng)可以作為許多服務的集合的組成成分 對待。每一服務經(jīng)由清楚地定義的接口使其功能可用。在SOA中，每一服務典型地是自描 述且開放的軟件部件。SOA包括服務，它們的組成成分和交互。下面相對于系統(tǒng)客戶端描述 管理信息系統(tǒng)資源的方法。在公開號為2005/0204054的美國專利中也描述了一種管理信 息系統(tǒng)資源的示例性方法。圖1是實現(xiàn)SOA的信息系統(tǒng)20的圖示。在示例性實施例中，信息系統(tǒng)20具有發(fā) 布/訂閱S0A。發(fā)布者24發(fā)布例如關于多個話題的消息，并且例如由訂閱關于特定話題的 消息的有意方操作訂閱者(用戶)34。雖然以圖示的形式示出，但是一個或多個元件應理 解為包括處理器、關聯(lián)的存儲器和相關的硬件，其中處理器被配置為獲取、解碼和執(zhí)行計算機指令，以實現(xiàn)對應于在此所描述的方法、裝置或系統(tǒng)的一個或多個操作。同樣地，計算機 可讀介質(zhì)或機器可讀介質(zhì)可以與處理器一起使用以提供指令。計算機可讀介質(zhì)可以包括光 介質(zhì)(例如光盤(⑶))、磁介質(zhì)(例如軟盤或硬盤)或固態(tài)存儲器(例如隨機存取存儲器 (RAM)或只讀存儲器(ROM))。通過信息代理(InfoBroker) 46將發(fā)布服務38和訂閱服務42分離。發(fā)布者24和 訂閱者34相對于作為服務提供者的InfoBroker 46是服務請求者(在此也稱為“客戶端” 和“應用”)。發(fā)布服務38和訂閱服務42被包括在由InfoBroker 46提供給發(fā)布者24和訂 閱者34的公共服務50中。公共服務50也包括安全54、持久56、過濾58、融合60、分發(fā)62 和發(fā)現(xiàn)64。也可以提供另外的服務66，例如訂閱登記。信息代理46也將QoS管理服務70 作為公共服務50提供給客戶端24和客戶端34。如下面進一步描述的，信息代理46提供對 QoS管理器74的訪問，客戶端通過所述QoS管理器74可以協(xié)商QoS約定(QoS contract)。 如下面進一步所描述的，信息代理46經(jīng)由QoS管理服務70將服務質(zhì)量提供給客戶端24和 客戶端34。在一個實施例中，發(fā)布者24和訂閱者34可以動態(tài)地發(fā)現(xiàn)InfoBroker 46并且使 用前述服務50。這類服務可以具有不同的QoS特性，并且這類服務的交互可以是動態(tài)的和 分離的。在性能、可靠性、時間性和安全性方面，不同的發(fā)布者24和訂閱者34可能具有不 同的QoS需求。例如，某些發(fā)布者24可能具有比其他發(fā)布者高的優(yōu)先級，并且可能要求將 它們的消息在較快的響應時間內(nèi)以正確的順序保證交付。類似地，某些訂閱者34可能比其 他訂閱者更關鍵，因此在接收消息時要求較短的延遲。作為服務提供者，InfoBroker 46可以將一個或多個QoS保證提供給一個或多個 發(fā)布者24和/或訂閱者34。InfoBroker 46可以限制發(fā)布者24和/或訂閱者34的一個 或多個行為，例如每一時間單元接收或交付消息的速率和/或消息載荷大小。為了處理多 個并發(fā)客戶端(例如發(fā)布者24和訂閱者34)的QoS需求，QoS管理服務70包括這類服務， 例如進入控制80、預測82、資源管理84、監(jiān)控86和自適應88。發(fā)布者24和訂閱者34可以向InfoBroker 46表達它們的QoS需求并且協(xié)商QoS 約定。QoS約定可以是暫時的或永久的。以此方式，QoS約定可以在每一會話基礎上是暫時 的或?qū)哂刑囟ń巧目蛻舳耸怯谰玫?。InfoBroker 46提供用于滿足與客戶端的QoS約 定的資源和機制。InfoBroker 46在執(zhí)行QoS約定期間監(jiān)控系統(tǒng)狀態(tài)，并且提供合適的自適 應服務。在一種配置中，InfoBroker 46導出QoS管理器74以使其QoS管理服務70對客戶 端可用。客戶端24和/或客戶端34將其QoS需求作為可擴展標記語言(XML)消息發(fā)送給 QoS管理器74。在接收達成協(xié)議的QoS約定之后，客戶端使用該約定作為其與InfoBroker 46交互(例如發(fā)送和/或接收消息)的背景(context)。在圖1中示例的體系結(jié)構(gòu)為作為QoS服務提供者的InfoBroker 46提供覆蓋QoS 管理的多個方面的部件服務。例如InfoBroker 46可以分析應用QoS需求并且可以基于策 略以及當前的和預測的未來系統(tǒng)狀態(tài)，做出進入控制決定。InfoBroker 46可以調(diào)撥系統(tǒng)資 源和機制以滿足QoS需求，并且可以在運行時間監(jiān)控和調(diào)整系統(tǒng)行為。通常，在信息系統(tǒng)20中，根據(jù)QoS特性來指定服務50的QoS需求。QoS特性描述 服務請求者和服務提供者兩者都理解的具體方面或約束。例如，QoS特性可以劃分為四個類別性能、可靠性、時間性和安全性?？梢詫⒁唤MQoS參數(shù)與每一類別關聯(lián)，例如如下所示。 與性能類別關聯(lián)的參數(shù)是響應時間、消息吞吐量、載荷大小、發(fā)布/訂閱容積率和端到端 延遲。與可靠性類別關聯(lián)的參數(shù)是交付保證、去重復、消息順序、丟失概率、錯誤率、重試閾 值、消息持續(xù)性和關鍵性。與時間性類別關聯(lián)的參數(shù)是生存時間、最后期限、恒定位速率、 幀速率和優(yōu)先級。與安全性類別關聯(lián)的參數(shù)是消息簽名和加密。應該注意，QoS特性和參數(shù)的前述分類是示例性的。可以設想QoS各方面的其他 和/或另外的特征化和/或分類。在示例實施例中，基于QoS特性和參數(shù)的前述分類，基于 XML的語言使得服務請求者能夠?qū)⒁粋€或多個QoS需求表達為QoS消息。圖2是示例性QoS管理體系結(jié)構(gòu)300的圖示。QoS管理體系結(jié)構(gòu)300可以包括部 件服務、它們的交互和例如通過現(xiàn)成商品(COTS)監(jiān)控工具與外部服務(如實時主機和網(wǎng)絡 狀態(tài)監(jiān)控)的接口。關鍵部件服務包括Q0S管理器308、建立服務312、策略管理器316、資 源管理器320、預測服務324、操作服務328、保持服務332、監(jiān)控服務336、自適應服務340和 診斷服務344。在監(jiān)控服務和QoS診斷服務之間的交互348遵循登記和通知模式，而在其他 服務之間的交互352是基于請求和答復模式。如下面進一步所描述的，診斷服務344經(jīng)由 COTS監(jiān)控工具364與外部服務(如實時主機356和網(wǎng)絡360)相接。QoS管理器308組織客戶端的QoS服務的建立和操作。如前面參照圖1討論的， QoS管理器308為客戶端提供訪問QoS管理服務的接口。如下面進一步所描述的，給定以 XML QoS消息表達的QoS需求，建立服務312可以為客戶端設立QoS約定。也如下面進一步 所描述的，建立服務312使用策略管理器316、預測服務324和資源管理器320。如果不能 建立約定，則建立服務312向代表客戶端做出建立請求的QoS管理器308報告。策略管理器316檢查QoS策略368以確?？蛻舳说腝oS需求中的參數(shù)被允許用于 客戶端的角色，并且如果允許，策略管理器316檢查需要什么資源和機制來滿足該需求。資 源管理器320提供包括用于系統(tǒng)資源的保留、分配和釋放的資源生命周期管理。由于資源 典型地位于主機356的平臺，因此資源管理器320定義通用QoS管理功能的抽象類。平臺 的示例是對象管理組開發(fā)的公共對象請求代理體系結(jié)構(gòu)(CORBA)、Sun Microsystems公司 (圣克拉拉(Santa Clara)，加利福利亞州)開發(fā)的Java平臺企業(yè)版(J2EE)和微軟公司 (雷德蒙德(Redmond)，華盛頓州)開發(fā)的.NET架構(gòu)。如下面進一步所描述的，針對每一主 機平臺實現(xiàn)具體的資源類。預測服務324根據(jù)若干關鍵系統(tǒng)參數(shù)(例如存儲器使用、CPU負載、網(wǎng)絡吞吐量、 延遲)跟蹤系統(tǒng)狀態(tài)。預測服務324也根據(jù)請求使用各種預測算法在一小段時間窗口中預 測未來系統(tǒng)狀態(tài)。操作服務328使用初始化進程330來初始化用于QoS約定的資源配置，并且在執(zhí) 行QoS約定期間協(xié)調(diào)服務。保持服務332可以保持用于QoS約定的一個或多個關鍵QoS參 數(shù)，并且可以根據(jù)針對這類參數(shù)的閾值交叉點激活自適應服務340。監(jiān)控服務336采樣并且 集合資源的使用和可用級別，并且測量性能，例如真實的吞吐量和延遲值。監(jiān)控服務336登 記診斷服務344的狀態(tài)判定，當判定變?yōu)檎鏁r(例如由于系統(tǒng)狀態(tài)的改變)，診斷服務344 返回通知。為了恢復正常范圍內(nèi)的關鍵QoS參數(shù)，自適應服務340動態(tài)地改變資源和機制 372。自適應服務340也可以對客戶端的約定違約采取措施。這類措施可以包括例如減慢
7來自客戶端的消息接受，該客戶端遠遠超出其達成協(xié)議的發(fā)布速率進行發(fā)布。例如，當所觀 察到的參數(shù)以低于它的閾值返回時，保持服務332可以請求自適應服務340根據(jù)QoS約定 恢復QoS級別。自適應機制372可以是插件。因此可以靜態(tài)地配置并基于策略動態(tài)地選擇 合適的自適應機制372。診斷服務344使用推理技術(例如使用因果網(wǎng)絡)來將低級別系統(tǒng)信號集合成關 于系統(tǒng)狀態(tài)的屬性。診斷服務344獲得來自監(jiān)控工具364的實時輸入，即時集合數(shù)據(jù)，并且 將數(shù)據(jù)存儲在倉庫376中。診斷服務344也可以根據(jù)值變化來評估對屬性的任何判定并且 觸發(fā)對有意方(例如監(jiān)控服務336)的通知。通過詢問QoS服務提供者(例如參照圖1所描述的信息代理)或通過使用發(fā)現(xiàn) 服務，客戶端經(jīng)由QoS管理器308訪問QoS管理服務。在示例實施例中，QoS管理器308是 QoS管理體系結(jié)構(gòu)300中客戶端為QoS服務與其直接接口的唯一部件。中間件域是具有一個管理域的環(huán)境，在該管理域內(nèi)中間件解決方案將服務提供給 客戶端應用的集合。中間件域的示例包括Apache Software Foundation開發(fā)的ActiveMQ 消息代理、JBoss應用服務器、IBM公司(阿蒙克(ArMond)，紐約州)開發(fā)的WebSphere、 數(shù)據(jù)分發(fā)服務(DDS)、波音公司(芝加哥，伊利諾斯州)開發(fā)的系統(tǒng)通用操作環(huán)境的系統(tǒng) (SOSCOE)和C0RBA。如針對信息系統(tǒng)20所描述的，在保持QoS支持的同時，能夠?qū)⑾?一個中間件域散布到另一中間件域?qū)⑹怯欣?。圖3是通過信息系統(tǒng)400的消息流的圖示，所述信息系統(tǒng)包括多個中間件域，例如 中間件域404和中間件域406。虛線指示消息流，而實線指示約定協(xié)商(也稱為控制流)。 在示例實施例中，信息系統(tǒng)400具有發(fā)布/訂閱SOA實現(xiàn)。發(fā)布者408發(fā)布例如關于多個 話題的消息，并且例如通過訂閱關于特定話題的消息的有意方來操作訂閱者410。多個QoS 管理器426和QoS管理器428安排用于客戶端的QoS服務的建立和操作。如前面參照圖1 所討論的，QoS管理器426和QoS管理器428為客戶端提供訪問QoS管理服務的接口。信 息系統(tǒng)400也包括QoS橋430和消息接發(fā)服務432，以在保持QoS屬性的同時，協(xié)助從發(fā)布 者408到訂閱者410的穿過多個中間件域的端到端消息流。如上面所描述的，QoS指系統(tǒng)(例如信息系統(tǒng)400)在不同的優(yōu)先級級別將服務提 供給客戶端(例如發(fā)布者408和訂閱者410)的能力。對于面向消息的系統(tǒng)，QoS指對客戶 端、中間件和網(wǎng)絡進行的消息傳輸和處理分配不同的性能級別。QoS管理涉及設置和控制 QoS屬性，QoS屬性例如但不限于吞吐量、延遲、抖動(時變)、丟失率、持續(xù)性和持久性。QoS 需求和QoS約定是這些屬性的集合。QoS需求指定由應用請求的消息收發(fā)性能的級別，并且 QoS約定指定給應用準予(即“允諾”)的性能級別。此外，在示例實施例中，如果沒有指定 QoS需求，則暗示缺省的QoS需求集。例如，缺省的QoS需求集可以包括“允諾”盡力而為。端到端消息流開始于在生產(chǎn)者(例如發(fā)布者408)處產(chǎn)生消息，并且終止于由消費 者(例如訂閱者410)消費消息。在由多個異種中間件域組成的系統(tǒng)中，端到端消息流也將 包括在中間件解決方案之間的傳輸，以及在所有中間件解決方案內(nèi)的傳輸。保持QoS屬性 是實時的、任務緊急環(huán)境的基本部件。系統(tǒng)端點和消息處理中間級必須遵循指定服務需求 的QoS約定。典型地，已知的中間件技術提供某個級別的QoS支持。然而，QoS支持級別隨 著技術的不同而不同，隨著從流之間的相對優(yōu)先級到概念(如流量整形和數(shù)據(jù)持續(xù)性)的 不同而不同。
QoS橋430使得中間件解決方案404和中間件解決方案406能夠共享與各自的客 戶端應用已經(jīng)建立的QoS約定，使得向不同中間件域上的應用之間的消息流提供在多個互 連的中間件環(huán)境或域內(nèi)和其之間一致的QoS級別。中間件域404和中間件域406中的QoS 管理器426和QoS管理器428各自將特定的協(xié)議(在圖3中未示出)用于經(jīng)由QoS橋430 傳播(即轉(zhuǎn)發(fā)和接收)已建立的QoS約定。QoS管理器426和QoS管理器428使用該協(xié)議， 使得當將消息轉(zhuǎn)發(fā)到不同的中間件域時，在一個中間件域中與發(fā)布者已經(jīng)建立的約定中的 QoS設置可以用作QoS需求。例如，在發(fā)布者408和QoS管理器426之間建立的約定可以用 作從QoS橋430發(fā)送到QoS管理器428的QoS需求。QoS管理器426負責與在其域中的應用(例如發(fā)布者408)建立和保持QoS約定。 QoS管理器426接收來自發(fā)布者408的QoS需求，并且建議由QoS策略446和可用資源指示 的約定。當發(fā)布者408接受時，約定變成有約束力的。QoS管理器426通過將QoS約定轉(zhuǎn)化 為針對中間件域404的一組QoS參數(shù)并且在該組QoS參數(shù)和發(fā)布者408之間設置關聯(lián)來應 用該約定。例如，當發(fā)布者408接受QoS約定時，QoS管理器426創(chuàng)建到發(fā)布者408的中間 件連接，并且在連接中設置QoS參數(shù)。QoS管理器426也將QoS需求發(fā)送到QoS橋430，QoS橋430依次將該QoS需求傳 播到其他中間件域，例如中間件域406。QoS橋430是專門化的QoS管理器。更具體地說， QoS橋430是中間件域之間的QoS管理器。QoS橋430與QoS管理器和消息接發(fā)服務(例 如QoS管理器426和消息接發(fā)服務432)進行交互，而不是與客戶端應用和中間件解決方案 進行交互。消息接發(fā)服務432提供兩個或更多個中間件域之間的互操作性，所述互操作性 包括實施在QoS管理器426和QoS橋430之間建立的每一消息流的QoS設置。在示例實施 例中，將到達消息接發(fā)服務432而無明確的QoS需求的消息流處理為與缺省的QoS需求集 關聯(lián)，例如保證盡力而為方式的一組QoS需求。在圖3中也圖解說明用于在多個中間件域之間的端到端通信的示例性方法。發(fā)布 者類型客戶端應用408通過將其QoS需求提交到QoS管理器426來啟動500消息流。QoS 需求是以獨立于中間件的語言撰寫的。QoS管理器426基于接收到的QoS需求、QoS策略 446和可用資源，創(chuàng)建502獨立于中間件的QoS約定。獨特的標識符與該約定關聯(lián)。QoS約 定可以還基于，但不限于僅基于QoS需求、操作者角色、內(nèi)容類型用戶賬戶、可用的計算資 源(本地的和/或遠程的)和可用的網(wǎng)絡資源。QoS管理器426將獨立于中間件的QoS約定轉(zhuǎn)化508為中間件特定的資源規(guī)劃。 該資源規(guī)劃包含滿足該約定需要的計算資源和網(wǎng)絡資源的級別。QoS約定被發(fā)送512到發(fā) 布者408，并且發(fā)布者408接收該約定。發(fā)布者408將接受消息發(fā)布516到QoS管理器426， 并且將消息的發(fā)布加入518到消息流。QoS管理器426實現(xiàn)522資源規(guī)劃。為消息流分配在資源規(guī)劃中調(diào)出的計算資源 和網(wǎng)絡資源。在示例實施例中，資源規(guī)劃和QoS約定用于下述中的至少一個確定計算資源 的分配(例如用于緩沖器的存儲器和用于服務緊急優(yōu)先級流的專用線程)，設置進程和線 程優(yōu)先級，以及例如用合適的DiffServ代碼點標注網(wǎng)絡分組。QoS管理器426將QoS需求散布524到QoS橋430。QoS橋430獲得從源中間件域 (即發(fā)布的來源)接收到的QoS需求，并且與消息接發(fā)服務432進行交互528以創(chuàng)建與起 始中間件域的客戶端連接，用于接收消息流。QoS橋430也使用橋策略530將接收到的QoS
9需求轉(zhuǎn)化為針對消息接發(fā)服務432的一組QoS參數(shù)，所述消息接發(fā)服務將中間件域404和 中間件域406連接在一起。QoS橋430也將接收到的用于消息流的QoS需求散布到下游中 間件域406，對其不做改變或根據(jù)橋策略530進行修改。如上面所描述的，在目的地中間件域406處的QoS管理器428執(zhí)行與起始QoS管 理器426相同的步驟。換句話說，QoS管理器428創(chuàng)建534 “本地”QoS約定和等價的資源 規(guī)劃、保留資源、將約定發(fā)送到客戶端(在此情況下是QoS橋430)、并且一旦接受即實現(xiàn)資 源規(guī)劃?？蛻舳藨?例如訂閱者410)用它們各自的中間件406訂閱536消息流。由于 該步驟獨立于其他控制流通信，因此該訂閱可以在任何時間點發(fā)生。在替代實施例中，在QoS管理器426和QoS橋430之間散布524發(fā)布者408和QoS 管理器426之間適當位置的QoS約定，而不是來自發(fā)布者408的QoS需求。在源域404處 QoS管理器426所準予的是比發(fā)布者408所請求的低得多的QoS級別的控制流的情況下，對 于下游域406，保留原始需求中所請求的資源級別不是有益的。通過散布QoS約定而不是原 始QoS需求，可以避免不必要的麻煩的資源保留。圖4是上面所描述的信息系統(tǒng)400的應用的示例性實施例的圖示。圖4圖解說明 用于將策略驅(qū)動的QoS應用在多個中間件域之間的消息流的信息系統(tǒng)548。在示例實施例 中，寄生在JBoss中間件552上的遺留系統(tǒng)的客戶端應用550需要與寄生在SOSCOE中間件 556上的高級系統(tǒng)的客戶端應用554共享信息。服務代理560扮演客戶端應用550和中間 件平臺552之間的仲裁人。服務代理562代表中間件平臺556為客戶端應用554執(zhí)行相同 的功能。服務代理560包括QoS管理器564而服務代理562包括QoS管理器566。QoS橋 570使得來自中間件域552的消息能夠與中間件域556共享。QoS橋570是特定類型的QoS 管理器，其為消息流接收來自QoS管理器564的QoS需求，并且與QoS管理器566 —起工作 來將相同的QoS需求組應用在同一消息流的附加部分上。高級系統(tǒng)、遺留系統(tǒng)和數(shù)據(jù)庫系統(tǒng)是可以在各種中間件域中操作的系統(tǒng)示例。服 務代理560和服務代理562在指定于中間件的系統(tǒng)和獨立于中間件的系統(tǒng)之間進行轉(zhuǎn)化。 此外，服務代理560和服務代理562驗證這些系統(tǒng)并且批準和管理它們的服務需求。當關 聯(lián)的中間件平臺缺少消息優(yōu)先級區(qū)分時，服務代理560和服務代理562根據(jù)所設立的QoS 約定也可以區(qū)分消息流中單個消息的傳送的優(yōu)先級。上面所描述的實施例提供了有效的端到端QoS管理體系結(jié)構(gòu)，其允許在不同的中 間件解決方案之間接發(fā)消息。在服務代理中的QoS管理器和QoS橋?qū)oS需求轉(zhuǎn)化為合適 的特定于中間件的目標格式，以提供必要的資源分配來支持可預測、自適應、有保證的消息 遞送和優(yōu)先級路由。上面描述的方法和系統(tǒng)使得QoS需求/約定能夠指定用于從端點到端點的整個消 息流的處理。中間件域和中間級(橋接)節(jié)點一致地實施QoS約定。QoS策略可重定義并 且用于控制來自QoS需求的QoS約定設立，將QoS需求/約定轉(zhuǎn)化為特定于中間件的資源 規(guī)劃，以及將QoS需求/約定轉(zhuǎn)化為網(wǎng)絡參數(shù)設置。上面描述的前述各種配置也可以另外視為包含與具有存儲器的處理器一起使用 的機器可讀介質(zhì)。機器可讀介質(zhì)可以包括使處理器接收來自信息系統(tǒng)客戶端的、將一個或 多個QoS需求表達為一個或多個參數(shù)值的QoS消息的指令。機器可讀介質(zhì)也包括使處理器基于一個或多個參數(shù)值與客戶端建立用于服務質(zhì)量的約定的指令。機器可讀介質(zhì)包括使處 理器基于該約定將信息系統(tǒng)的一個或多個資源分配給客戶端的指令。此外，機器可讀介質(zhì) 包括將所接收到的QoS消息散布到下游中間件域的指令。在實現(xiàn)了前述QoS管理系統(tǒng)的配置的SOA中，InfoBroker可以將區(qū)分的服務提供 給不同角色和QoS需求的客戶端。因此InfoBroker可以優(yōu)化資源的分配和使用以滿足來 自許多并發(fā)客戶端的需求。高度重要的客戶端比較不重要的客戶端取得更多的資源或資源 使用的更多共享。上面描述的QoS管理系統(tǒng)在保持QoS需求的同時，也允許在多個中間件 域之間的端點到端點消息傳送。前述系統(tǒng)的配置可以用來管理網(wǎng)絡吞吐量，以基于優(yōu)先級提供可靠的信息遞送。 因為以面向?qū)ο蟮姆椒▽Y源建模，因此前述方法使得在多個中間件平臺上能夠進行統(tǒng)一 的資源管理和多態(tài)的資源分配。上面所描述的基于XML的QoS語言為應用提供了靈活的和可擴展的方式，以用QoS 特性的各種方面表達QoS需求。因此可以將在單個架構(gòu)中集成和處理QoS特性的所有方面 的體系結(jié)構(gòu)提供給QoS服務提供者。在前述系統(tǒng)中，將信息系統(tǒng)的資源建模為軟件對象，以 提供在多個中間件平臺之間的多態(tài)資源分配。在單個架構(gòu)中管理用于任務和消息兩者的 QoS特性。例如通過在系統(tǒng)中間件層中的QoS服務提供者，并發(fā)應用的QoS需求被滿足?；谄湫в?，資源被劃分為多個類別，在運行時間極大地簡化他們的配置。前述資 源分配方法可以是基于策略的，并且容易進行修改和擴展。該方法通過有效地管理所分配 的資源，比起較不重要的客戶端顯然地為高度重要的客戶端縮短了延遲。當客戶端的運行 時行為改變以實施客戶端QoS約定時，配置可以適應資源分配?？梢砸詸?quán)利要求格式將另外的實施例描述如下All. 一種用于提供消息流的服務質(zhì)量(QoS)橋，該消息流在多個互連的中間件域 內(nèi)和在多個互連的中間件域之間具有一致的QoS級別，所述QoS橋被配置為接收來自第一 QoS管理器的至少一個QoS需求，將所述至少一個QoS需求傳播到第二 QoS管理器，以及將 所述至少一個QoS需求轉(zhuǎn)化為至少一個QoS參數(shù)，所述QoS橋被配置為使用消息接發(fā)服務 來接收和實施所述至少一個QoS參數(shù)，以及協(xié)助在所述多個互連的中間件域之間的所述消 息流。A12.根據(jù)權(quán)利要求All所述的QoS橋，其中所述至少一個QoS需求包括基于QoS 策略和可用資源中的至少一個的QoS約定。A13.根據(jù)權(quán)利要求All所述的QoS橋，其中所述QoS橋提供在所述多個互連的中 間件域之間具有一致QoS的端到端消息流。雖然已經(jīng)根據(jù)各種特定的實施例描述了本發(fā)明，但是本領域技術人員將認識到可 以在權(quán)利要求的精神和范圍內(nèi)修改實施本發(fā)明。
權(quán)利要求
一種管理信息系統(tǒng)資源以提供消息流的方法，所述消息流在多個互連的中間件域內(nèi)及其之間具有一致的服務質(zhì)量“QoS”級別，所述方法包括接收來自第一QoS管理器(426，564)的、表達至少一個QoS需求的QoS消息；將所述至少一個QoS需求轉(zhuǎn)化為針對消息接發(fā)服務(432)的至少一個參數(shù)，所述消息接發(fā)服務以通信方式耦合多個中間件域(404，406)；在第一中間件域(404)和所述消息接發(fā)服務之間創(chuàng)建客戶端連接，用于接收所述消息流；將所述QoS消息發(fā)送到第二中間件域(406)；以及在所述消息接發(fā)服務和所述第二中間件域之間創(chuàng)建客戶端連接，用于發(fā)送所述消息流。
2.根據(jù)權(quán)利要求1所述的方法，還包括基于所述至少一個QoS需求，在所述第一QoS管 理器和客戶端(24，408)之間建立用于服務質(zhì)量的第一約定，并且其中接收來自所述第一 QoS管理器的所述QoS消息包括接收來自所述第一 QoS管理器的所述第一 QoS約定。
3.根據(jù)權(quán)利要求2所述的方法，還包括以下操作中的至少一個基于所述第一QoS約 定，管理所述客戶端與所述信息系統(tǒng)的交互和基于資源分配策略，分配所述系統(tǒng)的資源。
4.根據(jù)權(quán)利要求3所述的方法，其中將所述QoS消息發(fā)送到所述第二中間件域包括根 據(jù)所述資源分配策略(446，530)轉(zhuǎn)換所述QoS消息。
5.根據(jù)權(quán)利要求1所述的方法，其中發(fā)送所述QoS消息還包括基于所述QoS消息建立 第二約定，并且基于所述第二約定管理所述消息接發(fā)服務和所述第二中間件域的交互。
6.根據(jù)權(quán)利要求1所述的方法，其中所述信息系統(tǒng)包括面向服務的體系結(jié)構(gòu)“S0A”，所 述方法作為由所述客戶端調(diào)用的服務執(zhí)行。
7.根據(jù)權(quán)利要求1所述的方法，還包括接收來自準備發(fā)布或訂閱消息或請求任務執(zhí)行 的多個QoS管理器的多個QoS消息，并且基于所述QoS消息中所表達的所述需求，與所述 QoS管理器建立用于QoS的約定。
8.根據(jù)權(quán)利要求1所述的方法，其中接收來自所述第一QoS管理器的所述QoS消息還 包括如果從所述第一 QoS管理器未提供QoS消息，則應用缺省QoS消息，所述缺省QoS消息 表達當在所述第一中間件域和所述消息接發(fā)服務之間創(chuàng)建所述客戶端連接用于接收所述 消息流時的至少一個QoS需求。
9.根據(jù)權(quán)利要求1所述的方法，還包括在訂閱者(34)處接收所述消息流。
10.一種用于在信息系統(tǒng)中管理服務質(zhì)量QoS的“QoS”管理系統(tǒng)，所述信息系統(tǒng)包括由 至少一個處理器執(zhí)行的至少第一中間件解決方案和第二中間件解決方案，所述QoS管理系 統(tǒng)包括第一 QoS管理器(426，524)，其被配置為在所述至少一個處理器上執(zhí)行，使得表達至少 一個QoS參數(shù)的QoS消息從所述信息系統(tǒng)的客戶端被接收；QoS橋(430，570)，其被配置為在所述至少一個處理器上執(zhí)行，使得所述QoS消息從所 述第一 QoS管理器被接收；以及第二 QoS管理器(428，566)，其被配置為在所述至少一個處理器上執(zhí)行，使得由所述第 二 QoS管理器接收來自所述QoS橋的所述QoS消息，并且所述QoS消息被轉(zhuǎn)發(fā)到所述信息 系統(tǒng)的訂閱者，提供在所述客戶端和所述訂閱者之間具有一致QoS的端到端消息流。
11.根據(jù)權(quán)利要求10所述的QoS管理系統(tǒng)，其中所述QoS管理系統(tǒng)使用消息接發(fā)服務 (432)，所述消息接發(fā)服務被配置為在所述至少一個處理器上執(zhí)行，使得來自所述第一中間 件解決方案的所述消息流在所述消息接發(fā)服務處被接收，由所述QoS橋協(xié)助。
12.根據(jù)權(quán)利要求11所述的QoS管理系統(tǒng)，其中所述QoS橋還被配置為進行以下操作 中的至少一個將所述接收到的QoS消息散布到所述第二 QoS管理器，使用橋策略將所述接 收到的QoS消息修改為針對所述消息接發(fā)服務的一組QoS參數(shù)。
13.根據(jù)權(quán)利要求10所述的QoS管理系統(tǒng)，其中所述第一QoS管理器還被配置為在所 述第一 QoS管理器和所述客戶端之間建立第一約定。
14.根據(jù)權(quán)利要求13所述的QoS管理系統(tǒng)，其中所述QoS橋被配置為進行以下操作中 的至少一個接收來自所述第一 QoS管理器的所述第一約定；關于所述至少一個QoS參數(shù)檢查所述系統(tǒng)的至少一個策略，并且確定用于滿足在所述 至少一個QoS參數(shù)中所表達的所述客戶端需求的至少一個資源；以及關于在來自所述第一 QoS管理器的所述QoS消息中的所述至少一個QoS參數(shù)檢查所述 系統(tǒng)的至少一個策略，并且確定至少一個QoS參數(shù)以及基于所述至少一個QoS參數(shù)將QoS 消息發(fā)送到所述第二 QoS管理器。
15.根據(jù)權(quán)利要求10所述的QoS管理系統(tǒng)，其中所述第一QoS管理器、所述QoS橋和所 述第二 QoS管理器中的至少一個被配置為基于策略和所述QoS消息中的至少一個，將所述 信息系統(tǒng)的至少一個資源分配給客戶端。
全文摘要
一種管理信息系統(tǒng)資源以提供消息流的方法，所述消息流在多個互連的中間件域內(nèi)和多個互連的中間件域之間具有一致的服務質(zhì)量“QoS”級別，所述方法包括接收來自第一QoS管理器(426，564)的、表達至少一個QoS需求的QoS消息，將所述至少一個QoS需求轉(zhuǎn)化為針對以通信方式耦合多個中間件域(404，406)的消息接發(fā)服務(432)的至少一個參數(shù)，在第一中間件域(404)和所述消息接發(fā)服務之間創(chuàng)建客戶端連接用于接收所述消息流，將所述QoS消息發(fā)送到第二中間件域(406)，以及在所述消息接發(fā)服務和所述第二中間件域之間創(chuàng)建客戶端連接用于發(fā)送所述消息流。
文檔編號H04L12/56GK101904140SQ200880106092
公開日2010年12月1日 申請日期2008年10月31日 優(yōu)先權(quán)日2007年11月7日
發(fā)明者A·陳, R·A·圣地亞哥, R·J·威尼格, 王昌周, 王桂軍 申請人:波音公司