CN1433627A

CN1433627A - 用于处理通信系统中的记录的方法和系统

Info

Publication number: CN1433627A
Application number: CN00818828.9A
Authority: CN
Inventors: K·R·波特
Original assignee: MCI Worldcom Inc
Current assignee: Verizon Business Global LLC
Priority date: 1999-12-04
Filing date: 2000-12-04
Publication date: 2003-07-30
Also published as: AU1942101A; EP1238520A1; EP1238520B1; US7356806B2; BR0016155A; JP2003516043A; US20040172471A1; DE60030155D1; EP1238520A4; AU773434B2; WO2001041407A1; CA2393459A1; MXPA02005546A; US6714978B1; ATE336858T1; DE60030155T2

Abstract

在为多个用户提供业务的通信网中，在业务处理期间发生的事件被累积在事件记录中并且发送到记录处理器以便执行后处理，如为该网络的用户估算要计的费用。该通信网中的每个业务处理节点累积事件记录，将其与关于如何对其处理的指令捆绑在一起，并且将其调度到一个或多个记录处理器(408)。在发送到记录处理器之前，事件记录通过描述如何在事件记录的事件上执行处理的指令增加。记录处理器(408)是通用处理器并且用于后处理的指令在事件记录自身中携带。不再要求后处理器专用于如计费的特殊目的。而且，后处理函数的调度更及时并且可以与到网络业务处理器(410)的业务处理函数的调度集成在一起。

Description

用于处理通信系统中的记录的方法和系统

发明领域

本发明涉及通信网，并且特别是涉及一种用于在通信网使用期间处理事件记录的新方法。

背景

在传统的收入承载的通信网，如公共交换电话网(PSTN)中，网络拥有者或“业务提供者”估算每个用户或“业务用户”的费用。用户为访问和使用该网络而付费并且估算的费用可基于固定费用、连接的距离和持续时间、传送的数据量、特殊业务的使用等。

为测量每个用户的使用，网络中的不同点要代表每个用户保持通过网络的连接或数据流记录。例如，在电话网中，对通话进行路由的交换机保持处理的每个通话的记录。因实际原因，这些记录传统地在每个交换机本地存储并且周期性地采集以便进行计费处理。这些记录还用于得出业务量统计和检测欺诈使用模式。

因为给定的连接，例如长途电话，可能涉及几个交换机，在处理该通话期间将生成几个单独的通话记录。在计费处理期间，这些记录必须从网络中所有交换机采集的数百万其它记录中挑选出来。然后组合相关的记录以便给出在特定通话期间使用了哪些网络资源并且因此应向适当的用户计多少费用的组合描述。

控制每个交换机的软件设计为记录在通话处理期间发生的选定事件并且将这些事件编码为一种非常特殊的格式。对事件编码的传统方法称为自动消息记帐(AMA)并且在可从泰克科迪亚科技(TelcordiaTechnologies)获得的名为GR-1100-CORE的行业标准文档中有描述。简而言之，编码格式是很好定义的静态数据结构，在本行业也称为通话详细记录(CDR)。单个通话记录捆绑成块，由交换机写入磁带或其它形式的持久存储设备中。

从网络采集一定时间积累的通话记录之后，计费处理系统必须解码并且解释由交换机和其它网元编码的计费记录内容的意义。为保证准确的计费处理，CDR的语法和语义必须通常能由生成记录的网元以及解释记录的处理系统理解。

计费处理器中的软件设计为解析和处理假定特定结构和内容的通话记录。CDR语法和语义的任何改变都需要计费代码的改变。这个改变由新的可计费业务或特性的引入而成为必需。例如，将长途电话通话的费用记在借记卡上或第三方的新业务的引入需要在CDR中编码新的信息。

在过去的电话网中，新业务的引入相对不频繁。减少进入市场的时间对业务提供者来说不是高优先级的。但是，最近，业务提供者之间的竞争以及由用户需求驱动的新功能的可用性加速了新特性的引入。

修改计费系统代码的负担阻碍了通信网中新特性的引入。传统的固定长度的CDR相对不灵活并且是不必要的限制。自从第一次引入CDR以来，通信带宽和处理速度已经成倍地改善，消除了保持CDR紧凑的需要。现在可以认识到背离传统CDR格式的许多优点。

因此，需要一种改善的方法来采集、传送和处理在通信网中记录的事件信息而无论何时新的计费特性加入该网络时都不需要大量的重写和测试计费系统软件。这个要求一般适用于由提供无论任何原因，不管是计费、欺诈检测、业务分析等都需要处理的通信业务产生的任何记录。

目前技术正在实现由单一通信网为用户提供各种业务类型、带宽、传输技术和特殊业务。因此，需要通用并且易于扩展的后处理系统与通信系统一起协同运行。

顺便还需要更通用的术语来表现这样的通信和后处理系统的特点。虽然“通话”和“通话处理”的概念和术语已经在传统电话网应用很久了，更广泛的术语“会话”和“业务处理”更适合于包含更现代的网络的所有用途。仅举几个例子，这里使用的“会话”指使用网络的一个实例并且包括单一数据分组的递交、临时双向语音信道的建立、或大量多媒体文件的传送。术语“业务处理”一般指网络为实现网络用户的需要作出的决定以及执行的操作。

发明概述

本发明针对一种用于创建和管理通信网中业务处理记录的方法，其中业务处理记录包括用于解释记录中描述的记录数据的指令。如这里使用的，术语“指令”一般指事情如何处理的编码。指令可以采用，例如，可实行代码、伪代码、源代码、描述或标记语言、简单的数据结构、或其混合的形式。而为了清楚，术语“方法”在下面用于描述在业务处理记录内传送的处理指令，应该理解，影响记录处理的“指令”的更一般的概念同样适合于每个实例。

根据本发明的一个优选实施方案，处理记录包括用于解释记录中描述的已记录数据的可执行代码形式的指令。

根据另一个方面，本发明针对一种方法，凭此业务处理记录被创建、累积、按合适的函数打包，然后基于一个任意的捆绑和调度策略来转发到计费处理系统。

根据本发明的一个优选实施方案，业务处理记录符合一个规定的可执行格式，例如可执行JAVA。(JAVA是Sun微系统的注册商标。)

业务处理记录可以由通信网中的任何网元或业务处理函数开始。业务处理记录与连接、会话或涉及网络的其它事务相关。除了估算要计费给用户的费用，业务处理记录还被处理以识别欺诈模式、分析消费者趋势、以及促进网络容量工程。每个业务处理记录包括业务处理事件数据并且，根据本发明，还包括指令，如方法或可调用函数，用于解释和处理业务处理事件数据。

