專利名稱：管理多個異構(gòu)網(wǎng)絡(luò)的系統(tǒng)中實時事件監(jiān)視的發(fā)布和預(yù)訂方法
技術(shù)領(lǐng)域：
本發(fā)明的領(lǐng)域是網(wǎng)絡(luò)管理和支持。更確切地說，本發(fā)明提供的系統(tǒng)用于遠(yuǎn)程地和可靠地監(jiān)視和管理多個異構(gòu)的網(wǎng)絡(luò)和系統(tǒng)，它除了其他能力，還能夠遍及全部被管理的網(wǎng)絡(luò)，選擇性地或全局地實時監(jiān)視若干事件，以及訪問和管理個別網(wǎng)絡(luò)部件達(dá)到每個被管理網(wǎng)絡(luò)內(nèi)的任何內(nèi)部深度，而不要求對所述網(wǎng)絡(luò)的特殊訪問，并且不考慮所述被管理網(wǎng)絡(luò)的或其內(nèi)的架構(gòu)、商業(yè)目的或?qū)ぶ纺Ｊ健?br> 背景技術(shù)：
現(xiàn)代數(shù)據(jù)和通信網(wǎng)絡(luò)高度復(fù)雜而且要求大量的管理，以便使這些網(wǎng)絡(luò)及其提供的服務(wù)保持正常且平穩(wěn)運行?！熬W(wǎng)絡(luò)管理”范圍內(nèi)的行為之一是監(jiān)視網(wǎng)絡(luò)以及其系統(tǒng)和組件的最佳狀態(tài)，以便盡快地，優(yōu)選情況下在用戶或商業(yè)過程受到影響之前發(fā)現(xiàn)問題。這樣的管理范圍內(nèi)的其他行為包括運行、監(jiān)管、維護和進行規(guī)定。為了逐個網(wǎng)絡(luò)地提供以上引用的所述類型的管理和支持，存在著眾多的系統(tǒng)。許多組織需要復(fù)雜的網(wǎng)絡(luò)，但是缺乏管理它們的資源，缺乏為其個體網(wǎng)絡(luò)獲得完全配備的管理系統(tǒng)的預(yù)算，或者相信要是這種行為可能外包的話他們會更節(jié)省。不過，如果為多個異構(gòu)客戶承擔(dān)管理網(wǎng)絡(luò)任務(wù)的組織必須為每個客戶提供分開的管理基礎(chǔ)設(shè)施，它將面對成倍增加的花費。所以，需要的系統(tǒng)能夠遠(yuǎn)程地但是集中地和可靠地管理多個異構(gòu)網(wǎng)絡(luò)，意味著擁有不同的所有權(quán)或處在不同的管理之下的網(wǎng)絡(luò)，或者在另外的情況下以具有不同架構(gòu)、不同管理策略、不同商業(yè)目的和/或不同整體設(shè)計為特征的多個網(wǎng)絡(luò)。為了支持網(wǎng)絡(luò)和任何給定網(wǎng)絡(luò)之內(nèi)的或針對該任何網(wǎng)絡(luò)設(shè)備的網(wǎng)絡(luò)設(shè)備管理，存在著大量的訪問方法。訪問方法包括簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)、命令行界面(CLI)、定制 XML、CMIP、Windows 管理規(guī)范(WMI)、事務(wù)處理語言 l、C0RBA、netconf、Java管理擴展(JMX)、 Java消息服務(wù)(JMS)、SOAP以及XML-RPC。這些主要是底層協(xié)議，有助于完成若干管理工作，但是不針對在管理多個異構(gòu)網(wǎng)絡(luò)中所涉及的問題。如上所述，當(dāng)前存在著管理整個企業(yè)級網(wǎng)絡(luò)的若干系統(tǒng)。流行的系統(tǒng)包括惠普公司的Open View 、Computer Associates 的 Ulliceilter 以及 IBM Tivoli 框架。 不過，開發(fā)這些系統(tǒng)主要是為了管理個別企業(yè)級網(wǎng)絡(luò)。對于管理完全異構(gòu)網(wǎng)絡(luò)它們的能力有限。這樣的系統(tǒng)的另一個實例是Solarwinds Orion 網(wǎng)絡(luò)性能監(jiān)視器。不過， Solarwinds系統(tǒng)使用無狀態(tài)的通信方法并且它針對監(jiān)視而不是被監(jiān)視網(wǎng)絡(luò)內(nèi)各個設(shè)備的遠(yuǎn)程管理。一種有些不同的方式是如美國專利公開號2006/0218267 Al所反映的Jumpnode Systems LLC的方式，它提供的硬件設(shè)備能夠被安裝在本地網(wǎng)絡(luò)，以便監(jiān)視本地網(wǎng)絡(luò)事件并向遠(yuǎn)程管理中心傳送所收集的信息。不過，Jumpnode 設(shè)備在本地跟蹤網(wǎng)絡(luò)事件，所以容易丟失連接從而丟失數(shù)據(jù)造成安全風(fēng)險。另外，每個硬件設(shè)備都必須有自己的特有“因特網(wǎng)訪問(Internet drop) ”(或從本地網(wǎng)外可以直接訪問其他的接入點(比如調(diào)制解調(diào)器端口))，以便對遠(yuǎn)程管理設(shè)施進行必不可少的連接，以及這些設(shè)備依賴無狀態(tài)通信和輪詢，這對于實時數(shù)據(jù)采集是不提供的。對于網(wǎng)間通信也存在著若干工具，比如代理服務(wù)器、遠(yuǎn)程控制軟件系統(tǒng)比如 GoToMyPC (現(xiàn)在由 Citrix Systems所擁有)和 Alarmnet (由 Honeywell Security Systems所有)。不過，如果沒有允許更深層訪問的特殊裝置，比如特殊的證書、VPN訪問權(quán)限、防火墻中的特殊開口等，或者手工建立的套接字和隧道，這些工具不提供在被管理網(wǎng)絡(luò)第一層之外通信的方式。它們也不提供減少巨大數(shù)據(jù)量的機制，其中巨大的數(shù)據(jù)量可能是由跨越多個所管理網(wǎng)絡(luò)和系統(tǒng)無選擇監(jiān)視一切事件，而不是選擇性地一次僅僅觀察一個數(shù)據(jù)源而導(dǎo)致的。另外，由于通常是從與終端用戶社區(qū)網(wǎng)絡(luò)分開的管理網(wǎng)絡(luò)執(zhí)行集中化的輪詢，導(dǎo)致了缺乏以終端用戶的本地觀點的所輪詢資源可用性的保真度。不僅如此，遠(yuǎn)距離的測量可能在取得的實際測量結(jié)果中引入人為統(tǒng)計假象，比如等待時間。同樣，為了將網(wǎng)絡(luò)的內(nèi)部運行和資源與外部觀察和訪問相隔離，也存在著若干工具比如網(wǎng)絡(luò)地址翻譯(NAT)，并且NAT系統(tǒng)能夠被配置為將消息轉(zhuǎn)發(fā)到指定的內(nèi)部網(wǎng)絡(luò)目的地和資源。這種方案的實例反映在美國專利號6，581，108 (轉(zhuǎn)讓給Lucent Technologies, Inc.)以及美國專利公開號 2005/0271047 Al 和 2006/0029084 Al 中。不過，這樣的設(shè)施對遠(yuǎn)程管理實用性有限。從NAT域內(nèi)部啟動的NAT連接是基于會話的?？梢灾贫ㄌ厥獾臈l款以轉(zhuǎn)發(fā)從外部啟動的連接。不過，經(jīng)由NAT防火墻從外部管理網(wǎng)絡(luò)是不切實際的，因為人們將不得不配置NAT使NAT內(nèi)的每個網(wǎng)絡(luò)部件從外部可訪問。已經(jīng)嘗試管理多個網(wǎng)絡(luò)的若干系統(tǒng)尚未滿意地應(yīng)對許多問題，包括 被管理網(wǎng)絡(luò)之間的重疊私有地址。異構(gòu)網(wǎng)絡(luò)有充分的理由可以利用相同的私有地址分配，從而導(dǎo)致沖突?，F(xiàn)有的變通方案已經(jīng)涉及分配不同的網(wǎng)絡(luò)模式，這可能非常不方便而昂貴，尤其是根據(jù)需要立刻改變整個模式之時；通過VPN或靜態(tài)路由每次連接到一個網(wǎng)絡(luò)，從而在監(jiān)視中創(chuàng)建若干時間間隔或者以大量復(fù)制和費用為代價提供多個管理基礎(chǔ)設(shè)施。轉(zhuǎn)讓給Ricoh Company, Ltd的美國專利號7，302，469中反映的另一種方式是轉(zhuǎn)而使用假設(shè)為全局唯一的模式，比如基于MAC地址的模式。不過，這樣的系統(tǒng)盡管提供了監(jiān)視功能，卻不為這些設(shè)備的本地網(wǎng)絡(luò)之外的遠(yuǎn)程設(shè)施提供任何裝置來為了管理這些設(shè)備而單獨對其尋址。 訪問和管理每個網(wǎng)絡(luò)內(nèi)的過程和資源的特殊裝置的需要。如果不提供某些“特殊”訪問裝置比如VPN、防火墻中的孔等，還不存在遠(yuǎn)程地管理網(wǎng)絡(luò)過程和資源的一般方法。 一切現(xiàn)有方案都涉及昂貴、不便或安全妥協(xié)，對于網(wǎng)絡(luò)管理服務(wù)的許多潛在客戶而言，這些是無法接受的。 不可抗拒的網(wǎng)絡(luò)事件信息量。每個網(wǎng)絡(luò)都能夠產(chǎn)生非常高的為了監(jiān)視目的的事件信息量。當(dāng)多個網(wǎng)絡(luò)為管理而聚集時，這種信息量將翻倍?，F(xiàn)有的系統(tǒng)尚未恰當(dāng)?shù)貞?yīng)對以下問題如何將事件信息限制為相關(guān)信息，而不損害監(jiān)視相關(guān)信息的連續(xù)能力。
所以，需要從單一的公共基礎(chǔ)設(shè)施來管理和服務(wù)多個異構(gòu)網(wǎng)絡(luò)的實際而有效的方法，其方式由通行的客戶防火墻和安全實踐所支持，無須對特殊訪問和會聚的網(wǎng)絡(luò)管理應(yīng)用程序進行廣泛的或不一致的規(guī)定，它利用這些技術(shù)并作為服務(wù)供給管理平臺，能夠觀察和/或管理所述集合體中全部被管理的網(wǎng)絡(luò)，或者分別地觀察和/或管理全部被管理的網(wǎng)絡(luò)中的任何一個。

