專利名稱：端到端的發(fā)布/訂購中間件體系結(jié)構(gòu)的制作方法
技術領域：
本發(fā)明涉及數(shù)據(jù)消息傳遞，更具體地說，涉及發(fā)布/訂購系統(tǒng)的中間件 體系結(jié)構(gòu)。
背景技術：
數(shù)據(jù)消息傳遞基礎設施所要求的日益提高的性能水平強迫聯(lián)網(wǎng)基礎設 施和協(xié)議的發(fā)展?；旧?，數(shù)據(jù)分發(fā)涉及各種數(shù)據(jù)源和目的地，以及各種 類型的互連體系結(jié)構(gòu)和數(shù)據(jù)源和目的地之間的通信模式。現(xiàn)有數(shù)據(jù)消息傳 遞體系結(jié)構(gòu)的示例包括輪軸輪輻式(hub-and-spoke)，對等式和存儲轉(zhuǎn)發(fā) 式。利用輪軸輪輻系統(tǒng)配置，所有通信都通過輪軸傳輸，這在處理量大時 通常會導致性能瓶頸。因此，這種消息傳遞系統(tǒng)產(chǎn)生了等待時間。繞過這 種瓶頸的一種方法是布署更多的服務器，并且在這些不同的服務器之間分 布網(wǎng)絡負載。但是，這種體系結(jié)構(gòu)表現(xiàn)出可擴展性和操作問題。與具有輪 軸輪輻配置的系統(tǒng)相比，具有對等配置的系統(tǒ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)生性能瓶頸。此外，在消息量增大了時，索引和寫入任務可能相 當慢，因此可能引入額外的等待時間。現(xiàn)有數(shù)據(jù)消息傳遞體系結(jié)構(gòu)共有一些不足。 一個共同的不足是在現(xiàn)有 體系結(jié)構(gòu)中數(shù)據(jù)消息傳遞依賴于駐留在應用層上的軟件。這意味著消息傳 遞基礎設施要經(jīng)歷OS (操作系統(tǒng))排隊和網(wǎng)絡I/0 (輸入/輸出)，這可能 產(chǎn)生性能瓶頸。另一個共同的不足是現(xiàn)有體系結(jié)構(gòu)靜態(tài)地而不是動態(tài)地使 用數(shù)據(jù)傳輸協(xié)議，即使在某些情形下其他協(xié)議可能更合適也是如此。常見 協(xié)議的一些示例包括可路由多播、廣播或單播。實際上，現(xiàn)有體系結(jié)構(gòu)中 的應用編程接口 (API)未被設計為實時地在傳輸協(xié)議之間切換。另外，網(wǎng)絡配置判決通常是在布署時進行的，并且通常被定義為在特 定假設下對一組網(wǎng)絡和消息傳遞條件進行優(yōu)化。與靜態(tài)(固定的)配置相 關聯(lián)的限制排除了實時動態(tài)網(wǎng)絡重配置。換言之，現(xiàn)有體系結(jié)構(gòu)是針對特 定傳輸協(xié)議配置的，而該傳輸協(xié)議并不總是適合所有網(wǎng)絡數(shù)據(jù)傳輸負載條 件，因此，現(xiàn)有體系結(jié)構(gòu)總是不能實時地應對改變或增大的負載能力需 求。此外，在數(shù)據(jù)消息傳遞去往特定的接收者或者接收者群組時，現(xiàn)有消 息傳遞體系結(jié)構(gòu)使用可路由多播來將數(shù)據(jù)傳輸過網(wǎng)絡。但是，在針對多播 建立的系統(tǒng)中，存在對可以用來分發(fā)數(shù)據(jù)的多播群組的數(shù)目的限制，結(jié) 果，消息傳遞系統(tǒng)不再將數(shù)據(jù)發(fā)送向未被向其訂購的目的地(即，不是訂 戶的客戶)。由于數(shù)據(jù)過濾，這增大了客戶的數(shù)據(jù)處理負載和丟棄率。因 此，由于任何原因變?yōu)檫^載并且不能跟上數(shù)據(jù)流的客戶最終丟棄進入數(shù) 據(jù)，并且稍后要求重傳。重傳對整個系統(tǒng)造成影響，因為所有客戶都接收 重復的傳輸，并且所有客戶都對進入數(shù)據(jù)進行重新處理。因此，重傳可能 導致多播風暴，并且最終可能使整個系統(tǒng)癱瘓。在系統(tǒng)是針對單播消息傳遞建立來作為減少丟棄率的一種方法時，該 消息傳遞系統(tǒng)可能因為數(shù)據(jù)復制而經(jīng)歷帶寬飽和。例如，如果多于一個客 戶訂購了感興趣的給定話題，則消息傳遞系統(tǒng)必須將該數(shù)據(jù)遞送到每個訂 戶，實際上，系統(tǒng)將該數(shù)據(jù)的不同拷貝發(fā)送到每個訂戶。盡管這解決了客 戶濾除非訂購數(shù)據(jù)的問題，但是單播傳輸是不可擴展的，因此基本上不適 合訂購特定數(shù)據(jù)的大量客戶群組或者消費模式極度重疊的情形。
現(xiàn)有體系結(jié)構(gòu)的另一個共同不足是它們的協(xié)議變換較慢并且數(shù)量非常多。這是因為企業(yè)應用集成(EIA)領域中的IT (信息技術)權(quán)宜(band-aid) 策略所致，在該領域中，越來越多的新技術被與遺留系統(tǒng)集成。因此，在多個領域中都需要提高數(shù)據(jù)消息傳遞系統(tǒng)性能。其中性能可 能需要提高的示例有速度、資源分配、等待時間等。發(fā)明內(nèi)容本發(fā)明部分基于前述觀察和利用不同的方法可以解決這種不足使得具 有更好的結(jié)果這一觀點。這些觀察使得開發(fā)出用于大量低等待時間消息傳 遞的端到端消息發(fā)布/訂購體系結(jié)構(gòu)。因此，具有根據(jù)本發(fā)明原理的端到端 消息發(fā)布/訂閱中間件體系結(jié)構(gòu)的數(shù)據(jù)分發(fā)系統(tǒng)可以有利地在極低等待時間 的情況下路由大量的消息，這是通過減少具有基于鄰居的路由選擇和網(wǎng)絡 非居間化(disintermediation)的中介跳，引入高效的本地到外部和外部到 本地協(xié)議轉(zhuǎn)換、實時監(jiān)控系統(tǒng)性能(包括等待時間)、布署基于話題和基 于通道的消息通信、以及動態(tài)并且智能地對系統(tǒng)互連配置和消息傳輸協(xié)議 進行優(yōu)化，等等。另外，這種系統(tǒng)可以利用數(shù)據(jù)緩存提供有保證的遞送服 務質(zhì)量。結(jié)合資源分配，根據(jù)本發(fā)明的數(shù)據(jù)分發(fā)系統(tǒng)帶來了實時動態(tài)分配可用 資源的優(yōu)點。就此而言，與傳統(tǒng)的靜態(tài)配置方法相反，本發(fā)明設想了一種 系統(tǒng)，該系統(tǒng)具有用于資源分配的實時、動態(tài)、經(jīng)學習的方法。其中可以 對資源分配進行實時優(yōu)化的示例包括網(wǎng)絡資源(帶寬、協(xié)議、路徑/路由的 利用)和客戶系統(tǒng)資源(CPU、存儲器和盤空間的利用)。結(jié)合監(jiān)控系統(tǒng)拓撲和性能，根據(jù)本發(fā)明的數(shù)據(jù)分發(fā)系統(tǒng)有益地區(qū)分開 消息級和幀級等待時間測量。在某些情形中，這些測量之間的相關提供了 有競爭力的商業(yè)優(yōu)點。換言之，等待時間的本質(zhì)和程度可以指示最佳數(shù)據(jù) 和數(shù)據(jù)資源，而其又可以用在商業(yè)過程中，并且提供有競爭力的優(yōu)勢。因此，根據(jù)所示并且在這里寬廣描述的本發(fā)明的目的，具有發(fā)布/訂閱 中間件體系結(jié)構(gòu)的一種示例性系統(tǒng)包括 一個或多于一個的消息傳遞設 備，被配置用于接收并路由消息；互連；以及設置和管理系統(tǒng)，通過所述
互連而鏈接并且被配置用于與每個消息傳遞設備交換管理消息。在這樣的 系統(tǒng)中，消息傳遞設備通過動態(tài)地選擇消息傳輸協(xié)議和消息路由路徑而執(zhí) 行消息的路由。另外，所述發(fā)布/訂購系統(tǒng)可以被從設置和管理系統(tǒng)而被集中式監(jiān)控和 配置。這提供了用于授權(quán)、用戶管理、數(shù)字權(quán)限管理、模式等的易管理并 且可縮放的單點配置。而且，上述系統(tǒng)可以用一個或多個命名空間域來實現(xiàn)，并且，如果實 際上存在多于一個的空間域，則系統(tǒng)還包括用于在命名空間域之間連接的 域互連介質(zhì)。該域互連介質(zhì)例如可以是聯(lián)網(wǎng)基礎設施。在另一個實施例中，具有發(fā)布/訂購中間件體系結(jié)構(gòu)的企業(yè)系統(tǒng)包括 市場數(shù)據(jù)傳遞基礎設施，其具有一個或多個用于接收和路由市場數(shù)據(jù)消息 的消息傳遞設備；市場訂單路由基礎設施，其具有一個或多個用于接收和 路由交易訂單消息的消息傳遞設備；以及中間基礎設施，其分別與所述市 場數(shù)據(jù)傳遞基礎設施和所述市場訂單路由基礎設施通信鏈接。在該系統(tǒng) 中，中間基礎設施包括一個或多于一個被配置為用于接收和路由所述市場 數(shù)據(jù)消息和所述交易訂單消息的消息傳遞設備、互連、以及設置和管理系 統(tǒng)，所述設置和管理系統(tǒng)通過所述互連而鏈接，并且被配置為用于與每個 消息傳遞設備交換管理消息，所述消息傳遞設備包括市場數(shù)據(jù)傳遞基礎設 施和市場訂單路由基礎設施中的消息傳遞設備。此外，所述消息傳遞設備 中的每一個還被配置為用于通過動態(tài)地選擇消息傳輸協(xié)議和消息路由路徑 而執(zhí)行其所接收的消息的路由。而且，在這樣的企業(yè)系統(tǒng)中，存在用于發(fā)布市場數(shù)據(jù)消息的市場數(shù)據(jù) 源和用于接收市場數(shù)據(jù)消息并且用于發(fā)布交易訂單消息的市場數(shù)據(jù)客戶 (外部數(shù)據(jù)目的地)。所述市場數(shù)據(jù)客戶包括一個或多個應用。因此，中 間件基礎設施包括應用編程接口，該應用編程接口在所述應用程序的每一 個和這樣的應用編程接口所注冊到的中間基礎設施中的消息傳遞設備的一 個之間。所述應用編程接口用于將市場數(shù)據(jù)消息傳遞到應用，并且從應用 傳遞交易訂單消息。該系統(tǒng)還包括用于分別將進入和外出消息在本地消息 協(xié)議和外部消息協(xié)議之間進行翻譯的協(xié)議變換引擎。
總之，本發(fā)明的這些和其它特征、方面和優(yōu)點將從這里的描述、所附 的權(quán)利要求書和下文所描述的附圖中被更好地理解。