根据本发明的业务处理记录作为可执行代码打包，其中方法编码为可调用函数并且事件编码为对使用与事件的特定实例相关的参数的那些函数的调用。

这种类型的业务处理记录可由通用处理系统处理，从记录中提取函数内容并且然后使用方法来解释和处理记录中的数据。无论何时新的业务或可计费特性加入网络中，新的或修改的业务处理函数就调度到整个网络的网元，如交换机和路由器中。当业务处理函数随新功能升级时，业务处理函数中生成业务处理记录的某些部分可以设计为将计费和其它后处理方法包括在随后生成并且发送的业务处理记录中。因此，计费函数就与业务处理函数一起生成并且分配。换句话说，这个方法使得计费函数的创建和调度与业务处理函数成为一个整体。

和使用专用硬件和软件的现有技术记录处理系统相比，根据本发明生成的事件记录可由通用后处理系统从业务处理事件记录中提取指令并且然后使用这些指令处理记录事件来处理。对计费函数的改变与业务函数在同一时间创建并且分配。因此，计费函数不需要与业务函数分开维护和测试。这导致新业务在通信网中更快的实施。

如前所述，传送给记录处理器的业务处理记录包括影响在记录处理器中事件数据如何解释和处理的指令。虽然现有技术通话详细记录包括在彼此的前后关系中解释的多个数据域，多个数据域在彼此前后关系中处理的方法是完全固定在记录处理器的软件和硬件内的。因此，现有技术CDR中数据域的语义由约定建立。相反，本发明允许数据域基于记录中的其它内容来动态地重新打算并且由记录处理器之外的逻辑操作来决定。实际上，本发明甚至使得记录处理器能够仅由业务处理记录的指令内容来重新打算。给定的通用记录处理器除了在业务处理记录本身里传送的指令之外实际上没有内在能力来处理业务处理记录里的事件。

附图描述

下面参考附图详细地描述本发明的上述以及其它特性和优点，其中：

图1是显示通话详细记录如何从网络中的交换位置析出的现有技术通信网示意图；

图2是描述根据现有技术多个后处理器如何处理通话记录的示意图；

图3是描述根据现有技术的通话详细记录结构的示意图；

图4是根据本发明的一个优选实施方案用于执行业务处理和业务事件记录生成的系统的功能框图；

图5是根据本发明的一个优选实施方案用于描述可解释的业务处理记录的结构的伪代码列表；

图6是根据本发明的一个优选实施方案描述与通用记录处理器相关的各种组件的功能的框图；

图7是描述事件捆绑器收集业务处理期间生成的事件的过程的流程图；

图8是描述小代码(code-let)编制器增加方法以及否则处理事件采集以生成小代码的过程的流程图；

图9是描述用于将小代码转换为可解释代码的过程的流程图；

图10是描述通用记录处理器接收并且处理可解释代码的过程的流程图；

图11是描述根据本发明的一个优选实施方案用于开发、调度和执行记录处理功能的整体过程的流程图。

发明详述

本发明针对用于处理通信网生成的事件记录的系统和方法。根据本发明的一个优选实施方案，事件记录由通用记录处理器处理并且用于执行这样处理的方法在事件记录本身内部传送。

下面的描述详细说明了记录处理方法的调度和执行如何以这种方式出现。

参见附图1，通信网100显示为包括由有时称为“中继”的通信链路组120和122互联的交换机112、114和116。这个交换机和链路的集合组成一个业务承载网110。在图1的例子中，业务承载网110用于在不同用户位置102a-102i之间传送信息。

网络110中交换机112、114和116的行动需要协调以便对数据进行路由或者连接用户。因此，交换控制器/通话处理器132被耦合以便控制交换机112。然而交换机112直接处理用户业务，交换控制器/通话处理器132命令交换机112在特定端口之间进行连接。在某些实际实现中，交换控制器/通话处理器132的某些或所有功能块都与交换机112集成或配置在一起。

同样，图1中交换机114和116分别由交换控制器/通话处理器134和136控制。

图1中每个交换控制器/通话处理器都连接到分组交换信令网150中，后者进而又耦合到至少一个业务控制点160。

通过信令网150，交换控制器132、134和136利用例如公共信道7号信令网(SS7)彼此之间进行通信。而且，交换控制器132、134和136可访问业务控制点160以确定如何发送给定的业务请求。在典型的电话网中，SCP160通常包括用于执行号码翻译，如将1-800号码电话通话映射为实际目的地号码的数据库。业务控制点160维护影响业务承载网110如何实现用户请求的数据。

如图1所示，业务管理系统(SMS)170耦合用于将业务控制数据下载到SCP160。在如图1所示的典型的智能网中，决定交换机和通话处理器行为的软件指令“内置”或手工加载到设备中。通过SMS170或SCP160没有机制用于向这些元件分配实际的操作软件。代替的，通过改变SCP160处的数据表的内容来实施对网络100的运行的有限控制。该软件控制交换机控制器/通话处理器132的一个方面创建通话处理临时发生的记录。这些记录包含关于用户使用实例的信息并且一般用于计算通常在一个给定的时间期间每个用户需要为其使用网络付费的量。这些记录累积到通话详细记录文件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的处理的任何重要的欺诈相关的调查结果。

业务分析函数230为了优化网络的运行或设计类似地处理CDR文件。生成计费记录223的文件解析阶段222以及生成记录数据实例235的记录关联/解析234与计费处理器函数210内的函数是类似的。业务分析阶段236检查使用模型，如网络的给定部分的通话的数量和持续时间，可能对指导网络中的资源利用或规划网络的增长有用。生成业务分析结果报告238以便概括业务分析236的调查结果。

计费处理器210、欺诈分析处理器220，以及业务分析处理器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描述了在通信系统400中实现的本发明的一个示例实施方案。特别地，图4显示在提供通信业务期间记录是如何生成和发送的。

通信系统400包括一个业务承载网络402和一个网络控制/业务处理功能410。

业务承载网402可以是电话网、分组交换数据网、帧中继、异步传输模式(ATM)、或任何其它形式的信息传输和路由网。业务承载网402甚至可以是不同传输类型的组合并且可进一步包含如语音响应单元或传真存储转发设备的特殊资源。

网络控制/业务处理函数410协调业务承载网402中设备的操作。例如，在通信系统400是电话网的情况下，网络控制/业务处理函数410处理在传统电话网中典型地由智能网(IN)通话处理器执行的通话处理，如通话路由选择。网络控制/业务处理函数410不管业务承载网402中使用的传输技术，都包括向用户提供业务需要的所有处理。