發(fā)明內(nèi)容
本發(fā)明的一個目的是提供從單一的公共基礎(chǔ)設(shè)施來管理和服務(wù)多個異構(gòu)網(wǎng)絡(luò)的若干方法，不要求被管理的所述網(wǎng)絡(luò)或系統(tǒng)的任何擁有者改變?nèi)魏瓮負(fù)涮卣骰虿考?。本發(fā)明的進一步目的是通過提供克服被管理的網(wǎng)絡(luò)和系統(tǒng)之間可能存在的地址空間沖突的方法，便利對多個異構(gòu)網(wǎng)絡(luò)的管理和服務(wù)方法。本發(fā)明的另一個目的是為了路由管理部件之間的通信而提供統(tǒng)一的和全面的方法和協(xié)議，以便能夠建立可擴展地根據(jù)基礎(chǔ)管理部件的可管理選擇的管理基礎(chǔ)設(shè)施。本發(fā)明的目的還有在管理和支持異構(gòu)網(wǎng)絡(luò)和系統(tǒng)的系統(tǒng)中提供一種方法，用于遠(yuǎn)程地觀察有關(guān)多個網(wǎng)絡(luò)管理過程的實時信息，既不接受巨大數(shù)量的無關(guān)數(shù)據(jù)，也不限制所述數(shù)據(jù)觀察以防排除相關(guān)的數(shù)據(jù)。本發(fā)明的附加目的是利用所述技術(shù)滿足以上的各個目的，以便提供會聚的網(wǎng)絡(luò)管理應(yīng)用程序，它供給管理平臺作為服務(wù)，能夠觀察和/或管理所述集合體中全部被管理的網(wǎng)絡(luò)，或者分別地觀察和/或管理它們中任何一個。為了實現(xiàn)這些目的，在一個實施例中，本發(fā)明提供了從離開多個異構(gòu)網(wǎng)絡(luò)或系統(tǒng)中任何一個的位置的集中物理位置監(jiān)視和管理所述被管理的網(wǎng)絡(luò)和系統(tǒng)的系統(tǒng)，其中實現(xiàn)了所述操作而不要求被管理的任何網(wǎng)絡(luò)或系統(tǒng)的擁有者改變?nèi)魏瓮負(fù)涮卣骰虿考?，并且不要求到所述被管理網(wǎng)絡(luò)中任何一個的專用連接。這種系統(tǒng)能夠被提供為服務(wù)，用戶通過它能夠觀察和/或管理所述集合體中全部被管理的網(wǎng)絡(luò)，或者分別地觀察和/或管理它們中任何一個。為了便利管理多個異構(gòu)網(wǎng)絡(luò)和系統(tǒng)的能力，在一個實施例中，本發(fā)明進一步提供管理對于網(wǎng)絡(luò)的相應(yīng)部件具有重疊IP地址模式的網(wǎng)絡(luò)拓?fù)涞哪芰Γ绞綖樵诿總€部件的本地域內(nèi)結(jié)合唯一標(biāo)識符和所述部件的地址，以及使所述結(jié)合的唯一標(biāo)識符對所述管理系統(tǒng)中其他部件可用。為了便利所述能力，在通過模塊軟件組件提供這樣的能力的實施例中，本發(fā)明進一步提供了在這樣的組件之間為命令選路的方法，方式為明示地或暗示地指定路由；指定命令；以所述路由和命令作為參數(shù)調(diào)用套接字；根據(jù)所述路由為所述命令和參數(shù)選路；在所述路由目標(biāo)以所述命令的參數(shù)執(zhí)行它；通過所述路由返回所述執(zhí)行的任何結(jié)果；以及在所述執(zhí)行完成后關(guān)閉所述路由。在所述實施例中，本發(fā)明提供了所述管理系統(tǒng)訪問多個網(wǎng)絡(luò)設(shè)施的多個網(wǎng)絡(luò)管理過程的方法，方式為對所述網(wǎng)絡(luò)設(shè)施中選定的一個請求預(yù)訂所述設(shè)施上的網(wǎng)絡(luò)管理過程； 以及與所述設(shè)施更新所述信息的其自身內(nèi)部表達(dá)大約同時地，向所述管理系統(tǒng)中繼關(guān)于被預(yù)訂的網(wǎng)絡(luò)管理過程的改變后信息。這種機制在本文稱為“發(fā)布和預(yù)訂”，用于出于管理目的，對于集中和分別管理的網(wǎng)絡(luò)，支持豐富多彩的信息輸出和顯示。
根據(jù)以下的附圖和詳細(xì)說明，本發(fā)明的其他方面和優(yōu)點將顯而易見。


