CN1706204A - 用于信令事件的业务逻辑环境高速缓存 - Google Patents

Abstract

一种在电话系统中共享信令事件数据的方法，能包括：在第一业务逻辑部件内接收来自一个电话信令网的事件。对该事件能确定事件环境并将该事件环境异步存储在一个事件环境高速缓存中，该高速缓存与至少所述第一业务逻辑部件及第二业务逻辑部件在通信上链接。

Description

用于信令事件的业务逻辑 环境高速缓存

技术领域

本发明涉及电话领域，更具体地说，涉及电话网中各业务逻辑部件之间的信息交换。

背景技术

电信公司不断地创建要向用户提供的新电话业务和/或性能(下文中称作“业务”)。这些业务往往需要多个业务逻辑部件之间的交互作用。一个普通的例子是呼叫控制业务逻辑和事务(transaction)业务逻辑。呼叫控制业务逻辑与建立电话呼叫的话音通信方面相关联，而事务业务逻辑为电话业务的非话音处理方面提供基础，如800号码翻译、数据库查询、短消息业务(SMS)、本地号码可移植性，以及其它基于事务的业务或业务组件。这样，为实现给定的电话业务，呼叫控制业务逻辑往往必须与事务业务逻辑交互作用。

例如，作为事务业务逻辑进行的号码翻译的结果，一个电话呼叫要被转接到另一个电话号码，那么呼叫控制业务逻辑必须能从事务业务逻辑得到呼叫转接信息。就是说，响应一个电话呼叫的接收，呼叫控制业务逻辑必须查询发端业务，在这一情况中是事务业务逻辑，以确定如何处理该电话呼叫。传统上，不同业务逻辑部件之间的交互作用是通过使用业务到业务消息传递协议实现的。

通过业务到业务消息传递协议，一个接收业务能确定关于给定电话呼叫的环境(contextual)信息。于是，该接收业务，在这一情况中是呼叫控制业务逻辑，根据环境信息，能处理该电话呼叫。然而，业务到业务消息传递机制有一些缺点。一个这样的缺点是发端业务必须保持在现用状态，以向任何需要环境信息来完成一个呼叫的任何接收业务以多消息形式提供信息。发端业务成为“主方”，而接收业务成为“从方”。发端业务保持现用状态只是为了提供接收业务所需要的消息传递功能，尽管发端业务的最初功能已经完成。结果，在业务到业务使用期内消耗了昂贵的存储器和处理器资源。

另一个缺点是更新业务到业务消息传递协议的费用会很高。值得注意的是，每个依靠业务到业务消息传递协议的业务逻辑部件必须与协议本身一起被更新。这样，对于一个给定的协议增强，至少两个业务逻辑部件必须被更新。结果，在一个电话网内的多个节点可能不得不经受协调的更新过程。

这些类型的问题已成为发展智能网(IN)和高级智能网(AIN)的障碍。尽管已经开发了多个协议，如SR-3511、1129 CORE、CORE INAP等，但尚未出现国际标准。此外，维护业务控制点(SCP)的成本模型已开始与维护电话交换机的成本模型相匹配。而且，由于使用SCP成本模型实现的业务对资源敏感，所以在业务到业务使用期对利用存储器和处理器资源的需求增大了业务的实现、布署和维护成本。

发明内容

本发明提供在电话系统中两个或更多个业务逻辑部件之间共享信令事件数据的解决方案。例如，本发明能作用电话环境中的呼叫处理系统和事务处理系统之间的接口。特别是，一个事件环境(context)高速缓存能在通信上与电话系统中的两个或更多个业务逻辑部件链接。这样，本发明能消除对每个电话业务部件内协调实现业务到业务消息传递协议的需求。业务逻辑部件能在事件环境高速缓存内建立条目，然后处理其它事件。其它业务逻辑部件能访问事件环境高速缓存内的信息。于是，发端业务逻辑部件不需保持聚焦或继续执行而只是为了向其它业务逻辑部件提供呼叫处理指令消息。

本发明的一个方面能包括一种在电话系统中共享信令事件数据的方法。该方法能包括：在第一业务逻辑部件内接收一个来自电话信令网的事件，确定该事件的事件环境，并将该事件环境存储在与第一业务逻辑部件及至少一个第二业务逻辑部件在通信上链接的事件环境高速缓存中。

第一业务逻辑部件可以是一个包括ISDN和/或用户部分接口(ISUP)的呼叫处理系统。第二业务逻辑部件可以是包括事务能力应用部分(TCAP)接口的事务处理系统。电话信令网可以是7号信令系统网。于是，当事件是TCAP事件时，确定事件数据的步骤可以包括根据所接收的TCAP事件识别被拔号码入站业务，被呼叫的电话号码以及至少一个要执行的电话业务。

该方法能够进一步包括接收一个后续的TCAP事件，确定在事件环境高速缓存中是否存在该后续TCAP事件的事件环境，如果不存在，则确定该后续TCAP事件的事件环境。该后续TCAP事件的事件环境能够指定被拨号码入站业务、被呼叫的电话号码以及至少一个要执行的电话业务。该事件环境能被存储在事件环境高速缓存中。于是，呼叫处理部件能访问该事件环境高速缓存以确定如何处理一个被转接的呼叫。

