專利名稱：基于策略的jms中間件群的系統(tǒng)和/或方法
技術(shù)領(lǐng)域：
本發(fā)明實(shí)施例在此公開的內(nèi)容設(shè)計(jì)應(yīng)用整合技術(shù)，尤其涉及，基于發(fā)布-訂閱 (publish-and-subscribe)模型(或與其類似的模型)的應(yīng)用整合技術(shù)。在本發(fā)明的具體 實(shí)施例中提供了在中間件群中的，基于客戶(client)的以策略為導(dǎo)向的負(fù)載平衡特性組 織的傳遞消息的中間件。本發(fā)明實(shí)施例中的負(fù)載平衡策略可以是“可分層的(Iayerable) ”， 這使得用戶可以對復(fù)合且復(fù)雜的負(fù)載平衡特性進(jìn)行定義。
背景技術(shù)：
和

發(fā)明內(nèi)容
如今的公司面臨實(shí)現(xiàn)在其企業(yè)事務(wù)中的多類型整合的解決方案的挑戰(zhàn)。這些挑戰(zhàn) 中的多數(shù)與應(yīng)用整合(如，軟件應(yīng)用和/或其他系統(tǒng)之間的整合)問題有關(guān)，同時這些挑戰(zhàn) 也也具有類似的模式。舉例來說，第一個與上述描述有關(guān)的環(huán)境涉及從一個系統(tǒng)到多個其他系統(tǒng)的相似 業(yè)務(wù)的增長，比如，訂購狀態(tài)的變化或是產(chǎn)品價格的變化。第二個環(huán)境涉及在兩個或多個系 統(tǒng)之間的相似業(yè)務(wù)進(jìn)行同步以得到單個視圖(single view)，比如，在幾個應(yīng)用中的客戶、 產(chǎn)品登記、產(chǎn)品訂購、以及產(chǎn)品SKU信息的實(shí)時同步的環(huán)境中。這是最常見的需要整合解決 方案解決的問題。在單向同步中，每一個資源常常既是同步中的潛在的起源又是目標(biāo)。不 存在作為初始數(shù)據(jù)資源的單獨(dú)的資源。這樣，任何資源發(fā)生的改變都應(yīng)當(dāng)反映到所有其他 的資源中。第三個環(huán)境與將多個起源中的信息聯(lián)合起來加入到通用的目標(biāo)系統(tǒng)中有關(guān)，比 如，將藥店客戶記錄和藥方的處理和網(wǎng)站數(shù)據(jù)聯(lián)系起來形成中央應(yīng)用和數(shù)據(jù)庫。目前可以利用多種工具來設(shè)計(jì)和實(shí)施解決方案以解決這些挑戰(zhàn)，如，采用發(fā) 布_訂閱模型或與其類似的技術(shù)。發(fā)布_訂閱模型是基于消息的解決方案類型中的一種， 在基于消息的解決方案中消息以匿名的方式通過消息中間件(message broker)進(jìn)行交換。 產(chǎn)生共享信息的應(yīng)用通過以發(fā)布至消息中間件的可識別文件的某種類型提供該信息。需要 該信息的應(yīng)用則訂閱其需要的文件類型。在運(yùn)行階段，消息中間件接收來自發(fā)布者的文件，然后將這些文件分發(fā)至訂閱者。 訂閱應(yīng)用(subscribing application)使用該文件來處理或執(zhí)行對應(yīng)的工作，并且可向發(fā) 布應(yīng)用(publishing )發(fā)送或不發(fā)送口向應(yīng)。在典型的系統(tǒng)中，整合服務(wù)器中運(yùn)行的整合服務(wù)或應(yīng)用向中間件發(fā)布文件。然后， 中間件將這些文件路由到位于其他整合服務(wù)器的訂閱者處。整合服務(wù)器和中間件共享迅 速、高效的處理過程以便在整個系統(tǒng)中交換文件。雖然這樣的技術(shù)已經(jīng)成功的用于為上述的各種環(huán)境中的問題提供解決方案，但是 仍然還需要對其做進(jìn)一步的改進(jìn)。比如，整合服務(wù)器(integration server，IS)“觸發(fā)子系 統(tǒng)(Trigger System) ”提供了用于消息處理(例如，異步消息處理)的豐富的基礎(chǔ)結(jié)構(gòu)。雖 然，這個功能僅能用于基于專有的(如，中間件)消息協(xié)議的消息處理。這樣，使用者現(xiàn)在需 要進(jìn)行艱難的設(shè)計(jì)決定，即在功能豐富的專有協(xié)議和標(biāo)準(zhǔn)的可互操作的消息協(xié)議(如，Java Message Service,即Java消息服務(wù)，簡稱JMS)之間擇一使用。解決該問題的一個途徑涉及整合服務(wù)器中的JMS適配器(adapter)的使用。以便為整合服務(wù)器同時提供專有的“觸發(fā)子系統(tǒng)”(由整合服務(wù)器提供用于專有消息處理)和獨(dú) 立的JMS適配器。不幸的是，這種解決方案從某種意義上來說是不完整的。尤其是，不管標(biāo)準(zhǔn)的可互 操作的消息處理的JMS適配器的可用性，“觸發(fā)子系統(tǒng)”的功能并不能在與JMS的連接中被 充分利用。想要在使用JMS適配器的同時擴(kuò)展“觸發(fā)子系統(tǒng)”的功能的使用者，必須定制執(zhí) 行(custom-implement)這些功能，在為每一個新的應(yīng)用的應(yīng)用中。這往往需要大量的配置 和程序設(shè)計(jì)，并將導(dǎo)致過多的非標(biāo)準(zhǔn)的相同或/和相似功能的實(shí)施。由于JMS仍然處于標(biāo) 準(zhǔn)化過程以便其可在網(wǎng)絡(luò)服務(wù)上下文中進(jìn)行使用，這個問題還會進(jìn)一步加劇。本質(zhì)上，這意 味著，如果需要這些專有的中間件的相應(yīng)的功能，那么需要在應(yīng)用服務(wù)層一次又一次的執(zhí) 行這些功能。即使這些條件都能執(zhí)行，它們也必然不是標(biāo)準(zhǔn)化的，因?yàn)?，例如，公司的組織、 流程、需求、基礎(chǔ)設(shè)施等都是不同的。這樣，問題仍然在于，不存在一個單獨(dú)的方法將現(xiàn)在的“觸發(fā)子系統(tǒng)”和其所有的 功能與基于標(biāo)準(zhǔn)的消息處理(如，通過JMS)聯(lián)系起來。相應(yīng)的，需要在功能豐富的專有協(xié) 議和基于標(biāo)準(zhǔn)的可互操作的消息協(xié)議(如JMS)之間進(jìn)行權(quán)衡。需要考慮的是，在本領(lǐng)域中需要改進(jìn)對上述涉及的和/或其他的一個或多個環(huán)境 中對應(yīng)用整合解決方案的技術(shù)進(jìn)行改進(jìn)。如前述所述，克服這些和/或其他問題有關(guān)的技術(shù)的例子與提供消息層有關(guān)，該 消息層可為解決應(yīng)用整合問題提供豐富的功能設(shè)置，這可以通過在應(yīng)用層外部存在的專有 和開放的消息結(jié)構(gòu)來實(shí)現(xiàn)。這樣的消息結(jié)構(gòu)可以是“觸發(fā)器(triggers)”的形式，在具體的 實(shí)施例中，這種觸發(fā)器可以為這樣的應(yīng)用整合問題提供發(fā)布-訂閱類型的解決方案。這些 觸發(fā)器可以是JMS觸發(fā)器。另一方面與可通過通用的觸發(fā)子系統(tǒng)達(dá)到的平行子系統(tǒng)有關(guān)，該觸發(fā)子系統(tǒng)作為 相關(guān)的觸發(fā)子系統(tǒng)上的附加值層。還有一方面與潛在的完全嵌入的JMS有關(guān)，該JMS作為整合服務(wù)觸發(fā)子系統(tǒng)中的 專有消息協(xié)議的等同物，這樣所有或潛在的所有的已存在的功能都可以被JMS使能。還有一方面與消息層的使用有關(guān)，該消息層使得對JMS消息處理可以不使用整合 服務(wù)器中的特定適配器。進(jìn)一步的，該消息層可以避免對JMS觸發(fā)器本身進(jìn)行任何改變，并 且/或可降低在應(yīng)用服務(wù)層級對客戶程序進(jìn)行設(shè)計(jì)和/或執(zhí)行的需要，在一些具體實(shí)施例 中。雖然這些中間件具有一些優(yōu)點(diǎn)，但是仍然需要對其進(jìn)行進(jìn)一步的改進(jìn)。比如，需要 考慮對中間件進(jìn)行改進(jìn)以便擴(kuò)展提供的負(fù)載平衡功能。實(shí)際上，本申請的發(fā)明人注意到，在 最近的幾年中，客戶需要為其中間件應(yīng)用提供失效備援(failover，或稱故障切換)和負(fù)載 平衡特性。相應(yīng)的，本發(fā)明的具體實(shí)施例中的一方面與使得中間件實(shí)現(xiàn)客戶端的故障切換和 負(fù)載平衡功能有關(guān)。在具體實(shí)施例中的負(fù)載平衡功能處于應(yīng)用空間中，并且可對其進(jìn)行擴(kuò)展。本發(fā)明的具體實(shí)施例的另一方面與使得負(fù)載平衡功能與中間件群一起工作有關(guān)。 基于此，發(fā)布者和訂閱者可與中間件群連接，中間件群中的中間件可以共享從發(fā)布者到訂 閱者的消息路由。
具體實(shí)施例的再一方面與提供通過一個或多個策略進(jìn)行負(fù)載平衡功能有關(guān)，這些 策略可能是“可疊堆的(stackable) ”、“可分層的(Iayerable) ”、或“復(fù)合的(compound)”。本發(fā)明的具體實(shí)施例與應(yīng)用整合系統(tǒng)有關(guān)。發(fā)布應(yīng)用被配置為產(chǎn)生和發(fā)送消息。 消息依照使用者定義的復(fù)合策略進(jìn)行發(fā)送，該策略包括至少第一和第二策略層。提供第一 和第二中間件群。每一個中間件群包括多個中間件，每一個中間件被配置成將消息從發(fā)布 應(yīng)用轉(zhuǎn)發(fā)(relay，或稱中繼)到至少一個訂閱應(yīng)用。復(fù)合群連接與發(fā)布應(yīng)用相連。多個群 連接與復(fù)合群連接相連。復(fù)合群連接被配置為將消息按照第一策略層路由至至少一個群連 接。每一個群連接被配置為將消息按照第二策略層路由至至少一個中間件。本發(fā)明的具體實(shí)施例與應(yīng)用整合系統(tǒng)中的消息路由方法有關(guān)。提供發(fā)布應(yīng)用。提 供第二中間件群。每一個中間件群包括多個中間件，每一個中間件被配置為將消息從發(fā)布 應(yīng)用轉(zhuǎn)發(fā)到至少一個訂閱應(yīng)用。復(fù)合群連接與發(fā)布應(yīng)用相連。多個群連接與復(fù)合群連接相 連。通過發(fā)布應(yīng)用產(chǎn)生消息。該消息按照使用者定義的包括至少第一和第二策略層的復(fù)合 策略被從發(fā)布應(yīng)用發(fā)送至中間件群。消息從復(fù)合群連接按照第一策略層路由至至少一個群 連接。消息按照第二策略層從至少一個群路由至至少一個中間件。本發(fā)明的具體實(shí)施例與調(diào)用應(yīng)用整合系統(tǒng)中的目標(biāo)服務(wù)的方法有關(guān)。提供第一和 第二客戶系統(tǒng)，這兩個系統(tǒng)實(shí)施發(fā)布/訂閱消息交換模型。提供至少一個中間件群，該中間 件群包括多個中間件服務(wù)器。第一客戶系統(tǒng)產(chǎn)生消息，該消息用于觸發(fā)調(diào)用第二客戶系統(tǒng) 上的目標(biāo)服務(wù)。該消息基于第一客戶系統(tǒng)定義的策略從第一客戶系統(tǒng)路由至在至少一個中 間群中的至少一個中間件，再路由到第二客戶系統(tǒng)。第二客戶系統(tǒng)接收該消息。通過第二 客戶系統(tǒng)調(diào)用目標(biāo)服務(wù)。這些具體實(shí)施例和實(shí)施例的各方面可以分開使用，和/或進(jìn)行不同的組合使用， 以獲得本發(fā)明的其他實(shí)施例。


