專利名稱：控制發(fā)布保持的方法以及發(fā)布/訂購代理器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)處理網(wǎng)絡(luò)內(nèi)的通信與數(shù)據(jù)存儲管理，更具體地，本發(fā)明 提供用于在發(fā)布/訂購消息環(huán)境中控制消息的保持的設(shè)備、方法和計算機程 序。
背景技術(shù)：
在消息網(wǎng)絡(luò)中，消息可以經(jīng)由提供路由的、以及在多種情況下提供轉(zhuǎn)換 和其它服務(wù)的一個或多個"消息代理器"，從一個數(shù)據(jù)處理系統(tǒng)傳遞到另一個 數(shù)據(jù)處理系統(tǒng)。雖然可以在分布式代理器網(wǎng)絡(luò)內(nèi)的各個點實現(xiàn)代理器功能， 但是代理器通常位于網(wǎng)絡(luò)內(nèi)的通信集線器處。
多個消息代理器支持發(fā)布/訂購?fù)ㄐ欧独＿@包括發(fā)布器發(fā)送能夠由已經(jīng) 在接收該類型的通信中注冊他們的興趣的一組訂購器所接收的通信，發(fā)布應(yīng) 用通常不需要知道是哪個訂購器對其感興趣。發(fā)布/訂購允許訂購器接收感興 趣區(qū)域(例如，股票價格或者諸如新聞短訊或者特殊報價的事件)中的最新 信息，而不需要非得積極主動地并且重復(fù)地向每個發(fā)布器請求該信息。
一般的發(fā)布/訂購環(huán)境具有多個發(fā)布器應(yīng)用，其經(jīng)由代理器通過網(wǎng)絡(luò)向位 于遠(yuǎn)程設(shè)備上的潛在的多個訂購器應(yīng)用發(fā)送消息。因為通過中間代理器的通 信不要求每個發(fā)布器和每個訂購器之間的專用連接，所以發(fā)布器與訂購器之 間是分離的，這與緊緊連接的傳統(tǒng)的客戶機一服務(wù)器范例相比，大大地簡化 了網(wǎng)絡(luò)布局。訂購器向代理器注冊，以及識別他們想要為其接收發(fā)布消息的 信息的種類，并且將該信息存儲在代理器。在多個發(fā)布/訂購的實施方式中， 訂購器指定表示他們想要接收的信息的一個或多個主題名稱。當(dāng)發(fā)布器發(fā)送 他們的消息到代理器時，發(fā)布器給消息分配主題名稱，并且代理器使用匹配 引擎來對所接收的消息的主題與它所存儲的注冊訂購器的訂購信息進行比 較。這個比較確定該消息應(yīng)該轉(zhuǎn)發(fā)給哪個訂購器。主題常常被分層地指定，
例如使用字符串格式"root/levelltopicName/level2topicName，，，以使能使用迭 代遍歷主題分層的匹配算法來對所接收消息中指定的主題與訂購進行比較。
訂購能夠與主題樹內(nèi)的結(jié)點相關(guān)聯(lián)。
雖然訂購匹配常常包括檢驗消息標(biāo)題內(nèi)的主題字段，但是匹配可以附加 地或者另外地包括檢驗其它消息標(biāo)題字段或者檢驗消息內(nèi)容，以及基于附加
信息而過濾消息。例如，實現(xiàn)JavaTM Message Service ( JMS )的消息代理器 通常允許基于消息屬性(而不是基于是消息內(nèi)容或"有效載荷"的應(yīng)用數(shù)據(jù)) 而過濾。消息代理器可以執(zhí)行附加功能，例如執(zhí)行數(shù)據(jù)內(nèi)容或者格式變換， 或者相反，在轉(zhuǎn)發(fā)它們給訂購器之前處理接收消息。(Java和所有基于Java 的商沖示是Sun Microsystems ^^司的商才示)。
支持發(fā)布/訂購范例以及允許按消息內(nèi)容過濾的、市場上可得到的消息代 理器產(chǎn)品的示例是IBM公司的WebSphere Message Broker,如2006年7月在 IBM 乂i^司的文葉牛"IBM WebSphere Message Broker Version 6 Release 0 -Introduction"和2006年7月在IBM公司的"IBM WebSphere Message Broker Version 6 Release 0 — Publish7Subscribe，，中所描述的。消息代理器可以與處理 通過異類網(wǎng)絡(luò)提供可靠消息傳遞的復(fù)雜性的下層消息傳遞產(chǎn)品相關(guān)聯(lián)。IBM 公司的WebSphere MQ消息產(chǎn)品是提供這樣的消息功能的產(chǎn)品示例，并在包 括2005年6月在IBM發(fā)布的參考編號GC34—65卯一Ol"WebSphere MQ Clients"的IBM公司的多個發(fā)布文件中得到描述。(IBM和WebSphere是國際 商業(yè)機器公司的注冊商標(biāo))。
發(fā)布/訂購范例是傳播信息到多個用戶的有效方法，并且對發(fā)布器和/或訂 購器的組能夠隨時間改變以及對發(fā)布器和/或訂購器的數(shù)量很大的環(huán)境尤其 有用。 一些訂購僅僅當(dāng)訂購應(yīng)用連接到代理器時保持為活動的。這些訂購被 稱為是"非持久的"。因為"非持久的"訂購器很可能錯過多個想要的發(fā)布，所 以許多其它訂購是"持久的"并且保持活動的，直到該訂購應(yīng)用明確地取消訂 購時為止。當(dāng)訂購器重連接時，為了檢索，在代理器處擁有匹配未連接的"持 久，，訂購器的訂購的發(fā)布。當(dāng)"持久"訂購器不再希望接收發(fā)布時，訂購器能夠 從代理器取消訂購(或者取消訂購特定的主題或者主題組)。
雖然該訂購和取消訂購的能力使持久訂購器在他們所接收的發(fā)布的控制 之下，但是通常在每個訂購器的執(zhí)行一在代理器處開始訂購和取消訂購操作 -中存在一些等待時間。在依賴于低帶寬或者訂購器與代理器之間的不可靠 連接的通信環(huán)境中，在訂購器能夠獲得任何發(fā)布之前，等待時間會導(dǎo)致顯著 的延遲。在訂購操作之后，在代理器接收匹配新訂購器的訂購的任何發(fā)布之
前，也可能存在相當(dāng)大的延遲。對于一些訂購器應(yīng)用，這樣的延遲將是可接
受的；但是一些訂購器應(yīng)用盡可能快地需要發(fā)布的信息。
在發(fā)布已經(jīng)被轉(zhuǎn)發(fā)到當(dāng)前注冊的訂購器的組之后， 一些發(fā)布/訂購代理器 刪除每個發(fā)布。用這樣的代理器，在每個訂購器通過代理器注冊各個訂購信 息之后，他們僅僅接收通過該代理器所收到的發(fā)布。然而， 一些發(fā)布/訂購代 理器實現(xiàn)可選的"保持"策略，由此，代理器保持由代理器收到的適合于某主 題的最新發(fā)布的副本(通常每個主題只保持一條消息)。這樣的保持發(fā)布可以 保存在代理器的高速緩沖存儲器或其它存儲器中。這對于希望快速接收他們 感興趣的主題的最新發(fā)布的新訂購器來說是有用的 一不需要必須等待將要由 各個發(fā)布器發(fā)送的新發(fā)布一以及對于不常見的發(fā)布的主題的訂購器來說也是 有用的。
舉例來說，考慮正在移動電話或者PDA上運行的貨幣轉(zhuǎn)換器應(yīng)用。該應(yīng) 用需要發(fā)布外幣兌換率來執(zhí)行貨幣轉(zhuǎn)換。當(dāng)最新調(diào)用貨幣轉(zhuǎn)換器應(yīng)用時，信 任不同工作日發(fā)布的兌換率，^艮容易產(chǎn)生錯誤，因此該應(yīng)用需要從發(fā)布/訂購 代理器處獲得最新的兌換率信息。然而，用戶可能不想等待兌換率發(fā)布器發(fā) 出他們的下一次廣播發(fā)布。因為下一次發(fā)布的兌換率信息可能是不可接受的， 所以該應(yīng)用用戶可能設(shè)法快速做出關(guān)于是否購買商品、等待幾分鐘或者甚至 幾秒鐘的決定。如果代理器保持它已經(jīng)接收的最新兌換率發(fā)布，則一旦他們 訂購，這就能夠被轉(zhuǎn)發(fā)到新訂購的貨幣轉(zhuǎn)換器應(yīng)用，而不需要等待發(fā)布器的 下一次發(fā)布。
在保持發(fā)布的典型實施方式中，發(fā)布器設(shè)置保持標(biāo)志，而代理器通過保 持該發(fā)布來響應(yīng)該保持標(biāo)志。發(fā)布器還可以指定保持發(fā)布的終止時間(在其 之后發(fā)布數(shù)據(jù)無效或者無用)。當(dāng)?shù)竭_終止時間時，代理器刪除保持消息。
在其它應(yīng)用中，新訂購器不僅僅接收最后發(fā)布是有用的。累積信息或許 比僅僅看單個發(fā)布更有用。該問題的一個解決辦法是除發(fā)布/訂購消息代理器 之外，還使用重放服務(wù)器。重放服務(wù)器保持大量數(shù)據(jù)，使得以前發(fā)布的消息 是可獲得的，并且如果需要時能夠被檢索到，但是相關(guān)聯(lián)的處理和存儲開銷 相對應(yīng)地大。重放服務(wù)器是獨立于發(fā)布/訂購代理器的實體，因此結(jié)合訂購匹 配和內(nèi)容以及代理器的形式轉(zhuǎn)換是一項重要的任務(wù)。
另 一可能的解決辦法是代理器為每個主題保持預(yù)定數(shù)量N的發(fā)布。然而， 依賴于預(yù)定數(shù)量是不靈活的，仍然存在如何決定適當(dāng)?shù)腘值的問題(平衡存
儲開銷與給新訂購器保持發(fā)布的收益)。預(yù)定值N對于標(biāo)識哪些發(fā)布組具有
累積顯著性并且應(yīng)該集中在一起、以及哪些發(fā)布應(yīng)該獨立地處理是沒有用的。 典型的發(fā)布/訂購代理器忽視發(fā)布之間的潛在關(guān)系，因此具有累積顯著性的發(fā) 布的分組目前依賴于訂購器應(yīng)用的分析。