在网络控制/业务处理函数410内，会话处理函数412表示确定如何控制业务承载网402以便响应用户请求提供业务的处理。会话处理函数412类似于电话网中的电话处理。但是，会话处理函数412还包括对传统电话网之外的数据传输、多方通信、广播、组播、按需带宽、存储转发、网关协调以及其它特性。

会话处理函数412在协调业务期间生成事件413。会话处理函数412以软件实现并且在计算机上运行。实现会话处理函数412的部分指令决定何时对应于应该记录的重要的、可能可计费的行为的处理步骤出现。

例如，电话用户可访问查号并且然后为少的费用自动请求该通话结束。因为会话处理函数412引起业务承载网402来满足这个请求，该行为作为事件记录因此计费处理会将该费用附加在用户的帐单上。

不是所有事件都有计费意义。有些事件简单地记录什么发生并且被证明对发现和消除网络中的问题，或者对观察使用模式有用。实现业务处理函数的软件指令决定哪些行为会生成事件。因此，业务处理软件的设计者控制哪些事件适合被报告。

如图4所示，在业务处理期间生成的事件413由事件捆绑器414累积。事件捆绑器414决定如何将事件分组在一起，哪些事件可以过滤掉，以及何时累积了足够数量的事件以便以事件集合415的形式传递到下一个处理阶段。事件捆绑策略422是决定事件捆绑器414行为的存储的规则集合或数据。

为调整事件捆绑器414的行为或性能，网络工程师在事件捆绑策略422内任意建立规则。结果，例如，事件捆绑器414使用会话的结束作为将与该会话相关的所有事件捆绑在一起的触发器。否则，事件捆绑器414按使用的资源、按事件类型或按事件中涉及的网络事件的标识将事件分组。如事件捆绑策略422控制的，事件捆绑器414还规定表示部分或多个会话的事件组。

如图4所示，由事件捆绑器414创建的事件集合415随后由小代码编制器416处理以生成小代码417。每个小代码417包括与表示对解释事件数据有用的处理步骤的代码一起的记录事件数据。小代码编制器416检查一个或多个接收的事件集合415并且增加可执行代码段和附加数据。特别地，小代码编制器416依据事件集合415中存在什么事件类型来有条件地增加选择的数据和指令(可执行代码)。要增加到小代码中的指令源自包含代码段的库420或者由小代码编制器416动态地构建。小代码编制器416将来自多个事件集合415的数据组合到单一小代码417。

小代码编制器416的行为由网络工程师任意建立的存储的小代码建立原则424确定。小代码建立策略424可以是包含例如导致小代码编制器416将多个事件集合组合成单一小代码417的规则和数据的数据文件。小代码建立策略424还例如决定将来自库420的代码段包含在小代码417中，或仅仅是参考。小代码编制器416会考虑已知的通用库函数在将最终接收打包数据的记录处理器之间的可用性。小代码编制器416决定记录处理器以前从没用过的新的或者更新的函数已经可用。因此，小代码处理策略函数可确保小代码中包含新函数，因此记录处理器可使用新函数并且可能为以后使用而存储该函数。而且，通过小代码建立策略424，网络工程师可明确地指定新的或更新的函数来上载到记录处理器的本地库中。对每个方法或方法组的这一指定在图5中描述为上载指示器532。

在本发明的优选实施方案中，小代码编制器416赋予每个小代码417足够的数据和方法，因此通用处理器可以解释包含在其中的数据并且给出有用的输出，例如为用户计费。因此，对如何进行计费以及其它间接处理的控制在软件指令以及网络控制/业务处理器函数410内的函数库内实现。这意味着计费以及其它间接处理函数可伴随业务处理特性开发、测试和调度。

在本发明的优选实施方案中，小代码417以如JAVA字节代码的通用可执行代码的形式创建，以便各种网络控制/业务处理器410以及记录处理器408a-b可以在不同的计算平台上实现并且在创建和处理事件记录方面完全兼容。不管对JAVA字节代码的示例参考，相关领域的技术人员认可可采用许多其它种类的通用可执行代码，如小应用程序(applet)、servlet、JAVA BEANS、以及串行对象。

在图4中，记录处理器408a和408b代表可解释和执行在通信系统400内的业务处理期间生成的指令和数据的通用目的处理器。

调度程序418接收每个小代码417并且生成发送到记录处理器408a、408b的所谓的“可解释”文件419。如调度策略426中存储的指令所指导的，调度程序418决定何时以及向哪里发送每个结果可解释文件419。通过调整调度策略426中的设置，网络工程师可使调度程序418将可解释代码发送到选择的或优选的记录处理器408a、408b中的一个。调度程序418还通过感知记录处理器408a和408b之间的瞬时处理负载来执行负载均衡并且决定因此向哪里发送每个可解释文件419。调度程序418“调节”可解释文件419到多个记录处理器。调度程序418选择将可解释文件419发送到存储区域440而不是直接到任何记录处理器。调度程序418基于对库函数的了解或区分每个记录处理器408a、408b的特殊功能来决定向哪里发送每个可解释文件419。

调度程序418的上述任何行为都由调度策略426的内容控制或改变。调度程序418还决定可解释文件419的最终形式。

根据本发明的一个优选实施方案，通信系统400还包括网络管理系统(NMS)404和业务开发环境(SDE)406。

部分地，网络管理系统404担任传统的监视业务承载网402的功能状态，以及声称对其控制的角色。根据本发明的一个优选实施方案，NMS404还是一种用于向通信系统400中的一个或多个网络控制/业务处理函数410分配操作指令或软件的装置。在1998年8月5日提交的共同转让、共同未决的美国专利申请第09/128,937号并且名为“用于智能分布式网络结构的智能呼叫平台(Intelligent Call Platformfor an Intelligent Distributed Network Architecture)”中描述有用于向业务处理器分配操作软件和数据的这样一种装置，该专利申请的整个内容和公开内容合并在这里供参考，就象在这里提出一样。

业务处理和其它函数，包括计费处理以及其它这样的间接处理函数，在业务开发环境(SDE)406中创建。一旦满意的开发和测试，在SDE406中开发的函数就对NMS404可用以便分配到网络中。通过前面描述的机制，计费以及其它间接处理函数通过SDE406和NMS404类似地开发和传播。

本发明的一个显著优点是可以在无须记录处理器软件任何改变的情况下以这种形式提供许多类型的改变。因为记录处理器的函数多半源自接收的可解释包，所以大多数通常的改变，如新的可计费特性的增加，在不改变记录处理器代码的情况下已经完成。在优选实施方案中，记录处理器支持JAVA等并且可解释代码是象这样打包的。

