專利名稱：用于處理通信系統(tǒng)中的記錄的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及通信網，并且特別是涉及一種用于在通信網使用期間處理事件記錄的新方法。
背景在傳統(tǒng)的收入承載的通信網，如公共交換電話網(PSTN)中，網絡擁有者或“業(yè)務提供者”估算每個用戶或“業(yè)務用戶”的費用。用戶為訪問和使用該網絡而付費并且估算的費用可基于固定費用、連接的距離和持續(xù)時間、傳送的數據量、特殊業(yè)務的使用等。
為測量每個用戶的使用，網絡中的不同點要代表每個用戶保持通過網絡的連接或數據流記錄。例如，在電話網中，對通話進行路由的交換機保持處理的每個通話的記錄。因實際原因，這些記錄傳統(tǒng)地在每個交換機本地存儲并且周期性地采集以便進行計費處理。這些記錄還用于得出業(yè)務量統(tǒng)計和檢測欺詐使用模式。
因為給定的連接，例如長途電話，可能涉及幾個交換機，在處理該通話期間將生成幾個單獨的通話記錄。在計費處理期間，這些記錄必須從網絡中所有交換機采集的數百萬其它記錄中挑選出來。然后組合相關的記錄以便給出在特定通話期間使用了哪些網絡資源并且因此應向適當的用戶計多少費用的組合描述。
控制每個交換機的軟件設計為記錄在通話處理期間發(fā)生的選定事件并且將這些事件編碼為一種非常特殊的格式。對事件編碼的傳統(tǒng)方法稱為自動消息記帳(AMA)并且在可從泰克科迪亞科技(TelcordiaTechnologies)獲得的名為GR-1100-CORE的行業(yè)標準文檔中有描述。簡而言之，編碼格式是很好定義的靜態(tài)數據結構，在本行業(yè)也稱為通話詳細記錄(CDR)。單個通話記錄捆綁成塊，由交換機寫入磁帶或其它形式的持久存儲設備中。
從網絡采集一定時間積累的通話記錄之后，計費處理系統(tǒng)必須解碼并且解釋由交換機和其它網元編碼的計費記錄內容的意義。為保證準確的計費處理，CDR的語法和語義必須通常能由生成記錄的網元以及解釋記錄的處理系統(tǒng)理解。
計費處理器中的軟件設計為解析和處理假定特定結構和內容的通話記錄。CDR語法和語義的任何改變都需要計費代碼的改變。這個改變由新的可計費業(yè)務或特性的引入而成為必需。例如，將長途電話通話的費用記在借記卡上或第三方的新業(yè)務的引入需要在CDR中編碼新的信息。
在過去的電話網中，新業(yè)務的引入相對不頻繁。減少進入市場的時間對業(yè)務提供者來說不是高優(yōu)先級的。但是，最近，業(yè)務提供者之間的競爭以及由用戶需求驅動的新功能的可用性加速了新特性的引入。
修改計費系統(tǒng)代碼的負擔阻礙了通信網中新特性的引入。傳統(tǒng)的固定長度的CDR相對不靈活并且是不必要的限制。自從第一次引入CDR以來，通信帶寬和處理速度已經成倍地改善，消除了保持CDR緊湊的需要?，F在可以認識到背離傳統(tǒng)CDR格式的許多優(yōu)點。
因此，需要一種改善的方法來采集、傳送和處理在通信網中記錄的事件信息而無論何時新的計費特性加入該網絡時都不需要大量的重寫和測試計費系統(tǒng)軟件。這個要求一般適用于由提供無論任何原因，不管是計費、欺詐檢測、業(yè)務分析等都需要處理的通信業(yè)務產生的任何記錄。
目前技術正在實現由單一通信網為用戶提供各種業(yè)務類型、帶寬、傳輸技術和特殊業(yè)務。因此，需要通用并且易于擴展的后處理系統(tǒng)與通信系統(tǒng)一起協同運行。
順便還需要更通用的術語來表現這樣的通信和后處理系統(tǒng)的特點。雖然“通話”和“通話處理”的概念和術語已經在傳統(tǒng)電話網應用很久了，更廣泛的術語“會話”和“業(yè)務處理”更適合于包含更現代的網絡的所有用途。僅舉幾個例子，這里使用的“會話”指使用網絡的一個實例并且包括單一數據分組的遞交、臨時雙向語音信道的建立、或大量多媒體文件的傳送。術語“業(yè)務處理”一般指網絡為實現網絡用戶的需要作出的決定以及執(zhí)行的操作。
根據本發(fā)明的一個優(yōu)選實施方案，處理記錄包括用于解釋記錄中描述的已記錄數據的可執(zhí)行代碼形式的指令。
根據另一個方面，本發(fā)明針對一種方法，憑此業(yè)務處理記錄被創(chuàng)建、累積、按合適的函數打包，然后基于一個任意的捆綁和調度策略來轉發(fā)到計費處理系統(tǒng)。
根據本發(fā)明的一個優(yōu)選實施方案，業(yè)務處理記錄符合一個規(guī)定的可執(zhí)行格式，例如可執(zhí)行JAVA。(JAVA是Sun微系統(tǒng)的注冊商標。)業(yè)務處理記錄可以由通信網中的任何網元或業(yè)務處理函數開始。業(yè)務處理記錄與連接、會話或涉及網絡的其它事務相關。除了估算要計費給用戶的費用，業(yè)務處理記錄還被處理以識別欺詐模式、分析消費者趨勢、以及促進網絡容量工程。每個業(yè)務處理記錄包括業(yè)務處理事件數據并且，根據本發(fā)明，還包括指令，如方法或可調用函數，用于解釋和處理業(yè)務處理事件數據。
根據本發(fā)明的業(yè)務處理記錄作為可執(zhí)行代碼打包，其中方法編碼為可調用函數并且事件編碼為對使用與事件的特定實例相關的參數的那些函數的調用。
這種類型的業(yè)務處理記錄可由通用處理系統(tǒng)處理，從記錄中提取函數內容并且然后使用方法來解釋和處理記錄中的數據。無論何時新的業(yè)務或可計費特性加入網絡中，新的或修改的業(yè)務處理函數就調度到整個網絡的網元，如交換機和路由器中。當業(yè)務處理函數隨新功能升級時，業(yè)務處理函數中生成業(yè)務處理記錄的某些部分可以設計為將計費和其它后處理方法包括在隨后生成并且發(fā)送的業(yè)務處理記錄中。因此，計費函數就與業(yè)務處理函數一起生成并且分配。換句話說，這個方法使得計費函數的創(chuàng)建和調度與業(yè)務處理函數成為一個整體。
和使用專用硬件和軟件的現有技術記錄處理系統(tǒng)相比，根據本發(fā)明生成的事件記錄可由通用后處理系統(tǒng)從業(yè)務處理事件記錄中提取指令并且然后使用這些指令處理記錄事件來處理。對計費函數的改變與業(yè)務函數在同一時間創(chuàng)建并且分配。因此，計費函數不需要與業(yè)務函數分開維護和測試。這導致新業(yè)務在通信網中更快的實施。
如前所述，傳送給記錄處理器的業(yè)務處理記錄包括影響在記錄處理器中事件數據如何解釋和處理的指令。雖然現有技術通話詳細記錄包括在彼此的前后關系中解釋的多個數據域，多個數據域在彼此前后關系中處理的方法是完全固定在記錄處理器的軟件和硬件內的。因此，現有技術CDR中數據域的語義由約定建立。相反，本發(fā)明允許數據域基于記錄中的其它內容來動態(tài)地重新打算并且由記錄處理器之外的邏輯操作來決定。實際上，本發(fā)明甚至使得記錄處理器能夠僅由業(yè)務處理記錄的指令內容來重新打算。給定的通用記錄處理器除了在業(yè)務處理記錄本身里傳送的指令之外實際上沒有內在能力來處理業(yè)務處理記錄里的事件。
發(fā)明詳述本發(fā)明針對用于處理通信網生成的事件記錄的系統(tǒng)和方法。根據本發(fā)明的一個優(yōu)選實施方案，事件記錄由通用記錄處理器處理并且用于執(zhí)行這樣處理的方法在事件記錄本身內部傳送。
下面的描述詳細說明了記錄處理方法的調度和執(zhí)行如何以這種方式出現。
參見附