發(fā)明內(nèi)容
本發(fā)明第 一 方面提供 一種用于在發(fā)布/訂購系統(tǒng)中對發(fā)布的保持進行控 制的方法。該方法包括發(fā)布器發(fā)送新發(fā)布，該新發(fā)布標(biāo)記是否應(yīng)該與以前的 保持發(fā)布一起保持該新發(fā)布。發(fā)布/訂購代理器通過與以前的保持發(fā)布一起保 持新發(fā)布來響應(yīng)這樣的標(biāo)記。
在優(yōu)選的實施例中，新發(fā)布的內(nèi)容或者"有效載荷"能夠添加到以前的保 持發(fā)布上，從而導(dǎo)致含有附加信息的單個保持發(fā)布。這對于代理器和新訂購 器兩者都具有潛在的優(yōu)點。第一，由于標(biāo)題信息的復(fù)制，具有多個發(fā)布所建 立的內(nèi)容的單個保持發(fā)布所需要的存儲量往往小于包含同樣數(shù)據(jù)內(nèi)容的多個 保持發(fā)布所需要的存儲量。第二， 一旦代理器已經(jīng)執(zhí)行添加操作，則代理器 的存儲管理和數(shù)據(jù)存取操作比代理器總是需要追蹤一組相關(guān)聯(lián)的保持發(fā)布時 的簡單。第三，使用傳統(tǒng)技術(shù)能夠給新訂購器提供單個保持發(fā)布，然而如果 添加新內(nèi)容到保持發(fā)布，則訂購器將獲得一組發(fā)布的信息內(nèi)容。如果該組發(fā) 布具有累積顯著性，則添加信息可以導(dǎo)致單個保持發(fā)布，其對于新訂購器來 說比僅僅保持有關(guān)每個主題的最新發(fā)布的常規(guī)方法更有用。
在基于主題的發(fā)布/訂購系統(tǒng)中，發(fā)布器給出的關(guān)于發(fā)布保持的標(biāo)記可以 包括發(fā)布器指定的指令，其用于代理器添加新發(fā)布的內(nèi)容到適合于各個發(fā)布 主題的最新保持發(fā)布上。在發(fā)布器系統(tǒng)內(nèi)，例如，該新能力可以實現(xiàn)為新的
API調(diào)用或者適合于由發(fā)布器應(yīng)用使用的可選屬性。在該實施例中，發(fā)布器 API通過向標(biāo)題信息或者發(fā)布消息的內(nèi)容增加添加指令來響應(yīng)新API調(diào)用或 者屬性。
同時，代理器優(yōu)選地實現(xiàn)保持管理器，其響應(yīng)于"添加"指令或者另一累 積保持指令而實現(xiàn)新功能。具體地，發(fā)布/訂購代理器可以通過向代理器的存 儲庫中的各個保持發(fā)布中增加新發(fā)布(優(yōu)選地，僅僅新發(fā)布的內(nèi)容或者"有效 載荷")來響應(yīng)添加指令。優(yōu)選地，代理器還響應(yīng)"不添加"指令(或者沒有"添 加，，指令)來刷新以前的保持發(fā)布。然后代理器可以保持發(fā)送給具有不添加指
令的代理器的新發(fā)布。
根據(jù)本發(fā)明的一個實施例，包含添加指令的新發(fā)布被分別添加到用于各 個發(fā)布主題的當(dāng)前保持發(fā)布上，直到接收到不包含添加指令的新發(fā)布時為止。 然后，以前保持的發(fā)布由新的"不添加"發(fā)布所覆蓋。然后能夠如前所述添加 隨后的發(fā)布。
在另一實施例中，響應(yīng)于發(fā)布器指示一起保持某些消息的愿望，在代理 器中累積一組發(fā)布消息作為分離的但是相關(guān)聯(lián)的消息。這樣具有以與原來發(fā) 布相同的形式保持消息的優(yōu)點，而代理器不需要必須創(chuàng)建具有添加內(nèi)容的修 改消息，因此代理器不需要花很大的努力就能管理最初轉(zhuǎn)發(fā)(到第一組訂購 器)的消息和隨后轉(zhuǎn)發(fā)給新訂購器的加上添加內(nèi)容的消息之間的潛在的差異。
關(guān)于是否添加相關(guān)消息內(nèi)容到單個保持發(fā)布或者是否保持一組相關(guān)的但 是分離的消息的決定將取決于特定應(yīng)用的需要。
本發(fā)明的第二方面提供一種用于發(fā)布/訂購?fù)ㄐ啪W(wǎng)絡(luò)的發(fā)布/訂購代理器。
該代理器包括從發(fā)布器接收發(fā)布的裝置；標(biāo)識發(fā)布器指定的、是否應(yīng)該與 以前的保持發(fā)布相關(guān)聯(lián)地保持該發(fā)布的標(biāo)記的裝置；和響應(yīng)于發(fā)布器指定的 標(biāo)記，與以前的保持發(fā)布相關(guān)聯(lián)地保持新發(fā)布的裝置。
本發(fā)明的第三方面提供一種在通信網(wǎng)絡(luò)內(nèi)發(fā)布消息到發(fā)布/訂購代理器 的消息客戶機，該發(fā)布/訂購消息客戶機包括用于調(diào)用向發(fā)布/訂購代理器發(fā) 送消息的操作的裝置；以及用于在消息內(nèi)指定應(yīng)該由代理器與以前保持的消 息相關(guān)聯(lián)地保持該消息的裝置。在由消息客戶機實現(xiàn)的消息API內(nèi)優(yōu)選地實 現(xiàn)用于調(diào)用的裝置和用于指定的裝置。在一個實施例中，用于指定應(yīng)該與以 前保持的發(fā)布相關(guān)聯(lián)地保持該消息的裝置包括調(diào)用發(fā)送操作的API調(diào)用的可 選屬性。消息客戶機可以包括調(diào)用該發(fā)送操作以及指定保持需要的應(yīng)用程 序，和實現(xiàn)消息傳遞協(xié)議以及路由功能、以通過網(wǎng)絡(luò)向發(fā)布/訂購代理器傳遞 消息的消息傳遞部件。
上述方法的步驟和系統(tǒng)的某些部件可以以計算機程序代碼來實現(xiàn)，并且 可作為計算機程序產(chǎn)品來獲得。這樣的程序產(chǎn)品包括記錄在記錄介質(zhì)上的程 序代碼，用于控制在執(zhí)行程序代碼的數(shù)據(jù)處理設(shè)備上的操作的執(zhí)行，以實現(xiàn) 上述方法。用于經(jīng)由諸如因特網(wǎng)的數(shù)據(jù)傳送媒介下載的計算機程序是可獲得 的。本發(fā)明的各部件也可以以硬件來實現(xiàn)。