通過參考本發(fā)明實(shí)施例及其相關(guān)附圖中的具體描述，可以更好和更全面的理解各 個特點(diǎn)和優(yōu)點(diǎn)圖1是應(yīng)用整合系統(tǒng)的組成示意圖；圖2是當(dāng)整合系統(tǒng)與中間件連接時，其如何向中間件發(fā)布或分發(fā)文件的示意圖；圖3是當(dāng)沒有中間件時整合服務(wù)器如何發(fā)布文件的示意圖；圖4是當(dāng)請求/響應(yīng)同步時，整合服務(wù)器向中間件發(fā)布文件并等待響應(yīng)的示意 圖；圖5是整合服務(wù)器為已發(fā)布的文件進(jìn)行訂閱的路徑的示意圖；圖6是整合服務(wù)器為已分發(fā)至默認(rèn)客戶的文件進(jìn)行訂閱的路徑的示意圖；圖7是本地發(fā)布文檔的發(fā)布和訂閱路徑的示意圖；圖8是發(fā)布和訂閱模型的整合解決方案中的兩側(cè)的示意圖，其中，可發(fā)布的文檔 類型與相同中間件文檔類型相連；圖9是當(dāng)前的消息層的示意圖；圖10是本發(fā)明實(shí)施例中的消息層的示意圖；圖11是本發(fā)明實(shí)施例中的與產(chǎn)生中間件群有關(guān)的多個元素的示意圖12是本發(fā)明實(shí)施例中的基于負(fù)載平衡技術(shù)的公共應(yīng)用接口的示意圖；圖13 15是本發(fā)明實(shí)施例中的群連接、策略管理以及中間件選擇的類的圖表的 示意圖；圖16是本發(fā)明實(shí)施例中的負(fù)載平衡中間件JMS應(yīng)用的結(jié)構(gòu)示意圖；圖17是本發(fā)明實(shí)施例中的負(fù)載平衡發(fā)布/訂閱模型的具體實(shí)施有關(guān)的多個元素 的示意圖；圖18是本發(fā)明實(shí)施例中的基于循環(huán)(round robin)策略的負(fù)載平衡發(fā)布的流程 序的示意圖；圖19是本發(fā)明實(shí)施例中的當(dāng)訂閱者應(yīng)用產(chǎn)生JMS連接時的群連接的示意圖；圖20是本發(fā)明實(shí)施例中的采用中間件群的有保證的(guaranteed)多發(fā)送策略的 具體示意圖；圖21是本發(fā)明實(shí)施例中的執(zhí)行了復(fù)合策略的負(fù)載均衡中間件JMS應(yīng)用的結(jié)構(gòu)的 示意圖；以及圖22 23是使用整合服務(wù)來調(diào)用發(fā)布服務(wù)和觸發(fā)器的不同具體技術(shù)的示意圖。 具體實(shí)施例下面將對本發(fā)明實(shí)施例中的應(yīng)用整合系統(tǒng)和操作方法進(jìn)行描述。應(yīng)當(dāng)理解的是， 下述的描述不應(yīng)作為對本發(fā)明實(shí)施例的限制。實(shí)際上，下述描述的示例主要描述了通過一 個發(fā)布-訂閱方式解決實(shí)際應(yīng)用中出現(xiàn)的與應(yīng)用整合問題的有關(guān)技術(shù)，其可用在本發(fā)明實(shí) 施例中的與消息層、觸發(fā)器、以及觸發(fā)子系統(tǒng)的連接中?，F(xiàn)在參考附圖進(jìn)行進(jìn)一步說明，附圖1是應(yīng)用整合系統(tǒng)100的組成示意圖。圖中 示意了多個整合服務(wù)器，每一個整合服務(wù)器都與中間件106通訊連接。其中，示意了第一整 合服務(wù)器102、包括多個適配器108的第二整合服務(wù)器102’、以及包括多個適配器108’的 整合服務(wù)器群102”。總的來說，整合服務(wù)器是系統(tǒng)的中央運(yùn)行階段的組成組件。其作為需要整合的系 統(tǒng)和應(yīng)用的進(jìn)入節(jié)點(diǎn)，并且也是系統(tǒng)的執(zhí)行整合邏輯的主要引擎。其還提供了下層處理程 序和設(shè)備，用于管理來自企業(yè)內(nèi)部或/或外部的資源104(或資源群104’)的信息的有序處 理。整合服務(wù)器102向中間件發(fā)布文檔并接收來自中間件的文檔。本發(fā)明實(shí)施例中的中間件106形成了潛在的全局的可升級的消息傳輸主干。其提 供了基于發(fā)布_訂閱模型或其類似模型(例如，請求/響應(yīng)、發(fā)布_等待等)的異步、基于 消息的解決方案的執(zhí)行基礎(chǔ)架構(gòu)。中間件106在信息產(chǎn)生者(如，發(fā)布者)和信息消費(fèi)者(如，訂閱者)之間進(jìn)行文 檔路由。這樣，中間件106接收、排列、以及分發(fā)文檔。中間件106保留其識別的注冊文檔 類型。其還保留與接收這些文檔類型有關(guān)的訂閱者的列表。當(dāng)中間件106接收發(fā)布的文檔 時，其為該文檔類型的訂閱者對該接收的文檔進(jìn)行排序。訂閱者從其隊(duì)列中取回文檔。該 動作常常會觸發(fā)處理該文檔的訂閱者的系統(tǒng)上的動作(activity)。系統(tǒng)100中可選擇性包括多個(multiple)中間件106。多個中間件106可以按照 組(稱為區(qū)域)的形式進(jìn)行操作，這使得幾個中間件106可共享文檔類型和訂閱信息。下述是對使用了發(fā)布-訂閱模型的整合解決方案的基本組成模塊的描述。這些組成模塊包括，例如，文檔、可發(fā)布的文檔類型、觸發(fā)器、服務(wù)、適配器通知、以及標(biāo)準(zhǔn)文檔。在基于發(fā)布_訂閱模型的整合解決方案中，應(yīng)用發(fā)布和訂閱文檔。文檔是上述提 及的組成組件用來封裝和交換數(shù)據(jù)的對象。文檔代表了資源傳輸至組成部分的數(shù)據(jù)的主 體。通常，其代表業(yè)務(wù)事件諸如，發(fā)訂單(例如，通過購買訂單文檔)、運(yùn)送貨物(例如，通過 運(yùn)送通知)、添加新員工(例如，通過新員工記錄)等。每一個發(fā)布的文檔都包括封裝。該封裝更像電子郵件信息中的頭部。封裝記錄諸 如發(fā)送者地址、文檔發(fā)送時間、序列號、和/或其他對路由或控制有用的信息。其還包括有 關(guān)文檔和其在系統(tǒng)中傳送的信息。每一個發(fā)布的文檔都與可發(fā)布的文檔類型有關(guān)?？砂l(fā)布的文檔類型是已命名的類 似圖表的定義，其描述了可以被發(fā)布和訂閱的特定的文檔類型的結(jié)構(gòu)?？砂l(fā)布的文檔類型 的實(shí)體可以在整合服務(wù)器內(nèi)進(jìn)行本地發(fā)布或是被發(fā)布至中間件。在包括中間件的公共環(huán)境 中，每一個可發(fā)布的文檔類型都必然是中間件的文檔類型。中間件上的客戶訂閱可發(fā)布的 文檔類型。中間件使用可發(fā)布的文檔類型來決定將文檔分發(fā)至哪個客戶。在此處描述的本發(fā)明實(shí)施例的發(fā)布_訂閱模型中，觸發(fā)器建立對可發(fā)布的文檔類 型的訂閱。觸發(fā)器還明確將要處理通過該訂閱接收的文檔的服務(wù)。在觸發(fā)器中，通過條件 將一個或多個可發(fā)布的文檔類型與服務(wù)關(guān)聯(lián)起來。服務(wù)是工作(work)中的類似方法的單元。其包括整合服務(wù)器執(zhí)行的程序邏輯。服 務(wù)可被建立來執(zhí)行工作，諸如，從文檔中抽取數(shù)據(jù)、與后端資源相互影響、向中間件發(fā)布文 檔等等。當(dāng)觸發(fā)器被建立時，使用者可以定義用來處理被訂閱的文檔的服務(wù)。每當(dāng)適配器的資源上發(fā)生特定的事件時，適配器通知(adapter notification)總 是通知系統(tǒng)。當(dāng)資源中發(fā)生特定的事件時，適配器通知發(fā)布文檔。每一個適配器通知包括相 關(guān)的可發(fā)布的文檔類型。觸發(fā)器可以用來訂閱與適配器通知有關(guān)的可發(fā)布的文檔類型。與 觸發(fā)狀態(tài)下的與可發(fā)布的文檔類型有關(guān)的服務(wù)可，如，執(zhí)行一些額外的處理、更新、和/或 同步，如，基于適配器通知內(nèi)容的。標(biāo)準(zhǔn)文檔是當(dāng)文檔在系統(tǒng)中傳輸時的可能的標(biāo)準(zhǔn)表現(xiàn)形式。標(biāo)準(zhǔn)文檔作為各資 源間的中間數(shù)據(jù)形式。例如，從企業(yè)接收購買訂單的執(zhí)行實(shí)例中，流程中的一個步驟可能 是將購買訂單文檔轉(zhuǎn)換為企業(yè)的標(biāo)準(zhǔn)購買訂單格式。該格式被稱為購買訂單文檔的“標(biāo)準(zhǔn) (canonical) ”格式。該標(biāo)準(zhǔn)文檔可被發(fā)布、發(fā)送、以及傳輸至處理購買訂單的服務(wù)。通過將文檔轉(zhuǎn)換為中性的中間格式，訂閱者(如，適配器服務(wù))僅僅需要知道如何 將標(biāo)準(zhǔn)文檔轉(zhuǎn)換為所需的應(yīng)用格式即可。如果不使用標(biāo)準(zhǔn)文檔，那么每一個訂閱者都必須 可對每一個發(fā)布者的原始文檔格式進(jìn)行解碼。標(biāo)準(zhǔn)文檔為可發(fā)布的文檔類型。當(dāng)建立發(fā)布服務(wù)時可使用標(biāo)準(zhǔn)文檔，當(dāng)建立觸發(fā) 器時其被訂閱。在流服務(wù)(flow services)中，可以將文檔從應(yīng)用的原始格式映射為標(biāo)準(zhǔn) 格式。如圖2 7所示，為訂閱_發(fā)布路徑的原理示意圖。如前所述，整合服務(wù)器通過訂 閱和發(fā)布交換文檔。一個整合服務(wù)器發(fā)布文檔，而一個或多個整合服務(wù)器訂閱并處理該文 檔。整合服務(wù)器通常與中間件交互來發(fā)布和訂閱文檔。舉例來說，整合服務(wù)器可向中間件 發(fā)布文檔，整合服務(wù)器可從中間件取回文檔，和/或整合服務(wù)器可在本地發(fā)布和訂閱文檔。當(dāng)整合服務(wù)器被配置為與中間件連接時，該整合服務(wù)器可以向中間件發(fā)布文檔。
9然后，中間件將文檔路由至所有的訂閱者。如下所述為3種發(fā)布路徑情況的示例向中間件 發(fā)布文檔，當(dāng)中間件不可用時向中間件發(fā)布文檔，向中間件發(fā)布文檔并等待響應(yīng)(如，類似 請求/響應(yīng)場景)。如果沒有為整合服務(wù)器配置中間件，所有的發(fā)布都可能變成本地發(fā)布， 并且也不能實(shí)現(xiàn)向特定的接受者發(fā)布文檔。以下將對該可能性進(jìn)行詳細(xì)描述。如圖2所示，為當(dāng)與中間件連接時整合服務(wù)器如何發(fā)布和訂閱文檔的示意圖。當(dāng) 整合服務(wù)器向已配置的中間件發(fā)送文檔時，該整合服務(wù)器發(fā)布或分發(fā)該文檔。當(dāng)整合服務(wù) 器發(fā)布文檔時，其可能被廣播發(fā)送往所有的訂閱者。中間件將文檔路由至所有已訂閱了該 文檔的客戶。當(dāng)整合服務(wù)器分發(fā)文檔時，該分發(fā)請求明確文檔的接受者。中間件僅為特定 的客戶對文檔進(jìn)行排隊(duì)。整合服務(wù)器102中的發(fā)布服務(wù)202向分配器204發(fā)送文檔(或當(dāng)資源中產(chǎn)生事件 時適配器通知發(fā)布文檔，適配器監(jiān)視)(步驟S201)。在整合服務(wù)器102向分配器204發(fā)送 文檔之前，驗(yàn)證文檔的可發(fā)布的文檔類型。如果文檔是無效的，服務(wù)202返回指示無效錯誤 的異常響應(yīng)。分配器204從連接池206處獲得連接208 (步驟S202)。該連接池206是連 接208的預(yù)先定義的集合，整合服務(wù)器102采用該連接向中間件106發(fā)布文檔。為向中間 件106發(fā)布文檔，整合服務(wù)器102使用連接208作為默認(rèn)客戶的連接。分配器204向中間 件106發(fā)送文檔(步驟S203)。中間件106為文檔檢查存儲類型，以決定如何存儲該文檔(S204)。例如，如果文 檔為易失的(volatile)，則中間件106可將該文檔存儲在內(nèi)存210。如果文檔為有保證的 (guaranteed)，則中間件106可將該文檔存儲在內(nèi)存210和/或在磁盤212上。中間件106將文檔路由至訂閱者(步驟S205)。如果文檔已經(jīng)發(fā)布(如，廣播)，中 間件106確認(rèn)訂閱者，并為每一個訂閱者在客戶隊(duì)列(如，第一和第二客戶隊(duì)列214a b) 中生成該文檔的副本。如果文檔被分發(fā)，中間件106將文檔置于特定分發(fā)請求中的客戶的 隊(duì)列中(如，第一和第二客戶隊(duì)列214a b)。如果該文檔沒有訂閱者，則中間件106向發(fā) 布者202返回確認(rèn)，并接著丟棄文檔。如果，存在文檔的死亡信件(deadletter)訂閱，則中 間件106將文檔置于包括死亡信件訂閱的隊(duì)列中(例如，第一和/或第二客戶隊(duì)列214a b)。在中間件106中文檔一直保留在隊(duì)列中(如，第一和/或第二客戶隊(duì)列214a b)直 到訂閱客戶被拾獲?？梢灶A(yù)先設(shè)定存活時間，例如，通過用戶設(shè)定。如果文檔為有保證的， 中間件106向分配器204返回確認(rèn)信息以提示文檔被成功的接收和存儲(步驟S206)。分 配器204將連接208返還給連接池206。整合服務(wù)器102向發(fā)布服務(wù)202返還控制以執(zhí)行 下一步驟(步驟S207)?？梢詫砂l(fā)布的文檔類型和整合服務(wù)器102進(jìn)行配置，這樣當(dāng)文檔被發(fā)布時整合 服務(wù)器102不會驗(yàn)證文檔。同時，當(dāng)整合服務(wù)器102發(fā)布文檔發(fā)生傳輸錯誤時，審核子系統(tǒng) 可記錄該文檔并將其標(biāo)記為“失敗(FAILED)”狀態(tài)。傳輸錯誤是根據(jù)條件產(chǎn)生的錯誤，可被 迅速的解決，例如，與網(wǎng)絡(luò)連接的資源不可用或不可以連接到數(shù)據(jù)庫。可使用監(jiān)測器來發(fā)現(xiàn) 和重發(fā)狀態(tài)為“失敗”的文檔。如圖3所示，為當(dāng)中間件不可用時整合服務(wù)器如何發(fā)布文檔的原理示意圖。簡而 言之，整合服務(wù)器102不斷的檢測其與中間件106之間的連接208，如果其確定已配置的中 間件106不可用則可改變發(fā)布路徑。如果沒有與中間件106連接，整合服務(wù)器106可將有保 證的文檔路由至出站文檔存儲302。文檔可保留在出站文檔存儲302中直到與中間件106的連接208重新建立起來。整合服務(wù)器102中的發(fā)布服務(wù)202向分配器204發(fā)送文檔(或當(dāng)資源中發(fā)生事件 時適配器通知發(fā)布文檔，適配器監(jiān)視)(步驟S301)。在整合服務(wù)器102向分配器204發(fā)送 文檔之前，驗(yàn)證文檔的可發(fā)布文檔類型。如果文檔是無效的，服務(wù)202返回指示無效錯誤的 異常響應(yīng)。分配器204檢測到中間件106不可用。相應(yīng)的，存儲該文檔。例如，如果文檔是 有保證的，分配器204將文檔路由至出站文檔存儲302中(例如，在磁盤上)。如果文檔是 易失的，分配器204丟棄文檔，同時發(fā)布服務(wù)發(fā)出異常響應(yīng)。整合服務(wù)器102執(zhí)行發(fā)布服務(wù) 中的下一步驟。當(dāng)整合服務(wù)器102重新建立起與中間件106的連接時，整合服務(wù)器102從連接池 206處獲得連接208(步驟S303)。整合服務(wù)器102自動從出站文檔存儲302中向中間件 106發(fā)送文檔(S304)。為更迅速的清空出站文檔存儲302，整合服務(wù)器102可以一次發(fā)送一 批文檔。應(yīng)當(dāng)理解的是，整合服務(wù)器102可使用單一連接208來清空出站文檔存儲302，例 如，以保存已發(fā)布的命令。中間件106為文檔檢查存儲類型，如果確定文檔為有保證的，則將該文檔存儲在 內(nèi)存210和磁盤212上(S305)。中間件106將文檔路由至訂閱者(步驟S306)。如果文檔 已經(jīng)發(fā)布(如，廣播)，中間件106確認(rèn)訂閱者，并為每一個訂閱者在客戶隊(duì)列(如，第一和 第二客戶隊(duì)列214a b)中生成該文檔的副本。如果文檔被分發(fā)，中間件106將文檔置于 特定分發(fā)請求中的客戶的隊(duì)列中(如，第一和第二客戶隊(duì)列214a b)。如果該文檔沒有訂 閱者，則中間件106向發(fā)布者202返回確認(rèn)，并接著丟棄文檔。如果，存在文檔的死亡信件 訂閱，則中間件106將文檔置于包括死亡信件訂閱的隊(duì)列中(例如，第一和/或第二客戶隊(duì) 列214a b)。在中間件106中文檔一直被保留在隊(duì)列中(如，第一和/或第二客戶隊(duì)列 214a b)直到訂閱客戶被拾獲?？梢灶A(yù)先設(shè)定存活時間，例如，通過用戶設(shè)定。如果文檔 為有保證的，中間件106向分配器204返回確認(rèn)信息以提示文檔被成功的接收和存儲(步 驟S206)。分配器204將連接208返還給連接池206。中間件106向整合服務(wù)器102返回 確認(rèn)信息以提示文檔被成功的接收和存儲(S307)。整合服務(wù)器102向發(fā)布服務(wù)202返還控 制以執(zhí)行下一步驟(步驟S307)。整合服務(wù)器102從出站文檔存儲302中移除文檔。當(dāng)中間件106不可用時，可以通過將已發(fā)布的文檔置于出站文檔存儲302以保留 該文檔，整合服務(wù)器102被配置為替代的發(fā)出異常響應(yīng)。當(dāng)與中間件106的連接被重新建 立時，整合服務(wù)器102可以將所有新的已發(fā)布的文檔(例如，易失的和有保證的)發(fā)送至出 站文檔存儲302，直至出站文檔存儲302被清空。這樣，整合服務(wù)器102可以保持發(fā)表的次 序。在整合服務(wù)器102清空出站文檔存儲之后，整合服務(wù)器102可以重新直接向中間件106 發(fā)布文檔。如果整合服務(wù)器102具有一個確定的嘗試次數(shù)來從出站文檔存儲302中向中間件 106發(fā)送文檔，當(dāng)所有次的嘗試均失敗時，審核子系統(tǒng)可記錄該文檔并標(biāo)記其狀態(tài)為“多次 嘗試失敗(TOO MANY TRIES)”。當(dāng)整合服務(wù)器102發(fā)布文檔時如果產(chǎn)生傳輸錯誤，審核子系 統(tǒng)可記錄該文檔并標(biāo)記其狀態(tài)為“失敗(FAILED)”?？梢詫砂l(fā)布的文檔類型和整合服務(wù) 器102進(jìn)行配置，這樣，當(dāng)文檔被發(fā)布時整合服務(wù)器102不對其進(jìn)行驗(yàn)證?？梢允褂脵z測器 來發(fā)現(xiàn)和重發(fā)狀態(tài)為“多次嘗試失敗”或“失敗”的文檔。如圖4所示，為整合服務(wù)器向中間件發(fā)布文檔并等待響應(yīng)(Mply)的示意圖，其中請求/響應(yīng)為同步的。在發(fā)布_等待情況下，服務(wù)發(fā)布文檔(如，請求)，然后等待響應(yīng)文 檔。有時稱之為請求/響應(yīng)模型。請求/響應(yīng)可以是同步或異步的。在同步請求/響應(yīng)中， 在等待響應(yīng)時發(fā)布流服務(wù)停止執(zhí)行。當(dāng)服務(wù)收到來自特定客戶的響應(yīng)文檔時，服務(wù)繼續(xù)執(zhí) 行。在異步請求/響應(yīng)中，在發(fā)布請求文檔后發(fā)布流服務(wù)連續(xù)執(zhí)行。即是說，發(fā)布服務(wù)在執(zhí) 行流服務(wù)中的下一步驟前不會等待響應(yīng)。發(fā)布流服務(wù)調(diào)用單獨(dú)的服務(wù)來取回響應(yīng)文檔。發(fā)布服務(wù)202向分配器204發(fā)送文檔(例如，請求)(步驟S401)。整合服務(wù)器102 以獨(dú)一無二的標(biāo)識在文檔封裝中填入標(biāo)記域，以用來與該請求的響應(yīng)文檔進(jìn)行匹配。發(fā)布 服務(wù)202進(jìn)入等待狀態(tài)。發(fā)布服務(wù)202不進(jìn)行后續(xù)動作直到其收到來自訂閱者的響應(yīng)或是 達(dá)到等待時間。整合服務(wù)器102可在其一發(fā)布文檔時就開始對等待時間進(jìn)行計(jì)時。在整合 服務(wù)器102向分配器204發(fā)送文檔之前，其可驗(yàn)證文檔的可發(fā)布文檔類型。如果文檔是無 效的，服務(wù)202可返回代表無效錯誤的異常信息。然后，服務(wù)202可在發(fā)出異常信息的同時 解除阻塞(unblock)分配器204從連接池206處獲得連接(步驟S402)。該連接池206是連接208的 預(yù)定集合，整合服務(wù)器102采用該連接向中間件106發(fā)布文檔。為向中間件106發(fā)布文檔， 整合服務(wù)器102使用連接208作為請求/響應(yīng)客戶的連接。如果中間件106不可用，分配 器204可將文檔路由至出站文檔存儲302，如按照如前所述的方法。分配器204向中間件 106發(fā)送文檔(步驟S403)。中間件106為文檔檢查存儲類型，以決定如何存儲該文檔(S404)。例如，如果文檔 為易失的，則中間件106可將該文檔存儲在內(nèi)存210。如果文檔為有保證的，則中間件106可 將該文檔存儲在內(nèi)存210和磁盤212上。中間件106將文檔路由至訂閱者(步驟S405)。如 果文檔已經(jīng)發(fā)布(如，廣播)，中間件106確認(rèn)訂閱者，并為每一個訂閱者在客戶隊(duì)列(如， 第一和第二客戶隊(duì)列214a b)中生成該文檔的副本。如果文檔被分發(fā)，中間件106將文 檔放置在特定分發(fā)請求的客戶的隊(duì)列中(如，第一和第二客戶隊(duì)列214a b)。如果該文檔 沒有訂閱者，則中間件106向發(fā)布者202返回確認(rèn)，并接著丟棄文檔。如果，存在文檔的死 亡信件訂閱，則中間件106將文檔置于包括死亡信件訂閱的隊(duì)列中(例如，第一和/或第二 客戶隊(duì)列214a b)。在中間件106中文檔被一直保留在隊(duì)列中(如，第一和/或第二客戶 隊(duì)列214a b)直到訂閱客戶被拾獲。可以預(yù)先設(shè)定存活時間，例如，通過用戶設(shè)定。如果 文檔為有保證的，中間件106向分配器204返回確認(rèn)信息以提示文檔被成功的接收和存儲 (步驟S406)。分配器204將連接208返還給連接池206。訂閱者取回并處理文檔(S407)。訂閱者采用服務(wù)(圖中未示)來組成和發(fā)布響 應(yīng)文檔。該服務(wù)自動在響應(yīng)文檔封裝的標(biāo)記域填入與請求文檔封裝的標(biāo)記域中填入的值相 同的值。該服務(wù)還自動的確定請求客戶作為響應(yīng)文檔的接受者。一個或多個訂閱向中間件 106發(fā)送響應(yīng)文檔(S408)。中間件106將該響應(yīng)文檔存儲在，如，內(nèi)存210處。中間件106 將響應(yīng)文檔置于為發(fā)起該請求的整合服務(wù)器102設(shè)置的請求/響應(yīng)客戶隊(duì)列402中。發(fā)起該請求的整合服務(wù)器102從連接池206中獲取請求/響應(yīng)客戶，并從中間件 106中取回響應(yīng)文檔(S409)。整合服務(wù)器102利用響應(yīng)文檔的標(biāo)記域與原始請求的進(jìn)行匹 配(S410)。整合服務(wù)器102將響應(yīng)文檔置于等待服務(wù)404的流水線(pipeline)中(S411)。 等待服務(wù)重新執(zhí)行。如果請求服務(wù)為響應(yīng)文檔定義了可發(fā)布的文檔類型，則響應(yīng)文檔需要符合該特定的與之類似的類型。否則，響應(yīng)文檔可以是任意的可發(fā)布的文檔類型。需要注意的是，單個 請求可以接收多個響應(yīng)。發(fā)起請求的整合服務(wù)器102可以僅使用其從中間件106取回的第 一響應(yīng)文檔。整合服務(wù)器102也可以丟棄其他所有的響應(yīng)。對“第一”可以進(jìn)行任意的解 釋。中間件106處理到達(dá)的響應(yīng)的次序中可以不提供保證。所有的響應(yīng)文檔都可被當(dāng)做易失的文檔。易失文檔可以存儲在內(nèi)存210中，并且 如果響應(yīng)文檔所處于的資源關(guān)閉了或者在響應(yīng)文檔傳輸過程中連接208丟失了該響應(yīng)文 檔可能丟失。如果在服務(wù)接收響應(yīng)之前已經(jīng)經(jīng)過了等待時間，整合服務(wù)器102可結(jié)束請求，而 該服務(wù)可返回空文檔以提示請求超時。整合服務(wù)器102可執(zhí)行流服務(wù)中的下一個步驟。如 果響應(yīng)文檔在流服務(wù)重新執(zhí)行之前后到達(dá)，整合服務(wù)器102可拒收該文檔并產(chǎn)生日志記錄 消息說明由于沒有線程在等待該文檔所以拒收該文檔。可發(fā)布的文檔類型和整合服務(wù)器 102可以被配置為，當(dāng)文檔發(fā)布時整合服務(wù)器102不驗(yàn)證文檔。當(dāng)整合服務(wù)器與中間件連接時，文檔在訂閱側(cè)經(jīng)歷的路徑包括，例如，從中間件取 回文檔，在整合服務(wù)器上存儲文檔，以及處理文檔。文檔的訂閱路徑可能取決于文檔是向所 有的訂閱者發(fā)布(例如，廣播)還是直接向整合服務(wù)器分發(fā)。如圖5所示，為整合服務(wù)器訂閱已發(fā)布的文檔的路徑的示意圖。當(dāng)發(fā)布或廣播文 檔時，中間件針對每一訂閱觸發(fā)器將文檔的副本置于客戶隊(duì)列中。每一訂閱觸發(fā)器將取回 和處理文檔。整合服務(wù)器102中的分配器204采用服務(wù)線程來請求中間件106上的觸發(fā)器的客 戶隊(duì)列214a中的文檔(S501)。需要說明的是，整合服務(wù)器102上的每一個觸發(fā)器可具有處 于中間件106上的相應(yīng)的客戶隊(duì)列。線程為觸發(fā)器取回批量文檔(S502)。分配器204將文 檔置于觸發(fā)器文檔存儲502中的觸發(fā)器隊(duì)列214a中(S503)?？蓪⒂|發(fā)器文檔存儲502存 儲在，例如，內(nèi)存210中。然后，分配器204釋放用于取回文檔的服務(wù)線程。分配器204從服務(wù)線程池(圖中未示)中獲得線程，從觸發(fā)器隊(duì)列214a中 拉取文檔，并評估在觸發(fā)器中的文檔的條件(S504)。如果為觸發(fā)器配置了僅發(fā)生一次 (exactly-once)的處理流程，則整合服務(wù)器102可先確定文檔是否為已經(jīng)被觸發(fā)器處理過 的文檔的副本。在這種情況下，僅當(dāng)文檔是新的的時候，整合服務(wù)器102才會連續(xù)處理文 檔。如果文檔符合觸發(fā)器條件，分配器204執(zhí)行與該條件有關(guān)的觸發(fā)器服務(wù)(S502a) (S504)。如果文檔不符合觸發(fā)器條件，整合服務(wù)器102可丟棄文檔，向中間件106返回確認(rèn) 信息，并將服務(wù)線程返回至服務(wù)線程池。整合服務(wù)器102也可產(chǎn)生日志記錄消息記錄該文 檔沒有與條件匹配。觸發(fā)器服務(wù)執(zhí)行至結(jié)束(如，成功或錯誤)(S506)。如果觸發(fā)器服務(wù)502a成功的 執(zhí)行了，整合服務(wù)器102向中間件106返回確認(rèn)信息(例如，如果這是有保證的文檔)。然 后，整合服務(wù)器102從觸發(fā)器服務(wù)214a中移除文檔的副本，并將服務(wù)線程返回至服務(wù)線程 池。如果產(chǎn)生服務(wù)異常，觸發(fā)器服務(wù)502a以錯誤結(jié)束，整合服務(wù)器102拒收文檔。如果文 檔是有保證的，整合服務(wù)器102向中間件106返回確認(rèn)信息。整合服務(wù)器102從觸發(fā)器隊(duì) 列214a中移除該文檔副本，將服務(wù)線程返回至服務(wù)線程池中，并發(fā)送錯誤文檔以指示產(chǎn)生 了錯誤。如果在觸發(fā)器服務(wù)執(zhí)行期間產(chǎn)生了傳輸錯誤，服務(wù)獲取該錯誤，將其覆蓋(wraps)并重新作為異常丟棄，然后，整合服務(wù)器102等待重試間隔時長(該重試間隔可以被預(yù)先定 義和/或由用戶定義)并使用原始文檔作為輸入重新執(zhí)行該服務(wù)。如果整合服務(wù)器102達(dá) 到最大重試次數(shù)(也可以被預(yù)先定義和/或由用戶定義)，并且觸發(fā)器服務(wù)502a由于傳輸 錯誤仍然失敗了，整合服務(wù)器102將最后一次失敗作為服務(wù)錯誤處理。當(dāng)收到確認(rèn)信息后，中間件106可從有保證的存儲212中移除文檔的副本。整合 服務(wù)器102可僅為有保證的文檔返回確認(rèn)信息。如果整合服務(wù)器102在確認(rèn)有保證的文檔 之前關(guān)閉或重連與中間件106的連接，則當(dāng)服務(wù)重啟或連接重新建立時，整合服務(wù)器102可 從中間件106處重新獲得該文檔。這樣，文檔可被重新分發(fā)。如果觸發(fā)器服務(wù)產(chǎn)生了基于 錯誤的審核數(shù)據(jù)并包括審核記錄中輸入流水線的副本，監(jiān)測器可用來在稍后的時間重新調(diào) 用觸發(fā)器服務(wù)。在觸發(fā)器中，文檔可能滿足一個以上的條件。然而，整合服務(wù)器102可能僅執(zhí)行與 第一被滿足的條件相關(guān)的服務(wù)。觸發(fā)器的處理模式?jīng)Q定了整合服務(wù)器102以連續(xù)的還是同 時的方式處理觸發(fā)器隊(duì)列中的文檔。在連續(xù)處理中，整合服務(wù)器102按照文檔在觸發(fā)隊(duì)列 中的次序一次處理一個文檔。在同時處理中，整合服務(wù)器102 —次處理其可處理的多個文 檔，但是不一定按照文檔在隊(duì)列中的順序處理。需要說明的是，在同時處理中，整合服務(wù)器 102 —次可處理的文檔數(shù)目取決于可用線程的最大數(shù)目，這在具體實(shí)施例中可由用戶來配 置。如果在文檔取回或存儲中發(fā)生傳輸錯誤，審核子系統(tǒng)可記錄該文檔并標(biāo)記其狀態(tài) 為“失敗”。傳輸錯誤是根據(jù)條件產(chǎn)生的錯誤，可能稍后被解決，例如，與網(wǎng)絡(luò)連接的資源不 可用或不可以連接到數(shù)據(jù)庫?？墒褂帽O(jiān)測器來發(fā)現(xiàn)和重發(fā)狀態(tài)為“失敗”的文檔。并且，觸 發(fā)器可被配置為如果發(fā)生重試失敗則暫停(suspend)或在稍后的時間里重試。當(dāng)整合服務(wù) 器102達(dá)到重試的最大次數(shù)并且觸發(fā)器仍然失敗(由于異常)時可產(chǎn)生重試失敗。如圖6所示，為整合服務(wù)器訂閱發(fā)往默認(rèn)客戶的文檔的路徑的示意圖。發(fā)布服務(wù) 可通過指定文檔的目的地來分發(fā)文檔。例如，發(fā)布服務(wù)可指定取回文檔的中間件客戶。當(dāng) 中間件接收到分發(fā)的文檔時，其僅將該文檔的副本置于指定的客戶的隊(duì)列中。通常，文檔分 發(fā)至默認(rèn)客戶。默認(rèn)客戶是當(dāng)整合服務(wù)器第一次配置其與中間件的連接時由中間件客戶為 該整合服務(wù)器產(chǎn)生的。需要說明的是，如果發(fā)布服務(wù)指定了單獨(dú)的觸發(fā)器作為文檔的目的 地(例如，發(fā)布服務(wù)指定了觸發(fā)器客戶ID作為目的地ID)，文檔的訂閱路徑與發(fā)布文檔的路 徑一樣。整合服務(wù)器102中的分配器請求來自中間件106上的默認(rèn)客戶隊(duì)列中的文檔 (S601)。需要說明的是，默認(rèn)客戶可能是為整合服務(wù)器102產(chǎn)生的中間件客戶。僅當(dāng)發(fā)布 者向整合服務(wù)器的客戶ID分發(fā)文檔時，中間件106才將文檔置于默認(rèn)客戶的中間件隊(duì)列 602中。線程以批量的方式取回分發(fā)至默認(rèn)客戶的文檔(S602)。線程一次取回的文檔數(shù)目 由，舉例來說，默認(rèn)的文檔存儲的重填水平和容量、以及中間件106上的默認(rèn)客戶的可用文 檔數(shù)目決定。分配器204將文檔的副本(例如，存儲于內(nèi)存中)置于默認(rèn)文檔存儲604中 (S603)。分配器204確定訂閱文檔的訂閱者，并將文檔副本路由至每一個訂閱者的觸發(fā)器 隊(duì)列214a b(S604)。在分發(fā)文檔的情況中，整合服務(wù)器102將文檔存儲在觸發(fā)器隊(duì)列214 中。觸發(fā)器隊(duì)列214位于存儲在磁盤上的觸發(fā)器文檔存儲502中。整合服務(wù)器102將文檔的副本從默認(rèn)文檔存儲604中移除并，如果文檔是有保證的，向中間件106返回確認(rèn)信息 (S605)。中間件106將文檔從默認(rèn)客戶隊(duì)列602中移除。分配器204從服務(wù)線程池中獲取線程，從觸發(fā)器隊(duì)列214a中拉取文檔，并評估在 觸發(fā)器中的文檔的條件(S504)。如果為觸發(fā)器配置了僅發(fā)生一次(exactly-once)的處理 流程，則整合服務(wù)器102可先確定文檔是否是已經(jīng)被觸發(fā)器處理過的文檔的副本。在這種 情況下，僅當(dāng)文檔是新文檔時，整合服務(wù)器102才會連續(xù)處理文檔。如果文檔符合觸發(fā)器條件，分配器204執(zhí)行與該條件有關(guān)的觸發(fā)器服務(wù)502a、 504b (S607)。如果文檔不符合觸發(fā)器條件，整合服務(wù)器102向觸發(fā)器隊(duì)列214a b發(fā)送確 認(rèn)信息，丟棄文檔(例如，從觸發(fā)器隊(duì)列214a b中移除該文檔)，并將服務(wù)線程返回至服 務(wù)線程池。整合服務(wù)器102也可產(chǎn)生日志記錄消息記錄該文檔沒有與條件匹配。觸發(fā)器服務(wù)執(zhí)行至結(jié)束(如，成功或錯誤)(S608)。如果觸發(fā)器服務(wù)502a、504b成 功的執(zhí)行了，整合服務(wù)器102向觸發(fā)器隊(duì)列214a b返回確認(rèn)信息(例如，如果這是有保 證的文檔)，從觸發(fā)器隊(duì)列214a b中移除該文檔，并將服務(wù)線程返回至服務(wù)線程池。如果 產(chǎn)生服務(wù)異常，觸發(fā)器服務(wù)502a、504b以錯誤結(jié)束，整合服務(wù)器102拒收文檔，從觸發(fā)器隊(duì) 列214a b中移除該文檔，將服務(wù)線程返回至服務(wù)線程池，并發(fā)送錯誤文檔以指示產(chǎn)生了 錯誤。如果文檔是有保證的，整合服務(wù)器102向觸發(fā)器隊(duì)列214a b返回確認(rèn)信息。觸發(fā) 器隊(duì)列214a b從存儲中移除該文檔副本。如果在觸發(fā)器服務(wù)執(zhí)行期間產(chǎn)生了傳輸錯誤， 服務(wù)獲取該錯誤，將其覆蓋(wraps)并重新作為異常丟棄，然后，整合服務(wù)器102等待重試 間隔時長(該重試間隔可以被預(yù)先定義和/或由用戶定義)并使用原始文檔作為輸入重新 執(zhí)行該服務(wù)。如果整合服務(wù)器102達(dá)到最大重試次數(shù)(也可以被預(yù)先定義和/或由用戶定 義)，并且觸發(fā)器服務(wù)由于傳輸錯誤仍然失敗了，整合服務(wù)器102將最后一次失敗作為服務(wù) 錯誤處理。整合服務(wù)器102可將分發(fā)文檔存儲在位于磁盤上的觸發(fā)器文檔存儲502中。整合 服務(wù)器102可將發(fā)布文檔存儲在位于內(nèi)存中的觸發(fā)器文檔存儲502中。如果在處理存儲在 磁盤上的觸發(fā)器文檔中的有保證的文檔之前整合服務(wù)器102關(guān)閉了，整合服務(wù)器可以在重 啟后從觸發(fā)器文檔存儲502中重新獲取文檔。易失的文檔可存儲在內(nèi)存中，在重啟后不可 恢復(fù)。如果服務(wù)產(chǎn)生了基于錯誤的審核數(shù)據(jù)，并包括審核記錄中的輸入流水線的備份 (副本)，監(jiān)測器可用來在稍后的時間重新調(diào)用觸發(fā)器服務(wù)。如前所述，文檔可能滿足一個 以上的觸發(fā)器中的條件。然而，整合服務(wù)器102可能僅執(zhí)行與第一被滿足的條件相關(guān)的服務(wù)。觸發(fā)器的處理模式?jīng)Q定了整合服務(wù)器102以連續(xù)的還是以同時的方式處理觸發(fā) 器隊(duì)列中的文檔。在連續(xù)處理中，整合服務(wù)器102按照文檔在觸發(fā)隊(duì)列中的次序一次處理 一個文檔。在同時處理中，整合服務(wù)器102—次處理其可處理的多個文檔，但是不一定按照 文檔在隊(duì)列中的順序處理。如果在文檔取回或存儲中發(fā)生傳輸錯誤，審核子系統(tǒng)可記錄該文檔并標(biāo)記其狀態(tài) 為“失敗”?？墒褂帽O(jiān)測器來發(fā)現(xiàn)和重發(fā)狀態(tài)為“失敗”的文檔。并且，觸發(fā)器可被配置為如 果發(fā)生重試失敗則暫停(suspend)或在稍后的時間里重試。當(dāng)整合服務(wù)器102達(dá)到重試的 最大次數(shù)并且觸發(fā)器仍然失敗(由于異常)時可產(chǎn)生重試失敗。
如圖7所示，為本地發(fā)布文檔的發(fā)布和訂閱路徑的示意圖。本地發(fā)布涉及在整合 服務(wù)器102內(nèi)發(fā)布文檔的處理過程。在這種情況中，只有位于同一整合服務(wù)器上的訂閱者 可以接收和處理文檔。在本地發(fā)布中，文檔保留在整合服務(wù)器內(nèi)。中間件不參與該過程。當(dāng) 發(fā)布文檔的服務(wù)中指示文檔應(yīng)當(dāng)在本地發(fā)布，或當(dāng)整合服務(wù)器沒有被配置為與中間件連接 時，會產(chǎn)生本地發(fā)布。整合服務(wù)器102中的發(fā)布服務(wù)202向分配器204發(fā)送文檔(S701)。在整合服務(wù)器 102向分配器204發(fā)送文檔之前，其可驗(yàn)證文檔的可發(fā)布文檔類型。如果文檔是無效的，服 務(wù)可返回代表無效錯誤的異常信息。分配器204或者確定哪一個觸發(fā)器訂閱文檔并在每一 個訂閱者的觸發(fā)器隊(duì)列214中放置文檔的副本，或者在觸發(fā)器文檔存儲502 (例如，位于磁 盤上)中保存本地發(fā)布的文檔，如果文檔沒有訂閱者則丟棄文檔(S702)。分配器204從服務(wù)線程池中獲得線程，從觸發(fā)器隊(duì)列214中拉取文檔，并評估在觸 發(fā)器中的文檔的條件(S703)。如果為觸發(fā)器配置了僅發(fā)生一次(exactly-once)的處理流 程，則整合服務(wù)器102可先確定文檔是否是已經(jīng)被觸發(fā)器處理過的文檔的副本。在這種情 況下，僅當(dāng)文檔是新的時候，整合服務(wù)器102才會連續(xù)處理文檔。如果文檔符合觸發(fā)器條 件，分配器204執(zhí)行與該條件有關(guān)的觸發(fā)器服務(wù)502/504/506 (S704)。如果文檔不符合觸發(fā) 器條件，整合服務(wù)器102向觸發(fā)器隊(duì)列214發(fā)送確認(rèn)信息，丟棄文檔(例如，從觸發(fā)器隊(duì)列 214中移除該文檔)，并將服務(wù)線程返回至服務(wù)線程池。觸發(fā)器服務(wù)執(zhí)行至結(jié)束(如，成功或錯誤)(S705)。如果觸發(fā)器服務(wù)502/504/506 成功的執(zhí)行了，整合服務(wù)器102向觸發(fā)器隊(duì)列214返回確認(rèn)信息(例如，如果這是有保證的 文檔)，從觸發(fā)器隊(duì)列214中移除該文檔，并將服務(wù)線程返回至服務(wù)線程池。如果產(chǎn)生服務(wù) 異常，觸發(fā)器服務(wù)502/504/506以錯誤結(jié)束，整合服務(wù)器102拒收文檔，從觸發(fā)器隊(duì)列214 中移除該文檔，并將服務(wù)線程返回至服務(wù)線程池。如果文檔是有保證的，整合服務(wù)器102向 觸發(fā)器隊(duì)列214返回確認(rèn)信息。如果在觸發(fā)器服務(wù)執(zhí)行期間產(chǎn)生了傳輸錯誤，服務(wù)獲取該 錯誤，將其覆蓋(wraps)并重新作為異常丟棄，然后，整合服務(wù)器102等待重試間隔時長并 使用原始文檔作為輸入重新執(zhí)行該服務(wù)。如果整合服務(wù)器102達(dá)到最大重試次數(shù)，并且觸 發(fā)器服務(wù)502/504/506由于傳輸錯誤仍然失敗了，整合服務(wù)器102將最后一次失敗作為服 務(wù)錯誤處理?？梢詫砂l(fā)布的文檔類型和整合服務(wù)器102進(jìn)行配置，以使得當(dāng)文檔被發(fā)布時整 合服務(wù)器102不對其進(jìn)行驗(yàn)證。整合服務(wù)器102可將本地發(fā)布的文檔存儲在位于磁盤的觸 發(fā)器文檔存儲502中。如果在處理存儲在磁盤上的觸發(fā)器文檔中的有保證的文檔之前整合 服務(wù)器102關(guān)閉了，整合服務(wù)器可以在重啟后從觸發(fā)器文檔存儲502中重新獲取文檔。，在 重啟后整合服務(wù)器102不會恢復(fù)易失的文檔。如果服務(wù)產(chǎn)生了基于錯誤的審核數(shù)據(jù)，并包 括審核記錄中的輸入流水線的備份(副本)，監(jiān)測器可用來在稍后的時間重新調(diào)用觸發(fā)器 服務(wù)。文檔可能滿足一個以上的觸發(fā)器中的條件。然而，整合服務(wù)器102可能僅執(zhí)行與 第一被滿足的條件相關(guān)的服務(wù)。觸發(fā)器的處理模式?jīng)Q定了整合服務(wù)器102以連續(xù)的還是以 同時的方式處理觸發(fā)器隊(duì)列中的文檔。在連續(xù)處理中，整合服務(wù)器102按照文檔在觸發(fā)隊(duì) 列中的次序一次處理一個文檔。在同時處理中，整合服務(wù)器102 —次處理其可處理的多個 文檔，但是不一定按照文檔在隊(duì)列中順序處理。觸發(fā)器可被配置為如果發(fā)生重試失敗則暫
16停(suspend)或在稍后的時間里重試。當(dāng)整合服務(wù)器102達(dá)到重試的最大次數(shù)并且觸發(fā)器 仍然失敗(由于異常)時可產(chǎn)生重試失敗。以上是對發(fā)布-訂閱方案的總體步驟的描述。簡而言之，在發(fā)布側(cè)，用戶為將要被 發(fā)布的文檔產(chǎn)生可發(fā)布的文檔類型，并產(chǎn)生處理來自發(fā)布側(cè)發(fā)布的文檔的服務(wù)。在訂閱側(cè)， 用戶產(chǎn)生發(fā)布文檔的服務(wù)和觸發(fā)，該觸發(fā)將輸入文檔與處理文檔的服務(wù)關(guān)聯(lián)起來。具體來說，建立整合解決方案的第一步在于定義問題并確定如何采用發(fā)布-訂閱 模型解決問題。當(dāng)設(shè)計(jì)該解決方案時，確定需要被發(fā)布/訂閱的文檔將會是有益的一步。該 信息在產(chǎn)生可發(fā)布的文檔類型時是有用的。相似的，確定文檔應(yīng)當(dāng)如何被發(fā)布也是有用的 一步。該信息在產(chǎn)生發(fā)布文檔的服務(wù)時是有用的。最后，確定如何處理文檔也是有用的一 步。該信息在產(chǎn)生處理文檔的服務(wù)時是有用的。在第二步中，確定產(chǎn)品的配置。在一些情況中，需要開發(fā)環(huán)境(development environment)來鏡像產(chǎn)品環(huán)境。需要考慮的因素包括是否所有的文檔的發(fā)布和訂閱都在單 一的整合服務(wù)器上進(jìn)行，或是否使用多個整合服務(wù)器；如果使用了多個整合服務(wù)器，是否需 要配置群；以及，在產(chǎn)品環(huán)境中是否使用中間件。在第三步中，產(chǎn)生可發(fā)布的文檔類型。這 是，在確定將要被發(fā)布的文檔后，在發(fā)布側(cè)，產(chǎn)生可發(fā)布的文檔類型。在第四步中，使可發(fā)布的文檔類型可用。產(chǎn)生處理文檔的服務(wù)和訂閱文檔的觸發(fā)， 訂閱側(cè)通常需要定義了將要被發(fā)布的文檔的可發(fā)布的文檔類型。當(dāng)開發(fā)環(huán)境是單個的整合 服務(wù)器時，發(fā)布側(cè)和訂閱側(cè)都處于單個的整合服務(wù)器上。這樣，總的來說，不需要進(jìn)行使可 發(fā)布的文檔類型對其他開發(fā)者而言可用的動作。在用于發(fā)布側(cè)的可發(fā)布文檔類型產(chǎn)生后， 可發(fā)布的文檔類型馬上可用于訂閱側(cè)的使用。然而，當(dāng)開發(fā)環(huán)境包括多個整合服務(wù)器及與 其一起的中間件時，發(fā)布側(cè)和訂閱側(cè)分別處于與中間件連接的單獨(dú)的整合服務(wù)器上。這樣， 當(dāng)產(chǎn)生了可發(fā)布的文檔類型，中間件上自動產(chǎn)生相應(yīng)的中間件文檔類型。使可發(fā)布的文檔 類型對其他開發(fā)者也是可用的。這可以通過從中間件文檔類型產(chǎn)生可發(fā)布的文檔類型來實(shí) 現(xiàn)。這也可以通過使用封裝副本(package replication)向與其他整合服務(wù)器共同工作的 開發(fā)者分發(fā)可發(fā)布的文檔類型來實(shí)現(xiàn)。在這種情況下，當(dāng)其他開發(fā)者收到封裝時，他們可以 安裝該封裝，然后通過從中間件拉取他們同步文檔類型。在第五步中，在發(fā)布側(cè)，產(chǎn)生將文檔發(fā)布至中間件或是在相同的本地整合服務(wù)器 的服務(wù)。在第六步中，在訂閱側(cè)，產(chǎn)生將處理入局文檔的服務(wù)。當(dāng)產(chǎn)生處理文檔的服務(wù)時， 在對發(fā)布文檔的可發(fā)布文檔類型的輸入標(biāo)志中可包括文檔目錄。通過這種途徑，在可發(fā)布 文檔類型中定義的域可用于索引文檔中的數(shù)據(jù)。在第七步中，定義了觸發(fā)(器)。在訂閱側(cè)，產(chǎn)生觸發(fā)，以將一個或多個可發(fā)布的文 檔類型與處理發(fā)布文檔的服務(wù)聯(lián)系起來。為將可發(fā)布的文檔類型與服務(wù)聯(lián)系起來，可在觸 發(fā)器中產(chǎn)生條件以定義訂閱的可發(fā)布的文檔類型和當(dāng)該類型的文檔到達(dá)時調(diào)用的服務(wù)。通 過增加定義發(fā)布文檔的內(nèi)容的標(biāo)準(zhǔn)的過濾器可以進(jìn)一步的精簡該條件。當(dāng)觸發(fā)被保存時， 整合服務(wù)器使用觸發(fā)中的條件來定義對可發(fā)布的文檔類型的訂閱。觸發(fā)器設(shè)計(jì)的進(jìn)一步細(xì) 節(jié)和配置在后續(xù)部分進(jìn)行描述。在第八步中，同步可發(fā)布的文檔類型。當(dāng)在整合解決方案中包括中間件時，每一個 可發(fā)布的文檔類型具有在中間件上的相應(yīng)的中間件文檔類型。如圖8所示，為發(fā)布_訂閱模 型解決方案的兩側(cè)，其中，可發(fā)布的文檔類型與相同的中間件文檔類型相聯(lián)系。在發(fā)布-訂閱解決方案中，發(fā)布側(cè)和訂閱側(cè)都使用相同可發(fā)布的文檔類型802。當(dāng)向中間件106發(fā)布文 檔804時，發(fā)布側(cè)使用可發(fā)布的文檔類型802來定義被發(fā)布的文檔的類型。訂閱側(cè)引用在 觸發(fā)器808中的可發(fā)布的文檔類型來指示訂閱的文檔的類型。為使整合解決方案正確的運(yùn) 行，在發(fā)布側(cè)和訂閱側(cè)的可發(fā)布的文檔類型802應(yīng)當(dāng)引用相同的中間件文檔類型806。以下描述在開發(fā)環(huán)境中如何使可發(fā)布的文檔類型與相同的中間件文檔類型相符 合。在開發(fā)環(huán)境中涉及一個整合服務(wù)器時，當(dāng)整合解決方案涉及產(chǎn)品時，發(fā)布側(cè)和訂閱側(cè)可 以在與中間件連接的不同整合服務(wù)器上。這樣，有必要同步的產(chǎn)生與可發(fā)布的文檔類型有 關(guān)的中間件文檔類型。相應(yīng)的，在發(fā)布側(cè)，在同步時，將可發(fā)布的文檔類型推送至中間件以 在中間件上產(chǎn)生中間件文檔類型?？墒褂梅庋b副本來產(chǎn)生和分發(fā)包括可發(fā)布的文檔類型的 封裝。在訂閱側(cè)，安裝包括發(fā)布者產(chǎn)生的可發(fā)布的文檔類型的封裝。在同步時，從中間件拉 取文檔類型以更新可發(fā)布的文檔類型。當(dāng)開發(fā)環(huán)境涉及與中間件一起的多個整合服務(wù)器時，由于開發(fā)中使用了中間件， 所以在發(fā)布側(cè)和訂閱側(cè)中的可發(fā)布的文檔類型可能已經(jīng)與相同的中間件文檔類型相符合 了。盡管如此，可使用所有文檔類型的簡單同步來保證可發(fā)布的文檔類型與中間件文檔類 型同步。以下將描述與觸發(fā)器有關(guān)的具體細(xì)節(jié)。觸發(fā)器建立對可發(fā)布文檔類型的訂閱，并 明確如何處理這些可發(fā)布的文檔類型的實(shí)例。當(dāng)觸發(fā)器建立時，會產(chǎn)生一個或多個條件。條 件將一個或多個可發(fā)布的文檔類型與單個服務(wù)聯(lián)系起來?？砂l(fā)布的文檔類型作為觸發(fā)器的 訂閱片塊(subscription piece) 0服務(wù)器處理片塊。當(dāng)觸發(fā)器接收器訂閱的文檔時，整合 服務(wù)器通過調(diào)用在條件中定義的服務(wù)來處理文檔。建立觸發(fā)器的過程與以下基本階段有關(guān)。產(chǎn)生位于整合服務(wù)器上的新觸發(fā)器。在 該階段，在整合服務(wù)器上產(chǎn)生了新的觸發(fā)器，在該整合服務(wù)器上將進(jìn)行開發(fā)和測試。為觸發(fā) 器產(chǎn)生一個或多個條件。在該階段，可發(fā)布的文檔類型與服務(wù)關(guān)聯(lián)，產(chǎn)生施加于入局文檔的 過濾器，選擇聯(lián)合的類型(join types)。設(shè)置觸發(fā)器特性。在該階段，設(shè)置配置該觸發(fā)器的 運(yùn)行階段環(huán)境的參數(shù)，例如，觸發(fā)器隊(duì)列容量、文檔處理模式、觸發(fā)器服務(wù)重試限制、以及僅 進(jìn)行一次的處理。在觸發(fā)器上可進(jìn)行測試和調(diào)試。處理觸發(fā)器接收文檔的服務(wù)被稱為觸發(fā)器服務(wù)。通常，條件詳細(xì)定義了單獨(dú)的觸 發(fā)器服務(wù)。在使能觸發(fā)器之前，在相同的整合服務(wù)器上必須已經(jīng)存在觸發(fā)器服務(wù)。另外，觸 發(fā)器服務(wù)的輸入標(biāo)志需要包括對可發(fā)布的文檔類型的文檔目錄。該文檔目錄的名稱是可發(fā) 布的文檔類型的完全合格的名稱?？砂l(fā)布的文檔類型的完全合格的名稱需要符合一系列的 格式，t匕如為，folder, subfolder :PublishabelDocumentTypeName。當(dāng)保存了觸發(fā)器，整合服務(wù)器可以評估該觸發(fā)器，并詳細(xì)定義觸發(fā)器中的條件，以 保證觸發(fā)器是有效地。如果整合服務(wù)器確定觸發(fā)器或觸發(fā)器中的條件無效，則會向用戶顯 示錯誤信息，并使觸發(fā)器無效。在具體的實(shí)施例中，當(dāng)如下條件中的每一個都是真實(shí)的時 候，觸發(fā)器可被當(dāng)作是有效地觸發(fā)器包括至少一個條件；觸發(fā)器中的每一個條件指定了 獨(dú)一無二的名稱；觸發(fā)器中每一個條件指定了服務(wù)；觸發(fā)器中的每一個條件指定了一個或 多個可發(fā)布的文檔類型；如果觸發(fā)器中的多個條件指定了相同的可發(fā)布的文檔類型，在每 一個條件中作用于可發(fā)布的文檔類型的過濾器都是相同的；作用于可發(fā)布的文檔類型的過 濾器的語法是正確的；并且，觸發(fā)器包括不超過一個的聯(lián)合條件。
總的來說，觸發(fā)器可以僅訂閱可發(fā)布的文檔類型。多個觸發(fā)器(以及在觸發(fā)器中 的多個條件)可以引用相同的可發(fā)布的文檔類型。在運(yùn)行階段，對于每一個觸發(fā)器，整合服 務(wù)器調(diào)用為第一條件指定的服務(wù)，該第一條件與可發(fā)布的文檔類型標(biāo)準(zhǔn)相符合。如圖9所示，為提供了在前述系統(tǒng)中、之間的通訊的當(dāng)前消息層900的組成示意 圖。消息層900的特定方面(aspects)可位于整合服務(wù)器(或整合服務(wù)器的實(shí)例)與中 間件上，作為單獨(dú)的執(zhí)行體，并且/或者其可以出現(xiàn)在任何提供者上，在本發(fā)明的具體實(shí)施 例中。在消息層900中，提供應(yīng)用服務(wù)902作為客戶執(zhí)行體。消息提供者(例如，專有物 (proprietary)或JMS模式中的中間件功能，另一個JMS提供者)可選擇的從接近(access) 提供者的客戶中區(qū)別。在這種情況下，客戶可以是整合服務(wù)器或客戶程序或應(yīng)用，例如，嵌 入到提供者的客戶圖書館中。這樣的客戶圖書館可包括消息API層(例如，API中間件和/ 或JMS API)中的JAR文件。在本發(fā)明的具體實(shí)施例中，消息層(例如，JMS適配器和觸發(fā) 器層，通過應(yīng)用編碼)中的高層可位于整合服務(wù)器上。觸發(fā)器層904使能上述的中間件觸發(fā)器服務(wù)，其與如前所述的整合服務(wù)器中間件 觸發(fā)器子系統(tǒng)和設(shè)備906相互作用。這些層使能到達(dá)專有物(例如，中間件)消息API層 908的通路。通過JAR文件可以分發(fā)或/和執(zhí)行中間件API。這樣，消息層900的右側(cè)通過 專有物消息層提供與整合服務(wù)器或整合服務(wù)器實(shí)例910進(jìn)行交互的豐富的特性，以提供應(yīng) 用整合解決方案。如前所記錄的，基于開放的、標(biāo)準(zhǔn)的消息協(xié)議提供互操作性和/或通訊，通過適配 器的應(yīng)用可使能合適的消息協(xié)議(例如，JMS消息)。這樣，在消息層900的左側(cè)，提供了 JMS適配器層912用于與JMS API層914進(jìn)行接口，通過使用JDK提供的標(biāo)準(zhǔn)JMS接口可使 上述使能。這樣，消息層900的左邊提供了互操作性和/或開放的消息特征，其可通過JMS 相關(guān)層與整合服務(wù)器實(shí)例910交互，以提供應(yīng)用整合的解決方案。從圖9中可以了解，當(dāng)前的消息層900并不包括觸發(fā)器子系統(tǒng)，為消息協(xié)議的左 邊。這樣，建立于JMS適配器上的應(yīng)用就缺少中間件觸發(fā)子系統(tǒng)的擴(kuò)展性能。這樣，采用當(dāng) 前的消息層900，使用者必須在互操作性和標(biāo)準(zhǔn)消息之間進(jìn)行抉擇，并且處理在一邊，更重 要的是，專有物消息和處理在另一邊。在本發(fā)明的具體實(shí)施例中，解決該問題的方案涉及將完全嵌入JMS作為整合服務(wù) 器觸發(fā)器子系統(tǒng)中的專有物消息協(xié)議中的等同物，這樣所有或潛在的所有已存在的功能都 可由JMS實(shí)現(xiàn)。相應(yīng)的，如圖10所示，為本發(fā)明實(shí)施例中的相應(yīng)的消息層1000的組成示意圖。與 圖9中的消息層900相比，本發(fā)明實(shí)施例中的消息層1000可位于整合服務(wù)器(或整合服務(wù) 器的實(shí)例，如圖9所示)和中間件上，作為單獨(dú)的執(zhí)行體(在圖10中未示這種情況)。其可 以出現(xiàn)在任何提供者上，如，支持JMS消息的提供者上。不管怎樣，通過使用本發(fā)明實(shí)施例 中的消息層1000，可以在沒有使用供于整合服務(wù)器的特定的適配器就可以使能JMS消息。 進(jìn)一步的，在本發(fā)明的具體實(shí)施例中，這樣的消息層1000可以使避免對JMS觸發(fā)器本身進(jìn) 行任何改變成為可能(例如，使常規(guī)格式下的標(biāo)準(zhǔn)JMS消息的使用成為可能)，和/或可降 低對客戶程序的需求和/或在應(yīng)用服務(wù)水平層面的執(zhí)行，在本發(fā)明的具體實(shí)施例中。如圖10所示，消息層1000的左側(cè)基本上是右側(cè)的鏡像。特別的，提供JMS觸發(fā)器 層1004作為中間件觸發(fā)器層904的對應(yīng)物，JMS子系統(tǒng)1006 (用于產(chǎn)生JMS適配器912)
19作為中間件觸發(fā)器子系統(tǒng)906的對應(yīng)物。同時還提供了相同的JMS消息API層914和專有 物中間件消息 API 層(proprietary broker messaging API layer) 908 在消息協(xié)議 1000 中包括提供了通用觸發(fā)器功能的觸發(fā)器子系統(tǒng)1002。提供觸發(fā)器子系統(tǒng)1002作為在單獨(dú) 觸發(fā)器子系統(tǒng)之上的增值(value-added)層，因而使能平行子系統(tǒng)的功能。在本發(fā)明的具體實(shí)施例中，通過采用如下的具體措施使能觸發(fā)器子系統(tǒng)1002。第 一，擴(kuò)展整合服務(wù)器觸發(fā)器的名稱空間實(shí)體，并將其調(diào)整為包括特性，并特別按照J(rèn)MS消息 設(shè)置。觸發(fā)器的名稱空間是已命名的對象，其使得配置時可以考慮等待消息需要多長時間 以及當(dāng)收到消息時如何處理這些消息。其可以，如，作為文件夾的已命名的層次結(jié)構(gòu)進(jìn)行組 織。舉例來說，下述的結(jié)構(gòu)表征了作為業(yè)務(wù)應(yīng)用應(yīng)當(dāng)如何處理訂單文檔(當(dāng)文檔被接收時) 的指令bussapp. processpo :handlineincomingprocessingorder0 名禾爾空間可以組織為 樹狀，可以在其節(jié)點(diǎn)進(jìn)行配置。第二，可擴(kuò)展和調(diào)整整合服務(wù)器觸發(fā)器管理(administration)功能以使其包括 可選擇的特定的JMS(例如，交替的限流方案)。在調(diào)整進(jìn)入系統(tǒng)的消息上這種管理功能是 有用的(例如，在降低系統(tǒng)溢出的產(chǎn)生上)。管理可以在全局進(jìn)行或/和在觸發(fā)器層進(jìn)行。 對功能的舉例包括調(diào)節(jié)/延遲觸發(fā)器接受和/或處理。第三，可為JMS擴(kuò)展和調(diào)整整合服務(wù)器觸發(fā)器群模型。需要說明的是，該群，例如， 在負(fù)載平衡中提供的，可以提供可伸縮性(scalability)和耐久性(survivability)的增 長。在本發(fā)明的具體實(shí)施例中，可在一個或多個整合服務(wù)器上使用相同的觸發(fā)器。第四，可為JMS擴(kuò)展和調(diào)整整合服務(wù)器觸發(fā)器聯(lián)合機(jī)制。在聯(lián)合操作中，如果處理 流程一次調(diào)用所有文檔的處理，觸發(fā)器會等待多個文檔。第五，可為JMS擴(kuò)展和調(diào)整整合服 務(wù)器觸發(fā)器次序的服務(wù)執(zhí)行機(jī)制。如果涉及多個文檔，次序的服務(wù)執(zhí)行保證了依次序的處 理。第六，可為JMS消息提供整合的交易操作(transaction handling)的執(zhí)行。交易操作 涉及將處理隊(duì)列與交易綁定。然后，可調(diào)配處理隊(duì)列以供整個交易的使用，或如果交易中的 操作失敗，則中止(roll back)改變。在本發(fā)明的具體實(shí)施例中，當(dāng)將中間件作為JMS提供者自身使用時，可以為實(shí) 例提供特定的客戶擴(kuò)展。例如，可以使能單獨(dú)步驟(如，JNDI)的配置，多服務(wù)失效備援 (failover)(例如，共享的客戶模式)，和/或流型的大消息處理。實(shí)際上，本發(fā)明實(shí)施例中 的配置功能簡化了現(xiàn)有技術(shù)中的對客戶程序和執(zhí)行的需求。本發(fā)明的具體實(shí)施例編程提供 了基于菜單的配置工具以替代具體的編程過程。消息處理標(biāo)準(zhǔn)流涉及預(yù)處理、處理、以及后處理。預(yù)處理涉及消息的取得和估值， 這包括，例如，群支持、副本檢測、交易初始化、以及類似功能。處理涉及服務(wù)調(diào)度，這可包 括，例如，本地過濾器處理、應(yīng)用的并發(fā)、聯(lián)結(jié)和次序的服務(wù)執(zhí)行評估、以及類似功能。后處 理涉及消息確認(rèn)，其包括，例如，錯誤和重試操作、交易完成、及其類似。這些配置技術(shù)提供特定的例證性的優(yōu)點(diǎn)。例如，由于在整個觸發(fā)器中消息操作和 處理是地址化(addressed)的，所以整合服務(wù)器中建立的功能可以被改變(leveraged)。由 于在本發(fā)明的具體實(shí)施例中的觸發(fā)器結(jié)構(gòu)是獨(dú)一無二的，所以基于JMS的發(fā)送機(jī)制也是如 此。更進(jìn)一步的，通過合適的協(xié)議傳統(tǒng)的中間件雖然提供豐富的特性集合但降低了互操作 性，而JMS消息提供互操作性但減少了特性，本發(fā)明的具體實(shí)施例既提供在標(biāo)準(zhǔn)消息協(xié)議 的基礎(chǔ)上的互操作性同時還提供了豐富的特性集合。這樣，提供消息層的擴(kuò)展以降低(而且有時是消除)對，消息層、適配器、和/或使用這種客戶消息層和/或適配器的應(yīng)用，的 客戶開發(fā)的需要。如此，可以避免重復(fù)的重新編碼(該重新編碼通常是以非標(biāo)準(zhǔn)的方式完 成)，同時，在基于配置的方式中還可提供相同或更好的功能。S卩，大致的優(yōu)點(diǎn)包括豐富的增強(qiáng)的完全的可互操作的基于標(biāo)準(zhǔn)的(如，基于JMS) 的消息處理，替代或在專有物中間件以外可使用交替的(例如，JMS)消息提供者的能力，與 一個以上消息提供者同時連接的能力(如，一個中間件和/或任意個的JMS提供者)。觸發(fā) 器子系統(tǒng)所提供的特定的優(yōu)點(diǎn)可包括，在本發(fā)明實(shí)施例中公布的收聽者的配置(為一個或 多個JMS目的地)(例如，隊(duì)列或主題)，用于服務(wù)負(fù)載控制的配置的并發(fā)性(例如，可用于 每一觸發(fā)器(per-trigger)和/或全局的線程)，全局和每一觸發(fā)器運(yùn)行階段管理(例如， 控制、暫停和重新開始、容量管理等)，一次和僅一次的處理(例如，有保證的處理、副本檢 測、錯誤重試等)，自動傳輸錯誤操作和恢復(fù)(例如，為暫時的不可用的后端應(yīng)用)，消息處 理的群支持(例如，提供可測量性、可用性和失效備援特性)，對大文檔的基于流的消息處 理(例如，降低內(nèi)存溢出)，基于聯(lián)合(其在業(yè)務(wù)處理模型的執(zhí)行中有用)的條件消息處理， 次序的消息序列的次序服務(wù)執(zhí)行，整合的本地和XA交易支持，消息的客戶側(cè)隊(duì)列(例如，以 支持JMS提供者的不可用性)，本地過濾器(例如，超過限制的JMS選擇器容量)，等等。雖然上述的本發(fā)明實(shí)施例中中間件具有優(yōu)點(diǎn)，但是還可以對其進(jìn)行進(jìn)一步的改 進(jìn)。例如，應(yīng)該理解到，可以對中間件進(jìn)行改進(jìn)，以提供擴(kuò)展的負(fù)載平衡特性。實(shí)際上，當(dāng)前 應(yīng)用的發(fā)明人已經(jīng)注意到，在過去的幾年里，客戶需要為其中間件應(yīng)用獲得失效備援和負(fù) 載平衡特性。相應(yīng)的，本發(fā)明實(shí)施例中的中間件執(zhí)行客戶側(cè)失效備援和負(fù)載平衡功能。本 發(fā)明實(shí)施例中的負(fù)載平衡功能可在應(yīng)用空間范圍內(nèi)也可以擴(kuò)展。更具體的，上述的負(fù)載平衡特性可以作用于一組中間件(此處稱為中間件群)。發(fā) 布者和訂閱者可與中間件群連接，中間件群中的中間件可以共享從發(fā)布者到訂閱者的消息 路由。例如，在具體實(shí)施例中的發(fā)布者可選擇運(yùn)行在中間件群中的任意的中間件來發(fā)布消 息，訂閱者可以從該中間件接收相同的消息。在本發(fā)明的具體實(shí)施例中，負(fù)載平衡特性的執(zhí)行可作為上述的JMS中間件API的 擴(kuò)展。進(jìn)一步的，具體實(shí)施例有利于使得監(jiān)控和跟蹤負(fù)載平衡流通數(shù)據(jù)稱為可能，例如，通 過嵌入工具或數(shù)據(jù)庫。舉例來說，可使用JMS API記錄器來記錄消息。記錄的消息可能或 不能可見或可估測于監(jiān)控的目的。需要理解的是，可進(jìn)行其他的執(zhí)行實(shí)例，本發(fā)明的技術(shù)方 案不應(yīng)局限于本實(shí)施例或任何具體的實(shí)施例。具體實(shí)施例中的負(fù)載平衡功能可有益于允許使用者應(yīng)用來增加系統(tǒng)的吞吐量，例 如，在快速的發(fā)布者和慢速的訂閱者的情況中。在這樣的情況中，例如，發(fā)布者可與多個組 成群的中間件連接，基于發(fā)布策略(如，循環(huán)，等)發(fā)布文檔，并且所有的訂閱這可與群中的 所有中間件連接。多個訂閱者可共享消息處理負(fù)載，這可增強(qiáng)整個系統(tǒng)的表現(xiàn)。此外，如果 其中一個中間件停止(例如，變?yōu)椴豢捎谩⒊^容量、或其他情況的失效等)，其他的中間件 可接手該停止的中間件的消息分發(fā)。這樣，可見，本例中的執(zhí)行可基于中間件群提供客戶側(cè) 的失效備援功能。當(dāng)多發(fā)布者中存在相同的消息時，本例中的執(zhí)行可以幫助平衡發(fā)布者的 工作負(fù)載，并同時提供失效備援支持。在本發(fā)明的具體實(shí)施例中還提供了基于主題的消息 分發(fā)，和在中間件群內(nèi)的中間件流通負(fù)載。本發(fā)明具體實(shí)施例中的失效備援特性可以以有限至的方式處理活躍的/活躍的和活躍的/消極的失效備援情況。即是說，當(dāng)中間件的整個群依據(jù)循環(huán)策略共享消息分發(fā) 時，例如，達(dá)到了活躍的/活躍的失效備援。當(dāng)中間件基于粘性算法(sticky algorithm) 分發(fā)消息時，例如，其中僅當(dāng)前一中間件停止時下一中間件才會接管消息分發(fā)，可執(zhí)行活躍 的/消極的失效備援。在本發(fā)明的具體實(shí)施例中，如果發(fā)生了失效備援，已經(jīng)處于失效中間 件上的文檔可以保留在特定的中間件隊(duì)列中，直到特定的中間件的功能恢復(fù)。具體實(shí)施例中的負(fù)載平衡特性可以與子類一起執(zhí)行，該子類是已經(jīng)存在的JMS連 接、會話(session)、和客戶類的擴(kuò)展。例如，當(dāng)應(yīng)用產(chǎn)生與群連接工廠連接的JMS時，可生 成群連接實(shí)體(實(shí)例)。該連接發(fā)起與組成群的中間件的多個物理連接。當(dāng)群連接上產(chǎn)生 會話時，可將基于該物理連接填入多個群會話。JMS連接執(zhí)行可將一個插孔(socket)與一 個中間件連接，多個與不同中間件連接的物理連接將群連接功能合并為通用的連接，等。如圖11所示，為本發(fā)明實(shí)施例中的與中間件群的產(chǎn)生有關(guān)的各種元素的示意圖。 為了使用具體實(shí)施例中的負(fù)載平衡特性，可產(chǎn)生包括多個中間件106的中間件群1102。如 圖11所示，中間件群1102被置于發(fā)布/請求客戶端(如，圖中的左側(cè))與訂閱/響應(yīng)客戶 端(如，圖中的右側(cè))之間。兩個客戶端都包括整合服務(wù)器102 (或，其實(shí)體/實(shí)例)，還包 括與JMSAPI的接口 914?？缮蛇B接工廠(connection factory)，該連接工廠包括組成群 的中間件的子集和相應(yīng)的群策略。用戶接口工具1104(例如，由webMethods/Software AG 提供的myWebMethods Server或MWS)使得用戶可先選擇群，然后選擇一個或多個中間件的 列表。MWS 1104可使得用戶可確定對于特定的負(fù)載平衡群應(yīng)當(dāng)采用哪一種負(fù)載平衡策略。 換句話說，用戶可定義包括多個中間件的中間件群，然后為已經(jīng)產(chǎn)生的群確定特定的負(fù)載 平衡策略。用戶接口可被圖解的或命令行的方式驅(qū)動。如圖11中所示，與NWS 1104配對提供的JNDI提供者1006可包括目的地和連接 工廠數(shù)據(jù)。當(dāng)產(chǎn)生JMS連接時，JMS API 914可可選擇的使能或使無效負(fù)載平衡，該負(fù)載平 衡基于中間件群定義的存在以及負(fù)載平衡策略。如果連接工廠中僅定義了一個中間件，例 如，所有的消息發(fā)布和接收可能都是普通的JMS消息。如果連接工廠與中間件群(如，多個 中間件)相關(guān)，并定義了負(fù)載平衡策略，例如，中間件可作為整體工作并根據(jù)負(fù)載平衡策略 分發(fā)消息。在發(fā)布操作中，可檢查中間件群標(biāo)志。如果設(shè)置了該標(biāo)志，則文件可能不會被發(fā)布 至群遠(yuǎn)端中間件(cluster remote broker)。在具體實(shí)施例中，具有許多不同的用于定義負(fù)載分發(fā)策略的算法。以下描述其中 的幾個策略。應(yīng)當(dāng)理解的是，這些策略的范圍從簡單的循環(huán)算法到更加復(fù)雜的算法，并且， 此處描述的具體實(shí)施例不應(yīng)被局限為任何具體的策略。 在循環(huán)(round robin)負(fù)載平衡策略中，群連接中的第一中間件處理第一發(fā)布操 作，第二中間件處理第二發(fā)布操作，并以此類推，直到所有的中間件都進(jìn)行了處理。該隊(duì)列 重復(fù)再重復(fù)。循環(huán)算法的一個好處在于，發(fā)布操作被平等的分布于群中的可用中間中，以一 個次序的方式。 在“粘性的”負(fù)載平衡策略中，客戶將會向第一中間件進(jìn)行發(fā)布直到該中間件失 效，該中間件失效后迫使客戶切換到下一中間件。 在隨機(jī)分配中，發(fā)布操作可指派給任何在群中中間件組上隨機(jī)抽取的服務(wù)。在這 種情況下，中間件中的一個可能被分配需處理很多消息，而其他的服務(wù)確是空閑的。然而，
22久而久之，總的來說可期望每一個中間件都取得相近的負(fù)載的分擔(dān)。
“文檔大小(document size) ”策略基于消息的大小路由該消息。可以測量對象 的大小，例如，通過將排列為比特(byte)流并檢查該流的長度。以下的代碼可用于檢測對 象的大小，例如
0152]Pulic static byte[] sizeof (object obj)throws java. io. IOException
0153]{
0154]ByteArrayOutputStream byteObject = new ByteArrayOutputStream{}；
0155]ObjectOutputStream objectOutputStream =
0156]new ObjectOutputStream(byteobject)；
0157]0bjectOutputStream. writeObject(obj)；
0158]0bjectOutputStream. flush ()；
0159]0b jectOutputStream. close ()；
0160]byteOb ject. close ()；
0161]return byteObject. toByteArray ()；
0162]}
0163] 應(yīng)當(dāng)理解的是，由于對每個消息進(jìn)行排列以測量其大小，這個過程可影響運(yùn)行階 段的表現(xiàn)?！び袡?quán)重的循環(huán)策略可適應(yīng)，例如，具有不同處理能力的中間件服務(wù)器。在有權(quán)重 的循環(huán)算法中，為每一個目的地(在本例中，為中間件服務(wù)器)分配表征，相應(yīng)于列表中的 其他中間件的，中間件服務(wù)器的表現(xiàn)的值。該“權(quán)重”確定了可向該特定的中間件服務(wù)器發(fā) 送多少更多(或更少)個消息，相比于列表中的其他服務(wù)器?？商峁┯脩艚涌趤泶_定群中 的每一個服務(wù)器的權(quán)重。例如，客戶可確定相關(guān)的賦給每一個中間件服務(wù)器實(shí)體的權(quán)重，如 果為負(fù)載平衡選擇了基于權(quán)重的策略的話。群中的每一個中間件服務(wù)器可，例如，接收一定比例的消息，該比例與消息的權(quán)重 有關(guān)％=((中間件服務(wù)器的權(quán)重)/(在群中的所有服務(wù)器的權(quán)重的和))*100。附加地或可替換地，消息向每一個中間件服務(wù)器的分發(fā)可以是實(shí)時權(quán)重的函數(shù) (與僅僅是一個平均值相反)。提供以下的示例以進(jìn)行說明例1 如果群中的所有中間件都具有相同的權(quán)重，那么他們將承擔(dān)同等比例的負(fù) 載。如果一個中間件服務(wù)器的權(quán)重為1而所有其他的中間件服務(wù)器的權(quán)重為2，則權(quán)重為1 的中間件服務(wù)器承擔(dān)的負(fù)載為其他任何服務(wù)器的一半。例2:假定，在有權(quán)重的循環(huán)環(huán)境的開發(fā)中，具有三個中間件被分別的衡量 (benchmarked)和配置。進(jìn)一步假定，第一個中間件可以處理100個消息/秒，第二個可以 處理300個消息/秒，而最后一個中間件可處理25個消息/秒。在這種情況下，可以為其 分配權(quán)重為中間件權(quán)重中間件1權(quán)重4中間件2權(quán)重12中間件3權(quán)重1采用該策略，當(dāng)發(fā)布每17個消息時，4個消息將被發(fā)送至中間件1，僅僅向中間件3發(fā)送一個消息。 “多發(fā)送(multi-send)”策略可支持兩種子選擇，稱為，“盡力而為(best effort)”和“有保證的(guaranteed)”。在盡力而為多發(fā)送子選擇中，JMS API可嘗試 將消息發(fā)布至所有或群中盡可能多個的中間件。即使只有一個中間件收到了該消息，也 可以認(rèn)為該發(fā)布/發(fā)送操作成功了。向群的中間件發(fā)布的消息實(shí)際上可以是非交易性的 (non-transactional)。相比之下，在有保證的多發(fā)送子選擇中，JMSAPI采用XA交易可向 M個中間件(即群中的中間件)中的N個發(fā)布消息(參見下述)。在這種情況中，群中的每 一個中間件可作為單獨(dú)的XA資源，而如果M個中間件(即群中的中間件)中的N個接收到 了消息，則認(rèn)為該發(fā)布操作成功了。對于多發(fā)送盡力而為策略，JMS客戶可使用標(biāo)準(zhǔn)的JMS發(fā)布/發(fā)送語義來向群中 的所有中間件發(fā)送消息。消息產(chǎn)生者可向目的地發(fā)送或發(fā)布消息。—旦發(fā)送或發(fā)布步驟的調(diào)用成功的返回，則可以假定中間件已經(jīng)接收到了消息。 在產(chǎn)生者側(cè)，確認(rèn)信息的通知與主題發(fā)布者的發(fā)布步驟、或隊(duì)列發(fā)送者的發(fā)送步驟的成功 調(diào)用有關(guān)。如果其沒有接收到JMS異常(JMSException)，則表明對JMS客戶的多發(fā)送操作 成功了。以下是多發(fā)送盡力而為的代碼的例子try {//Assumption clusterFactory. setBrokerCluster(new String[]{ "Broker#|i|oca|host 6849","Broker2i|oca|host 6949"})；clusterFactory. setClusterName ( "Tl")；clusterFactory. setClusterPolicy(WmClusterPolicyManager. MULTISEND_BESTEFF0RT)connection = ((WmConnectionFactory)clusterFactory). createConnection()；connection, start ()；session = pubIisherConnection. createSession(false,Session.AUT0_ACKN0WLEDGE)；MessageProducer producer = session. createProducer (queue)；TextMessage message = session. createTextMessage( "Testing MultiSend”)；//This will attempt to send the message to all the brokers inThe above clusterProducer, send(message)；System, out. println( "Multi Send is successful，，)；}catch(JMSExceptione) {//this means the multi send best effort failed to publish toeven one broker in the cluster
}從上述實(shí)施例可知，JMS發(fā)送并發(fā)布語義，該語義可用于向群中所有的中間件發(fā)布 消息。本質(zhì)地，JMS API可同步的向所有中間件發(fā)送消息并產(chǎn)生異常，雖然消息不能分發(fā)至 至少一個中間件。對于多發(fā)送有保證的策略，JMS API可向客戶(本例中為整合服務(wù)器)提供 APIgetXAConnectionsO，并會返回 XA 連接(Connection)的 N 數(shù)字(N number)。整合服 務(wù)器可使其為交易的一部分并可執(zhí)行發(fā)布操作。這有助于保證向群中的N個中間件發(fā)布 消息的成功。如果存在失敗，該策略可“回滾(rollback)”并嘗試再次發(fā)送。JMSAPI中的 getXAConnection的每一個后續(xù)呼叫(subsequent call)可發(fā)送另一個N個中間件的組合， 該N個中間件為群活躍中間件列表中的中間件。JMS API可保留有關(guān)MXN組合連接的列 表。 例如，如果有配置在群中的3個中間件B1、B2、B3，其策略為多發(fā)送有保證的策略 且為3個中的2個有保證，JMS API可保留B1-B2、B2-B3、B3-B1連接列表。 在具體的實(shí)施例中，可在循環(huán)模式中保存XA連接組合列表。這有助于保證，在群 中的中間件之間平衡負(fù)載。 在與不可用的中間件Bl有關(guān)的異常中，該列表可以與列表中的B1-B2—起更新， 而剩下的則可以被設(shè)為不活躍。需要注意的是，可以為或不為采用多發(fā)送有保證策略的連接工廠提供XA連接。JMS API可發(fā)送三種異常。“成功(Success) ”可表示客戶成功的向η個服務(wù)器發(fā) 送了消息?！安糠殖晒?Partial success) ”則表示向一些服務(wù)器發(fā)送成功但是沒有達(dá)到η 個服務(wù)器都成功了。“失敗(Failure)”表示向所有的服務(wù)器的發(fā)送都失敗了。JMS API可包括獨(dú)立的API以供客戶詢問中間件是否可用，例如，使用 isAvailableO函數(shù)，其指示了所需數(shù)量的中間件是否可用于發(fā)布。需要注意的是，該功能 可用于所有的策略類型。在具體實(shí)施例中，執(zhí)行副本消息檢測是有用的。例如，可以理解，當(dāng)采用多發(fā)送策 略時，執(zhí)行副本檢測是有用的。如前所述，在多發(fā)送語義中，客戶想JMS API發(fā)送消息。然 后，JMS API建立于群中所有中間件的連接?；诙喟l(fā)送JMS策略，JMS API可向群中的多 個(該個數(shù)可以與其最多可以向其發(fā)送的中間件的數(shù)目相同)中間件發(fā)送消息。訂閱者可 以采用同樣或不同的連接工廠來與中間件群連接。JMS API可建立與群中所有中間件的連 接以從每個中間件取回消息。由于采用的多發(fā)送策略的特性以及由發(fā)布客戶進(jìn)行的執(zhí)行， 這些中間件可具有相同的消息。在多發(fā)送語義中為避免副本，可執(zhí)行副本消息檢測來保證沒有消息被發(fā)送兩遍， 在中間件群環(huán)境中?？蔀镴MS消費(fèi)者客戶，例如JMS API，采用這種檢測機(jī)制。副本消息檢 測可影響JMS消息ID，在發(fā)送或發(fā)布操作中，可從JMS API中的產(chǎn)生者自動的產(chǎn)生?？稍O(shè)置 JMS消息ID使其代表通用唯一標(biāo)識(Universally Unique Identifier, UUID)。當(dāng)執(zhí)行副 本消息檢測特性時，可在連接工廠中使能JMS消息ID，雖然其可在其他上下文中被無效。例 如，可使用Java SE 5中的java. util. UUID類來產(chǎn)生UUID，即通過簡單的調(diào)用類中的UUID. randomUUID ()函數(shù)。如下所述，在消息的確認(rèn)中，JMS API可在連續(xù)的ID上進(jìn)行確認(rèn)，該ID來自中間件(其從該中間件為接收消息)，并進(jìn)行在群眾的剩余中間件上的待定確認(rèn)。待定確認(rèn)可以在 JMS消息上的UUID集合上表現(xiàn)。這有助于保證，在其他中間件上的副本消息不會被發(fā)送至 訂閱者。在具體實(shí)施例中，可可使用記錄進(jìn)行負(fù)載平衡。已記錄的消息的種類可包括，例 如，消息何時被發(fā)布/重發(fā)布，消息何時被接收，錯誤何時產(chǎn)生，連通性何時改變，等等。需 要注意的是，可存在很多原因?qū)е轮虚g件不可達(dá)。需要理解的是，在具體實(shí)施例中有時在負(fù) 載平衡解決方案中提供“最好的猜測(best guess)”。以上描述的策略可以看作是“簡單的”策略，在這個范圍，一個策略有效的控制中 間件群的負(fù)載平衡行為。然后，如上所提及的，具體實(shí)施例可“分層(layer)”多個策略，一 個在另一個之上。這樣，“簡單的”策略可以被分層，以便定義“復(fù)合(composition)”策略。 換句話來說，可對復(fù)合策略進(jìn)行定義和實(shí)施，使其作為多層群策略，在具體實(shí)施例中。為使 用該負(fù)載平衡特性，使用者可定義單個的群策略。這些來自JNDI提供者的子輩群連接工廠 對象可進(jìn)行分組，例如，組成復(fù)合連接工廠。復(fù)合連接工廠也可包括負(fù)載平衡策略定義，其 確定消息如何通過中間件群進(jìn)行分發(fā)。例如，如果連接工廠與多個群連接工廠對象有關(guān)，并 且定義了負(fù)載平衡策略，則群可以作為一個整體進(jìn)行工作，并根據(jù)負(fù)載平衡策略分發(fā)消息。在如下例子中，負(fù)載平衡策略可用于域復(fù)合連接工廠的連接中。當(dāng)然，需要說明的 是，可以將其他負(fù)載平衡策略與下述的負(fù)載平衡策略一起使用，或替換其使用?！ぴ谘h(huán)負(fù)載平衡策略中，將第一發(fā)布操作分配給復(fù)合群連接中的第一群連接，第 二發(fā)布操作分配給第二群，以此類推，直到所有的群都被遍歷，按此順序重復(fù)。在此上下文 中的循環(huán)算法的優(yōu)點(diǎn)包括發(fā)布操作以次序的方式平等的在可用群中分配。 在粘性的負(fù)載平衡策略中，JMS API需將消息發(fā)布至第一群，除非該群不再可用。 僅當(dāng)?shù)谝蝗菏r，消息才會被切換到下一個群。·在多種子盡力而為(seed-best effort)策略中，JMS API須將消息發(fā)布至所有 群或由復(fù)合群連接工廠定義的群子集中。如果消息被分發(fā)至至少一個群，則認(rèn)為發(fā)布/發(fā) 送操作成功了。為使能中間件服務(wù)器集群(clustering)，可對上述的中間件進(jìn)行改變。例如，中間 件服務(wù)器可支持群的產(chǎn)生。在這點(diǎn)上，集群中可不需要文檔轉(zhuǎn)發(fā)，由于訂閱者可能與群中的 所有中間件連接。相應(yīng)的，當(dāng)中間件加入群時，可對其適當(dāng)?shù)倪M(jìn)行通知，例如，以禁用群中的 文檔轉(zhuǎn)發(fā)。另一個例子涉及對文檔轉(zhuǎn)發(fā)的變化。在這點(diǎn)上，由于訂閱者可能與群中的所有 中間件連接，向任一中間件發(fā)布文檔即足以保證訂閱者可收到該文檔。相應(yīng)的，可以不需要 文檔向另一中間件進(jìn)行轉(zhuǎn)發(fā)。另一個設(shè)計(jì)上的可能的改變涉及文檔的預(yù)確認(rèn)(pre-acknowledgement)。該特性 可降低(或甚至阻止)副本文檔分發(fā)的可能性，當(dāng)采用多發(fā)送策略時，如前所述。本質(zhì)上， JMS客戶可以向另一中間取回和發(fā)送預(yù)確認(rèn)，這樣其他中間件可以丟棄文檔的副本。在中間 件中為支持該特性，發(fā)布者可設(shè)置UUID。然后，中間件即可識別兩種預(yù)確認(rèn)類型。第一種預(yù) 確認(rèn)為，客產(chǎn)已經(jīng)接收了至少一個文檔的復(fù)制件。在這種情況中，中間件可抑制發(fā)送文檔的 另一個復(fù)制件，但保存文檔以防在處理和確認(rèn)文檔之前與客戶失去連接。第二種預(yù)確認(rèn)為， 客戶已經(jīng)接收并處理/確認(rèn)了文檔。在這種情況下，中間件可從其隊(duì)列中刪除文檔，因?yàn)橐?經(jīng)不再需要該文檔了。
在具體實(shí)施例中，這種預(yù)確認(rèn)特性可以降低(而且有時候可阻止)發(fā)送副本消息 的可能性，例如，當(dāng)發(fā)布者采用多發(fā)送策略發(fā)送文檔時。然后，在具體的實(shí)施例中，并不能保 證這種“非副本(no duplicaties)”行為；相應(yīng)的，客戶自己也有檢測副本的機(jī)制。如前所提及的，通過在中間件中施行預(yù)確認(rèn)的兩種類型，來提供預(yù)確認(rèn)特性。第 一，暫時的預(yù)確認(rèn)將促使中間件保留文檔，而不將其發(fā)送給客戶。這種行為有助于保證不向 客戶發(fā)送不必須要的副本文檔。第二，確定的預(yù)確認(rèn)可指示，客戶已經(jīng)接收并成功的處理了 文檔，在這種情況下，中間件可以從隊(duì)列中刪除文檔。在具體細(xì)節(jié)中，中間件客戶隊(duì)列可維持兩個集合，稱為，tentatiVe_pre_aCk和 ckconf irmed_pre_ack。這些集合可存儲UUID (例如，數(shù)據(jù)類型“串”的)，當(dāng)其被客戶預(yù)確 認(rèn)。在發(fā)布/訂閱時，中間件可檢測這些集合，同時，中間件可進(jìn)行合適的動作(例如，丟棄 事件，跳過事件等)。UUID標(biāo)記的文檔可以幾種方式被暫時的預(yù)確認(rèn)。第一，例如，發(fā)布者可設(shè)置封裝 域(如，“preack”)為“暫時的(tentative) ”，這可在發(fā)布期間由中間件讀取，同時文檔被 標(biāo)記為預(yù)確認(rèn)的。第二，例如，客戶可進(jìn)行明確的呼叫(例如，JMS 二進(jìn)制協(xié)議)并通知中 間件暫時的預(yù)確認(rèn)。在這點(diǎn)上，可采用中間件二進(jìn)制協(xié)議(例如，協(xié)議V6(Pr0t0C0lV6))支 持新的呼叫以通知中間件預(yù)確認(rèn)。為有助于預(yù)確認(rèn)特性的實(shí)施，發(fā)布者可設(shè)置文檔中的暫時的預(yù)確認(rèn)封裝域，為除 一個以外的所有的中間件。如果這樣配置，則意味著，僅一個中間件將向訂閱者發(fā)送文檔， 而其他的中間件將僅在隊(duì)列中保持副本文檔。當(dāng)從客戶接收確認(rèn)時，向中間件發(fā)送規(guī)則的 確認(rèn)(例如，依照J(rèn)MS API通過發(fā)送“ack”)，該中間件為從其獲取文檔的中間件，并且可向 所有其他的中間件發(fā)送預(yù)確認(rèn)的確認(rèn)。在中間件側(cè)，在發(fā)布操作中中間件可檢測確認(rèn)的預(yù)確認(rèn)集合，并且如果文檔已經(jīng) 被客戶預(yù)確認(rèn)則跳過對文檔進(jìn)行排隊(duì)。當(dāng)將文檔添加到客戶隊(duì)列時，可進(jìn)行檢測。在將事 件插入客戶隊(duì)列之前可以不向其他地方增加檢測，例如，諸如內(nèi)部發(fā)布、將來的發(fā)布、將來 的事件更新、以及在隊(duì)列瀏覽時插入事件。在訂閱操作中，中間件可先檢測暫時的預(yù)確認(rèn)集合并，如果文檔已經(jīng)暫時地去人 了，跳過(而不是刪除)文檔。如果已經(jīng)確認(rèn)了確認(rèn)，刪除文檔?？墒褂檬录幚眍悂泶_定 事件是否已經(jīng)被與確定了。相似的，可采用類來確定是否要跳過事件。另一個可能的設(shè)計(jì)的改進(jìn)設(shè)計(jì)提供兩個或多個群之間的中間件群入口。該特征 可，例如，支持單個中間件失效情況中的失效備援，也支持采用多發(fā)送策略時的多冗余路 徑。中間件群入口可允許在群對之間的多個入口連接。相應(yīng)的，在具體實(shí)施例中，可避 免入口連接之間的單點(diǎn)的失敗?？稍谙到y(tǒng)中增加冗余，例如，這樣可以恰當(dāng)?shù)奶幚矶喟l(fā)布語 義。以下為中間件群入口的例子·假定有第一群，群Cl，其包括三個中間件。即，Cl = {A，B, C}。進(jìn)一步假定，有 第二群，群C2，具有兩個中間件。S卩，C2= {X，Y}。 基于這種假設(shè)，Cl和C2之間的可能的入口連接集合可以是子集{G} = {(Α，Χ)， (Α，Υ)，(Β，Χ)，(B，Y)，(C，X)，(C，Y)}?！た赡艿娜肟谶B接的集合{G’ }，其是{G}的子集，包括明確的元素和基數(shù)|G’
27<=mXn|，且有 m= Cl |，η = C2 |。需要注意的是，允許在群對之間產(chǎn)生多入口。還需要注意的是，入口刪除需要發(fā)送 細(xì)節(jié)信息，以精確的定義被移除的鏈接。在任何事件中，中間件發(fā)布路徑可發(fā)現(xiàn)第一活躍入 口連接并將事件轉(zhuǎn)發(fā)至相應(yīng)的遠(yuǎn)端中間件隊(duì)列。當(dāng)在另一端接收到轉(zhuǎn)發(fā)的事件時，其可被 處理?？蓪诙嘀虚g件協(xié)議發(fā)送的元數(shù)據(jù)的任何更新進(jìn)行處理，雖然元數(shù)據(jù)和運(yùn)行階段 文檔可以不被轉(zhuǎn)發(fā)回其起始的群，例如，以避免在非循環(huán)圖中產(chǎn)生循環(huán)回路。具體實(shí)施例中的負(fù)載平衡特性可以設(shè)計(jì)為應(yīng)用解決方案，該方案與中間件協(xié)議和 存儲實(shí)施無關(guān)。例如，具體實(shí)施例中的負(fù)載平衡特性可以建立在中間件API頂端，這樣足以 忍受大量的中間件服務(wù)器代碼的改變和/或?yàn)槲磥硖匦栽鰪?qiáng)的可擴(kuò)展性。使能具體實(shí)施例中的負(fù)載平衡特性的示例的運(yùn)行階段組成部分包括群連接、中間 件選擇器、以及策略管理器。群連接可實(shí)施為從發(fā)布者或訂閱者到中間件群的邏輯連接。其 可與中間件連接集合一起實(shí)施，例如，該連接作為從客戶到中間件群的抽象連接。中間件選 擇器可以為檢測運(yùn)行中間件并為相連的發(fā)布者或訂閱者選擇中間件(或多個中間件)的組 件。策略管理器可管理策略的產(chǎn)生、持續(xù)、以及在運(yùn)行階段的解釋。這些負(fù)載平衡組件中的 每一個可以以Java類的形式執(zhí)行，例如，當(dāng)發(fā)布者或訂閱者生成與中間件群的連接時對其 進(jìn)行調(diào)用。這些類可位于相同的Java處理中，作為在具體實(shí)施例中的發(fā)布者或訂閱。在具體實(shí)施例中，每一個發(fā)布者或訂閱者連接可與僅僅一個群連接通訊。群連接 啟動多個線程以進(jìn)行活躍中間件的檢測，基于策略的中間件選擇，與群中的單個中間件的 連接管理，等等。當(dāng)JMS應(yīng)用產(chǎn)生與連接工廠的JMS連接時，會產(chǎn)生群連接，該連接工廠包括 中間件群定義。此處的這些連接工廠涉及群連接工廠。群連接具體可為JMS連接的子類。 可利用該連接產(chǎn)生JMS發(fā)布者和訂閱者，類似于利用JMS API產(chǎn)生發(fā)布者和訂閱者時的方 法。然而，群發(fā)布者的發(fā)布方法和群訂閱者的接收方法可被覆蓋以結(jié)合負(fù)載平衡邏輯。當(dāng) 應(yīng)用關(guān)閉或破壞連接時，群連接管理的相應(yīng)的群連接和中間件連接也被關(guān)閉或破壞。產(chǎn)生訂閱者的訂閱的方法也可以在群連接會話的子類中實(shí)施。這些新方法可為訂 閱者建立向群中所有中間件的訂閱，例如，對用戶的經(jīng)驗(yàn)是透明的。中間件選擇器可稱為群連接，例如，以選擇和連接下一可用的中間件。這將會發(fā)生 在下述情況，例如，在產(chǎn)生初始連接之前，在消息被發(fā)布之間，在連接失敗時，產(chǎn)生重連接之 前，等等。中間件選擇器可包括線程，該線程周期性的更新群的中間件狀態(tài)表。可在群連接 之間共享該狀態(tài)表。這個中間件選擇器的輪詢階段可以被配置為，例如，與策略選擇相連。中間件選擇器可調(diào)用策略管理器，例如，以取回策略信息和運(yùn)行階段中間件選擇 標(biāo)準(zhǔn)?？稍诓呗怨芾砥髦蟹庋b策略的格式和實(shí)施，例如，該策略管理器，相應(yīng)的，為提供策 略存儲接口和策略算法的運(yùn)行階段操作的程序(例如，Java程序)?？蓮脑獢?shù)據(jù)存儲中向 Java對象中裝載策略?？梢曰?，例如，元數(shù)據(jù)存儲接口，對策略進(jìn)行串行化或并行化。可 為訂制的策略提供嵌入接口，并調(diào)用策略執(zhí)行的運(yùn)行階段接口來發(fā)現(xiàn)基于群中的中間件的 選擇標(biāo)準(zhǔn)。具體實(shí)施例中的負(fù)載平衡技術(shù)可為存在的JMS應(yīng)用向負(fù)載平衡JMS應(yīng)用提供平穩(wěn) 的過渡，而不需要改變代碼，同時還可減少對連接工廠的配置改變的數(shù)目。具體實(shí)施例中的 負(fù)載平衡技術(shù)中提供的具體公共應(yīng)用接口包括策略管理器接口和記錄器嵌入接口，如圖12 中所示。換句話說，圖12中示意了具體實(shí)施例中的負(fù)載平衡技術(shù)中提供的公共接口。如圖12 的例子中所示，這些類包括 WmConnectionFactorylmpl 1202，WmClusterPoIicyManager 1204, WmClusterPolicy 1206, WmClusterTrackable 1208，以及 WmClusterTracker 1210。 相應(yīng)的，在以下對這些類進(jìn)行描述。向現(xiàn)有的WmConnectionFactorylmpl中增力口兩個屬性?！?brokerCluster 為Java String數(shù)組，包括根據(jù)連接工廠定義的所有的中間件 (Broker)。將中間件次序(Order of the Broker)保留為用戶定義的次序?！?clusterPolicy 根據(jù)連接工廠定義的負(fù)載平衡策略的名稱?！ば枰⒁獾氖?，還可包括額外的屬性來支持其他的策略，例如， setMultiSendCount作為多發(fā)送有保證策略的屬性，有權(quán)重的循環(huán)策略中的每一個中間件 的權(quán)重(weights)。如上所述，可提供額外的公共方法來支持其他的屬性。WmConnectionFactorylmpl具有如下設(shè)置和獲取功能· setBrokerCluster 為連接工廠賦予作為群的中間件列表?！?getBrokerCluster 獲取根據(jù)連接工廠定義的群中間件的列表?！?setClusterPolicy 取回負(fù)載平衡策略的名稱?！?getClusterPolicy 定義與連接工廠的連接一起使用的負(fù)載平衡策略。· isClusterPolicy 如果該連接工廠與中間件群有關(guān)則返回真，否則，返回假。WmClusterPolicyManager為負(fù)載平衡組成組件進(jìn)行策略管理。其可從其他接近策 略元數(shù)據(jù)存儲的程序調(diào)用獲得。可調(diào)用WmClusterPolicyManager以，例如，發(fā)現(xiàn)已存在的 策略以及產(chǎn)生用戶的訂制的策略?；诖?，WmClusterPolicyManager接口(Interface)包 括如下方法· getPoIicyManager 查找用于該應(yīng)用的策略管理器。.getClusterBrokerInfo 為連接的客戶返回群中間件集合，基于當(dāng)前策略。如果 沒有指定的中間件，則返回空集合，群連接異常處理器將視其為連接錯誤?！?getAvaiIablePolicyNames 為該應(yīng)用取回可用的策略名稱?！?insertPolicy 產(chǎn)生并插入訂制的策略。· deletePolicy 從可用策略列表中移除策略?！?getPolicy 基于策略名稱查找運(yùn)行的策略實(shí)體。WmClusterPolicy定義的一個方法，getNextBrokers ()，其用于返回連接的中間件 的優(yōu)先的集合，基于指定的中間件群。WmClusterTrackable提供用于診斷的嵌入到跟蹤工具中的方法· setTracker 從負(fù)載平衡應(yīng)用中調(diào)用該方法以配置跟蹤工具或負(fù)載平衡中使用 的數(shù)據(jù)庫。跟蹤器重應(yīng)當(dāng)運(yùn)行WmClusterTracker接口。如果沒有設(shè)置跟蹤器，則負(fù)載平衡 不會寫任何數(shù)據(jù)。· setTrackerCategories 定義記錄的動作數(shù)據(jù)的類型。WmClusterTracker提供記錄消息的方法· Track 如果需要對動作進(jìn)行跟蹤則寫入記錄。· setTrackerCategories 使應(yīng)用配置記錄的動作的類型。如圖13 15所示，描述了群連接、策略管理器、以及中間件選擇器的類的一個具 體示意圖。如圖13所示，群連接的組成組件包括如下類
· WmClusterConnectionlmpl 當(dāng)在群連接工廠上產(chǎn)生JMS連接時組件該類，該類 作為負(fù)載平衡功能(函數(shù))的啟動程序。其執(zhí)行WmClusterTrackable接口，并且其為處理 群連接功能的WmCormectionlmpl的組成部分。擴(kuò)展WmCormectionlmpl的幾個子類以提供群行為。這些子類包括，例如WmClusterQueueConnectionlmpl, WmClusterTopicConnectionlmpl,WmClusterXAConnectionlmpl, WmClusterXAQueueConnectionlmpl,以及WmClusterXATopicConnectionlmplο· WmClusterConnectionfforker WmConnectionlmpl 的〒胃Bii^li5F 中的工作者類(worker class)，其管理與中間件的客戶連接。WmClusterConnectionlmpl 可包括多個 WmClusterConnectionfforker 實(shí)體。· WmClusterConnectionExceptionHandler 監(jiān)聽并處理連接的相關(guān)失敗，并更新 中間件群狀態(tài)表。'WmClusterSessionImpl類WmSessionImpl的子類，其覆蓋用于產(chǎn)生負(fù)載平衡的 中間客戶的會話方法。其還提供負(fù)載平衡發(fā)布的發(fā)布方法。各種各樣的會話實(shí)施方案的群擴(kuò)展包括WmClusterQueueSessionlmpl, WmClusterTopicSessionlmpl,WmClusterXASessionlmpl, WmClusterXAQueueSessionlmpl, VXRWmClusterXATopicSessionlmpl ο· WmClusterMessageConsumerlmpl WmMessageConsumerImpl 的子類，其為負(fù)載平 衡訂閱者實(shí)施接收方法。· WmMessageProducerlmpl 子類WmMessageProducerImp 1 的子類集合，實(shí)施群集 (clustering)行為。包括 WmClusterQueueSenderlmpl 禾口 WmClusterTopicPublisherlmpl?！?WmClusterQueueBrowserlmpl :WmQueueBrowserImpl 的子類,為將所有物理隊(duì)列 集合為一個群隊(duì)列的邏輯的實(shí)施。可實(shí)施新的消息瀏覽器類。群連接組成部件還定義了兩個接口 'WmClusterTrackable 允許嵌入式追蹤器的接口。WmClusterConnectionlmpl 實(shí) 施該接口。· WmClusterTracker 嵌入式追蹤工具或數(shù)據(jù)庫應(yīng)用實(shí)施的接口。策略管理器，例如，通過提供對中間件選擇器為中間件選擇標(biāo)準(zhǔn)采用的策略的操 作(handlers)，來處理策略的維持和發(fā)現(xiàn)。如圖14所示，其包括下述類· WmClusterPolicyManager 作為策略工廠工作的抽象類。其裝載和保存屬于相 關(guān)元數(shù)據(jù)存儲的策略。"WmClusterPolicy 提供策略的嵌入接口的抽象類。其實(shí)施負(fù)載平衡算法的通用 行為?！ぞ唧w策略管理者(Concrete Policy Manager)類WmClusterPoIicyManager 的 子類，諸如WmClusterJNDIPlicyManager，其實(shí)施達(dá)到具體元數(shù)據(jù)存儲的細(xì)節(jié)?！ぞ唧w策略(Concrete Policy)類WmClusterPolicy 的子類，諸如 WmClusterRoimdRobinPolicy，其實(shí)施特定的算法或規(guī)則，用于選擇要連接的運(yùn)行階段的中 間件。
如圖15所示中間件選擇器用于查找要連接的下一中間件集合。中間件選擇器包 括如下主要的類· WmClusterBrokerSelector 查詢策略管理器，分析群中間件狀態(tài)信息，以為群連 接提供可選擇的中間件。· WmClusterBrokerMonitor 為運(yùn)行階段信息，周期性的輪詢?nèi)杭闹虚g件。該輪 詢間隔可由使用者訂制，例如，作為連接工廠屬性?！?WmClusterBrokerlnfo 保持關(guān)于群中的中間件的運(yùn)行階段信息，其可以是持續(xù) 的或非持續(xù)的。圖16示意了具體實(shí)施例中的負(fù)載平衡中間件JMS應(yīng)用的整體結(jié)構(gòu)。如圖16所示 以及在上述所提及的，負(fù)載平衡中間件JMS應(yīng)用有三種行動者(actor)類型，包括發(fā)布者應(yīng) 用1602、中間件群1102、以及訂閱者應(yīng)用1606。JMS負(fù)載平衡訂閱者和發(fā)布者1604和1608 以與普通的JMS發(fā)布者和訂閱者相同的方式工作，例如，以與連接1610和1612相關(guān)的方式 工作，分別的，并處理消息的發(fā)布/訂閱。上述的很多“發(fā)布/訂閱(pub/sub)”行為也應(yīng) 用到負(fù)載平衡的具體實(shí)施例中。具體實(shí)施例中的負(fù)載平衡特征可被自動使能，例如，當(dāng)JMS 應(yīng)用啟動與中間件群連接工廠的JMS連接時。負(fù)載平衡類可運(yùn)行于與應(yīng)用相同的虛擬機(jī)器 (例如，JavaVirtual Machine或JVM)中，而負(fù)載平衡的組成組件的機(jī)制對應(yīng)用來說是透明 的。如圖16所示，負(fù)載平衡發(fā)布者1604和訂閱者1608與以中間件群1102形式存在 的中間件106集合連接。中間件群1102中的中間件106作為一個整體工作，以共享工作負(fù) 載并提供負(fù)載平衡。在JMS API中可提供負(fù)載平衡功能的實(shí)施，其由發(fā)布者應(yīng)用1602或訂 閱者應(yīng)用1606調(diào)用。群連接1610和1612可在群1102的兩側(cè)工作。發(fā)布者應(yīng)用1602與群連接1610連 接，且每一個群連接1610都與群1102中的一個或多個中間件106連接，基于采用的策略。 相似的，訂閱者應(yīng)用1606也可與群連接1610連接，其與群1102中的每一個中間件106連 接。這些與中間件106的直接連接可由群連接組件來維持。現(xiàn)在描述具體實(shí)施例中的運(yùn)行階段行為。具體的，在運(yùn)行階段可通過JMS連接使 能負(fù)載平衡功能，該功能改變連接和發(fā)布/訂閱流。從發(fā)布者應(yīng)用中，應(yīng)用代碼調(diào)用連接的產(chǎn)生。這會啟動群連接和其相關(guān)類的產(chǎn)生， 例如，以管理與中間件群的連接。在生成連接過程中，群連接首先咨詢中間件選擇器以發(fā)現(xiàn) 要連接的第一中間件集合。當(dāng)應(yīng)用產(chǎn)生會話時，安置群會話。對群會話的發(fā)布調(diào)用群連接， 以更新當(dāng)前的連接。在循環(huán)策略的情況中，例如，在消息被發(fā)布前，群連接與下一中間件連 接。如果中間件不可用，更新中間件狀態(tài)表，負(fù)載平衡將會在進(jìn)行連接時跳過該中間 件。當(dāng)使用者應(yīng)用關(guān)閉JMS連接時，相關(guān)的群連接被關(guān)閉，而相關(guān)的負(fù)載平衡類也被 破壞。圖17與圖11和16類似，圖17為具體實(shí)施例中的與負(fù)載平衡發(fā)布/訂閱模型有 關(guān)的各元素的示意圖。具體的，圖17示意了經(jīng)由整合服務(wù)器102的請求，例如，經(jīng)由pub. jms. send方法，相應(yīng)的，該方法調(diào)用JMS API 914。在請求/發(fā)布客戶側(cè)，經(jīng)由JMS API 914
31建立與每個中間件106的連接，該中間件106配置在中間件群1102中(例如，如圖17左側(cè) 所示)。在響應(yīng)/訂閱側(cè)(如，圖17中的右側(cè)所示)，整合服務(wù)器102包括被配置來調(diào)用一 個或多個觸發(fā)服務(wù)502的觸發(fā)器(如，JMS觸發(fā)器)。在響應(yīng)/訂閱側(cè)的整合服務(wù)器102，類 似于在請求/發(fā)布客戶側(cè)上的整合服務(wù)器，與配置在中間件群1102中的中間件106連接。 循環(huán)策略如何在圖16和17中示意的原理結(jié)構(gòu)中實(shí)施的細(xì)節(jié)將根據(jù)圖18和19進(jìn)行解釋。圖18示意了在具體實(shí)施例中的依據(jù)循環(huán)策略的負(fù)載平衡發(fā)布的流程。類似的，當(dāng) 訂閱者應(yīng)用產(chǎn)生JMS連接時，產(chǎn)生群連接，如圖19所示。產(chǎn)生群會話以代替規(guī)則的JMS會 話。當(dāng)訂閱者應(yīng)用構(gòu)建訂閱者時，群連接產(chǎn)生助手(helper)類實(shí)體，例如，以處理與群中所 有中間件的連接。在負(fù)載平衡應(yīng)用中，放置群消費(fèi)者子類實(shí)體。在所有訂閱者中放置訂閱，并在領(lǐng)域(territory)中間件中強(qiáng)置僅處于本地的訂 閱。當(dāng)消費(fèi)者接收消息時，所有群消費(fèi)者接收來自所有中間件的消息。從中間件接收的消 息可以有或者沒有預(yù)定的次序。群連接、群會話、以及群消費(fèi)者可被破壞，當(dāng)訂閱者應(yīng)用關(guān)閉連接或結(jié)束時。具體實(shí)施例中提供了在群環(huán)境中的交易消息的供應(yīng)。例如，在具體實(shí)施例中可提 供在JMS群集的環(huán)境中的JTA/XA的供應(yīng)。基于此，JMS實(shí)施可起到在分發(fā)交易中的資源管 理器的作用，其作用的方式可與數(shù)據(jù)庫處理分發(fā)交易類似。在典型的腳本中，應(yīng)用服務(wù)器 起到交易管理器的作用，作為在兩個或多個JMS會話和/或數(shù)據(jù)庫資源之間的兩階段提交 (two phase commit，簡稱2PC)交易。下表提供了示例的設(shè)計(jì)的變化使能在具體實(shí)施例中 的JMS群環(huán)境中的XA全局交易的實(shí)施
權(quán)利要求
一種在應(yīng)用整合系統(tǒng)，包括發(fā)布應(yīng)用，被配置為產(chǎn)生和發(fā)送消息，所述消息依據(jù)使用者定義的復(fù)合策略發(fā)送，所述復(fù)合策略包括至少第一和第二策略層；第一和第二中間件群，每一個所述中間件群包括多個中間件，所述每個中間件被配置為從發(fā)布應(yīng)用中繼消息到至少一個訂閱應(yīng)用；與所述發(fā)布應(yīng)用連接的復(fù)合群連接；以及與所述復(fù)合群連接連接的多個群連接；其中，所述復(fù)合群連接被配置為依據(jù)所述第一策略層向至少一個所述群連接路由消息，以及每一個所述群連接被配置為依據(jù)所述第二策略層向至少一個中間件路由消息。
2.如權(quán)利要求1所述的系統(tǒng)，其特征在于，每一個所述策略層基于下述策略中的一種 (a)循環(huán)負(fù)載平衡策略，(b)粘性的負(fù)載平衡策略，其中向特定的中間件進(jìn)行發(fā)布直到產(chǎn)生 失敗，當(dāng)產(chǎn)生失敗時向不同的該特定的中間件的另一中間件進(jìn)行發(fā)布，(c)隨機(jī)分配，(d) 文檔大小策略，其中基于文檔大小向不同的中間件路由消息，(e)有權(quán)重的循環(huán)策略，其中 為每一個中間件分配權(quán)重，該權(quán)重表征中間件相對于其他中間件的服務(wù)執(zhí)行程度以及與其 他中間件相比被發(fā)送給每一中間件的消息的相對數(shù)量，以及(f)向多個中間件發(fā)送消息的 多發(fā)送策略。
3.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述第一策略層與所述第二策略層不同。
4.如權(quán)利要求1所述的系統(tǒng)，其特征在于，至少一個所述策略層基于向多個中間件發(fā) 送消息的多發(fā)送策略。
5.如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述多發(fā)送策略為盡力而為的多發(fā)送策略， 在所述盡力而為的多發(fā)送策略中如果至少一個所述中間件接收到消息則認(rèn)為成功。
6.如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述多發(fā)送策略為有保證的多發(fā)送策略，在 所述有保證的多發(fā)送策略中僅當(dāng)M個中間件中的N個接收到消息時認(rèn)為成功，其中，N為使 用者定義的常數(shù)，M為相關(guān)群中的中間件的數(shù)目。
7.如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述多發(fā)送策略包括副本消息檢測，通過比 較與所述消息有關(guān)的通用唯一標(biāo)識UUIDs進(jìn)行副本消息檢測。
8.如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述多發(fā)送策略包括在所述中間件中至少 一些中的消息確認(rèn)。
9.如權(quán)利要求1所述的系統(tǒng)，其特征在于，進(jìn)一步包括至少一個訂閱應(yīng)用，所述訂閱應(yīng) 用被配置為接收來所述發(fā)布應(yīng)用的消息并依據(jù)所述消息引發(fā)要被執(zhí)行的服務(wù)。
10.如權(quán)利要求1所述的系統(tǒng)，其特征在于，進(jìn)一步包括與每一個所述訂閱應(yīng)用連接的訂閱復(fù)合群連接；以及與所述訂閱復(fù)合群連接連接的多個訂閱群連接；其中，每一個所述訂閱復(fù)合群連接依據(jù)第一訂閱策略層被配置為向至少一個所述訂閱 群連接路由確認(rèn)消息，以及每一個所述訂閱群連接依據(jù)訂閱策略層被配置為向至少一個中間件路由所述消息。
11.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述消息為JMS消息。
12.在應(yīng)用整合系統(tǒng)中的消息路由方法，包括提供發(fā)布應(yīng)用；提供第一和第二中間件群，每一個所述中間件群包括多個中間件，所述每個中間件被 配置為從發(fā)布應(yīng)用中繼消息到至少一個訂閱應(yīng)用；連接復(fù)合群連接與所述發(fā)布應(yīng)用；連接多個群連接與所述復(fù)合群連接；根據(jù)所述發(fā)布應(yīng)用產(chǎn)生消息；以及依據(jù)使用者定義的包括至少第一和第二策略層的復(fù)合策略從所述發(fā)布應(yīng)用向所述中 間件群發(fā)送消息，所述消息依據(jù)所述第一策略層被從所述復(fù)合群連接路由至至少一個所述 群連接，所述消息依據(jù)所述第二策略層被從至少一個所述群連接路由至至少一個所述中間 件。
13.如權(quán)利要求12所述的方法，其特征在于，每一個所述策略層基于下述策略中的一 種(a)循環(huán)負(fù)載平衡策略，(b)粘性的負(fù)載平衡策略，其中向特定的中間件進(jìn)行發(fā)布直到 產(chǎn)生失敗，當(dāng)產(chǎn)生失敗時向不同的該特定的中間件的另一中間件進(jìn)行發(fā)布，(c)隨機(jī)分配， (d)文檔大小策略，其中基于文檔大小向不同的中間件路由消息，(e)有權(quán)重的循環(huán)策略， 其中為每一個中間件分配權(quán)重，該權(quán)重表征中間件相對于其他中間件的服務(wù)執(zhí)行程度以及 與其他中間件相比被發(fā)送給每一中間件的消息的相對數(shù)量，以及(f)向多個中間件發(fā)送消 息的多發(fā)送策略。
14.如權(quán)利要求12所述的方法，其特征在于，所述第一策略層與所述第二策略層不同。
15.如權(quán)利要求12所述的方法，其特征在于，至少一個所述策略層基于向多個中間件 發(fā)送消息的多發(fā)送策略。
16.如權(quán)利要求15所述的方法，其特征在于，所述多發(fā)送策略為盡力而為的多發(fā)送策 略，在所述盡力而為的多發(fā)送策略中如果至少一個所述中間件接收到消息則認(rèn)為成功。
17.如權(quán)利要求15所述的方法，其特征在于，所述多發(fā)送策略為有保證的多發(fā)送策略， 在所述有保證的多發(fā)送策略中僅當(dāng)M個中間件中的N個接收到消息時認(rèn)為成功，其中，N為 使用者定義的常數(shù)，M為相關(guān)群中的中間件的數(shù)目。
18.如權(quán)利要求15所述的方法，其特征在于，進(jìn)一步包括通過比較與所述消息有關(guān)的 通用唯一標(biāo)識UUIDs檢測副本消息。
19.如權(quán)利要求15所述的方法，其特征在于，進(jìn)一步包括對所述中間件中至少一些中 間件的消息的接收進(jìn)行確認(rèn)。
20.如權(quán)利要求21所述的方法，其特征在于，進(jìn)一步包括提供至少一個訂閱應(yīng)用，所述 訂閱應(yīng)用被配置為接收來所述發(fā)布應(yīng)用的消息并依據(jù)所述消息引發(fā)要被執(zhí)行的服務(wù)。
21.如權(quán)利要求12所述的方法，其特征在于，所述消息為JMS消息。
22.如權(quán)利要求12所述的方法，其特征在于，進(jìn)一步包括在應(yīng)用整合系統(tǒng)運(yùn)轉(zhuǎn)時部署 增加的中間件和/或發(fā)布應(yīng)用。
23.如權(quán)利要求12所述的方法，其特征在于，進(jìn)一步包括重新定義復(fù)合策略。
24.一種在應(yīng)用整合系統(tǒng)中調(diào)用目標(biāo)服務(wù)的方法，所述方法包括提供第一和第二客戶系統(tǒng)，所述系統(tǒng)一起實(shí)施發(fā)布/訂閱消息交換模型；提供至少一個中間件群，所述至少一個中間件群包括多個中間件服務(wù)器；通過所述第一客戶系統(tǒng)產(chǎn)生消息，所述消息為調(diào)用在所述第二客戶系統(tǒng)中的目標(biāo)服務(wù)的觸發(fā)器 依據(jù)所述第一客戶系統(tǒng)定義的策略，將所述消息從所述第一客戶系統(tǒng)經(jīng)由在至少一個 所述中間件群中的至少一個所述中間件服務(wù)器路由至所述第二客戶系統(tǒng)； 在所述第二客戶系統(tǒng)接收所述消息；以及 通過所述第二客戶系統(tǒng)調(diào)用所述目標(biāo)服務(wù)。
25.如權(quán)利要求24所述的方法，進(jìn)一步包括 在應(yīng)用整合系統(tǒng)運(yùn)轉(zhuǎn)時部署增加的中間件和/或客戶系統(tǒng)；以及 根據(jù)應(yīng)用整合系統(tǒng)的組成更新元數(shù)據(jù)。
全文摘要
此處揭示的實(shí)施例涉及基于策略的JMS中間件群的系統(tǒng)和/或方法，尤其涉及，建立在發(fā)布-訂閱模型(或其類似)上的應(yīng)用整合技術(shù)。在具體實(shí)施例中，提供了發(fā)布應(yīng)用，以及第一和第二中間件群。每一個中間件群包括多個中間件，且每一個中間件被配置為從發(fā)布應(yīng)用向至少一個訂閱應(yīng)用中繼消息。復(fù)合群連接與發(fā)布應(yīng)用連接，而群連接則與復(fù)合群連接。發(fā)布應(yīng)用產(chǎn)生的消息依據(jù)使用者定義的復(fù)合策略被發(fā)送給中間件群?；诘谝徊呗詫樱⒈粡膹?fù)合群連接路由至至少一個群連接?；诘诙呗詫?，消息被從至少一個群連接路由至至少一個中間件。
文檔編號H04L29/08GK101945056SQ20101022293
公開日2011年1月12日 申請日期2010年6月29日 優(yōu)先權(quán)日2009年6月29日
發(fā)明者德里克·羅區(qū)奇, 瓦蘇德瓦·科塔馬蘇, 賈森·辛普森 申請人:軟件Ag公司