只有可执行程序的基本形式方面的改变，如在可解释对象中定位方法和数据的方式，会必然地影响记录处理器的操作。业务处理特性、事件处理策略、小代码处理策略以及调度策略的改变一般对记录处理器代码没有影响，除了这些改变需要可解释文件格式的基本改变的未必可能的事件。

图5描述了根据本发明的一个优选实施方案调度到记录处理器的一个可解释文件的典型内容。在图5中，可解释文件500显示为包括几段。文件数据头510包括关于可解释文件500的一般信息，如文件类型标识符串512，文件长度514，以及包含段的相对位置或文件内的进入点的进入点表516。

可解释文件500中的方法段530包括可由记录处理器直接执行的函数。在本发明的优选实施方案中，方法段530包括已编译的JAVA可执行代码段。但是，图5中为清楚起见，方法段530以与源代码类似的形式出现。某些方法或方法组附有上载指示器532，用于指定应该上载并且保留在最终接收可解释文件500的每个记录处理器的库中的那些方法。

可解释文件500中的记录数据段550包括表示通信网中业务处理期间发生的实际事件的方法调用。记录数据段550中调用的某些方法是在可解释文件500的段530中包含的那些，而其它方法可从可解释文件外部的库中获得。每个方法调用使用适合于特殊事件或行为的特殊实例的参数。下面将详细进行描述，当记录处理器加载并且执行可解释代码时，顺序方法调用使得记录处理器能够重新构造网络中业务处理期间发生的事件并且基于重新构造的事件执行有用的处理。

例如，可解释文件500的方法段530包括称为“Add_Party(加入会话方)”的方法。这个方法接受许多新的一方加入到已有的通信会话中，以及该方请求加入的日期和时间。新的一方加入到通信会话中将要求对用户计算额外的费用。“Add_Party”方法包括用于确定增加到用户帐单的合适的费用的代码。

如前面与小代码建立策略424一起描述的，在给定可解释代码中给定方法的包括依赖于函数的需要。如果可解释文件包括许多会话的事件但是没有一个会话涉及Add-Party函数，则可解释文件不需要包括Add-Party函数。同样，如果加入会话方函数很常见，可能是标准库函数，则可解释文件不需要包括该函数，而是引用该函数或记录处理器需要的库。

记录数据段550包括在代码中处理从哪里开始的一个准确的进入点，如图5中main()语句所表示的。所有的执行环境(例如，操作系统，以及解释程序)规定如何识别其特定可执行格式的开始点(例如，在C/C++和JAVA中的“main”程序)。记录数据段550的开始是通用处理器加载可执行文件500并且然后开始处理内容之后的执行开始点。如后面详细描述的，通用记录处理器对可解释文件的最终处理需要对象的说明、在这些对象上的方法调用、以及对象间的相互作用，这对于面向对象编程的领域的技术人员是熟知的。

简而言之，随着网络用户参加使用通信网的会话，与该会话相关的事件被记录并且组装到可解释文件500中的整体描述中。事件表示为可解释文件500的记录数据段550中的方法调用。在可解释文件500处理期间要调用的方法可通过可解释文件500自包含在并且分配到记录处理器中。在本说明书的附录A中作为参考显示了根据可解释文件500的上述描述的JAVA代码的例子。

图6说明了根据本发明的一个优选实施方案装备以便接收并且处理可解释文件的记录处理器600。

在图6中，可解释文件419由记录处理器408a接收并且以与程序在计算机中加载和执行或者小应用程序由主计算机应用程序，如互联网浏览器加载和执行类似的方式加载并且执行。更特别地，可解释文件419的内容被解析并且由加载程序/解释程序610读进记录处理器408a的存储空间630。因在解析期间找到可解释文件419中的代码段，这些段被作为临时代码640拷贝到记录处理器的存储空间并且加载程序/解释程序610生成一个临时表，在内存中将函数的名字映射到其地址。因为在可解释文件419中遇到对库函数的引用，所以加载程序/解释程序610将从本地库630中选择的函数拷贝到存储空间630以便在处理期间很容易对其访问。这相当于本地库的运行时绑定。

当解释程序610遇到可解释文件419中的主进入点时，实际记录网络事件的处理开始。例如，存储器中的处理上下文有效地重新构建与给定通信会话相关的事件和环境。在存储器中的会话重构650内，因表示事件的每个函数调用在可解释文件419中遇到，所以创建对象实例652、654、656和658并且紧接着调用方法来完成由可解释文件419中的代码计划的处理。

各种对象实例652、654、656和658，例如，表示给定会话中涉及的用户、用户设备、交换机、路径、通话支路、业务或资源。计算机科学和面向对象的编程领域的技术人员熟悉处理可以这种形式发生的各种方式。

记录处理器408a可访问一个外部或集中的数据库660来检索如给定用户的当前帐户信息的共享数据。记录处理器408a为给定用户处理事务并且然后将更新的信息返回数据库660。例如，记录处理器408a获得用户的帐户并且然后将费用添加到该用户的帐户信息中。因此，即使不同会话的使用由不同的记录处理器处理，费用也会正确地累加到该用户的帐户。

将编码的功能放在可解释文件419的一个显著优点是具有包括如哈希表和二进制树的有用数据结构以及如循环、递归、条件分支等的编程结构的灵活性。相反，现有技术的通话详细记录仅包含数值。

现在参见图7，显示的流程图用于描述事件捆绑器414在处理来自会话处理器412的事件413时执行的处理步骤。一接收到来自会话处理器702的事件413，处理就从步骤702处开始。因此图7中描述的处理对每个这样的接收事件413重复。优选地，事件捆绑器414为会话处理器412参与的每个单独的通信会话维护一个持久的事件累积。每个这样的累积称为“会话事件集合”并且优选地持续直到相关会话完成并且由会话处理器412决定中断。这对技术人员很容易理解，会话处理器412为每个事件413提供某种类型的指示器来识别通信会话的相关实例。事件捆绑器414使用这个指示器来正确地关联与业务处理器412中特定通信会话相关的进入事件413。

从步骤704继续，决定事件是与一个进行中的会话有关，还是一个事件捆绑器414还没有创建会话事件集合的新会话。

如果进入事件表示一个新会话，则在步骤706，建立新的会话事件集合。否则，处理直接从步骤704移到步骤708。

在步骤708，决定进入事件是否表示会话的结束。一旦会话结束，会话处理器412就生成并且发送一个由事件捆绑器414识别的末端类型事件。为概括处理的剩余部分，如果进入事件不表示会话结束，则该事件简单地添加到与会话相关的进行中事件集合中。否则，事件捆绑器414将决定如何将结束的事件集合与其它事件集合组合在一起并且决定是否将累积的事件集合发送到小代码编制器416。