本发明的另一方面能够包括一种在电话系统中共享信令事件数据的方法，该方法包括接收一个呼叫并确定在事件环境高速缓存中是否存在与所接收的呼叫关联的事件环境。例如，该确定步骤能够包括从该呼叫识别被拨号码的入站业务和被呼叫的电话号码，并根据被拨号码入站业务和被呼叫的电话号码搜索事件环境高速缓存。如果在事件环境高速缓存中存在一个条目，则该事件能被检索出来。例如，为处理所接收的呼叫要执行的话音标记语言脚本的位置能被识别出来。如果该事件指定属性，则这些属性能被识别提供给执行中的话音标记语言脚本。如果对于所接收的呼叫在事件环境高速缓存中不存在事件环境，则能执行一个呼叫恢复机制。

本发明的另一方面能够包括一个电话系统，该系统包括第一业务逻辑部件、第二业务逻辑部件以及与第一业务逻辑部件及第二业务逻辑部件在通信上链接的事件环境高速缓存。第一业务逻辑部件可以是被配置成处理ISUP事件的呼叫处理系统。第二业务逻辑部件可以是被配置成处理TCAP事件的事务处理系统。该事件环境高速缓存能在第一业务逻辑部件和第二业务逻辑部件之间提供信息交换，而无需业务到业务消息传递协议。

本发明的另一方面能包括一个电话系统，该系统包括具有用于执行电话业务的话音标记语言脚本实现的分布式逻辑环境的呼叫处理部件和具有用于执行电话业务的TCAP标记语言脚本实现的分布式逻辑环境的事务处理部件。呼叫处理部件和事务处理部件能由事件环境高速缓存在通信上链接。

该呼叫处理部件能够包括被配置成接收呼叫的呼叫处理器单元。该呼叫处理器单元能包括对与电话号码关联的电话业务的话音标记语言文档实现的地址。该呼叫处理部件还能包括一个语音标记语言语法分析器，其被配置成响应对呼叫的接收，从这些地址检索话音标记语言文档并对该话音标记语言文档进行语法分析。该呼叫处理部件能进一步包括一个业务处理器，其被配置成执行语法分析后的话音标记语言文档以实现这些电话业务，以及至少一个会话管理器，其被配置成协调话音标记语言语法分析器和业务处理器的操作。

事务处理部件能够包括一个事务业务处理器，它具有与电话号码关联的电话业务的TCAP话音标记语言脚本实现的地址。该事务业务处理器能够被配置成执行实现电话业务的语法分析后的TCAP标记语言脚本。该事务处理部件还能包括一个TCAP标记语言语法分析器和至少一个事务会话管理器。TCAP标记语言语法分析器能被配置成从这些地址中检索电话业务的TCAP标记语言脚本实现并对这些TCAP标记语言脚本进行语法分析。事务会话管理器能够配置成协调TCAP标记语言语法分析器和事务业务处理器的操作。

从另一方面看，本发明提供一个机器可读存储器，在其上存在了一个具有多个代码段的计算机程序，所述代码段可由机器执行以使机器进行如下步骤：在第一业务逻辑部件内从电话信令网接收一个事件；确定用于所述事件的事件环境；并将所述事件环境存储在一个事件环境高速缓存中，该高速缓存与所述第一业务逻辑部件及至少一个第二业务逻辑部件在通信上链接。

优选地，本发明提供一个机器可读存储器，其中，所述第一业务逻辑部件是一个呼叫处理系统，所述第二业务逻辑部件是一个事务处理系统。

优选地，本发明提供一个机器可读存储器，其中，所述呼叫处理系统包含ISDN接口和ISUP接口二者中的至少一个，所述事务处理系统包含一个TCAP接口，而所述电话信令网是7号信令系统网。

优选地，本发明提供一个机器可读存储器，其中，所述事件是TCAP事件，所述确定事件数据步骤进一步包括：从所述接收的TCAP事件中识别出一个被拨号码入站业务、一个被呼叫的电话号码以及至少一个要执行的电话业务。

优选地，本发明提供一个机器可读存储器，进一步包括：接收一个后续TCAP事件；确定在所述事件环境高速缓存中是否存在所述后续TCAP事件的事件环境；如果不存在，则为所述后续TCAP事件确定一个事件环境，用以指定被拨号码入站业务、被呼叫的电话号码以及至少一个要执行的电话业务，并将所述事件环境存储在所述事件环境高速缓存。

优选地，本发明提供一个机器可读存储器，进一步包括：所述呼叫处理部件访问所述事件环境高速缓存，以确定如何处理一个被转接的呼叫。

从另一方面看，本发明提供一个机器可读存储器，在其上存储了一个具有多个代码段的计算机程序，所述代码段可由机器执行以使机器进行如下步骤：接收一个呼叫；确定在事件环境高速缓存中是否存在与所述接收的呼叫关联的事件环境；如果是，则从所述事件环境高速缓存中检索所述事件环境；如果否，则执行一个呼叫恢复机制。

优选地，本发明提供一个机器可读存储器，所述确定步骤进一步包括：从所述呼叫中识别出被拨号码入站业务和被呼叫的电话号码；以及根据所述被拨号码入站业务和所述被呼叫的电话号码搜索所述事件环境高速缓存。

优选地，本发明提供一个机器可读存储器，所述检索步骤进一步包括：识别话音标记语言脚本的位置以执行处理所述接收的呼叫。

优选地，本发明提供一个机器可读存储器，所述识别步骤进一步包识别由所述事件环境指定的属性，其中所述属性被提供给执行中的所述音标记语言脚本。

附图说明

现在将参考附图只以举例方式描述本发明，在附图中：

图1是示意图，示出了根据本发明的一个优选实施例的位于两个业务逻辑部件之间的事件环境高速缓存。

图2是示意图，示出了根据本发明的一个优选实施例的位于一个电话业务系统的呼叫处理部件和事务处理部件之间的事件环境高速缓存。

图3是示意图，示出了根据本发明的一个优选实施例的具有呼叫处理部件和事务处理部件的系统。