圖1，通信網100顯示為包括由有時稱為“中繼”的通信鏈路組120和122互聯的交換機112、114和116。這個交換機和鏈路的集合組成一個業(yè)務承載網110。在圖1的例子中，業(yè)務承載網110用于在不同用戶位置102a-102i之間傳送信息。
網絡110中交換機112、114和116的行動需要協調以便對數據進行路由或者連接用戶。因此，交換控制器/通話處理器132被耦合以便控制交換機112。然而交換機112直接處理用戶業(yè)務，交換控制器/通話處理器132命令交換機112在特定端口之間進行連接。在某些實際實現中，交換控制器/通話處理器132的某些或所有功能塊都與交換機112集成或配置在一起。
同樣，圖1中交換機114和116分別由交換控制器/通話處理器134和136控制。
圖1中每個交換控制器/通話處理器都連接到分組交換信令網150中，后者進而又耦合到至少一個業(yè)務控制點160。
通過信令網150，交換控制器132、134和136利用例如公共信道7號信令網(SS7)彼此之間進行通信。而且，交換控制器132、134和136可訪問業(yè)務控制點160以確定如何發(fā)送給定的業(yè)務請求。在典型的電話網中，SCP160通常包括用于執(zhí)行號碼翻譯，如將1-800號碼電話通話映射為實際目的地號碼的數據庫。業(yè)務控制點160維護影響業(yè)務承載網110如何實現用戶請求的數據。
如圖1所示，業(yè)務管理系統(tǒng)(SMS)170耦合用于將業(yè)務控制數據下載到SCP160。在如圖1所示的典型的智能網中，決定交換機和通話處理器行為的軟件指令“內置”或手工加載到設備中。通過SMS170或SCP160沒有機制用于向這些元件分配實際的操作軟件。代替的，通過改變SCP160處的數據表的內容來實施對網絡100的運行的有限控制。該軟件控制交換機控制器/通話處理器132的一個方面創(chuàng)建通話處理臨時發(fā)生的記錄。這些記錄包含關于用戶使用實例的信息并且一般用于計算通常在一個給定的時間期間每個用戶需要為其使用網絡付費的量。這些記錄累積到通話詳細記錄文件142中。
同樣地，交換機控制器/通話處理器134和136分別累積通話詳細記錄文件144和146。
因為生成通話詳細記錄的單元通常相對遠的分離，單獨的通話詳細記錄文件在每個站點累積并且然后周期性地采集以便處理。
圖2描述采集和處理CDR文件的現有技術。在圖2中，在網100內的通話處理期間已經累積的CDR文件142、144和146合并并且提交給各種處理函數。計費處理函數210處理CDR文件以便為使用網絡的每個用戶計費。聚集的CDR文件首先由文件解析階段212解析生成單獨的計費記錄213。結果的解析計費記錄輸入到記錄關聯/解析函數214，其使CDR相互關聯并且組成該網絡處理的每個通話的描述。這個函數對于協調來自與給定通話相關的多個位置的CDR特別重要。記錄關聯/解析函數214還鑒別CDR之間的差異。隨著從CDR裝配出每個通話的一致描述，記錄數據實例215就輸出到計費分析函數216中。計費分析函數216檢查每個通話的可計費特征，將合適的計費費率應用于記錄的使用上，并且將費用加到每個用戶的帳單上。計費分析函數216的輸出是每個用戶的帳單218。
欺詐分析函數220為了檢測欺詐模式，而不是計費，類似地處理CDR文件。生成計費記錄223的文件解析階段222以及生成記錄數據實例225的記錄關聯/解析224與計費處理器函數210內的函數是類似的。欺詐分析階段226檢查各個通話的進展，以及檢查指示不尋常行為的多個通話之間的相似性。生成欺詐結果的報告228以便突出來自欺詐分析226的處理的任何重要的欺詐相關的調查結果。
業(yè)務分析函數230為了優(yōu)化網絡的運行或設計類似地處理CDR文件。生成計費記錄223的文件解析階段222以及生成記錄數據實例235的記錄關聯/解析234與計費處理器函數210內的函數是類似的。業(yè)務分析階段236檢查使用模型，如網絡的給定部分的通話的數量和持續(xù)時間，可能對指導網絡中的資源利用或規(guī)劃網絡的增長有用。生成業(yè)務分析結果報告238以便概括業(yè)務分析236的調查結果。
計費處理器210、欺詐分析處理器220，以及業(yè)務分析處理器230典型地以軟件實現以便運行在計算機上并且典型地彼此單獨維護，甚至可能用不同的編程語言或在不同的計算平臺上。處理的CDR的語法或語義的任何改變都需要所有三個軟件實現的改變和重新測試。
圖3顯示根據現有技術的典型的通話詳細記錄文件300的結構，與上述CDR文件142、144和146類似。CDR文件300基本上是一系列相關聯的許多固定長度CDR，在圖3中由記錄304a-304d描述。CDR文件300還包括頭302以便提供關于文件的一般信息，如文件中的記錄數或生成記錄的網元的標識。還可以包括一個尾部306以便于某些類型的數據處理或存儲。尾部306可，例如，包括來自CDR的對于檢查數據文件的完整性有用的校驗和。通話詳細記錄文件300中的記錄304a-304d僅包含表示如電話號碼和特征組的值的數據。現有技術通話詳細記錄文件300不包含處理邏輯或指令的表示。
圖4描述了在通信系統(tǒng)400中實現的本發(fā)明的一個示例實施方案。特別地，圖4顯示在提供通信業(yè)務期間記錄是如何生成和發(fā)送的。
通信系統(tǒng)400包括一個業(yè)務承載網絡402和一個網絡控制/業(yè)務處理功能410。
業(yè)務承載網402可以是電話網、分組交換數據網、幀中繼、異步傳輸模式(ATM)、或任何其它形式的信息傳輸和路由網。業(yè)務承載網402甚至可以是不同傳輸類型的組合并且可進一步包含如語音響應單元或傳真存儲轉發(fā)設備的特殊資源。
網絡控制/業(yè)務處理函數410協調業(yè)務承載網402中設備的操作。例如，在通信系統(tǒng)400是電話網的情況下，網絡控制/業(yè)務處理函數410處理在傳統(tǒng)電話網中典型地由智能網(IN)通話處理器執(zhí)行的通話處理，如通話路由選擇。網絡控制/業(yè)務處理函數410不管業(yè)務承載網402中使用的傳輸技術，都包括向用戶提供業(yè)務需要的所有處理。
在網絡控制/業(yè)務處理函數410內，會話處理函數412表示確定如何控制業(yè)務承載網402以便響應用戶請求提供業(yè)務的處理。會話處理函數412類似于電話網中的電話處理。但是，會話處理函數412還包括對傳統(tǒng)電話網之外的數據傳輸、多方通信、廣播、組播、按需帶寬、存儲轉發(fā)、網關協調以及其它特性。
會話處理函數412在協調業(yè)務期間生成事件413。會話處理函數412以軟件實現并且在計算機上運行。實現會話處理函數412的部分指令決定何時對應于應該記錄的重要的、可能可計費的行為的處理步驟出現。
例如，電話用戶可訪問查號并且然后為少的費用自動請求該通話結束。因為會話處理函數412引起業(yè)務承載網402來滿足這個請求，該行為作為事件記錄因此計費處理會將該費用附加在用戶的帳單上。
不是所有事件都有計費意義。有些事件簡單地記錄什么發(fā)生并且被證明對發(fā)現和消除網絡中的問題，或者對觀察使用模式有用。實現業(yè)務處理函數的軟件指令決定哪些行為會生成事件。因此，業(yè)務處理軟件的設計者控制哪些事件適合被報告。
如圖4所示，在業(yè)務處理期間生成的事件413由事件捆綁器414累積。事件捆綁器414決定如何將事件分組在一起，哪些事件可以過濾掉，以及何時累積了足夠數量的事件以便以事件集合415的形式傳遞到下一個處理階段。事件捆綁策略422是決定事件捆綁器414行為的存儲的規(guī)則集合或數據。
為調整事件捆綁器414的行為或性能，網絡工程師在事件捆綁策略422內任意建立規(guī)則。結果，例如，事件捆綁器414使用會話的結束作為將與該會話相關的所有事件捆綁在一起的觸發(fā)器。否則，事件捆綁器414按使用的資源、按事件類型或按事件中涉及的網絡事件的標識將事件分組。如事件捆綁策略422控制的，事件捆綁器414還規(guī)定表示部分或多個會話的事件組。
如圖4所示，由事件捆綁器414創(chuàng)建的事件集合415隨后由小代碼編制器416處理以生成小代碼417。每個小代碼417包括與表示對解釋事件數據有用的處理步驟的代碼一起的記錄事件數據。小代碼編制器416檢查一個或多個接收的事件集合415并且增加可執(zhí)行代碼段和附加數據。特別地，小代碼編制器416依據事件集合415中存在什么事件類型來有條件地增加選擇的數據和指令(可執(zhí)行代碼)。要增加到小代碼中的指令源自包含代碼段的庫420或者由小代碼編制器416動態(tài)地構建。小代碼編制器416將來自多個事件集合415的數據組合到單一小代碼417。
小代碼編制器416的行為由網絡工程師任意建立的存儲的小代碼建立原則424確定。小代碼建立策略424可以是包含例如導致小代碼編制器416將多個事件集合組合成單一小代碼417的規(guī)則和數據的數據文件。小代碼建立策略424還例如決定將來自庫420的代碼段包含在小代碼417中，或僅僅是參考。小代碼編制器416會考慮已知的通用庫函數在將最終接收打包數據的記錄處理器之間的可用性。小代碼編制器416決定記錄處理器以前從沒用過的新的或者更新的函數已經可用。因此，小代碼處理策略函數可確保小代碼中包含新函數，因此記錄處理器可使用新函數并且可能為以后使用而存儲該函數。而且，通過小代碼建立策略424，網絡工程師可明確地指定新的或更新的函數來上載到記錄處理器的本地庫中。對每個方法或方法組的這一指定在圖5中描述為上載指示器532。
在本發(fā)明的優(yōu)選實施方案中，小代碼編制器416賦予每個小代碼417足夠的數據和方法，因此通用處理器可以解釋包含在其中的數據并且給出有用的輸出，例如為用戶計費。因此，對如何進行計費以及其它間接處理的控制在軟件指令以及網絡控制/業(yè)務處理器函數410內的函數庫內實現。這意味著計費以及其它間接處理函數可伴隨業(yè)務處理特性開發(fā)、測試和調度。
在本發(fā)明的優(yōu)選實施方案中，小代碼417以如JAVA字節(jié)代碼的通用可執(zhí)行代碼的形式創(chuàng)建，以便各種網絡控制/業(yè)務處理器410以及記錄處理器408a-b可以在不同的計算平臺上實現并且在創(chuàng)建和處理事件記錄方面完全兼容。不管對JAVA字節(jié)代碼的示例參考，相關領域的技術人員認可可采用許多其它種類的通用可執(zhí)行代碼，如小應用程序(applet)、servlet、JAVA BEANS、以及串行對象。
在圖4中，記錄處理器408a和408b代表可解釋和執(zhí)行在通信系統(tǒng)400內的業(yè)務處理期間生成的指令和數據的通用目的處理器。
調度程序418接收每個小代碼417并且生成發(fā)送到記錄處理器408a、408b的所謂的“可解釋”文件419。如調度策略426中存儲的指令所指導的，調度程序418決定何時以及向哪里發(fā)送每個結果可解釋文件419。通過調整調度策略426中的設置，網絡工程師可使調度程序418將可解釋代碼發(fā)送到選擇的或優(yōu)選的記錄處理器408a、408b中的一個。調度程序418還通過感知記錄處理器408a和408b之間的瞬時處理負載來執(zhí)行負載均衡并且決定因此向哪里發(fā)送每個可解釋文件419。調度程序418“調節(jié)”可解釋文件419到多個記錄處理器。調度程序418選擇將可解釋文件419發(fā)送到存儲區(qū)域440而不是直接到任何記錄處理器。調度程序418基于對庫函數的了解或區(qū)分每個記錄處理器408a、408b的特殊功能來決定向哪里發(fā)送每個可解釋文件419。
調度程序418的上述任何行為都由調度策略426的內容控制或改變。調度程序418還決定可解釋文件419的最終形式。
根據本發(fā)明的一個優(yōu)選實施方案，通信系統(tǒng)400還包括網絡管理系統(tǒng)(NMS)404和業(yè)務開發(fā)環(huán)境(SDE)406。
部分地，網絡管理系統(tǒng)404擔任傳統(tǒng)的監(jiān)視業(yè)務承載網402的功能狀態(tài)，以及聲稱對其控制的角色。根據本發(fā)明的一個優(yōu)選實施方案，NMS404還是一種用于向通信系統(tǒng)400中的一個或多個網絡控制/業(yè)務處理函數410分配操作指令或軟件的裝置。在1998年8月5日提交的共同轉讓、共同未決的美國專利申請第09/128,937號并且名為“用于智能分布式網絡結構的智能呼叫平臺(Intelligent Call Platformfor an Intelligent Distributed Network Architecture)”中描述有用于向業(yè)務處理器分配操作軟件和數據的這樣一種裝置，該專利申請的整個內容和公開內容合并在這里供參考，就象在這里提出一樣。
業(yè)務處理和其它函數，包括計費處理以及其它這樣的間接處理函數，在業(yè)務開發(fā)環(huán)境(SDE)406中創(chuàng)建。一旦滿意的開發(fā)和測試，在SDE406中開發(fā)的函數就對NMS404可用以便分配到網絡中。通過前面描述的機制，計費以及其它間接處理函數通過SDE406和NMS404類似地開發(fā)和傳播。
本發(fā)明的一個顯著優(yōu)點是可以在無須記錄處理器軟件任何改變的情況下以這種形式提供許多類型的改變。因為記錄處理器的函數多半源自接收的可解釋包，所以大多數通常的改變，如新的可計費特性的增加，在不改變記錄處理器代碼的情況下已經完成。在優(yōu)選實施方案中，記錄處理器支持JAVA等并且可解釋代碼是象這樣打包的。
只有可執(zhí)行程序的基本形式方面的改變，如在可解釋對象中定位方法和數據的方式，會必然地影響記錄處理器的操作。業(yè)務處理特性、事件處理策略、小代碼處理策略以及調度策略的改變一般對記錄處理器代碼沒有影響，除了這些改變需要可解釋文件格式的基本改變的未必可能的事件。
圖5描述了根據本發(fā)明的一個優(yōu)選實施方案調度到記錄處理器的一個可解釋文件的典型內容。在圖5中，可解釋文件500顯示為包括幾段。文件數據頭510包括關于可解釋文件500的一般信息，如文件類型標識符串512，文件長度514，以及包含段的相對位置或文件內的進入點的進入點表516。
可解釋文件500中的方法段530包括可由記錄處理器直接執(zhí)行的函數。在本發(fā)明的優(yōu)選實施方案中，方法段530包括已編譯的JAVA可執(zhí)行代碼段。但是，圖5中為清楚起見，方法段530以與源代碼類似的形式出現。某些方法或方法組附有上載指示器532，用于指定應該上載并且保留在最終接收可解釋文件500的每個記錄處理器的庫中的那些方法。
可解釋文件500中的記錄數據段550包括表示通信網中業(yè)務處理期間發(fā)生的實際事件的方法調用。記錄數據段550中調用的某些方法是在可解釋文件500的段530中包含的那些，而其它方法可從可解釋文件外部的庫中獲得。每個方法調用使用適合于特殊事件或行為的特殊實例的參數。下面將詳細進行描述，當記錄處理器加載并且執(zhí)行可解釋代碼時，順序方法調用使得記錄處理器能夠重新構造網絡中業(yè)務處理期間發(fā)生的事件并且基于重新構造的事件執(zhí)行有用的處理。
例如，可解釋文件500的方法段530包括稱為“Add_Party(加入會話方)”的方法。這個方法接受許多新的一方加入到已有的通信會話中，以及該方請求加入的日期和時間。新的一方加入到通信會話中將要求對用戶計算額外的費用?！癆dd_Party”方法包括用于確定增加到用戶帳單的合適的費用的代碼。
如前面與小代碼建立策略424一起描述的，在給定可解釋代碼中給定方法的包括依賴于函數的需要。如果可解釋文件包括許多會話的事件但是沒有一個會話涉及Add-Party函數，則可解釋文件不需要包括Add-Party函數。同樣，如果加入會話方函數很常見，可能是標準庫函數，則可解釋文件不需要包括該函數，而是引用該函數或記錄處理器需要的庫。
記錄數據段550包括在代碼中處理從哪里開始的一個準確的進入點，如圖5中main()語句所表示的。所有的執(zhí)行環(huán)境(例如，操作系統(tǒng)，以及解釋程序)規(guī)定如何識別其特定可執(zhí)行格式的開始點(例如，在C/C++和JAVA中的“main”程序)。記錄數據段550的開始是通用處理器加載可執(zhí)行文件500并且然后開始處理內容之后的執(zhí)行開始點。如后面詳細描述的，通用記錄處理器對可解釋文件的最終處理需要對象的說明、在這些對象上的方法調用、以及對象間的相互作用，這對于面向對象編程的領域的技術人員是熟知的。
簡而言之，隨著網絡用戶參加使用通信網的會話，與該會話相關的事件被記錄并且組裝到可解釋文件500中的整體描述中。事件表示為可解釋文件500的記錄數據段550中的方法調用。在可解釋文件500處理期間要調用的方法可通過可解釋文件500自包含在并且分配到記錄處理器中。在本說明書的附錄A中作為參考顯示了根據可解釋文件500的上述描述的JAVA代碼的例子。
圖6說明了根據本發(fā)明的一個優(yōu)選實施方案裝備以便接收并且處理可解釋文件的記錄處理器600。
在圖6中，可解釋文件419由記錄處理器408a接收并且以與程序在計算機中加載和執(zhí)行或者小應用程序由主計算機應用程序，如互聯網瀏覽器加載和執(zhí)行類似的方式加載并且執(zhí)行。更特別地，可解釋文件419的內容被解析并且由加載程序/解釋程序610讀進記錄處理器408a的存儲空間630。因在解析期間找到可解釋文件419中的代碼段，這些段被作為臨時代碼640拷貝到記錄處理器的存儲空間并且加載程序/解釋程序610生成一個臨時表，在內存中將函數的名字映射到其地址。因為在可解釋文件419中遇到對庫函數的引用，所以加載程序/解釋程序610將從本地庫630中選擇的函數拷貝到存儲空間630以便在處理期間很容易對其訪問。這相當于本地庫的運行時綁定。
當解釋程序610遇到可解釋文件419中的主進入點時，實際記錄網絡事件的處理開始。例如，存儲器中的處理上下文有效地重新構建與給定通信會話相關的事件和環(huán)境。在存儲器中的會話重構650內，因表示事件的每個函數調用在可解釋文件419中遇到，所以創(chuàng)建對象實例652、654、656和658并且緊接著調用方法來完成由可解釋文件419中的代碼計劃的處理。
各種對象實例652、654、656和658，例如，表示給定會話中涉及的用戶、用戶設備、交換機、路徑、通話支路、業(yè)務或資源。計算機科學和面向對象的編程領域的技術人員熟悉處理可以這種形式發(fā)生的各種方式。
記錄處理器408a可訪問一個外部或集中的數據庫660來檢索如給定用戶的當前帳戶信息的共享數據。記錄處理器408a為給定用戶處理事務并且然后將更新的信息返回數據庫660。例如，記錄處理器408a獲得用戶的帳戶并且然后將費用添加到該用戶的帳戶信息中。因此，即使不同會話的使用由不同的記錄處理器處理，費用也會正確地累加到該用戶的帳戶。
將編碼的功能放在可解釋文件419的一個顯著優(yōu)點是具有包括如哈希表和二進制樹的有用數據結構以及如循環(huán)、遞歸、條件分支等的編程結構的靈活性。相反，現有技術的通話詳細記錄僅包含數值。
現在參見圖7，顯示的流程圖用于描述事件捆綁器414在處理來自會話處理器412的事件413時執(zhí)行的處理步驟。一接收到來自會話處理器702的事件413，處理就從步驟702處開始。因此圖7中描述的處理對每個這樣的接收事件413重復。優(yōu)選地，事件捆綁器414為會話處理器412參與的每個單獨的通信會話維護一個持久的事件累積。每個這樣的累積稱為“會話事件集合”并且優(yōu)選地持續(xù)直到相關會話完成并且由會話處理器412決定中斷。這對技術人員很容易理解，會話處理器412為每個事件413提供某種類型的指示器來識別通信會話的相關實例。事件捆綁器414使用這個指示器來正確地關聯與業(yè)務處理器412中特定通信會話相關的進入事件413。
從步驟704繼續(xù)，決定事件是與一個進行中的會話有關，還是一個事件捆綁器414還沒有創(chuàng)建會話事件集合的新會話。
如果進入事件表示一個新會話，則在步驟706，建立新的會話事件集合。否則，處理直接從步驟704移到步驟708。
在步驟708，決定進入事件是否表示會話的結束。一旦會話結束，會話處理器412就生成并且發(fā)送一個由事件捆綁器414識別的末端類型事件。為概括處理的剩余部分，如果進入事件不表示會話結束，則該事件簡單地添加到與會話相關的進行中事件集合中。否則，事件捆綁器414將決定如何將結束的事件集合與其它事件集合組合在一起并且決定是否將累積的事件集合發(fā)送到小代碼編制器416。
在步驟708，如果決定事件不表示會話結束，則處理從決定步驟710繼續(xù)。在步驟710，事件捆綁器414根據事件捆綁策略424中的設置執(zhí)行什么事件類型添加到會話事件集合中的控制。如前面提到的，網絡工程師使用這種方法來限制集合中事件的類型。例如，某些事件消息僅對診斷目的有用并且在后處理期間用不到。通過改變事件捆綁策略422的內容，網絡工程師可動態(tài)地導致診斷事件通知包含在或不包含在事件集合中。在通常情況下，采用這個過濾來避免最終將會發(fā)送到后處理的集合中無關的內容。
如果在步驟710，進入事件沒有被事件捆綁策略422中實現的當前指令過濾，則在步驟712該事件添加到合適的會話事件集合。否則，跳過步驟712并且單一進入事件的處理如末端步驟714表示的結束。
回來參考步驟708，如果進入事件確實表示相關會話的結束，則處理從步驟716重新開始，其中會話事件集合對進一步輸入關閉并且關于該集合的任何需要的概要數據被編譯并且加入到該集合中。概要數據可包括，例如，集合中事件的數量、使用的任何特殊資源的列表，或會話處理器或事件捆綁器函數的軟件版本。
然后繼續(xù)到步驟718，事件捆綁器414，由事件捆綁策略422中的內容指導，基于事件集合的某個通用屬性決定事件集合是否要分組到聚合的集合。例如，網絡工程師通過將與業(yè)務承載網402中的特定資源的使用相關的集合組合在一起來決定優(yōu)化性能。
如果在步驟718，沒有使用用于組合集合的標準，則在步驟720，最近結束的事件集合被簡單地添加到累積的或聚集的集合。隨著單一集合的增加，在步驟722檢查累積集合的屬性以便決定累積的集合是否準備好發(fā)送到小代碼編制器416。做出這個決定的事件捆綁器414的標準由事件捆綁策略424內的內容決定。例如，無論何時聚集的集合增長到某個整體大小或當從來自事件捆綁器的前一個聚集集合的發(fā)送以來已經過去了一個時間限制，則事件捆綁器414發(fā)送一個聚集集合。完成后者以便當網絡相對空閑時減少處理少量會話的延遲。
然后在步驟722，如果符合發(fā)送累積集合的標準，則該事件集合就發(fā)送到小代碼編制器416并且優(yōu)選地從實現事件捆綁器414的處理器的有效存儲器中去除。否則，在步驟722，如果不滿足發(fā)送標準，則累積的集合僅暫時保持在存儲器中并且單一事件的處理如末端步驟714所指示的結束。
附圖的圖8描述了小代碼編制器416執(zhí)行的處理，由此每個事件集合415從事件捆綁器414中接收并且處理以便生成小代碼417。
圖8的處理一接收到單一事件集合415就從步驟802開始。然后直接進行到步驟804，小代碼編制器416決定被組裝的小代碼是否已經存在或者新的事件集合的接收是否應該啟動一個新的小代碼。如果在步驟804決定需要，則在步驟808重新開始執(zhí)行之前在步驟806創(chuàng)建小代碼。在步驟806創(chuàng)建的小代碼將作為一個或多個事件集合的容器。
注意步驟804和806主要在單一小代碼中包括多個事件集合時有用。
在步驟808，小代碼編制器416決定是否容許在單一小代碼中放置多個事件集合。這受到小代碼建立策略424的內容的影響。例如，網絡工程師為了效率決定允許事件集合綁定到小代碼中。如果允許這樣的綁定，則執(zhí)行步驟812以便將接收的事件集合加入到當前小代碼中。
在加入事件集合之后，小代碼編制器416在步驟814估算該小代碼是否滿足結束并且發(fā)送該小代碼的條件。小代碼發(fā)送條件是小代碼建立策略424內的設置。例如，網絡工程師將無論何時小代碼超過某個大小或事件集合的數量就導致小代碼編制器發(fā)送小代碼的內容放在小代碼建立策略424中。
發(fā)送條件還考慮在小代碼內的事件集合中用到的資源類型。
如果，在將事件集合加入到小代碼之后，在步驟814小代碼還不滿足發(fā)送條件，則處理在步驟830終止并且事件集合和小代碼都不再進一步處理直到接收到隨后的事件集合。
替代地，如果在步驟814小代碼被認為滿足發(fā)送條件，則可能包括多個事件集合的小代碼在步驟816開始進一步被處理。
回來參見步驟808，如果不允許多個事件集合構成小代碼，則執(zhí)行進行到步驟810，其中在步驟802接收的單一事件集合被簡單地放入在步驟806創(chuàng)建的小代碼中。此后在步驟816開始進一步處理新的小代碼。
圖8中的剩余處理步驟按需要用后面后處理器需要的功能塊擴大小代碼。這些功能塊與前面與圖5一起描述的方法530對應。
在步驟816，基于小代碼中包括的事件類型構造了表示運行時需要的所有處理方法和任何其它功能塊的相關性列表。例如，如果即使小代碼中的一個事件集合包括涉及對通話方的費用撤銷的事件，則為了后處理器正確地處理該事件以及處理包含該事件的任何會話，在運行時，某些函數必須可用。
某些經常用到或非?；镜暮瘮等鐖D6中的庫620所示永久地駐留在后處理器中。通過對哪些函數一般對后處理器可用的某些了解，小代碼編制器可避免在小代碼中復制這些運行時函數。因此，步驟818涉及決定是否能用引用代替實際運行時函數以便減少小代碼的大小。在步驟818，由小代碼建立策略424指示小代碼編制器416是否允許引用來代替實際的運行時函數。網絡工程師可調整小代碼建立策略424的內容來導致小代碼編制器為最小化小代碼大小來使用對運行時函數的引用。否則，網絡工程師想要某些或所有需要的函數顯式地包括在每個小代碼中，以便確保最終接收該小代碼的所有后處理器使所有需要的功能完整。如果目標后處理器的功能在小代碼建立時還不確定時，這樣做很有必要。
如果處理步驟818發(fā)現允許小代碼中的引用，則在步驟820對可由引用表示的每個函數的合適的引用就放置在小代碼的方法段中。這樣的引用例如，可規(guī)定庫名和函數調用名。
除此之外，對于在步驟820由引用代替的每個函數，更新運行時相關性列表，刪除現在已經通過引用充分包含在小代碼中的函數。
無論函數是否由引用代替，在步驟822小代碼的處理都繼續(xù)，其中為任何剩余的相關性檢查在步驟816得到的相關性列表。如果還有必需尋址的運行時相關性，則執(zhí)行步驟824來向小代碼的方法段增加需要的函數。
這些函數可，例如，從圖4所示的本地函數庫420獲得。由步驟824包括在小代碼中的所有函數從步驟816得到的相關性列表中去掉。
然后，在步驟826，再次檢查相關性列表來看是否還需要沒有顯式地或通過引用包含的任何函數。如果還有函數需要包括，則在步驟828，查閱小代碼建立策略以便找到可用的指令來在小代碼編制器416中動態(tài)建立所需的功能。然后從相關性列表中去掉動態(tài)構建并且包括在小代碼中的任何函數并且處理在步驟830重新開始。
在步驟830，進行相關性的最終評估。如果有任何剩余的未解決的相關性，則小代碼編制器在步驟832聲明一個錯誤情況并且取消小代碼以便網絡工程師查找錯誤的故障原因。因此接收事件集合的處理在步驟840終止。
否則，如果步驟830，所有運行時函數相關性都解決了，則在步驟834完整的小代碼傳遞到調度程序418并且接收事件集合的處理在步驟840結束。
圖9描述了在接收來自小代碼編制器416的小代碼415并且將完整的可執(zhí)行代碼或“可解釋”文件419發(fā)送到記錄處理器408或臨時數據存儲庫時由調度程序418執(zhí)行的處理步驟。
一接收到小代碼，圖9的處理就從步驟902開始并且立即繼續(xù)到步驟904。
在步驟904，通過編譯和鏈接(如果需要)累積在小代碼中的代碼并且通過將頭信息加到對應于圖5中頭段510的可執(zhí)行文件，小代碼被轉換成自包含可解釋代碼。在一個變化方案中，接收的小代碼包括類似人們可讀的源代碼形式的函數。這個源代碼需要編譯成某種形式的直接可執(zhí)行機器指令并且函數引用需要通過鏈接解決，計算機編程的技術人員通常都理解這一點。在另一個變化方案中，小代碼包括作為僅需要包含和鏈接在可解釋文件中的預編譯段的函數。在第三個變化方案中，函數以類似源代碼的形式在可解釋文件中傳遞以便由記錄處理器后處理程序在運行時解釋。
在優(yōu)選實施方案中，可解釋文件包括已編譯JAVA字節(jié)代碼形式的函數并且記錄處理器能夠直接執(zhí)行這樣的可解釋文件。
在步驟904，還生成了一個壓縮或加密版本的可解釋文件以便改善可解釋文件傳輸和存儲時的效率和安全性。
接著，在步驟906，查閱調度策略426以便決定可解釋文件的目的地是否固定。在某些情況下，網絡工程師希望強制所有的可解釋文件發(fā)送到一個特定的記錄處理器。
如果是這種情況，則在步驟908，試圖將可解釋文件發(fā)送到指定的記錄處理器或存儲庫。如果這個發(fā)送努力失敗則聲明一個錯誤。然后因為不允許替代的目的地或存儲庫所以處理在步驟910終止。
返回步驟906，如果在調度策略426中可解釋文件的目的地不固定，則執(zhí)行進行到步驟912。在步驟912，生成兩個列表。一個是當前對調度程序可用的所有目的地列表，如記錄處理器和存儲庫。另一個是小代碼的外部相關性列表。例如，小代碼編制器假設某些庫在運行時可得到并且如圖8的步驟818-820所指示的選擇僅引用函數。外部相關性可以是小代碼編制器假設將在后處理運行時環(huán)境中存在的數據或函數。
如果不是所有的記錄處理器都有假設的運行時函數，則步驟912、914和915確保可解釋文件僅調度到在本地庫中確實有需要的運行時函數的記錄處理器中，如圖6所示的庫620。
在步驟912生成列表之后，執(zhí)行步驟914以便確定是否允許基于每個目的地功能的路由。這個決定由調度策略426的內容確定。每個目的地的功能包括，例如，可用的運行時庫、處理或存儲功能、或目的地的特定資源的可用性。網絡工程師可能想要禁止功能的路由以便執(zhí)行故障檢查或協調新的函數庫的調度，這將在后面與圖10的步驟1008一起描述。
如果允許基于功能的路由，則執(zhí)行步驟915由此沒有處理可解釋文件需要的功能的目的地從步驟912得到的候選目的地列表中刪除。
接著，在步驟916，查閱調度策略以便確定到目的地的可執(zhí)行文件的路由是否可考慮候選目的地之間的優(yōu)先選擇順序。如果是，則執(zhí)行步驟917以便基于調度策略426中包含的優(yōu)先選擇對候選列表排序。網絡工程師可利用這個功能使得特定業(yè)務處理器優(yōu)選地“歸位”到特定的記錄處理器。這個優(yōu)先選擇可基于，例如靜態(tài)負載均衡或業(yè)務處理器和記錄處理器之間的接近性。
在步驟918，查閱調度策略以便確定是否允許動態(tài)負載均衡。如果允許，則執(zhí)行步驟919以便進一步根據當前處理負載對候選目的地列表排序。每個目的地記錄處理器的當前處理負載可通過例如網絡管理系統(tǒng)轉播到調度程序。雖然沒有明確地顯示，但是通信網領域的普通技術人員很容易理解實現這個的方法。
一到達步驟920，則從步驟912得到的目的地的候選列表就根據調度策略426的指示完成過濾和排序。步驟920簡單地涉及選擇目的地列表的最上部的記錄作為由步驟922、924、926和928形成的處理循環(huán)的初始上下文。
在步驟922，試圖將在步驟904建立的當前可解釋文件發(fā)送到對于步驟922的第一次迭代，在步驟920識別的當前候選目的地。
在步驟924，如果步驟922的試圖發(fā)送是成功的，則如末端步驟930所示就完成了小代碼的處理以及相應可解釋文件的調度。
否則，如果步驟924指示調度不成功，則處理移到步驟926來找到另一個候選目的地。如果步驟926發(fā)現在列表中沒有其它候選目的地，則在步驟932聲明一個錯誤，可解釋文件被發(fā)送到臨時存儲區(qū)，并且處理在步驟930終止。
當步驟926確實在候選目的地列表中找到額外的未試過的目的地時，處理在步驟928繼續(xù)，其中前面試過的候選項從列表中刪除并且列表中的下一個候選目的地成為當前目的地。如所示，然后對新的當前目的地重復步驟922和924。簡單地說，重復包括步驟922、924、926和928的循環(huán)，直到或者成功地將可解釋文件發(fā)送到目的地，或者目的地列表用完。本領域的普通技術人員應該理解，有幾種方式來實現并且檢驗到目的地的可解釋文件的傳輸。
圖10描述了根據本發(fā)明的一個優(yōu)選實施方案，一接收到由業(yè)務處理器生成的可解釋文件，就由記錄處理器執(zhí)行的處理步驟。與下面的描述一起參考圖6和圖10將特別有幫助。圖10中大多數的處理步驟由圖6中的加載程序/解釋程序610執(zhí)行或協調。
隨著可解釋文件的接收，圖10的處理從步驟1002開始。接著，在步驟1004，如果需要，則可解釋文件被解密并且解壓縮，以生成準備加載到處理環(huán)境中的可解釋文件。接著，在步驟1006，讀取可解釋文件中的頭信息以便決定可解釋文件處理期間需要的相關性。
在步驟1008，為指定要從可解釋文件上載到記錄處理器庫中的方法檢查包含對應于圖5中方法段530的方法的部分可解釋文件。如前面與圖4中小代碼建立策略424一起描述的，特別是當調度希望廣泛分布和經常使用的新方法時，網絡工程師可指定要上載到記錄處理器的庫中的選定方法。
在步驟1008，對接收的可解釋文件中的每一種方法或方法集都檢查如圖5中的上載指示器532的標記，以便確定可解釋文件中的任何方法是否應該上載并且駐留在記錄處理器的庫中。如果不，則處理如下所述從步驟1014繼續(xù)。否則，則執(zhí)行步驟1010以便決定指定的可上載方法是否已經在庫中。如果可上載的方法已經在庫中，則處理如下所述從步驟1014繼續(xù)。否則，指定的方法被上載并且永久地存儲在記錄處理器庫中。
如本領域的技術人員認可的，這個處理自動地更新記錄處理器庫并且可以補充一個從記錄處理器庫中偶然刪除不用的或不經常使用的函數和數據的維護處理。
而且，本領域的技術人員將認識到，從可解釋文件到記錄處理器庫的方法上載還可以通過執(zhí)行可解釋文件中的代碼來控制或固有地實現。換句話說，簡單地往回參見圖5，當由記錄處理器執(zhí)行可解釋文件時，可解釋文件500的記錄數據段550內的某些方法調用可進行庫內容的檢查以及選定方法到記錄處理器庫中的上載。
在步驟1014，檢查記錄處理器，并且特別是記錄處理器的本地庫以便看看是否所有的相關性都存在。如果在步驟1014，確定某些相關性在記錄處理器中不存在，則在步驟1010，檢查可解釋文件以便看看缺少的相關性是否是自包含的。如果不是，則在步驟1026聲明一個錯誤并且可解釋文件的處理在末端步驟1024結束。
否則，當確定所有需要的元素對記錄處理器都是可用的時，則執(zhí)行步驟1016，其中包括作為可解釋文件中的函數或庫的方法被讀取到運行時環(huán)境中，即作為如圖6所示的存儲空間630中的代碼640。如前面所描述的，來自庫620的函數也因支持可解釋文件的執(zhí)行的需要拿到存儲空間630。隨著庫函數放入存儲空間620，加載程序/解釋程序610建立一個將函數名映射為表示存儲器中實例化的每個函數的進入點的存儲器地址的臨時表。這使得調用每個函數時能夠找到跳到的正確的存儲器位置。本領域的技術人員會將這個認作稱為運行時綁定的常規(guī)處理。
再參見圖10，在步驟1010，加載程序/解釋程序610定位已經調度到存儲器空間630中的可解釋文件的主進入點。然后進行可解釋文件的執(zhí)行。如前面與圖6一起描述的，然后可解釋文件中的指令將典型地導致在存儲空間630內創(chuàng)建會話重建空間650并且會在其中實例化各種業(yè)務相關以及事件相關的對象。由可解釋文件執(zhí)行創(chuàng)建的輸出累積在記錄處理器中直到可解釋文件執(zhí)行結束?？山忉屛募膱?zhí)行還導致數據寫入上下文信息存儲器660。例如，如果記錄處理器運行一個由長途電話會話引起的可解釋文件，則輸出文件可以是用戶的帳單或報告并且上下文信息存儲器660可存儲包含該用戶帳戶的即時余額的帳戶記錄。
如步驟1020所指示的，來自上下文信息存儲器660的記錄可按可解釋文件執(zhí)行期間的需要檢索以及更新。
在步驟1022，當可解釋文件的執(zhí)行結束時，執(zhí)行結果輸出為輸出670表示的文件或打印報告。然后如末端步驟1024所表示的，單一可解釋文件的處理結束。
圖11描述根據本發(fā)明的一個優(yōu)選實施方案，在業(yè)務功能創(chuàng)建、調度和實施時執(zhí)行的全部步驟。與下面的描述一起參見圖11和圖4會很有用。
當在業(yè)務開發(fā)環(huán)境(SDE)406中開發(fā)出新的業(yè)務時圖11的處理從步驟1102開始。
在步驟1104，業(yè)務開發(fā)者執(zhí)行SDE 406中的進一步操作以便為最近開發(fā)的業(yè)務函數指定相關性。優(yōu)選地，自動包括代碼相關性而數據資源可能需要業(yè)務開發(fā)者明確地標識。
在步驟1106，完成的新業(yè)務函數的拷貝通過NMS 404分配到網絡400中的許多網絡控制/業(yè)務處理器410。特別地，新業(yè)務函數可能出現在會話處理器412和庫420中。
在步驟1108，在新業(yè)務函數調度之后的某個時刻，新的業(yè)務函數在業(yè)務處理過程中被訪問并且會話處理器412生成一個相應的事件413。最終，小代碼編制器416將在小代碼中發(fā)現該事件的存在并且從庫420加入相應的記錄處理函數。這個記錄處理函數可能在步驟1106初始業(yè)務調度時加入到庫中。
在步驟1110，小代碼打包為可解釋文件并且如前面詳述地調度到記錄處理器。
在步驟1112，接收到可解釋文件的記錄處理器認出沒有包含在其本地庫中的新功能。通過圖10中描述的過程，記錄處理器自動識別并且為隨后的可解釋文件保留新的業(yè)務函數。而且，如前所述，記錄處理器通過某些方式與小代碼編制器通信以指示新函數現在包括在記錄處理器庫中并且代碼編制器僅包括對該函數的引用直到進一步通知。
在步驟1114，記錄處理器讀取可解釋文件，開始執(zhí)行其內容，并且由圖11所述的處理生成輸出。
最后，在步驟1116，調度和使用從業(yè)務處理器發(fā)出的通過可解釋文件遞交的新記錄處理函數的過程結束。
雖然在這里在示例實施方案環(huán)境中描述了本發(fā)明，但是本領域的普通技術人員應認識到，在不背離本發(fā)明范圍和精神的情況下，在已經示出和描述的基礎上可以有許多改變。示出和描述的示例實施方案的任何方面都不應該解釋為限制本發(fā)明。本發(fā)明的范圍應該由所附的權利要求來解釋。
附錄A//標題計費例子//版本//版權版權(c)1999//作者Kelvin R.Potrer//公司MCI WorldCom//描述計費例子<pre listing-type="program-listing">public class BillingTest{public class Datum{ public String myName； private Datum(){}； public Datum(String name){myName＝name；}； public void add(String type，String value){}； public String toString() { StringBuffer buffer＝new StringBuffer(myName)； buffer.append(＂＂)； //... return(buffer.to String())； }；}；//class Datumpublic class PhoneDevice{ private String myNumber； private String myType； public PhoneDevice(String number，String type) { myNumber ＝number； myType ＝type；}；//PhoneDevicepublic void offhook(String timestamp){ System.out.println(myType+＇＇+myNumber+＇＇+＂offhook＂+timestamp)；}；//摘機public void dialed_digits(String digits，String timestamp){ System.out.println(myType+＇＇+myNumber+＇＇+＂dialed＝＂+digits+＇＇+ timestamp)；}；//dialed_digits&lt;dp n="d23"/&gt; public String getNumber() { return(myNumber)； }； public void ring(String timestamp) { System.out.println(myType+＇＇+myNumber+＇＇+＂offhook＂+timestamp)； }；}；//調用狀態(tài)private boolean invokedStandalone＝false；//構造程序public BillingTest(){}//構造程序public void doFileInfo(){ //文件信息 Datum fileInfo＝new Datum(＂File Information＂)； fileInfo.add(＂FileType＂，＂Call-grouped&amp;amp;Timestamped Phone Operations＂)； fileInfo.add(＂SourceTypeVersion＂，＂1.3.1＂)； System.out.println(fileInfo.toString())；}；public void doSourcelnfo(){ //源信息 Datum contextData＝new Datum(＂Source Information＂)； contextData.add(＂Source＂，＂Switch 153-1503 Main St.，Garland，TX＂)； contextData.add(＂StartTime＂，＂Jan 02 1997 030005.3＂)； contextData.add(＂StopTime＂，＂Jan 09 1997 025911.2＂)； System.out.println(contextData.toString())；}；public String doCall_00000(){ //參與方通話00000 PhoneDevice phone1＝new PhoneDevice(＂2149367856＂，＂POTS＂)； PhoneDevice phone2＝new PhoneDevice(＂9727291000＂，＂Business Set＂)； //通話00000序列&lt;dp n="d24"/&gt; phonel.offhook(＂Jan 02 19997 030005.3＂)； phonel.dialed_digits(phone2.getNumber()，＂Jan 02 19997 030006.8＂)； //... return(＂...＂)；}；public String doCall_00001(){ return(＂...＂)；}；//...thru doCall_00499()...//快速索引函數public String doCall(int i){ String result； switch(i) { case 0result＝doCall_00000()；break； case 1result＝doCall_00001()；break； //... defaultresult＝＂Bad Index.＂； }；//switch return(result)；}；//doCallpublic void doProcess(){//文件信息doFileInfo()；//源傳息doSourceInfo()；//開始處理通話int number_of_calls＝500；String result；for(int i＝0；i＜number_of_calls；i++){ result＝doCall(i)；System.out.println(result)；&lt;dp n="d25"/&gt; }； //... }；//doProcess() public static void main(String[]args) { BillingTest billingTest＝new BillingTest()； billingTest.invokedStandalone＝true； billingTest.doProcess()； }；//main(...)}</pre>
權利要求
1.一種為多個用戶提供通信業(yè)務的系統(tǒng)，包括耦合到多個用戶的業(yè)務承載傳輸網；一個或多個業(yè)務處理器，其控制傳輸網為多個用戶執(zhí)行業(yè)務，生成與業(yè)務執(zhí)行相關的事件記錄，并且在事件記錄中加入用于處理已記錄事件的一個或多個指令；以及一個或多個記錄處理器，其從業(yè)務處理器接收事件記錄，提取用于處理已記錄事件的指令，并且使用從中獲得的指令處理事件記錄。
2.如權利要求1的系統(tǒng)，還包括為業(yè)務處理器分配用于處理已記錄事件的指令的網絡管理系統(tǒng)。
3.如權利要求2的系統(tǒng)，還包括業(yè)務開發(fā)環(huán)境，其中創(chuàng)建用于處理記錄的指令并且發(fā)送到網絡管理系統(tǒng)以便分配到業(yè)務處理器。
4.如權利要求1的系統(tǒng)，其中所述指令是JAVA字節(jié)代碼形式的可執(zhí)行代碼。
5.如權利要求1的系統(tǒng)，其中所述指令是小應用程序形式的可執(zhí)行代碼。
6.如權利要求1的系統(tǒng)，其中所述指令是servlet形式的可執(zhí)行代碼。
7.如權利要求1的系統(tǒng)，其中所述指令是JAVA BEANS形式的可執(zhí)行代碼。
8.如權利要求1的系統(tǒng)，其中所述指令是串行軟件對象形式的可執(zhí)行代碼。
9.一種為多個用戶提供通信業(yè)務的系統(tǒng)，包括耦合到多個用戶的業(yè)務承載傳輸網；一個或多個業(yè)務處理器，其控制傳輸網為多個用戶執(zhí)行業(yè)務，生成與業(yè)務執(zhí)行相關的事件記錄，并且將事件記錄轉換為可執(zhí)行文件；以及從業(yè)務處理器接收所述可執(zhí)行文件并且通過執(zhí)行所述可執(zhí)行文件完成事件記錄處理的一個或多個記錄處理器。
10.如權利要求9的系統(tǒng)，其中所述指令是JAVA字節(jié)代碼形式的可執(zhí)行代碼。
11.如權利要求9的系統(tǒng)，其中所述指令是小應用程序形式的可執(zhí)行代碼。
12.如權利要求9的系統(tǒng)，其中所述指令是servlet形式的可執(zhí)行代碼。
13.如權利要求9的系統(tǒng)，其中所述指令是JAVA BEANS形式的可執(zhí)行代碼。
14.如權利要求9的系統(tǒng)，其中所述指令是串行軟件對象形式的可執(zhí)行代碼。
15.一種在通信網中提供業(yè)務的方法，其中多個用戶耦合到由一個或多個業(yè)務處理器控制的傳輸網上，所述方法包括步驟從業(yè)務處理器生成表示業(yè)務處理事件的事件記錄；將事件記錄轉換為可執(zhí)行文件；將事件記錄以可執(zhí)行文件形式發(fā)送到記錄處理器；以及在記錄處理器中執(zhí)行所述可執(zhí)行文件以便完成事件記錄的處理。
16.一種在通信網中提供業(yè)務的方法，其中多個用戶耦合到由一個或多個業(yè)務處理器控制的傳輸網上，所述方法包括步驟從業(yè)務處理器生成表示業(yè)務處理事件的事件記錄；在事件記錄中加入一個或多個指令以便供記錄處理器在處理事件記錄時使用；將事件記錄轉換為可執(zhí)行文件；將事件記錄以可執(zhí)行文件形式發(fā)送到記錄處理器；從事件記錄中將指令提取到記錄處理器的運行時處理環(huán)境中；在記錄處理器中執(zhí)行從事件記錄中提取的指令以便處理其中記錄的事件；以及依據事件記錄中發(fā)送的事件而從記錄處理器中輸出執(zhí)行指令的結果。
17.如權利要求16的方法，還包括將指令從網絡管理系統(tǒng)分配到一個或多個業(yè)務處理器的步驟。
18.如權利要求17的方法，還包括在業(yè)務開發(fā)環(huán)境中開發(fā)所述方法并且將開發(fā)的方法分配到網絡管理系統(tǒng)以便分配給業(yè)務處理器的步驟。
19.如權利要求16的方法，其中基于記錄中已有的事件類型選擇性地完成到事件記錄的方法的增加。
20.一種用于處理在通信系統(tǒng)的業(yè)務處理期間發(fā)生的事件的方法，所述方法包括步驟創(chuàng)建在業(yè)務處理期間發(fā)生的事件記錄；向事件記錄中加入一個或多個處理方法；將包括處理方法的事件記錄傳送到記錄處理器；從事件記錄中將處理方法提取到記錄處理器的存儲器中；在記錄處理器中應用處理方法來處理事件記錄中記錄的事件；以及輸出對事件記錄中記錄的事件應用處理方法的記錄處理器的結果。
21.如權利要求20的方法，其中基于事件記錄中存在的事件類型選擇性地完成每個處理方法的加入。
22.如權利要求20的方法，還包括根據后續(xù)的事件記錄而在與記錄處理器相關的永久存儲器中保留處理方法的步驟。
23.一種用于表示在通信系統(tǒng)中業(yè)務處理期間發(fā)生的事件的業(yè)務處理事件記錄，包括描述在通信系統(tǒng)中發(fā)生的業(yè)務處理的一個或多個事件數據；描述記錄處理器如何處理業(yè)務處理事件記錄中的事件數據的一個或多個處理方法。
24.如權利要求23的業(yè)務處理事件記錄，其中所述事件數據以處理方法調用的形式存在于業(yè)務處理事件記錄中。
25.如權利要求23的系統(tǒng)，其中所述處理方法采用JAVA字節(jié)代碼形式。
26.如權利要求23的系統(tǒng)，其中所述處理方法采用小應用程序形式。
27.如權利要求23的系統(tǒng)，其中所述處理方法采用servlet形式。
28.如權利要求23的系統(tǒng)，其中所述處理方法采用JAVA BEANS形式。
29.如權利要求23的系統(tǒng)，其中所述處理方法采用串行軟件對象形式。
30.一種用于處理由通信系統(tǒng)生成的可解釋文件的記錄處理器，所述可解釋文件包括方法以及記錄的業(yè)務處理事件，所述記錄處理器包括包括存儲空間的通用處理環(huán)境；以及解釋程序/加載程序，其接收和解析可解釋文件，將方法加載到所述存儲空間，并且通過在通用處理環(huán)境中執(zhí)行加載的方法來處理可解釋文件中記錄的業(yè)務處理事件。
31.如權利要求30的記錄處理器，還包括方法的永久存儲庫以及記錄處理所需的數據。
32.如權利要求31的記錄處理器，其中從可解釋文件中獲得的一個或多個方法被上載到所述永久存儲庫中。
33.如權利要求32的記錄處理器，其中所述方法被響應于可解釋文件中的指示器選擇性地上載到所述永久存儲庫中。
34.一種用于控制通信網向耦合到所述網絡的用戶提供業(yè)務的業(yè)務處理器，所述業(yè)務處理器包括至少一個會話處理器，其執(zhí)行業(yè)務邏輯并且生成原始會話處理事件；至少一個事件捆綁器，其從會話處理器采集原始會話處理事件并且組裝事件集合；至少一個小代碼編制器，其接收來自事件捆綁器的事件集合并且加入方法以形成小代碼；以及至少一個調度程序，其接收來自小代碼編制器的小代碼，創(chuàng)建相應的可解釋文件，并且將可解釋文件發(fā)送到記錄處理器。
35.如權利要求34的業(yè)務處理器，還包括事件捆綁策略函數，其控制事件捆綁器聚集原始業(yè)務處理事件、過濾某些類型的事件、以及發(fā)送事件集合的方式。
36.如權利要求34的業(yè)務處理器，還包括小代碼建立策略，其控制小代碼編制器如何處理事件集合以及加入方法以便創(chuàng)建小代碼。
37.如權利要求34的業(yè)務處理器，還包括調度策略函數，其控制來自小代碼的可解釋文件的形成并且控制如何將可解釋文件發(fā)送到記錄處理器。
38.一種用于管理將來自生成業(yè)務處理事件記錄的通信系統(tǒng)的指令分配到記錄處理器的方法，包括步驟向業(yè)務處理事件記錄加入指令以便形成可解釋文件；識別哪些指令要由記錄處理器保留；指定可解釋文件中哪些指令要由記錄處理器保留；將可解釋文件傳送到記錄處理器；以及將已經指定要保留的那些指令上載到記錄處理器的永久存儲器中。
全文摘要
在為多個用戶提供業(yè)務的通信網中，在業(yè)務處理期間發(fā)生的事件被累積在事件記錄中并且發(fā)送到記錄處理器以便執(zhí)行后處理，如為該網絡的用戶估算要計的費用。該通信網中的每個業(yè)務處理節(jié)點累積事件記錄，將其與關于如何對其處理的指令捆綁在一起，并且將其調度到一個或多個記錄處理器(408)。在發(fā)送到記錄處理器之前，事件記錄通過描述如何在事件記錄的事件上執(zhí)行處理的指令增加。記錄處理器(408)是通用處理器并且用于后處理的指令在事件記錄自身中攜帶。不再要求后處理器專用于如計費的特殊目的。而且，后處理函數的調度更及時并且可以與到網絡業(yè)務處理器(410)的業(yè)務處理函數的調度集成在一起。
文檔編號G06Q20/00GK1433627SQ00818828
公開日2003年7月30日 申請日期2000年12月4日 優(yōu)先權日1999年12月4日
發(fā)明者K·R·波特 申請人:Mci全球通訊公司