在步骤708，如果决定事件不表示会话结束，则处理从决定步骤710继续。在步骤710，事件捆绑器414根据事件捆绑策略424中的设置执行什么事件类型添加到会话事件集合中的控制。如前面提到的，网络工程师使用这种方法来限制集合中事件的类型。例如，某些事件消息仅对诊断目的有用并且在后处理期间用不到。通过改变事件捆绑策略422的内容，网络工程师可动态地导致诊断事件通知包含在或不包含在事件集合中。在通常情况下，采用这个过滤来避免最终将会发送到后处理的集合中无关的内容。

如果在步骤710，进入事件没有被事件捆绑策略422中实现的当前指令过滤，则在步骤712该事件添加到合适的会话事件集合。否则，跳过步骤712并且单一进入事件的处理如末端步骤714表示的结束。

回来参考步骤708，如果进入事件确实表示相关会话的结束，则处理从步骤716重新开始，其中会话事件集合对进一步输入关闭并且关于该集合的任何需要的概要数据被编译并且加入到该集合中。概要数据可包括，例如，集合中事件的数量、使用的任何特殊资源的列表，或会话处理器或事件捆绑器函数的软件版本。

然后继续到步骤718，事件捆绑器414，由事件捆绑策略422中的内容指导，基于事件集合的某个通用属性决定事件集合是否要分组到聚合的集合。例如，网络工程师通过将与业务承载网402中的特定资源的使用相关的集合组合在一起来决定优化性能。

如果在步骤718，没有使用用于组合集合的标准，则在步骤720，最近结束的事件集合被简单地添加到累积的或聚集的集合。随着单一集合的增加，在步骤722检查累积集合的属性以便决定累积的集合是否准备好发送到小代码编制器416。做出这个决定的事件捆绑器414的标准由事件捆绑策略424内的内容决定。例如，无论何时聚集的集合增长到某个整体大小或当从来自事件捆绑器的前一个聚集集合的发送以来已经过去了一个时间限制，则事件捆绑器414发送一个聚集集合。完成后者以便当网络相对空闲时减少处理少量会话的延迟。

然后在步骤722，如果符合发送累积集合的标准，则该事件集合就发送到小代码编制器416并且优选地从实现事件捆绑器414的处理器的有效存储器中去除。否则，在步骤722，如果不满足发送标准，则累积的集合仅暂时保持在存储器中并且单一事件的处理如末端步骤714所指示的结束。

附图的图8描述了小代码编制器416执行的处理，由此每个事件集合415从事件捆绑器414中接收并且处理以便生成小代码417。

图8的处理一接收到单一事件集合415就从步骤802开始。然后直接进行到步骤804，小代码编制器416决定被组装的小代码是否已经存在或者新的事件集合的接收是否应该启动一个新的小代码。如果在步骤804决定需要，则在步骤808重新开始执行之前在步骤806创建小代码。在步骤806创建的小代码将作为一个或多个事件集合的容器。

注意步骤804和806主要在单一小代码中包括多个事件集合时有用。

在步骤808，小代码编制器416决定是否容许在单一小代码中放置多个事件集合。这受到小代码建立策略424的内容的影响。例如，网络工程师为了效率决定允许事件集合绑定到小代码中。如果允许这样的绑定，则执行步骤812以便将接收的事件集合加入到当前小代码中。

在加入事件集合之后，小代码编制器416在步骤814估算该小代码是否满足结束并且发送该小代码的条件。小代码发送条件是小代码建立策略424内的设置。例如，网络工程师将无论何时小代码超过某个大小或事件集合的数量就导致小代码编制器发送小代码的内容放在小代码建立策略424中。

发送条件还考虑在小代码内的事件集合中用到的资源类型。

如果，在将事件集合加入到小代码之后，在步骤814小代码还不满足发送条件，则处理在步骤830终止并且事件集合和小代码都不再进一步处理直到接收到随后的事件集合。

替代地，如果在步骤814小代码被认为满足发送条件，则可能包括多个事件集合的小代码在步骤816开始进一步被处理。

回来参见步骤808，如果不允许多个事件集合构成小代码，则执行进行到步骤810，其中在步骤802接收的单一事件集合被简单地放入在步骤806创建的小代码中。此后在步骤816开始进一步处理新的小代码。

图8中的剩余处理步骤按需要用后面后处理器需要的功能块扩大小代码。这些功能块与前面与图5一起描述的方法530对应。

在步骤816，基于小代码中包括的事件类型构造了表示运行时需要的所有处理方法和任何其它功能块的相关性列表。例如，如果即使小代码中的一个事件集合包括涉及对通话方的费用撤销的事件，则为了后处理器正确地处理该事件以及处理包含该事件的任何会话，在运行时，某些函数必须可用。

某些经常用到或非常基本的函数如图6中的库620所示永久地驻留在后处理器中。通过对哪些函数一般对后处理器可用的某些了解，小代码编制器可避免在小代码中复制这些运行时函数。因此，步骤818涉及决定是否能用引用代替实际运行时函数以便减少小代码的大小。在步骤818，由小代码建立策略424指示小代码编制器416是否允许引用来代替实际的运行时函数。网络工程师可调整小代码建立策略424的内容来导致小代码编制器为最小化小代码大小来使用对运行时函数的引用。否则，网络工程师想要某些或所有需要的函数显式地包括在每个小代码中，以便确保最终接收该小代码的所有后处理器使所有需要的功能完整。如果目标后处理器的功能在小代码建立时还不确定时，这样做很有必要。

如果处理步骤818发现允许小代码中的引用，则在步骤820对可由引用表示的每个函数的合适的引用就放置在小代码的方法段中。这样的引用例如，可规定库名和函数调用名。

除此之外，对于在步骤820由引用代替的每个函数，更新运行时相关性列表，删除现在已经通过引用充分包含在小代码中的函数。

无论函数是否由引用代替，在步骤822小代码的处理都继续，其中为任何剩余的相关性检查在步骤816得到的相关性列表。如果还有必需寻址的运行时相关性，则执行步骤824来向小代码的方法段增加需要的函数。

这些函数可，例如，从图4所示的本地函数库420获得。由步骤824包括在小代码中的所有函数从步骤816得到的相关性列表中去掉。

然后，在步骤826，再次检查相关性列表来看是否还需要没有显式地或通过引用包含的任何函数。如果还有函数需要包括，则在步骤828，查阅小代码建立策略以便找到可用的指令来在小代码编制器416中动态建立所需的功能。然后从相关性列表中去掉动态构建并且包括在小代码中的任何函数并且处理在步骤830重新开始。