图4是流程图，显示根据本发明一个优选实施例的由图3的系统执行的处理从信令网接收的事务事件的方法。

图5是流程图，示出了根据本发明的一个优选实施例的由图3的系统执行的呼叫处理的方法。

具体实施方式

本发明提供在电话系统中两个或更多个业务逻辑部件之间共享信令事件数据的解决方案。例如，本发明能作用电话环境中的呼叫处理系统和事务处理系统之间的接口。特别是，一个事件环境高速缓存能与电话系统中的两个或更多个业务逻辑部件在通信上链接。通过存储事件环境信息，各业务逻辑部件经由事件环境高速缓存进行通信，其中所述的信息能向其它业务逻辑部件指示如何处理所接收的呼叫。

图1是示意图，示出了根据这里公开的发明安排的系统10，它具有位于两个业务逻辑部件15和20之间的事件环境高速缓存25。事件环境高速缓存25能作为一个或多个分布式计算机系统、存储设备和/或存贮设备来实现，它们能与业务逻辑部件15和20在通信上链接。这样，事件环境高速缓存25能用于代替业务到业务消息传递协议。于是，例如，随着各种信令事件被业务逻辑部件15接收，关于所接收事件的信息能被作为条目放在事件环境高速缓存25中。这样，不是业务逻辑部件15保持在现用状态或“在可及之处(in scope)”以响应其后来自业务逻辑部件20的查询，而是业务逻辑部件15的资源能被贡献于另一个事件和/或业务，因为业务逻辑部件20能咨询事件环境高速缓存25以确定信令事件信息。值得注意的是，尽管显示了两个业务逻辑部件，但本领域技术人员将会理解，多于两个的业务逻辑部件能与事件环境高速缓存25在通信上链接。

图2是示意图，显示根据这里公开的发明安排的系统50，它具有位于电话业务系统的呼叫处理业务部件55和事务处理业务部件60之间的事件环境高速缓存65。呼叫处理业务部件55能包括一个ISDN用户部分(ISUP)接口。事务处理业务部件60能包括一个事务能力应用部分(TCAP)接口。

在操作过程中，事务处理业务部件60能接收TCAP事件。事务处理业务部件60能访问事件环境高速缓存65以确定在事件环境高速缓存中是否存在与所接收的TCAP事件关联的事件环境。如果是，则事件处理业务部件60能对该事件环境高速缓存条目进行刷新。如果否，则事务处理业务部件60能在事件环境高速缓存65中放入一个新条目。例如，事务处理业务部件60能在事件环境高速缓存65中放入一个条目，该条目指定被拨号码入站业务(DNIS)、被呼叫的号码以及任何呼叫处理应用、脚本和/或为执行这些呼叫处理应用和脚本所需要的相关数据。

响应TCAP事件，事务处理业务部件60能确定一个呼叫要被转接到与DNIS关联的话音邮箱。于是，事务处理业务部件60能确定该呼叫要转接到的电话号码以及为处理被转接的呼叫要执行的任何应用。这样，在该情况中，该事务处理业务部件能在事件环境高速缓存中建立一个条目，该条目指定DNIS、主叫号码、呼叫要被转接到的电话号码以及任何应用和应用参数。

呼叫处理业务部件55在收到该呼叫时，能使用由入局的呼叫所指定的DNIS和主叫电话号码，查询事件环境高速缓存65。呼叫处理业务部件55能得到诸如呼叫要被转接到的电话号码以及要执行的任何应用及应用参数等信息。事件环境高速缓存条目只需保留若干秒钟，使得接收业务部件，在该情况中是呼叫处理业务部件55，能访问为处理所接收的呼叫而需要的信息。否则，如果在事件环境高速缓存65中没有用于所接收呼叫的条目，则呼叫处理业务部件能执行恢复机制，如挂掉该呼叫、向呼叫方发出一个消息、把该呼叫转移到与DNIS关联的话音邮件等。

图3是示意图，显示根据这里公开的发明安排用于实现电话业务和/或性能(下文中称作“业务”)的示例性的系统100。如图3中所示，系统100能包括呼叫控制部件102以及事务处理部件104。呼叫控制部件102和事务处理部件104能通过高速缓存260在通信上链接。

呼叫控制部件102能包括介质网关105、bean/script应用(业务处理器)115、会话管理器120、VXML语法分析器125、超文本传输协议(HTTP)服务器130以及数据存储135。数据存储135能包括一个或多个VXML脚本用于指定文档、音频和文本等。VXML脚本，例如脚本109，是用于指定电话业务的呼叫控制方面的脚本实现。在数据存储135内的VXML脚本能通过HTTP服务器130被访问。应该理解，虽然数据存储135被描述成单个数据存储，但它能被实现为一个或多个分布式数据存储。

介质网关105能与一个或多个通信干线(未示出)在通信上链接，如T1线路和/或ISDN线路。每个入局的通信干线能与信道处理器160对接，信道处理器160用作介质网关105和通信干线之间的接口。对于相应电话交换机的每个话音电路，能包括一个信道处理器160。介质网关105还能包括一个应用表107和一个bean/script接口110。应用表107能指定DNIS之间的关联，以及数据存储135中存储的电话业务的VXML脚本实现。更具体地说，应用表107保持DNIS和DNIS已被注册的电话业务的列表。应用表107进一步指定能从中检索电话业务的各种VXML脚本实现的网络位置。

于是，当收到一个入局的呼叫时，介质网关105能确定由入局的呼叫所指定的DNIS。采用“应用表”107，该DNIS能与一个或多个VXML脚本匹配。这样，便能识别出该DNIS已被注册的那些电话业务VXML脚本实现的位置或地址。电话业务的VXML脚本的位置能被提供给会话管理器120。