下面參考附圖，以舉例的方式更詳細(xì)地描述本發(fā)明的實施例，其中: 圖1是表示根據(jù)本發(fā)明實施例的發(fā)布/訂購數(shù)據(jù)處理網(wǎng)絡(luò)的示意圖； 圖2是表示根據(jù)本發(fā)明的 一個實施例的方法的步驟的流程圖； 圖3是表示根據(jù)本發(fā)明的另一實施例的方法的步驟的流程圖； 圖4示出在發(fā)布器消息客戶機系統(tǒng)中執(zhí)行的操作。
具體實施例方式
以下描述本發(fā)明的多個方面和實施例，包括用于在分布式數(shù)據(jù)處理網(wǎng)絡(luò) 內(nèi)實現(xiàn)本發(fā)明的方法、計算機程序和數(shù)據(jù)處理設(shè)備。該實施例僅僅作為說明 性示例描述，以確保完全地理解本發(fā)明和它的優(yōu)點。本發(fā)明并不局限于所述 的i^明性實施例。
在來自發(fā)布器的標(biāo)記的控制下，實施例使新發(fā)布消息能在發(fā)布/訂購代理 器中與以前保持的發(fā)布一起保持。這使具有累積顯著性的發(fā)布組能被一起保 持，作為關(guān)于每個主題保持所有的發(fā)布或者僅僅保持一個發(fā)布的替換，以便 新訂購器能夠從代理器處獲得具有累積顯著性的最新保持發(fā)布組。
因為成本的原因以及為了促進事務(wù)的發(fā)展，發(fā)布/訂購匹配引擎以計算機 程序代碼來實現(xiàn)是常見的。通常，包括所述發(fā)布/訂購代理器、發(fā)布器應(yīng)用和 訂購器應(yīng)用的本發(fā)明的若干個部件可以用計算機程序代碼來實現(xiàn)。該代碼可 以用諸如C + + 、 JavaTM、或者SmallTalk的面向?qū)ο缶幊陶Z言或者用諸如C 編程語言的過程編程語言來編寫。這些程序代碼部件可以在通用計算機或者 專用數(shù)據(jù)處理設(shè)備上執(zhí)行。如以下更詳細(xì)地確認(rèn)，實現(xiàn)本發(fā)明的一些特征和
局域網(wǎng)(LAN)、廣域網(wǎng)(WAN)、或者因特網(wǎng)的數(shù)據(jù)處理網(wǎng)絡(luò)的多個數(shù)據(jù)處 理系統(tǒng)中。在這樣的網(wǎng)絡(luò)內(nèi)的不同系統(tǒng)和設(shè)備之間的連接可以是有線或者無 線的，并且不局限于任一特定的通信協(xié)議或者數(shù)據(jù)格式，以及在這樣的網(wǎng)絡(luò) 中的數(shù)據(jù)處理系統(tǒng)可以是異類系統(tǒng)。
在^f艮多情況下，發(fā)布/訂購代理器將在大容量、高性能、網(wǎng)絡(luò)連接的數(shù)據(jù) 處理系統(tǒng)上實現(xiàn)一因為這樣的系統(tǒng)能夠為大量的發(fā)布器和訂購器維持高性能 發(fā)布吞吐量。該發(fā)布/訂購代理器可以是邊緣服務(wù)器的部件(即代理器可以是 一組網(wǎng)絡(luò)服務(wù)器或者應(yīng)用服務(wù)器部件中的一個)或者網(wǎng)絡(luò)網(wǎng)關(guān)設(shè)備。然而，
具有少量代碼足跡的"微代理器"解決辦法近年來已經(jīng)得到發(fā)展并且已經(jīng)在例 如遠(yuǎn)程遙測應(yīng)用中使用，因此現(xiàn)在說，發(fā)布器、訂購器、和發(fā)布/訂購代理器 全部都可以在各類數(shù)據(jù)處理系統(tǒng)和設(shè)備的任一個上實現(xiàn)是正確的。因此本發(fā)
明能夠在包括無線連接PDA和自動傳感器設(shè)備的網(wǎng)絡(luò)中、以及在包括復(fù)雜和
高性能的計算機系統(tǒng)的網(wǎng)絡(luò)中實現(xiàn)。
對于本領(lǐng)域^L術(shù)人員來說4艮明顯，分布式發(fā)布/訂購?fù)ㄐ啪W(wǎng)絡(luò)的各個部件
能夠以軟件或者硬件(例如使用電子邏輯電路)實現(xiàn)。例如，發(fā)布/訂購匹配
引擎70能夠由硬件比較器實現(xiàn)，該硬件比較器對發(fā)布消息內(nèi)的主題名稱與存 儲訂購內(nèi)的主題名稱進行比較。然后在電子電路內(nèi)處理比較器的指示匹配或 者不匹配的輸出信號，以便控制消息是否轉(zhuǎn)發(fā)給特定的訂購器。由一些發(fā)布/ 訂購匹配引擎實現(xiàn)的過濾步驟可以由電子過濾器(一種電子電路)實現(xiàn)一尤 其在將要施加過濾器的數(shù)據(jù)值能夠表示為信號振幅的地方。
因此，很明顯，本發(fā)明適用于各類操作環(huán)境并且可以使用硬件和軟件的 各個組合實現(xiàn)。在每種情況下，本發(fā)明提供發(fā)布/訂購?fù)ㄐ怒h(huán)境中的訂購匹配 的增強的基于事件的管理。特定地，本發(fā)明的實施例使訂購器能定義時間上 不可預(yù)測的活動和非活動事件，使得訂購匹配能夠由發(fā)布/訂購代理器接通和 斷開，而不需要訂購器重復(fù)地發(fā)布"訂購"和"取消訂購"的請求。
圖1示出已經(jīng)實現(xiàn)了本發(fā)明實施例的簡單的發(fā)布/訂購消息網(wǎng)絡(luò)。運行在 各個數(shù)據(jù)處理系統(tǒng)30、 40上的一組發(fā)布器應(yīng)用10、 20能夠發(fā)布能由在各個 數(shù)據(jù)處理系統(tǒng)80、 90、 IOO上運行的多個訂購器應(yīng)用50、 60、 70所接收的消 息。發(fā)布器IO、 20發(fā)送消息到正在網(wǎng)絡(luò)內(nèi)的另一數(shù)據(jù)處理系統(tǒng)120上運行的 發(fā)布/訂購消息代理器110。訂購器向代理器指定他們希望接收到的消息類型 (例如，消息主題名稱)。消息代理器對所接收的發(fā)布與該組訂購器50、 60、 70的訂購信息進行比較一例如將所接收消息的標(biāo)題內(nèi)的主題名稱和與代理器 相關(guān)聯(lián)的訂購目錄或者表內(nèi)的主題名稱相比較，以標(biāo)識任何匹配。在發(fā)布器 和訂購器之間他們不需要直接連接并且不需要彼此的地址信息。作為替代， 發(fā)布器IO、 20向代理器IIO發(fā)送消息，包括諸如消息主題的消息類型信息； 訂購器在他們所發(fā)送給代理器的訂購信息中指定他們的需求；然后代理器傳 遞所接收的消息給對所接收的類型的接收消息感興趣的訂購器。
在圖l的示例中，發(fā)布器10、 20和訂購器50、 60、 70依賴下層消息客 戶機130、 140、 170、 180、 190的消息傳遞功能，以處理考慮典型的異類分
布式網(wǎng)絡(luò)的復(fù)雜性的消息路由和格式化操作，以及使用消息隊列來提供異步 消息處理能力。在其它實施例中，消息客戶機的消息傳遞功能可以被替代實 現(xiàn)為發(fā)布器應(yīng)用的整體特征。
消息代理器110包括訂購匹配引擎150和代理器的數(shù)據(jù)處理系統(tǒng)120的 庫內(nèi)的相關(guān)聯(lián)的訂購目錄或者表160。在一些實施例中，消息代理器與經(jīng)由 網(wǎng)絡(luò)通信與遠(yuǎn)程消息客戶機130 、 140、 170、 180、 190互操作的本地消息系 統(tǒng)(例如IBM WebSphere MQ消息產(chǎn)品)接口 ，但是在本實施例中，代理器 的數(shù)據(jù)處理系統(tǒng)120的消息路由和格式化特征被實現(xiàn)為代理器110本身的整 體特征。特定地，對于每個消息客戶機，代理器110的接收器和發(fā)送器部件 200、 210包括通信棧和協(xié)議處理模塊，用于編組消息的消息代理器的內(nèi)部表 示為規(guī)范的字節(jié)格式，以及從規(guī)范的字節(jié)格式中解編組(demarshal)消息的 消息代理器的內(nèi)部表示，以允許消息流過網(wǎng)絡(luò)連接。通信?？梢源嫒∮糜谂c 外部網(wǎng)絡(luò)通信的TCP/IP套接字(socket )。消息代理器110聽取用于重新建 立客戶連接的特定的TCP端口。在收到入站連接請求時，消息代理器自舉用 于該客戶的通信棧。該棧響應(yīng)于維持與客戶的連接以及監(jiān)控套接字連接的當(dāng) 前狀態(tài)。通信棧自舉協(xié)議處理模塊，而協(xié)議處理模塊處理消息格式和通信協(xié) 議的解碼和編碼，以便完成能夠由消息代理器消耗的內(nèi)部對象表示。例如， 協(xié)議模塊將來自發(fā)布器客戶機的入站消息解編組為對象形式，以及提交他們 給用于匹配注冊訂購和用于傳遞給訂購器的發(fā)布/訂購匹配引擎。
匹配引擎對所接收的發(fā)布與當(dāng)前注冊的訂購組進行比較，以標(biāo)識0、 l或 多個匹配。在本實施例中，這包括如在本領(lǐng)域已知的以及如以上所述的主題 匹配。如果訂購器應(yīng)用50、 60、 70當(dāng)前向^f戈理器注冊，并且分別^^皮標(biāo)識為 SUBSCRIBERS、 SUBSCRIBER2和SUBSCRIBER3，則在代理器中擁有的簡 單訂購目錄如下
SUBSCRIBER1: TOPIC 1, TOPIC3
SUBSCRIBER2: TOPIC2， TOPIC4
SUBSCRIBER3 : TOPIC 1
通常，每個主題表示為與訂購匹配引擎150使用的分層主題樹相對應(yīng)的 分層字符串格式。例如，TOPIC 1可以是格式"root/levelltopicName/leve12 topicName"，所以匹配引擎能夠遍歷分層來4全查匹配訂購，如之前所述。經(jīng) 受附加到主題匹配的任一消息過濾后，由代理器接收的關(guān)于TOPIC1的所有消息將轉(zhuǎn)發(fā)到SUBSCRIBER1和SUBSCRIBERS接收的關(guān)于TOPIC2的消 息將只轉(zhuǎn)發(fā)到SUBSCRIBER2 ;關(guān)于TOPIC3的消息將只轉(zhuǎn)發(fā)到 SUBSCRIBER1;而關(guān)于TOPIC4的消息將只轉(zhuǎn)發(fā)到SUBSCRIBER2。
對于圖1的特定實施例，讓我們假定所有訂購器具有非持久的訂購，因 此對于當(dāng)前未連接的訂購器來說，以每個訂購器為基礎(chǔ)，在代理器中不保持 消息。還讓我們假定沒有高容量的重放服務(wù)器。換句話說，將每個發(fā)布轉(zhuǎn)發(fā) 到當(dāng)前的注冊的訂購器組，其已經(jīng)訂購接收關(guān)于在發(fā)布消息內(nèi)指定的特定消 息主題的發(fā)布，但是在本特定實施例中，沒有保存代表當(dāng)前未連接的持久訂 購器的消息。
然而，雖然沒有以每個訂購器為基礎(chǔ)保存發(fā)布，但是本發(fā)明提供了對保 持發(fā)布的支持，如下所述。
由已知發(fā)布器應(yīng)用使用的示例消息API包括響應(yīng)于發(fā)布器指定主題名 稱、指定或者附加信息數(shù)據(jù)、并且可選地設(shè)置"保持"標(biāo)志，向代理器發(fā)送消 息的sendMessage(發(fā)送消息)操作。主題名稱是一組預(yù)定主題名稱中的一個， 其中該組中的每個主題名稱可由消息代理器110解釋，并且可以由一個或多 個訂購器指定為感興趣的主題。當(dāng)由發(fā)布器指定時，主題名稱和保持標(biāo)志被 包括在發(fā)送消息的標(biāo)題內(nèi)。消息數(shù)據(jù)也包括在消息內(nèi)。由發(fā)布器設(shè)置"保持" 標(biāo)志是向代理器發(fā)出的指令復(fù)制該消息到代理器的消息庫中，以及當(dāng)該消 息是關(guān)于特定主題的最新接收消息時，保持庫中的副本。sendMessageAPI調(diào) 用的格式可以是
sendMessage ( TOPIC—NAME, DATA, RETAIN—FLAG )
其中TOPIC_NAME可以是標(biāo)識一個預(yù)定主題的分層字符串，DATA是消 息的數(shù)據(jù)內(nèi)容，而RETAIN—FLAG是表示邏輯"真"(即消息應(yīng)該被保持在代 理器中)或者"假"(消息不應(yīng)該被保持)的值。例如，消息可以通過發(fā)出API 調(diào)用來發(fā)布，諸如
sendMessage ("greenhouse/temperature", "34 degrees", true )
其中主題是"greenhouse/temperature (綠房子/溫度)"，消息數(shù)據(jù)是小數(shù) 據(jù)項"34 degrees (度)"，而保持標(biāo)志值設(shè)置為"true (真)，，。
代理器將在主題"greenhouse/temperature，，下保持消息數(shù)據(jù)"34 degrees"的 副本，直到接收到關(guān)于該主題的具有不同數(shù)據(jù)值(例如"32 degrees")的消息 時為止。然后新的數(shù)據(jù)值將覆蓋以前的值。保持消息的這種實施方式(如迄
今為止在以上最后幾段所描述的)在本領(lǐng)域是已知的。
然而，在本發(fā)明中，保持標(biāo)志設(shè)置為"真"的消息并不一定覆蓋現(xiàn)有的保 持消息，而是可以將其添加(或相反與其結(jié)合)到以前保持的關(guān)于同一主題 的消息上。
在本實施例中，保持特征由是消息代理器110的部件的保持管理器220 來實現(xiàn)。如果保持標(biāo)志已經(jīng)設(shè)置為"真"，則保持管理器接收所收到的關(guān)于任 一主題的每個消息的消息數(shù)據(jù)的副本。該標(biāo)志沒有設(shè)置為"真，，的消息不被傳 遞到保持管理器中。當(dāng)然，保持標(biāo)志可以通過使用值1和O表示"真"和"假"、 或者使用具有能指示發(fā)布器是否需要所保持的消息的效果的任一其它表達式 來實現(xiàn)。
圖2提供根據(jù)本發(fā)明的第一示例實施例的消息代理器110內(nèi)的處理序列 的示意圖。該處理序列僅僅是本發(fā)明的一個可能的實施方式，以下參考圖3 等等描述附加的示例。發(fā)布器10向代理器110發(fā)送(300)消息，包括能夠 取真值或者假值的保持標(biāo)志和其它的添加標(biāo)志。以下參考圖4將更詳細(xì)地描 述在發(fā)布器系統(tǒng)中執(zhí)行的操作。以下還將更詳細(xì)地描述添加標(biāo)志。發(fā)布消息 由接收器側(cè)通信棧和協(xié)議處理器200處理(310 ),然后檢驗(320 )保持標(biāo)志 來確定發(fā)布器是否想要在代理器中保持消息。如果保持標(biāo)志設(shè)置為假，則消 息被傳遞到訂購匹配引擎150。訂購匹配引擎150比較(330 )消息標(biāo)題內(nèi)的 主題信息與以前由代理器IIO存儲的訂購160來標(biāo)識所有的匹配訂購。如果 沒有主題匹配(或者如果不滿足其它過濾條件)，則刪除(340 )消息。 一個 或多個訂購和發(fā)布消息之間的正匹配導(dǎo)致消息使用傳統(tǒng)的技術(shù)轉(zhuǎn)發(fā)(350 )到 一個或多個標(biāo)識訂購器。然后訂購器用由他們自己的應(yīng)用邏輯指定的任何方 法來接收(360)和處理消息。
然而，如果保持標(biāo)志被確定(320)設(shè)置為真，則消息被傳遞到保持管理 器220。保持管理器從消息標(biāo)題的附加字段中提取值來確定(370)消息是否 應(yīng)該添加到現(xiàn)有的關(guān)于指定主題的保持消息中，或者是否應(yīng)該覆蓋任何以前 所保持的消息。附加消息標(biāo)題字段在sendMessage API調(diào)用中被指定如下
sendMessage ( TOPIC—NAME, DATA, RETAIN—FLAG, APPEND—FLAG )
其中APPEND—FLAG的邏輯值可以是"真"或者"假"。如果附加值是"真，，， 則消息數(shù)據(jù)被添加(380 )到關(guān)于該主題的以前所保持的消息上，并且被保存 (390 )到保持發(fā)布的庫230中。添加消息數(shù)據(jù)包括從以前保持的發(fā)布中復(fù)
制消息數(shù)據(jù)，以及從最新接收的關(guān)于同一主題的發(fā)布中提取消息數(shù)據(jù)，然后 生成新的消息，其中所提取的新數(shù)據(jù)被添加到以前保持的數(shù)據(jù)中。在第一實
施例中，庫230中擁有的消息標(biāo)題信息相對于以前保持的發(fā)布來說沒有改變 (即僅僅通過添加操作而擴大了消息內(nèi)容)。有時，訂購器應(yīng)用不需要處理消 息標(biāo)題中所擁有的信息，并且由于在關(guān)于同一主題的連續(xù)發(fā)布之間，大量標(biāo) 題信息是完全相同的，則當(dāng)添加消息時，不需要改變庫230中的消息標(biāo)題信 息。在第二實施例中，其中發(fā)布日期和時間是訂購器應(yīng)用所感興趣的，以前 保持的發(fā)布的消息標(biāo)題或者保持不變，或者由已經(jīng)添加到保持發(fā)布的新接收 發(fā)布的消息標(biāo)題所代替，這取決于訂購器應(yīng)用的需要。在再一實施例中，其 中通過消息標(biāo)題字段的許可，添加消息的消息標(biāo)題可以合并(例如包括一組 添加登錄記錄的第一和最后發(fā)布的日期與時間)。
符合上述新格式的第一示例sendMessage API調(diào)用如下
sendMessage("application/log"， "09陽Mar-2006 11:23:42
com.ibm.myapplication.MyClassException:java.lang.NullPointerException", true, true)
如果關(guān)于該主題的多個消息被在代理器中接收，并且他們每個都具有設(shè) 置為"真"的添加標(biāo)志，則在代理器中擁有的、用于該指定主題的消息數(shù)據(jù)能 夠隨著時間的過去在庫230中^皮建立，諸如以下示例
't)9-Mar-20061 l:25:12conibimnyapplicalioaMyClassException:Java_lang.NullPointerException 09-Mar-200611:24:30 com.flmmy^pIicatioaMyClassExceptionJavaJarig.Nul]PointerException 09-Mar-200611:23:42 com.ihmjny^)plicatiorLMyClassExceptionJavaJarig.Nul]PointerException" 在第一實施例中，當(dāng)需要時，該組添加消息能夠由新的保持發(fā)布刷新和 覆蓋UOO)。是否刷新的決定可能是檢驗定時器到期的結(jié)果，作為是否添加 的確定(370 )的一部分，或者例如，確定(370)可以響應(yīng)添加標(biāo)志已經(jīng)"i殳 置為"假"的sendMessage ( ) API調(diào)用。對于發(fā)布器應(yīng)用，根據(jù)在應(yīng)用內(nèi)的執(zhí) 行的發(fā)展，能夠做出關(guān)于何時添加到保持發(fā)布、以及何時刷新和覆蓋保持發(fā) 布的決定。例如，當(dāng)應(yīng)用重新開始或者當(dāng)新執(zhí)行進程開始時，新登錄可以開 始，以及該重新開始能夠是刷新以前的保持消息和開始保持新登錄記錄的正 確時間點。發(fā)布器應(yīng)用執(zhí)行的其它重復(fù)階段可以是刷新保持消息的適當(dāng)點。
對保持消息的保持和刷新的這個柔性控制是對僅僅保持最后N個消息的 改進，因為后者會留給訂購器在諸如用于不同應(yīng)用執(zhí)行的登錄記錄的不相關(guān)
的保持發(fā)布之間進行區(qū)分的任務(wù)。
在一個實施例中,不保持發(fā)布消息的決定由保持管理器220解釋，作為 從如圖2所示的庫230中刷新(410)現(xiàn)有的保持發(fā)布的指令(因為不這樣做 會使過時的保持消息留在庫中)。在另一實施例中，保持管理器完全不管具有 保持標(biāo)志設(shè)置為假的任何消息。
在本發(fā)明的一個實施例中，由訂購匹配引擎處理以及最終轉(zhuǎn)發(fā)到注冊訂 購器的消息是最新的保持發(fā)布一一即，或者已經(jīng)覆蓋了 (400)以前的保持發(fā) 布的最新接收發(fā)布，或者添加(380 )接收消息到以前的保持消息的最新結(jié)果。 轉(zhuǎn)發(fā)包含累積數(shù)據(jù)(即添加消息)的單個消息給當(dāng)前的訂購器組、或者轉(zhuǎn)發(fā) 最新接收發(fā)布(即不添加)是否對他們更有用，則將取決于特定的應(yīng)用環(huán)境。 在涉及發(fā)布器應(yīng)用內(nèi)的當(dāng)前執(zhí)行進程的登錄記錄的情況下，具有附加內(nèi)容的 消息可以是轉(zhuǎn)發(fā)最有用的項目，因為接收訂購器然后能夠通過處理單個消息 而不必從多個發(fā)布消息中集合信息來處理有關(guān)的登錄記錄組。
然而，在其它實施例中，附加消息^U又用于"新近的"訂購器和間歇訂購 器一以響應(yīng)于新訂購來提供快速的更新機制。因此，接收新發(fā)布時連接到代 理器的訂購器將接收該新發(fā)布，如果該新發(fā)布匹配它們的訂購的話(即相對 于傳統(tǒng)的發(fā)布/訂購解決辦法沒有任何變化，不具有保持管理器添加或相反的 相關(guān)聯(lián)的消息，以及在保持管理器和訂購匹配引擎150之間沒有虛線箭頭)。 該實施方式將導(dǎo)致新近的訂購器接收不同于當(dāng)前訂購器的格式(在單個消息 中添加)的發(fā)布信息，但是由于數(shù)據(jù)內(nèi)容將是相同的，對于許多訂購器應(yīng)用， 不同格式的發(fā)出將不會產(chǎn)生問題。
如果對新的訂購器應(yīng)用來說，在庫230中由保持管理器220建立的累積 數(shù)據(jù)組比單個保持消息更有用，則本發(fā)明的"添加"特征實現(xiàn)了對已知的保持 發(fā)布解決辦法的改進。對于多個不同類型的訂購器應(yīng)用，諸如需要了解接收 數(shù)據(jù)值內(nèi)的事件頻率或者模式而不僅僅是單個數(shù)據(jù)值的多個監(jiān)控應(yīng)用，這將 是真的?；氐絻稉Q率示例，貨幣的相對值是增加還是減少與用戶完全有關(guān)。 在訂購器應(yīng)用是監(jiān)控處理異常的另一示例中，單個異常未必需要訂購器應(yīng)用 的任何活動，但是高頻異?？梢灾甘拘枰惹凶⒁獾膯栴}。
如果新訂購器能夠連接足夠久的時間來接收足夠多的新發(fā)布消息的序 列，則即使沒有本發(fā)明的添加特征，隨著時間的過去，新訂購器也能得到發(fā) 布消息數(shù)據(jù)內(nèi)的事件頻率或者模式。然而， 一些訂購器將只能夠短暫地連接，
而且一些訂購器應(yīng)用的用戶將希望一旦訂購則能快速地接收結(jié)果。因此存在 多個應(yīng)用類，本發(fā)明為其提供對已知解決辦法的改進。
本發(fā)明的實施例使"服務(wù)質(zhì)量，，的新選項能提供給訂購器。例如，如果保 持管理器從最新的相關(guān)消息組累積數(shù)據(jù)(諸如用于當(dāng)前應(yīng)用執(zhí)行進程的所有 登錄)，則訂購器可以不需要持久的訂購。非持久的訂購和由保持管理器保持 的消息子集可能滿足，而單個最新發(fā)布或者最后N個發(fā)布消息可能不滿足。
只有不頻繁地和暫時地連接到代理器的訂購器可以從由保持管理器220使用 的庫230中獲得足夠的信息，因此也許能避免在代理器中存儲大量過時消息。
在本發(fā)明的另 一實施例中，添加消息到以前的保持消息的指令可以通過 使用發(fā)送消息的新API調(diào)用來指定，例如
appendMessage ( TOPIC—NAME, DATA )
由于使用appendMessage ()發(fā)送的任一消息都想要保持，所以不需要保 持標(biāo)志。想要為特定主題刷新和覆蓋保持消息組的消息能夠繼續(xù)使用已知的 API調(diào)用格式
sendMessage ( TOPIC—NAME, DATA, RETAIN—FLAG )
或者可以提供另 一新的API調(diào)用，例如
ReplaceMessage ( TOPIC—NAME, DATA)
上述appendMessage ()調(diào)用在發(fā)布器應(yīng)用的API中調(diào)用操作，來以與 前述示例sendMessage ( TOPIC_NAME,DATA, RETAIN—FLAG, APPEND— FLAG )相同的方式發(fā)送消息。
第一示例appendMessage ()調(diào)用如下 appendMessage("application/log"， "09-Mar-2006 11:23:42 com.ibm.myapplication.MyClassException:Java.lang.NullPointerException") 不管實現(xiàn)以上哪種接口實施方式，或者任一其它實施方式，通常都希望 消息代理器可配置為設(shè)置保持添加消息組的最大消息長度。諸如最大消息長 度或者超時時段的屬性還可以在API調(diào)用中指定。對于保持管理器如何響應(yīng) 達到最大大小的添加消息內(nèi)容，存在各種實施方式的選項。在一個實施例中， 保持管理器創(chuàng)建與第 一保持消息相關(guān)聯(lián)的第二保持消息，以及繼續(xù)向第二保 持消息添加數(shù)據(jù)，直到其達到最大大小或者刷新保持消息時為止。在另一實 施例中，刷新或者截斷過大的保持消息，以便能夠添加更多新近發(fā)布的信息。 在另一實施例中，通過累積庫230中的、相互關(guān)聯(lián)的一組保持消息，可以響應(yīng)appendMessage ( ) API調(diào)用(或者一個上述其它接口選項)。這是對 保持具有附加消息內(nèi)容的單個發(fā)布的另一選擇。通過標(biāo)識在與新訂購有關(guān)的 庫230中保持的相關(guān)聯(lián)的消息組，保持管理器220響應(yīng)新近的訂購器，并且 轉(zhuǎn)發(fā)該組發(fā)布到新訂購器。這種保持發(fā)布為獨立的然而相關(guān)聯(lián)的消息的方法 確保將發(fā)送給"新近，，訂購器的保持發(fā)布每個等同于發(fā)送給其它訂購器的發(fā) 布。
圖2提供表示處理發(fā)布消息的方法的流程圖，其中在消息向訂購器轉(zhuǎn)發(fā) 之前，這些消息可以添加到其它消息上，而圖3示出另一實施方式，其中隨 匹配引擎150處理消息之后，執(zhí)行保持管理器的處理。在這個實施例中，接 收的發(fā)布能夠被轉(zhuǎn)發(fā)到當(dāng)前注冊訂購器，而不必等待保持管理器完成它的處理。
參考圖3，接收消息來標(biāo)識當(dāng)前感興趣的訂購器的處理僅僅是傳統(tǒng)的， 但是保持管理器考慮來自發(fā)布器的標(biāo)記，該發(fā)布器關(guān)心新發(fā)布的消息是否應(yīng) 該與作為保持消息所擁有的較早的發(fā)布相關(guān)聯(lián)地保持。代理器接收(500 )新 發(fā)布并且傳遞該發(fā)布給訂購匹配引擎。訂購匹配引擎比較(510)主題信息和 消息內(nèi)容的可能的其它標(biāo)題信息與一組存儲訂購，如在本領(lǐng)域是已知的。如 果標(biāo)識至少一個匹配訂購，則轉(zhuǎn)發(fā)(520)發(fā)布到各個訂購器。還傳遞發(fā)布到 保持管理器220，其在該實施例中執(zhí)行(530)檢驗發(fā)布是否將被保持。如在 上述實施例中，這個檢驗可以包括檢驗發(fā)布消息標(biāo)題內(nèi)的保持標(biāo)志，以及可 能根據(jù)由保持管理器施加的 一組規(guī)則來檢驗定時器或者主題名稱或者其它標(biāo) 準(zhǔn)。如果將不保持消息，則現(xiàn)在可以從代理器中刪除(540)消息。
如果保持標(biāo)志及其它標(biāo)準(zhǔn)的檢驗確定發(fā)布消息應(yīng)該保持在代理器中 > 則 然后確定(550 )新發(fā)布是否應(yīng)該與一個或多個以前的保持發(fā)布一起保持，或 者新發(fā)布是否應(yīng)該是關(guān)于該主題的唯一保持發(fā)布。如上所述，確定(550 )可 以包含檢驗發(fā)布消息標(biāo)題字段內(nèi)的添加標(biāo)志，或者響應(yīng)appendMessage( ) API 調(diào)用。如果確定新發(fā)布應(yīng)該被保持，但是不應(yīng)該與以前的發(fā)布結(jié)合，則將新 發(fā)布另存為用于特定消息主題的新保持發(fā)布一覆蓋(560 )關(guān)于同一主題的以 前的保持發(fā)布。如果確定發(fā)布消息應(yīng)該與一個或多個以前的發(fā)布相結(jié)合，則 通過與以前的保持發(fā)布相關(guān)聯(lián)地保存(570 )新發(fā)布來更新庫230。在更新庫 230中，最初的保持發(fā)布具有添加給它的指針，其指針標(biāo)識關(guān)于同一主題的 下一保持發(fā)布的存儲位置。當(dāng)需要時能夠增加新發(fā)布和指針。這組相關(guān)聯(lián)的
發(fā)布被保持在庫230中，直到"新近"訂購器需要時或者直到超時或者刷新指 令時為止。
在本發(fā)明的另 一實施例中，在消息已經(jīng)與匹配引擎的處理并行地通過接 收器側(cè)通信棧和協(xié)議處理器200之后，保持管理器可以接收該消息。
在另 一實施例中，能夠?qū)崿F(xiàn)保持管理器來保持所接收的關(guān)于任意以及每 個主題的或者用于預(yù)定主題子集的最新消息，而不必依賴于"保持"標(biāo)志。能 夠?qū)崿F(xiàn)保持管理器來保持僅僅關(guān)于預(yù)定主題子集的和只有"保持"標(biāo)志已經(jīng)設(shè) 置為真的消息。
用于向發(fā)布/訂購代理器發(fā)布消息的典型消息客戶機系統(tǒng)包括實現(xiàn)消息 API的發(fā)布器應(yīng)用，和用于向發(fā)布/訂購代理器的數(shù)據(jù)處理系統(tǒng)傳送消息的消 息傳遞部件。如圖4所示，消息客戶機應(yīng)用使用上述消息API來調(diào)用(600) 發(fā)送消息操作，包括指定諸如保持需要的參數(shù)。消息API插入(610 )消息保 持標(biāo)記到消息的標(biāo)題字段中。消息客戶機系統(tǒng)的消息傳遞部件實現(xiàn)消息傳遞 協(xié)議和路由功能，以向代理器傳遞(620)消息。
很明顯，對本領(lǐng)域技術(shù)人員來說，在本發(fā)明的范圍內(nèi)可以對上述實施例 進行各種修改和補充，并且以下陳述的權(quán)利要求不應(yīng)該解釋為局限于以上詳 細(xì)描述的特定說明性實施例。
權(quán)利要求
1、一種用于在發(fā)布/訂購系統(tǒng)中對發(fā)布的保持進行控制的方法，該方法包括發(fā)布/訂購代理器從發(fā)布器接收發(fā)布；該發(fā)布/訂購代理器標(biāo)識發(fā)布器指定的、是否應(yīng)該與以前的保持發(fā)布相關(guān)聯(lián)地保持該發(fā)布的標(biāo)記；以及該發(fā)布/訂購代理器通過與該以前的保持發(fā)布相關(guān)聯(lián)地保持該新發(fā)布來響應(yīng)該發(fā)布器指定的標(biāo)記。
2、 根據(jù)權(quán)利要求1所述的方法，其中該發(fā)布器指定的標(biāo)記包括添加指令， 與該以前的保持發(fā)布相關(guān)聯(lián)地保持該新發(fā)布的步驟包括向該以前的保持發(fā) 布內(nèi)的數(shù)據(jù)中添加所接收發(fā)布中的數(shù)據(jù)。
3、 根據(jù)權(quán)利要求1所述的方法，其中與該以前的保持發(fā)布相關(guān)聯(lián)地保持 該新發(fā)布的步驟包括與描述獨立的發(fā)布之間的聯(lián)系的信息一起保持該多個 獨立的發(fā)布。
4、 根據(jù)前述任一權(quán)利要求所述的方法，其中該發(fā)布/訂購代理器響應(yīng)沒 有所述發(fā)布器指定的標(biāo)記，對于仍然需要保持的發(fā)布，覆蓋以前的保持發(fā)布。
5、 根據(jù)權(quán)利要求4所述的方法，其中所接收的發(fā)布包括具有消息標(biāo)題和 消息主體的消息，其中該消息標(biāo)題包括指示該發(fā)布器是否需要保持該消息主 體的第一字段和包括該發(fā)布器指定的、是否應(yīng)該與以前的保持發(fā)布相關(guān)聯(lián)地 保持該消息主體的標(biāo)記的第二字段。
6、 根據(jù)前述任一權(quán)利要求所述的方法，用于基于主題的發(fā)布/訂購系統(tǒng)， 其中訂購器指定訂購內(nèi)感興趣的主題，以及其中該發(fā)布/訂購代理器的匹配引 擎對在接收發(fā)布中指定的主題與訂購器指定的、該發(fā)布/訂購代理器所擁有的 訂購主題進行比較，其中該代理器響應(yīng)包括訂購器指定主題的新訂購的接收，傳遞當(dāng)前由該 代理器保持的、適合于該訂購器指定主題的任一發(fā)布到相應(yīng)的訂購器。
7、 根據(jù)權(quán)利要求2所述的方法，包括檢驗該添加數(shù)據(jù)的步驟是否將超過 最大消息大小的步驟，以及如果該添加數(shù)據(jù)的步驟將超過該最大消息大小， 則拒絕該添加指令。
8、 根據(jù)權(quán)利要求7所述的方法，其中該發(fā)布/訂購代理器響應(yīng)所述拒絕， 以與以前的保持發(fā)布相關(guān)聯(lián)地保持該新發(fā)布。
9、 一種用于發(fā)布/訂購?fù)ㄐ啪W(wǎng)絡(luò)的發(fā)布/訂購代理器，該代理器包括 從發(fā)布器接收發(fā)布的裝置；比較接收發(fā)布與存儲訂購來標(biāo)識匹配的發(fā)布的訂購匹配部件，從而標(biāo)識 該匹配發(fā)布應(yīng)該被轉(zhuǎn)發(fā)到的訂購器；轉(zhuǎn)發(fā)匹配發(fā)布到所標(biāo)識的訂購器的裝置；以及保持管理器，其中該保持管理器響應(yīng)發(fā)布器指定的、該發(fā)布是否應(yīng)該與 以前的保持發(fā)布相關(guān)聯(lián)地保持的標(biāo)記，來與該以前的保持發(fā)布相關(guān)聯(lián)地保持 該新發(fā)布。
10、 一種向通信網(wǎng)絡(luò)內(nèi)的發(fā)布/訂購代理器發(fā)布消息的消息客戶機，該發(fā) 布/訂購消息客戶機包括調(diào)用向該發(fā)布/訂購代理器發(fā)送消息的操作的裝置；以及 在該消息內(nèi)指定應(yīng)該由該代理器與以前的保持消息相關(guān)聯(lián)地保持該消息 的裝置。
全文摘要
提供了在發(fā)布/訂購系統(tǒng)中對發(fā)布的保持進行管理的方法、數(shù)據(jù)處理系統(tǒng)和計算機程序。發(fā)布器向發(fā)布/訂購代理器發(fā)送新發(fā)布，其中標(biāo)記是否應(yīng)該與以前的保持發(fā)布相關(guān)聯(lián)地保持該新發(fā)布。發(fā)布/訂購代理器通過與以前的保持發(fā)布一起保持新發(fā)布來響應(yīng)這樣的標(biāo)記。新發(fā)布消息的內(nèi)容或者“有效載荷”可以添加到以前的保持消息中，從而導(dǎo)致包括多個發(fā)布消息中的信息的單個保持消息。
文檔編號H04L12/18GK101192942SQ200710186338
公開日2008年6月4日 申請日期2007年11月12日 優(yōu)先權(quán)日2006年11月30日
發(fā)明者加雷斯·E·瓊斯, 安德魯·J·斯坦福-克拉克, 本杰明·J·弗萊徹, 馬修·R·懷特黑德 申請人:國際商業(yè)機器公司