在步骤830，进行相关性的最终评估。如果有任何剩余的未解决的相关性，则小代码编制器在步骤832声明一个错误情况并且取消小代码以便网络工程师查找错误的故障原因。因此接收事件集合的处理在步骤840终止。

否则，如果步骤830，所有运行时函数相关性都解决了，则在步骤834完整的小代码传递到调度程序418并且接收事件集合的处理在步骤840结束。

图9描述了在接收来自小代码编制器416的小代码415并且将完整的可执行代码或“可解释”文件419发送到记录处理器408或临时数据存储库时由调度程序418执行的处理步骤。

一接收到小代码，图9的处理就从步骤902开始并且立即继续到步骤904。

在步骤904，通过编译和链接(如果需要)累积在小代码中的代码并且通过将头信息加到对应于图5中头段510的可执行文件，小代码被转换成自包含可解释代码。在一个变化方案中，接收的小代码包括类似人们可读的源代码形式的函数。这个源代码需要编译成某种形式的直接可执行机器指令并且函数引用需要通过链接解决，计算机编程的技术人员通常都理解这一点。在另一个变化方案中，小代码包括作为仅需要包含和链接在可解释文件中的预编译段的函数。在第三个变化方案中，函数以类似源代码的形式在可解释文件中传递以便由记录处理器后处理程序在运行时解释。

在优选实施方案中，可解释文件包括已编译JAVA字节代码形式的函数并且记录处理器能够直接执行这样的可解释文件。

在步骤904，还生成了一个压缩或加密版本的可解释文件以便改善可解释文件传输和存储时的效率和安全性。

接着，在步骤906，查阅调度策略426以便决定可解释文件的目的地是否固定。在某些情况下，网络工程师希望强制所有的可解释文件发送到一个特定的记录处理器。

如果是这种情况，则在步骤908，试图将可解释文件发送到指定的记录处理器或存储库。如果这个发送努力失败则声明一个错误。然后因为不允许替代的目的地或存储库所以处理在步骤910终止。

返回步骤906，如果在调度策略426中可解释文件的目的地不固定，则执行进行到步骤912。在步骤912，生成两个列表。一个是当前对调度程序可用的所有目的地列表，如记录处理器和存储库。另一个是小代码的外部相关性列表。例如，小代码编制器假设某些库在运行时可得到并且如图8的步骤818-820所指示的选择仅引用函数。外部相关性可以是小代码编制器假设将在后处理运行时环境中存在的数据或函数。

如果不是所有的记录处理器都有假设的运行时函数，则步骤912、914和915确保可解释文件仅调度到在本地库中确实有需要的运行时函数的记录处理器中，如图6所示的库620。

在步骤912生成列表之后，执行步骤914以便确定是否允许基于每个目的地功能的路由。这个决定由调度策略426的内容确定。每个目的地的功能包括，例如，可用的运行时库、处理或存储功能、或目的地的特定资源的可用性。网络工程师可能想要禁止功能的路由以便执行故障检查或协调新的函数库的调度，这将在后面与图10的步骤1008一起描述。

如果允许基于功能的路由，则执行步骤915由此没有处理可解释文件需要的功能的目的地从步骤912得到的候选目的地列表中删除。

接着，在步骤916，查阅调度策略以便确定到目的地的可执行文件的路由是否可考虑候选目的地之间的优先选择顺序。如果是，则执行步骤917以便基于调度策略426中包含的优先选择对候选列表排序。网络工程师可利用这个功能使得特定业务处理器优选地“归位”到特定的记录处理器。这个优先选择可基于，例如静态负载均衡或业务处理器和记录处理器之间的接近性。

在步骤918，查阅调度策略以便确定是否允许动态负载均衡。如果允许，则执行步骤919以便进一步根据当前处理负载对候选目的地列表排序。每个目的地记录处理器的当前处理负载可通过例如网络管理系统转播到调度程序。虽然没有明确地显示，但是通信网领域的普通技术人员很容易理解实现这个的方法。

一到达步骤920，则从步骤912得到的目的地的候选列表就根据调度策略426的指示完成过滤和排序。步骤920简单地涉及选择目的地列表的最上部的记录作为由步骤922、924、926和928形成的处理循环的初始上下文。

在步骤922，试图将在步骤904建立的当前可解释文件发送到对于步骤922的第一次迭代，在步骤920识别的当前候选目的地。

在步骤924，如果步骤922的试图发送是成功的，则如末端步骤930所示就完成了小代码的处理以及相应可解释文件的调度。

否则，如果步骤924指示调度不成功，则处理移到步骤926来找到另一个候选目的地。如果步骤926发现在列表中没有其它候选目的地，则在步骤932声明一个错误，可解释文件被发送到临时存储区，并且处理在步骤930终止。

当步骤926确实在候选目的地列表中找到额外的未试过的目的地时，处理在步骤928继续，其中前面试过的候选项从列表中删除并且列表中的下一个候选目的地成为当前目的地。如所示，然后对新的当前目的地重复步骤922和924。简单地说，重复包括步骤922、924、926和928的循环，直到或者成功地将可解释文件发送到目的地，或者目的地列表用完。本领域的普通技术人员应该理解，有几种方式来实现并且检验到目的地的可解释文件的传输。

图10描述了根据本发明的一个优选实施方案，一接收到由业务处理器生成的可解释文件，就由记录处理器执行的处理步骤。与下面的描述一起参考图6和图10将特别有帮助。图10中大多数的处理步骤由图6中的加载程序/解释程序610执行或协调。

随着可解释文件的接收，图10的处理从步骤1002开始。接着，在步骤1004，如果需要，则可解释文件被解密并且解压缩，以生成准备加载到处理环境中的可解释文件。接着，在步骤1006，读取可解释文件中的头信息以便决定可解释文件处理期间需要的相关性。

在步骤1008，为指定要从可解释文件上载到记录处理器库中的方法检查包含对应于图5中方法段530的方法的部分可解释文件。如前面与图4中小代码建立策略424一起描述的，特别是当调度希望广泛分布和经常使用的新方法时，网络工程师可指定要上载到记录处理器的库中的选定方法。

在步骤1008，对接收的可解释文件中的每一种方法或方法集都检查如图5中的上载指示器532的标记，以便确定可解释文件中的任何方法是否应该上载并且驻留在记录处理器的库中。如果不，则处理如下所述从步骤1014继续。否则，则执行步骤1010以便决定指定的可上载方法是否已经在库中。如果可上载的方法已经在库中，则处理如下所述从步骤1014继续。否则，指定的方法被上载并且永久地存储在记录处理器库中。

如本领域的技术人员认可的，这个处理自动地更新记录处理器库并且可以补充一个从记录处理器库中偶然删除不用的或不经常使用的函数和数据的维护处理。