介质网关105还能包括7号信令系统(SS7)接口165。SS7接口165能包括消息传送部分(MTP)接口以及ISDN用户部分接口(ISUP)。介质网关165的SS7接口165能支持为建立和撤销呼叫所必需的那些协议并且支持语音通信。例如，MTP接口能支持物理层、数据链路层和网络层协议。MTP接口能有助于在两个通信端点之间可靠地交换信令消息。通过使用MTP，可以完成端点之间的流程控制、差错检验和消息排序等任务。MTP接口还能通过执行寻址、路由选择和拥塞控制来提供保证信令点之间的递送所必须的业务。ISUP接口能提供必要的呼叫控制业务，这些业务能用于建立和终止经由PSTN的呼叫。值得注意的是，ISUP接口能用于确定哪些过程适于在信令网上建立、保持和撤销长途呼叫(trunk call)。

在介质网关105中能包括bean/script接口110，它能包括桥接业务或功能，用于连接一个局域网(LAN)和另一个局域网。Bean/script接口110能有助于业务处理器115和介质网关105的其它部件(如信道处理器160和话音接口140)之间的通信。Bean/script接口110能被配置成支持可通过将被讨论的业务处理器115解释的VXML脚本提供的功能范围。值得注意的是，由于VXML脚本能支持扩展的呼叫控制和TCAP功能，所以Bean/script接口110也能被配置成支持那些呼叫控制和TCAP功能。话音接口140能提供话音识别以及文本到话音(TTS)功能。于是，通过电信中继线接收的话音能被转换成文本，而文本数据能被转换成音频流，以通过电信中继线提供给一个或多个用户。

放到一起，业务处理器115、会话管理器120以及VXML语法分析器125提供一个分布式话音浏览器的部件。VXML语法分析器125能在运行时被例示并能通过HTTP服务器130从数据存储135中检索VXML脚本。VXML语法分析器125能把检索出的VXML脚本转换成一种中间格式，这种格式能被映射到业务处理器115并由业务处理器115解释。值得注意的是，VXML脚本能被增强为包括一些新标记，这些标记定义TCAP事务，如允许呼叫、阻塞呼叫、转移呼叫、选择性转移呼叫以及桥接呼叫。于是，VXML语法分析器125也能被配置成识别对VXML脚本的任何附加的标记增强。

业务处理器115可以是可再用的软件部件，它们能与分布式计算环境中的同一个或不同的计算机系统中的其它部件组合。一个业务处理器115能为每个信道处理器160在运行时被例示，从而能与特定信道处理器关联。这些业务处理器115有效地用作解释器，它们为分析后的VXML脚本提供执行环境以实现由VXML脚本指定的电话业务。于是，业务处理器115使介质网关105的内部功能与电话业务的分析后的VXML脚本表现相匹配。如图中所示，业务处理器115能与介质网关105的话音接口140在通信上链接。这样，业务处理器115能访问TTS和话音识别功能，以实现由分析后的VXML脚本指定的电话业务。例如，文本和识别出的话音能被用于填写VXML脚本、表格和/或文档中的字段。

值得注意的是，业务处理器115和VXML语法分析器125能分别在Java虚拟机145和155内执行。虽然图1描述的是在单个Java虚拟机145和155内执行的多个业务处理器115和VXML语法分析器125，但每个业务处理器115和VXML语法分析器125能在各自的单个Java虚拟机内执行，从而最大限度地减小在一个程序内发生的错误将负面影响另一个程序的危险。

每个业务处理器115和VXML语法分析器125能注册到会话管理器120。因此，会话管理器120能跟踪哪些业务处理器115和VXML语法分析器125可用于呼叫处理。会话管理器120进一步能协调一对业务处理器115/WXML语法分析器125的操作。会话管理器120能在业务处理器115和VXML语法分析器125之间传送信息。特别是，从介质网关105提供给会话管理器120的请求能包括被呼叫的电话号码、一个或多个统一资源标识符(URI)(包括统一资源定位器(URL))，其用于指定电话业务的脚本表现、以及代表在其上接收呼叫的特定信道处理器的标识符。会话管理器120能把这些信息保存在局部数据存储中。这样，会话管理器120能确定一个空闲VXML语法分析器125，以便能向它提供所接收的URI。此外，根据所保存的URI、被呼叫的电话号码以及信道处理器标识符，来自VXML语法分析器125的结果能回送给适当的业务处理器115。

如业务处理器115和VXML语法分析器125的情况那样，多个会话管理器120能在单一Java虚拟机内执行，或每个会话管理器120能在一个单独Java虚拟机内执行。在任何情况中，如前所述，业务处理器115、会话管理器120和VXML语法分析器125能存在于分布在整个计算网络中的各单独计算机器中。再有，在需要时这些各种部件能被复制，以支持增加了的处理负载。结果，当把业务处理器115、会话管理器120以及VXML语法分析器125放在一起时，能提供一个分布式话音浏览器体系结构，它能被放大以支持大量系统请求。一个高速缓冲存储器170能放在会话管理器120和VXML语法分析器125之间。高速缓冲存储器170能通过减少频繁使用的VXML脚本的多次读取和语法分析来提高系统性能。

