在智能网络中提供实时呼叫处理服务的方法和装置的制作方法

专利名称：在智能网络中提供实时呼叫处理服务的方法和装置的制作方法
技术领域：
本发明一般涉及为提供通信服务的智能网络系统，具体说，涉及一种新颖的服务控制系统，用于在整个智能网络中分布的多个服务接点的每一个上提供实时事件处理服务。
网络服务是由通信网络诸如数据和电话网络以及它的相关的资源响应与一个或者多个用户的交互作用执行的一种功能。例如，用户可以通过拨一个特殊的数字序列调用电话网络驻留服务，诸如呼叫转移或话音邮箱。其它的网络服务可以指向帮助网络所有者实现网络安全、验证、和鉴别。增加或修改一种服务需要改变通信网络。
最方便的远程通信网络是由相互连接的交换机和通信服务组成的。这些交换机由集成的或者嵌入的处理器控制，而处理器由交换机设计者设计的专用软件或固件操作。通常，交换机制造商的软件或固件必须支持服务处理、呼叫处理、设备处理和网络管理的所有功能方面。这意味着当网络所有者希望实现一个新的服务或者修改现有服务时，必须由各交换机制造商修改网络中的每一个交换机的软件。
网络包括由不同制造商生产的不同交换机模型的这一事实需要仔细开发、测试、和开通新软件。开发、测试、和开通新软件需要的时间被延长，因为随着现在的每一次修改，在每一交换机上的代码大小增加的更大也更复杂。这样，这一处理可能要几年。另外，这种增加的复杂性给交换机处理器增加了负担，增加了交换机误动作的机会，和可能需要修改或更换交换机。
此外，多个网络所有者依赖于一组公共的交换机制造商这一事实导致限制竞争这样的不希望的情形。首先，一个制造商的软件发布可能试图结合由几个网络所有者请求的改变，这样，阻止了这些网络所有者提供与其竞争者提供的服务真正不同的服务。这也逼迫一些网络所有者等待制造商把来自其他网络所有者的请求结合到新的发布中。第二，结合由一个网络所有者请求的功能以实现一种新服务的交换机软件发布可能无意变成可访问其他网络所有者。
随着在过去五到十年期间由于用户移动性的增加、各种通信和带宽的增加、传统编号方案的分离、更复杂的服务和增加的竞争，而对新网络服务要求的增加，这些问题变得不能容忍。因此，广泛承认需要新网络结构来结合建立、开通和执行服务逻辑的更灵活的方式。为充分理解以下说明的本发明的新颖结构，下面参考

