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

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


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