事务处理部件104能包括SS7 TCAP服务器200、SS7 TCAP客户机205、TCAP bean/script应用(事务业务处理器)210、事务会话管理器220、TCAP XML语法分析器225、超文本传输协议(HTTP)服务器230、以及数据存储235。数据存储235能包括一个或多个TCAP XML脚本，如脚本209，用于指定根据一个或多个电话业务要进行的事务。例如，TCAPXML脚本能实现800号翻译、数据库查询、短消息业务(SMS)、本地号码可移植性、以及其它基于事务的业务或业务方面。能通过HTTP服务器230访问数据存储235内的TCAP XML脚本。应该理解，虽然数据存储235被描述为单个数据存储，但它能作为一个或多个分布式数据存储实现。

SS7服务器200能提供到信令网(在该情况中是SS7网)的接口。SS7服务器200能包括MTP接口、信令连接控制部分接口(SCCP)以及TCAP接口。SCCP接口能提供对一个信令点内的应用的寻址能力。例如，SCCP接口能用于寻址这样一些应用，它们提供800号呼叫处理、高级智能网(ATN)业务、呼叫或信用卡处理业务以及定制局域信令业务(CLASS)。SS7服务器200能提供其它接口，例如，移动应用部分(MAP)接口、智能网(IN)接口以及高级智能网(AIN)接口或IN(ITU-T/ETSI CS1/2)接口。这些接口能用于加强已存在的业务或提供新的业务能力或增强。

TCAP接口能是一个基于应用的接口，它能提供为支持与电路无关的活动所必须的业务，这些活动包括网络实体间与事务有关的信息的交换。例如，TCAP接口能利用SCCP接口向应用递送消息。值得注意的是，TCAP接口能提供800号事务、呼叫或信用卡事务以及AIN和CLASS事务所必需的业务。SS7客户机205能包括一个应用编程接口(API)库，它能用于与SS7服务器200交互作用。此外，SS7客户机205能有助于通过由Java允许的TCAP接口与事务处理器210的通信，该接口能被称作Java允许的TCAP应用协议接口。

TCAP XML语法分析器225能被运行时例示并能通过HTTP服务器230从数据存储235中检索TCAP XML脚本。TCAP XML语法分析器225能把检索出的TCAP XML脚本转换成中间格式，这种格式能被映射到事务业务处理器210并由事务业务处理器210解释。TCAP XML脚本能包括定义TCAP事务的标记，这些事务如允许呼叫、阻塞呼叫、转移呼叫、选择性转移呼叫、以及桥接呼叫。于是，TCAP XML语法分析器225还能被配置成识别TCAP XML脚本内任何与TCAP有关的标记。

事务业务处理210能够是可再用的软件部件，它们能与分布式计算环境中的同一个或不同的计算机系统中的其它部件组合。事务业务处理器210能被配置成经由Java允许的TCAP接口与SS7客户机205通信。一个事务业务处理器210能被运行时例示用于每个所接收的TCAP事件，或者一个或多个事务业务处理器210能保持操作状态以接收TCAP事件。在任何情况中，在需要时，附加的事务业务处理器210能被例示以处理额外的TCAP事件。每个事务业务处理器210能与应用表215的一个副本关联。应用表215能指定DNIS和数据存储235中存储的电话业务的TCAP XML脚本实现之间的关联。更具体地说，应用表215保持DNIS和DNIS已被注册的电话业务的列表。应用表215进一步指定能从中检索电话业务的各种TCAP XML脚本实现的网络位置。

当通过TCAP接口从SS7客户机205接收一个TCAP事件时，事务业务处理器210能被例示。事务业务处理器210能接收由来自TCAP客户机205的TCAP事件指定的DNIS。事务业务处理器210能使用应用表215匹配该DNIS与一个或多个TCAP XML脚本。这样，便能识别出该DNIS已被注册的那些电话业务的TCAP XML脚本实现的位置或地址。电话业务的TCAP XML脚本的位置能被提供给事务会话管理器220。事务业务处理器210还用作解释器，其为语法分析后的TCAP XML脚本提供执行环境以实现电话业务的事务方面。通过TCAP接口，事务业务处理器210能与TCAP堆栈交互作用，以实现由TCAP XML脚本定义的基于事务的业务。

值得注意的是，事务业务处理器210和TCAP XML语法分析器225能分别在Java虚拟机240和250内执行。虽然图1描述的是在单个Java虚拟机240和250内执行的多个事务业务处理器210和TCAP XML语法分析器225，但每个事务业务处理器210和TCAP XML语法分析器225能在各自的单个Java虚拟机内执行，从而最大限度地减小在一个程序内发生差错将负面影响另一个程序的危险性。

每个事务业务处理器210和TCAP XML语法分析器225能注册到事务会话管理器220。于是，事务会话管理器220能跟踪哪些事务业务处理器210和TCAP XML语法分析器225可用于呼叫处理。事务会话管理器220进一步能协调一对事务业务处理器210/TCAP XML语法分析器225的操作。事务会话管理器220能在事务业务处理器210和TCAP XML语法分析器225之间传送信息。

例如，从事务业务处理器210提供给事务会话管理器220的TCAP事件，在与应用表215中的适当TCAP XML脚本匹配之后，能指定DNIS、一个或多个统一资源标识符(URI)(包括统一资源定位器(URL))用于指定电话业务的一个或多个TCAP XML脚本表示、TCAP标识符以及事务处理器标识符。事务会话管理器220能把这些信息保存在局部数据存储中。于是，事务会话管理器220能确定一个空闲的TCAP XML语法分析器225，以便能向它提供所接收的URI。此外，根据所保存的URI、DNIS以及事务处理器标识符，来自TCAP XML语法分析器225的结果能回送给适当的事务业务处理器215。