图1提供对相关现有技术的说明。
参考图1，其中表示出包括本发明的各种交换结构的一种逻辑表示。总体用20表示的整体交换机包括服务处理功能22、呼叫处理功能24、设备处理功能26和交换机结构28。所有这些功能22、24、26和28都是硬编码、混合的和不可区分的，其用组30表示。此外，功能22、24、26和28由交换机制造商设计，并在随不同制造商而不同的专用平台上运行。其结果，只有在制造商的帮助下才可以修改这些功能22、24、26和28，这将减慢服务开发和实现，增加带给市场新服务的成本。因此，新的和革新的服务的开发、呼叫处理、数据处理、信号处理和网络操作受制造商对其专用交换机硬件和软件的控制限制，对建立和实现工业标准存在固有的困难。
服务处理功能22在整体交换机20中编码并只允许基于本地数据内容和所拨的号码本地控制这一处理。这一本地信息由一个执行编码服务功能的硬编码处理引擎解释。呼叫处理功能24被硬编码，它提供呼叫启动和呼叫终止功能。这一处理实际上建立和拆除单个连接来完成呼叫。类似地，设备处理功能26也是硬编码，它提供涉及在一次呼叫中所包括的物理资源的所有数据处理。交换机结构28表示交换机和计算机的硬件部件以运行由交换机制造商，诸如北方电信公司，提供的整体软件。交换机结构28提供为建立连接所必需的物理设施，可以包括，但不限于，机架设备(T1和DSO的)、交换矩阵设备(网络平面及其处理器)、连接层信号处理器(SS7，MTP，ISDN，LAPD)和特殊电路(会议端口，音调检测器)。
为试图解决先前说明的问题，国际通信联盟和欧洲通信标准协会批准了ITU-T智能网络标准(“IN”)。类似地，Bellcore批准了高级智能网络标准(“AIN”)。虽然这两个标准在表示和发展状态上不同，但是它们具有几乎相同的目的和基本概念。因此，这两个标准被视为一个单一的网络结构，其中服务处理功能22从交换机分开。
使用IN和AIN结构，网络所有者大致可以通过建立和开发一个新的服务逻辑程序(“SLP”)来推出一种新服务，其基本是一个与服务独立的创建块(“SIBB”)表，它在给定类型的呼叫时被调用。根据这一方法，一些专门的元件类型互操作与SLP结合来给网络用户提供服务。其结果，任何新的或可能的服务将由现有SIBB限制。
用40总体指示的IN或AIN结构逻辑上分开整体交换机20的功能为一个服务控制点(“SCP”)42及一个服务交换点(“SSP”)和交换系统44。SCP42包括服务处理功能22，而SSP和交换系统44包括呼叫处理功能24、设备处理功能26和交换机结构28。在这种场合，呼叫处理功能24、设备处理功能26和交换机结构28硬编码的、混合的和不可区分的，其由组46指示。
服务交换点(“SSP”)是一个功能模块，它驻留在交换机内以便仅根据所拨号码识别一个用户的信令何时需要多于一个路由。SSP在其对远程SCP42启动为改正呼叫处理的查询时暂停对该呼叫的进一步处理，SCP42基本上用作一个交换机的号码的数据库服务器。处理的这一分开导致处理特殊服务呼叫的不经常的、但是耗时的任务从交换机卸载。此外，这一适度的集中在使一个容易修改的、重负载资源服务于整个网络和对给每一交换机开通一个完整的拷贝之间划定一个平衡。
现在参考图2，图中表示使用一个IN或AIN结构的远程通信系统的示意图，其用50总体指示。各种用户系统，诸如ISDN终端52、第一电话54、第二电话56连接到SSP和交换系统44。ISDN终端52通过信令线60和传输线62连接到SSP和交换系统44。第一电话54通过传输线64连接到SSP和交换系统44。第二电话56通过传输线68连接到远程交换系统66，而远程交换系统66通过传输线70连接到SSP和交换系统44。
如在前面参考图1所说明的，SSP70是一个功能模块，它驻留在交换机中以便根据所拨号码识别一个用户的信令何时需要多于一个路由。SSP70在其启动为正确处理呼叫的询问时暂停对该呼叫的进一步处理。这一询问以SS7信令的形式发送到远程SCP42。服务控制点42是这样命名的，因为在这一位置改变数据库的内容可以改变对通过许多分支交换机连接的用户显现的网络功能。该询问通过信令线72发送到信号传输点(“STP”)74，它只是为在这些元件之间发送SS7消息的路由器，然后通过信令线76到SCP42。
综合服务管理系统(“ISMS”)78被认为是一个管理工具，以开通或改变服务或者管理每一用户对服务的访问。ISMS78主要通过改变操作逻辑和存储在SSP70和SCP42中的数据操作。ISMS78具有各种用户接口80和82。该ISMS78通过操作线84连接到SCP42，通过操作线86连接到SSP和交换系统44，和通过操作线90连接到智能外围设备(“IP”)88。智能外围设备88是用于给网络增加在交换机上不可用的功能的设备，诸如话音响应或语音识别系统。IP88通过线92和传输线94连接到SSP和交换系统44。
现在参考图2说明按照现有技术的呼叫处理。当用户拿起接收器并开始拨号时启动呼叫。在公司交换机上的SSP70监视拨号并识别触发器顺序。SSP70暂停对该呼叫的进一步处理，直到可以查询服务逻辑。然后SSP70组成一个标准的SS7消息，并将其通过STP74发送到SCP42。SCP42接收并解码该消息并调用SLP。SLI解释SCP，它可能为驱动其它功能诸如为号码转换的数据库查阅调用。SCP42给SSP和交换系统44返回一个有关该呼叫处理的SS7消息，不然的话给网络单元发送消息以执行正确的服务。在呼叫结束时在交换机之间发送一个SS7消息以拆除该呼叫，并由在该呼叫中所涉及的每一交换机产生一个呼叫详情记录。呼叫详情记录为每一个呼叫被收集、相关、并脱机分解，以便为收费呼叫导出账单，从而完成呼叫处理。
IN和AIN结构试图预先定义一个标准功能集以支持所有可预见的服务。这些标准功能都被硬编码入交换机中的各个状态机中。不幸的是，可能结合新技术和未预见服务而产生的任何新功能不可能不在许多销售商的平台上对网络软件进行广泛的检查和测试而实现。此外，如果一个新功能需要改变标准化的呼叫模型、协议、或接口的话，则使用该功能的服务的实现可能被推迟，直到由一个工业标准组批准这些改变。但是，即使作为草订的标准试图扩宽IN和AIN支持的功能，可是设备提供商拒绝批准这些草订的标准，因为编码复杂性的巨大增加。
进一步观看图2，使呼叫处理和设备处理功能亦即SSP70在该交换机内操作产生IN和AIN结构的其它限制。其结果，这些功能必须由每一交换机制造商使用他们的专用软件提供。因此，网络所有者仍然极大依赖于制造商软件的发布来支持新功能。为使事情进一步复杂化，网络所有者不能在统一的开发和测试环境下结合其它模块测试SSP70模块。此外，不能保证打算用于一个交换机制造商的处理环境的SSP70与网络所有者的服务建立环境兼容。
这种多个网络所有者对交换机制造商的一个公共集合的依赖性导致两种限制竞争的不希望的情形。首先，一个制造商的软件发布可能试图结合由几个网络所有者请求的改变，从而阻止网络所有者使其服务与由他们的竞争对手提供的服务分开。这也迫使某些网络所有者等待，直到制造商结合其他网络所有者的请求到新发布中。第二，结合由一个网络所有者请求的功能的交换机软件发布以实现一种新服务可能不经意为其他网络所有者访问。因此，不管IN和AIN结构的意图，网络所有者建立、测试和开发新服务仍然因为网络所有者不能完全控制或访问塑造网络服务行为的功能元件而受阻。
在另一种试图解决这些问题的方案中，一个单独的交换机智能和交换机结构(“SSI/SF“)构造(其总体用150(图1)指示)逻辑上把SSP70从交换系统44分开。现在回过来参考图1，交换机智能152包括呼叫处理24和设备处理功能26，其以相应的硬编码状态机引擎编码到离散的状态表内，这些状态机引擎用圆圈154和156表示。在交换机结构功能158和交换机智能功能152之间的接口可以通过一个通信网络扩展，使得交换机结构158和交换机智能152可以不必在物理上位于一起，通过在同一处理器内执行，或甚至具有一对一的对应。随之，交换机智能152提供一个对所有交换机公共的、简单的非服务特定、非制造商特定功能的一致接口。
一个综合智能计算设备(“ICC”)160包括服务处理功能22，其与多个交换机智能元件52通信。这一方法提供网络所有者灵活实现服务的优点，因为除最基本的功能外所有功能都移到制造商特定代码的范围之外。可以通过为建立、开发、测试和执行服务逻辑提供更统一的环境实现进一步的改善。
如前所述，当前网络交换机基于整体专用硬件和软件。虽然网络交换机可能值数百万美元，但是这种设备在从当前可用的计算技术看来其处理速度较慢。例如，这些交换机基于运行在60MHz范围的精简指令集计算(“RISC”)处理器，使用诸如X.25数据通信协议与每一其它交换机通信，X.25协议通常支持在一个交换网络中的各种平台之间9.6kb/s的传输速率。当这与包括运行在200MHz或更高的处理器的个人计算机和提供150Mb/s和ATM接口的高端计算机工作站比较极慢。因此，网络所有者需要能够使用高端工作站来代替专用硬件。
本发明指向一种服务控制系统，用于提供实时服务处理在一个资源集合设备例如交换机和路由器上接收到的所有事件和服务请求，这些资源集合设备物理上与一个智能通信网络的多个分布的服务节点的每一个关联。
一般来说，本发明的服务控制部件在进行服务请求处理时能够命令智能网络资源集合设备，例如ATM交换机、因特网网关、智能外设、或者其它交换机或路由器资源，并进一步包括为处理这些服务请求所需要的智能。特别说，嵌入的智能能使服务控制部件与其它智能网络部件交互作用来访问另外的逻辑部件或获取为处理一个服务逻辑事件所需要的信息(服务或用户数据)。服务控制在实时服务处理期间连接资源集合设备和本地数据管理系统并与之交互，并具有为处理智能网络提供的服务尝试所需要的逻辑和处理能力。服务控制由服务管理员和智能网络的数据管理部件管理、更新和操纵。智能网络独立于其内接收到呼叫的呼叫交换平台或资源集合设备并对其透明地提供智能呼叫处理服务，并容易适应处理呼叫事件。这样，消除了对昂贵的、销售商特定的硬件、操作系统和交换平台的依赖。分布的智能网络另外支持与位置无关的事件处理服务执行，允许模块软件逻辑程序在结构中任何地方虚拟运行，并在这些分布的处理器之间提供与位置无关的通信，从而进一步消除了对专门服务节点的需要。
更特别的是，本发明控制当由资源集合设备给服务控制部件发送一个服务请求时开始的一个或者多个进程。服务控制与其它部件交互作用来访问提供所请求的服务必需的数据。当所请求的服务行为序列完成或当服务用户撤回使用该服务时，该进程完成。在服务代表请求的服务请求者中涉及的所有资源在处理结束时释放。每一服务请求启动服务处理的一个实例(线程)，从而提供大量并行处理而很少意外事故或瓶颈。
优选每一服务线程实例维持它自己的事件队列，同时服务控制为一个特定呼叫实例对接收到的事件提供异步通道到适当的服务线程队列来按照与该事件关联的预先决定的优先级为其存储和执行。服务控制另外给事件提供异步通道到交换机/资源集合设备、或其它执行服务逻辑程序，同时该线程实例在其等待响应时闭锁。
根据本发明，服务控制部件的主要责任包括接收和处理来自一个交换平台或其它外部资源的事件或请求；识别和调用服务逻辑程序以处理到来的请求；从数据管理存储设备通过网络操作系统(NOS)或直接通过一个数据库应用程序接口(API)请求服务或用户相关的数据；通过NOS对数据管理部件更新服务或用户相关的数据；提供给资源集合设备和其它服务逻辑程序发送优先的事件和消息以控制用户交互反应的能力；从资源集合设备接收包括用户输入的消息集合，例如相应于一个选择菜单项等的PIN、(双音调多频率)DTMF数字；维护在服务处理的同一实例中包括的所有参加者的状态和数据；和产生帐单记录并传输它们到数据管理部件的帐单记录产生功能。
作为本发明特征的新颖性的各种特征特别在附在本公开后面并形成本公开一部分的权利要求中指出。为更好理解本发明、其操作优点，和由其使用得到的特定的目的，必须参考附图和说明性的事项，其中图示和说明了本发明的优选的实施例。
本发明的上述以及其它优点通过参考下面的说明并结合附图可以更好地理解，附图中图1是各种交换结构的逻辑表示；图2是使用按照现有技术的一个典型的智能网络结构的通信系统的示意图；图3是使用智能分布式网络结构的通信系统的示意图；图4(a)是一个方框图，表示下一代智能网络的SA和DM部件；图4(b)概念表示服务操纵部件300的功能；图4(c)表示数据管理部件400的功能结构；图5是使用按照本发明的智能分布式网络结构的通信系统的逻辑和功能示意图；图6是一个示意图，表示在按照本发明的一个智能呼叫处理器内的功能接口的分层；图7是一个示意图，表示在按照本发明的一个智能呼叫处理器内的被管理对象的类层次；图8表示服务控制环境430的一个优选的结构；图9表示NOS NT和LRN功能子部件的功能结构；图10表示用于智能网络的资源管理系统的结构；图11(a)和11(b)表示3层智能网络资源管理功能；图12(a)表示SLEE起动处理；图12(b)表示服务管理器处理；图12(c)表示SLEE类加载器处理；图12(d)到12(e)表示说明服务代理功能的流程图；图12(f)表示线程管理器处理；图12(g)表示服务代理后事件处理；图13(a)到13(c)表示为执行1-800/8xx呼叫处理服务的示例处理流程；图14表示一个由IDNA/NGIN服务的呼叫处理方案。
本发明是综合智能网络的一个部件，该综合智能网络在这里特称为智能分布式网络结构(“IDNA”)或下一代智能网络(“NGIN”)。正如这里说明的，设计NGIN结构是为在资源集合设备或交换平台例如交换机、路由器、IP结束地址等处接收到的任何类型的呼叫执行智能呼叫处理服务。IDNA/NGIN优选包括多个分布的服务节点，每一节点提供一个执行环境，提供为处理在与该特别服务节点物理关联的交换机或资源集合设备处接收到的实例中的呼叫必需的呼叫处理功能。NGIN具有高伸缩结构，设计为保证可执行服务对象作为独立服务逻辑程序(“SLP”)实施，和为执行事件服务例如1-800电话呼叫、发送传真的关联的数据可以在服务节点处以成本高效的方式调度和维护。通过使用遵从CORBA的对象请求代理人技术，该智能网络独立于接收到一个事件或呼叫的事件交换平台或资源集合设备并对其透明地支持位置和与平台无关的呼叫处理服务执行，并允许高级逻辑程序独立于该服务执行平台在网络中的任何地方虚拟运行。此外，该系统提供在这些分布式处理之间的与位置无关的通信。
现在参考图1，智能分布式网络结构(“IDNA”)总体用170指示。本发明集成ICC 160和SSI/SF结构150的交换机智能152到一个智能呼叫处理器(“ICP”)172中。不像其功能在状态表中定义的SSI/SF结构40的IN或AIN，ICP172包括服务控制功能22、呼叫处理功能24和设备处理功能26作为在一个面向对象的平台内管理的对象，其分别用方框174、176和178指示。ICP172逻辑上与资源集合设备180分开。
现在参考图3，说明使用按照本发明的智能分布式网络结构的一个通信系统，其总体用200指示。广域网(“WAN”)202是一个支持应用和数据在广阔的地理区域上分布的系统。传输网络基于同步光学网络(“SONET”)和连接IDNA节点204，并允许在这些节点内的应用彼此通信。
每一个IDNA节点包括一个智能呼叫处理器(“ICP”)172和一个资源集合设备180(图1)。图3表示具有一个资源集合设备A(“RCA”)206和一个资源集合设备B(“RCB”)208的IDNA节点204。该ICP可以连接到附属处理器210，其提供现有支持功能，诸如提供(provisioning)、开帐单和恢复，然而，这些功能可以通过由一个网络管理系统(“NMS”)212提供的功能吸收。不过，在该优选的实施例中，这些支持功能可以由一个集中的服务管理(“SA”)系统500提供，该系统500具有数据管理(“DM”)部件400，其将在这里参考图4(a)说明。如在图3中进一步表示，ICP172也可以通过一条具有信令216的直接连接214和承载连接218连接到其它ICP′172、其它网络(未示出)、或其它设备(未示出)。直接连接防止了在连接的设备之间的延迟并允许这些设备以它们自己的语言通信。ICP172是IDNA节点204的“大脑”并优选是通用计算机，其可以在具有单存储器存储设备的一个单处理器到一个大型计算机网络中变化，取决于IDNA节点204的处理需求。优选，通用计算机具有冗余处理、存储器存储和连接。
这里，通用计算机指的是商业上现成的部件或用其组装的计算机，其与为电话交换应用专门配制和设计的专用设备相对。通用计算机在呼叫网络中的集成提供很多优点。
通用计算机的使用给ICP172使用附加硬件扩展的能力以满足增加的处理需求。这些附加包括增加处理功率、数据存储、和通信带宽的能力。这些附加不需要修改在呼叫网络中每一交换机上的制造商特定的软件和/或硬件。因此，可以在总体规模上实现和安装新服务和协议，不需要修改交换网络中的单个设备。通过改变整体交换机20(图1)为智能呼叫处理器172，本发明提供前述优点和增加的能力。
在需要更大处理能力的应用的场合，多处理允许使用较少贵重的处理器来优化呼叫处理的价格/性能比。在其它应用中，必须或更成本高效地使用多个具有更高处理速率的大功率机器，诸如小型机，可能有利。
如上所述，ICP172可以包括一簇运行在例如UNIX或Windows NT操作系统下的通用计算机。例如，在一个大的应用中，支持在单一资源集合设备上直到100,000端口，ICP172可以由16个以对称多处理器级连的以333MHz运行的32位的处理器组成。这些处理情况可以例如分成4个单独的服务器，每一个具有4个处理器。单个处理器将与一个系统区域网络(“SAN”)连接或其它级连技术连接。处理器簇可以共享对独立磁盘冗余阵列(“RAID”)模块数据存储设备的访问。可以通过增加或去除模块化的磁盘存储设备调节共享存储器。级连中的服务器优选共享对RC180的冗余连接(图1)。
如所说明的和类似计算机的“即插即用”特征，ICP软件结构是一个开放的处理模型，它允许(1)管理软件；(2)ICP应用(3)计算硬件和软件；(4)资源集合设备部件；和甚至(5)服务结构和处理的可互换性。这种类结构由于标准化而减少维护成本和提供从规模的经济性产生的好处。
这样，本发明能分割开发工作和使用模块化工具，这会导致更快开发和实现服务。此外，服务管理的使用及其相关方面在按需的基础上在网络操作员的控制内，其与由固定消息发送协议或由给定制造商供应的硬件和软件的特定组合施加的限制相反。
通过使用被管理对象，本发明还允许服务和功能灵活地(“在你希望它的地方”)和动态地(“随意地”)根据任何数目的因素，诸如容量和用途在网络内分布。因为服务处理22(图1)、呼叫处理24(图1)和设备处理26(图1)在一个同种的平台上操作，因此性能得以改善。另外，本发明允许监视和操纵以前不能访问的呼叫子元件。本发明还提供监视功能或服务的使用使得当它们过期或未使用时可以将其删除。
资源集合设备(“RC”)180(图1)是提供载体、信令和连接服务的物理设备或资源的集合。可以包括智能外设88的RC180替换IN或AIN或SSI/SF结构的交换机结构28和158(图1)。不像IN或AIN结构，诸如RCA206的资源集合设备的控制处在更低级。此外，RCA206可以包括多于一个交换机结构158。交换机结构158或其它用户接口(未示出)通过标准的电话连接连接众多用户和交换网络。这些用户系统可以包括ISDN终端52、传真机220、电话54、和PBX系统222。ICP172通过一条高速数据通信管线(最小100Mb/秒以太连接)224控制RC180(图1)、RCA206和RCB208并与之通信。RC180、206和208可以模拟为一个打印机，而ICP172可以模拟为一个个人计算机，其中，个人计算机使用一个驱动器以控制该打印机。在IDNA节点204中的“驱动器”是一个资源集合设备代理(“RCP”)(未示出)，其在下面参考图5说明。这允许制造商使用这一接口提供一个遵从IDNA的节点而无需重写他们所有的软件以结合IDNA模型。
另外，资源集合设备180(图1)、RCA206和RCB208的控制位于比由AIN或IN结构通常提供的较低级。其结果，资源集合设备制造商只需提供单一接口以支持设备和网络管理处理；他们不必提供网络所有者专门的呼叫和服务处理。低级接口被抽象到更离散的操作中。具有单一接口允许网络所有者根据价格和性能的决定从众多的资源集合设备制造商中选择。智能加到ICP172，而不是RC180，它使RC180从改变中分离并减少其复杂性。因为RC180的作用被简化，更容易实现改变，从而使其较容易迁移到另外可选用的交换和传输技术，诸如异步传输方式(“ATM”)。
智能外设(“IP”)88提供处理和执行在实际呼叫传输路径内包含的信息行动的能力。IP88通常在一个单独的资源集合设备诸如RCB208内，并以和RCA206相似的方式由ICP172控制。IP可以提供使用数字信号处理(“DSP”)技术实时处理在实际传输路径内的数据的能力。
使用网络管理系统(“NMS”)212来监视和控制在IDNA网络200中的硬件和服务。建议的NMS212实现可以是一个遵从通信管理网络(“TMN”)的架构，其提供在IDNA网络200中的部件的管理。更具体说，NMS212控制服务的开通，维护这些服务的正常状态，提供关于这些服务的信息，和为IDNA网络200提供网络级管理功能。NMS212通过在IDNA节点204中的代理功能访问和控制服务和硬件。在IDNA节点204中的ICP-NMS代理(未示出)执行由NMS212发布的命令和请求。NMS212可以通过一个标准操作连接226直接监视和控制RCA206和RCB208。
如图3中进一步表示，被管理对象生成环境(“MOCE”)228包括子部件以产生在IDNA网络中运行的服务。服务设计者使用来产生新服务的服务独立的建立块和API表示植入MOCE的基本子部件，一个图形用户接口(“GUI”)中。MOCE是存在于单一用户环境或平台上的工具的统一集合，另外可称为服务建立(“SC”)环境。它表示在服务建立处理中需要的操作的集合，诸如包含在被管理对象中的服务文献、被管理对象定义、接口定义、协议定义和数据输入定义，和服务测试。网络所有者只需使用MOCE228开发服务一次，因为被管理对象可以应用于它的网络上的所有节点。这与网络所有者使每一不同的交换机制造商开发他们的服务版本形成对比，后者意味着服务必须多次开发。
MOCE228和NMS212通过一个注册表(repository)230连接在一起。注册表230包含被管理的对象，后者由NMS212分发并用于IDNA/NGIN节点204中。注册表230还提供在MOCE228和NMS212之间的一个缓冲器。然而，MOCE228可以直接连接到NMS212以执行“活的”网络测试，其由虚线232指示。
根据本发明示于图4(a)的一个优选的实施例，IDNA/NGIN系统包括一个集中的服务管理(“SA”)部件500，它连同增加的能力既提供存储器(注册表)230功能又提供IDNA系统170的类网络管理(NMS)212功能。一般说来，示于图4(a)的SA部件500支持脱机存储、命名、分布、激活和去除为该IDNA/NGIN系统的所有服务和数据，以及另外提供数据管理(“DM”)功能，允许运行时对由在IDNA/NGIN服务节点中的服务对象使用的数据存储、复制、同步、和可用性。
更特别的是，如在图4(b)中概念性表示，服务管理部件500是执行为管理、存储、和分布所有服务和由IDNA服务处理节点使用的服务数据并为配置在该系统IDNA/NGIN中实现的硬件和软件两者所需要的所有功能。一般说来，如图4(b)所示，SA部件500负责从MOCE(服务建立)228接收数据，从命令入口和其它传统(legency)系统229接收用户命令数据以提供IDNA/NGIN系统为用户使用；例如在服务处理期间由MOCE/SCE用户请求，部署数据、服务独立的建立块(“SIBB”)、服务逻辑程序(“SLP”)和其它服务逻辑部件503例如给MOCE200；从MOCE228接收完成的和测试的服务组件、SIBB、SLP或其它服务逻辑或数据部件506；给每一服务部件提供唯一的名字；和给数据管理功能部件600分发数据和每一服务部件509，其在这里较详细说明。另外，如图4(a)所示，服务管理300维护注册表230，它包括包含所有IDNA服务和数据的记录的综合数据库(“DBOR”)，从中数据管理部件600接收它所有的数据。
服务管理的其它责任包括激活数据和服务部件512以保证所有数据、SIBB和被管理对象或服务逻辑程序SLP通过数据管理部件600为节点可用；通过将其逻辑名字供给网络操作系统(“NOS”)部件700登记数据、SLP和SIBB515的名字，下面详细说明，用于以其注册；去激活数据和服务部件518；和从IDNA/NGIN系统通过数据管理部件600去除数据和服务部件518。服务管理在其通过它的命名处理描述之外另外通过维护每一SIBB的状态和服务(预测试，后测试，部署等)执行配置管理功能。这能保证服务在该服务的所有部件未成功测试和配置之前不能部署。
图4(b)中进一步表示，服务管理部件500另外按照SA接收到的配置信息执行配置和提供(provisioning)IDNA/NGIN服务节点204。特别是，SA部件500根据接收到的配置信息决定在每一服务节点204上的每一部件的性能，哪一个服务和数据要分配给哪一个节点，哪一个服务要在该服务节点驻留的服务器上运行，和哪一个数据要被高速缓冲存储到与IDNA/NGIN节点服务器关联驻留的本地存储器中。特别，SA部署在服务简档(配置)文件580中包含的配置规则到NOS系统700的本地(节点)资源管理器(“LRM”)部件575为存储到位于每一服务节点处的本地LRM高速缓冲存储器中。这些配置文件580决定哪一个服务在某个IDNA节点上执行。LRM首先读取存储在该节点处的本地高速缓冲存储器中的这一服务简档，并决定一个专门的服务层执行环境(“SLEE”)，例如，一个虚拟机，来根据在服务简档中的规则运行该服务和哪些服务要在SLEE中活动运行(作为持续的对象)，或仅在需要时说明。
回过来参考图4(a)，NGIN数据管理部件600既在服务生命周期中也在服务使用能力中作用。在服务管理部件维护记录的综合数据库(注册表)的地方，数据管理部件600为每一IDNA/NGIN服务节点提供本地数据存储和数据管理功能。这包括所有类型的数据，包括服务程序和SIBB、用于服务的数据(用户简档，电话号码等)多媒体文件(诸如为交互声音应答(“IVR”)服务的音频文件)等。特别，一个服务节点的数据管理部件600接收SA综合DBOR的摘要，包括为由服务管理指定的本地NGIN服务节点执行的服务所需要的所有数据。下面相对于图4(c)详细说明它的机制。
在优选的实施例中，SA部件的数据管理部件600为每一IDNA/NGIN服务节点提供本地数据存储和管理功能。特别，数据管理存储从服务管理接收到的数据到一个或者多个数据库，并通过高速缓冲存储需要的数据到驻留在服务控制计算机内的存储器中或在一个并存的数据库服务器中使得服务/数据可以以最小延迟提供给服务控制服务，使服务/数据容易为服务控制环境使用。更一般说，数据管理部件600在从服务管理接收到或作为服务处理结果接收到数据的场合执行数据的实时存储、复制、同步和可用性。这些DM功能可以进一步归类为1)数据仓储功能；2)数据操纵功能；3)数据使用功能；4)帐单记录产生功能。
现在参考图5，说明使用根据本发明的一个智能分布式网络结构200的通信系统的逻辑和功能示意图。所示ICP172包括一个ICP-NMS代理240和一个SLEE242，它依次容纳从被管理对象基类244导出的多种被管理对象246、248、250和252。
一般说来，被管理对象是软件功能包的一个方法，其中，每一被管理对象提供功能和管理两种接口，以实现被管理对象的功能。管理接口控制对谁的访问和什么可以访问被管理对象的功能。在本发明中，由IDNA/NGIN节点204运行的所有电话应用软件，除了基础设施软件，都作为被管理对象和支持库实现。这提供统一的接口和实现来控制和管理IDNA节点软件。
连接、选取路由、和终止由节点处理的载波通信量的网络单元的集合将集中称为资源集合设备180。在SLEE上运行的服务处理应用使用资源代理(“RCP”)244，作为对RC180的控制接口。RCP244可以比做一个设备驱动器，它使来自SLEE中的对象的独立于设备的命令适应要由RC180执行的设备特定的命令。RCP244可以说明为一个实现在该RCP224中的资源的销售商之间公共的基本命令的接口。RCP244可以如所示一个或者多个运行在IDNA节点204上的被管理的对象实现。另外可选的方案是，可以作为RC180的一部分提供这一功能。NMS212、注册表230和MOCE228与图3-5(a)的讨论中的那些元件的说明一致。
注意，操作链路26直接连接NMS212到RC180。这相应于网络管理系统监视网络硬件运行状态的更传统的作用。这可以独立于IDNA结构完成(例如，通过使用著名的TMN方法)。另外，RC180可以连接到其它资源集合设备254。还表示出一个直接的信令连接214进入ICP172，使得信令216，诸如SS7，可以直接进入呼叫处理环境。通过在网络外设截取信令，SS7消息可以直接到ICP172，不通过RC180。这通过缩短路径减少了延迟和改善了结实性。一条伴随的载体线218连接到RC180。
图6表示在ICP172中功能接口的层次。MOCE228是一个产生被管理对象软件及其从属物的系统。NMS212通过接口在ICP172内提供的代理功能，称为ICP-NMS代理240，控制ICP172的执行。NMS212控制在ICP172上的本地操作系统(“LOS”)260的运行。NMS212控制ICP172的运行，包括启动和终止处理；询问处理表的内容和处理的状态；配置操作系统参数；和监视容纳ICP712的通用计算机系统的性能。
NMS212还控制广域网操作系统(“WANOS”)262的运行。NMS212通过它对LOS260的控制和通过由NMS SLEE控制提供的任何其它接口控制WANOS支持处理的运行的初始化和WANOS库配置。NMS212控制运行在ICP172上的一个或者多个SLEE242的实例化和运行。LOS260是一个用于操作通用计算机系统的商业现成的操作系统。WANOS262是一个商业现成的中间件软件包(例如一个对象请求代理程序)，其便利在计算节点之间的无缝通信。SLEE242负责被管理对象244的执行，这些被管理对象是实现服务处理结构的软件实例。SLEE242通过ICP-NMS代理240实现控制被管理对象244执行的手段。这样，SLEE242是这样一种软件处理，它能够部署和清除被管理对象软件、说明和毁坏被管理对象实例、支持被管理对象的交互反应和与被管理对象合作、管理对本机库264的访问、和在实现所需要的控制中与NMS-ICP代理240接口。
本机库264是这样一种库，将其编码使仅依赖于LOS260或者WANOS262和本地通用计算机执行(例如编译的C程序库)。它们主要用于补充由SLEE242提供的本地功能。
SLEE库266是编码在SLEE242内执行的库。它们可以访问由SLEE242提供的功能和本机库264。被管理对象244是由SLEE242加载和执行的软件。它们可以访问由SLEE242提供的功能和SLEE库266(和可能本机库264)。
ICP-NMS代理240给NMS212提供控制ICP172的运行的能力。ICP-NMS代理240实现控制LOS260的运行和配置、WANOS262的允许和配置、和SLEE242的说明和运行的能力。建议的服务处理结构以增加的抽象的层操作。然而，从SLEE242看来，只有两层被管理对象层，它是在NMS212的控制下相互作用的对象层(软件实例)；和库层254或266，它是给被管理对象242或SLEE242自身的运行提供补充功能的软件层(要么对SLEE242是本机的，或者LOS260)。然而，可以预期在某些点，NMS212可以放弃对被管理对象实例的精确位置控制。例如，可以允许被管理对象实例根据一种或者多种算法或事件，诸如响应一个命令，从一个节点迁移到另一节点。
应该理解，集中说，LOS和WANOS功能可以表示为网络操作系统或“NOS”，如图6所示，其功能为在IDNA/NGIN系统部件之间提供与平台无关的和与位置无关的连接性。也就是说，NOS包括一组网络范围的服务，这些服务提供在其它IDNA/NGIN功能部件和子部件之间的处理接口和通信。在由NOS提供的服务中间，有对象连接性、逻辑名转换、处理间通信、和本地和系统范围内的资源管理(“RM”)。例如，如图4(a)所示，NOS部件700提供本地(NODE RM)和系统范围内的资源管理(SYS RM)功能。特别，NOS部件包容来自需要服务和数据的处理的任何服务的位置，以便一个处理只需要调用单一逻辑名。然后NOS部件决定使用哪一个服务实例，和给该实例提供连接。NOS700部分允许IDNA/NGIN广泛分布的性质以及IDNA/NGIN的与平台无关性。例如，前述逻辑程序使用NOS部件700来调用其它逻辑程序，并因此可以调用其它运行在同一服务节点或远程服务节点上的不同的SLEE上运行的逻辑程序。特别，通过SA500，可以指定一个服务节点只执行一定的服务。当到达交换机的一个呼叫具有一个相关的服务节点204，对该节点不能执行所需要的服务时，例如参加一个会议桥(conferencebridge)，IDNA可以需要引导该呼叫到另一个配置为能提供这种服务的节点。优选，IDNA通过NOS部件700在另一远程服务节点调用需要的服务，执行呼叫处理，和响应在原来节点处的交换机提供服务。
现在参考图7，说明按照本发明的被管理对象的类结构。抽象基类被管理对象244包括公共的功能和虚拟功能以保证所有导出的类可以恰当地作为在SLEE242中的对象支持。具体说，表示出4种不同的子类，服务控制类252、呼叫控制类250、载体控制类248、和资源代理类246。
服务控制类252是为所有服务功能对象的基类。对话管理器类280包容与该对话有关的信息和活动。一次对话可以包括一次或多次呼叫或对网络功能的其它调用。对话管理器类280为每次对话提供一个唯一的标识符。如果呼叫处理以节点方式发生，则必须校对帐单信息。为每一呼叫的一个唯一的标识符使校对容易，代替需要代价很高的相关处理。在服务处理中，协议由连续抽象层返转。最终，协议被足够抽象以保证对话管理器的分配/实例化(例如在SS7中，IAM消息的接收将保证具有对话管理)。
载体能力类282改变在载体上的服务的质量。服务控制类252能改变一个呼叫的服务质量(“QoS”)或者甚至改变载体能力，诸如从56千位/秒移动到更高速率，然后返回。QoS由连接管理器类302管理。例如，半速率子类284使一个呼叫的QoS降级到4 KHz的采样速率，而不是通常的8KHz采样速率。立体声子类286可以允许用户在一个呼叫中形成两个连接以支持左通道和右通道。
服务仲裁类288把调停服务冲突和服务交互反应编成典律。这是需要的，因为服务控制类252可以冲突，特别在启动和终止服务时。由于许多实际的理由，不希望在每一服务控制类252中编码知道如何解决与服务控制类252每一其它类型的冲突。而代之以，当出现一个冲突时，把对冲突的服务的参考和它们暂停的请求传送给服务仲裁类288。然后服务仲裁类288可以决定适当的动作过程，或许考虑本地文本、配置数据和对冲突的服务对象随后的询问。具有服务仲裁类288允许明显地记载和编码与硬编码或隐式机构相对的冲突解决算法。此外，当更新或增加一个服务时，不必更新现有服务来考虑任何冲突改变，其可能需要改变在一个单一服务中的多种关系。
特征类209实现与电话关联的能力的标准集合(例如3路呼叫，呼叫等待)。这样的一种能力可以是越权292，它能使始发端断开一个现有的连接以便到达打算的接收者。另一个公共的能力可以包括一个呼叫闭锁294，从而可以根据关于始发的一组判据拒绝始发提供者。
使用服务区分类296在呼叫处理期间有选择的调用其它服务，它并被作为服务自身细分。服务区分类296提供灵活的、对环境敏感的服务激活并避免需要在每一服务对象内具有固定的代码来决定何时激活该服务。激活顺序从服务自身分开。例如，用户A和用户B访问同一组特征。用户A选择使用一个特定组的信号有选择地调用一个或者多个他的服务。用户B喜欢使用不同组信号来激活他的服务。这些用户之间的仅有的差别是它们激活他们的服务的方式。于是，希望从服务自身分开选择处理。有两种可用的解决方案。对于用户A和B的服务选择处理可以在单独的服务区分类296中编码，或者一个服务区分类296可以使用每个用户的一个简档来指示适当的信息。这可以推广应用到更多其服务组解体的用户。此外，服务区分类296的使用可以根据一个给定呼叫的上下文或进展改变对服务访问的映射。这一类的实现允许各种呼叫参加者使用可能不同的激活输入激活不同的服务。在现有技术中，所有交换机销售商交付不灵活的服务选择方案，它阻碍了这一能力。
与介质无关的服务类298是服务控制类252的一种类型，诸如存储和转移300、广播、重定向、预先占有、QoS、和多方连接，其可以应用于不同的介质类型，包括声音、传真、电子邮件、和其它。如果一个服务控制类252被开发，其可以被应用到每一介质类型，然后该服务控制类252可以被破碎到可重用服务控制类252中。如果该服务控制类252被破碎到依赖介质的功能和与介质无关的功能中(亦即一种与介质无关的SC，其实现一种服务和一组依赖介质的返转器SC-每一介质类型一个)。作为从与介质无关的类298导出，存储和转移类300提供一般能力以存储消息或某些介质类型的数据流，和然后根据某些事件在后来交付它的能力。重定向提供根据指定的条件从一个逻辑地址移动一个连接到另一逻辑地址的能力。这一概念是呼叫转移(所有类型)、ACD/UCD、WATS(1-800个服务)、找到我/跟随我和移动漫游等的基础。预先占有，无论是协商的还是其它，包括诸如呼叫等待、优先级预先占有等服务。QoS调制的连接实现在包网络上实现另外的服务，诸如话音/传真、流式视频和文件传输。多方连接包括3路和N路视频会议等。虽然用户控制和输入主要使用电话上的键实现，但是可以期望使用话音识别用于将来的用户控制和输入。
连接管理器类302负责协调和仲裁在一个呼叫中涉及的各种载体控制248的连接。这样，管理在多个呼叫中的各方之间连接性的复杂性被包容并从所有其它服务中去除。服务和呼叫处理从该连接去耦合。这打破了作为一对多映射呼叫到连接的范式。现在映射呼叫到呼叫是多对多。
在一个结构内的连接管理器类302设计为以单独操作或作为等同物合作。在运行中，服务控制类252给连接管理器类302提交增加、修改和清除呼叫段的请求。实现这些改变是连接管理器类302的责任。注意因为连接可以被认为要么作为资源进入，要么作为贡献资源，所以连接管理器类302可以作为代理或者基本资源管理功能的一个方面实现。
呼叫控制类250实现基本呼叫处理，诸如通用于电话的基本有穷态机，和指定呼叫处理如何发生。有两类可以按照始发端(放置一个呼叫)304和终止端(接收一个呼叫)306的功能划分导出。
指导载体控制类248通过资源代理246改变到资源集合设备180或从其来的特定的信号和事件为可以由呼叫控制对象250理解的普通信号和事件。从该类导出的一个对象的一个期望的作用是收集关于一个呼叫的始发端的信息，诸如用户线号码、服务类别、访问类型等。子类可以根据与信令相关的电路或通道号码区分。这些可以包括一个与信道相关的类308，它施加在在一个ISDN基本接口310中的每23个载体通道中的单一信令信道。一个信道单一类312由一个模拟电话314代表，其使用拨号来控制单一电路，和信道公共类316，其由SS7信令318表示，完全从载体信道分开。
资源代理类246用于接口执行环境到真实世界交换机和载体网络中的其它元件。在这一级实现的和由所有下行的类继承的内部状态的例子是在服务中和不在服务中和不使用。期待的导出类是电话320(为标准2500组的标准代理)、声音响应单元(“VRU”)322(为声音响应单元的标准代理)、IMT中继线连接324(为数字中继线(I1/E1)电路的标准代理)、和调制解调器连接326(为数字调制解调器的标准代理)，相应于资源集合设备180内的特定资源类型。现在参考图10说明服务控制部件可以服务于到来的服务请求的一种优选的方式，该图特别表示服务控制环境430的另一个实施例，其具有在一个服务控制服务器例如通用计算机440的操作系统内执行的SLEE应用450、450′。
如图8所示，SLEE450是一个JavaTM“虚拟机”，设计用来执行至少5类在执行呼叫处理服务和其它支持服务中实现的逻辑程序(对象)1)特征区分器逻辑程序(“FD”)510，它们是服务控制类/服务区分器类296(图7)的功能子部件，其首先从交换平台接收服务请求，根据某些可用的准则例如一个呼叫拨的号码决定哪一种服务执行该呼叫，和然后调用合适的服务逻辑程序处理该呼叫；2)服务逻辑程序(“SLP”)对象520，它们是服务控制类252(图7)的功能子部件，其执行为接收到的服务请求或事件的服务处理；3)线路逻辑程序(“LLP”)对象530，它们是呼叫控制类250(图7)的功能子部件，用于维护一条网络访问线路的当前状态；4)事件逻辑程序(“ELP”)对象540，它们是服务控制/对话管理器类260(图7)的功能子部件，所有其它逻辑程序都对其写事件；5)呼叫逻辑程序(“CLP”)对象545，它们是服务控制/连接管理器类302(图7)的功能子部件，它通过为在一次呼叫处理中涉及的所有其它逻辑程序提供一个连接点来维护一个完整呼叫的状态。这些逻辑程序的每一个都作为一个软件对象体现，优选以JavaTM编程语言书写，它既可以临时以实例化，也可以是持续的，后面会说明。这样设计IDNA/NHIN服务控制结构，使得这些对象只在MOCE/SCE中写一次，而可以部署在该网络中任何地方的任何类型的计算机上和任何类型的操作系统上的SLEE。
一个极大的特殊性是FD510是一个静态子部件，它1)首先从资源集合设备例如交换机接收一个服务请求，当交换机识别到该服务要由IDNA/NMIN处理时；2)分析与该服务请求关联的信息；3)决定哪一个SLP能够处理该服务请求。优选，该FD可以是系统进程或一个为接收从资源集合设备提供的数据的用实例化的对象，包括但不限于，被呼叫号码、呼叫号码、始发交换机ID、始发中继线组、始发线路信息、和网络呼叫ID。通过NOS，FD510启动适当的SLP、CLP和始发LLP的实例化以处理呼叫。优选，FD510是持续对象，不绑定在一个特定的呼叫或事件上，并一直在服务控制SLEE450内活动运行。依赖于所执行的分析的复杂性和对FD的请求的大小，可以由FD的一个或者多个实例在服务控制SLEE450内活动地运行，以便共享负载和保证实时效率。例如，可以使用一个FD来分析接收到的SS7消息数据，同时可以使用另一个FD来分析ATM消息数据。
线路逻辑程序(LLP)530是一个功能子部件，它1)维护一个网络访问点、连接、或线路的当前状态；2)为与该物理点、连接、或线路关联的特征查询数据管理；和3)应用这些特征，诸如在呼叫场合命令时的呼叫中断、呼叫等待、呼叫转移、和溢出路由选择。有一个与启动一个呼叫的一条线路关联的LLP，以下称为“LLPO”，和与一个点、连接、或线路关联的一个呼叫对它结束的LLP，以下称“LLPT”。一旦一个线路逻辑程序实例被实现，则它在交换机结构中注册。下面会说明，线路逻辑程序530给服务处理的同一实例的ELP子部件发送所有事件数据。
动态子部件是根据服务处理的不同阶段动态构造的部件，它们在服务处理的实例完成时拆除，包括事件逻辑程序(ELP)；呼叫逻辑程序(CLP)；和服务逻辑程序(SLP)。
事件逻辑程序(ELP)540是用于保持在服务处理期间产生的实时事件数据和记录在服务执行期间发生的所有事件数据的功能子部件。事件逻辑程序优选当首先接收到一个事件时由在交换机处的呼叫控制处理实例化。当交换机给NGIN发送一个服务请求时，它通过ELP的地址，使得事件数据可以发送到与该呼叫绑定的这一逻辑程序。事件逻辑程序对在服务处理的同一实例内的所有功能子部件是可访问的，亦即与该呼叫有关的CLP、LLP和SLP。当每一服务处理部件在执行该服务期间中处理该呼叫时，它通过NOS根据预先建立的规则把事件数据写到ELP。当一个呼叫完成时，ELP中的事件数据被写到一个数据存储器或记录文件中，然后从这里编辑这些事件数据为帐单记录并向下游系统发送用于产生帐单、话务量/用途报告、和其它办公室支持功能。特别是，ELP执行功能1)收集由一个特定呼叫产生的网络事件；2)格式化该事件为何时的呼叫历史记录，例如呼叫详细记录(“CDR”)、帐单数据记录(“BDR”)、交换机事件记录等；3)为将来传输给下游系统例如用于用户记账而例如在数据管理中验证、检验和存储信息。应该理解，决定哪一事件被写入ELP的规则在服务产生时建立。事件数据另外可由伪管理和网络管理系统访问。
呼叫逻辑程序(CLP)545是维护在服务处理中涉及的每一SLP的状态并提供在所有服务(LP)之中处理接口的功能子部件。在一个实施例中，当为一个呼叫首先接收到一个事件服务请求时由FD实现一个CLP实例，或可以由位于该交换机处的一个呼叫控制部件实例化。另外可选的方案为，CLP545可以根据编程到SLP中的触发点由一个SLP510在服务处理期间的某一点实例化；以这种方式，一个CLP的实例化对一个服务来说可以是特定的。呼叫逻辑程序在实例化时接收服务处理的同一实例内的所有功能子部件的地址，亦即SLP、LLP和ELP。该ELP然后关联SLP、LLPO、LLPT、和为该呼叫的ELP，并可由该服务处理的同一实例内的所有这些子部件访问。也就是说，呼叫逻辑程序是为在服务处理的同一实例中涉及的SLP和LLP之间的通信的连接点。当一个呼叫完成时，CLP通知服务处理的同一实例内的所有子部件呼叫完成，这将启动该逻辑程序的拆卸处理。
服务逻辑程序(SLP)520是提供为执行一个服务所需要的逻辑的动态子部件。SLP与服务而不是与呼叫绑定，并为呼叫执行服务和其中包含的特征。SLP为一个服务可以应用的特征例如包括呼叫路由选择算法和IVR服务。SLP可以是为经常使用的服务的一个持续对象，或者可以为不经常使用的服务当由FD需要时实例化或在呼叫完成时终止。某个一定的SLP是在所有时间还是在一定时间或者仅在需要时激活由为该服务的服务管理产生的配置文件580决定，如图11所示。优选，SLP访问服务处理的同一实例内的CLP和ELP子部件。
并非所有的SLP都与一个特定的呼叫服务相关，某些SLP可为由其它SLP需要的或者调用的进程使用。这样，例如，一个用于800服务的SLP可以需要调用一个SLP为线路信息数据库查询以完成其为呼叫路由变换的任务。一个SLP也可以把为一个呼叫的呼叫处理控制传给另一个SLP。优选只有一个控制SLP每次为服务处理的一个单一实例执行。任何作为由该SLP执行的服务任务的一部分产生的事件数据都发送到在服务处理的同一实例内的ELP部件540。
一个SLP可能不能在一个操作系统内直接执行，因为它不包含为一个操作系统执行的所有信息。此外，如果该SLP需要被在不同的操作系统中执行而不改变格式和内容的话，则提供在该SLP和操作系统之间的NOS中间件以维护该SLP在操作系统上的一致性。
如图8进一步所示，在SLEE 450内为支持和操作功能执行的其它处理包括服务管理(“SM”)对象554，其负责加载、激活、去激活和清除在SLEE中运行的服务，和另外监视在其SLEE内运行的所有其它服务，并给NOS报告状态和使用数据；一个NOS客户处理558，它是一个NOS类库，其用于接口NOS服务，并由在该SLEE内运行的所有服务使用以调用NOS服务，亦即是对NOS的门关；线程管理器(“TM”)557，它提供为NGIN服务需要的功能以并发执行而不绑定所有SLEE资源；和数据管理API(“DM API”)410，其用于与本地高速缓冲存储器415和DM400的高速缓冲存储器管理器部件接口，它在这里参考图4(c)说明。
图8所示的在SLEE中加载的另一个服务实例包括一个服务代理(“Sag”)实例559和一个与其关联的线程管理器实例557，其用于在服务节点处的服务激活，下面将详细说明。
图12(a)说明提供到SLEE处理的主入口点的(SLEE.Java)处理步骤。如图12(a)所示，步骤602假定一个DM系统部件可用，NOS站点定位器系统包括一个NOS客户处理558和NOS主处理560(图11)，后者提供一个NOS类库，该库用于与NOS服务接口并由运行在该SLEE内的所有服务使用以调用NOS服务，该NOS站点定位器系统可用于接收逻辑名和对象引用登记，以及服务控制服务器操作系统，例如WindowsNT，UNIX，PC，等，可以启动SLEE处理，例如通过识别一个引导程序调用，诸如main()或fork()。应该理解，NOS主部件560(图8)直接与计算机的操作系统、NOS客户处理558，和其它系统部件571接口。优选，有一个位于网络或一个本地节点上的NOS主处理560，它与每一SLEE上的NOS客户对象558接口，并包括为提供NOS服务所有的NOS类库。接着，在步骤604，输入服务控制配置文件并分析该文件以建立一个配置对象，它可以包括一个包含键字值对的散列表，如步骤606指示。SLEE接受两个参数一个名字和一个配置文件。名字参数是唯一的NGIN名字串，其由NOS定位器服务使用用来识别SLEE的这一实例，亦即由SLEE使用使自身与NGIN定位器服务注册(步骤612)，以及由定位器服务使用配置文件来寻找它的网址定位器。例如，该表可以用于寻找SLEE配置特性。当NOS实现CORBA时，接着在步骤608初始化基本CORBA功能。接着，在步骤610，实现一个SLEE类加载器实例并在该SLEE内实现一个NOS定位器代理服务实例，其在步骤612指示。接着，如在步骤615指示，服务管理器(SM)类通过类加载器加载、实例化、并与本地代理NOS定位器服务对象绑定。应该理解，本地定位器服务传送服务管理器限制给在NGIN域内的其它定位器服务。在下面参考图12(b)时会说明，在服务管理器对象向定位器服务注册后，能够给/从SLEE处理为加载、激活、去激活和清除服务的服务管理请求。最后，如在步骤618指示，执行处理事件循环的SLEE线程，该线程保持SLEE运行和在NOS事件通过服务管理器(“SM”)或服务代理(“Sag“)对象到来时允许SLEE处理NOS事件，下面详细说明这点。
图12(b)表示由服务管理器对象实例554(图8)执行的(ServiceManagerImpl.Java)处理步骤，该实例在上面参考图12(a)的步骤615讨论时实现。优选，SM对象实现一个为代表NOS执行服务管理操作的ORB接口。该处理表示由SM实例为加载、激活、去激活、运行和结束SLEE内的服务所采取的步骤，例如通过(1oad)，(run)，(start)和(stop)方法。由NOS传送给该SM对象实例的参数包括希望的服务的逻辑参考和指示NOS是否应该用NGIN本地资源管理器(LRM)站点定位器注册该服务或该服务是否负责向NOS注册自身的布尔标志。如在步骤620指示，首先接收到加载服务的请求，然后在步骤622交由代理命名服务处理。然后，在步骤624，对所请求的服务例如1-800收集(“18C”)决定是否已加载，也就是说，是否实现体现所请求的服务的对象实例。如果为所请求的服务的对象已经实例化，则NOS在步骤626将把该服务的对象引用返回以定位物理对象实例，处理返回到步骤632。如果为所请求的服务的服务对象例如18C尚未实例化，则在步骤625实现Classloader类实例化，其实现递归加载以加载所请求的服务依赖的所有类，包括其它SLP和SIBB。递归加载例如可以通过参考本地高速缓冲存储器中的一个本地配置文件而可能。特别，传输一个标志，该标志指示类加载器是否递归加载所有这些依赖的类到JVM。当为在第一实例中的一个服务加载类时，应该理解，如果一个一般服务代理类尚未加载时可以将其加载。然后，在把所有类在步骤625加载后，在步骤628检验布尔注册标志以决定该服务必须以本地NOS命名服务(代理)注册自身。如果该布尔标志已经设定例如为真，则该服务有责任向NOS命名服务注册，如在步骤630指示。否则，处理继续到步骤632，这里实现Sag类实例化，并在服务代理对象实例(图11)和该特定服务之间建立关联，例如通过把SLP对象传送入服务代理实例。然后，在步骤635，以要说明的方式产生一个新的SLEE线程，并调用该SLEE线程以运行该服务代理，亦即，关联该SLEE线程与服务代理。最后，跳出SM处理，处理返回到SLEE.java处理。通过在SM中提供的方法，另外负责监视在它的SLEE内运行的所有其它服务，并向NOS报告状态和使用数据。
另外对SM处理，参考图12(c)详细说明(SLEEClassLoader.java)调用。特别，SLEEClassLoader类是JVM的ClassLoader类的一个专门并使其扩展的类。它通过允许类被加载到网络上而扩展系统类加载器的行为。这样，作为图12(c)的第一步骤686，类加载器首先检查它的与SLEE的实例关联的本地高速缓冲存储器看该类是否已经加载和定义。如果该类已经被加载，则处理返回。如果该类尚未加载，则在步骤688通过NOS发送一个消息以检查一个本地数据存储器(DM)决定是否该类可为加载使用。例如，SLEEClassLoader可以从关系式数据库使用JDBC数据库连接检索类，然而，应该理解，可以从支持JDBCAPI的任何关系式数据库检索类。如果在本地数据存储器中未找到该服务类，则SLEEClassLoader在步骤689检查一个本地文件系统。如果该类在无论数据存储器或者本地文件系统中找到的话，则取该类，其在步骤690指示。然后，在步骤694，调用一个定义类方法以使该类可为JVM执行环境使用。特别，(defineClass)方法递归经历为执行该服务而指定的每一类并变换一个字节阵列为类Class的一个实例。然后，可以使用在类Class中的newInstance方法产生这一新定义的类的实例。这一功能允许SLEE加载和实现新服务实例但仍保持其一般性。优选，如在步骤695指示，调用一种方法以存储在本地高速缓冲存储器，使得下次加载类时可以有高速缓冲存储器命中。
在该优选实施例中，这些实例化的对象的每一个都根据一个命名约定将自身向一个NOS定位器服务注册，例如LRM577，所述命名约定通常用下面的串例示
…场地级.SLEE号码.SLP名…这里，场地级是有关NGIN服务控制服务器440的物理位置的信息；SLEE号码是一个特定的SLEE，其中实现该对象的实例，例如SLEE#1；SLP名是该服务的逻辑名，例如，特征区分#1。字符串也可以包括“版本号”。注册名被传送到在该NGIN域中的其它定位器场地；通过注册处理和NOS资源管理功能(下面说明)，NOS部件知道已经部署哪一个处理，它们被部署到什么地方，和服务当前在何处可用。
本方法和由类加载器产生的对象的构造器可以引用其它类。为决定提到的类，Java虚拟机调用类加载器最初产生该类的loadClass方法。如果Java虚拟机只需要决定该类是否存在和如果它确实存在而知道其超类，则把“解析”标志设定为假。然而，如果该类的一个实例正被产生或任何其方法正被调用，则该类也必须被解析。在这一场合，解析标志设定为真，并调用resolveClass方法。这一功能保证由服务参考的类/SIBB/JavaBeans也由SLEEClassLoader解析。
图12(d)表示当实例化时服务代理类处理流程。如在步骤639所示，第一步骤包括实现与服务代理关联的一个线程管理器(“TM”)对象的实例并作为在图11中一个TM对象实例557描述。下面会说明，线程管理器对象基于一个(ThreadManager)类，其可以被实例化而表现类似一个线程工厂，用作为每一服务请求产生一个新的SLEE线程，或一个线程注册表，它当在具有高线程产生延迟的机器上运行时是希望的。接着，在步骤640，与服务关联的SA通过其(运行)类方法进入一个处理事件环路，并在现在准备好接收与一个服务关联的呼叫事件。
参考图12(e)，图中表示出ServiceAgent类的细节，它通过其(begin)，(continue)和(end)类方法提供到NGIN服务的门关。在SLEE内的每一服务具有一个关联的ServiceAgent对象，其基于一个负责管理服务实例(呼叫实例)和分配事件给服务实例的类。如图12(e)所示，在由服务管理器(1oad)方法实现一个Sag对象实例和运行后，Sag的(begin)方法每次在接收到请求该服务的一个新呼叫时被调用。特别，如图12(e)指示，在步骤641，tid、orid标识符参数和包含有关为该呼叫的服务处理的事件信息的一个消息流首先传送给Sag开始方法，所述消息流例如由来自在这里称为新一代交换机(“NGS”)的IDNA/NGIN交换机的一个初始地址消息(“IAM”)提供。然后，在步骤643，例如通过调用一个(decode)方法解码该消息流来执行与该服务实例有关的决定性消息。另外，用于管理呼叫上下文数据的呼叫上下文对象实例被产生以接收执行的消息信息。在开始方法中，如在步骤645指示的，通过调用ThreadManager实例的分配方法为该呼叫分配一个新线程，其在这里参考图12(g)说明，或如果事前已为该服务实现几个线程实例的话，则从线程库拉出一个线程。否则，如果Sag(continue)方法被调用的话，则返回为相应于为该呼叫分配的线程的一个对象引用。
更具体的是，线程管理器对象基于ThreadManager类，其优选根据对话id管理线程。为分配和释放线程分别提供两种方法，(allocate)和(release)。分配和释放两者都期望一个唯一的标识符作为可以用于线程识别的关键字。该唯一的标识符包括一个事务处理ID(“Tid”)，其由接收该呼叫的NGS设定，和一个标识呼叫始发端并用于识别一个呼叫实例的对象引用ID(“Orid”)。图12(f)表示线程管理器类的(分配)方法的操作细节。如图12(f)所示，在步骤660，把唯一标识呼叫事务处理的Tid和Orid标识符传送给处理，并根据该标识符产生一个唯一的关键字。然后，在步骤662，询问该关键字标识符是否存在于该线程，例如，通过检查关键字值对的一个散列表。如果识别到关键字，意味着已经为该呼叫分配一个服务线程，然后在步骤664，线程管理器在咨询散列表后返回SleeThread实例(线程对象)。否则，在步骤663，给跟踪已实例化的服务线程的数目的计数器加一，并在监视系统负载的努力中，在步骤665，决定是否已经超过为该服务的线程实例的最大值。如果已经超过为该服务的线程实例的最大值，例如，在比较计数器值与在服务配置文件中找到的最大服务实例值，然后在步骤667给NOS发布一个消息，使其能够为该服务寻找另一个实例，其可以例如在另一个在同一场地执行的、或在另一服务节点位置实例化的SLEE中可用，同时处理返回。另外对该SleeThread实例化处理的是其PriorityEventQueue的初始化，它在这里参考图12(g)详细说明。如果为该服务的线程实例的最大值尚未超过，则在步骤668，决定是否超过为该服务的线程实例的某个阈值。如果已经超过为该服务的线程实例的某个阈值，则在步骤669，给NOS本地资源管理功能发布一个警告，说明已经达到服务阈值。最后，在步骤670，不管在步骤668的输出，为所请求的服务分配一个新SleeThread实例，为请求的服务初始化一个优先事件队列，开始该线程，同时控制返回为该服务的Sag实例。
返回到图12(e)所示服务代理(begin)方法功能，在线程管理器为该服务实例分配一个线程后，与该线程有关的对象变量在步骤646初始化，并通过查询一个(clone)方法实现所请求的服务的一个新对象实例。然后，在步骤648，新复制的SLP实例设定到新分配的线程中。然后，在步骤650，决定存在一个事件信息，其需要与该呼叫实例关联，例如所有从输入消息流中抽取的IAM信息。如果存在与该新复制的SLP实例关联的事件信息，则将其推入线程，如在步骤652所示。不管是否存在要被推入线程的事件信息，都起动为该SLP的新分配的线程，等待与服务相关的事件信息的异步到达，该信息由SA(continue)方法处理。如前所述，为该呼叫分配的SleeThread维护一个优先级事件队列为保持在处理期间接收到的与服务相关的所有事件信息。有关服务处理的所有事件具有一个相关的优先级，而线程将根据其优先级亦即其在服务事件队列中的位置管理事件信息的处理。最后，在步骤654，为该呼叫实例开始线程事件循环。
应该理解，SA(continue)方法基本和在图12(e)所示(begin)方法相同，其差别是SA(continue)方法指向为该呼叫实例已经实例化的服务处理线程为实时服务相关的事件选择信道，如已经参考图12(e)所说明的。这样，服务代理的继续方法接收事件和该呼叫实例的识别参数，重新分配与为接收到的事件的tid、orid参数关联的服务线程，并把该事件推入线程的事件优先级队列。应该理解，SAg和SM类两者都包括一个对NOS的IDL接口。服务(SLP)不具有这样的接口，然而能够通过其Sag接口在系统范围通信。在实时服务处理期间，SLEE450能够执行下面的事情1)在服务处理期间在SLP和SIBB级上解释指令；2)给SLP的指定实例交付到来的事件；3)如果设定跟踪标志的话，产生跟踪数据；4)允许跟踪对准SLP、SIBB、和SLEE级进行，并把跟踪数据发送给一个指定的输出；5)产生SLEE使用数据并给一个指定输出发送运行时间使用数据；6)为远程通信管理网络(TMN)实例产生例外数据(错误)；7)为TMN接口产生性能数据；8)为增加SLP的新实例或实用程序接收消息/请求并增加这样的新SLP或实用程序实例而不中断和降低服务处理；9)通过为负载共享增多服务控制实例支持同一服务。
当一个服务实例完成处理时，它要么启动该服务的终止，或者按照系统意愿启动通信中的另一个处理。无论在哪种事件，都调用Sag(end)方法，它的功能为终止与该呼叫关联的线程实例。这通过调用一个ThreadManager(release)方法、传送唯一标识该呼叫实例的Tid和Orid、推任何事件到线程的事件队列、和释放该呼叫亦即终止该线程实例和/或把该线程事利放回到线程库中而实现。
优选，SleeThread类实例提供为IDNA/NGIN服务所需要的功能以并行执行而不绑定所有SLEE资源和便利协作资源共享。具体说，在SleeThread和服务实例之间有一个一对一映射，同时SLEE把SleeThread的一个实例与服务的一个实例相关，亦即为由一个服务处理的每个呼叫存在一个与该呼叫关联的SleeThread实例。SleeThread还通过容放事务处理id(tid)、对象引用id(orid)、对象引用，例如同类和代理两者、SLP、和与该SLP关联的优先级事件队列。更特别的是，一个SleeThread通过实现两个关键的接口作为一个在服务(SLP)和ServiceAgent之间的事件通道为使ServiceAgent推SleeThread上的事件的PushConsumer；和能使服务从它们关联的线程中拉事件的PullSupplier。下面会说明，每一个SleeThread以所述方式具有一个为排队NGINEvebts的PriorityEventQueue的实例。
优选，(PriorityEventQueue)类是一个与平台无关的类，它把与一个服务(SLP)关联的事件(NGINEvent的导出类)排队。如参考图12(f)的步骤667、670所示，每个SleeThread对象实现PriorityEventQueue的一个实例，它可以包括事件的一个散列表。事件可以以降序排队，例如，事件优先级由在NGINEvent基类中定义，并在从10到1的范围内任何位置，例如，10是最高的优先级。这样，每一线程可以跟踪可用/不可用于处理的事件的数量，从而允许完全的服务处理的并行性。
图12(g)表示一个(postEvent)方法，其包容为确定正由线程接收的事件的优先级的逻辑，如在步骤675指示，并把事件登记入PriorityEventQueue中。如图12(g)所示，这基本上通过比较被推入的事件的优先级与要在步骤678处理的优先级队列中的下一事件的优先级而实现，决定被推入的事件的优先级是否大于要在步骤680处理的(如果有的话)队列中的下一事件的优先级，并要么把被推入的事件放在该队列的顶以设定它为下一要处理的事件，如在步骤682a指示，或者，循环通过该队列并决定该事件按照其优先级在该队列中应该存储的位置，如在步骤682b所示。然后，在步骤684，SleeThread处理具有最高优先级的下一事件，当其已经从系统分配处理时间时。
更特别的是，通过SleeThread实现一个PullSupplier接口以支持为用户的一种操作从供应者请求数据，这通过要么调用一个直到事件数据可用前被闭锁的“Pull”操作，或者出现一个例外并给用户返回事件数据；或者调用不闭锁的“TryPull”操作。也就是说，如果事件数据可用，则它返回事件数据并设定hasEvent参数为真；如果该事件不可用，则它设定hasEvent参数为假并返回一个空值。这样，SleeThread可以作为事件供应者，而服务(SLP)采取用户的角色。服务(SLP)使用SleeThread Pull或tryPull从SleeThread取事件数据。该服务要么使用Pull操作，如果它没有事件数据不能继续的话，否则，它使用tryPull操作。
由SleeThread实现PushConsumer接口并实现一个类属PushConsumer接口，它支持为供应者的操作以通信事件数据给用户，这通过调用推操作到线程和把事件数据作为参数传送给线程的优先级事件队列实现。这样，SleeThread作为事件用户，而ServiceAgent采取供应者的角色。ServiceAgent使用SleeThread推操作通信事件数据给SleeThread。一个“kill”服务事件可以包括最高优先级。为事件的优先级可以是缺省的，或者当设计新产生的事件类时可以在服务产生处建立。
如上所述，为一个特定服务的服务代理实例把在服务处理过程中所有接收到和产生的事件引导到为该呼叫建立的服务线程实例，或从其引导而来。例如，由在一个节点的交换机产生的初始事件可以包括一个(ServiceRequestEvent)，该类负责对IDNA/NGIN服务控制传达一个初始服务请求，而特别是初始呼叫上下文信息，诸如启动服务请求的时间；请求从其始发的交换机ID；呼叫始发的端口ID；呼叫始发的终端设备ID；呼叫方号码；被呼叫方号码等。一个扩展NGINevent的(connectEvent)子类可以报告连接发生的时间、呼叫号码所连接到的站号码；和在ATM-VNET服务的范围中报告到来的虚拟路径ID和出去的虚拟路径ID。一个扩展NGINevent的(releaseEvent)子类可以报告释放事件。例如，在ATM-VNET服务的范围中，当呼叫或被呼叫方终止一个呼叫时，或当用户信用金用完时可以引起释放。这样一种类可以实现SIBB来决定产生一个释放事件的时间；引起产生释放事件和从连接呼叫和被呼叫方到产生释放事件的时间过去的时间。另外对这一点，可以使用扩展NGINevent的(connectEvent)子类表达从NGIN到NGS的一个终止消息。在接收到这一消息时，交换机可以启动拆卸连接处理。一个(MonitorReleaseEvent)子类扩展NGINevent和用于给NGS发送消息，指导NGS在接收一个释放指示时把一个释放指示传给NGIN。当NGS接收一个监视释放消息时，可以调用(UniNotifyEvent)子类给始发端(呼叫者)发送一个通知。(MonitorConnectEvent)子类扩展NGINEvent，它是一个用于从NGIN给NGS发送消息的子类，指导NGS在接收到一个连接消息时给NGIN发送一个事件。
如上所述，在实时服务处理的范围中，数据管理的数据检索和更新功能包括由DM在服务处理期间访问存储的数据的能力。
在该优选实施例中，在任何特定的服务节点，DM在服务处理期间例如通过NOS接收来自在SLEE中执行被管理对象实例的数据请求。如果数据管理不能理解数据请求的话，它特别通知请求者(例如被管理对象)。如果数据请求是为检索一个数据实体，则数据管理返回所请求的数据给请求者(例如通过NOS)。应该理解，由DM提供为操纵和询问在一个单一注册表或在多个注册表中的数据所需要的任何支持。数据管理另外支持收集和相关跨越多个注册表的询问结果。如果DM不能定位在数据检索请求中的所请求的实体的名字时，则DM通知NOS部件。如果在检索一个数据实体期间发生错误的话也将通知NOS部件。数据管理另外通知请求者(执行服务控制的对象)不能从一个有效名字检索一个特定数据实体。如果数据请求是为更新一个数据实体，则数据管理更新该数据实体并决定是否需要回答。如果DM不能更新在一个数据请求中指定的数据实体的话，则它通知请求者，如果它不能定位在该数据更新请求中所请求的实体的名字时，它另外通知NOS。在NGIN运行期间的任何时间，DM通知NOS在更新一个数据实体期间的数据库错误。如果数据请求是为删除一个数据实体，则DM删除该数据实体，并决定该事务处理是否需要在其它注册表中启动。
图4(c)总体表示数据管理部件400的功能结构，它包括服务控制服务器部件405，用于使呼叫服务数据在服务节点处为实时呼叫处理可用；和作为一个分立的数据库服务器实现的数据库部件407，其用于存储和分发由SA维护的数据的一个选择的子集。具体说，服务控制服务器部件405包括数据管理(DM)客户409，其为实际数据管理应用；一个DM API 410，它与DM应用连接，并且是DM应用使用从SA获得数据的接口；本地高速缓冲存储器415，它是服务控制服务器上的一个共享存储器，用于存储来自DBOR提取器的某些或全部数据，这些数据可按照本地高速缓冲存储策略为呼叫处理使用；和高速缓冲存储器管理器420，它通过实现本地高速缓冲存储策略维护本地高速缓冲存储器的状态和与DM服务器通信从DBOR提取器检索数据。数据库部件407包括DBOR提取器，它由一个或多个数据库组成，这些数据库具有要由被管理对象实例在该节点处执行服务期间使用的数据；DBOR提取器管理器426，用于管理SA保持的信息的一个选择的子集；SA客户422，它从服务管理输入数据给DBOR提取器管理器426；DDAPI424，它是在SA客户422和SA的数据分发处理之间的处理接口；和数据管理服务器425，它一般从DBOR提取器管理器426提取数据选段。
现在参考图4(c)和8进一步详细说明数据管理操作。在一个SLEE内，有几类功能可以从数据管理400需要数据，包括但不限于被管理对象(SIBB，SLP等)和NOS。它们每一个在图4(c)中作为一个在服务控制SLEE内执行的DM客户表示。当DM API 412为所有DM客户提供一个公共消息集以与数据管理接口时，DM客户410使用DM API请求数据。DM API 412还从该DM客户包容需要数据的特定位置，当这一数据可以被存储在一个本地高速缓冲存储器415中或仅在DBOR提取器427中时。DM客户410通过逻辑名请求数据，DM API 412决定该数据是否可以从本地高速缓冲存储器检索，如果需要通过DM服务器从DBOR提取器请求数据的话。优选，本地高速缓冲存储器415是为运行在在控制服务器405内提供的每一SLEE上的每一处理可用的共享高速缓冲存储器，亦即可以有一个或者多个为不同应用提供的本地高速缓冲存储器，例如1-800处理高速缓冲存储器，路由选择管理器高速缓冲存储器等，每一共享的高速缓冲存储器有它自己各自的高速缓冲存储器管理器。
当DM客户410请求数据时，DM API首先检查本地高速缓冲存储器415，看所请求的数据是否存储在那里。如果所请求的数据存储在本地高速缓冲存储器415中，则DM API使用任何标准数据检索技术检索所请求的数据并将其提供给DM客户410，诸如散列关键字和算法，或索引顺序访问方法。
如果所请求的数据不存储在本地高速缓冲存储器415中，则关联的高速缓冲存储器管理器420通过DM服务器425从DBOR提取器427检索该数据。特别，DM API 412通知高速缓冲存储器管理器420它需要一定的数据和高速缓冲存储器管理器通过给DM服务器425发送一个请求来响应。DM服务器425依次使用为数据库访问的DBOR提取器管理器426从DBOR提取器检索请求的数据。DM服务器425把检索到的数据回送给高速缓冲存储器管理器420，而高速缓冲存储器管理器通过DM API 412给DM客户610提供数据。高速缓冲存储器管理器还可以根据本地高速缓冲存储策略写所请求的数据到本地高速缓冲存储器415，本地高速缓冲存储策略既依赖于服务命令也依赖于它们在其上运行的计算机的能力，特别是存储器容量。这些性能说明从服务和由服务管理产生的计算机简档获取。优选，为IDNA/NGIN的DM400的数据高速缓冲存储器管理器部件在每一服务节点使用一个客户侧高速缓冲存储策略。
现在参考图8-10详细说明IDNA/NGIN网络操作系统(“NOS”)部件700。如上所述，NOS功能包括为该IDNA/NGIN系统170允许处理间的通信、对象的连接性、和本地和网络范围内的资源管理功能。因为所有NGIN处理执行在广阔分布结构上的多种硬件和操作系统平台，因此NOS在所有处理之间提供与平台无关的和与位置无关的通信。特别，NOS包括几种功能子部件以提供在所有NGIN处理之间的接口，包括在服务控制、服务管理、和数据管理之间的接口。NOS也是呼叫控制和服务控制(图5)之间的接口，和能使运行在同一SLEE上的两个或者多个处理彼此通信。
如图8-10所示，NOS功能子部件包括1)名字转换(“NT”)处理570，它为数据和服务对象解析逻辑名为物理地址，该物理地址标识所请求的对象在其内运行的计算机(作为一个网络地址)和存储器地址；2)本地资源管理(“LRM”)处理575、577，它跟踪和维护在SLEE处和在服务节点执行的资源的状态；3)综合网络资源状态(“NRS”)处理590，它维护在整个NGIN网络范围内所有服务节点资源的状态，并提供处理间通信；4)为提供对象连接性的一组服务，诸如由一个遵从公共对象请求代理结构(CORBA)的ORB所提供的，它能使在不同计算机平台上的对象之间的通信、API消息集、和因特网协议(IP)通信以这样的方式进行，使得能够满足或者超过一定的实时呼叫处理性能需求。例如，为处理一个典型的1-800号“集合呼叫”事件的典型响应时间，应该大约50到100毫秒。
如在这里说明的，NOS部件700可以使用一个遵从CORBA的ORB为对象连接性实现，诸如由Orbix所提供的，Orbix是由马萨诸塞州的剑桥市和爱尔兰的都伯林市的IONA技术公司开发。ORB通过名字服务提供在不同计算机平台上的对象之间的通信，所述名字服务能够映射逻辑名为物理地址。
在系统引导时，SLEE450起动并在它的环境中发布N0S客户部件558和服务管理器处理部件554的一个实例。SM SLP 554从包括立即要实例化的服务的逻辑名的配置文件580中为其它部件检索逻辑名。然后，它给ORB名字服务提供该逻辑名，ORB名字服务映射该逻辑名为物理地址。ORB从该点开始维护服务对象的连接性。ORB名字服务也用于其它服务注册。在SLEE上起动的每一个服务将自身与NOS注册，而正是通过这种注册ORB识别逻辑名的物理地址。
为实现在交互对象之间的与平台无关的通信，定义接口，它通过接口定义语言(“IDL”)而可能。CORBA当前支持IDL，然而，其它面向对象的通信技术，诸如远程方法调用(RMI)协议可以被实现，只要性能需求适合实时呼叫处理。特别，为每一NGIN部件的接口在其建立时定义，并通过将它们存储在一个与本地LRM575关联的持续的数据存储器或库(未示出)中使其在运行时间可用，如图9所示。允许服务询问该库以了解新对象接口。NOS客户处理558和NOS主处理560(图8)是一个NOS类库，其用于与NOS服务接口，并由在该SLEE内运行的所有服务使用以调用NOS NT和LRM服务，其在这里进一步详细说明。
现在参考图9，图中表示NOS NT子部件570和LRM功能子部件575的功能结构，这两个子部件驻留在执行一个或者多个SLEE450和450′的计算机上，NT和LRM子部件与每一SLEE关联。图9特别表示单NGIN服务节点或“场地”45的一个例子，其具有至少两个计算系统440和440′，分别实现SLEE部件450和450′和各NOS部件700和700′，它们每一个包括各自的NT功能子部件570和570′，和各自的LRM功能子部件575和575′。虽然表示出单一SLEE在一个单独的计算机上执行，但是应该理解，两个或者多个SLEE可以在单一地点的同一计算机上运行。在每一SLEE450、450′上运行的是标记为S1、…、S4的几个服务对象或者处理，它们可以是SLP、LLP、CLP、ELP、持续运行的FD逻辑程序和NOS客户对象558，或者其它处理。
如在这里说明的，每一NOS NT功能子部件570、570′各包括一个为识别一个要使用的数据或服务对象的正确版本、和要使用的该对象的最优实例的处理，特别通过允许一个处理调用任何其它处理，使用一个在不同版本中保持不变的单一公共逻辑名和被呼叫的处理的实例。这样，NOS NT部件570包容来自处理的实例的对象引用、版本、和物理位置。
如在这里说明的，在每一服务节点的NOS700的每一本地资源管理器(“LRM”)部件575、575′决定哪一个服务执行在一个节点处的哪一个SLEE，在服务简档(配置)文件580中包含的每一配置规则，它们可以包括从SA为在本地LRM高速缓冲存储器中存储部署的服务简档的内容。LRM首先读取存储在该节点处的本地高速缓冲存储器中的这一服务简档580，并决定哪一个特定的SLEE根据在该服务简档的规则运行一个服务，和哪一个服务在该SLEE中活动运行(作为持续对象)，或只在需要时才实例化。
在该优选的实施例中，LRM575允许运行时间配置和优化服务执行，这通过跟踪每一服务控制资源的正常情况和状态而实现。特别，每一LRM功能子部件维护一张所有编程在该SLEE上运行的服务的表，哪一个服务处理(对象引用)在一个SLEE上活动地运行和根据预定的阈值在该节点处的SLEE的当前负载状态(处理能力)。
更特别的是，SLEE(服务器)LRM部件575是一组建立在相应于在该系统中的每一对象(逻辑程序)的对象引用的一个本地高速缓冲存储器中的库，该对象引用包括有关服务器的信息，诸如IP地址和端口号码，使能够通信。当新对象在该系统内变得可用时与NOS注册，亦即为它们产生一个对象引用，为通过数据管理在本地高速缓冲存储器中注册。
在查询其服务简档(配置)文件580以决定哪一个服务立即实例化后，NOS LRM部件575通过也在SLEE450中执行的NOS客户接口从NOS NT 570发送一个服务激活请求给在SLEE中的活动的服务管理器对象554。SM对象554是一个为允许控制SLEE服务的API对象。例如，它提供当接收到为一个不活动的服务的请求时实现新服务实例的能力。也就是说，当它被实例化时它能够给该对象指定一个处理线程，而服务然后通过LRM575将其自身与NOS注册。当一个服务被另一服务使用其逻辑名调用时，LRM使用配置文件中的规则以决定哪一个实例被调用，通过使用ORB名字服务映射逻辑名为活动实例的物理地址。
如图9所示，与一个NGIN场地或服务节点45关联的是在一个单独的计算机440″上的NOS部件700″上运行的，或在一个共享的计算机上诸如计算机440或计算机440′上运行的场地LRM577。场地LRM577的功能是1)跟踪在每一SLEE处的服务的可用性，其为所有在每一SLEE上运行的处理的当前负载的函数；2)维护一个资源状态表，它是每一单个的SLEE LRM 575的活动更新的复制，另外为每一资源有一个SLEE标识符。场地LRM子部件577根据几个准则中的任何一个决定所请求的服务的哪一个应该被使用，这些准则包括但不限于1)被呼叫的服务实例与呼叫服务实例的接近度(同样的对不同的SLEE，同样的对不同的场地)；2)被呼叫的服务实例对由被呼叫服务所需要的数据管理数据的接近度；3)当前系统和处理负载。
作为一个例子，在图9中表示出每当一个处理，例如在SLEE1中的S1，需要实现一个SLP的实例，S4，以执行一个特定的处理时，例如Vnet服务，NOS首先判定该服务亦即它的对象引用是否在本地高速缓冲存储器中例如在SLEE1中可用。如果本地LRM575没有所请求的对象引用，则NOS寻找场地级LRM577来决定相应于所请求的服务的特定对象引用的位置。例如，如图9所示，该对象可以在SLEE2中找到，并当找到时NOS通过实现该对象的一个实例使该服务可用，如果SLEE具有这样做的能力，亦即尚未达到它的使用阈值。
如图10进一步所示，在为每一SLEE的各LRM575和为每一场地的各LRM577之外，NOS部件700另外包括一个网络资源状态(“NRS”)子部件590，它是一个执行网络范围资源管理功能的处理。特别，NRS包括一个由每一场地LRM维护的、为在网络中的每一场地LRM的数据的子集，例如为相应于图10中各场地440a、…、440c的场地577a、…、577c。NRS590包括1)一个SLEE表；2)哪一类型的服务被编程在每一SLEE上运行；和3)哪一个服务在每一SLEE上活动运行，亦即SLEE的当前负载作为百分之一的基础。这一NRS子部件590是一个逻辑上中心化的功能，给NOS为场地LRM577a、…、577c不能满足的请求的另一传播级。另外，NRS子部件590为每一SLEE450包括一个二进制指示符以指示该SLEE是向上还是向下，和指示一个服务使用阈值是否由该SLEE达到。“向上”或“向下”指示符和使用阈值应用用于决定一个SLEE是否可用于从其它服务接受服务请求，和NRS子部件可以简单地提供二进制指示符，指示在给定这些指示符和阈值应用时一个SLEE是否可用。作为一个例子，如果一个请求的SLP对象在一个SLEE中被找到，但是该SLEE没有能力实现所请求的处理的实例，则它将发送一个通知给场地LRM577，告知已经达到为该SLEE的使用阈值而不能处理为该服务另外的请求。这一信息也将传送到NRS部件590(图10)。
回过来参考图8，NGIN系统实现一个监视机构595为监视存储器容量、数据库容量、查询所请求的对象的长度、队列中的时间的量、和为系统中每一SLEE的其它资源/负载参数。对NOS700有3个因子可用，它根据这些因子的一个或者多个来决定SLEE的使用阈值。在固定阈值外，可以为滞后使用多重阈值。
现在参考图11(a)-11(b)详细说明由NOS执行的资源管理功能的一个说明性例子，该NOS包括NT、LRM、和NRS，它们能够使NOS700提供位置和与平台无关的处理，同时优化NGIN的总处理能力。在参考图11(a)和11(b)说明的LRM处理流程图801中，假定在一个服务控制服务器上的SLEE1上执行的服务S1需要调用服务S2，如在步骤802所示。服务S1可以是一个FD或者服务逻辑程序，其从交换机结构呼叫控制接收一个事件服务请求并需要调用另一SLP，S2，例如为完成呼叫处理。
特别，参考图11(a)，服务S1使用为SLP S2的逻辑名发布一个请求给NOS700。当接收到为一个服务对象的SLP请求时，NOS名字转换功能570a被实现，其在步骤804指示，用于决定NOS是否识别到所请求的服务作为在本地服务控制服务器上活动运行的服务，亦即具有一个与所请求的服务的逻辑名关联的对象引用。优选，在本地服务器高速缓冲存储器中存储的数据包括下面的NOS命名数据字段1)SLP逻辑服务名，它通常是说明服务的逻辑名和特征区分符数据指向的名；2)一个可选的版本号，它说明一个特定服务的版本，它可以例如为需要该版本的服务运行的一个特定用户或一个节点等需要；3)状态，包括已部署，亦即当SA已经给节点部署工作包，但是服务尚未激活；活动的，亦即指示该服务当前是活动的；或回退，当它希望回退到服务对象先前的版本，例如为提供一个迅速的逆转；4)对象名或参考，它可以包括一个IP地址、端口、和其它标识该对象实例的物理位置的信息；5)服务中的数据和时间和服务外的数据和时间；6)错误处理对象名，例如，如果该对象不可用或不能被激活；7)当在回退状态下要被执行的回退对象名。本地服务器NOS命名处理得益与由一个LRM状态处理器(未示出)提供的服务，该处理器只使用在服务控制服务器内一个特定SLEE内运行的当前活动的服务来更新本地服务器高速缓冲存储器状态数据库。这使得本地服务器NOS名字转换功能可以首先在本地执行。当NOS首先得到一个请求时，它查阅一个逻辑名来获得对象名(或对象引用)。NOS从逻辑名得到对象名，而节点LRM处理根据一个或者多个规则决定所请求的对象的最好的实例，其在步骤806指示。
如果在步骤804识别到逻辑名并且该逻辑对象可用，则处理前进到步骤806的LRM功能以决定在SLEE1上运行的S2的活动的(“可用的”)实例，根据一定的准则，诸如使用阈值。如果没有找到活动的实例，则LRM可以检验看是否编程S2在SLEE1上运行，但是尚未实例化。如果是这样的话，则NOS700可以决定实现SLEE1上的S2的一个实例，如果SLEE1有足够的可用容量的话。如前所述，在服务器级的LRM只知道在该服务器上什么是活动的和知道什么已经被实例化。如果该对象当前是活动的并且在本地服务器级实例化，则为实现为该服务的一个新线程的对象引用实例返回到SLP请求。NOS将根据返回的对象引用启动一个新服务线程的实例为执行所请求的服务，并如果尚未实例化的话返回一个对象引用。
如果在步骤804决定SLEE1没有足够的可用容量的话，或如果S2尚不能在SLEE1上运行的话，则在SLEE1上的LRM发送一个服务请求给场地LRM577a，(图10)。该场地LRM应用相似的业务规则并决定S2的一个实例是否在该场地的另一个SLEE上活动，或应该被实现。这样，在步骤810，节点NOS名字转换功能被实现，用于决定所请求的逻辑名是否在该节点可用，亦即在该节点的同一或不同的本地服务控制服务器上的另一个SLEE是否维护一个与所请求的服务的逻辑名关联的对象引用。如果在步骤810识别到该逻辑服务名，则NT子部件570询问NOS LRM 575以决定使用S2的哪一个实例。然后节点LRM在步骤814对节点高速缓冲存储器状态数据库(未示出)应用业务规则以便为所请求的服务检索希望的对象引用，如果活动的话，则给呼叫SLP返回该地址(步骤802，图11(a))。如果决定该服务当前不能实例化，或在一个特定的SLEE上需要的服务由于处理负载或者其它施加的限制可能不能被实例化，则在步骤818执行分配和加载处理，这通过检查节点高速缓冲存储器状态数据库和实现与例如服务接近性、数据接近性、施加阈值、当前处理负载等相关的可应用的业务规则，在决定服务对象可为实例化的场合在SLEE内实现所请求的服务实例，和给呼叫SLP返回地址。应该理解，当为实现每个SLEE实例有多于一个的服务可用时在决定哪一个服务线程要实例化中可以实现一个循环方案。
返回到图11(a)，如果在步骤810决定当前节点不能识别所请求的逻辑名，亦即，节点高速缓冲存储器没有与所请求的服务的逻辑名关联的对象引用，或者由于应用的业务规则，不能在该节点实现该对象实例，则在步骤822询问综合网络资源状态(NRS)处理590，在智能网络170的范围上检查SLEE的当前状态和决定可以处理为S2的服务请求的SLEE。在这之前，如在步骤820指示，进行检查，决定表示网络资源管理被询问以寻找一个对象引用的次数的索引数是否超过一个预定的限制，例如3次。如果已经超过该阈值，则处理终止，管理员可以通知不能找到服务对象和存在一个错误条件，如在步骤821所示。如果尚未超过NRS查询阈值，则如在步骤822所示，NRS处理决定在网络中的哪一个服务节点能够执行所请求的服务。在决定智能网络中的节点后，如在步骤822指示，处理继续到步骤824，图11(b)，在这里实现节点NOS名转换功能570b以获得与所请求的服务的逻辑名关联的一个对象引用。如果在步骤824不能识别在该节点的逻辑服务名，则在步骤829，NRS查询索引数加一，处理返回到步骤820，图11(a)，检查是否超过索引数阈值，如果是的话则存在错误条件。如果在步骤820，图11(a)，NRS查询索引尚未超过其预定阈值，则NRS处理590在步骤822被再次询问以寻找在另一服务节点的可用服务的一个新位置。
如果在步骤824识别到该逻辑名，则处理在步骤826继续，根据可接受的处理负载决定与所请求的对象引用关联的一个地址。然后把该地址返回到请求的SLP，其示于步骤802，图11(a)。如果在步骤826决定该服务当前不能被实例化(激活)，则处理前进到步骤828，允许一个分配和加载处理，这通过检查在该节点的节点高速缓冲存储器状态数据库768、实现业务规则，在决定服务对象可为实例化使用的场合在该SLEE内实现所请求的服务实例。接着，实现对象SLP实例的地址在步骤824返回给请求的客户。
一旦选择了S2的一个活动的实例，则为该S2实例的对象引用返回到SLEE1上的NT(步骤802)。该NT然后有效地转换逻辑名S2为为S2的选择的实例的一个对象标识符，并在在S1和S2之间进行处理间通信中使用为S2的对象标识符。对象标识符包括一个IP地址，端口，和标识该对象实例的物理位置的其它信息。一旦决定了一个对象引用，则NOS通过实现遵从CORBA的ORB和除去诸如UDP/IP的协议的数据通信连接提供在两个服务之间的对象连接性。被叫服务的位置，不管在同一个SLEE上运行还是在几千英里以外的另一个场地处的另一个SLEE上运行，对呼叫服务完全透明。这样，如果为服务一个呼叫需要的SLP在一个远程场地的SLEE上实例化，则该呼叫仍然在接收该呼叫的交换机上保持。优选，一旦一个对象引用例如在另一场地通过NRS级被访问一次，则NOS通过服务管理，保证该对象引用被高速缓冲存储到请求场地为将来参考和被审查。这样，在当前的例子中，为减少当该服务被再次需要而由启动一个场地LRM查阅引起的后继的查阅，为服务S2的对象引用，每当它被定位后，被高速缓冲存储到在SLEE1的LRM575的本地高速缓冲存储器中。对熟悉本技术领域的人显然，有很多方式在SLEE上提供服务对象引用数据。例如，可以使用一个NOS数据复制机构来复制在一个场地LRM577处的所有对象引用到为该场地的每一个SLEE的每一个LRM。
在1-800呼叫(“18C”)的范围中，现在参考图13(a)-13(c)的流程图和图18的概念功能示意图以例示的目的说明一个18C呼叫处理和服务使用方案。首先，如在步骤920所示，呼叫首先到达NGS交换机结构75。当NGS接收到一个呼叫时，载体控制部件(图5)给呼叫控制部件提供接收该呼叫的一个访问线路，以及ANI，拨的号码，和为呼叫处理需要的其它数据。呼叫控制部件为该呼叫维护一个状态模型，其根据它的编程逻辑执行。另外在状态模型中包括的是为实现一个ELP540实例和给FD510发送服务请求的触发器，其示于图18。为实现一个ELP实例，NGS呼叫控制部件90给NOS发送消息，使用为一个ELP的逻辑名，其在图13(a)中的步骤923指示。NOS作为响应，给服务管理器对象(图8)发送一个消息，在一个SLEE中实现一个ELP实例并返回为该ELP的一个对象引用给呼叫控制，如在步骤926指示。NGS呼叫控制部件包括该对象引用在一个服务请求消息中，该消息被发送到在SLEE中的FD，其在步骤929指示。这样，由任何处理为该呼叫产生的所有合格的事件数据都写入实例化的ELP处理中。特别是，服务请求消息送给为FD的逻辑名；该逻辑名由NOS NT部件转换为为一个FD逻辑程序的物理地址，该逻辑程序运行在接收到该呼叫的同一个服务节点上。在服务请求消息中包含的是拨叫的号码，ANI，和其它数据。
接着，如在步骤931所示，FD使用其特征区分表来识别哪一个SLP处理接收到的服务请求。例如，如果接收到的消息是一个18C服务请求，则其由18C SLP处理。下面的表3是一个节录的FD表的例子，具有包括指向各种“免费”的指针的条目，例如，1-800，呼叫服务。
入口端口表“001001”SLP指针′Vnet′“001002”指向FGD表的表指针FGD表
1800*表指针800表1888*表指针800表1900*表指针900表1*SLP指针‘本地号码’800表1800收集SLP指向‘1-800-C’的指针18008888000SLP指向‘Op服务’的指针1800* SLP指向‘800服务’的指针1888* SLP指向‘800服务’的指针这里，FGD是一个特征组区分器。特别，根据该呼叫在网络中何处始发(交换机板)和接收到的呼叫的类型(例如1-800)，FD将决定一个合适的SLP逻辑名，例如，标识“001002”’指示接收一个需要查阅FGD表(指向FGD表的指针)的呼叫。FGD表依赖被叫号码例如800*依次维护指向其它表的指针，这里*是一个定界符。从该800表，例如FD获得指向被请求的SLP逻辑名的指针。随后，该SLP被调用，该服务请求被交给NOS，后者根据所请求的18C服务实现一个CLP545、LLPO530和SLP520对象实例。例如，对于LLPO，根据在其上接收到该呼叫的载体控制线路给NOS提供为该LLPO的一个逻辑名。该线路的标识既可以根据ANI，也可以根据由载体控制部件80识别的访问线。ANI识别启动该呼叫的始发访问线，其可以是也可以不是NGS接收该呼叫的同一条访问线，亦即所接收到的呼叫可以始发于一个本地网络，例如，并传送给在一个交换间的载体网络上的交换机75。因此，与该线关联的特征，诸如呼叫等待或呼叫中断可以由该ANI识别。NOS为LLPO的逻辑名是一个物理地址，用于实现一个LLPO实例。虽然其它逻辑程序(诸如SLP)可以在其它场地实例化，但是LLP在它们关联的线所在的场地实例化。LLP在可以在一个服务控制服务器上或者在一个呼叫控制服务器上的SLEE内实例化。一旦实例被实现，则LLPO询问数据管理与该线关联的特征，维护始发线的状态，并当诸如呼叫等待或溢出路由选择这些特征由呼叫者(亦即呼叫等待)或网络(亦即溢出路由选择)调用时调用任何这些特征。
参考步骤934，图13(a)，NOS从特征区分器接收一个服务请求切换请求，包含表示要被调用的特定服务例如18C的逻辑名。NOS识别该请求包含一个逻辑名并在它的实例表(未示出)内查找以决定它是否具有任何可用的SLP处理以服务这一服务请求。它还通过NOS LRM功能识别所请求类型的哪一个实例要使用，如在步骤937指示。然后，如在步骤941指示，NOS给运行在一个服务控制SLEE上的服务管理者对象发送一个请求以调用所请求的18C SLP服务。在该优选的实施例中，NOS从一个服务控制服务器选择SLP，该服务器从NGS接收始发到来的服务请求通知，然而，应该理解，NOS可以通过实现NOS LRM和根据它的服务控制实例表和它们当前的状态在任何服务控制部件内选择SLP。如在步骤943指示，NOS决定所选择的SLP是否已经实例化和如果所选择的SLP尚未实例化的话，将指导SM实现该SLP对象实例，如在步骤946指示。否则，如果所选择的SLP已经实例化，则线程管理器给该SLP对象指定一个新的处理线程，如在步骤945所示。
图13(b)的下一步骤949需要实例化的SLP处理将其物理地址向NOS注册，以及NOS分配该SLP给服务请求。然后，NOS把服务请求切换消息传送给该新SLP，其在步骤951指示。与此并行，NOS给实例化的CLP发送所有数据，包括为该实例化的SLP、ELP、和LLPO对象的对象引用。还给LLPO和SLP提供为CLP和ELP的对象引用，以便LLPO和SLP可以与CLP和ELP接口。最后，如在步骤954指示，SLP然后开始按照它编程的逻辑处理该呼叫。
在18C呼叫的环境中，18C SLP 520优选从一个18C路由选择数据库(未示出)获得必需的数据来作出合适的决定。如图13(c)所示，18C SLP 520调用下面的步骤在步骤960给NOS NT发送一个它需要的为18C路由选择数据库的逻辑名；用该逻辑18C路由选择数据库名查询DM并从DM接收实际的18C路由选择DB名及其存储的位置，其在步骤962指示；请求NOS LRM看18C路由选择数据库是否可在本地使用，如在步骤964所示，如果是的话，则返回18C数据库的物理地址给18C SLP，其示于步骤966；通过发送被呼叫的800号码、线路ID、始发交换机中继线、和ANI给数据管理发送关于用户简档查阅的询问，如在步骤968指示；从DM接收包括交换机/中继线的最后的路由选择信息回到18C SLP，如在步骤970指示，在步骤972，请求DM查阅在路由选择响应中指定的终止的实际终止位置(节点)并从DM接收实际终止节点位置。之后，过程需要给ELP510发送路由选择响应信息为在呼叫上下文数据中放置，例如在DM中存储，和使用切换命令给CLP545发送一个包括路由选择信息的拨出(outdial)请求。在这一方案中，终止节点可以是远程的，在该种场合必须实现在该远程节点上的终止LLP实例和执行简档查阅以决定在终止线路上的任何特征。在其它服务流程方案中，SLP可能必须调用一个或者更多其它SLP。
一旦SLP决定为一个呼叫的网络终止，或反之决定为资源集合设备采取一个动作，例如检测DTMF数字或播放声音，则它发送一个服务响应消息给NGS呼叫控制，如在步骤957指示。然后呼叫控制执行指令，该指令可以包括指示NGS交换机75′(图14)设定和完成该呼叫到一个网络终止，其在步骤959所示。
更特别的是，实现一个拨出/挂断切换(outdial/handoff)过程，它需要CLP545使用切换命令给LLPO(始发线路)发送该拨出，其传递给在呼叫交换机处的一个NOS代理，后者把该呼叫引导到终止节点。然后ELP处理写该拨出l呼叫上下文数据到DM。
回过来参考步骤957，如果SLP给呼叫控制返回为一个网络终止的物理地址，则为对其终止呼叫的该线路实现一个LLPT处理实例531。这通过允许NOS把为该LLPT的一个逻辑名与由该SLP提供的网络终止关联而实现；这一逻辑名提供给NOS要么通过该SLP(在一个实施例中)或者通过在一个对FD的服务请求中的呼叫控制(在另一个实施例中)。NOS依次在存在终止线路的服务节点处的一个SLEE中实现该LLPT实例。
或者，在步骤957，SLP可以代之以返回一个为一个特定资源的请求，例如在处理18C呼叫的例子中一个IVR功能。NGS决定哪一个资源要被分配，亦即哪一个交换机端口具有IVR能力，VRU端口等，并给SLP返回为该资源的一个地址。然后该SLP识别为与该资源关联的LLPT的一个地址(通过对数据管理的询问)和请求实现该LLPT实例。然后把该呼叫引导到该资源并处理，也许用对NGIN的另一服务请求。
当该呼叫完成后(亦即当双方断开连接后)，LLP从在每一交换机75、75′(图14)处的NOS部件接收一个呼叫完成通知，并把该呼叫完成通知传送给CLP。CLP把该呼叫完成通知传送给相关的LLP和ELP，并当由CLP通知触发时被杀死。在其终止前，可以首先存储ELP呼叫详情数据，该数据需要在呼叫完成后被维护，例如用于出帐单和各种其它目的。
上面详细说明了几种优选的实施例。应该理解，本发明的范围也包括与所述实施例不同但在权利要求的范围内的实施例。
例如，通用计算机被理解为是一种计算设备，它不是为一类应用专门制造。通用计算机可以是任何大小的任何计算设备，其可以执行为实现本发明所需要的功能。
一个另外的例子是“Java”编程语言可以用其它具有类似特征和执行与实现本发明所需要的类似功能的等价的编程语言代替。
这些术语以及其它术语在这里的使用不意味着限制本发明到单独这些术语。所使用的术语可以与同义的和/或指等价事情的其它术语互换。包含的词汇在考虑本发明的范围时应该解释为非穷举的。还应该理解，本发明的各种实施例使用硬件、软件或微编码固件或用它们实现。
虽然本发明结合上述实施例公开和讨论，但是对于熟悉本技术领域的人十分明显，在本发明的精神和范围内可以进行大量的改变、变化和修改。因此，打算用下面的权利要求包含这种变化和修改。
权利要求
1.一种用于具有多个服务节点的通信网络控制系统，每一个节点具有一个存储器存储设备，和一个执行环境，用于响应在与一个服务节点关联的一个网络交换机单元上接收到一个事件执行服务，所述系统包括一个服务管理器设备，用于在每一节点上产生一个服务简档，服务简档包括与在每一节点的服务处理相关的服务对象资源的类型和数量，和根据所述简档下载服务对象资源的所述类型和数量到所述节点；实例化机构，用于实现服务对象实例而在所述一个或者多个执行环境中执行；和资源管理设备，用于跟踪一个服务节点的执行环境资源，和维护在所述网络内的每一服务节点可用的服务类型表，每一服务类型具有一个相关的能力状态，它指示一个请求的服务是否可用于在一个服务节点实例化，其中，当所述能力状态指示一个所请求的服务不可用于在所述网络中实例化时，所述资源管理设备对所述中心管理器设备通信，说明需要实现新服务对象实例以下载和激活在一个服务节点处的新服务。
2.如权利要求1所述系统，其中，所述实例化机构包括一个第一对象，用于从所述存储器存储系统加载一个或者多个服务对象并为在所述执行环境中执行而实现所述一个或者多个对象实例；相应于一个特定服务的一个第二对象，用于为相应于每一接收到的所述服务请求的每一服务实例分配一个或者多个服务线程，每一服务线程实例具有一个唯一的与之关联的标识符。
3.如权利要求2所述系统，另外包括一个网络操作系统，用于在执行对象实例之间提供实时通信消息和事件，所述第二对象相应于为在所述服务实例之间的事件和消息提供通道的特定服务，所述事件和消息包括所述唯一的标识符以协调接收到的消息和事件到适当的服务实例。
4.如权利要求3所述系统，另外包括为每一服务线程实例分配的一个事件队列机构，用于排队与所述在服务执行过程中接收到的服务实例关联的事件，其中，事件具有相关的优先级，指示所述事件应该被执行的顺序，所述事件队列设备允许按照其相关的优先级处理接收的事件。
5.如权利要求3所述系统，另外包括一个类加载器处理，用于从所述存储器存储系统根据一个为所述服务节点实现初始服务能力的配置文件最初加载一个或者多个服务对象，所述类加载器负责根据一个预定的服务能力策略实现要成为可用的所述第一对象和任何服务对象实例。
6.如权利要求3所述系统，其中，所述相应于一个特定服务的第二对象包括线程管理器实例，用于比较与一个服务关联的线程实例的数量与在所述服务简档决定的一个预定的阈值，并当所述执行环境不再支持实现新服务线程实例时给所述资源管理设备产生警告信号。
7.如权利要求6所述系统，其中，所述服务对象实例化机构包括所述网络操作系统，所述资源管理设备另外跟踪在每一服务节点处的执行环境的处理能力并给所述网络操作系统提供一个指示，指示在一个服务节点处的执行环境是否可以根据其处理能力执行一个服务。
8.如权利要求7所述系统，其中，当在一个执行环境处当前执行的服务线程的数目超过所述预定阈值时，所述资源管理设备进一步给所述网络操作系统通信一个过载状态，并防止在所述执行环境实现另外的服务对象实例。
9.如权利要求3所述系统，其中，所述实例化机构包括一个相应于在每一所述执行环境处的一个执行环境中执行的服务的实例的活动的服务对象线程的注册表，映射设备，用于以一个对象引用映射一个服务逻辑名，所述网络操作系统使用所述对象引用来允许实现在一个本地执行环境中的一个所请求的服务对象线程实例。
10.一种提供在通信网络中的服务节点上的服务的方法，每一个服务节点具有一个存储器存储设备，和一个执行环境，用于响应在与一个服务节点关联的一个网络交换机单元上一个事件的接收而执行服务，所述方法包括为每一服务节点产生一个服务简档，服务简档包括与在每一节点的服务处理相关的服务对象资源的类型和数量，和根据所述简档下载服务对象资源的所述类型和数量到所述节点；实现服务对象实例，为在所述一个或者多个执行环境中执行；跟踪在一个服务节点的执行环境资源，通过维护在每一服务节点可用的服务类型表实现，每一服务类型具有一个相关的能力状态，它指示一个被请求的服务是否可用于在一个服务节点实例化，其中，当所述能力状态指示一个所请求的服务不可用于在所述网络中实例化时，给中心管理设备通信需要实现新服务对象实例，从而下载和激活在一个服务节点处的新服务对象。
11.如权利要求10所述方法，其中，所述实例化步骤包括提供一个第一对象，用于从所述存储器存储系统加载一个或者多个服务对象并为根据接收到的服务请求在所述执行环境内执行而实现所述一个或者多个对象实例；提供相应于一个特定服务的一个第二对象，用于为相应于每一接收到的所述服务请求的每一服务实例分配一个或者多个服务线程，每一服务线程实例具有一个唯一的与之关联的标识符。
12.如权利要求11所述方法，另外包括在一个或者多个执行服务对象之间通信在服务对象执行期间产生的消息和事件以支持服务处理的步骤，所述事件和消息由所述唯一的标识符标识以通过所述第二对象正确地执行服务实例。
13.如权利要求12所述方法，另外包括排队与在服务执行过程中接收到的一个执行服务实例关联的事件的步骤，所述事件具有相关的优先级，指示所述事件应该被执行的顺序，其中，所述接收到的事件按照其相应的优先级处理。
14.如权利要求10所述方法，另外包括从所述存储器存储系统根据一个为所述服务节点提供初始服务能力的配置文件最初加载一个或者多个服务对象，所述类加载器负责根据一个预定的服务能力策略实现要成为可用的所述第一对象和任何服务对象实例。
15.如权利要求11所述方法，其中，所述跟踪在一个服务节点处执行环境资源的步骤包括比较与一个服务关联的线程实例的数量与在所述服务简档中决定的一个预定的阈值；当一个执行环境不再支持实现新服务线程实例时给资源管理设备产生一个警告信号。
16.如权利要求10所述方法，其中，所述实例化机构包括维护相应于在每一所述服务节点的一个执行环境中执行的服务实例的活动的服务对象线程的注册表，映射一个服务逻辑名与一个对象引用；使用所述对象引用允许实现在一个本地执行环境中的一个所请求的服务对象线程实例。
全文摘要
提供在智能网络中的一个交换机(159)上接收的实时呼叫处理服务的系统和方法,所述网络具有一个或者多个服务节点(204),节点具有始发交换机用于接收呼叫事件。所述系统包括一个平台独立的通信系统,用于允许在在该智能网络中的服务节点(204)上执行的对象实例之间通信。一个在与始发端交换机关联的执行环境中执行的操作系统代理对象(204)实例通信相应于在该交换机接收的呼叫事件的始发端信息给在该网络中一个服务节点(204)上提供的执行环境中执行的一个或者多个对象实例;该对象实例包括一个线路对象实例,用于维护与一个呼叫始发关联的一条通信线路的状态,和服务对象实现根据用户请求执行服务的方法。
文档编号H04Q3/545GK1334939SQ99814463
公开日2002年2月6日 申请日期1999年10月20日 优先权日1998年10月20日
发明者阿贾伊·蒂欧, 温迪·黄, 亨利·王, 萨米·西德 申请人:阿贾伊·蒂欧, 温迪·黄, 亨利·王, 萨米·西德