專利名稱：智能消息傳遞應(yīng)用編程接口的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)消息傳遞中間件體系結(jié)構(gòu)，并且更具體地涉及具有發(fā) 布和訂購(此后稱為"發(fā)布/訂購")中間件體系結(jié)構(gòu)的消息傳遞系統(tǒng)中的 應(yīng)用編程接口。
背景技術(shù)：
數(shù)據(jù)消息傳輸傳遞基礎(chǔ)設(shè)施所要求的日益提高的性能水平強迫聯(lián)網(wǎng)基 礎(chǔ)設(shè)施和協(xié)議的發(fā)展?；旧?，數(shù)據(jù)分發(fā)涉及各種數(shù)據(jù)源和目的地，以及 各種類型的互連體系結(jié)構(gòu)和數(shù)據(jù)源和目的地之間的通信模式?，F(xiàn)有數(shù)據(jù)消 息傳輸傳遞體系結(jié)構(gòu)的示例包括輪軸輪輻式(hub-and-spoke)，對等式和 存儲轉(zhuǎn)發(fā)式。利用輪軸輪輻系統(tǒng)配置，所有通信都通過輪軸傳輸，這在處理量大時 通常會導(dǎo)致性能瓶頸。因此，這種消息傳遞系統(tǒng)產(chǎn)生了等待時間。繞過這 種瓶頸的一種方法是布署更多的服務(wù)器，并且在這些不同的服務(wù)器之間分 布網(wǎng)絡(luò)負(fù)載。但是，這種體系結(jié)構(gòu)表現(xiàn)出可擴展性和操作問題。與具有輪軸輪輻配置的系統(tǒng)相比，具有對等配置的系統(tǒng)對應(yīng)用產(chǎn)生了不必要的壓力 以處理和過濾數(shù)據(jù)，并且僅與其最慢的客戶或節(jié)點一樣快。而具有存儲轉(zhuǎn) 發(fā)系統(tǒng)配置的系統(tǒng)為了提供持久性，要在將數(shù)據(jù)轉(zhuǎn)發(fā)到路徑中的下一個節(jié) 點之前存儲該數(shù)據(jù)。存儲操作通常通過索引和將消息寫到存儲盤來實現(xiàn)， 這可能產(chǎn)生性能瓶頸。此外，在消息量增大了時，索引和寫入任務(wù)可能相 當(dāng)慢，因此可能引入額外的等待時間?，F(xiàn)有數(shù)據(jù)消息傳遞體系結(jié)構(gòu)共有一些不足。 一個共同的不足是在現(xiàn)有 體系結(jié)構(gòu)中數(shù)據(jù)消息傳遞依賴于駐留在應(yīng)用層上的軟件。這意味著消息傳 遞基礎(chǔ)設(shè)施要經(jīng)歷OS (操作系統(tǒng))排隊和網(wǎng)絡(luò)I/0 (輸入/輸出)，這可能 產(chǎn)生性能瓶頸。另一個共同的不足是現(xiàn)有體系結(jié)構(gòu)靜態(tài)地而不是動態(tài)地使 用數(shù)據(jù)傳輸協(xié)議，即使在某些情形下其他協(xié)議可能更合適也是如此。常見 協(xié)議的一些示例包括可路由多播、廣播或單播。實際上，現(xiàn)有體系結(jié)構(gòu)中 的應(yīng)用編程接口 (API)未被設(shè)計為實時地在傳輸協(xié)議之間切換。另外，網(wǎng)絡(luò)配置判決通常是在布署時進(jìn)行的，并且通常被定義為在特 定假設(shè)下對一組網(wǎng)絡(luò)和消息傳遞條件進(jìn)行優(yōu)化。與靜態(tài)(固定的)配置相 關(guān)聯(lián)的限制排除了實時動態(tài)網(wǎng)絡(luò)重配置。換言之，現(xiàn)有體系結(jié)構(gòu)是針對特 定傳輸協(xié)議配置的，而該傳輸協(xié)議并不總是適合所有網(wǎng)絡(luò)數(shù)據(jù)傳輸負(fù)載條 件，因此，現(xiàn)有體系結(jié)構(gòu)總是不能實時地應(yīng)對改變或增大的負(fù)載能力需 求。此外，在數(shù)據(jù)消息傳遞去往特定的接收者或者接收者群組時，現(xiàn)有消 息傳遞體系結(jié)構(gòu)使用可路由多播來將數(shù)據(jù)傳輸過網(wǎng)絡(luò)。但是，在針對多播 建立的系統(tǒng)中，存在對可以用來分發(fā)數(shù)據(jù)的多播群組的數(shù)目的限制，結(jié) 果，消息傳遞系統(tǒng)不再將數(shù)據(jù)發(fā)送向未被向其訂購的目的地(即不是該特 定數(shù)據(jù)的訂購者的消費者)。由于數(shù)據(jù)過濾，這增大了客戶的數(shù)據(jù)處理負(fù) 載和丟棄率。因此，由于任何原因變?yōu)檫^載并且不能跟上數(shù)據(jù)流的客戶最 終丟棄進(jìn)入數(shù)據(jù)，并且稍后要求重傳。重傳對整個系統(tǒng)造成影響，因為所 有客戶都接收重復(fù)的傳輸，并且所有客戶都對進(jìn)入數(shù)據(jù)進(jìn)行重新處理。因 此，重傳可能導(dǎo)致多播風(fēng)暴，并且最終可能使整個系統(tǒng)癱瘓。在系統(tǒng)是針對單播消息傳遞建立來作為減少丟棄率的一種方法時，該消息傳遞系統(tǒng)可能因為數(shù)據(jù)復(fù)制而經(jīng)歷帶寬飽和。例如，如果多于一個客 戶訂購了感興趣的給定話題，則消息傳遞系統(tǒng)必須將該數(shù)據(jù)遞送到每個訂 戶，實際上，系統(tǒng)將該數(shù)據(jù)的不同拷貝發(fā)送到每個訂戶。盡管這解決了客 戶濾除非訂購數(shù)據(jù)的問題，但是單播傳輸是不可擴展的，因此基本上不適 合訂購特定數(shù)據(jù)的大量客戶群組或者消費模式極度重疊的情形。另外，在發(fā)布者和訂購者之間的路徑中，消息在應(yīng)用之間的跳 (hop)中傳播，其中每一跳都引入了應(yīng)用和操作系統(tǒng)(OS)等待時間。 因此，總的端到端等待時間隨著跳的數(shù)目增長而增加。還有，當(dāng)從發(fā)布者 向訂購者路由消息時，沿著路徑的消息吞吐量受路徑中的最慢節(jié)點所限 制，并且在現(xiàn)有系統(tǒng)中無法實現(xiàn)端到端消息傳遞流控制來克服該限制?，F(xiàn)有體系結(jié)構(gòu)的另一個普遍缺點是它們的緩慢并且經(jīng)常大量的協(xié)議變換。這是因為企業(yè)應(yīng)用集成(EAI)領(lǐng)域中的IT (信息技術(shù))權(quán)宜(band-aid) 策略，其中越來越多的新技術(shù)被與遺留系統(tǒng)集成。因此，需要在許多區(qū)域中提高數(shù)據(jù)消息傳遞系統(tǒng)的性能。性能可能需 要提高之處的示例是速度、資源分配、等待時間等等。發(fā)明內(nèi)容本發(fā)明部分地基于上述觀察并基于如下觀念，即可以使用不同的方法 來解決這種缺點且具有更好的結(jié)果。這些觀察引起了用于高容量和低等待 時間的消息傳遞的端到端消息發(fā)布/訂購中間件體系結(jié)構(gòu)的產(chǎn)生，特別引起 了智能消息傳遞應(yīng)用編程接口 (API)的產(chǎn)生。因此，對于與應(yīng)用的通 信，具有端到端消息發(fā)布/訂購中間件體系結(jié)構(gòu)的數(shù)據(jù)分配系統(tǒng)可以有利地 傳送顯著更高的消息容量并且具有顯著更低的等待時間，所述端到端消息 發(fā)布/訂購中間件體系結(jié)構(gòu)包括根據(jù)本發(fā)明的原理的智能消息傳遞API。為 了實現(xiàn)該目的，本發(fā)明例如設(shè)想通過可靠、高度可用、基于會話的容錯設(shè) 計并通過引入以下特征的各種組合來改善API與消息傳遞設(shè)備之間的通 信，所述特征包括遲模式綁定、部分發(fā)布、協(xié)議優(yōu)化、實時信道優(yōu)化、 增值計算定義語言、智能消息傳遞網(wǎng)絡(luò)接口硬件、應(yīng)用的DMA (直接存 儲器訪問)、系統(tǒng)性能監(jiān)視、消息流控制、具有臨時緩存的消息傳輸邏輯以及增值消息處理。從而，根據(jù)如圖所示并在這里概況描述的本發(fā)明的目的， 一種用于應(yīng) 用與發(fā)布/訂購中間件系統(tǒng)之間的通信的示例性API包括通信引擎、 一個或 多個存根，以及進(jìn)程間通信總線(我們簡稱為總線)。在一個實施例中， 當(dāng)例如多于一個應(yīng)用使用單個通信引擎來接收和發(fā)送消息時，通信引擎可被實現(xiàn)為守護進(jìn)程(Daemon)。在另一個實施例中，通信引擎可和存根一 起被編譯到應(yīng)用中，以消除額外的守護跳。在這種情況下，通信引擎和存 根之間的總線將被定義為進(jìn)程內(nèi)通信總線。在該實施例中，所述通信引擎被配置為充當(dāng)應(yīng)用與發(fā)布/訂購中間件系 統(tǒng)之間的通信的網(wǎng)關(guān)。所述通信引擎的操作對應(yīng)用是透明的，用于使用動 態(tài)選擇的消息傳輸協(xié)議從而提供協(xié)議優(yōu)化，并用于對傳輸信道資源和流實 時地進(jìn)行監(jiān)視和動態(tài)控制。所述一個或多個存根被用于所述應(yīng)用與所述通 信引擎之間的通信。進(jìn)而，所述總線被用于所述一個或多個存根與所述通 信引擎之間的通信。還是根據(jù)本發(fā)明的目的，API的第二示例包括通信引擎、 一個或多個 存根和總線。該實施例中的通信引擎被建立在包括消息層和消息傳輸層的 邏輯層上，其中所述消息層包括應(yīng)用遞送路由引擎、管理消息層和消息路 由選擇引擎，并且其中所述消息傳輸層包括信道管理部分，所述信道管理 部分用于基于系統(tǒng)資源使用實時地控制由所述消息層處理的消息的傳輸路 徑。上述的實施例是用于實現(xiàn)API的示例中的兩個，并且其他示例根據(jù)附 圖和后面的描述將變得顯而易見?？傊?，根據(jù)這里的描述、所述權(quán)利要求 書和此后描述的附圖，本發(fā)明的這些和其他特征、方面和優(yōu)點將變得更加 明白。