如事务业务处理器210和TCAP XML语法分析器225的情况那样，多个事务会话管理器能在单一Java虚拟机内执行，或每个事务会话管理器220能在一个单独Java虚拟机内执行。在任何情况中，如前所述，事务业务处理器210、事务会话管理器220和TCAP XML语法分析器225能存在于分布在整个计算网络中的各单独计算机器中。再有，在需要时这些各种部件能被复制，以支持增加的处理负载。结果，当把事务业务处理器210、会话管理器220以及TCAP XML语法分析器225放在一起时，它们能提供一个具有不同逻辑部件的分布式TCAP事件处理体系结构，该结构能被被逐渐扩大以支持大量TCAP事件。

一个高速缓冲存储器255能被放在事务会话管理器220和TCAP XML语法分析器225之间。高速缓冲存储器255能通过减少多次提取和语法分析频繁使用的TCAP XML脚本来提高系统性能。这里公开的发明安排进一步能包括一个或多个防火墙175、180和185。虽然防火墙对于这里公开的系统100的操作不是必需的，但增加防火墙提供附加的网络安全性。特别是，防火墙175和180提供双重防火墙保护，正如许多电信公司所需要的那样。防火墙185能提供VXML和TCAP XML语法分析器与法人网络或其它专用网络的隔离。

呼叫处理部件102和事务处理部件104能由事件环境高速缓存260在通信上链接。事件环境高速缓存260能是一个异步高速缓存，其中的条目只有几秒钟的生命周期。事务处理部件104能在事件环境高速缓存260中存储关于呼叫、TCAP事件或业务的信息。由事务处理部件104存储在环境高速缓存260中的信息能被呼叫处理部件102访问。这样，作为事务处理部件104中接收到TCAP事件的结果，该信息能向呼叫处理部件102提供关于如何处理被呼叫处理部件102转接或接收的呼叫的指示。

例如，当执行一个TCAP XML脚本时，事务业务处理器210能在环境高速缓存260中建立一个条目。虽然每个条目只被保留几秒钟，但该条目能指定包括DNIS、主叫号码以及业务名称或URI的信息，例如要执行的VXML脚本，以及为执行该VXML脚本可能需要的任何参数。值得注意的是，所接收的TCAP的事件环境能通过执行一个TCAP XML脚本来确定。当呼叫处理部件接收一个被转接的呼叫时，呼叫处理部件102能访问环境高速缓存260以确定用于处理该呼叫的行动的适当过程，而不是通过业务到业务消息传送协议询问事务处理部件104。

图4是流程图，显示由图3的系统进行的实现电话业务的事务方面的方法300。该方法能在图3的系统已被例示为至少一个事务业务处理器的状态下开始。再有，一个或多个语法分析器，如TCAP XML语法分析器，能被例示，使得事务业务处理器和语法分析器已注册到事务会话管理器。值得注意的是，在业务处理器和语法分析器之间无需一对一地对应。在任何情况下，在步骤405，SS7服务器能从信令网接收一个TCAP事件。在步骤410，所接收的TCAP事件能通过IP连接被发送给SS7客户机。

然后，在步骤415，该TCAP事件能被提供给事务业务处理器。TCAP事件能指定DNIS和主叫电话号码。于是，在步骤420，能识别出与该DNIS关联的一个或多个TCAP XML脚本。例如，能查询DNIS和所关联的TCAPXML的列表，以确定该DNIS已对其注册的电话业务的特定TCAP XML脚本实现。

在步骤425，能确定事件环境高速缓存中是否已建立了对应于所接收的TCAP事件的条目。如果是，则该方法能进行到步骤435。然而，如果否，则该方法能继续到步骤430，在步骤430，能在事件环境高速缓存中建立一个条目。事件环境高速缓存中的条目能包括DNIS、主叫电话号码、一个或多个所关联的VXML呼叫处理脚本以及可能由所指定的VXML呼叫处理脚本需要的任何参数数据。此外，在其后通过执行TCAP XML脚本所确定的任何其它信息也能被写入事件环境高速缓存。

在步骤435，事务业务处理器能通过TCP/IP连接向事务会话管理器发送至少下列信息：DNIS；一个或多个URI、其指定电话业务的TCAP XML脚本实现、对于这些电话业务、该电话号码已被注册；代表该TCAP事件最初被赋予的特定事务处理器的标识符；以及TCAP标识符。尽管在图4中未示出，但在把该URI传送给可用的语法分析器之前，事务会话管理器能通过TCP/IP连接查询一个脚本高速缓冲存储器，以确定由该URI指定的TCAP XML脚本是否被包含在该高速缓冲存储器中。如果是，则该TCAP XML脚本已被语法分析器分析过并以一种中间格式存在，该中间格式能由事务业务处理器执行。于是，能从该高速缓冲存储器检索出被语法分析过的TCAP XML脚本并提供给事务会话管理器，从而跳过步骤440、445、450并继续到步骤455。

在步骤440，事务会话管理器能识别出一个可用的语法分析器并通过TCP/IP连接向该语法分析器提供该URI。值得注意的是，事务会话管理器能保存该事务处理器标识符的一个本地副本。在步骤445，该语法分析器能向HTTP服务器发出HTTP请求以检索由该URI指定的TCAP XML脚本。TCAP XML脚本能实现允许呼叫、阻塞呼叫、转移呼叫、选择性转移呼叫、桥接呼叫等业务以及其它功能，包括查询网络数据库等。在步骤450，语法分析器能通过HTTP连接接收所请求的TCAP XML脚本。然后，语法分析器能分析该TCAP XML脚本，把该TCAP XML脚本转换成能由事务业务处理器解释和执行的一种中间格式。