而且，本领域的技术人员将认识到，从可解释文件到记录处理器库的方法上载还可以通过执行可解释文件中的代码来控制或固有地实现。换句话说，简单地往回参见图5，当由记录处理器执行可解释文件时，可解释文件500的记录数据段550内的某些方法调用可进行库内容的检查以及选定方法到记录处理器库中的上载。

在步骤1014，检查记录处理器，并且特别是记录处理器的本地库以便看看是否所有的相关性都存在。如果在步骤1014，确定某些相关性在记录处理器中不存在，则在步骤1010，检查可解释文件以便看看缺少的相关性是否是自包含的。如果不是，则在步骤1026声明一个错误并且可解释文件的处理在末端步骤1024结束。

否则，当确定所有需要的元素对记录处理器都是可用的时，则执行步骤1016，其中包括作为可解释文件中的函数或库的方法被读取到运行时环境中，即作为如图6所示的存储空间630中的代码640。如前面所描述的，来自库620的函数也因支持可解释文件的执行的需要拿到存储空间630。随着库函数放入存储空间620，加载程序/解释程序610建立一个将函数名映射为表示存储器中实例化的每个函数的进入点的存储器地址的临时表。这使得调用每个函数时能够找到跳到的正确的存储器位置。本领域的技术人员会将这个认作称为运行时绑定的常规处理。

再参见图10，在步骤1010，加载程序/解释程序610定位已经调度到存储器空间630中的可解释文件的主进入点。然后进行可解释文件的执行。如前面与图6一起描述的，然后可解释文件中的指令将典型地导致在存储空间630内创建会话重建空间650并且会在其中实例化各种业务相关以及事件相关的对象。由可解释文件执行创建的输出累积在记录处理器中直到可解释文件执行结束。可解释文件的执行还导致数据写入上下文信息存储器660。例如，如果记录处理器运行一个由长途电话会话引起的可解释文件，则输出文件可以是用户的帐单或报告并且上下文信息存储器660可存储包含该用户帐户的即时余额的帐户记录。

如步骤1020所指示的，来自上下文信息存储器660的记录可按可解释文件执行期间的需要检索以及更新。

在步骤1022，当可解释文件的执行结束时，执行结果输出为输出670表示的文件或打印报告。然后如末端步骤1024所表示的，单一可解释文件的处理结束。

图11描述根据本发明的一个优选实施方案，在业务功能创建、调度和实施时执行的全部步骤。与下面的描述一起参见图11和图4会很有用。

当在业务开发环境(SDE)406中开发出新的业务时图11的处理从步骤1102开始。

在步骤1104，业务开发者执行SDE 406中的进一步操作以便为最近开发的业务函数指定相关性。优选地，自动包括代码相关性而数据资源可能需要业务开发者明确地标识。

在步骤1106，完成的新业务函数的拷贝通过NMS 404分配到网络400中的许多网络控制/业务处理器410。特别地，新业务函数可能出现在会话处理器412和库420中。

在步骤1108，在新业务函数调度之后的某个时刻，新的业务函数在业务处理过程中被访问并且会话处理器412生成一个相应的事件413。最终，小代码编制器416将在小代码中发现该事件的存在并且从库420加入相应的记录处理函数。这个记录处理函数可能在步骤1106初始业务调度时加入到库中。

在步骤1110，小代码打包为可解释文件并且如前面详述地调度到记录处理器。

在步骤1112，接收到可解释文件的记录处理器认出没有包含在其本地库中的新功能。通过图10中描述的过程，记录处理器自动识别并且为随后的可解释文件保留新的业务函数。而且，如前所述，记录处理器通过某些方式与小代码编制器通信以指示新函数现在包括在记录处理器库中并且代码编制器仅包括对该函数的引用直到进一步通知。

在步骤1114，记录处理器读取可解释文件，开始执行其内容，并且由图11所述的处理生成输出。

最后，在步骤1116，调度和使用从业务处理器发出的通过可解释文件递交的新记录处理函数的过程结束。

虽然在这里在示例实施方案环境中描述了本发明，但是本领域的普通技术人员应认识到，在不背离本发明范围和精神的情况下，在已经示出和描述的基础上可以有许多改变。示出和描述的示例实施方案的任何方面都不应该解释为限制本发明。本发明的范围应该由所附的权利要求来解释。

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 Datum
public class PhoneDevice
{
 private String myNumber；
 private String myType；
 public PhoneDevice(String number，String type)
 {
  myNumber         ＝number；
  myType       ＝type；
}；//PhoneDevice
public 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
        <!-- SIPO <DP n="23"> -->
        <dp n="d23"/>
 public String getNumber()
 {
  return(myNumber)；
 }；
 public void ring(String timestamp)
 {
  System.out.println(myType+＇：＇+myNumber+＇＇+＂offhook＂+timestamp)；
 }；
}；
//调用状态
private boolean invokedStandalone＝false；
//构造程序
public BillingTest()
{
}//构造程序
public void doFileInfo()
{
 //文件信息
 Datum fileInfo＝new Datum(＂File Information＂)；
 fileInfo.add(＂FileType＂，＂Call-grouped&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 03：00：05.3＂)；
 contextData.add(＂StopTime＂，＂Jan 09 1997 02：59：11.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序列
        <!-- SIPO <DP n="24"> -->
        <dp n="d24"/>
 phonel.offhook(＂Jan 02 19997 03：00：05.3＂)；
 phonel.dialed_digits(phone2.getNumber()，＂Jan 02 19997 03：00：06.8＂)；
 //...
 return(＂...＂)；
}；
public String doCall_00001()
{
 return(＂...＂)；
}；
//...thru doCall_00499()...
//快速索引函数
public String doCall(int i)
{
 String result；
 switch(i)
 {
  case 0：result＝doCall_00000()；break；
  case 1：result＝doCall_00001()；break；
  //...
  default：result＝＂Bad Index.＂；
 }；//switch
 return(result)；
}；//doCall
public 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)；
        <!-- SIPO <DP n="25"> -->
        <dp n="d25"/>
  }；
  //...
 }；//doProcess()
 public static void main(String[]args)
 {
  BillingTest billingTest＝new BillingTest()；
  billingTest.invokedStandalone＝true；
  billingTest.doProcess()；
 }；//main(...)
}

Claims

1.一种为多个用户提供通信业务的系统，包括：

耦合到多个用户的业务承载传输网；

一个或多个业务处理器，其控制传输网为多个用户执行业务，生成与业务执行相关的事件记录，并且在事件记录中加入用于处理已记录事件的一个或多个指令；以及