被結(jié)合于此并組成本說明書的一部分的附示了本發(fā)明的各種方 面，并和具體描述一起用來說明本發(fā)明的原理。為了方便，整個附圖中將 使用相同的標(biāo)號來指示相同或相似的元件。圖1示出了根據(jù)本發(fā)明原理的端到端中間件體系結(jié)構(gòu)。圖la是示出了覆蓋網(wǎng)絡(luò)(overlaynetwork)的圖。 圖2是示出了利用根據(jù)本發(fā)明原理的端到端中間件體系結(jié)構(gòu)實現(xiàn)的企 業(yè)基礎(chǔ)設(shè)施的圖。圖2a是示出了具有創(chuàng)建網(wǎng)絡(luò)骨干網(wǎng)非居間化的消息設(shè)備(MA)的企 業(yè)基礎(chǔ)設(shè)施物理布署的圖。圖3示出了基于信道的消息傳遞系統(tǒng)的體系結(jié)構(gòu)。圖4示出了一種可能的基于話題的消息格式。圖5示出了基于話題的消息路由選擇和路由選擇表。圖6示出了智能消息傳遞應(yīng)用編程接口 (API)。圖7示出了自適應(yīng)消息流控制的影響。圖8a和圖8b示出了智能網(wǎng)絡(luò)接口卡(NIC)的配置。圖9示出了基于會話的容錯(faulttolerant)設(shè)計。圖10示出了消息傳遞設(shè)備(MA)到API的接口。
具體實施方式
這里的描述提供了根據(jù)本發(fā)明的各種實施例的消息發(fā)布-訂購系統(tǒng)的端 到端中間件體系結(jié)構(gòu)的細(xì)節(jié)，特別是智能消息傳遞應(yīng)用編程接口 (API) 的細(xì)節(jié)。在概括這些各種實施例的細(xì)節(jié)之前，下面是對本說明書中所使用 的術(shù)語的簡單說明。注意，該說明僅是為了澄清并且向讀者給出對可能如 何使用這些術(shù)語的理解，但是不是將這些術(shù)語限于使用它們的上下文中， 也不是要因此限制權(quán)利要求書的范圍。術(shù)語"中間件"在計算機工業(yè)中作為一個一般術(shù)語使用，針對在兩個 分離的通常已存在的程序之間協(xié)調(diào)的任何編程。添加中間件的目的是從應(yīng) 用卸下與信息交換相關(guān)聯(lián)的一些復(fù)雜性，其中這是通過定義網(wǎng)絡(luò)中的所有 參與者(發(fā)布者和訂購者)之間的通信接口等來實現(xiàn)的。 一般而言，中間 件程序提供消息傳遞服務(wù)，以使得不同的應(yīng)用程序可以通信。利用中間件 軟件層，可以無縫地執(zhí)行應(yīng)用之間的信息交換。通常通過利用中間件將不 同的應(yīng)用程序在系統(tǒng)上連結(jié)到一起被稱作企業(yè)應(yīng)用集成(EAI)。但是，10可以是一種更廣的術(shù)語，用在在源和目的地 之間的消息傳遞和布署來實現(xiàn)這種消息傳遞的設(shè)備的上下文中；因此，中 間件體系結(jié)構(gòu)單獨或者與下面將描述的組合覆蓋了實現(xiàn)高效數(shù)據(jù)消息傳遞 的聯(lián)網(wǎng)和計算機硬件與軟件組件。此外，術(shù)語"消息傳遞系統(tǒng)"或者"中 間件系統(tǒng)"可以被用在發(fā)布/訂購系統(tǒng)的上下文中，在該系統(tǒng)中，消息傳遞 服務(wù)器對在發(fā)布者和訂購者之間的消息路由選擇進(jìn)行管理。實際上，消息 傳遞中間件中發(fā)布/訂購的范式是可擴展的，因此是一種有力的模型。術(shù)語"客戶"可以用在客戶機-服務(wù)器應(yīng)用等的上下文中。在一個實例 中，客戶是這樣一種系統(tǒng)或應(yīng)用，其利用應(yīng)用編程接口 (API)注冊到中 間件系統(tǒng)，以訂購信息，并且接收該中間件系統(tǒng)遞送的數(shù)據(jù)或者發(fā)送將被 遞送到該中間件系統(tǒng)的數(shù)據(jù)。中間件體系結(jié)構(gòu)邊界內(nèi)部的API是一種客 戶；并且外部客戶是不使用該API的任何發(fā)布/訂購系統(tǒng)(或者外部數(shù)據(jù)目的地)，并且為了與之通信，消息要通過協(xié)議變換(稍后將描述)。術(shù)語"外部數(shù)據(jù)源"可以用在數(shù)據(jù)分發(fā)和消息發(fā)布/訂購系統(tǒng)的上下文 中。在一個示例中，外部數(shù)據(jù)源被認(rèn)為是位于企業(yè)專用網(wǎng)絡(luò)內(nèi)或者外部的 系統(tǒng)或應(yīng)用，其采用常用協(xié)議之一或者其自己的消息協(xié)議發(fā)布消息。外部 數(shù)據(jù)源的一個示例是市場數(shù)據(jù)交換，其發(fā)布股市報價，股市報價經(jīng)由中間 件系統(tǒng)被分發(fā)到交易員。外部數(shù)據(jù)源的另一個示例是事務(wù)性數(shù)據(jù)。注意， 在后面將更詳細(xì)描述的本發(fā)明的典型實現(xiàn)方式中，中間件體系結(jié)構(gòu)采用其 唯一的本地協(xié)議，來自外部數(shù)據(jù)源的數(shù)據(jù)一旦進(jìn)入該中間件系統(tǒng)域就被轉(zhuǎn) 換成該唯一的本地協(xié)議，從而避免了傳統(tǒng)系統(tǒng)中典型的多協(xié)議變換。術(shù)語"外部數(shù)據(jù)目的地"也用在數(shù)據(jù)分發(fā)和消息發(fā)布/訂購系統(tǒng)的上下 文中。例如，外部數(shù)據(jù)目的地是位于企業(yè)專用網(wǎng)絡(luò)內(nèi)或外部的系統(tǒng)或應(yīng) 用，其訂購經(jīng)由本地/全局網(wǎng)絡(luò)被路由的信息。外部數(shù)據(jù)目的地的一個示例 可以是對由交易員發(fā)布的事務(wù)訂單進(jìn)行處理的前述市場數(shù)據(jù)交換。外部數(shù) 據(jù)目的地的另一個示例是事務(wù)性數(shù)據(jù)。注意，在前述中間件體系結(jié)構(gòu)中， 去往外部數(shù)據(jù)目的地的消息從本地協(xié)議被翻譯成與該外部數(shù)據(jù)目的地相關(guān) 聯(lián)的外部協(xié)議。術(shù)語"總線"通常被用來描述互連，并且其可以是基于硬件或軟件的互連。例如，術(shù)語總線可被用來描述諸如使用套接字和共享存儲器的進(jìn)程 間通信鏈路，并且其還可被用來描述諸如函數(shù)調(diào)用這樣的進(jìn)程內(nèi)鏈接。從 這里的描述可以確認(rèn)，可以利用在中間件體系結(jié)構(gòu)中以各種配置實現(xiàn)的智 能消息傳遞應(yīng)用編程接口 (此后稱為"API")以各種方式實施本發(fā)明。 描述因此以圖1所示的端到端中間件體系結(jié)構(gòu)的示例開始。這種示例性體系結(jié)構(gòu)組合了許多有益特征，這些有益特征包括消息 傳遞公共概念、API、容錯、設(shè)置和管理(P&M)、服務(wù)質(zhì)量(QoS-合并 的，盡力而為的、有保證同時連接的、有保證同時不連接的，等等)、有保證遞送QoS的持久緩存、命名空間和安全性服務(wù)的管理、發(fā)布/訂購生態(tài)系統(tǒng)(核心、入口和出口組件)、傳輸透明的消息傳遞、基于鄰居的消 息傳遞(一種作為輪軸輪輻、對等和存儲轉(zhuǎn)發(fā)之間的混合體的模型，該模 型使用基于訂購的路由選擇協(xié)議，可以在必要時將訂購傳播到所有鄰 居)、遲計劃綁定、部分發(fā)布(與所有數(shù)據(jù)相對，僅發(fā)布改變的信息)和 動態(tài)分配網(wǎng)絡(luò)和系統(tǒng)資源。后面將說明，發(fā)布/訂購中間件系統(tǒng)有益地結(jié)合 了中間件體系結(jié)構(gòu)的容錯設(shè)計。在每個發(fā)布/訂購生態(tài)系統(tǒng)中，存在至少一個或多個(通常是兩個或更多個)消息傳遞設(shè)備(MA)，其中每個消息 傳遞設(shè)備被配置為充當(dāng)邊沿(出口/入口) MA或核心MA。注意，發(fā)布/訂 購生態(tài)系統(tǒng)的核心MA部分使用前述本地消息傳輸協(xié)議(對于中間件系統(tǒng) 本地的)，而入口和出口部分，邊沿MA則分別向該本地協(xié)議翻譯或者從 該本地協(xié)議翻譯。除了發(fā)布/訂購系統(tǒng)組件之外，圖1的圖還示出了它們之間的邏輯連接 和通信。從圖可見，所示的中間件體系結(jié)構(gòu)是分布式系統(tǒng)的中間件體系結(jié) 構(gòu)。在具有這種體系結(jié)構(gòu)的系統(tǒng)中，兩個截然不同的物理組件之間的邏輯 通信是利用消息流和相關(guān)聯(lián)的消息協(xié)議建立起來的。消息流包含兩類消息 之一管理和數(shù)據(jù)消息。管理消息用于管理和控制不同的物理組件、管理 對數(shù)據(jù)的訂購，等等。數(shù)據(jù)消息用于在源和目的地之間傳輸數(shù)據(jù)，并且在 典型的發(fā)布/訂購消息傳遞中，存在數(shù)據(jù)消息的多個發(fā)送者和多個接收者。利用所示結(jié)構(gòu)配置和邏輯通信，該具有發(fā)布/訂購中間件體系結(jié)構(gòu)的分 布式消息傳遞系統(tǒng)被設(shè)計來執(zhí)行多種邏輯功能。 一種邏輯功能是消息協(xié)議翻譯，該功能有利地在邊沿消息傳遞設(shè)備(MA)組件處執(zhí)行。這是因為 發(fā)布/訂購中間件系統(tǒng)的邊界內(nèi)的通信是利用針對消息的本地協(xié)議獨立于下 層傳輸邏輯被執(zhí)行的。這就是將這種體系結(jié)構(gòu)稱為傳輸透明基于信道的消 息傳遞體系結(jié)構(gòu)的原因。第二種邏輯功能是將消息從發(fā)布者路由到訂購者。注意，這些消息被 路由過整個發(fā)布/訂購網(wǎng)絡(luò)。因此，路由選擇功能由其中傳播消息的每個MA執(zhí)行，即，從邊沿MA106a-b (或者API)到核心MA108a-c，從一個 核心MA到另一個核心MA，最終到達(dá)邊沿MA (例如，106b)或者API 110a-b。 API 110a-b經(jīng)由進(jìn)程間通信總線(套接字、共享存儲器等)或經(jīng) 由諸如函數(shù)調(diào)用這樣的進(jìn)程內(nèi)通信總線與應(yīng)用112^通信，以發(fā)布和訂購 消息。第三種邏輯功能是針對不同類型的有保證的遞送服務(wù)質(zhì)量存儲消息， 包括例如有保證同時連接的和有保證同時不連接的。這是通過添加存儲轉(zhuǎn) 發(fā)功能來實現(xiàn)的。第四種功能是將這些消息遞送到訂購者。(如圖所示，API 106a-b將 消息遞送到訂購應(yīng)用112^)。在這種發(fā)布/訂購中間件體系結(jié)構(gòu)中，系統(tǒng)配置功能以及其他管理和系 統(tǒng)性能監(jiān)控功能由P&M系統(tǒng)管理。配置涉及發(fā)布/訂購中間件系統(tǒng)網(wǎng)絡(luò)和 組件的物理和邏輯配置。監(jiān)控和報告涉及對所有網(wǎng)絡(luò)和系統(tǒng)組件的健康進(jìn) 行監(jiān)控并且自動報告結(jié)果，這是按照每個要求進(jìn)行的或者被記入日志。 P&M系統(tǒng)利用管理消息執(zhí)行其配置、監(jiān)控和報告功能。另外，P&M系統(tǒng) 允許系統(tǒng)管理員定義與被路由遍該發(fā)布/訂購系統(tǒng)的每個消息相關(guān)聯(lián)的消息 命名空間。因此，發(fā)布/訂購網(wǎng)絡(luò)可以物理地和/或邏輯地被劃分成基于命 名空間的子網(wǎng)絡(luò)。P&M系統(tǒng)管理具有一個或多個MA的發(fā)布/訂購中間件系統(tǒng)。這些 MA取決于它們在系統(tǒng)中的角色被布署為邊沿MA或者核心MA。邊沿 MA在大多方面與核心MA類似，除了其包括協(xié)議翻譯引擎之外，協(xié)議翻 譯引擎將消息從外部協(xié)議翻譯成本地協(xié)議和從本地協(xié)議翻譯成外部協(xié)議。 因此， 一般來說，消息傳遞系統(tǒng)中發(fā)布/訂購中間件體系結(jié)構(gòu)的邊界(即，端到端發(fā)布/訂購中間件系統(tǒng)邊界)由其中存在邊沿MA 106a-b和API 110a-b的邊沿表征；并且在這些邊界內(nèi)，存在核心MA108a-c。注意，系統(tǒng)體系結(jié)構(gòu)不被限制到特定的受限的地理區(qū)域，并且實際 上，系統(tǒng)體系結(jié)構(gòu)被設(shè)計為超越區(qū)域或國家邊界，甚至跨越大洲。在這種 情形中， 一個網(wǎng)絡(luò)中的邊沿MA可以經(jīng)由現(xiàn)有的聯(lián)網(wǎng)基礎(chǔ)設(shè)施與地理上遠(yuǎn) 離的另一個網(wǎng)絡(luò)中的邊沿MA通信。在典型的系統(tǒng)中，核心MA 108a-c將在該發(fā)布/訂購中間件系統(tǒng)內(nèi)部發(fā) 布的消息路由向邊沿MA或API (例如，API 110a-b)。尤其是在核心 MA中的路由選擇圖被設(shè)計為用于最大量、低等待時間并且高效的路由選 擇。此外，核心MA之間的路由選擇可以實時動態(tài)改變。對于穿過多個節(jié) 點(核心MA)的給定的消息傳遞路徑，路由選擇的實時改變是基于一個 或多個度量的，這些度量包括網(wǎng)絡(luò)利用、總的端到端等待時間、通信量、 網(wǎng)絡(luò)和/或消息延遲、丟失和抖動?；蛘?，不是從兩條或多條不同的路徑中動態(tài)選擇最佳執(zhí)行路徑，而是 MA可以基于消息復(fù)制執(zhí)行多路徑路由選擇，并且從而通過所有路徑發(fā)送 相同的消息。位于不同路徑的匯聚點處的所有MA將丟棄復(fù)制的消息，僅 轉(zhuǎn)發(fā)第一個到達(dá)的消息。這種路由選擇方法具有使消息傳遞基礎(chǔ)設(shè)施針對 低等待時間被最優(yōu)化的優(yōu)點；但是這種路由選擇的缺點是基礎(chǔ)設(shè)施需要更 多的網(wǎng)絡(luò)帶寬來傳送復(fù)制的流量。邊沿MA具有這樣的能力將進(jìn)入消息的任何外部消息協(xié)議轉(zhuǎn)換成中 間件系統(tǒng)的本地消息協(xié)議；以及從本地消息協(xié)議轉(zhuǎn)換成外出消息的外部協(xié) 議。即，在消息進(jìn)入發(fā)布/訂購網(wǎng)絡(luò)域(入口)時，外部協(xié)議被轉(zhuǎn)換成本地 (例如，Tervela )消息協(xié)議；并且在消息離開發(fā)布/訂購網(wǎng)絡(luò)域(出口) 時，本地協(xié)議被轉(zhuǎn)換成外部協(xié)議。邊沿MA還操作用于將已發(fā)布的消息遞 送到訂購的外部數(shù)據(jù)目的地。另外，邊沿和核心MA 106a-b和108a-c都能夠在轉(zhuǎn)發(fā)消息之前存儲消 息?？梢詫崿F(xiàn)該功能的一種方法是利用緩存引擎(CE) 118a-b。 一個或多 個CE可以被連接到相同的MA。理論上，不認(rèn)為API具有這種存儲轉(zhuǎn)發(fā) 能力，盡管實際上API 110a-b可以在將消息遞送到應(yīng)用之前存儲消息，并14且其可以在將從應(yīng)用接收到的(即由應(yīng)用發(fā)布的)消息遞送到核心MA、邊沿MA或者另一個API之前存儲它們。在MA (邊沿或核心MA)具有到CE的活動連接時，其將被路由的 消息的全部或者子集轉(zhuǎn)發(fā)到CE， CE將它們寫到存儲區(qū)域中以實現(xiàn)持久 性。在預(yù)定時間段中，這些消息然后可在被請求時用于重傳。其中實現(xiàn)了 這種特征的示例有數(shù)據(jù)中繼、部分發(fā)布和各種服務(wù)質(zhì)量級別。部分發(fā)布在 減少網(wǎng)絡(luò)和客戶負(fù)載方面是有效的，因為其要求僅發(fā)送更新的信息，而不 是所有信息。為了說明路由選擇圖可能如何實現(xiàn)路由選擇，圖l中示出了發(fā)布/訂購 路由選擇路徑的數(shù)個示例。在該圖示中，發(fā)布/訂購網(wǎng)絡(luò)的中間件體系結(jié)構(gòu) 在發(fā)布者和訂購者之間提供了五條或更多的通信路徑。第一通信路徑將外部數(shù)據(jù)源鏈接到外部數(shù)據(jù)目的地。從外部數(shù)據(jù)源 114^接收到的已發(fā)布消息被翻譯成本地(例如，Tervda )消息協(xié)議， 然后被邊沿MA 106a路由。本地協(xié)議消息可以從邊沿MA 106a被路由的 一條路線是到外部數(shù)據(jù)目的地116n。該路徑被稱作通信路徑la。在這種 情形中，本地協(xié)議消息被轉(zhuǎn)換成適于該外部數(shù)據(jù)目的地的外部協(xié)議消息。 本地協(xié)議消息可以從邊沿MA 106a被路由的另一條路線是內(nèi)部通過核心 MA 108b。該路徑被稱作通信路徑lb。沿著該路徑，核心MA 108b將本 地消息路由到邊沿MA 106a。但是，在邊沿MA106a將本地協(xié)議消息路由 到外部數(shù)據(jù)目的地116i之前，其將它們轉(zhuǎn)換成適于該外部數(shù)據(jù)目的地116, 的外部消息協(xié)議。可見，這種通信路徑不要求API將消息從發(fā)布者路由到 訂購者。因此，如果發(fā)布/訂購系統(tǒng)被用于外部源到目的地的通信，則該系 統(tǒng)無需包括API。被稱作通信路徑2的另一條通信路徑利用API 110b將外部數(shù)據(jù)源 114n鏈接到一個應(yīng)用。從外部數(shù)據(jù)源接收到的已發(fā)布的消息在邊沿MA 106a處被翻譯成本地消息協(xié)議，然后被該邊沿MA路由到核心MA 108。 從第一核心MA 108a出發(fā)，這些消息被路由過另一個核心MA 108c到達(dá) API llOb。從該API出發(fā)，這些消息被遞送到訂購應(yīng)用(例如，1122)。 因為該通信路徑是雙向的，所以在另一個實例中，消息可以沿著反向路徑從訂購應(yīng)用112^到達(dá)外部數(shù)據(jù)目的地116n。在每個實例中，核心MA接 收本地協(xié)議消息并且路由本地協(xié)議消息，而邊沿MA接收外部或者本地協(xié) 議消息，并且分別路由本地或外部協(xié)議消息(邊沿MA將這種外部消息協(xié) 議翻譯成本地消息協(xié)議/從本地消息協(xié)議翻譯成這種外部消息協(xié)議)。每個 邊沿MA可以將入口消息同時路由到本地協(xié)議信道和外部協(xié)議信道兩者， 不管該入口消息是作為本地協(xié)議消息還是作為外部協(xié)議消息到來的。結(jié) 果，每個邊沿MA可以將入口消息同時路由到外部和內(nèi)部客戶，其中內(nèi)部 客戶消耗本地協(xié)議消息，而外部客戶消耗外部協(xié)議消息。這種能力使得消 息傳遞基礎(chǔ)設(shè)施能夠與遺留應(yīng)用和系統(tǒng)無縫并且平滑地集成。被稱作通信路徑3的另一條通信路徑鏈接兩個應(yīng)用，這兩個應(yīng)用都利 用API 110a-b。這些應(yīng)用中的至少一個發(fā)布消息或者訂購消息。已發(fā)布的 消息到訂購應(yīng)用的遞送或者來自發(fā)布應(yīng)用的已發(fā)布消息的遞送是利用位于 發(fā)布/訂購網(wǎng)絡(luò)邊沿的API實現(xiàn)的。在應(yīng)用訂購消息時，核心或者邊沿MA 之一將消息路由向該API，該API然后在數(shù)據(jù)正準(zhǔn)備被遞送到它們時通知 訂購應(yīng)用。從應(yīng)用發(fā)布的消息經(jīng)由該API被發(fā)送到該API被"注冊"到其 的核心MA 108c。注意，通過"注冊"(登錄)到一個MA，該API變?yōu)樵谶壿嬌线B接 到該MA。 API通過發(fā)送注冊("登錄"請求)消息到MA來發(fā)起到該 MA的連接。在注冊之后，該API可以通過將其訂購消息發(fā)送到該MA來 訂購特定的感興趣的話題。話題被用于發(fā)布/訂購消息傳遞，來定義共享的 訪問域和消息的目標(biāo)，因此，訂購一個或多個話題允許接收和發(fā)送具有這 種話題注釋的消息。P&M將周期授權(quán)更新發(fā)送到網(wǎng)絡(luò)中的MA，每個M八 相應(yīng)地更新其自己的表格。因此，如果發(fā)現(xiàn)API要被授權(quán)來訂購特定的話 題(該MA利用路由選擇授權(quán)表來驗證該API的授權(quán))，則該MA激活到 該API的邏輯連接。然后，如果該API被適當(dāng)?shù)刈缘胶诵腗A 108c，則 核心MA 108c將數(shù)據(jù)路由到第二 API 110，如圖所示。在其他示例中，該 核心MA 108b可以通過額外的一個或多個核心MA (未示出)路由消息， 這一個或多個核心MA將消息路由到API llOb， AP 110b然后將消息遞送 到訂購應(yīng)用112^?？梢姡ㄐ怕窂?不要求存在邊沿MA，因為其不涉及任何外部數(shù)據(jù) 消息協(xié)議。在一個對這里通信路徑給出示例的實施例中，企業(yè)系統(tǒng)被配置 有新聞服務(wù)器，該新聞服務(wù)器向雇員發(fā)布關(guān)于多種話題的最新新聞。為了 接收到新聞，雇員經(jīng)由利用API的新聞瀏覽器應(yīng)用訂購它們感興趣的話 題。注意，中間件體系結(jié)構(gòu)允許訂購一個或多個話題。此外，這種體系結(jié) 構(gòu)通過允許消息注釋中的通配符，從而利用單個訂購請求訂購一組相關(guān)的 話題。被稱作通信路徑4的又一條通信路徑是與P&M系統(tǒng)102和104相關(guān) 聯(lián)的多條路徑之一，這些路徑中的每條將P&M鏈接到發(fā)布/訂購網(wǎng)絡(luò)中間 件體系結(jié)構(gòu)中的MA之一。在P&M系統(tǒng)和每個MA之間往返的消息是管 理消息，管理消息用于對該MA進(jìn)行配置和監(jiān)控。在一種系統(tǒng)配置中， P&M系統(tǒng)直接與MA通信。在另一種系統(tǒng)配置中，P&M系統(tǒng)通過其他 MA與一些MA通信。在又一種配置中，P&M系統(tǒng)可以直接或者間接與 MA通信。在典型的實現(xiàn)方式中，中間件體系結(jié)構(gòu)可以被布署在網(wǎng)絡(luò)上，該網(wǎng)絡(luò) 具有交換機、路由器和其他聯(lián)網(wǎng)設(shè)備，并且其采用基于信道的消息傳遞， 該消息傳遞能夠通過任何類型的物理介質(zhì)通信。這種架構(gòu)不可知的基于信 道的消息傳遞的一種示例性實現(xiàn)方式是基于IP的網(wǎng)絡(luò)。在這種環(huán)境中，所 有發(fā)布/訂購物理組件之間的所有通信都通過UDP (數(shù)據(jù)報協(xié)議)執(zhí)行， 并且傳輸可靠性由消息傳輸層實現(xiàn)。圖la示出了根據(jù)本原理的覆蓋網(wǎng)絡(luò)。如圖所示，覆蓋通信l、 2和3可以經(jīng)由交換機214a-c、路由器216和 子網(wǎng)218a-c在三個核心MA 208a-c之間發(fā)生。換言之，這些通信路徑可以 建立在下層中間件網(wǎng)絡(luò)之上，所述下層網(wǎng)絡(luò)包括聯(lián)網(wǎng)基礎(chǔ)設(shè)施，例如子 網(wǎng)、交換機和路由器，并且如上所述，這種體系結(jié)構(gòu)可以跨越較大的地理 區(qū)域(不同的國家甚至不同的大洲)。很明顯，根據(jù)本發(fā)明原理的前述和其他端到端中間件體系結(jié)構(gòu)可以被 實現(xiàn)在各種商業(yè)環(huán)境中的各種企業(yè)基礎(chǔ)設(shè)施中。圖2示出了一種這樣的實 現(xiàn)方式。在該企業(yè)基礎(chǔ)設(shè)施中，市場數(shù)據(jù)分發(fā)工廠12被構(gòu)建在發(fā)布/訂購網(wǎng)絡(luò) 之上，該發(fā)布/訂購網(wǎng)絡(luò)用于將來自各個市場數(shù)據(jù)交換設(shè)備320^的股票市 場報價路由到交易員(未示出的應(yīng)用)。這種覆蓋解決方案依賴于下層網(wǎng)絡(luò)提供例如MA之間和這種MA和P&M系統(tǒng)之間的互連。到API 310^的 市場數(shù)據(jù)遞送是基于應(yīng)用訂購的。利用這種基礎(chǔ)設(shè)施，利用應(yīng)用(未示 出)的交易員將來自API 310&的交易單通過發(fā)布/訂購網(wǎng)絡(luò)(經(jīng)由核心 MA308 a-b和邊沿MA 306b)放置回市場數(shù)據(jù)交換設(shè)備320^。圖2a中示出了下層物理布署的一個示例。如圖所示，MA被直接彼此 連接，并且被直接插入到網(wǎng)絡(luò)和子網(wǎng)，在網(wǎng)絡(luò)和子網(wǎng)中消息傳遞流量的客 戶和發(fā)布者被物理連接。在這種情形中，互連應(yīng)當(dāng)是直接連接，即，MA 之間的直接連接和它們與P&M系統(tǒng)之間的直接連接。這使得能夠?qū)崿F(xiàn)網(wǎng) 絡(luò)骨干網(wǎng)非居間化，以及消息傳遞流量與其他企業(yè)應(yīng)用流量物理分離。有 效地，MA可以被用來移除對用于消息傳遞流量的傳統(tǒng)路由網(wǎng)絡(luò)的依賴。在物理布署的這種示例中，諸如市場數(shù)據(jù)交換設(shè)備之類的外部數(shù)據(jù)源 或者目的地被直接連接到邊沿MA，例如，邊沿MA 1。諸如市場交易應(yīng) 用之類的消息傳遞流量消耗或發(fā)布應(yīng)用被直接連接到子網(wǎng)1-12。這些應(yīng)用 具有至少兩條路線，用于訂購、發(fā)布或者與其他應(yīng)用通信；它們可以或者 利用企業(yè)骨干網(wǎng)或者利用消息傳遞骨干網(wǎng)，其中企業(yè)骨干網(wǎng)包括多層冗余 的路由器和交換機，它們傳送所有的企業(yè)應(yīng)用流量，包括但不限于，消息 傳遞流量；消息傳遞骨干網(wǎng)包括經(jīng)由集成交換機彼此直接互連的邊沿和核 心MA。利用替換骨干網(wǎng)具有這樣的優(yōu)點將消息傳遞流量與其他企業(yè)應(yīng)用流量隔離，從而更好地控制消息傳遞流量的性能。在一種實現(xiàn)方式中，位于子網(wǎng)6中的應(yīng)用邏輯上或者物理上連接到核心MA 3，利用Tervela API訂 購或者發(fā)布本地協(xié)議的消息流量。在另一種實現(xiàn)方式中，位于子網(wǎng)7中的 應(yīng)用邏輯上或者物理上連接到邊沿MA 1，訂購或者發(fā)布外部協(xié)議的消息 傳遞流量，其中該MA利用集成的協(xié)議變換引擎模塊執(zhí)行協(xié)議變換。邏輯 上，發(fā)布/訂購網(wǎng)絡(luò)的物理組件被構(gòu)建在類似于開放系統(tǒng)互連(OSI)參考 模型的1到4層的消息傳輸層之上。OSI模型的1到4層分別是物理層、輸層。因此，在本發(fā)明的一個實施例中，發(fā)布/訂購網(wǎng)絡(luò)通過例如在所有網(wǎng)絡(luò) 交換機和路由器或者網(wǎng)絡(luò)交換機和路由器的子集中插入一個或多個消息傳 遞線路卡，從而可以被直接布署到下層網(wǎng)絡(luò)/構(gòu)架中。在本發(fā)明的另一個實 施例中，發(fā)布/訂購網(wǎng)絡(luò)可以作為網(wǎng)狀覆蓋網(wǎng)絡(luò)(其中，所有物理組件都被 彼此連接)而被有效地布署。例如，4個MA的完全網(wǎng)狀網(wǎng)絡(luò)是這樣的網(wǎng)絡(luò)，其中，每個MA被連接到其3個對等MA中的每個。在典型實現(xiàn)方式中，發(fā)布/訂購網(wǎng)絡(luò)是下述組件的網(wǎng)狀網(wǎng)絡(luò) 一個或多個外部數(shù)據(jù)源和/或目的地、 一個或多個設(shè)置和管理(P&M)系統(tǒng)、 一個或多個消息傳遞設(shè)備 (MA)、 一個或多個可選緩存引擎(CE)，以及一個或多個可選應(yīng)用編 程接口 (API)。如前所述，每個發(fā)布/訂購中間件系統(tǒng)的邊界內(nèi)的通信是獨立于下層傳 輸邏輯利用針對消息的本地協(xié)議來執(zhí)行的。這就是將這種體系結(jié)構(gòu)稱作傳 輸透明基于信道的消息傳遞體系結(jié)構(gòu)的原因。圖3更詳細(xì)地示出了基于信道的消息傳遞體系結(jié)構(gòu)320。 一般而言， 消息傳遞源和目的地之間的每條通信路徑被限定為一條消息傳遞信道。每 條信道326^利用信道源和信道目的地之間的接口 328^通過物理介質(zhì)建 立。每條這樣的信道是針對專門的消息協(xié)議建立的，所述消息協(xié)議例如是 本地(例如，Tervela )消息協(xié)議或其他。僅邊沿MA (對發(fā)布/訂購網(wǎng)絡(luò) 的入口和出口進(jìn)行管理的那些MA)利用信道消息協(xié)議(外部消息協(xié) 議)。基于信道消息協(xié)議，信道管理層324確定進(jìn)入和外出消息是否要求 協(xié)議翻譯。在每個邊沿MA處，如果進(jìn)入消息的信道消息協(xié)議不同于本地 協(xié)議，則信道管理層324將在將要處理的消息傳遞到本地消息層330之 前，通過將它們發(fā)送過協(xié)議翻譯引擎(PTE) 332，從而執(zhí)行協(xié)議翻譯。同 樣，在每個邊沿MA處，如果外出消息的本地消息協(xié)議不同于信道消息協(xié) 議(外部消息協(xié)議)，則信道管理層324將在將要處理的消息路由到傳輸 信道3261-n之前，將它們發(fā)送過協(xié)議翻譯引擎(PTE) 332，從而執(zhí)行協(xié) 議翻譯。從而，信道對與物理介質(zhì)的接口 3281-n、與該物理介質(zhì)相關(guān)聯(lián)的 特定網(wǎng)絡(luò)和傳輸邏輯、以及消息組件或者片段進(jìn)行管理。19換言之，信道管理OSI傳輸層322。對信道資源的優(yōu)化基于每條信道 被執(zhí)行(例如，基于消耗模式對物理介質(zhì)的消息密度優(yōu)化，所述消耗模式 包括帶寬、消息大小分布、信道目的地資源和信道健康統(tǒng)計)。然后，因 為通信信道是構(gòu)架不可知的，所以不要求特定類型的構(gòu)架。實際上，任何構(gòu)架介質(zhì)都將工作，例如，ATM、 Infmiband或者以太網(wǎng)。順便提及，在例如單個消息被分割到多個幀或者多個消息被打包到單 個幀中時，可能需要消息分段或重組。消息分段或重組在消息被遞送到信 道管理層之前被執(zhí)行。圖3進(jìn)一步示出了在具有中間件體系結(jié)構(gòu)的網(wǎng)絡(luò)中的多種可能的信道 實現(xiàn)方式。在一種實現(xiàn)方式340中，通信是利用通過太網(wǎng)交換的網(wǎng)絡(luò)的多 播，經(jīng)由基于網(wǎng)絡(luò)的信道執(zhí)行的，其中以太網(wǎng)交換的網(wǎng)絡(luò)充當(dāng)用于這種通 信的物理介質(zhì)。在這種實現(xiàn)方式中，源從其IP地址經(jīng)由其UDP端口將消 息發(fā)送向具有在其關(guān)聯(lián)的IP地址上的各個UDP端口的目的地群組(因此 是多播)。在這種實現(xiàn)方式的變體342中，源和目的地之間的通信是利用 UDP單播通過以太網(wǎng)交換的網(wǎng)絡(luò)實現(xiàn)的。源從其IP地址經(jīng)由其UDP端口 將消息發(fā)送向在其相應(yīng)的IP地址處具有UDP端口的選擇目的地。在另一種實現(xiàn)方式344中，信道是利用本地Infmiband傳輸協(xié)議通過 Infmiband互連建立的，其中Infiniband架構(gòu)是物理介質(zhì)。在這種實現(xiàn)方式 中，信道是基于節(jié)點的，并且源和目的地之間的通信是利用它們各自的節(jié) 點地址基于節(jié)點的。在又一種實現(xiàn)方式346中，信道是基于存儲器的，例 如RDMA (遠(yuǎn)程直接存儲器訪問)，并且在這里被稱作直接連接 (DC)。利用這種類型的信道，消息從源機器被直接發(fā)送到目的地機器的 存儲器，從而繞過CPU處理來應(yīng)對從NIC到應(yīng)用存儲器空間的消息，并 且可能避免了將消息封裝成網(wǎng)絡(luò)分組的網(wǎng)絡(luò)開銷。至于本地協(xié)議， 一種方法利用前述本地TervelaTM消息協(xié)議。概念上， TervdaTM消息協(xié)議與基于IP的協(xié)議類似。每個消息包含消息頭部和消息 有效載荷。消息頭部包含多個字段，其中一個字段用于話題信息，所述話 題信息指示由客戶用來訂購共享的信息域的話題。圖4示出了一個可能的基于話題的消息格式。如圖所示，消息包括頭部370和主體372和374，主體372和374包括有效載荷。示出了兩類消 息，即，數(shù)據(jù)和管理消息，這兩類消息具有不同的消息體和有效載荷類型。頭部包括用于以下內(nèi)容的字段源和目的地命名空間標(biāo)識、源和目的地會話標(biāo)識、話題序列號和希望時間戳，另外，其還包括話題注釋字段 (該字段優(yōu)選是可變長度的)。話題可以被定義為基于標(biāo)記的字符串，例如，NYSE.RTF.IBM 376，該字符串是包含IBM股票實時報價的消息的話 題字符串。在一個實現(xiàn)方式中，消息中的話題信息可能被編碼或者被映射到一個 關(guān)鍵字，關(guān)鍵字可以是一個或多個整數(shù)值。然后，每個話題會被映射到一 個唯一的關(guān)鍵字，并且話題和關(guān)鍵字之間的映射數(shù)據(jù)庫將由P&M系統(tǒng)維 護，并且通過線路被更新到所有MA。結(jié)果，在API訂購或者發(fā)布一個話 題時，MA能夠返回用于消息的話題字段的關(guān)聯(lián)的唯一關(guān)鍵字。優(yōu)選地，訂購格式將遵循與消息話題相同的格式。但是，訂購格式還 支持與任何話題子字符串匹配的通配符以及與話題子字符串匹配的正則表 達(dá)式模式。通配符到實際話題的映射可以依賴于P&M系統(tǒng)，或者根據(jù)通 配符或模式匹配請求的復(fù)雜度由MA處理。例如，模式匹配可以遵循例如以下規(guī)則示例弁1:具有通配符T1.承.T3.T4的字符串將與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹酉己，(i是不與T1.T2.T3.T4.T5匹酉己示例#2:具有通配符T1AT3.T4，的字符串將不與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹酉己，{旦是與T1.T2.T3.T4.T5匹配示例#3:具有通配符T1.*.T3.T4.[*](第五個元素可選)的字符串將與 Tl.T2a.T3.T4、 Tl.T2b.T3.T4 、以及T1.T2.T3.T4.T5匹酉己，{S是不與 T1.T2.T3.T4.T5.T6匹配示例#4:具有通配符T1.T2承.T3.T4的字符串將與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹酉己，f旦是不與Tl.T5a.T3.T4匹酉己示例#5:具有通配符T1.*.T3.T4> (任何數(shù)目的結(jié)尾元素)的字符串 將與Tl.T2a.T3.T4、 Tl.T2b.T3.T4、 T1.T2.T3.T4.T5和T1.T2.T3.T4.T5.T6 匹配21圖5示出了基于話題的消息路由選擇，其中話題通常被定義為基于標(biāo)記(token)的字符串，例如，T1.T2.T3.T4，其中Tl、 T2、 T3禾口 T4是可變長度的字符串?？梢?，具有特定話題注釋400的進(jìn)入消息被有選擇地路 由到通信信道404，并且路由選擇確定是基于路由選擇表402作出的。話 題訂購到信道的映射定義路由，并且用來將消息傳遞遍整個發(fā)布/訂購網(wǎng) 絡(luò)。所有這些路由或者說訂購和信道之間的映射的超集定義路由選擇表。 路由選擇表也被稱作訂購表。用于利用基于字符串的話題進(jìn)行路由選擇的 訂購表可以以多種方式被構(gòu)造，但是優(yōu)選配置為對其大小以及路由選擇查 找速度進(jìn)行優(yōu)化。在一種實現(xiàn)方式中，訂購表可以被定義為動態(tài)散列圖結(jié) 構(gòu)，而在另一種實現(xiàn)方式中，訂購表可以被布置在樹結(jié)構(gòu)中，如圖5中的 圖所示。樹包括由邊連接的節(jié)點(例如，T,、…、T1Q)，其中話題訂購的每個 子字符串對應(yīng)于樹中的一個節(jié)點。映射到給定的訂購的信道被存儲在訂購 的葉子節(jié)點上，每個葉子節(jié)點指示該話題訂購來自的信道的列表(即，通 過其接收到訂購請求)。該列表指示哪個信道應(yīng)接收其話題注釋與該訂購 匹配的消息的拷貝。如圖所示，消息路由選擇查找將消息話題作為輸入， 然后利用該話題的每個子字符串對樹進(jìn)行解析，來定位與進(jìn)入消息話題相 關(guān)聯(lián)的不同信道。例如，Tp T2， T3， T4和T5被導(dǎo)向信道1、 2和3; TV、 丁2和T3被導(dǎo)向信道4; T" T6、 T7、 丁*和丁9被導(dǎo)向信道4和5; T\， T6， T7， Ts和T9被導(dǎo)向信道l;以及TV T6、 T7、 L和Tu)被導(dǎo)向信道5。盡管對路由選擇表的結(jié)構(gòu)的選擇是要對路由選擇表的査找進(jìn)行優(yōu)化， 但是查找的性能還取決于用于找到與進(jìn)入消息話題匹配的一個或多個話題 訂購的搜索算法。因此，路由選擇表結(jié)構(gòu)應(yīng)當(dāng)能夠適應(yīng)這種算法，反之亦 然。減小路由選擇表的大小的一種方式是允許路由選擇算法有選擇地將訂 購傳播遍整個發(fā)布/訂購網(wǎng)絡(luò)。例如，如果訂購看來是已被傳播的另一個訂 購的子集(例如，整個字符串的一部分)，則無需傳播該子集訂購，因為 MA已具有該訂購的超集的信息?；谇笆?，優(yōu)選的消息路由選擇協(xié)議是基于話題的路由選擇協(xié)議，其 中授權(quán)在訂戶和相應(yīng)的話題之間的映射中指示出。授權(quán)是針對每個訂戶指定的，指示該訂購有權(quán)消耗何種消息或者該發(fā)布者可以產(chǎn)生(發(fā)布)哪些 消息。這些授權(quán)是在P&M機器中定義的，被傳輸?shù)桨l(fā)布/訂購網(wǎng)絡(luò)中的所有MA，然后被MA用來創(chuàng)建和更新它們的路由選擇表。每個MA通過追蹤何人被插入(請求訂購)到何種消息中來更新其路 由選擇表。但是，在將路由添加到其路由選擇表之前，MA必須針對發(fā)布/ 訂購網(wǎng)絡(luò)的授權(quán)對訂購進(jìn)行檢查。MA驗證可能是鄰居MA、 P&M系統(tǒng)、 CE或者API的訂購實體被授權(quán)如此執(zhí)行。如果該訂購是有效的，則路由 將被創(chuàng)建并且被添加到路由選擇表。然后，因為一些授權(quán)可能是預(yù)先已知 的，所以系統(tǒng)可以被布署以預(yù)定義授權(quán)，并且在引導(dǎo)時這些授權(quán)可以被字 段加載。例如，諸如配置更新之類的一些特定管理消息可能總是被轉(zhuǎn)發(fā)遍 網(wǎng)絡(luò)，并且因此在啟動時被自動載入。在給出了對具有發(fā)布/訂購中間件體系結(jié)構(gòu)的消息傳遞系統(tǒng)的上述描述 的情況下，可以明白，在處理用于應(yīng)用的消息傳遞時，智能消息傳遞應(yīng)用 編程接口 (在此簡稱為API)在這種系統(tǒng)中具有重要的角色。應(yīng)用依賴于 API來進(jìn)行所有消息傳遞，包括進(jìn)行注冊、發(fā)布和訂購。注冊包括把管理 注冊請求發(fā)送到一個或多個MA，所述一個或多個MA確認(rèn)API和應(yīng)用的 授權(quán)以便進(jìn)行注冊。 一旦它們的注冊被確認(rèn)，則應(yīng)用可以訂購和發(fā)布關(guān)于 被授權(quán)的任何話題的信息。相應(yīng)地，我們現(xiàn)在轉(zhuǎn)向?qū)Ω鶕?jù)本發(fā)明的原理配 置的API的細(xì)節(jié)進(jìn)行描述。圖6是圖示了 API的框圖。在該圖示中，API是API通信引擎602和API存根(stub) 604的組 合。通信引擎602是通常所說的在操作系統(tǒng)下運行的用于處理計算機系統(tǒng) 希望接收的周期性服務(wù)請求的程序；但是在一些情況下，其被嵌入在應(yīng)用 本身當(dāng)中并因而是進(jìn)程內(nèi)通信總線。通信引擎程序?qū)⒄埱筠D(zhuǎn)發(fā)給其他合適 的程序(或進(jìn)程)。在這種情況下，API通信引擎起應(yīng)用與發(fā)布/訂購中間 件系統(tǒng)之間的網(wǎng)關(guān)的作用。如所指的，API通信引擎通過動態(tài)地選擇傳輸 協(xié)議和動態(tài)地調(diào)節(jié)單個幀中要封裝的消息的數(shù)目來管理與MA之間的應(yīng)用 通信。被封裝在單個幀中的消息的數(shù)目取決于多個因素，例如MA和API 主機中的消息速率和系統(tǒng)資源利用。應(yīng)用使用API存根604來與API通信引擎進(jìn)行通信。通常，使用遠(yuǎn)程過程調(diào)用(RPC)的應(yīng)用程序是用存根進(jìn)行編譯的，該存根用所請求的遠(yuǎn) 程過程來替換該程序。存根接受RPC并將其轉(zhuǎn)發(fā)給遠(yuǎn)程過程，遠(yuǎn)程過程在 完成時將結(jié)果返回存根，以將結(jié)果傳遞給進(jìn)行RPC的程序。在一些情況下，API存根與API通信引擎之間的通信是經(jīng)由進(jìn)程間通信總線完成的，所述進(jìn)程間通信總線是使用諸如套接字或共享存儲器這樣的機制來實現(xiàn)的。API存根可以用各種編程語言得到，這些編程語言包括C、 C++， Java 和.NET。 API本身可以用多種語言完整得到，并且其可以在不同的操作系 統(tǒng)上運行，包括微軟Windows , LinuxTM和Solaris 。API通信引擎602和API存根604被編譯并被鏈接到正在使用API的 所有應(yīng)用606。 API存根與API通信引擎之間的通信是經(jīng)由進(jìn)程間通信總 線608完成的，所述進(jìn)程間通信總線是使用諸如套接字或共享存儲器這樣 的機制來實現(xiàn)的。API存根604可以用各種編程語言得到，這些編程語言 包括C、 C++, Java禾口.NET。在一些情況下，API本身可以用多種語言得 到。API在不同的操作系統(tǒng)平臺上運行，其中的三個示例是Windows , LinuxT, Solaris 。API通信引擎被建立在諸如消息傳輸層610這樣的邏輯層上。和與物 理介質(zhì)接口直接交互的MA不同，API多數(shù)實現(xiàn)在操作系統(tǒng)之上并且其消 息傳輸層經(jīng)由OS進(jìn)行通信。為了支持不同類型的信道，OS對于其默認(rèn)不 支持的每種物理介質(zhì)可能需要特定的驅(qū)動程序。OS還可能要求用戶插入 特定的物理介質(zhì)卡。例如，諸如直接連接(DC)或Infiniband這樣的物理 介質(zhì)需要特定接口卡和其相關(guān)的OS驅(qū)動程序，以允許消息傳輸層在信道 上發(fā)送消息。API中的消息傳遞層612也有點類似于MA中的消息傳遞層。然而主 要差異在于進(jìn)入消息在API和MA中分別沿著不同的路徑前進(jìn)。在API 中，數(shù)據(jù)消息被發(fā)送到應(yīng)用遞送路由引擎614 (更少的模式約束)并且管 理消息被發(fā)送到管理消息層616。除了將應(yīng)用(606)映射到訂購而非將信 道映射到應(yīng)用之外，應(yīng)用遞送路由引擎的行為類似于消息路由選擇引擎 618。因此，當(dāng)進(jìn)入消息到達(dá)時，應(yīng)用遞送路由引擎查找所有的訂購應(yīng) 用，然后將該消息的副本或者對該消息的引用發(fā)送到所有這些訂購應(yīng)用。在一些實現(xiàn)中，應(yīng)用遞送路由引擎負(fù)責(zé)遲計劃綁定(late schema binding)特征。如前所述，本地(例如Tervda )消息傳遞協(xié)議以原始且 壓縮的格式提供信息，該格式不包含底層數(shù)據(jù)的結(jié)構(gòu)和定義。結(jié)果，消息 傳遞系統(tǒng)有利地減小其帶寬利用并從而允許增加的消息容量和吞吐量。當(dāng) API接收到數(shù)據(jù)消息時，API將原始數(shù)據(jù)綁定到其計劃，從而允許應(yīng)用透 明地訪問信息。計劃通過提供域名、域類型與域在消息主體中的偏移位置 之間的映射來定義消息的內(nèi)容結(jié)構(gòu)。因此，應(yīng)用可以請求特定域名而無需 知道該域在消息中的位置，并且API使用偏移來定位該信息并將其返回給 應(yīng)用。在一個實現(xiàn)中，當(dāng)應(yīng)用請求從/向MA進(jìn)行訂購或發(fā)布時，計劃是由 MA提供的。在很大程度上，外出消息遵循與MA中相同的輸出邏輯。的確，API 可以和MA —樣具有協(xié)議優(yōu)化服務(wù)(POS) 620。然而，發(fā)布/訂購中間件 系統(tǒng)是按照基于主從的配置用分布在MA與API通信引擎之間的POS來 進(jìn)行配置的。然而，與MA中自行決定何時改變信道配置的POS不同， API中的POS充當(dāng)其所鏈接到的MA中的主POS的從屬。主POS和從 POS都對系統(tǒng)和網(wǎng)絡(luò)資源隨時間消逝的消耗計劃進(jìn)行監(jiān)視。從POS把這些 資源消耗計劃的全部、子集或匯總傳送給主POS，并且主POS基于這些計 劃來確定如何把消息遞送給API通信引擎，包括通過選擇傳輸協(xié)議來把消 息遞送給API通信引擎。例如，從單播、多播或廣播消息傳輸協(xié)議當(dāng)中選 擇的傳輸協(xié)議對環(huán)境不總是適合。因此，當(dāng)MA上的POS決定改變信道配 置時，其遠(yuǎn)程地控制API處的從POS。在消息傳遞發(fā)布/訂購中間件系統(tǒng)中執(zhí)行其角色時，API優(yōu)選對應(yīng)用透 明，這是因為其使得用于處理應(yīng)用請求的系統(tǒng)資源利用最小化。在一種配 置中，API通過執(zhí)行零拷貝消息接收(即省略從網(wǎng)絡(luò)接收到的消息的應(yīng)用 存儲空間的拷貝)來優(yōu)化存儲器拷貝的數(shù)目。例如，API通信引擎將緩沖 (存儲空間)引入網(wǎng)絡(luò)接口卡，以將進(jìn)入消息直接寫入API通信引擎的存 儲空間。這些消息對應(yīng)用變得可經(jīng)由共享存儲器進(jìn)行訪問。類似地，API 執(zhí)行從應(yīng)用的存儲空間直接到網(wǎng)絡(luò)的零拷貝消息傳遞。在另一種配置中，API使得用于執(zhí)行消息接收和發(fā)送任務(wù)所需的CPU處理量減少。例如，API通信引擎執(zhí)行批量消息接收和發(fā)送任務(wù)，而不是 一次接收或發(fā)送一條消息，從而使CPU處理周期的數(shù)目減少。這種批量消 息傳輸經(jīng)常涉及消息隊列。因此，為了使端到端等待時間最小化，批量消 息傳輸需要把保持消息排隊的時間限制為小于可接受的等待時間閾值。為了保持上述的透明性，API對由應(yīng)用發(fā)布或訂購的消息進(jìn)行處理。 為了減少系統(tǒng)帶寬使用并從而增加系統(tǒng)吞吐量，以原始且壓縮的格式來傳送消息信息。因此，當(dāng)API接收到數(shù)據(jù)消息時，API將原始數(shù)據(jù)綁定到其計劃，從而允許應(yīng)用透明地訪問信息。計劃通過提供域名、域類型與域在 消息主體中的偏移位置之間的映射來定義消息的內(nèi)容結(jié)構(gòu)。結(jié)果，應(yīng)用可以請求特定域名而無需知道該域在消息中的位置，并且API使用偏移來定位該信息并將其返回給應(yīng)用。附帶提及，為了更有效地利用帶寬，應(yīng)用可 以訂購一話題，其中其請求僅接收來自消息流的更新后的信息。由于這種訂購，MA將新消息與先前遞送的消息進(jìn)行比較并且僅將更新發(fā)布給應(yīng) 用。另一種實現(xiàn)提供了在訂購應(yīng)用與API之間以預(yù)先商定的格式呈現(xiàn)接收 到的或發(fā)布的數(shù)據(jù)的能力。該內(nèi)容轉(zhuǎn)換是由呈現(xiàn)引擎執(zhí)行的并基于由應(yīng)用 提供的數(shù)據(jù)呈現(xiàn)格式。數(shù)據(jù)呈現(xiàn)格式可被定義為底層數(shù)據(jù)計劃與應(yīng)用數(shù)據(jù) 格式之間的映射。例如，應(yīng)用可以以XML格式發(fā)布和使用數(shù)據(jù)，API將 在該XML格式與底層消息格式之間來回進(jìn)行轉(zhuǎn)換。API還被設(shè)計用于實時信道優(yōu)化。具體地說，MA與API通信引擎之 間的通信是在一條或多條信道上執(zhí)行的，其中每條信道傳輸與一個或多個 訂購或發(fā)布相對應(yīng)的消息。MA和API通信引擎不斷地監(jiān)視通信路徑中的 每條路徑并且動態(tài)地優(yōu)化可用資源。這是通過使與數(shù)據(jù)發(fā)布/訂購有關(guān)的處 理開銷最小化并保留用于發(fā)布和訂購應(yīng)用的必需和預(yù)期的系統(tǒng)資源來完成 的。在一個實現(xiàn)中，API通信引擎使能了實時信道消息流控制特征，用于 防止一個或多個應(yīng)用用完可用的系統(tǒng)資源。該消息流控制特征是由訂購的 QoS (服務(wù)質(zhì)量)控制的。例如，對于上次已知值或盡力而為型QoS，處 理較少的優(yōu)質(zhì)數(shù)據(jù)常常比處理較多的劣質(zhì)數(shù)據(jù)更重要。例如，如果數(shù)據(jù)質(zhì)量是通過其時效來測量的，則僅處理最新信息可能會更好。另外，API通 信引擎將信道隊列的當(dāng)前狀態(tài)通知給MA，而不是等待隊列溢出并把處理 舊數(shù)據(jù)的負(fù)擔(dān)留給應(yīng)用和丟失最新數(shù)據(jù)。圖7圖示了實時消息流控制(MFC)算法的影響。根據(jù)該算法，信道隊列的大小可以作為閾值參數(shù)工作。例如，通過特定信道遞送的消息在接 收設(shè)備側(cè)積累在其信道隊列中，并且隨著該信道隊列的增長其大小可能達(dá) 到一高閾值， 一旦其大小超過該高閾值，信道就可能無法跟上進(jìn)入消息 流。當(dāng)接近這種情況(其中信道處于達(dá)到其最大容量的危險中)時，接收消息傳遞設(shè)備在信道隊列溢出之前可以激活MFC。當(dāng)隊列縮小并且其大小 變得小于一低閾值時，MFC被關(guān)閉。高與低閾值之間的差被設(shè)為足夠用來 產(chǎn)生所謂的遲滯行為，其中MFC在比其被關(guān)閉時的隊列大小值更高的隊 列大小值處被開啟。該閾值差避免了當(dāng)隊列大小在高閾值周圍徘徊時否則 將會發(fā)生的消息流控制的頻繁開關(guān)振蕩。因此，為了避免消息傳遞接收者 側(cè)的隊列溢出，可以用將速率保持在最大信道容量之下的實時、動態(tài)MFC 來將進(jìn)入消息的速率保持在控制中。作為在信道隊列接近其容量時丟失消息的基于遲滯的MFC算法的替 代，實時動態(tài)MFC可以操作用來混合數(shù)據(jù)或?qū)τ嗁応犃袘?yīng)用某合并算 法。然而，因為該操作可能需要另外的消息變換，所以MA可能后退到慢 轉(zhuǎn)發(fā)路徑而不是留在快轉(zhuǎn)發(fā)路徑上。這將避免消息變換對消息傳遞吞吐量 產(chǎn)生消極影響。另外的消息變換是由與協(xié)議翻譯引擎類似的處理器執(zhí)行 的。這種處理器的示例包括NPU (網(wǎng)絡(luò)處理單元)、語義處理器、MA上 的單獨微引擎等等。為了更高的效率，實時合并或訂購級的消息處理可被分配在發(fā)送者和 接受者之間。例如，在訂購級的消息處理僅被一個訂購者請求的情況下， 與在發(fā)送者側(cè)執(zhí)行它相比，將它向下推至接收者側(cè)是合理的。然而，如果 數(shù)據(jù)的多于一個消費者正請求相同的訂購級消息處理，則在上游的發(fā)送者 側(cè)執(zhí)行它將會更合理。在信道的發(fā)送者和接收者側(cè)之間分配工作負(fù)荷的目 的是最優(yōu)地使用可用的組合處理資源。當(dāng)信道把多個消息封裝在單個幀中時，其可以通過釋放一些處理資源而將消息等待時間保持在最大可接受等待時間之下并且減輕接收側(cè)的壓 力。接收更少的大幀有時比處理許多小幀更有效。對于可能在使用包括 CPU、存儲器和NIC的一般計算機硬件組件的典型OS上運行的API而言尤其是如此。典型的NIC被設(shè)計為對每個接收到的幀生成OS中斷，這從 而減少了 API把消息遞送給訂購應(yīng)用所可用的應(yīng)用級別的處理時間。如圖7所進(jìn)一步示出，如果信道隊列的當(dāng)前水平越過了最大閾值，則 MA壓制該特定信道上的消息速率，以減少API通信引擎上的負(fù)載并允許 應(yīng)用返回穩(wěn)定狀態(tài)。在該壓制過程中，取決于服務(wù)的訂購質(zhì)量，將使最新 消息優(yōu)先于舊消息。如果隊列回到正常負(fù)載水平，則API可以通知MA禁 用信道消息流控制。在上述實現(xiàn)的一個變種中，消息流控制特征是在消息傳遞路由路徑 (去/來自應(yīng)用)的API側(cè)實現(xiàn)的。每當(dāng)消息需要被遞送給訂購應(yīng)用時， API通信引擎就可以做出判定，以在服務(wù)的訂購質(zhì)量允許的情況下以有利 于跟隨更新消息的方式丟棄消息?？傊?，在API中或在MA中，消息流控制可以應(yīng)用不同的壓制策略， 其中API通信引擎或者被連接到該API通信引擎的MA可以執(zhí)行基于訂購 的數(shù)據(jù)合并(亦稱為數(shù)據(jù)混合)，而不是有利于新消息而丟棄舊消息。換 言之，丟棄的數(shù)據(jù)未被完全丟失而是被與最新數(shù)據(jù)混合。在一個實施例 中，可以在給定的API和其MA之間為所有信道全局地定義這種消息流控 制壓制策略，并且可以根據(jù)P&M系統(tǒng)將該策略配置為合并的服務(wù)質(zhì)量。 該QoS將應(yīng)用于訂購該合并QoS的所有應(yīng)用。在另一個實施例中，該壓 制策略可以經(jīng)由來自應(yīng)用的API函數(shù)調(diào)用來自定義，從而提供了一些靈活 性。在這種特殊情況下，API通信引擎在與MA建立信道時傳達(dá)壓制策 略。信道配置參數(shù)是在該階段期間在API通信引擎與MA之間商定的。注意到當(dāng)該自定義壓制策略是在訂購級而非在消息級實現(xiàn)的時，應(yīng)用 可以在訂購給定話題時定義策略。基于訂購的壓制策略然后被加入該特定 訂購的信道配置。API通信引擎可被配置為提供增值消息處理；API所連接到的MA也 可以這樣做。對于增值消息處理，應(yīng)用可以訂購給定訂購或一組訂購的在28線(inline)增值消息處理服務(wù)。該服務(wù)將隨后被執(zhí)行或被應(yīng)用于所訂購的 消息流。另外，應(yīng)用可以使用高級消息處理語言來注冊一些偽代碼，用來 引用消息中的域(例如NEWFIELD=(FIELD(N)+FIELD(M))/2，這樣用等 于域N和M的算術(shù)平均的值在消息的末端定義了新域的建立)。這些增 值消息處理服務(wù)在新消息被處理時可以要求服務(wù)專用狀態(tài)被保持和更新。 將以與定義域相同的方式來定義這些狀態(tài)，并且將以偽代碼重新使用它們(例如STATE(0)+=FIELD(N)，這意味著狀態(tài)號碼0是FIELD(N)的累加 和)。這些服務(wù)可被默認(rèn)定義在系統(tǒng)中并且應(yīng)用在訂購特定話題時只需使 能這些服務(wù)，或者它們可以是自定義的?？傊梢酝ㄟ^API通信引擎或 被連接到該API的MA來執(zhí)行這種在線增值消息處理服務(wù)。與在線增值消息處理服務(wù)類似，基于內(nèi)容的訪問控制歹U表(ACL)可 以取決于實現(xiàn)而被部署在API通信引擎或MA上或者被部署在這兩者上。 例如假定股票交易員可能僅當(dāng)IBM價格高于S50時對具有IBM報價的消息 有興趣，否則其優(yōu)選丟棄所具有的報價低于該值的所有消息。為此，API(或MA)還能夠定義基于內(nèi)容的ACL并且應(yīng)用將定義基于訂購的 ACL?；谟嗁彽腁CL可以是使用消息中的域來表達(dá)的ACL條件和以 REJECT、 ACCEPT、 LOG的形式或另一合適方式表達(dá)的ACL動作的組 合。這種 ACL的 一 個示例是((FIELD(n)<VALUE， ACCEPT, REJECT|IX)G)。為了進(jìn)一步提高效率，API通信引擎可被配置為把消息處理中的一些 轉(zhuǎn)給智能消息傳遞網(wǎng)絡(luò)接口卡(NIC)。該智能消息傳遞NIC被提供用于 通過以硬件執(zhí)行完整的網(wǎng)絡(luò)堆棧來繞過聯(lián)網(wǎng)I/O,用于執(zhí)行從I/0卡直接到 應(yīng)用存儲空間的DMA并且用于管理消息傳遞可靠性，包括重傳和臨時緩 存。智能消息傳遞NIC可以進(jìn)一步執(zhí)行信道管理，包括如上所述的消息流 控制、增值消息處理和基于內(nèi)容的ACL。圖8a和圖8b中分別圖示了這種 智能消息傳遞NIC的兩種實現(xiàn)。圖8a圖示了存儲互連卡808，并且圖8b 圖示了消息傳遞卸載卡810。這兩種實現(xiàn)都包括主機CPU 802、主機存儲 器804和PCI主機橋806。正如眾所周知的，穩(wěn)定性、可用性和一致性在企業(yè)操作中經(jīng)常是必須29的。為此，發(fā)布/訂購中間件系統(tǒng)可被設(shè)計用于容錯，其組件中的多個被部署為容錯系統(tǒng)。例如，MA可被部署為容錯MA對，其中第一MA被稱為 主要MA，并且第二MA被稱為次要MA或容錯MA (FT MA)。此外， 為了存儲和轉(zhuǎn)發(fā)操作，CE (緩存引擎)可以被連接到主要或次要的核心/ 邊緣MA。當(dāng)主要或次要MA具有到CE的活動連接時，其把路由消息的 全部或子集轉(zhuǎn)發(fā)給該CE，該CE把它們寫入存儲區(qū)域用于保持。在預(yù)定時 間段內(nèi)，然后這些消息當(dāng)被請求時可用于重傳。圖10中示出了容錯設(shè)計的一個示例。在該示例中，系統(tǒng)是基于會話 的容錯。另一種可能的配置是完全故障轉(zhuǎn)移(failover)，但是在該示例中 我們己經(jīng)選擇了基于會話的容錯。會話被定義為兩個MA之間或者一個 MA與一個API之間的通信。會話包括兩個MA之間或者一個MA與一個 API之間的通信(例如910)并且其可以是主動或被動的。如果故障發(fā) 生，則MA或API可以決定把會話從主要MA 906切換到次要MA 908。 當(dāng)會話經(jīng)歷連接性和/或諸如CPU、存儲器、接口等這樣的系統(tǒng)資源的故 障時，故障就會發(fā)生。連接性問題是根據(jù)底層信道來定義的。例如，基于 IP的信道在損失、延遲和/或抖動隨著時間異常地增加時將經(jīng)歷連接性問 題。對于基于存儲器的信道，連接性問題可根據(jù)存儲地址沖突等來定義。 每當(dāng)會話經(jīng)歷一些連接性和/或系統(tǒng)資源問題時，MA或API就決定把會話 從主要MA切換到次要MA。在一個實現(xiàn)中，主要和次要MA可被看作是使用一些基于信道的邏輯 來將邏輯信道地址映射到物理信道地址的單個MA。例如，對于基于IP的 信道，API或MA可以通過把MA邏輯地址的ARP緩存條目更新為指向次 要MA的物理MAC地址來把有問題的會話重定向到次要MA?？傊?，基于會話的容錯設(shè)計具有當(dāng)只有所有會話中的一個或子集經(jīng)歷 問題時不影響所有會話的優(yōu)勢。就是說，當(dāng)會話經(jīng)歷一些性能問題時，該 會話被從主要MA (例如906)移動到次要容錯(FT) MA 908，而不影響 與該主要MA 906相關(guān)的其他會話。所以，例如APM被示出為仍具有與主 要MA 902 (作為活動MA)的相應(yīng)活動會話，而APs具有與FT MA 908 的活動會話。在與相應(yīng)MA進(jìn)行通信時，API使用經(jīng)由一個或多個物品或智能消息傳遞卸載NIC連接的物理介質(zhì)。圖10圖示了用于API與MA之間的通信 的接口。總之，本發(fā)明提供了一種進(jìn)行消息傳遞的新方法，更具體地說，提供 了一種具有智能消息傳遞應(yīng)用編程接口的新的發(fā)布/訂購中間件系統(tǒng)。雖然 已經(jīng)參照本發(fā)明的某些優(yōu)選版本相當(dāng)詳細(xì)地描述了本發(fā)明，但是其它版本 也是可能的。因此，所附權(quán)利要求書的精神和范圍應(yīng)當(dāng)不限于這里所包含 的對優(yōu)選版本的描述。
權(quán)利要求
1.一種用于應(yīng)用與發(fā)布/訂購中間件系統(tǒng)之間的通信的應(yīng)用編程接口，包括通信引擎，其被配置為充當(dāng)用于應(yīng)用與具有所述通信引擎的發(fā)布/訂購中間件系統(tǒng)之間的通信的網(wǎng)關(guān)，其中所述通信引擎的操作對應(yīng)用而言是透明的，用于使用動態(tài)選擇的消息傳輸協(xié)議并用于對傳輸信道資源和流實時地進(jìn)行監(jiān)視和動態(tài)控制；一個或多個存根，用于所述應(yīng)用與所述通信引擎之間的通信；以及總線，用于所述一個或多個存根與所述通信引擎之間的通信。
2. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述總線是進(jìn)程間通信 總線或進(jìn)程內(nèi)通信總線。
3. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作用 于動態(tài)地調(diào)節(jié)被封裝在一個幀中的消息的數(shù)目。
4. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作用 于基于會話的容錯。
5. 如權(quán)利要求l所述的應(yīng)用編程接口，其中，所述通信引擎還操作用 于消息的臨時緩存。
6. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作用 于增值消息處理。
7. 如權(quán)利要求6所述的應(yīng)用編程接口，其中，所述增值消息處理包括 基于內(nèi)容的訪問控制列表的部署，其中所述列表中的每個條目與一個訪問 條件和動作相關(guān)聯(lián)。
8. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作用 于向所述發(fā)布/訂購中間件系統(tǒng)中的消息傳遞設(shè)備進(jìn)行注冊并變得邏輯上連 接到所述消息傳遞設(shè)備。
9. 如權(quán)利要求8所述的應(yīng)用編程接口，其中，所述注冊是將請求記入 日志并且訂購是基于話題的，其中話題定義了所述應(yīng)用編程接口對之具有 發(fā)布/訂購授權(quán)的共享訪問域。
10. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于遲計劃綁定。
11. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于部分消息發(fā)布。
12. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于所述應(yīng)用對被存儲的消息進(jìn)行直接存儲器訪問。
13. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于處理批量消息傳遞。
14. 如權(quán)利要求12所述的應(yīng)用編程接口，其中，處理所述批量消息傳遞包括消息排隊，所述消息排隊帶有限制以避免隊列溢出和通信等待時 間。
15. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述實時消息傳輸資源和流控制使用如下策略或者識別并不顧舊消息，或者使消息混合。
16. 如權(quán)利要求15所述的應(yīng)用編程接口，其中，所述策略被全局地應(yīng)用于與所述應(yīng)用編程接口相關(guān)的所有消息傳輸路徑。
17. 如權(quán)利要求15所述的應(yīng)用編程接口，其中，所述策略是用戶定義的。
18. 如權(quán)利要求15所述的應(yīng)用編程接口，其中，所述策略在應(yīng)用訂購 時被定義和實現(xiàn)。
19. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于以原始壓縮數(shù)據(jù)格式處理消息并把所述原始數(shù)據(jù)綁定到其計劃。
20. 如權(quán)利要求6所述的應(yīng)用編程接口，其中，所述增值消息處理是 在應(yīng)用注冊期間定義的。
21. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于卸載到接口卡的消息處理。
22. 如權(quán)利要求1所述的應(yīng)用編程接口，其中，所述發(fā)布/訂購中間件 系統(tǒng)包括消息傳遞設(shè)備，并且其中在所述消息傳遞設(shè)備與所述應(yīng)用編程接 口之間以基于主從的配置分配協(xié)議優(yōu)化，其中所述應(yīng)用編程接口作為從 方。
23. 如權(quán)利要求2所述的應(yīng)用編程接口，其中，所述進(jìn)程間通信總線如果被使用則是使用套接字或共享存儲器來實現(xiàn)的，并且所述進(jìn)程內(nèi)通信 總線如果被使用則是使用函數(shù)調(diào)用來實現(xiàn)的。
24. —種用于應(yīng)用與發(fā)布/訂購中間件系統(tǒng)之間的通信的應(yīng)用編程接口，包括通信引擎，其被配置為充當(dāng)用于應(yīng)用與發(fā)布/訂購中間件系統(tǒng)之間的通 信的網(wǎng)關(guān)，所述通信引擎具有包括消息層和消息傳輸層的邏輯層，其中所 述消息層包括應(yīng)用遞送路由引擎、管理消息層和消息路由選擇引擎，并且 其中所述消息傳輸層包括信道管理部分，所述信道管理部分用于基于系統(tǒng)資源使用來實時地控制由所述消息層處理的消息的傳輸路徑；一個或多個存根，用于所述應(yīng)用與所述通信引擎之間的通信；以及總線，用于所述一個或多個存根與所述通信引擎之間的通信。
25. 如權(quán)利要求24所述的應(yīng)用編程接口，其中，所述通信引擎被部署 在操作系統(tǒng)之上。
26. 如權(quán)利要求24所述的應(yīng)用編程接口，其中，所述操作系統(tǒng)包括用 于接口卡的驅(qū)動程序，其中所述信道管理部分通過所述接口卡與用于向和 從所述應(yīng)用傳輸消息的物理介質(zhì)接口連接。
27. 如權(quán)利要求26所述的應(yīng)用編程接口，其中，所述接口卡是操作用 于存儲器互連或用于消息處理卸載的網(wǎng)絡(luò)接口卡。
28. 如權(quán)利要求26所述的應(yīng)用編程接口，其中，所述接口卡包括基于 硬件的聯(lián)網(wǎng)I/O (輸入/輸出)堆棧并且操作用于用于傳輸?shù)闹苯哟鎯ζ髟L 問和緩存。
29. 如權(quán)利要求24所述的應(yīng)用編程接口，其中，所述消息路由選擇引 擎包括傳輸協(xié)議優(yōu)化服務(wù)部分。
30. 如權(quán)利要求24所述的應(yīng)用編程接口，其中，所述應(yīng)用遞送路由引 擎操作用于把應(yīng)用映射到話題訂購。
31. 如權(quán)利要求24所述的應(yīng)用編程接口，其中，所述信道管理部分控 制多個信道并且所述應(yīng)用遞送路由引擎基于所述映射把消息遞送給應(yīng)用。
32. 如權(quán)利要求30所述的應(yīng)用編程接口，其中，所述管理消息層處理管理消息并且所述路由和應(yīng)用遞送路由引擎處理數(shù)據(jù)消息。
33. 如權(quán)利要求23所述的應(yīng)用編程接口，其中，所述通信引擎和所述一個或多個存根被編譯并被鏈接到如下應(yīng)用，所述應(yīng)用使用所述應(yīng)用編程 接口來與所述發(fā)布/訂購中間件系統(tǒng)進(jìn)行通信。
34. 如權(quán)利要求23所述的應(yīng)用編程接口，其中，所述通信引擎還操作 用于遲綁定計劃。
35. 如權(quán)利要求34所述的應(yīng)用編程接口，其中，所述應(yīng)用遞送路由引擎操作用于把計劃綁定到原始消息數(shù)據(jù)，從而允許所述應(yīng)用透明地訪問消 自樣自
36. 如權(quán)利要求1所述的應(yīng)用編程接口，還包括呈現(xiàn)引擎，其操作用 于使來往于所述應(yīng)用的進(jìn)入消息和外出消息在應(yīng)用數(shù)據(jù)格式與消息傳遞數(shù) 據(jù)計劃之間進(jìn)行轉(zhuǎn)換。
全文摘要
消息發(fā)布/訂購系統(tǒng)被要求處理高消息容量，同時減少等待時間和性能瓶頸。本發(fā)明所介紹的智能消息傳遞應(yīng)用編程接口被設(shè)計用于高容量、低等待時間的消息傳遞。API是發(fā)布/訂購中間件系統(tǒng)的一部分。利用API，該系統(tǒng)操作用來實時地對包括等待時間的系統(tǒng)性能進(jìn)行監(jiān)視，使用基于話題和基于信道的消息通信，并且動態(tài)地優(yōu)化系統(tǒng)互連配置和消息傳輸協(xié)議。
文檔編號G06F9/44GK101326508SQ200580046093
公開日2008年12月17日 申請日期2005年12月23日 優(yōu)先權(quán)日2005年1月6日
發(fā)明者巴利·J·湯普森, 庫·辛格, 皮埃爾·費沃 申請人:特維拉有限公司