在步骤455，分析后的呼叫处理脚本能通过TCP/IP连接从语法分析器传送给事务会话管理器。在步骤455，已得到事务处理器标识符的会话管理器能识别出与原始TCAP事件以及用于处理该TCAP XML事件的所接收的分析后TCAP XML脚本关联的事务业务处理器。在步骤460，事务会话管理器能将分析后的TCAP XML脚本传送给识别出的事务业务处理器。于是，事务业务处理器能通过执行分析后的TCAP XML脚本来实现该电话业务。如前所述，在其后通过执行TCAP XML脚本确定的任何其它信息也能写入事件环境高速缓存。在步骤460之后，该方法能继续跳到圆圈A并继续图5中的步骤505。

图5是流程图，显示如图3的系统所执行的呼叫处理方法。该方法能在图3的呼叫处理部件已被例示用于介质网关的每个信道处理器的至少一个业务处理器的状态下开始。再有，一个或多个语法分析器，如VXML语法分析器，能被例示，使得这些业务处理器和语法分析器已被注册到会话管理器。值得注意的是，在业务处理器和语法分析器之间无需一对一地对应。在任何情况下，电话交换机能接收一个呼叫。该电话交换机能选择该介质网关的一个空闲信道处理器并请求该介质网关接收该呼叫，例如使用带内信令或ISDN的D信道。响应该介质网关接收一个呼叫，该电话交换机能把该呼叫应用于所选择的信道处理器。于是，在步骤505，例如作为事务处理部件中接收的TCAP事件发起的一个呼叫转接的结果，该呼叫能被介质网关接收。在步骤510，能确定DNIS以及所接收呼叫的被叫电话号码。

在步骤515，能确定事件环境高速缓存中是否存在用于所接收呼叫的条目。例如，在事件环境高速缓存中的条目能使用一个散列表来存储。于是，该DNIS和所接收呼叫的被叫电话号码能用于确定一个散列关键字，用于定位所接收呼叫的条目。如果在事件环境高速缓存中不存在条目，则该方法能继续到步骤520，在那里能执行一个恢复过程。如前所述，恢复过程能包括向呼叫者发出一个消息、挂掉该呼叫或把该呼叫转移到与该DNIS关联的缺省话音邮件地址。在恢复过程已执行之后，该方法结束。

如果在事件环境高速缓存中的确存在用于所接收呼叫的条目，则该方法能进到步骤525。在步骤525，能从事件环境高速缓存中检索出由该事件环境高速缓存条目指定的信息。在步骤530，与该DNIS关联的一个或多个呼叫处理脚本能被识别出来。例如，能查询DNIS和所关联的VXML脚本列表，以确定这些特定的呼叫处理脚本或电话业务VXML脚本表示，对于它们该DNIS已被注册。值得注意的是，能使用DNIS或由该事件环境高速缓存条目指定的其它信息(包括电话号码)来搜索DNIS及所关联的VXML脚本的列表。例如，该事件环境高速缓存条目能指定要执行的一个或多个VXML脚本或VXML脚本位置。

在步骤535，介质网关能通过TCP/IP连接向会话管理器发送如下信息：被叫电话号码；一个或多个URI、用于指定电话业务的呼叫处理脚本表示、对于这些电话业务、该电话号码已被注册；以及代表接收该呼叫的特定信道处理器的标识符。

虽然在图5中未示出，但在把该URI传送给可用的语法分析器之前，会话管理器能通过TCP/IP连接查询一个脚本高速缓冲存储器，以确定由该URI指定的呼叫处理脚本是否被包含在该高速缓冲存储器中。如果是，则该呼叫处理脚本已被语法分析器分析过并以一种中间格式存在，它能由业务处理器执行。于是，能从该高速缓冲存储器检索出分析过的呼叫处理脚本并提供给会话管理器，从而跳过步骤540、545、550，并继续到步骤555。

在步骤540，会话管理器能识别出一个可用的语法分析器并通过TCP/IP连接向该语法分析器提供该URI。值得注意的是，该会话管理器能保存该信道处理器标识符的一个本地副本。在步骤545，该语法分析器能向HTTP服务器发出HTTP请求以检索由该URI指定的呼叫处理脚本。该呼叫处理脚本能包括例如语音标记语言脚本，如VXML文档、文本、脚本以及选定的音频部分。该语法分析器能通过THHP连接接收所请求的呼叫处理脚本。于是，在步骤550，语法分析器能分析该呼叫处理脚本，把该呼叫处理脚本转换成能由业务处理器解释的一种中间格式。

在步骤555，分析后的呼叫处理脚本能通过TCP/IP连接从语法分析器传送给会话管理器。在步骤560，已得到信道处理器标识符的会话管理器能识别出与接收该呼叫的信道处理器关联的业务处理器(script/bean)。在步骤565，会话管理器能将分析后的呼叫处理脚本传送给识别出的事务处理器。于是，在步骤570，业务处理器能通过执行分析后的呼叫处理脚本来实现电话业务。业务处理器能通过bean/script接口访问任何被要求的功能以实现该电话业务，例如，介质网关的话音处理器。

下面是一个示例性的TCAP XML脚本，它能用于请求一个转移的电话号码，以便为一个呼叫确定路由。

<？xml version＝1.0″？>

<txml version＝1.0″>

  <catch event＝″jain.protocol.ss7.tcap.component.InvokeIndEvent″

  name＝″request″>

                   <var name＝″number″

  expr＝″Onlinecalendar.getForwaraNumber(request.getDigits(

  ).new Date())″/>

  <object name＝″provider″

  expr＝″request.getProvider()″>/

  <script>

  <！[CDATA[

  provider.sendResults(number)；

  ]]>

  </script>

</catch></txml>