為了更全面地理解本發(fā)明及其優(yōu)點，現(xiàn)在連同附圖參考以下說明，其中相同的附圖標(biāo)記表示相同的部件，其中圖1是框圖，顯示了本發(fā)明一個實施例的示范配置中的多種部件，以及這些部件的互連；圖2是框圖，顯示了本發(fā)明一個實施例中所用的選路方法和協(xié)議的套接字和信道連接；圖3是框圖，顯示了服務(wù)器組件和客戶機應(yīng)用程序的示范組，使用根據(jù)本發(fā)明的發(fā)布和預(yù)訂機制的一個實施例，在客戶機上顯示數(shù)據(jù)；圖4描繪了示范網(wǎng)絡(luò)管理應(yīng)用程序的頂層屏幕顯示，顯示了受管理的多個異構(gòu)網(wǎng)圖5描繪了示范網(wǎng)絡(luò)管理應(yīng)用程序的屏幕顯示，針對被管理網(wǎng)絡(luò)的選定的一個的監(jiān)視和管理；圖6是屏幕顯示的示范描繪，顯示了根據(jù)本發(fā)明的一個實施例被監(jiān)視的所選定被管理網(wǎng)絡(luò)的事件列表；圖7是屏幕顯示的示范描繪，顯示了根據(jù)本發(fā)明的一個實施例，隨時間對所選定網(wǎng)絡(luò)端口使用的監(jiān)視；圖8是屏幕顯示的示范描繪，顯示了被管理網(wǎng)絡(luò)的“儀表板”視圖，包括網(wǎng)絡(luò)圖和若干部件的顯示；圖9是屏幕顯示的示范描繪，顯示了中央通信管理器(CM)處理器的最佳狀態(tài)矩陣；圖10是屏幕顯示的示范描繪，以QOS顯示顯示了電話跟蹤路由；圖11是屏幕顯示的示范描繪，顯示了一個電話跟蹤路由的QOS細(xì)節(jié)；圖12是屏幕顯示的示范描繪，顯示了策略設(shè)置模塊；圖13是屏幕顯示的示范描繪，顯示了隨時間的當(dāng)前服務(wù)的等級，加上移動平均數(shù)的顯示。
具體實施例方式以下是為了提供本發(fā)明可以如何優(yōu)選地實施的展示性實例而選定的本發(fā)明某些實施例的詳細(xì)說明。本發(fā)明的范圍不限于所介紹的若干特定實施例，它也不限于在附圖所描繪的或者在本發(fā)明的發(fā)明內(nèi)容或摘要中所陳述或介紹的任何特定實施、組成、實施例或特征。另外應(yīng)當(dāng)注意，本公開介紹了許多方法，每個都包括多個步驟。在本書面說明書中含有的任何內(nèi)容都不應(yīng)當(dāng)理解為暗示這樣的方法中任何必要的步驟次序，除非由明確的權(quán)利要求語言所規(guī)定。為了理解本說明書并解釋所附帶的權(quán)利要求書，應(yīng)當(dāng)以特定定義的方式理解某些術(shù)語?！爱悩?gòu)網(wǎng)絡(luò)”意味著在不同所有權(quán)或處于不同管理下的若干網(wǎng)絡(luò)，或者其他以具有不同架構(gòu)、不同管理策略以及可能互相沖突的地址模式為特征的若干網(wǎng)絡(luò)?！疤捉幼帧币馕吨p向通信鏈接中的端點。TCP/IP套接字是一種套接字，但是還存在著不是TCP/IP套接字，或者雖然從與TCP/IP套接字相同抽象基類實例化，但是不具有 TCP/IP套接字的完全功能的其他套接字(并且在本發(fā)明的語境中使用)。示范系統(tǒng)架構(gòu)圖1是高層框圖，顯示了本發(fā)明一個實施例示范配置中多種部件的概觀，以及這些部件的互連。這幅圖顯示了網(wǎng)絡(luò)101、102等，到10x，屬于客戶商務(wù)單元1、2等，直到客戶商務(wù)單元X。這些客戶商務(wù)單元可以是完全不相關(guān)的商務(wù)組織，其共同點僅僅在于它們使用相同的服務(wù)供應(yīng)商管理其各自的網(wǎng)絡(luò)。客戶商務(wù)單元1的網(wǎng)絡(luò)101比其他的網(wǎng)絡(luò)顯示得更詳細(xì)，盡管應(yīng)當(dāng)理解，其他單元可以具有圖1中未顯示的相當(dāng)?shù)摹⒏鼜?fù)雜的或更簡單的網(wǎng)絡(luò)?？蛻羯虅?wù)單元1被顯示為具有三個位置，111(主位置)、112和113。在每個位置處的網(wǎng)絡(luò)基礎(chǔ)設(shè)施內(nèi)是遠(yuǎn)程智能網(wǎng)關(guān)(RIG)。RIG CLl-RIG1在位置111、RIGBUl-RKi2在位置 112，而RIG BUl-RK3在位置113。在數(shù)據(jù)中心120內(nèi)提供了中央智能平臺(CIP)。在這個實施例中，數(shù)據(jù)中心120是單一設(shè)施，通過SRSTP (安全遠(yuǎn)程會話傳輸協(xié)議，將在以下進一步詳細(xì)介紹)維持著與客戶商務(wù)單元1至χ中每個單元的連接121、122和12x，更確切地說 (如由虛線121、122和12x的客戶側(cè)延續(xù)所示)與所述RIG的連接，對于網(wǎng)絡(luò)管理目的它被視為客戶商務(wù)單元的主要設(shè)施。這些RIG的每一個都經(jīng)由SRSTP同樣地連接到緊接的下游客戶位置處的RIG，如由虛線131、132所示。CIP 120基于延伸RIG所基于的類的軟件結(jié)構(gòu)運行，因而，除了相當(dāng)可觀的添加功能，CIP 120還包含RIG的全部功能和屬性?？朔悩?gòu)系統(tǒng)之間的地址空間沖突企業(yè)網(wǎng)絡(luò)可以使用全局或私有IP尋址。由于全局唯一 IP地址的短缺，許多企業(yè)都選擇由RFC 1918定義或者依據(jù)其他廣泛接受的慣例的私有地址空間之一。這些都提供了在某組織內(nèi)可私人使用的地址范圍，并不通過公共網(wǎng)絡(luò)選路，所以不要求必須是全局唯一的。因而完全有可能兩個或多個客戶商務(wù)單元101至IOx可能已經(jīng)采用了重疊的私有地址模式，并且如果直接連接在一起將發(fā)生沖突。例如，客戶商務(wù)單元1(網(wǎng)絡(luò)101)和客戶商務(wù)單元2 (網(wǎng)絡(luò)10 可能每個都已經(jīng)獨立地采用了 172. 16. 0. 0/12的私有尋址模式。在每個網(wǎng)絡(luò)內(nèi)存在的設(shè)備可能具有相同地址，例如172. 16. 7. 33。為了能夠集中地管理兩個系統(tǒng)，需要某種手段區(qū)分受管理的異構(gòu)網(wǎng)絡(luò)中初始已經(jīng)分配了相同地址的兩個節(jié)點。從私有地址節(jié)點自身尋址域之外與其通信，最廣泛使用的方法是“網(wǎng)絡(luò)地址翻譯”(NAT)。不過，NAT是基于會話的協(xié)議，其中會話通常從內(nèi)部啟動。對于管理這是不夠的，在管理中往往必須從所管理網(wǎng)絡(luò)之外部啟動接觸。另一種方式是NAT路由器或代理服務(wù)器按照特殊的數(shù)據(jù)入口轉(zhuǎn)發(fā)通信，但是這實際上在企業(yè)的防火墻中留下了“孔”，從而造成管理負(fù)擔(dān)和安全風(fēng)險。另一種變通方案可能是將全部受影響的網(wǎng)絡(luò)重新分配給大的地址空間，比如5. 0. 0. 0/8。不過，這樣的改變要求網(wǎng)絡(luò)上的一切都必須突然移動到新的地址模式，這可能由于資源密集和昂貴而令人望而卻步。本發(fā)明的一個實施例通過下列技術(shù)解決了這個問題 在被管理拓?fù)涞谋镜夭渴鹣到y(tǒng)(比如，RIG) 在RIG上抽象并標(biāo)注該RIG本地基礎(chǔ)設(shè)施中的名稱和屬性 用唯一的 ID (如 CL1-RIG1)加上時間戳(如 2008-0601-21 33 17. 04)命名 RIG
7
為了若干網(wǎng)絡(luò)公共管理的目的，將所述名稱與每個基礎(chǔ)設(shè)施部件的私有地址結(jié)合以形成新的“地址” 以上游寄存器可訪問的方式在RIG上的部件列表中發(fā)布這些管理地址以這種方式，上游雙親(不是另一個RIG就是所述CIP)就能夠查詢?nèi)魏蜗掠蔚?RIG (基于身份驗證和可適用的策略)，得到目錄信息。然后上游雙親能夠使用這些地址將命令指引至RIG的本地網(wǎng)絡(luò)內(nèi)部的部件。所有這樣的命令都將通過該本地RIG，達(dá)到用作代理的程度。同樣的尋址模式還將使得上游雙親能夠與第一個RIG下游的其他RIG進行通信。 例如，CIP 120能夠發(fā)送去往RIG 130的本地網(wǎng)絡(luò)基礎(chǔ)設(shè)施中某設(shè)備的命令。CIP 120 “知道”該目的地設(shè)備的地址，因為RIG 130的目錄被發(fā)布給了 RIG 110，并且又發(fā)布給了 CIP 120，因此能夠?qū)⒛趁畹牡刂反_定為RIG 130本地的設(shè)備，方式為經(jīng)由RIG 110發(fā)送該命令(不過，該命令如何選路是(下面討論的)SRSTP協(xié)議的功能，而不是尋址本身的功能)。詵路方法和協(xié)議由圖1架構(gòu)所呈現(xiàn)的另一個問題是選路，正如已經(jīng)由以上討論的尋址所建議。該問題是在已經(jīng)部署了多個軟件模塊如用于本地網(wǎng)絡(luò)管理的模塊的系統(tǒng)中，如何為命令和執(zhí)行命令的結(jié)果選路，以達(dá)到獲取集中管理整個模塊集(以及相關(guān)聯(lián)的部件)的有效能力的目的。這要求靈活的、啟用網(wǎng)絡(luò)的機制以在模塊軟件系統(tǒng)中為命令選路。更一般地說，為了完全實現(xiàn)圖1描繪的管理網(wǎng)絡(luò)所需的功能，需要一種模塊間通信和管理的方法，它能夠?qū)Ш饺我鈴?fù)雜的拓?fù)涠恍枰獮榱送ㄐ藕凸芾淼耐葟?fù)雜的預(yù)設(shè)置。例如，參考圖1可見，為了管理網(wǎng)絡(luò)101、102等，必須能夠為多種管理命令選路到該網(wǎng)絡(luò)的全部區(qū)域，并且可以將該網(wǎng)絡(luò)通過RIG的深度被“分層”。圖1以最簡單的形式將其顯示為RIG 110和RIG130的鏈條，當(dāng)然這種結(jié)構(gòu)可以被延伸至任意深度，并且整個基礎(chǔ)設(shè)施都將受到管理。最典型的情況下，利用若干協(xié)議比如RPC、RMI、Corba、JMS (Java消息服務(wù))、S0AP、 XML-RPC(以及其他類似的協(xié)議)在網(wǎng)絡(luò)環(huán)境中執(zhí)行命令。不過，這些都是點到點的協(xié)議，并且除了在調(diào)用命令的環(huán)境中另外提供的選路之外不具有選路。在當(dāng)前情況下，這樣的選路不一定存在。對于以上一般討論的原因，不期望在不是另外要求的情況下僅僅為了啟動管理功能而不得不建立這樣的一般選路。另外，當(dāng)集中管理時，為了安全的目的，需要保持不同客戶網(wǎng)絡(luò)的分離。通過鏈接一系列的互動協(xié)議，比如telnet或SSH，可以在復(fù)雜系統(tǒng)中為命令選路， 并且“跳躍”到目的地設(shè)備。同樣，人們可以手工地建造需要的套接字和隧道。不過，為這樣的通信作準(zhǔn)備具有先前討論的管理和安全缺點。在某些方面類似于這里所計劃的一種分配類型是歷史上所進行的郵件選路，利用了 Unix到Unix復(fù)制(UUCP)的郵件遞送協(xié)議。去往不在本地但是通過機器box2連接的機器box3上用戶的郵件消息將被提交到box2 ！ box3 ！用戶(稱為“bang”協(xié)議)。不過， UUCP協(xié)議是單向的。如果用于提交命令，它將不返回執(zhí)行命令的結(jié)果，因此可能缺乏網(wǎng)絡(luò)管理。圖2是框圖，顯示了本發(fā)明一個實施例中所用的選路方法和協(xié)議的套接字和信道連接。信道主控實例201、202和203代表著RIG。信道主控實例203是專用化的RIG，其主要功能是提供控制臺和⑶I界面。信道主控實例201可以是普通的RIG也可以是CIP (具有未顯示的附加功能部件)。另外，可以將信道主控實例鏈接到比圖2所示更深的深度，方式為添加信道主控實例并將其連接到上游信道主控實例上的附加信道連接，如類似于信道連接221、222的附加信道連接(未顯示)。在信道主控實例201、202的每個上顯示的模塊1、2和3代表著其各自信道主控實例本地的設(shè)備。ComStruc接口 231、232是信道主控實例201、202與相關(guān)聯(lián)模塊之間的相應(yīng)接口。每個信道主控實例都具有一個或多個信道連接，如到其他信道主控實例的信道連接221、222、225和226。優(yōu)選情況下，這些部件之間的實際連接是利用了 SSL隧道，盡管未必嚴(yán)格需要加密。具有完整GUI設(shè)施的實例以外的每個信道主控實例通常都具有相關(guān)聯(lián)的命令行界面，如MU42，僅僅由于歷史原因在圖2中稱為“海事終端”。每個信道主控實例還都具有稱為CSockets 051、252等)的通信接口，它經(jīng)由上述通信接口與外部設(shè)備和接口進行通信。某些CSockets如252、253以多個CSockets組的方式連接到所對應(yīng)的信道連接，反映了許多不同的管理過程能夠經(jīng)由相同的信道連接選路這個事實。在圖2下面的選路系統(tǒng)是基于命令的。最終，每個被選路的消息都遞送了將在路由鏈接的接收端上執(zhí)行的命令。這些命令經(jīng)由CSockets轉(zhuǎn)發(fā)。該結(jié)果是具有雙向套接字的命令混合。在示范系統(tǒng)中使用的命令包括的命令總數(shù)很大，并以樹的結(jié)構(gòu)排列，在某些方面類似于Microsoft NT 的NET命令，但是具有更多的選項。它們被稱為“Construe”命令。在本文附帶的附錄中闡述了許多示范ComStruc命令的列表，展示了這種命令層次的功能和語法。正如在附錄的表1中所見，在優(yōu)選實施例中，所述ComSruc命令形成了樹結(jié)構(gòu)，其中樹的“葉”為實際的命令，而“樹枝”為命令的容器(或種類)。通過級聯(lián)從樹根到所期望樹葉的信息串并添加任何必要的參數(shù)，就完整地規(guī)定了該命令。這樣的命令的實例(選路路徑部件不存在)是“tools restart”。在這個實例中，“tools”是容器，而“restart”是目標(biāo)(和ComStruc命令)。將給出某地址作為參數(shù)。該命令的效果是將在指定的地址處重新開始這種服務(wù)。可見，提供了許多其他命令。參數(shù)的實例是IP地址、設(shè)備名稱、用戶名稱、端口標(biāo)記等。目的是將命令遞歸地向下傳遞到所期望的目標(biāo)模塊。在SRSTP協(xié)議中，路由與所期望的命令一起被指定。選路路徑是“bang” ( “！ ”)分隔的服務(wù)器(RIG)名稱序列。SRSTP協(xié)議具有以下一般結(jié)構(gòu)(熟悉BNF和/或“man pages”的人不難認(rèn)識以下描述的格式)SRSTP 數(shù)據(jù)包[！ SERVER1NAME] [ ！ SERVER2NAME. . . ] ComStruc 命令[PARAMS]ComStruc 命令容器 +ComStruc 命令 | | 目標(biāo)PARAMS 字符串 *字符串:nonspacestring nonspacestring+CSocket擴充了 Java Socket類，但是這樣做是為了兼容而不是為了通信功能。 CSocket基于套接字最簡單的、非執(zhí)行調(diào)用的變量。提供了類似于套接字功能的通信功能， 但是獨立地提供而不通過繼承。
CSocket的構(gòu)造器接受ComStruc命令作為參數(shù)。如果該命令不具有明示指定的路由，則它被傳遞到本地的信道主控實例，后者將其傳遞到本地的ComStruc樹以找到目標(biāo)， 并且在可能時(在本地)執(zhí)行它。如果指定了路由，仍將該命令傳遞到信道主控實例(如 201)，但是然后被傳遞到其名稱與第一選路命令匹配的信道連接(如222)。它剝?nèi)テ渥陨淼拿Q(所收到路由字符串中的第一個名稱)并將其跨越SSL連接傳遞到同等信道連接 (如22 。該信道連接然后將該命令傳遞到其本地的信道主控實例(在這個實例中是202)。 然后在這個信道主控實例上重復(fù)相同的過程，必要時再次轉(zhuǎn)發(fā)該數(shù)據(jù)包，否則在本地執(zhí)行它。由于每個信道主控實例都具有相同的核心功能，所以這個過程可以以遞歸的方式不定次地繼續(xù)，以遍歷整個網(wǎng)絡(luò)直到已經(jīng)部署了信道主控實例的程度。命令執(zhí)行的結(jié)果以與普通Socket相同的方式反向傳遞(但是不使用Socket的實現(xiàn)，而是使用CSocket的自身實現(xiàn))。完成消息也從目標(biāo)被發(fā)送，以便關(guān)閉CSocket連接。更概括地說，以上介紹的優(yōu)選實施例提供了在模塊化的軟件系統(tǒng)中為命令選路的方法，包括·明示或暗示地指定路由 指定命令 以所述路由和命令為參數(shù)調(diào)用套接字 按照所述路由為命令和參數(shù)選路 在路由目標(biāo)處以命令參數(shù)執(zhí)行命令 經(jīng)由所述路由返回所述執(zhí)行的任何結(jié)果 當(dāng)所述執(zhí)行完成時關(guān)閉所述路由在容器和命令的層次中也可以提供前述方法中的命令。路由的鏈接都被隧道化， 優(yōu)選情況下通過SSL。也可以看出，根據(jù)之前的討論，以上介紹的實現(xiàn)SRSTP協(xié)議的系統(tǒng)一般提供了 應(yīng)用程序，暗示地或明示地指定了路由和命令并且以該路由和命令為參數(shù)調(diào)用
套接字 一種或多種本地設(shè)施，每種都包括 信道主控，通過將指定的路由與開放的信道連接進行匹配而建立路由 信道連接，將路由和命令的其余部分傳送到另一個信道連接，以及 執(zhí)行該命令的最后一個所述實例內(nèi)的目標(biāo)另外，在轉(zhuǎn)向討論的下一個主題之前應(yīng)當(dāng)指出，優(yōu)選實施例中提供的ComStruc命令之一，正如在附錄的表1中的闡述，是LocalConnect命令。在SRSTP上建立的CSocket 鏈的每個端點上使用LocalCormect，實質(zhì)上允許任何服務(wù)或網(wǎng)絡(luò)操作(如維護)經(jīng)由在套接字之間建立的SSL連接被隧道化，而不需要VPN。例如，這種機制可以容易地用于在CIP 控制臺與被管理網(wǎng)絡(luò)內(nèi)的深處資源之間建立telnet或SSH交互會話，或者建立遠(yuǎn)程桌面協(xié)議(RDP)會話，以便遠(yuǎn)程地控制該網(wǎng)絡(luò)中的計算機(無限制地包括經(jīng)由該計算機進行任何本地網(wǎng)絡(luò)管理操作)，等等。另外，以類似的方式，圖2中所反映的整個通信結(jié)構(gòu)可以與操作支持系統(tǒng)(OOS)串聯(lián)地部署，用作代理服務(wù)器，為OSS訪問所服務(wù)的網(wǎng)絡(luò)提供手段。根據(jù)前述應(yīng)當(dāng)顯而易見，SRSTP提供了網(wǎng)絡(luò)管理應(yīng)用的靈活基礎(chǔ)，尤其是對于遠(yuǎn)程地和集中地管理和支持異構(gòu)網(wǎng)絡(luò)。此外，本發(fā)明提供的分布式信息采集允許網(wǎng)絡(luò)管理者理解所管理部件的運行狀態(tài)，從被觀察部件的本地角度來看，這些部件可以跨越給定的網(wǎng)絡(luò)在不同的地理位置分布。 不僅如此，這樣分布的信息采集避免了引入測量假象，比如人為的等待時間?！鞍l(fā)布和預(yù)訂”機制現(xiàn)在我們轉(zhuǎn)向多個異構(gòu)網(wǎng)絡(luò)的管理系統(tǒng)能夠遠(yuǎn)程觀察多個網(wǎng)絡(luò)管理過程的有關(guān)實時信息的若干方法。這種能力對于一系列應(yīng)用程序是重要的，并且最基本的是，以便能夠有效地監(jiān)視受服務(wù)網(wǎng)絡(luò)的事件。對這個問題的現(xiàn)有解決方案，在甚至所嘗試的程度上，是連續(xù)地刷新所有網(wǎng)絡(luò)事件的全局顯示或數(shù)據(jù)庫，或者把數(shù)據(jù)采集事件限制為一次刷新一個來源。兩種方案都不完全令人滿意。前一種方案不是選擇性的并且不能縮放。后一種方案固有地放棄了實時監(jiān)視的所有能力。在一個實施例中，本發(fā)明使用可能被稱為“發(fā)布和預(yù)訂”(或作為替代，“預(yù)訂和推送”)的機制，用于遠(yuǎn)程地監(jiān)視多個異構(gòu)網(wǎng)絡(luò)中的事件。圖3是框圖，顯示了服務(wù)器組件和客戶機應(yīng)用程序示范組，實現(xiàn)發(fā)布和預(yù)訂機制以從遠(yuǎn)程網(wǎng)絡(luò)實時地獲取事件數(shù)據(jù)，并且在管理應(yīng)用程序中顯示數(shù)據(jù)。GXListClient 301 是客戶機應(yīng)用程序，例如CIP 120上的管理控制臺應(yīng)用程序(如圖1中)，或者上游的RIG、 GXListServer 系統(tǒng) 310、GXDataSource 311 >ComStrucTargets 312 禾Π ListSessions313 等， 全都駐留在被管理網(wǎng)絡(luò)320上。GXListClient 301在ComStruc隧道303上與被管理網(wǎng)絡(luò) 320通信，用以上連同附圖2所討論的方式。選路與連同圖2所討論的相同，但是為了簡單起見，圖3顯示了在ComStruc目標(biāo)312中終止的ComStruc隧道，它是連同圖2討論的命令樹(并且在圖2中顯示為Construe Interface 232)。在GXDataSource 311中保留了表格以保存被管理網(wǎng)絡(luò)320上每個受監(jiān)視過程的狀態(tài)信息。對每個這樣的表格，GXListServer 系統(tǒng)如313都存在。為了啟動發(fā)布和預(yù)訂過程，GXListClient如301在ComStruc隧道303上向Construe目標(biāo)312發(fā)送ComStruc DATA GXSTREAMCONNECT消息。這條命令進入 GXListServer 系統(tǒng) 310。GXListServer 系統(tǒng) 310 實例化列表會話，如 ListSession 313。(階段1)實例化后，ListSession313進入循環(huán)，傾聽改變跟蹤的請求(跟蹤改變)——對一定的列使用一定的過濾器的請求。請求者，在這種情況下是GXListClient 301，然后發(fā)送跟蹤改變請求(GXQUERY)。GXListClient使用CSocket (如圖2中)制作跟蹤改變請求。ListSession 313接收GXQUERY查詢命令然后進入“信息轉(zhuǎn)儲模式”，從而它收集了被預(yù)訂部件的全部應(yīng)答信息，并經(jīng)由ComStruc隧道303將其發(fā)回給該請求者(301)，同時向該請求者報告其進展。Listkssions 313還保存當(dāng)前查詢的記錄。在這一點上，就已經(jīng)建立了對指定網(wǎng)絡(luò)過程上指定更新的“預(yù)訂”。(階段2) GXListServer 310負(fù)責(zé)保存關(guān)聯(lián)表。目的地為GXDataSource 311的數(shù)據(jù)庫更新通過GXListkrver 310。每個數(shù)據(jù)庫更新請求也去往每個Listkssions對象313 等。在Listkssions對象313等內(nèi)，該更新請求與某過濾器和請求的列名進行匹配。如果存在著匹配(即如果數(shù)據(jù)庫服務(wù)器正在更新已經(jīng)被預(yù)訂的數(shù)據(jù))，在大約與進行實際數(shù)據(jù)庫更新相同的時間，該更新信息(它可以是添加、去除或改變)就被發(fā)送到GXListClient (如 301)。換言之，在已經(jīng)預(yù)訂了信息之后，更新本地表(也就是GXLisUerver 310)的“中間件”過程還將新數(shù)據(jù)復(fù)制到指向訂戶的套接字(也就是由ComStruc消息建立的CSocket)。 為了避免任何溢出，更新傳輸通過某隊列。以這種方式，所請求的信息被“發(fā)布”(或“推送”)給請求者。在套接字開放的任何時間，GXListClient 301都能夠請求新的過濾器和新的列， 在此情況下將存在著新的轉(zhuǎn)儲然后更新(階段2)。圖4至圖13顯示了可以從CIP 120運行的示范“管理控制臺”應(yīng)用程序的選定屏幕顯示，利用了以上介紹的“發(fā)布和預(yù)訂”機制，以及本文討論的尋址和選路技術(shù)。在所示的若干實例中，所討論的網(wǎng)絡(luò)處理IP電話(VOIP)以及數(shù)據(jù)通信。圖4顯示了管理控制臺的典型⑶I屏幕400。該屏幕的左上方面板401顯示了受管理的異構(gòu)網(wǎng)絡(luò)列表411、412等，屬于不同的公司。在其下方的區(qū)域407中是狀態(tài)匯總， 顯示了在多個狀態(tài)等級中每個的服務(wù)器數(shù)量以及相關(guān)聯(lián)的圖標(biāo)?？梢?，在這個實例中被觀察的所有五臺服務(wù)器都處于“良好”狀態(tài)，在左上方面板401中對應(yīng)項411、412等的旁邊顯示了對應(yīng)的“綠燈”圖標(biāo)408。右方面板402(分為上部分403和下部分404)顯示了對全體客戶要求操作員響應(yīng)的“警報”匯總。所顯示的警報也能夠經(jīng)由過濾器框405進行過濾。 對于每個警報都以表格形式顯示了一組數(shù)據(jù)，包括發(fā)生警報的服務(wù)器(421)、依賴此服務(wù)器資源鏈(“相關(guān)樹”)的頂節(jié)點(422)、報警等級(如0-5)、狀態(tài)(如新的、響應(yīng)的、關(guān)閉的) GM)、指示誰響應(yīng)此警報的響應(yīng)字段025)、日記項字段0沈)，它鏈接到具有更詳細(xì)描述的表，以及其他信息。右上方面板(40 匯總了尚未被響應(yīng)的全部當(dāng)前警報；右下方面板 (404)顯示被響應(yīng)的警報。當(dāng)某警報已經(jīng)得到解決，其顯示便從這個顯示中消失。用鼠標(biāo)在左上方面板401點擊網(wǎng)絡(luò)項411、412等之一，管理控制臺的用戶可以選擇被管理網(wǎng)絡(luò)之一。圖5顯示了管理控制臺用戶已經(jīng)選擇了以上連同圖4所討論的網(wǎng)絡(luò)之一后被顯示的屏幕。從這個屏幕，用戶可以使用各種各樣的工具觀察網(wǎng)絡(luò)的狀態(tài)，或者使用RIG的功能臨時地以遠(yuǎn)程網(wǎng)絡(luò)橋接客戶計算機，以便使用桌面共享應(yīng)用程序或者運行管理應(yīng)用程序。 在所示實施例中，根據(jù)默認(rèn)設(shè)置，這幅視圖顯示所選定網(wǎng)絡(luò)在這種情況下是HHR(511)的事件匯總。這個顯示的內(nèi)容經(jīng)由以上討論的“發(fā)布和預(yù)訂”機制提供。所述內(nèi)容是動態(tài)的，并且實時地連續(xù)刷新。通過點擊右上方面板503上主菜單530中的圖標(biāo)531等能夠轉(zhuǎn)入和轉(zhuǎn)出面板502中的多個其他顯示。所示事件匯總顯示也能夠通過點擊“Views (視圖)”按鈕 532然后點擊“Summary (匯總)”(541)達(dá)到。所列出的事件行561等每個都經(jīng)過顏色編碼，對應(yīng)討論中設(shè)備上的“Max Alert (最大報警)”。最大報警意味著設(shè)備相關(guān)鏈中最高的報警等級。對于每個事件，都有時間顯示571 ；“teXt_time (文本時間)”顯示572，它以被報告設(shè)備的本地時間指定；EventId 573，它指定了事件的類型；本地設(shè)備名稱，在這幅視圖中稱為subDeviceName 574 ；網(wǎng)絡(luò)，在這個視圖中稱為DeviceName 575(因為網(wǎng)絡(luò)是到上游RIG或CPI的“設(shè)備”)；以及其他信息。在這個實施例中，事件在可能時被“合并”。這意味著被視為“可合并的”事件，比如相繼的有效查驗，僅僅使其次數(shù)被更新并顯示先前事件時間，而不是以新的事件使該顯示混亂。在這樣的情況下，存在著“LaSt_teXt_time (最后文本時間)”577中的項表示前面被合并事件的時間。面板503中以“Summary(匯總)”541 開始的項目行被鏈接到其他顯示，包括以下討論的許多顯示。
12
圖6顯示了網(wǎng)絡(luò)管理控制臺屏幕，用于監(jiān)視被同時監(jiān)視的多個異構(gòu)網(wǎng)絡(luò)之一上的事件。當(dāng)選定了具體客戶網(wǎng)絡(luò)時，圖5中右方面板504顯示頂部控制條503和空間中下部屏幕504，它包含著用戶從控制條中所選定的組件視圖。用戶從主菜單530中選擇(例如)“Views (視圖)”532，然后從子菜單540中選擇“Events (事件)”542，Event Viewer組件將替換在面板504的組件視圖部分中的“Summary View(匯總視圖)”組件。管理系統(tǒng)已經(jīng)預(yù)訂了許多被管理網(wǎng)絡(luò)上的事件，但是所示圖6反映了限于一個具體客戶網(wǎng)絡(luò)(“HHR”511) 的顯示。圖6所示的事件列表是動態(tài)的并按照圖2展示的方法實時地自動更新。“Filter (過濾器)”部件605是全列的過濾器，根據(jù)任何列中能夠出現(xiàn)的關(guān)鍵字啟動快速過濾器。上方顯示面板603包含著尚未應(yīng)答的事件列表，每個事件都包括“time (時間)” 661、EventId 673、本地設(shè)備名(deviceName)674、受到任何影響的服務(wù)678、如果有的話，相關(guān)聯(lián)代理的 IP地址(agentlp)679以及其他信息。底部長方格604顯示了由下拉式控制691可調(diào)節(jié)的時間范圍內(nèi)全部事件的列表，這里顯示為六個小時。在面板603和604中(以及類似的其他顯示中)的若干列可以被GUI控制左右移動。最左邊的列用作該列表的分類關(guān)鍵字。按照默認(rèn)設(shè)置，分類關(guān)鍵字是時間列。圖7顯示了“系統(tǒng)監(jiān)視”類型的圖形顯示，顯示了作為時間函數(shù)的被管理系統(tǒng)上端口使用量的顯示。這個屏幕從圖5所示的監(jiān)視器鏈接543中也可到達(dá)。這些顯示隨著從右到左滾動的移動曲線圖而出現(xiàn)，從右側(cè)實時地更新，同樣按照圖2展示的方法。這個具體顯示圖顯示了在12小時的選定時間范圍(按照下拉控制791)內(nèi)某設(shè)備在插槽1中端口 8的使用情況。Y軸751以每秒位數(shù)顯示。下部面板705和706顯示了當(dāng)前視圖(703、705)適合更長時間線706的情況。該視圖時間框也可以通過面板705和706上的點擊和拖拉動作調(diào)節(jié)。作為替代，在這個展示中半透明窗口中顯示的所報告的每秒位數(shù)709等也可以顯示在動態(tài)顯示跡線開始處的右邊，以便不覆蓋該跡線。圖8是屏幕顯示的示范描繪，顯示了被管理網(wǎng)絡(luò)的“儀表板”視圖，包括網(wǎng)絡(luò)圖和若干部件的顯示。左側(cè)面板801顯示了網(wǎng)絡(luò)圖，具有連線821、822等，反映了通信和控制的連線。在這種情況下，CM831被顯示為連接到本地自存活的處理器(LSP)841、842等。LSP 841,842等被編程為在CM 831被停用或失去連接時自行承擔(dān)其自身的控制。在這樣的事件中，正常連接到CM 831的上游RIG(未顯示)將直接與LSP 841、842等連接，并且來自CM 831的上述控制連線822將消失。圖8的右方面板802顯示了頂層網(wǎng)絡(luò)部件(它們的每個都是相關(guān)樹)，具有其狀態(tài)的圖標(biāo)。沿著右方顯示面板802底部的鏈接851、852等是面板 802到其他“儀表板1示的鏈接，或者它們可以被顯示在其自身的窗口中，它們的每個都提供了一屏面關(guān)于所監(jiān)視網(wǎng)絡(luò)集中的、高層次的實時信息。圖9是屏幕顯示的示范描繪，顯示了中央通信管理器(CM)處理器的最佳狀態(tài)矩陣。它可以從圖8的處理器鏈接854中選擇。它顯示了處理器空閑的百分比(961)、處理器服務(wù)維護的百分比(962)、處理器用于電話呼叫的百分比(963)以及其他信息。圖10是屏幕顯示的示范描繪，顯示了具有QOS顯示的電話路由跟蹤。這個屏幕能夠通過點擊圖5中的電話QOS 545然后在列出電話的中間屏幕(未顯示)上點擊“Traces” 而到達(dá)。雙擊這個電話列表中的某項將帶出以下圖11所示的顯示。圖10顯示了用于所有電話的圖形路由跟蹤描述。這些電話能夠經(jīng)由過濾器控制1005過濾。每條路由跟蹤1041、 1042等的連線都將按照當(dāng)前的服務(wù)質(zhì)量(QOS)改變顏色，它是信息包丟失、來回行程時延和到達(dá)間隔抖動的函數(shù)(按照本領(lǐng)域熟知的方法計算)。圖11是屏幕顯示的示范描繪，顯示了一個電話路由跟蹤的QOS細(xì)節(jié)，包括來回行程時延1151、信息包丟失115 和1152b以及抖動1153a和1153b。抖動和信息包丟失的上下顯示1103和1104反映了路由跟蹤每個結(jié)尾處對應(yīng)的矩陣(如媒體處理器和電話)。圖12是顯示了策略設(shè)置模塊的屏幕顯示的示范描繪。為了觸發(fā)基于事件的標(biāo)準(zhǔn)化動作，比如報告、事件處理等，可以放置“策略”。策略被編程為流程圖和腳本類型的函數(shù)。 策略在顯示面板1203中經(jīng)由鼠標(biāo)可訪問的GUI控制(在所示的實例中，通過右擊可訪問的菜單)授權(quán)。每種創(chuàng)建的策略都被列在面板1202中。這種屏幕從圖4的ktup選項卡419 到達(dá)(Setup — Policy)。在所顯示流程圖1210中顯示的策略是對“虛擬”擴充的電話記錄 (因為物理電話不需要消息記錄)。為了取消代表虛擬擴充范圍的故障的事件，此策略產(chǎn)生新的事件，除非按照“IF”條件1211、1212，觀察到了服務(wù)中/掛機狀態(tài)和服務(wù)中/摘機狀態(tài)，在該情況下取消該事件。此策略導(dǎo)致對活動事件列表掃描軟電話故障，并且檢查確認(rèn)是否為軟電話故障。如果不是，它便發(fā)送新的事件取消該“故障”事件。因此，每種策略一旦建立，都會按照連同圖2所介紹的協(xié)議，基于實時監(jiān)視的事件連續(xù)地執(zhí)行其指定的條件。圖13是顯示了服務(wù)等級的監(jiān)視器的屏幕顯示的示范描繪。通過點擊在圖5中 “View(視圖)”鏈接532處開始的View — Service等級可到達(dá)這個顯示。圖13的顯示可以在分開的窗口中出現(xiàn)或在圖5的面板504中出現(xiàn)。圖13顯示了在由控制1391可選的時間框上的當(dāng)前服務(wù)等級(1311)，加上(按照控制139 在時間范圍內(nèi)被監(jiān)視服務(wù)等級的移動平均顯示1312，以及其他信息。同樣，這個顯示動態(tài)地顯示了被監(jiān)視網(wǎng)絡(luò)和資源的實時服務(wù)等級。應(yīng)當(dāng)顯而易見，圖4至圖13所展示的可運行實例，結(jié)合以上連同圖1至圖3所公開的技術(shù)，完全實現(xiàn)了會聚的監(jiān)視和管理平臺，按照本發(fā)明的目的，以服務(wù)的形式提供，能夠觀察事件和/或管理所述集合體中多個異構(gòu)網(wǎng)絡(luò)，或者分別地觀察和/或管理它們中任何一個，克服了過去不能提供這種系統(tǒng)的障礙，比如尋址沖突、沒有重大網(wǎng)絡(luò)變化或所不期望的補充基礎(chǔ)設(shè)施便不能在成員網(wǎng)絡(luò)內(nèi)路由、源于遠(yuǎn)程網(wǎng)絡(luò)測量和觀察的假象，以及由缺乏對每個被管理網(wǎng)絡(luò)的連續(xù)連接而產(chǎn)生的知識空缺。雖然已經(jīng)詳細(xì)地介紹了本發(fā)明，但是應(yīng)當(dāng)理解，本領(lǐng)域的技術(shù)人員可以容易地探知多種變化、替換和更改并可以在這里進行，而不脫離以下權(quán)利要求書所定義的本發(fā)明的實質(zhì)和范圍。附錄A表1 :Construc 命令層次
權(quán)利要求
1.一種管理系統(tǒng)訪問多個網(wǎng)絡(luò)設(shè)施的多個網(wǎng)絡(luò)管理過程的方法，包括(a)對所述網(wǎng)絡(luò)設(shè)施中選定的一個請求預(yù)訂所述設(shè)施上的網(wǎng)絡(luò)管理過程；以及(b)向所述管理系統(tǒng)中繼關(guān)于被預(yù)訂的網(wǎng)絡(luò)管理過程的改變后信息，所述中繼與所述設(shè)施更新所述信息自身內(nèi)部表達(dá)大約同時地由所述設(shè)施實行。
2.根據(jù)權(quán)利要求1的方法，其中，所述中繼由更新所述被更新信息的內(nèi)部表達(dá)的相同軟件例程完成。
3.根據(jù)權(quán)利要求1的方法，其中，當(dāng)預(yù)訂信息時，更新本地表的中間件過程也將所述新數(shù)據(jù)復(fù)制到套接字。
4.根據(jù)權(quán)利要求1的方法，其中，如果被訪問的所述網(wǎng)絡(luò)管理過程駐留在不同的網(wǎng)絡(luò)上，代理查詢和響應(yīng)的步驟包括(a)將第一唯一標(biāo)識符與每個被查詢部件的地址結(jié)合以形成結(jié)合的唯一標(biāo)識符，這個步驟在所述部件的本地域內(nèi)完成；以及(b)使所述結(jié)合的唯一標(biāo)識符對查詢系統(tǒng)可用。
5.根據(jù)權(quán)利要求1的方法，進一步包括按時間設(shè)置過濾器，以獲得歷史的和當(dāng)前的度 M.fn 息。
全文摘要
一種管理多個異構(gòu)網(wǎng)絡(luò)的系統(tǒng)中實時事件監(jiān)視的發(fā)布和預(yù)訂方法。提供了會聚的網(wǎng)絡(luò)管理應(yīng)用程序和系統(tǒng)，將管理平臺提供為服務(wù)，能夠以安全而高效的方式觀察和/或管理集合體中全部被管理的網(wǎng)絡(luò)，或者分別地觀察和/或管理它們中任何一個(包括被管理網(wǎng)絡(luò)內(nèi)的個別設(shè)備)，在被管理的網(wǎng)絡(luò)和系統(tǒng)上實時地提供了連續(xù)可用的信息，克服了若干整合問題，包括沖突地址模式、避免不必要基礎(chǔ)設(shè)施的需要以及在可用存儲器和帶寬約束內(nèi)實時采集一切必要信息的需要。
文檔編號G06F15/173GK102160049SQ200980136500
公開日2011年8月17日 申請日期2009年7月30日 優(yōu)先權(quán)日2008年7月31日
發(fā)明者E·貝德蘭, J·富奇洛, M·基弗 申請人:Juma技術(shù)公司