包含在本說明書中并且構(gòu)成本說明書一部分的附圖示出了本發(fā)明的各 個方面，并且與說明一起用于說明其原理。為了方便，在所有附圖中將使 用相同的標號來指示相同或相似的元件。圖1示出了根據(jù)本發(fā)明原理的端到端的中間件體系結(jié)構(gòu)。圖la是示出覆蓋網(wǎng)絡的圖。圖2是示出用根據(jù)本發(fā)明原理的端到端的中間件體系結(jié)構(gòu)所實現(xiàn)的企業(yè)基礎設施的圖。圖2a是示出在消息傳遞裝置(MA)創(chuàng)建網(wǎng)絡骨干網(wǎng)非居間化的情況 下的企業(yè)基礎設施物理部署的圖。圖3示出了基于信道的消息傳遞系統(tǒng)體系結(jié)構(gòu)。圖4示出了一種可能的基于話題的消息格式。圖5示出了基于話題的消息路由選擇和路由選擇表。圖6是示出根據(jù)本發(fā)明一個實施例的設置和管理(P&M)系統(tǒng)的框圖。圖7示出了具有基于命名空間的拓撲的消息傳遞(發(fā)布/訂購)系統(tǒng)。圖8是示出P&M系統(tǒng)和消息傳遞裝置中的一個之間的通信的圖。圖9是示出根據(jù)本發(fā)明原理而配置的MA的框圖。圖IO示出了用于在MA和CE (緩存引擎)之間通信的接口。圖ll示出了用于在MA和應用編程接口 (API)之間通信的接口。圖12是示出根據(jù)本發(fā)明一個實施例而配置的CE的框圖。圖13是根據(jù)本發(fā)明一個實施例而配置的API的框圖。圖14示出了根據(jù)本發(fā)明原理的利用基于會話的容錯配置所設計的系統(tǒng)。
具體實施方式
在概述根據(jù)本發(fā)明的各個方面和原理的各種實施例的細節(jié)之前，下面 是對一些術語的簡單說明，這些術語可以被用在整個說明書中。注意，該 說明僅是為了澄清并且向讀者給出對可能如何使用這些術語的理解，但是 不是將這些術語限于使用它們的上下文中，也不是要因此限制權(quán)利要求書 的范圍。術語"中間件"在計算機工業(yè)中作為一個一般術語使用，針對在兩個 分離的通常已存在的程序之間協(xié)調(diào)的任何編程。 一般而言，中間件程序提 供消息傳遞服務，使得不同的應用程序可以通信。通常通過利用中間件將 不同的應用程序在系統(tǒng)上連結(jié)到一起被稱作企業(yè)應用集成(EAI)。但 是，在該上下文中"中間件"可以是一種更廣的術語，用在源和目的地之 間的消息傳遞和被布署用于實現(xiàn)這種消息傳遞的設施的上下文中；因此， 中間件體系結(jié)構(gòu)單獨或者與下面將描述的組合覆蓋了實現(xiàn)高效數(shù)據(jù)消息傳 遞的聯(lián)網(wǎng)和計算機硬件與軟件組件。此外，術語"消息傳遞系統(tǒng)"或者 "中間件系統(tǒng)"可以被用在發(fā)布/訂購系統(tǒng)的上下文中，在該系統(tǒng)中，消息 傳遞服務器對在發(fā)布者和訂購者之間的消息路由選擇進行管理。實際上， 消息傳遞中間件中發(fā)布/訂購的范式是可擴展的，因此是一種有力的模型。術語"客戶"可以用在客戶機-服務器應用等的上下文中。在一個實例中，客戶是這樣一種系統(tǒng)或應用，其利用應用編程接口 (API)注冊到中間件系統(tǒng)，以訂購信息，并且接收該中間件系統(tǒng)遞送的數(shù)據(jù)。中間件體系結(jié)構(gòu)邊界內(nèi)部的API是一種客戶；并且外部客戶是不使用該API的任何發(fā) 布/訂購系統(tǒng).(或者外部數(shù)據(jù)目的地)，并且為了與之通信，消息要通過協(xié) 議變換(稍后將描述)。術語"外部數(shù)據(jù)源"可以用在數(shù)據(jù)分發(fā)和消息發(fā)布/訂購系統(tǒng)的上下文 中。在一個示例中，外部數(shù)據(jù)源被認為是位于企業(yè)專用網(wǎng)絡內(nèi)或者外部的 系統(tǒng)或應用，其采用常用協(xié)議之一或者其自己的消息協(xié)議發(fā)布消息。外部 數(shù)據(jù)源的一個示例是市場數(shù)據(jù)交換，其發(fā)布股市報價，股市報價經(jīng)由中間 件系統(tǒng)被分發(fā)到交易員。外部數(shù)據(jù)源的另一個示例是事務性數(shù)據(jù)。注意， 在后面將更詳細描述的本發(fā)明的典型實現(xiàn)方式中，中間件體系結(jié)構(gòu)采用其 唯一的本地協(xié)議，來自外部數(shù)據(jù)源的數(shù)據(jù)一旦進入該中間件系統(tǒng)域就被轉(zhuǎn)
換成該唯一的本地協(xié)議，從而避免了傳統(tǒng)系統(tǒng)中典型的多協(xié)議變換。術語"外部數(shù)據(jù)目的地"也用在數(shù)據(jù)分發(fā)和消息發(fā)布/訂購系統(tǒng)的上下 文中。例如，外部數(shù)據(jù)目的地是位于企業(yè)專用網(wǎng)絡內(nèi)或外部的系統(tǒng)或應 用，其訂購經(jīng)由本地/全局網(wǎng)絡被路由的信息。外部數(shù)據(jù)目的地的一個示例 可以是對由交易員發(fā)布的事務訂單進行處理的前述市場數(shù)據(jù)交換。外部數(shù) 據(jù)目的地的另一個實施例是事務性數(shù)據(jù)。注意，在前述中間件體系結(jié)構(gòu) 中，去往外部數(shù)據(jù)目的地的消息從本地協(xié)議被翻譯成與該外部數(shù)據(jù)目的地 相關聯(lián)的外部協(xié)議。從這里的描述可以確認，可以利用每種都在中間件體系結(jié)構(gòu)中實現(xiàn)的 各種配置以各種方式實施本發(fā)明。圖1示出了根據(jù)本發(fā)明原理的端到端中 間件體系結(jié)構(gòu)的示例。這種示例性體系結(jié)構(gòu)組合了許多有益特征，這些有益特征包括消息 傳遞公共概念、API、容錯、設置和管理(P&M)、服務質(zhì)量(QoS-合并 的，盡力而為的、有保證同時連接的、有保證同時不連接的，等等)、有保證遞送QoS的持久緩存、命名空間和安全性服務的管理、發(fā)布/訂購生態(tài)系統(tǒng)(核心、入口和出口組件)、傳輸透明的消息傳遞、基于鄰居的消 息傳遞(一種作為輪軸輪輻、對等和存儲轉(zhuǎn)發(fā)之間的混合體的模型，該模 型使用基于訂購的路由選擇協(xié)議，可以在必要時將訂購傳播到所有鄰 居)、遲計劃綁定、部分發(fā)布(與所有數(shù)據(jù)相對，僅發(fā)布改變的信息)和 動態(tài)分配網(wǎng)絡和系統(tǒng)資源。后面將說明，發(fā)布/訂購系統(tǒng)有益地結(jié)合了中間件體系結(jié)構(gòu)的容錯設計。注意，發(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)中，兩個截然不同的物理組件之間的邏輯 通信是利用消息流和相關聯(lián)的消息協(xié)議建立起來的。消息流包含兩類消息之一管理和數(shù)據(jù)消息。管理消息用于管理和控制不同的物理組件、管理對數(shù)據(jù)的訂購，等等。數(shù)據(jù)消息用于在源和目的地之間傳輸數(shù)據(jù)，并且在
典型的發(fā)布/訂購消息傳遞中，存在數(shù)據(jù)消息的多個發(fā)送者和多個接收者。利用所示結(jié)構(gòu)配置和邏輯通信，該具有中間件體系結(jié)構(gòu)的分布式發(fā)布/ 訂購系統(tǒng)被設計來執(zhí)行多種邏輯功能。 一種邏輯功能是消息協(xié)議翻譯，該 功能有利地在邊沿消息傳遞設備(MA)組件處執(zhí)行。第二種邏輯功能是 將消息從發(fā)布者路由到訂購者。注意，這些消息被路由過整個發(fā)布/訂購網(wǎng) 絡。因此，路由選擇功能由其中傳播消息的每個MA執(zhí)行，S卩，從邊沿MA106a-b (或者API)到核心MA108a-c，從一個核心MA到另一個核心 MA，最終到達邊沿MA (例如，106b)或者API110a-b。 API110a-b經(jīng)由 程間通信總線(套接字、共享存儲器等)與應用112^通信。第三種邏輯功能是針對不同類型的有保證的遞送服務質(zhì)量存儲消息， 包括例如有保證同時連接的和有保證同時不連接的。第四種功能是將這些 消息遞送到訂購者。如圖所示，API 106a-b將消息遞送到訂購應用112,-在該發(fā)布/訂購中間件體系結(jié)構(gòu)中，系統(tǒng)配置功能以及其他管理和系統(tǒng)性能監(jiān)控功能由P&M系統(tǒng)管理。另外，MA取決于它們在網(wǎng)絡中的角色 被布署為核心MA或者邊沿MA。邊沿MA在大多方面與核心MA類似， 除了其包括協(xié)議翻譯引擎之外，協(xié)議翻譯引擎將消息從外部協(xié)議翻譯成本 地協(xié)議和從本地協(xié)議翻譯成外部協(xié)議。因此， 一般來說，發(fā)布/訂購系統(tǒng)中 間件體系結(jié)構(gòu)的邊界由其中存在MA 106a-b和API llOa-b的其邊沿表征； 并且在這些邊界內(nèi)，存在核心MA 108a-c。在典型的系統(tǒng)中，核心MA 108a-c將在該系統(tǒng)內(nèi)部發(fā)布的消息路由向 邊沿MA或API (例如，API 110a-b)。尤其是在核心MA中的路由選擇 圖被設計來用于最大量、低等待時間并且高效地路由選擇。此外，核心 MA之間的路由選擇可以實時動態(tài)改變。對于穿過多個節(jié)點(核心MA) 的給定的消息傳遞路徑，路由選擇的實時改變是基于一個或多個度量的， 這些度量包括網(wǎng)絡利用、總地端到端等待時間、通信量、網(wǎng)絡延遲、丟失 和抖動?；蛘?，不是從兩條或多條不同的路徑中動態(tài)選擇最佳執(zhí)行路徑，而是 MA可以基于消息復制執(zhí)行多路徑路由選擇，并且從而通過所有路徑發(fā)送
相同的消息。位于不同路徑的匯聚點處的所有MA將丟棄復制的消息，僅 轉(zhuǎn)發(fā)第一個到達的消息。這種路由選擇方法具有使低等待時間的消息傳遞 基礎設施最優(yōu)化的優(yōu)點；盡管這種路由選擇的缺點是基礎設施需要更多的 網(wǎng)絡帶寬來傳送復制的流量。注意，系統(tǒng)體系結(jié)構(gòu)不被限制到特定的受限的地理區(qū)域，并且實際 上，系統(tǒng)體系結(jié)構(gòu)被設計為超越區(qū)域或國家邊界，甚至跨越大洲。在這種情形中， 一個網(wǎng)絡中的邊沿MA可以經(jīng)由現(xiàn)有的聯(lián)網(wǎng)基礎設施與地理上遠 離的另一個網(wǎng)絡中的邊沿MA通信。邊沿MA具有這樣的能力將進入消息的任何外部消息協(xié)議轉(zhuǎn)換成中間件系統(tǒng)的本地消息協(xié)議；以及從本地消息協(xié)議轉(zhuǎn)換成外出消息的外部協(xié) 議。即，在消息進入發(fā)布/訂購網(wǎng)絡域(入口)時，外部協(xié)議被轉(zhuǎn)換成本地(例如，Tervda )消息協(xié)議；并且在消息離開發(fā)布/訂購網(wǎng)絡域(出口) 時，本地協(xié)議被轉(zhuǎn)換成外部協(xié)議。邊沿MA的另一個功能是將已發(fā)布的消 息遞送到訂購了的外部數(shù)據(jù)目的地。另外，邊沿和核心MA 106a-b和108a-c都能夠在轉(zhuǎn)發(fā)消息之前存儲消 息?？梢詫崿F(xiàn)該功能的一種方法是利用緩存引擎(CE) 118a-b。 一個或多 個CE可以被連接到相同的MA。理論上，不認為API具有這種存儲轉(zhuǎn)發(fā) 能力，盡管實際上API 110a-b可以在將消息遞送到應用之前存儲消息，并 且其可以在將從應用接收到的消息遞送到核心MA、邊沿MA或者另一個 API之前存儲它們。在MA (邊沿或核心MA)具有到CE的活動連接時，其將被路由的 消息的全部或者子集轉(zhuǎn)發(fā)到CE， CE將它們寫到存儲區(qū)域中以實現(xiàn)持久 性。在預定時間段中，這些消息然后可在被請求時用于重傳。其中實現(xiàn)了 這種特征的示例有數(shù)據(jù)中繼、部分發(fā)布和各種服務質(zhì)量級別。部分發(fā)布在 減少網(wǎng)絡和客戶負載方面是有效的，因為其要求僅發(fā)送更新的信息，而不 是所有信息。為了說明路由選擇圖可能如何實現(xiàn)路由選擇，圖l中示出了發(fā)布/訂購 路由選擇路徑的數(shù)個示例。在該圖示中，發(fā)布/訂購網(wǎng)絡的中間件體系結(jié)構(gòu) 在發(fā)布者和訂購者之間提供了五條或更多的通信路徑。
第一通信路徑將外部數(shù)據(jù)源鏈接到外部數(shù)據(jù)目的地。從外部數(shù)據(jù)源114Ln接收到的已發(fā)布消息被翻譯成本地(例如，Tervela )消息協(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鏈接到一個應用。從外部數(shù)據(jù)源接收到的己發(fā)布的消息在邊沿MA 106a處被翻譯成本地消息協(xié)議，然后被該邊沿MA路由到核心MA 108。 從第一核心MA 108a出發(fā)，這些消息被路由過另一個核心MA 108c到達 API llOb。從該API出發(fā)，這些消息被遞送到訂購應用(例如，1122)。 因為該通信路徑是雙向的，所以在另一個實例中，消息可以沿著反向路徑 從訂購應用112到達外部數(shù)據(jù)目的地116n。在每個實例中，核心MA接 收本地協(xié)議消息并且路由本地協(xié)議消息，而邊沿MA接收外部或者本地協(xié) 議消息，并且分別路由本地或外部協(xié)議消息(邊沿MA將這種外部消息協(xié) 議翻譯成本地消息協(xié)議/從本地消息協(xié)議翻譯成這種外部消息協(xié)議)。每個 邊沿MA可以將入口消息同時路由到本地協(xié)議信道和外部協(xié)議信道。結(jié) 果，每個邊沿MA可以將入口消息同時路由到外部和內(nèi)部客戶，其中內(nèi)部 客戶消耗本地協(xié)議消息，而外部客戶消耗外部協(xié)議消息。這種能力使得消 息傳遞基礎設施能夠與遺留應用和系統(tǒng)無縫并且平滑地集成。被稱作通信路徑3的另一條通信路徑鏈接兩個應用，這兩個應用都利 用API llOa-b。這些應用中的至少一個發(fā)布消息或者訂購消息。已發(fā)布的 消息到訂購應用的遞送或者來自發(fā)布應用的已發(fā)布消息的遞送是利用位于
發(fā)布/訂購網(wǎng)絡邊沿的API實現(xiàn)的。在應用訂購消息時，核心或者邊沿MA之一將消息路由向該API，該API然后在數(shù)據(jù)正準備被遞送到它們時通知 訂購應用。從應用發(fā)布的消息經(jīng)由該API被發(fā)送到該API被"注冊"到其 的核心MA 108c。注意，通過"注冊"(登錄)到一個MA,該API變?yōu)樵谶壿嬌线B接 到該MA。 API通過發(fā)送注冊("登錄"請求)消息到MA來發(fā)起到該 MA的連接。在注冊之后，該API可以通過將其訂購消息發(fā)送到該MA來 訂購特定的感興趣的話題。話題被用于發(fā)布/訂購消息傳遞，來定義共享的 訪問域和消息的目標，因此，訂購一個或多個話題允許接收和發(fā)送具有這 種話題注釋的消息。P&M將周期授權(quán)更新發(fā)送到網(wǎng)絡中的MA，每個MA 相應地更新其自己的表格。因此，如果發(fā)現(xiàn)API要被授權(quán)來訂購特定的話 題(該MA利用路由選擇授權(quán)表來驗證該API的授權(quán))，則該MA激活到 該API的邏輯連接。然后，如果該API被適當?shù)刈缘胶诵腗A 108c，則 核心MA 108c將數(shù)據(jù)路由到第二 API 110，如圖所示。在其他示例中，該 核心MA 108b可以通過額外的一個或多個核心MA (未示出)路由消息， 這一個或多個核心MA將消息路由到API llOb， AP 110b然后將消息遞送 到訂購應用112^?？梢?，通信路徑3不要求存在邊沿MA，因為其不涉及任何外部數(shù)據(jù) 消息協(xié)議。在一個對這里通信路徑給出示例的實施例中，企業(yè)系統(tǒng)被配置 有新聞服務器，該新聞服務器向雇員發(fā)布關于多種話題的最新新聞。為了 接收到新聞，雇員經(jīng)由利用API的新聞瀏覽器應用訂購它們感興趣的話 題。注意，中間件體系結(jié)構(gòu)允許訂購一個或多個話題。此外，這種體系結(jié) 構(gòu)通過允許消息注釋中的通配符，從而利用單個訂購請求訂購一組相關的 話題。被稱作通信路徑4的又一條通信路徑是與P&M系統(tǒng)102和104相關 聯(lián)的多條路徑之一，這些路徑中的每條將P&M鏈接到發(fā)布/訂購網(wǎng)絡中間 件體系結(jié)構(gòu)中的MA之一。在P&M系統(tǒng)和每個MA之間往返的消息是管 理消息，管理消息用于對該MA進行配置和監(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)絡上，該網(wǎng)絡 具有交換機、路由器和其他聯(lián)網(wǎng)設備，并且其采用基于信道的消息傳遞， 該消息傳遞能夠通過任何類型的物理介質(zhì)通信。這種架構(gòu)不可知的基于信 道的消息傳遞的一種示例性實現(xiàn)方式是基于IP的網(wǎng)絡。在這種環(huán)境中，所 有發(fā)布/訂購物理組件之間的所有通信都通過UDP (數(shù)據(jù)報協(xié)議)執(zhí)行， 并且傳輸可靠性由消息傳輸層實現(xiàn)。圖la示出了根據(jù)本原理的覆蓋網(wǎng)絡。如圖所示，覆蓋通信l、 2和3可以經(jīng)由交換機214a-c、路由器216和 子網(wǎng)218a-c在三個核心MA 208a-c之間發(fā)生。換言之，這些通信路徑可以 建立在下層網(wǎng)絡之上，所述下層網(wǎng)絡包括聯(lián)網(wǎng)基礎設施，例如子網(wǎng)、交換 機和路由器，并且如上所述，這種體系結(jié)構(gòu)可以跨越較大的地理區(qū)域(不 同的國家甚至不同的大洲)。明顯地，根據(jù)本發(fā)明原理的前述和其他端到端中間件體系結(jié)構(gòu)可以被 實現(xiàn)在各種商業(yè)環(huán)境中的各種企業(yè)基礎設施中。圖2示出了一種這樣的實 現(xiàn)方式。在該企業(yè)基礎設施中，市場數(shù)據(jù)分發(fā)工廠12被構(gòu)建在發(fā)布/訂購網(wǎng)絡 之上，該發(fā)布/訂購網(wǎng)絡用于將來自各個市場數(shù)據(jù)交換設備320^的股票市 場報價路由到交易員(未示出的應用)。這種覆蓋解決方案依賴于下層網(wǎng) 絡提供例如MA之間和這種MA和P&M系統(tǒng)之間的互連。到API 310^的 市場數(shù)據(jù)遞送是基于應用訂購的。利用這種基礎設施，利用應用(未示 出)的交易員將來自API 310k的交易單通過發(fā)布/訂購網(wǎng)絡(經(jīng)由核心 MA308 a-b和邊沿MA 306b)放置回市場數(shù)據(jù)交換設備320,—n。圖2a中示出了下層物理布署的一個示例。如圖所示，MA被直接彼此 連接，并且被直接插入到網(wǎng)絡和子網(wǎng)，在網(wǎng)絡和子網(wǎng)中消息傳遞流量的客 戶和發(fā)布者被物理連接。在這種情形中，互連應當是直接連接，即，MA 之間的直接連接和它們與P&M系統(tǒng)之間的直接連接。這使得能夠?qū)崿F(xiàn)網(wǎng) 絡骨干網(wǎng)非居間化，以及消息傳遞流量與其他企業(yè)應用流量物理分離。有
效地，MA可以被用來移除對用于消息傳遞流量的傳統(tǒng)路由網(wǎng)絡的依賴。在物理布署的這種示例中，諸如市場數(shù)據(jù)交換設備之類的外部數(shù)據(jù)源或者目的地被直接連接到邊沿MA，例如，邊沿MA 1。諸如市場交易應 用之類的消息傳遞流量消耗或發(fā)布應用被直接連接到子網(wǎng)1-12。這些應用 具有至少兩條路線，用于訂購、發(fā)布或者與其他應用通信。應用可以或者 利用企業(yè)骨干網(wǎng)或者利用消息傳遞骨干網(wǎng)，其中企業(yè)骨干網(wǎng)包括多層冗余 的路由器和交換機，傳送所有的企業(yè)應用流量，例如，消息傳遞流量；消 息傳遞骨干網(wǎng)包括經(jīng)由集成交換機彼此直接互連的邊沿和核心MA。利用替換骨干網(wǎng)具有這樣的優(yōu)點將消息傳遞流量與其他企業(yè)應用流量隔離，從而更好地控制消息傳遞流量的性能。在一種實現(xiàn)方式中，位于子網(wǎng)6中 的應用邏輯或者物理上連接到核心MA 3，利用Tervela API，訂購或者 發(fā)布本地協(xié)議的消息流量。在另一種實現(xiàn)方式中，位于子網(wǎng)7中的應用邏 輯上或者物理上連接到邊沿MA 1，訂購或者發(fā)布外部協(xié)議的消息傳遞流 量，其中MA利用集成的協(xié)議變換引擎模塊執(zhí)行協(xié)議變換。邏輯上，發(fā)布/訂購網(wǎng)絡的物理組件被構(gòu)建在類似于開放系統(tǒng)互連 (OSI)參考模型的1到4層的消息傳輸層之上。OSI模型的1到4層分別 是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層和傳輸層。因此，在本發(fā)明的一個實施例中，發(fā)布/訂購網(wǎng)絡通過例如在所有網(wǎng)絡 交換機和路由器或者網(wǎng)絡交換機和路由器的子集中插入一個或多個消息傳 遞線路卡，從而可以被直接布署到下層網(wǎng)絡/架構(gòu)中。在本發(fā)明的另一個實 施例中，發(fā)布/訂購網(wǎng)絡可以作為網(wǎng)狀覆蓋網(wǎng)絡(其中，所有物理組件都被 彼此連接)而被布署。例如，4個MA的完全網(wǎng)狀網(wǎng)絡是這樣的網(wǎng)絡，其 中，每個MA被連接到其3個對等MA中的每個。在典型實現(xiàn)方式中，發(fā) 布/訂購網(wǎng)絡是下述組件的網(wǎng)狀網(wǎng)絡 一個或多個外部數(shù)據(jù)源和/或目的 地、 一個或多個設置和管理(P&M)系統(tǒng)、 一個或多個消息傳遞設備 (MA)、 一個或多個可選緩存引擎(CE)，以及一個或多個可選應用編 程接口 (API)。后面將更詳細地說明，在企業(yè)操作中，可靠性、可用性和一致性通常 都是必需的。為此，發(fā)布/訂購系統(tǒng)可以被設計為容錯的，其中其組件中的
若干個被布署為容錯系統(tǒng)。例如，MA可以被布署為容錯MA對，其中第一MA被稱作主MA，第二MA被稱作副MA或者容錯MA (FT MA)。 同樣，對于存儲轉(zhuǎn)發(fā)操作，CE (緩存引擎)可以被連接到主或副核心/邊 沿MA。在主或副MA具有到CE的活動連接時，其將所路由的消息的全 部或者子集轉(zhuǎn)發(fā)向該CE，該CE將它們寫入存儲區(qū)域以實現(xiàn)持久性。在預 定時間段內(nèi)，這些消息然后可用于根據(jù)要求用于重傳。
很明顯，遍及發(fā)布/訂購網(wǎng)絡的通信是利用用于與下層傳輸邏輯孤立的 消息的本地協(xié)議實現(xiàn)的。這就是將這種體系結(jié)構(gòu)稱作傳輸透明基于信道的 消息傳遞體系結(jié)構(gòu)的原因。
圖3更詳細地示出了基于信道的消息傳遞體系結(jié)構(gòu)320。 一般而言， 消息傳遞源和目的地之間的每條通信路徑被認為是一條消息傳遞信道。每 條信道326^利用信道源和信道目的地之間的接口 328^通過物理介質(zhì)建 立。每條這樣的信道是針對專門的消息協(xié)議建立的，所述消息協(xié)議例如是 本地(例如，Tervela )消息協(xié)議或其他。僅邊沿MA (對發(fā)布/訂購網(wǎng)絡 的入口和出口進行管理的那些MA)利用信道消息協(xié)議(外部消息協(xié) 議)?；谛诺老f(xié)議，信道管理層324確定進入和外出消息是否要求 協(xié)議翻譯。在每個邊沿MA處，如果進入消息的信道消息協(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ì)相關聯(lián)的 特定網(wǎng)絡和傳輸邏輯、以及消息組件或者片段進行管理。
換言之，信道對到物理層322的OSI傳輸進行管理。對信道資源的優(yōu) 化基于每條信道被執(zhí)行(例如，基于消耗模式對物理介質(zhì)的消息密度優(yōu) 化，所述消耗模式包括帶寬、消息大小分布、信道目的地資源和信道健康 統(tǒng)計)。然后，因為通信信道是架構(gòu)不可知的，所以不要求特定類型的架 構(gòu)。實際上，任何架構(gòu)介質(zhì)都將工作，例如，ATM、 Infiniband或者以太網(wǎng)。順便提及，在例如單個消息被分割到多個幀或者多個消息被打包到中. 個幀中時，可能需要消息分段或重新組裝。消息分段或重新組裝在消息被 遞送到信道管理層之前被執(zhí)行。圖3進一步示出了在具有中間件體系結(jié)構(gòu)的網(wǎng)絡中的多種可能的倍遊 實現(xiàn)方式。在一種實現(xiàn)方式340中，通信是利用通過太網(wǎng)交換的網(wǎng)絡的多 播，經(jīng)由基于網(wǎng)絡的信道執(zhí)行的，其中以太網(wǎng)交換的網(wǎng)絡充當用于這種通信的物理介質(zhì)。在這種實現(xiàn)方式中，源從其IP地址經(jīng)由其UDP端口將消 息發(fā)送向具有其關聯(lián)UDP端口的目的地群組(被定義為IP多播地址)。 在這種實現(xiàn)方式的變體342中，源和目的地之間的通信是利用UDP中-播 通過以太網(wǎng)交換的網(wǎng)絡實現(xiàn)的。源從其IP地址經(jīng)由其UDP端口將消總發(fā) 送向在其相應的IP地址處具有UDP端口的選擇目的地。在另一種實現(xiàn)方式344中，信道是利用本地Infmiband傳輸協(xié)議通過 Infmiband互連建立的，其中Infiniband架構(gòu)是物理介質(zhì)。在這種實現(xiàn)方式 中，信道是基于節(jié)點的，并且源和目的地之間的通信是利用它們各向的節(jié) 點地址基于節(jié)點的。在又一種實現(xiàn)方式346中，信道是基于存儲器的，例 如RDMA (遠程直接存儲器訪問)，并且在這里被稱作直接連接 (DC)。利用這種類型的信道，消息從源機器被直接發(fā)送到目的地機器的 存儲器，從而繞過CPU處理來應對從NIC到應用存儲器空間的消息，并 且可能避免了將消息封裝成網(wǎng)絡分組的網(wǎng)絡開銷。至于本地協(xié)議， 一種方法利用前述本地TervelaTM消息協(xié)議。概念上， Tervela 消息協(xié)議與基于IP的協(xié)議類似。每個消息包含消息頭部和消總 有效載荷。消息頭部包含多個字段，其中一個字段用于話題信息。如上所 述，話題由客戶用來訂購共享的信息域。圖4示出了一個可能的基于話題的消息格式。如圖所示，消息包括頭 部370和主體372和374，主體372和374包括有效載荷。示出了兩類消 息，即，數(shù)據(jù)和管理消息，這兩類消息具有不同的消息體和有效載荷類 型。頭部包括用于以下內(nèi)容的字段源和目的地命名空間標識、源和ll的 地會話標識、話題序列號和希望時間戳，另外，其還包括話題注釋字段
(該字段優(yōu)選是可變長度的)。話題可以被定義為基于標記的字符串，例如，NYSE.RTF.IBM 376，該字符串是包含IBM股票實時報價的消息的話 題字符串。在一些實現(xiàn)方式中，消息中的話題信息可能被編碼或者被映射到一個 關鍵字，關鍵字可以是一個或多個整數(shù)值。然后，每個話題會被映射到一 個唯一的關鍵字，并且話題和關鍵字之間的映射數(shù)據(jù)庫將由P&M系統(tǒng)維 護，并且通過線路被更新到所有MA。結(jié)果，在API訂購或者發(fā)布一個話 題時，MA能夠返回用于消息的話題字段的關聯(lián)的唯一關鍵字。優(yōu)選地，訂購格式將遵循與消息話題相同的格式。但是，訂購格式還 支持與任何話題子字符串匹配或者與話題正則表達式模式匹配的通配符。 對通配符到實際話題的映射的處理可以依賴于P&M系統(tǒng)，或者根據(jù)通配 符或模式匹配請求的復雜度由MA處理。例如，這種模式匹配可以是示例弁1:具有通配符T1AT3.T4的字符串將與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹酉己，《旦是不與T1.T2.T3.T4.T5匹酉己示例弁2:具有通配符T1AT3.T4盧的字符串將不與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹酉己，(i是與T1.T2.T3.T4.T5匹酉己示例#3:具有通配符T1.*.T3.T4.[*](第五個元素可選)的字符串將與 Tl.T2a.T3.T4、 Tl.T2b.T3.T4 、以及T1.T2.T3.T4.T5匹配，但是不與 T1.T2.T3.T4.T5.T6匹酉己示例糾具有通配符T1.T2*.T3.T4的字符串將與Tl.T2a.T3.T4、 Tl.T2b.T3.T4匹配，但是不與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 匹配圖5示出了基于話題的消息路由選擇。如圖所示，話題可以被定義為 基于標記的字符串，例如，T1.T2.T3.T4，其中Tl、 T2、 T3禾n T4是可變 長度的字符串?？梢?，具有特定話題注釋400的進入消息被有選擇地路由 到通信信道404，并且路由選擇確定是基于路由選擇表402作出的。話題
訂購到信道的映射定義路由，并且用來將消息傳遞遍整個發(fā)布/訂購網(wǎng)絡。 所有這些路由或者說訂購和信道之間的映射的超集定義路由選擇表。路由 選擇表也被稱作訂購表。用于利用基于字符串的話題進行路由選擇的訂購 表可以以多種方式被構(gòu)造，但是優(yōu)選配置為對其大小以及路由選擇査找速 度進行優(yōu)化。在一種實現(xiàn)方式中，訂購表可以被定義為動態(tài)散列圖結(jié)構(gòu)， 而在另一種實現(xiàn)方式中，訂購表可以被布置在樹結(jié)構(gòu)中，如圖5中的圖所 示。樹包括由邊連接的節(jié)點(例如，^、…、T1Q)，其中話題訂購的每個 子字符串對應于樹中的一個節(jié)點。映射到給定的訂購的信道被存儲在訂購 的葉子節(jié)點上，每個葉子節(jié)點指示該話題訂購來自的信道的列表(即，通 過其接收到訂購請求)。該列表指示哪個信道應接收其話題注釋與該訂購 匹配的消息的拷貝。如圖所示，消息路由選擇査找將消息話題作為輸入， 然后利用該話題的每個子字符串對樹進行解析，來定位與進入消息話題相 關聯(lián)的不同信道。例如，Tp T2， T3， T4和Ts被導向信道l、 2和3; T,、 T2和T3被導向信道4; TV T6、 T7、 L和T9被導向信道4和5; TP T6， T7， 丁8和丁9被導向信道1;以及Tp T6、 T7、 l和Tn)被導向信道5。盡管對路由選擇表的結(jié)構(gòu)的選擇是要對路由選擇表的查找進行優(yōu)化， 但是查找的性能還取決于用于找到與進入消息話題匹配的一個或多個話題 訂購的搜索算法。因此，路由選擇表結(jié)構(gòu)應當能夠適應這種算法，反之亦 然。減小路由選擇表的大小的一種方式是允許路由選擇算法有選擇地將訂 購傳播遍整個發(fā)布/訂購網(wǎng)絡。例如，如果訂購看來是己被傳播的另一個訂 購的子集(例如，整個字符串的一部分)，則無需傳播該子集訂購，因為 MA已具有該訂購的超集的信息?；谇笆?，優(yōu)選的消息路由選擇協(xié)議是基于話題的路由選擇協(xié)議，其 中授權(quán)在訂戶和相應的話題之間的映射中指示出。授權(quán)是針對每個訂戶或 者訂戶群組/類別指定的，指示該訂購有權(quán)消耗何種消息或者該產(chǎn)生者(發(fā) 布者)可以產(chǎn)生(發(fā)布)哪些消息。這些授權(quán)是在P&M系統(tǒng)中定義的， 被傳輸?shù)桨l(fā)布/訂購網(wǎng)絡中的所有MA，然后被MA用來創(chuàng)建和更新它們的 路由選擇表。
每個MA通過追蹤何人被插入(請求訂購)到何種消息中來更新其路 由選擇表。但是，在將路由添加到其路由選擇表之前，MA必須針對發(fā)布Z訂購網(wǎng)絡的授權(quán)對訂購進行檢查。MA驗證可能是鄰居MA、 P&M系統(tǒng)、 CE或者API的訂購實體被授權(quán)如此執(zhí)行。如果該訂購是有效的，則路由 將被創(chuàng)建并且被添加到路由選擇表。然后，因為一些授權(quán)可能是預先已知 的，所以系統(tǒng)可以被布署以預定義授權(quán)，并且在引導時這些授權(quán)可以被字 段加載。例如，諸如配置更新之類的一些特定管理消息可能總是被轉(zhuǎn)發(fā)遍 網(wǎng)絡，并且因此在啟動時被自動載入。除了其在訂購過程中的角色之外，P&M系統(tǒng)具有多種其他管理功 能。這些額外的功能包括發(fā)布/訂購系統(tǒng)配置和健康健康和報告。配置涉及 對發(fā)布/訂購系統(tǒng)網(wǎng)絡和組件的物理和邏輯配置。監(jiān)控和報告涉及對所有網(wǎng) 絡和系統(tǒng)組件的健康進行監(jiān)控并且自動報告結(jié)果，這是按照要求進行的或 者被記入日志。圖6是示出根據(jù)本發(fā)明一個實施例的設置和管理(P&M)系統(tǒng)的框 圖。如圖所示，P&M系統(tǒng)500可以被部署為與發(fā)布/訂購網(wǎng)絡中的一個或 多個MA通信的孤立裝置。在可替換的實施例中，P&M系統(tǒng)可以被集成 到MA中。P&M系統(tǒng)通過管理消息執(zhí)行其配置、監(jiān)控和報告功能，所述管理消 息是從裝置消息層502中的管理消息層506獲得的。與網(wǎng)絡中其它組件的 通信是通過具有所有上述信道管理的消息傳輸層504完成的，上述信道管 理對于根據(jù)本發(fā)明原理配置的系統(tǒng)中的組件來說是典型的。然而，不同于 直接與物理介質(zhì)接口交互的MA中的消息傳輸層，P&M系統(tǒng)經(jīng)常實現(xiàn)在 操作系統(tǒng)528 (OS)之上，消息傳輸層通過該OS與物理介質(zhì)接口 (接口 l...N)通信。因此，為了支持各種類型的通道，對于可能沒有其他方式對 OS可用的每種物理介質(zhì)，OS可能要求特定的驅(qū)動器。對于該介質(zhì)，OS 可能還要求特定的接口卡(例如，直接連接接口卡或者Infmiband接口 卡)。P&M系統(tǒng)還使用網(wǎng)絡管理棧508來與基于網(wǎng)絡的管理服務通信。這種 基于網(wǎng)絡的服務的示例包括SNMP (簡單網(wǎng)絡管理協(xié)議)、syslog、HTTP/HTTPS (基于安全套接字層的超文本傳送協(xié)議)，Telnet/SSH (安 全殼協(xié)議)。P&M可以具有構(gòu)建在多個功能塊之上的圖形用戶界面(GUI) 510。 這些功能塊的示例包括配置管理器512、實時監(jiān)控模塊514、歷史趨勢塊 516，以及商業(yè)邏輯/應用報告塊518。配置管理器功能塊對發(fā)布/訂購網(wǎng)絡 中包含的所有物理組件的配置進行處理。這些組件中的每個的配置520涉 及多個方面，包括例如安全性、加密、認證、授權(quán)(關于允許哪些用戶訂 購何種話題的權(quán)限)、以及拓撲(包括這些不同的組件直接的通信路 徑)。實時監(jiān)控功能塊514監(jiān)聽(嗅探)在發(fā)布/訂購網(wǎng)絡中發(fā)生的各種事件 522。這些事件的示例包括來自API的新訂購請求、連接到發(fā)布/訂購網(wǎng)絡 的新訂戶、對聯(lián)網(wǎng)的發(fā)布/訂購系統(tǒng)中的不同硬件組件的實時統(tǒng)計、所有 MA的路由選擇表的大小，以及資源利用水平。歷史趨勢塊516優(yōu)選被緊密鏈接到實時監(jiān)控系統(tǒng)，因為趨勢可以根據(jù) 被實時監(jiān)控的事件隨事件而被建立。就此而言，歷史趨勢塊從實時監(jiān)控子 系統(tǒng)獲取其輸入，在實時數(shù)據(jù)庫中存儲每個數(shù)據(jù)點。歷史趨勢塊然后可以 查詢該實時數(shù)據(jù)庫，并且將其取回的事件作為時間的函數(shù)繪制出圖表。該 塊可以進一 步被用來追蹤發(fā)布/訂購網(wǎng)絡隨時間的行為模式。商業(yè)邏輯報告塊518通過將隨時間變化的事件模式的未經(jīng)處理數(shù)據(jù)相 關聯(lián)來提供另一個級別的報告，以便幫助實現(xiàn)商業(yè)判決實現(xiàn)過程。在一種 實現(xiàn)方式中，商業(yè)邏輯報告塊將低層消息和網(wǎng)絡度量數(shù)據(jù)(一般是未經(jīng)處 理數(shù)據(jù))翻譯成商業(yè)度量，網(wǎng)絡度量數(shù)據(jù)的示例包括消息和幀速率、網(wǎng)絡 延遲、抖動和丟失數(shù)據(jù)。另外可選地，實時監(jiān)控和商業(yè)邏輯報告塊被用來監(jiān)控服務級別協(xié)議 (SLA)，并且驗證隨時間變化特定的服務級別是否得到滿足。在SLA未 得到滿足時，其允許理解并且獲得問題在于何處和問題是如何被觀察到的 合法證據(jù)，假設所有方都同意這種報告的有效性。此外，建立歷史度量的 趨勢可能有助于幫助理解消息基礎設施中的改變，并且其可能使得能夠洞 悉長期消息傳遞流量模式。結(jié)果，其成為商業(yè)判決處理中非常有價值的輸入。另外，P&M系統(tǒng)允許管理員定義一個消息命名空間，該消息命名空 間與在整個給定的發(fā)布/訂購網(wǎng)絡中路由的消息中的每一個相關聯(lián)。因此， 發(fā)布/訂購網(wǎng)絡可以被物理地和/或邏輯地分成基于命名空間的子網(wǎng)。這種 基于命名空間的拓撲在圖7中示出。命名空間對于每個發(fā)布/訂購子網(wǎng)來說 是唯一的。因此，在組合的發(fā)布/訂購網(wǎng)絡中，每個發(fā)布/訂購子網(wǎng)具有指 派給它的唯一的命名空間。在本示例中，發(fā)布/訂購網(wǎng)絡由兩個發(fā)布/訂購 子網(wǎng)組成，就具有命名空間"命名空間1"的第一個和具有命名空間"命名空間2"的第二個。實際上，命名空間管理特征(在圖6的項目520、512中)提供這樣的能力定義不同的管理域并且允許穿越這些不同的管理域的基于話題的消息通信同時避免話題沖突或復制。在一個示例中，發(fā)布/訂購子網(wǎng)"A"發(fā)布向發(fā)布/訂購子網(wǎng)"B"路由 的新聞更新，并且子網(wǎng)"C"發(fā)布也向子網(wǎng)"B"路由的新聞更新。然而， 如果子網(wǎng)"A"和"C"發(fā)布關于同一話題的相同的新聞更新，則子網(wǎng) "B"可以因為它們相關聯(lián)的命名空間而區(qū)分來自"A"的新聞和來自 "C"的新聞。在許多示例中，這些命名空間域?qū)⑹遣煌慕M織內(nèi)部域。 在其它示例中，這些域?qū)⑹遣煌慕M織或者合法實體域。換言之，命名空 間特征可以被一個組織用來將對其數(shù)據(jù)或內(nèi)容的授權(quán)限制到組織內(nèi)或組織 外的某些用戶。對于組織內(nèi)的用戶，這是通過向這些用戶發(fā)送命名空間許 可而完成的；而對于該組織外的用戶，這是通過向向這些用戶提供MA的 組織發(fā)布命名空間許可證實現(xiàn)的。如上所述，系統(tǒng)組件的配置和監(jiān)控兩者都是通過管理消息的通信執(zhí)行 的。因此，為了與MA通信，P&M系統(tǒng)使用基于信道的消息傳遞棧508 (以及消息層502、消息傳輸層504和信道管理526)。圖8是示出P&M 系統(tǒng)和MA中的一個之間的通信的圖?，F(xiàn)在轉(zhuǎn)向消息傳遞設備(MA)，圖9是示出根據(jù)本發(fā)明原理而配置 的MA的框圖。在本發(fā)明的一種實現(xiàn)方式中，MA是孤立的設備。在另一 種配置中中，MA是諸如路由器或交換機之類的任何網(wǎng)絡物理組件內(nèi)部的 嵌入式組件。在所示MA的實施例中，它被分成三個不同的功能部分。第 一部分602包括上述網(wǎng)絡管理服務(例如NTP、 SNMP、 Syslog 、 Telnet/SSH、 HTTP/HTTPS等)。這些服務是在諸如TCP/IP棧604之類的 標準網(wǎng)絡棧之上建立的，并且它們例如可以使用專用以太網(wǎng)網(wǎng)絡接口卡 (NIC) 606。在一個實施例中，專用NIC的使用提供了一種將管理流量與 數(shù)據(jù)消息傳遞流量物理上隔離的方式。第二部分被定義為消息傳遞棧 608，消息傳遞棧608具有在上部的消息層(例如TervelaTM消息層)610 和在其下面的傳輸消息層612。消息傳遞棧608處理任何進入MA或者從 MA出去的消息傳遞流量。第三部分614包括內(nèi)部服務。這些服務在MA 內(nèi)使用，并且沒有任何直接外部接口。這些內(nèi)部服務的示例包括諸如本地 和遠程管理、記錄、實時監(jiān)控和歷史趨勢服務之類的系統(tǒng)管理服務?？梢?通過內(nèi)部通信總線616用來自上述第一和第二部分中的任何部分的呼叫來 請求內(nèi)部服務。換言之，這些內(nèi)部服務通過由本地消息傳遞層610產(chǎn)生的管理消息或 者經(jīng)由網(wǎng)絡管理棧602而間接與P&M系統(tǒng)通信。它們追蹤系統(tǒng)的常規(guī)健 康，包括特定的性能量度以及消息傳遞層和下層的物理介質(zhì)的統(tǒng)計。這些 統(tǒng)計可以在每個信道的基礎上被存儲，或者它們可以通過計算整個系統(tǒng)的 隨時間變化的移動加權(quán)平均而被聚集。除了上述內(nèi)部服務之外，另一種內(nèi)部服務是時間戳服務(TSS) 624， TSS 624可以用于請求精確的時間戳。在一種配置中，TSS基于由MA直 接接收的GPS信號?；蛘撸褂肕A的內(nèi)部處理器時鐘而不是GPS信 號。然而，時鐘需要被周期性地更新并且與外部時間源同步。網(wǎng)絡時間協(xié) 議(NTP)或者另一個相當?shù)脑唇?jīng)常被用于該目的并且在這里也是合適 的。對于具有多個MA的系統(tǒng)來說，通過使用諸如NTP之類的標準網(wǎng)絡 時間協(xié)議，內(nèi)部TSS可以在多個MA之間被同步。尤其是， 一個主MA將 被同步于外部時間源，然后，發(fā)布/訂購網(wǎng)絡中的鄰近MA將它們自己與主 MA同步。MA之間的時間同步可以通過使用特定的管理消息協(xié)議來交換 時間信息而被實現(xiàn)?；蛘撸瑫r間同步可以用嵌入在每個數(shù)據(jù)消息中的時間 信息來實現(xiàn)，每個數(shù)據(jù)消息在整個發(fā)布/訂購網(wǎng)絡中路由。在所示出的MA中，本地(例如Tervela )消息傳遞層610具有許多
角色，這些角色中的兩個是路由本地協(xié)議消息和處理本地管理消息。管理 消息可以是API的注冊請求、來自API的訂購請求、來自P&M系統(tǒng)的配 置更新等等。管理消息通常是具有特定管理話題的標準消息。因此，MA將必須在任何消息可以在MA中本地傳遞之前訂購特定管理消息(至管理話題)。初始管理話題訂購可以被作為"靜態(tài)"(混合)路線插入在路由 表中，這些靜態(tài)路線在系統(tǒng)中被預定義，用于管理消息的傳遞。這些所謂的靜態(tài)路線將管理訂購本地路由到特定的MA，該特定的MA向消息路由 弓I擎指示其應該本地傳遞匹配管理消息。無論何時消息在MA中產(chǎn)生并且被該MA路由或者被經(jīng)由該MA轉(zhuǎn) 發(fā)，消息路由引擎(MRE) 620都搜索具有與消息話題匹配的訂購的信 道。希望路由表的查找將返回滿足這個標準的一個或多個信道的列表。然 而，如果返回的信道列表為空，則消息將被丟棄而不是轉(zhuǎn)發(fā)。另外，如果 返回的信道列表不為空，則消息的副本將被發(fā)送到該列表中的每一個信 道。優(yōu)選地，信道管理模塊不是發(fā)送消息的單獨副本到每個信道，而是僅 將消息的一個副本保持在存儲器中，并且其另外留意多少個信道正在獲得 和傳輸該信息。當所有信道完成在它們自己的物理介質(zhì)上發(fā)送消息時，引 用計數(shù)回到零，然后信道管理可以釋放分配給該消息的存儲器。這是如何 優(yōu)化系統(tǒng)資源的分配和使用的一個示例，該這種情況中，存儲緩沖器在消 息傳輸層中。注意到在MRE 620將消息傳遞到用于所有需要消息副本的信道的消息 傳輸層612之前，MRE獲得并基于對這些信道上的消費模式和分配給這些 信道的系統(tǒng)資源的統(tǒng)計。該監(jiān)控和統(tǒng)計跟蹤任務是通過協(xié)議優(yōu)化服務 (POS)執(zhí)行的。如果POS確定在源、目的地或者兩者處的系統(tǒng)和信道資源未被最優(yōu)地 使用，則其可以調(diào)整信道配置，或者甚至創(chuàng)建新的信道，這個新的信道將 更好地使用系統(tǒng)和信道資源。例如，通過監(jiān)控與系統(tǒng)和信道資源相關聯(lián)的 量度，例如延遲和丟棄率，POS可以在這些量度高于或低于預定閾值的情 況下改變信道通信協(xié)議。丟棄率被定義為從所接收消息的總數(shù)中舍棄的消 息的百分比。消息在它們被經(jīng)由多播信道傳遞到它們的目的地(例如 API)并且目的地沒有相同的訂購模式時被舍棄。如果丟棄率超過百分比 閾值，則MA可以決定將信道通信從多播切換至單播，或者在現(xiàn)有的多播 信道上重新分布訂購。如上所述，發(fā)布/訂購網(wǎng)絡可以建立在基于IP的網(wǎng)絡之上。在這種情 況中，MA可以具有多個單播信道，多個單播信道具有不同的客戶，這些 客戶訂購相同的話題。所有這些信道可以共享相同的介質(zhì)帶寬。如果消息速率急劇增加，則MA在必須將同一消息的多個副本發(fā)送到所有客戶的情 況下可能不再高效地使用介質(zhì)的可用帶寬。因此，POS可能決定從基于單 播的信道協(xié)議切換至基于多播的信道協(xié)議，該基于多播的信道協(xié)議將向位 于同一介質(zhì)上的所有客戶僅發(fā)送消息的一個副本。為了從一種類型的信道 協(xié)議切換至另一種類型的信道協(xié)議，在MA 600上運行的POS 622模塊將 通知(一個或多個)API上的POS,需要創(chuàng)建另一個信道以優(yōu)化信道資 源。當信道被創(chuàng)建并且就緒時，MA從舊的信道切換到新的信道。然后，對于邊緣MA的特定情況，當信道將進入的消息傳遞到信道管 理模塊時，第一個檢查是驗證消息協(xié)議是否不同于本地消息協(xié)議。如果確 實不同，則信道管理模塊將請求協(xié)議翻譯引擎618把進入的消息轉(zhuǎn)換為本 地(例如Tervda )消息協(xié)議。當消息被轉(zhuǎn)換時，其被傳給(Tervda ) 消息傳遞層610。另外，在核心MA的情況中，當信道處理進入的消息 時，消息被傳給假設所有信道在使用本地消息協(xié)議的本地(Tervda )消 息傳遞層，因此，所有消息已經(jīng)具有本地消息格式。如前所述，所有在發(fā)布/訂購網(wǎng)絡中被路由的消息都在特定信道(見消 息傳輸層612內(nèi)部)上被接收或者發(fā)送。MA用這些信道與發(fā)布/訂購網(wǎng)絡 中的所有其它物理組件通信。這些通信接口被在圖中表示，其中，在圖8 中，接口被示出用于P&M系統(tǒng)和MA之間的通信，在圖10中，接口被示 出用于MA和CE (緩存引擎)之間的通信，以及在圖11中，接口被示出 用于MA和API之間的通信。有時候這些接口被中斷或者目的地不能跟上負荷。在這些情形或其它 類似情形中，消息可以被從存儲裝置讀回并且被重新發(fā)送。因此，無論何 時需要諸如存儲和轉(zhuǎn)發(fā)功能的消息數(shù)據(jù)存儲，MA都可以有效地與緩存引 擎(CE)相關聯(lián)。CE通過物理介質(zhì)直接連接到MA (如圖1和圖10所示)，并且其被設計為在高容量和低延遲消息傳遞環(huán)境中提供存儲轉(zhuǎn)發(fā)體系結(jié)構(gòu)的特征。圖12是示出根據(jù)本發(fā)明一個實施例而配置的CE的框圖。CE 700執(zhí)行許多功能。對于消息數(shù)據(jù)持久性， 一個功能涉及接收由 MA所轉(zhuǎn)發(fā)的數(shù)據(jù)消息、用不同的消息頭部字段對它們做索引并且將它們 存儲在存儲區(qū)域710中。另一個功能涉及對來自MA的消息取回請求進行 響應并且重新發(fā)送被丟失或未接收到的消息(并且被客戶再次這樣請 求)。一般來說，CE建立在與MA相同的邏輯層之上。然而，其本地(例 如Tervela )消息傳遞層被大大簡化。因為與被路由到發(fā)布/訂購網(wǎng)絡中 的另一個物理組件相比，所有消息都在CE處被本地處理并傳遞到其管理 消息層714或其緩存層702，所以不需要路由引擎邏輯。如前所述，管理 消息除了用于被轉(zhuǎn)發(fā)到緩存層702的取回請求之外，通常用于管理目的。 所有的數(shù)據(jù)消息被轉(zhuǎn)發(fā)到緩存層，緩存層使用索引服務712來首先對消息 做索引，然后用存儲服務708將消息存儲在存儲區(qū)域701中。所有的數(shù)據(jù) 消息都被存儲預定義的時間段。索引服務712負責"垃圾收集"活動并且 通知存儲服務708需要什么時候從存儲區(qū)域舍棄過期的數(shù)據(jù)消息。除了CE之外，MA還與前述的API通信。圖13是根據(jù)本發(fā)明一個實 施例而配置的API的框圖。所示出的API 800是API通信引擎802和API存根(stub) 804的組 合，API存根804遵從并且鏈接到使用該API的所有應用程序806。通信 引擎的一個實現(xiàn)方式是可以是數(shù)據(jù)守護程序(daemon) 。 API存根和API 通信引擎之間的通信是通過進程間通信總線808完成的，進程間通信總線 808是用諸如套接字或者共享存儲器之類的機制實現(xiàn)的。API存根804在 包括C、 C++、 Java和.NET的各種編程語言中可用。在一些示例中，API 本身可以在各種語言中可用。API在各種操作系統(tǒng)平臺上運行，這些操作 系統(tǒng)平臺的三種示例是Windows 、 Linux 和Solaris ?；蛘撸珹PI通信 引擎和存根可以在編譯時與像單片API—樣的應用程序合并，以消除對在 應用服務器上產(chǎn)生另外進程的需要。
與CE很像，API通信引擎建立在可以在MA中找到的邏輯層上。為了能夠與MA通信，API也具有消息傳輸層810。然而，因為不同于直接 與物理介質(zhì)接口交互的MA， API在大多數(shù)的實現(xiàn)方式中都位于操作系統(tǒng) 之上(與具有P&M系統(tǒng)的情況一樣)，所以API和MA中的消息傳輸層 彼此不同。為了支持不同類型的信道，對于在缺省的情況下不被OS以其 它方式支持的每種物理介質(zhì)，OS可以要求特定驅(qū)動器用于每種物理介 質(zhì)。OS也可以要求用于插入特定的物理介質(zhì)卡。例如，諸如直接連接 (DC)或Infmiband之類的物理介質(zhì)要求特定接口卡，并且要求其相關聯(lián) 的OS驅(qū)動器允許消息傳輸層在信道上發(fā)送消息。API中的消息傳遞層812也與MA中的消息傳遞層有些類似。然而， 主要的差別在于進入的消息在API和MA中分別沿著不同的路徑。在API 中，數(shù)據(jù)消息被發(fā)送到應用傳遞路由引擎814 (較少的模式綁定)，并且 管理數(shù)據(jù)被發(fā)送到管理消息層816。應用傳遞路由引擎除了不是將信道映 射到訂購，而是將應用程序(806)映射到訂購之外，表現(xiàn)得與消息路由 引擎818類似。因此，當進入的消息到達時，應用傳遞路由引擎査找所有 的訂購應用程序，然后將該消息的副本或者對該消息的引用發(fā)送到它們?nèi)?部。在一些實現(xiàn)方式中，應用傳遞路由引擎負責遲模式綁定特征。如前所 述，本地(Tervela )消息傳遞協(xié)議以原始和壓縮格式提供信息，該格式 不包含下層的數(shù)據(jù)的結(jié)構(gòu)和定義。因此，消息傳遞系統(tǒng)有利地減小其帶寬 利用，并且又允許增加的消息容量和吞吐量。當API接收到數(shù)據(jù)消息時， API將原始數(shù)據(jù)綁定到其模式，允許應用程序透明地訪問信息。模式通過 提供字段命名、字段類型和其在消息體中的偏移位置之間的映射而定義消 息的內(nèi)容結(jié)構(gòu)。因此，應用程序可以請求特定字段命名而不用知道其在消 息中的位置，并且API使用偏移來定位該信息并將其返回到應用程序中。在很大程度上，外出的消息使用與MA中相同的輸出邏輯。在該示例 中，API具有協(xié)議優(yōu)化服務(POS) 820，該POS 820跟蹤關于消費模式以 及系統(tǒng)和信道資源利用的統(tǒng)計(與在MA中一樣完成)。然而，不同于對 什么時候改變信道配置作出其自己決定的MA中的POS， API中的POS充
當其所鏈接到的MA中的主POS的從屬。當MA上的POS決定改變信道 配置時，其遠程地控制API處的從POS。如上所述，對于系統(tǒng)的可用性和可靠性以及消息數(shù)據(jù)的一致性和持久 性，有利的是將系統(tǒng)配置為容錯系統(tǒng)。優(yōu)選地，系統(tǒng)被設計為具有如圖14 所示的基于會話的容錯配置。另一種可能的配置是完全的失效備援 (failover)，但是在本示例中，我們選擇基于會話的容錯。會話包括兩個MA之間或者一個MA和一個API (例如910)之間的 通信。會話可以是主動的或被動的。該配置使用主MA和副MA (例如 906和908)。如果發(fā)生失效，則MA或者API可以決定將會話從主MA 906切換到副MA 908。當會話經(jīng)歷連通性和/或諸如CPU、存儲器、接口 等之類的系統(tǒng)資源的失效時，發(fā)生失效。連通性問題是按照下層的信道而 定義的。例如，當丟失、延遲和/或抖動隨時間變化而不正常地增加時，基 于IP的信道將經(jīng)歷連通性問題。對于基于存儲器的信道來說，連通性問題 可以按照存儲器地址沖突等來定義。總的來說，基于會話的容錯設計具有在所有會話中的僅一個或者一個 子集在經(jīng)歷問題時不影響所有會話的優(yōu)點。也就是說，當會話經(jīng)歷一些性 能問題時，該會話被從主MA (例如906)移至副容錯(FT) MA 908，而 不影響與主MA 906相關聯(lián)的其它會話。因此，例如APIl-4被示出仍然具 有它們各自的與主MA 902 (作為主動MA)的主動會話，而API5具有與 FT MA 908的主動會話。主MA和副MA可以被看作使用某種基于信道的邏輯以將邏輯信道地 址映射到物理信道地址的單個MA。例如，對于基于IP的信道，API或者 MA可以通過更新MA邏輯地址的ARP緩存條目使其指向副MA的物理 MAC地i止，而將有問題的會話定向到副MA?？傊?，本發(fā)明提供了一種用于消息傳遞的新方法，更具體地說，提供 了一種改善消息傳遞系統(tǒng)效用的端到端的中間件體系結(jié)構(gòu)。雖然參考其某 些優(yōu)選版本，用相當多的細節(jié)描述了本發(fā)明，但是其它版本也是可以的。 因此，所附權(quán)限要求書的精神和范圍不應局限于包含在這里的優(yōu)選版本的 描述。
權(quán)利要求
1. 一種具有中間件體系結(jié)構(gòu)的系統(tǒng)，該系統(tǒng)包括 一個或多于一個消息傳遞設備，被配置為用于接收并路由消息； 互連；以及設置和管理系統(tǒng)，通過所述互連而鏈接并且被配置為用于與每個消息 傳遞設備交換管理消息，其中，每個消息傳遞設備還被配置為用于通過實時地動態(tài)地選擇消息 傳輸協(xié)議和消息路由路徑而執(zhí)行消息的路由。
2. 如權(quán)利要求1所述的系統(tǒng)，其中，所述設置和管理系統(tǒng)被配置為用 于執(zhí)行與所述管理消息相關聯(lián)的功能，所述功能包括系統(tǒng)配置、健康和性 能監(jiān)控和報告。
3. 如權(quán)利要求1所述的系統(tǒng)，其中，所述供應裝置被配置為用于管理 訂購，所述訂購包括客戶和外部數(shù)據(jù)目的地對一個或多個數(shù)據(jù)消息話題的 訂購以及消息傳遞設備對管理消息話題的訂購。
4. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備包括邊緣消息 傳遞設備和核心消息傳遞設備中的一個或多個。
5. 如權(quán)利要求1所述的系統(tǒng)，其中，每個邊緣消息傳遞設備被鏈接到 消息變換引擎，該消息變換引擎用于將進入的消息從外部協(xié)議變換為本地 協(xié)議并且用于將所路由的消息從所述本地協(xié)議變換為所述外部協(xié)議。
6. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳輸協(xié)議被選擇為單 播、多播或者廣播協(xié)議之一。
7. 如權(quán)利要求1所述的系統(tǒng)，還包括一個或多個應用編程接口，所述 應用編程接口被配置為用于在一個或多個應用程序和所述消息傳遞設備中 的一個之間進行接口連接。
8. 如權(quán)利要求7所述的系統(tǒng)，其中，所述消息傳遞設備和所述一個或多個應用編程接口用于通過在單個幀中包含一條或多條消息而彼此通信。
9. 如權(quán)利要求1所述的系統(tǒng)，其中，所述應用程序中的每一個被配置 為用于將包括注冊和訂購請求的請求發(fā)送到所述消息傳遞設備中的相應一 個，其中，所述設置和管理系統(tǒng)還被配置為用于處理數(shù)字權(quán)限管理，其中 每個相應的消息傳遞設備向所述設置和管理系統(tǒng)確認并報告試圖向其注冊 或訂購的應用是否被授權(quán)這樣作。
10. 如權(quán)利要求1所述的系統(tǒng)，其中，所述應用編程接口中的每一個 被邏輯地鏈接到消息傳遞設備，該消息傳遞設備被通過基于話題的訂購而 注冊到所述應用編程接口中的所述每一個。
11. 如權(quán)利要求IO所述的系統(tǒng)，其中，所述消息傳遞設備包括所述應 用編程接口所注冊到的一個或多個消息傳遞設備。
12. 如權(quán)利要求1所述的系統(tǒng)，其中，所述訂購是基于話題的并且每 一個都被通過訂購請求而建立，并且單個訂購請求能夠建立對一組相關話 題的訂購。
13. 如權(quán)利要求1所述的系統(tǒng)，其中，所述互連是互連網(wǎng)絡，所述消 息傳遞設備以及設置和管理系統(tǒng)被部署在所述網(wǎng)絡上，所述網(wǎng)絡配置有任 何數(shù)目的路由器、交換機和子網(wǎng)。
14. 如權(quán)利要求1所述的系統(tǒng)，其中，其中所述互連是基于信道的、網(wǎng)絡構(gòu)造無關的物理介質(zhì)。
15. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備、設置和管 理系統(tǒng)以及互連包含傳輸邏輯。
16. 如權(quán)利要求15所述的系統(tǒng)，被配置為用于傳輸透明基于信道的消 息傳遞，其中消息被以孤立于所述傳輸邏輯的本地協(xié)議格式傳送。
17. 如權(quán)利要求1所述的系統(tǒng)，還包括一個或多個外部源和外部目的 地，其中，所述消息傳遞設備包括一個或多個邊緣消息傳遞設備和一個或 多個核心消息傳遞設備，每個邊緣消息傳遞設備都與協(xié)議翻譯引擎相關 聯(lián)，并且在外部協(xié)議和本地協(xié)議之間翻譯消息，每個核心消息傳遞設備都 進行具有所述本地協(xié)議的消息的通信，所述外部源和目的地與所述邊緣消 息傳遞設備通信，所述邊緣消息傳遞設備又使用基于鄰居的消息路由與所 述核心消息傳遞設備通信。
18. 如權(quán)利要求17所述的系統(tǒng)，其中，邊緣MA用于將進入的消息同 時路由到本地協(xié)議客戶和外部協(xié)議客戶兩者。
19. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息是用模式和有效負荷 構(gòu)建的，所述模式和有效負荷在消息進入所述系統(tǒng)時被彼此分開并且在消 息離開所述系統(tǒng)時被合并。
20. 如權(quán)利要求1所述的系統(tǒng)，其中，所述設置和管理系統(tǒng)執(zhí)行命名 空間管理功能，該命名空間管理功能包括數(shù)字權(quán)限管理。
21. 如權(quán)利要求1所述的系統(tǒng)，其中，利用所述命名空間管理，訂購 了與特定命名空間相關聯(lián)的話題的客戶或者外部目的地被授權(quán)發(fā)布和訂購 用這樣的話題所標識的消息。
22. 如權(quán)利要求1所述的系統(tǒng)，其中，每個消息傳遞設備具有路El:l 表，消息在消息傳遞設備之間的路由是基于鄰居的，以使得每個消息傳遞 設備被配置為用于將消息經(jīng)由其信道之一路由到訂購了經(jīng)由該信道所傳輸 的消息的全部或者一個子集的鄰居，并且，每個消息傳遞設備還被配置為 用于優(yōu)化其訂購和信道之間的映射，以減小在僅訂購所述消息的一個子集 的鄰居處的丟棄率。
23. 如權(quán)利要求1所述的系統(tǒng)，其中，所述路由表具有多個結(jié)構(gòu)中的一個，所述結(jié)構(gòu)中的兩個是樹結(jié)構(gòu)和動態(tài)具有圖結(jié)構(gòu)。
24. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息和管理消息具有基于 話題的格式，每個消息具有頭部和有效負載，所述頭部除了包括源和目的 地命名空間標識字段之外，還包括話題字段。
25. 如權(quán)利要求24所述的系統(tǒng)，其中，所述話題字段包括可變長度的 串或關鍵字，所述關鍵字是一個唯一值，其中針對多個關鍵字，所述設置 和管理系統(tǒng)配置有用于保持每個這樣的關鍵字和其相應的話題之間的映射 的數(shù)據(jù)庫，所述設置和管理系統(tǒng)還被配置為用于關于該映射中的任何變化 而更新所述消息傳遞設備中的每一個。
26. 如權(quán)利要求24所述的系統(tǒng)，其中，所述消息包括具有話題字段的 訂購消息，該話題字段具有可變長度的串，該串具有用于將其與所提供的 任何話題子串匹配的任何數(shù)目的通配符，以使得這樣的話題和所述訂購消 息具有相同數(shù)目的話題子串。
27. 如權(quán)利要求1所述的系統(tǒng)，其中，傳輸協(xié)議和消息路由路徑的所述動態(tài)選擇基于系統(tǒng)拓撲、來自所述設置和管理系統(tǒng)的健康和性能報告，并且其涉及動態(tài)資源分配和動態(tài)信道創(chuàng)建和/或選擇中的一者或者兩者都涉及。
28. 如權(quán)利要求1所述的系統(tǒng)，具有超越地區(qū)、國家或者大洲界限的 邊界，在每個地區(qū)、國家或者大洲中具有子系統(tǒng)，其中所述子系統(tǒng)被通過 聯(lián)網(wǎng)基礎設施鏈接并且每個子系統(tǒng)包括設置和管理系統(tǒng)、互連和一個或多 個消息傳遞設備。
29. 如權(quán)利要求1所述的系統(tǒng)，其中，所述設置和管理系統(tǒng)被集成到 所述消息傳遞設備之一 中或者被實現(xiàn)為孤立裝置。
30. 如權(quán)利要求1所述的系統(tǒng)，其中，每個消息傳遞設備包括鏈接到物理接口管理功能塊的網(wǎng)絡管理棧；包含系統(tǒng)管理服務功能塊和時間戳 服務功能塊的服務塊，所述系統(tǒng)管理服務功能塊和時間戳服務功能塊兩者 都通過網(wǎng)絡管理內(nèi)部通信邏輯總線鏈接到所述網(wǎng)絡管理桟；以及與消息傳 輸層通信的本地消息層，所述消息傳輸層和本地消息層兩者都通過消息傳 遞內(nèi)部通信邏輯總線鏈接到所述服務塊。
31. 如權(quán)利要求30所述的系統(tǒng)，其中，所述本地消息層包括管理消息 層、消息路由引擎、消息傳輸和消息接收邏輯，以及主協(xié)議優(yōu)化服務。
32. 如權(quán)利要求30所述的系統(tǒng)，其中，所述消息傳輸層包括信道管 理，并且，消息路由路徑的所述動態(tài)選擇包括信道的選擇和/或創(chuàng)建。
33. 如權(quán)利要求32所述的系統(tǒng)，其中，每個信道被配置為用于基于網(wǎng) 絡、基于節(jié)點或者基于存儲器的傳輸協(xié)議，并且與到網(wǎng)絡構(gòu)造無關的物理 介質(zhì)的物理接口相關聯(lián)。
34. 如權(quán)利要求33所述的系統(tǒng)，其中，所述物理介質(zhì)被配置為以太 網(wǎng)、基于存儲器的直接連接或者Infiniband。
35. 如權(quán)利要求1所述的系統(tǒng)，其中，所述設置和管理系統(tǒng)包括鏈接 到配置功能塊和監(jiān)控功能塊的消息傳輸層和本地消息層，所述監(jiān)控模塊又 通過進程間通信總線連接到管理塊，所述管理塊包括配置管理、實施監(jiān) 控、歷史趨勢和應用業(yè)務報告功能塊。
36. 如權(quán)利要求35所述的系統(tǒng)，其中，所述設置和管理系統(tǒng)還包括下 列中的一者或者兩者都包括 一側(cè)連接到所述監(jiān)控功能塊并且另一側(cè)連接 到所述操作系統(tǒng)的所述網(wǎng)絡棧的網(wǎng)絡管理服務；以及連接到所述管理塊的 用戶接口。
37. 如權(quán)利要求32所述的系統(tǒng)，其中，所述互連包括所述傳輸信道和 物理介質(zhì)，所述消息傳遞設備通過所述傳輸信道和物理介質(zhì)與所述設置和 管理系統(tǒng)通信。
38. 如權(quán)利要求1所述的系統(tǒng)，還包括一個或多個緩存引擎，每個緩存引擎操作連接到相應的消息傳遞設備，用于提供服務質(zhì)量功能，包括消 息數(shù)據(jù)存儲和轉(zhuǎn)發(fā)功能。
39. 如權(quán)利要求38所述的系統(tǒng)，其中，每個緩存引擎包括與本地消息 層連接的緩存層，所述本地消息層又連接到消息傳輸層，其中所述緩存層 包括存儲裝置、存儲服務和索引服務。
40. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備中的一個或 多個通過應用編程接口操作連接到應用，該應用編程接口被注冊到這樣的 消息傳遞設備，并且在所述應用和所述消息傳遞設備之間傳遞數(shù)據(jù)。
41. 如權(quán)利要求40所述的系統(tǒng)，其中，每個消息傳遞設備包括主協(xié)議 優(yōu)化服務，并且每個應用編程接口包括響應于其相應的主協(xié)議優(yōu)化服務的 從協(xié)議優(yōu)化服務。
42. 如權(quán)利要求40所述的系統(tǒng)，其中，每個應用編程接口包括通信引 擎和一個或多個鏈接到其的應用程序存根。
43. 如權(quán)利要求42所述的系統(tǒng)，其中，所述通信引擎是數(shù)據(jù)守護程序。
44. 如權(quán)利要求40所述的系統(tǒng)，其中，每個應用編程接口被部署在客 戶應用主機中的操作系統(tǒng)之上。
45. 如權(quán)利要求40所述的系統(tǒng)，其中，每個應用編程接口包括用于 將消息傳遞到所述應用程序的應用傳遞引擎；以及用于處理管理消息的管 理消息層。
46. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備中的每一個 以及設置和管理系統(tǒng)被配置為用于容錯。
47. 如權(quán)利要求46所述的系統(tǒng)，其中，所述消息傳遞設備以容錯對的 方式布置，每一對包括主消息傳遞設備和副消息傳遞設備，所述副消息傳 遞設備在會話失效的情況下從所述主消息傳遞設備接管這樣的會話，而不 干擾所述主消息傳遞設備上的其它主動會話。
48. —種具有發(fā)布/訂購中間件體系結(jié)構(gòu)的系統(tǒng)，該系統(tǒng)包括一個或多個命名空間域；以及如果存在多于一個的空間域，則包括用于在所述命名空間域之間進行 連接的領域互連介質(zhì)，其中，每個命名空間域包括一個或多于一個的消息傳遞設備，被配置為用于接收和路由消息，互連；以及設置和管理系統(tǒng)，通過所述互連而鏈接并且被配置為用于與每個 消息傳遞設備交換管理消息，其中，每個消息傳遞設備還被配置為用于通過實時地、動態(tài)地選 擇消息傳輸協(xié)議和消息路由路徑而執(zhí)行消息的路由。
49. 一種具有發(fā)布/訂購中間件體系結(jié)構(gòu)的企業(yè)系統(tǒng)，該企業(yè)系統(tǒng)包括市場數(shù)據(jù)傳遞基礎設施，具有一個或多個用于接收和路由市場數(shù)據(jù)消息的消息傳遞設備；市場訂單路由基礎設施，具有一個或多個用于接收和路由交易訂單消 息的消息傳遞設備；以及中間基礎設施，分別與所述市場數(shù)據(jù)傳遞基礎設施和所述市場訂單路由基礎設施通信鏈接，其中，所述中間基礎設施包括一個或多于一個的消息傳遞設備，被配置為用于接收和路由所述 市場數(shù)據(jù)消息和所述交易訂單消息， 互連；以及設置和管理系統(tǒng)，通過所述互連而鏈接并且被配置為用于與每個 消息傳遞設備交換管理消息，所述消息傳遞設備包括所述市場數(shù)據(jù)傳遞基礎設施和所述市場訂單路由基礎設施中的所述消息傳遞設備；其中，所述消息傳遞設備中的每一個還被配置為用于通過實時 地、動態(tài)地選擇消息傳輸協(xié)議和消息路由路徑而執(zhí)行消息的路由。
50. 如權(quán)利要求49所述的企業(yè)系統(tǒng)，還包括 市場數(shù)據(jù)源，用于發(fā)布所述市場數(shù)據(jù)消息；以及市場數(shù)據(jù)客戶，用于接收所述市場數(shù)據(jù)消息并且用于發(fā)布所述交易訂 單消息，所述市場數(shù)據(jù)客戶包括一個或多個應用程序，其中，所述中間基礎設施包括應用編程接口，該應用編程接口在所述 應用程序的每一個和這樣的應用編程接口所注冊到的所述中間基礎設施中 的所述消息傳遞設備的一個之間，所述應用編程接口用于將所述市場數(shù)據(jù) 消息傳遞到所述應用程序并且從所述應用程序傳遞交易訂單消息。
51. 如權(quán)利要求49所述的企業(yè)系統(tǒng)，還包括協(xié)議變換引擎，并且其 中，所述市場數(shù)據(jù)傳遞基礎設施和所述市場訂單路由基礎設施中的消息傳 遞設備被配置為邊緣消息傳遞設備，所述中間基礎設施中的消息傳遞設備 被配置為核心消息傳遞設備，其中每個邊緣消息傳遞設備采用其相應的協(xié) 議變換引擎以在外部協(xié)議和本地協(xié)議之間變換消息，其中每個核心消息傳 遞設備被配置為用于處理所述本地協(xié)議的消息。
52. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備被互連以提 供網(wǎng)絡非居間化。
53. 如權(quán)利要求1所述的系統(tǒng)，其中，所述消息傳遞設備中的一個或 多個是交換或路由設備中的嵌入組件。
全文摘要
要求消息發(fā)布/訂購系統(tǒng)(10)用處理大量消息，同時減小延遲和性能瓶頸。本發(fā)明所提出的端到端的中間件體系結(jié)構(gòu)通過用基于鄰居的路由減少中間跳、引入高效的本地至外部和外部至本地的協(xié)議轉(zhuǎn)換、實時監(jiān)控包括延遲在內(nèi)的系統(tǒng)性能、采用基于話題和基于信道的消息通信并且動態(tài)地優(yōu)化系統(tǒng)互連配置和消息傳輸協(xié)議，而被設計為用于高容量、低延遲的消息傳遞。
文檔編號G06F15/16GK101124566SQ200580046094
公開日2008年2月13日 申請日期2005年12月23日 優(yōu)先權(quán)日2005年1月6日
發(fā)明者巴利·J·湯普森, 庫·辛格, 皮埃爾·費沃 申請人:特維拉有限公司