该示例性的TCAP XML脚本说明了一个业务能根据检索一个在线日历应用(如Lotus Notes^(TM))中指定的被叫方号码，将一个电话呼叫转移到另一个电话号码。该在线日历应用能指定在该日的各个时刻一个人所处的地方。TCAP XML脚本能从在线日历应用请求一个转移电话号码，并作为TCAP格式的消息返回该转移号码。换言之，TCAP XML脚本能根据被叫号码和当前日期和时间，使用接收的TCAP事件查询当前有效的转移号码。然后TCAP XML脚本能从该请求得到TCAP提供者并使用那个对象以返回结果。

事件环境能被写入事件环境高速缓存。如前文指出的那样，事件环境高速缓存条目能指定话音标记语言脚本、这些脚本的参数以及任何电话号码，这些电话号码能由呼叫处理部件使用，以及确定为了处理一个给定呼叫要执行的一个或多个话音标记语言脚本。

本发明提供在电话系统中两个或更多个业务逻辑部件之间共享事件环境数据的解决方案。通过提供事件环境高速缓存作为业务逻辑部件，例如呼叫处理和事务处理之间的接口，本发明消除了对每个电话业务内协调实现业务到业务消息传递协议的需求。除了消除对开发和维持多个业务逻辑部件内协调的业务到业务协议的需求外，本发明还解放了大量需要的电话计算资源，从而降低了电话业务开发、布署和维护的成本。

本发明能以硬件、软件或硬件与软件的组合来实现。本发明能以集中化方式在一个计算机系统内实现，或以分布式方式实现，其中不同的部件分布在一些互连的计算机系统上。任何类型的计算机系统或适于实现这里描述的方法的其它装置都是适宜的。硬件和软件的一个典型组合能是通用计算机系统与一个计算机程序的组合，该计算机程序当被加载和执行时将控制该计算机系统使其实现这里描述的方法。

本发明还能被嵌入一个计算机程序产品，它包含能实现这里描述的方法的全部特性，当把它加载到计算机系统时它能实现这些方法。本上下文中的计算机程序是指以任何语言、代码或符号表示的一组指令，它们或直接地或在下述之一或二者之后使具有信息处理能力的一个系统完成特定的功能：a)转换成另一种语言、代码或符号；b)以不同的材料形式再现。

Claims (15)

1.在电话系统中共享信令事件数据的方法，包括：

在第一业务逻辑部件内接收来自一个电话信令网的一个事件；

为所述事件确定一个事件环境；以及

将所述事件环境存储在一个事件环境高速缓存中，该高速缓存与所述第一业务逻辑部件及至少一个第二业务逻辑部件在通信上链接。

2.如权利要求1的方法，其中所述第一业务逻辑部件是一个呼叫处理系统，而所述第二业务逻辑部件是一个事务处理系统。

3.如权利要求2的方法，其中所述呼叫处理系统包含ISDN接口和ISUP接口二者中的至少一个，所述事务处理系统包含一个TCAP接口，而所述电话信令网是7号信令系统网。

4.如权利要求3的方法，其中所述事件是一个TCAP事件，所述确定事件数据步骤进一步包括：

从所述接收的TCAP事件中识别出被拨号码入站业务、被呼叫的电话号码以及至少一个要执行的电话业务。

5.如权利要求4的方法，进一步包括：

接收一个后续TCAP事件；

确定在所述事件环境高速缓存中是否存在所述后续TCAP事件的事件环境；以及

如果否，则确定所述后续TCAP事件的事件环境，该后续TCAP事件指定被拨号码入站业务、被呼叫的电话号码以及至少一个要执行的电话业务，并将所述事件环境存入所述事件环境高速缓存中。

6.如权利要求4的方法，进一步包括：

所述呼叫处理部件访问所述事件环境高速缓存，以确定如何处理一个被转接的呼叫。

7.如权利要求1的方法，其中确定事件环境的步骤进一步包括：

接收一个呼叫；

确定在所述事件环境高速缓存中是否存在与所述接收的呼叫关联的事件环境；

如果是，则从所述事件环境高速缓存中检索所述事件环境；以及

如果否，则执行一个呼叫恢复机制。

8.如权利要求7的方法，所述确定步骤进一步包括：

从所述呼叫中识别出一个被拨号码入站业务和一个被呼叫的电话号码；以及

根据所述被拨号码入站业务和所述被呼叫的电话号码，搜索所述事件环境高速缓存。

9.如权利要求8的方法，所述检索步骤进一步包括：

识别一个要执行以处理所述接收的呼叫的话音标记语言脚本的位置。

10.如权利要求9的方法，所述识别步骤进一步包括：

识别由所述事件环境指定的属性，其中所述属性被提供给执行的所述话音标记语言脚本。

11.一个电话系统，包含：

第一业务逻辑部件；

第二业务逻辑部件；以及

一个事件环境高速缓存，其与所述第一业务逻辑部件及所述第二逻辑部件在通信上链接。

12.权利要求11的系统，其中所述事件环境高速缓存提供所述第一业务逻辑部件和所述第二业务逻辑部件之间的信息交换，而无需使用业务到业务消息传递协议。

13.权利要求12的系统，其中所述第一业务逻辑部件是一个呼叫处理系统，而所述第二业务逻辑部件是一个事务处理系统。

14.权利要求13的系统，其中所述呼叫处理系统被配置成处理ISUP事件，而所述事务处理系统被配置成处理TCAP事件。

15.一种可直接加载到数字计算机的内存贮器中的计算机程序产品，包括：多个软件代码部分，用于当所述产品在计算机上运行时，执行权利要求1至权利要求10中任何一个的步骤。

Images