一个或多个记录处理器，其从业务处理器接收事件记录，提取用于处理已记录事件的指令，并且使用从中获得的指令处理事件记录。

2.如权利要求1的系统，还包括：

为业务处理器分配用于处理已记录事件的指令的网络管理系统。

3.如权利要求2的系统，还包括：

业务开发环境，其中创建用于处理记录的指令并且发送到网络管理系统以便分配到业务处理器。

4.如权利要求1的系统，其中所述指令是JAVA字节代码形式的可执行代码。

5.如权利要求1的系统，其中所述指令是小应用程序形式的可执行代码。

6.如权利要求1的系统，其中所述指令是servlet形式的可执行代码。

7.如权利要求1的系统，其中所述指令是JAVA BEANS形式的可执行代码。

8.如权利要求1的系统，其中所述指令是串行软件对象形式的可执行代码。

9.一种为多个用户提供通信业务的系统，包括：

耦合到多个用户的业务承载传输网；

一个或多个业务处理器，其控制传输网为多个用户执行业务，生成与业务执行相关的事件记录，并且将事件记录转换为可执行文件；以及

从业务处理器接收所述可执行文件并且通过执行所述可执行文件完成事件记录处理的一个或多个记录处理器。

10.如权利要求9的系统，其中所述指令是JAVA字节代码形式的可执行代码。

11.如权利要求9的系统，其中所述指令是小应用程序形式的可执行代码。

12.如权利要求9的系统，其中所述指令是servlet形式的可执行代码。

13.如权利要求9的系统，其中所述指令是JAVA BEANS形式的可执行代码。

14.如权利要求9的系统，其中所述指令是串行软件对象形式的可执行代码。

15.一种在通信网中提供业务的方法，其中多个用户耦合到由一个或多个业务处理器控制的传输网上，所述方法包括步骤：

从业务处理器生成表示业务处理事件的事件记录；

将事件记录转换为可执行文件；

将事件记录以可执行文件形式发送到记录处理器；以及

在记录处理器中执行所述可执行文件以便完成事件记录的处理。

16.一种在通信网中提供业务的方法，其中多个用户耦合到由一个或多个业务处理器控制的传输网上，所述方法包括步骤：

从业务处理器生成表示业务处理事件的事件记录；

在事件记录中加入一个或多个指令以便供记录处理器在处理事件记录时使用；

将事件记录转换为可执行文件；

将事件记录以可执行文件形式发送到记录处理器；

从事件记录中将指令提取到记录处理器的运行时处理环境中；

在记录处理器中执行从事件记录中提取的指令以便处理其中记录的事件；以及

依据事件记录中发送的事件而从记录处理器中输出执行指令的结果。

17.如权利要求16的方法，还包括将指令从网络管理系统分配到一个或多个业务处理器的步骤。

18.如权利要求17的方法，还包括在业务开发环境中开发所述方法并且将开发的方法分配到网络管理系统以便分配给业务处理器的步骤。

19.如权利要求16的方法，其中基于记录中已有的事件类型选择性地完成到事件记录的方法的增加。

20.一种用于处理在通信系统的业务处理期间发生的事件的方法，所述方法包括步骤：

创建在业务处理期间发生的事件记录；

向事件记录中加入一个或多个处理方法；

将包括处理方法的事件记录传送到记录处理器；

从事件记录中将处理方法提取到记录处理器的存储器中；

在记录处理器中应用处理方法来处理事件记录中记录的事件；以及

输出对事件记录中记录的事件应用处理方法的记录处理器的结果。

21.如权利要求20的方法，其中基于事件记录中存在的事件类型选择性地完成每个处理方法的加入。

22.如权利要求20的方法，还包括根据后续的事件记录而在与记录处理器相关的永久存储器中保留处理方法的步骤。

23.一种用于表示在通信系统中业务处理期间发生的事件的业务处理事件记录，包括：

描述在通信系统中发生的业务处理的一个或多个事件数据；

描述记录处理器如何处理业务处理事件记录中的事件数据的一个或多个处理方法。

24.如权利要求23的业务处理事件记录，其中所述事件数据以处理方法调用的形式存在于业务处理事件记录中。

25.如权利要求23的系统，其中所述处理方法采用JAVA字节代码形式。

26.如权利要求23的系统，其中所述处理方法采用小应用程序形式。

27.如权利要求23的系统，其中所述处理方法采用servlet形式。

28.如权利要求23的系统，其中所述处理方法采用JAVA BEANS形式。

29.如权利要求23的系统，其中所述处理方法采用串行软件对象形式。

30.一种用于处理由通信系统生成的可解释文件的记录处理器，所述可解释文件包括方法以及记录的业务处理事件，所述记录处理器包括：

包括存储空间的通用处理环境；以及

解释程序/加载程序，其接收和解析可解释文件，将方法加载到所述存储空间，并且通过在通用处理环境中执行加载的方法来处理可解释文件中记录的业务处理事件。

31.如权利要求30的记录处理器，还包括方法的永久存储库以及记录处理所需的数据。

32.如权利要求31的记录处理器，其中从可解释文件中获得的一个或多个方法被上载到所述永久存储库中。

33.如权利要求32的记录处理器，其中所述方法被响应于可解释文件中的指示器选择性地上载到所述永久存储库中。

34.一种用于控制通信网向耦合到所述网络的用户提供业务的业务处理器，所述业务处理器包括：

至少一个会话处理器，其执行业务逻辑并且生成原始会话处理事件；

至少一个事件捆绑器，其从会话处理器采集原始会话处理事件并且组装事件集合；

至少一个小代码编制器，其接收来自事件捆绑器的事件集合并且加入方法以形成小代码；以及

至少一个调度程序，其接收来自小代码编制器的小代码，创建相应的可解释文件，并且将可解释文件发送到记录处理器。

35.如权利要求34的业务处理器，还包括事件捆绑策略函数，其控制事件捆绑器聚集原始业务处理事件、过滤某些类型的事件、以及发送事件集合的方式。

36.如权利要求34的业务处理器，还包括小代码建立策略，其控制小代码编制器如何处理事件集合以及加入方法以便创建小代码。

37.如权利要求34的业务处理器，还包括调度策略函数，其控制来自小代码的可解释文件的形成并且控制如何将可解释文件发送到记录处理器。

38.一种用于管理将来自生成业务处理事件记录的通信系统的指令分配到记录处理器的方法，包括步骤：

向业务处理事件记录加入指令以便形成可解释文件；

识别哪些指令要由记录处理器保留；

指定可解释文件中哪些指令要由记录处理器保留；

将可解释文件传送到记录处理器；以及

将已经指定要保留的那些指令上载到记录处理器的永久存储器中。