CN101106604B - 翻译器以及基于翻译器的处理多业务的系统和方法 - Google Patents

Abstract

本发明公开了一种基于扩展呼叫处理语言(CPL)的翻译器，包括系统总控模块，用于对获取的扩展CPL业务脚本进行翻译，并创建配置模块和翻译总控模块。在本发明系统上采用的方法包括以下步骤：在终端建立业务开发环境，根据预设置的扩展CPL，基于扩展CPL编写扩展CPL业务脚本；终端将封装扩展CPL业务脚本的信息发送给翻译器，翻译器翻译扩展CPL业务脚本并转换成底层代码；翻译器将底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码实现与其相应的所述业务。采用本发明的翻译器以及系统、方法，提供了对多业务接入的支持，使业务服务器能触发并实现用户的多种业务请求。

Description

翻译器以及基于翻译器的处理多业务的系统和方法 

技术领域

本发明涉及基于呼叫处理语言(CPL)处理业务的技术，尤其涉及一种基于CPL的翻译器以及基于翻译器的处理多业务的系统和方法。 

背景技术

在IP电话系统中，用来描述IP电话如何处理呼叫请求的语言为CPL，CPL是基于扩展性标记语言(XML)的脚本语言，XML的扩展性体现在允许业务开发者定义创建业务所需的标签。CPL独立于信令协议，可在不同的信令协议下执行，信令协议包括公共交换电话网上的多媒体通信协议的数据流复用标准(H.323)和会话发起协议(SIP)。 

由于CPL与其描述的处理呼叫处理请求的动作之间存在十分紧密的对应关系，因此，目前业务开发者通过CPL编写CPL业务脚本来规定业务信息，进行业务开发。CPL业务脚本以标签的形式对信息进行标记，CPL业务脚本中包括两种类型的信息：辅助信息和呼叫处理的动作，其中呼叫处理的动作包括顶层动作和子动作，也就是说，CPL业务脚本的标签中包括辅助信息或呼叫处理动作，其中，呼叫处理动作为顶层动作或子动作。 

顶层动作指CPL业务脚本描述的业务服务器所触发的动作，包括呼入动作和呼出动作两种类型，其中，呼入动作指呼叫到达该CPL业务脚本描述的业务服务器时所产生的动作；而呼出动作指呼叫发自该CPL业务脚本描述的业务时服务器产生的动作。举例子来说：顶层动作即描述终端对业务服务器发出第一个呼叫请求时，所述业务服务器根据该请求进行判断后的处理动作；所述业务服务器经过一系列处理动作后，返回处理结果给所述终端的动作也称为顶层动作。

子动作类似于C语言中函数的概念，指可以在其他动作中调用的动作。仍沿用对顶层动作描述中所举的例子，子动作即描述所述业务服务器执行完顶层动作后，继续进行判断，并选择呼叫路由所进行的一系列处理动作。 

顶层动作与子动作的区别在于：顶层动作描述在谁与谁之间建立呼叫连接，为发起呼叫请求的终端与所述业务服务器之间的动作，而子动作是为了完成该终端的呼叫请求，所述业务服务器所经过的一系列处理动作，包括代理转发，重定向等。 

通过CPL编写CPL业务脚本时，CPL中描述的节点与CPL业务脚本中的辅助信息以及呼叫处理动作的对应关系具体为：一个呼叫处理的动作对应于由一组节点构成的集合，这些节点用来描述所述业务服务器所进行的各种判断选择，以及相应于判断选择完成的动作。其中，节点指对应于所述业务服务器中进行的判断选择操作，用CPL编写CPL业务脚本时设置的逻辑功能判断点。每个节点包含几个参数和输出，其中，参数描述了节点的精确的行为即设置一些匹配条件，辅助信息与匹配条件相对应；输出指在参数符合匹配条件的前提下，节点将要做出的判断以及采取的动作。这些节点从一个根节点出发，根节点的输出与后续的子节点连接，组成一种树状结构。 

当要执行一个呼叫处理动作时，首先从顶层的根节点开始执行，即根据参数的匹配条件所述业务服务器进行判断选择，执行相应的顶层动作并输出一个处理结果，然后将该处理结果输入根节点下属的子节点，继续执行这种处理过程直到某个子节点没有输出时为止。 

综上所述，现有技术为：基于上述CPL处理业务的技术，业务开发者编写好CPL业务脚本后，通过在终端与业务服务器之间传送CPL业务脚本，在业务服务器触发并实现CPL业务脚本的机制，使业务服务器能对终端的呼叫请求进行控制和处理。 

所采用的基于呼叫处理语言处理业务的系统，包括相连的终端以及业务服务器，业务服务器用于对获取的CPL业务脚本进行触发并编译，执行CPL业务脚本所描述的业务。

如图1所示，通过上述系统，基于呼叫处理语言处理业务的方法包括以下步骤： 

步骤101：业务开发者在终端建立业务开发环境，用CPL编写CPL业务脚本，终端将封装CPL业务脚本的信息发送给业务服务器，并在业务服务器上部署呼叫业务； 

步骤102：业务服务器触发CPL业务脚本，执行呼叫业务。 

CPL定义了四种标签，用来编写CPL业务脚本实现上述呼叫处理过程，包括：①判断选择标签，进一步包括根据主叫或被叫的地址做出选择的标签(address-switch)、根据请求中的字符串做出选择的标签(string-switch)、根据语言做出选择的标签(language-switch)、根据时间做出选择的标签(time-switch)、根据主叫的优先级做出选择的标签(priority-switch)，上述标签用来支持不同的选择控制方式。 

②位置修改标签，从位置集合中添加或输出记录，包括锁定位置记录的标签(location)、查找位置记录的标签(lookup)、移去位置记录的标签(remove-location)。 

③信令操作标签，引发底层信令协议的操作，进一步包括引发底层协议的转发操作即向一个新的地址发送呼叫请求(proxy)、引发底层协议的重定向操作即通知主叫将呼叫重定向到一个新的地址(redirect)、以及引发底层协议的拒绝操作即拒绝呼叫请求(reject)。 

④非信令操作标签引发与底层协议无关的操作，进一步包括发送电子邮件的操作(mail)、记录日志的操作(log)。 

现有技术存在的缺点是：仅通过业务服务器处理业务所花费的时间较长，而且用CPL编写的CPL业务脚本仅限于描述IP电话业务即业务服务器只能处理呼叫业务，不能处理定位、短信、彩信以及GIS等其他业务，在用户基于多业务平台发起业务请求的情况下，不能提供对多业务接入的支持，从而业务服务器无法触发并实现用户的多种业务请求。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于扩展CPL的翻译器，降低了通过业务服务器处理业务所花费的时间，提高了业务服务器实现业务的效率。 

本发明的又一目的在于提供一种基于扩展CPL翻译器的处理多业务的系统，提供了对多业务接入的支持，使业务服务器能触发并实现用户的多种业务请求。 

本发明的再一目的在于提供一种基于扩展CPL翻译器的处理多业务的方法，提供了对多业务接入的支持，使业务服务器能触发并实现用户的多种业务请求。 

为达到上述目的，本发明的技术方案是这样实现的： 

一种基于扩展呼叫处理语言CPL的翻译器，翻译器包括设置在翻译器中的系统总控模块，所述系统总控模块用于对获取的扩展CPL业务脚本进行翻译，并创建配置模块和翻译总控模块；该翻译器还包括：业务验证模块、业务翻译模块、文件生成模块以及编译模块；其中，配置模块和翻译总控模块分别与所述总控模块相连，且配置模块与翻译总控模块相连，业务验证模块、业务翻译模块、文件生成模块以及编译模块分别与所述翻译总控模块相连； 

所述配置模块用于以配置文件的方式从所述扩展CPL业务脚本的信息中提取配置信息，并获取配置信息中的扩展CPL业务脚本的路径、消息类存放路径以及业务能力构件类存放路径；所述翻译总控模块用于根据所述配置信息对所述扩展CPL业务脚本进行翻译；具体为：所述翻译总控模块用于具体以调度业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块用于对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块用于根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块用于根据所述业务实例代码以及所述业务描述文件所描述 的信息，生成最终的业务实例文件；编译模块用于编译所述业务实例文件，生成可部署在所述业务服务器上的代码压缩包。 

一种基于扩展CPL翻译器的处理多业务的系统，该系统包括终端、基于扩展CPL的翻译器以及业务服务器，终端通过基于扩展CPL的翻译器与业务服务器相连； 

所述基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于所述消息标签的消息类存放路径以及相应于所述业务能力构件标签的业务能力构件类存放路径；配置模块将所述配置信息以及所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译，并且翻译的过程为：该翻译总控模块以所述翻译器中的业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块编译所述业务实例文件，生成可部署在所述业务服务器上的代码压缩包；并将所述代码压缩包后转发给所述业务服务器； 

所述业务服务器用于执行所述代码压缩包的底层代码，并实现与所述扩展CPL业务脚本相应的业务。 

一种基于扩展CPL翻译器的处理多业务的方法，包括以下步骤： 

A、在终端建立业务开发环境，根据预设置的扩展CPL编写扩展CPL业务脚本； 

B、终端将封装所述扩展CPL业务脚本的信息发送给基于扩展CPL的翻译器，基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块， 终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于所述消息标签的消息类存放路径以及相应于所述业务能力构件标签的业务能力构件类存放路径；配置模块将所述配置信息以及所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译，并且翻译的过程为：该翻译总控模块以所述翻译器中的业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块编译所述业务实例文件，生成可部署在所述业务服务器上的代码压缩包； 

C、所述基于扩展CPL的翻译器将所述底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码，并实现与所述扩展CPL业务脚本相应的所述业务。 

其中，所述步骤B具体为： 

在编译所述扩展CPL业务脚本时，所述业务翻译模块先根据扩展CPL业务脚本中所述消息标签的执行顺序生成与其对应的标签节点树，然后以前序遍历方式查找标签节点树上的标签节点，根据查找的顺序以及预先设置的标签转换类(converter)判断当前标签节点是否与预先设置的converter对应，如果是，则调用当前标签节点所对应的converter进行处理并转换成所述底层代码，并按照查找的顺序将当前生成的底层代码存储在预先设置的存储区；如果否，则返回异常信息后，继续执行所述查找以及所述判断操作； 

其中，所述业务翻译模块生成标签节点树具体为：以用于实现简单应用程序编程接口SAX解析技术的jdom方式生成与所述标签的执行顺序对应的标签节点树； 

所述预先设置的存储区为存储作用域的堆栈； 

存储所述底层代码具体为：以压栈的方式，将当前生成的底层代码存储在该底层代码应插入的所述存储作用域的堆栈；相应地，以出栈的方式调用该底层代码。 

采用本发明基于扩展CPL的翻译器对从终端获取的扩展CPL业务脚本进行翻译，翻译成底层代码并编译，进行批处理生成底层代码压缩包后，转发给业务服务器，降低了通过业务服务器处理业务的时间，提高了业务服务器实现业务的效率； 

在现有系统的终端与业务服务器之间增加基于扩展CPL的翻译器后构成本发明的系统，在该系统上采用本发明的方法，通过增加消息标签对CPL进行语法上的扩展，以及相应地增加包括定位、短信、彩信以及GIS等多种业务的能力构件标签，对CPL进行业务能力上的扩展来增加多种业务类型，并由此基于扩展CPL编写的扩展CPL业务脚本提供对多业务接入的支持；由于扩展CPL业务脚本不同于用于实现业务的底层代码，屏蔽了底层代码的具体实现细节，对业务进行更抽象的描述，因此相应地需要在终端与业务服务器之间增加基于扩展CPL的翻译器，采用基于扩展CPL的翻译器翻译扩展CPL业务脚本并转换成底层代码。 

综上所述，本发明采用基于扩展CPL的翻译器以及基于扩展CPL翻译器的处理多业务的系统和方法，首先基于扩展CPL编写扩展CPL业务脚本，保证多业务的接入，然后采用基于扩展CPL的翻译器对扩展CPL业务脚本进行翻译，使业务服务器能触发并实现用户的多种业务请求。同时基于扩展CPL业务脚本屏蔽底层代码的具体实现细节对业务进行抽象描述，提高了业务开发的抽象层次，也就是说业务开发者无需专注于编写底层代码，在不需要掌握深厚电信知识和具有编程能力的情况下，也可根据需要抽象地描述多种业务，方便 了业务开发者创建和配置业务，提高开发业务的效率。 

附图说明

图1为现有技术处理呼叫业务的实现流程图； 

图2为本发明基于扩展CPL的翻译器的原理构成示意图； 

图3为本发明基于扩展CPL的翻译器的构成示意图； 

图4为本发明处理多业务方法的原理实现流程图； 

图5为本发明通过基于扩展CPL翻译器处理多业务方法的实现流程图； 

图6为本发明处理多业务方法中对扩展CPL业务脚本进行翻译的实现流程图； 

图7为本发明处理多业务方法中一棵标签节点树的示意图。 

具体实施方式

本发明的核心思想为：在基于扩展CPL的翻译器中设置系统总控模块，对从终端获取的扩展CPL业务脚本进行翻译，翻译成底层代码并编译，进行批处理生成底层代码压缩包后，转发给业务服务器；在现有系统的终端与业务服务器之间增加所述基于扩展CPL的翻译器，即终端通过基于扩展CPL的翻译器与业务服务器相连后构成本发明的系统，在本发明的系统上采用本发明的方法，通过增加消息标签对CPL进行语法上的扩展，以及相应增加包括定位、短信、彩信以及GIS等多种业务的能力构件标签，对CPL进行业务能力上的扩展来增加多种业务类型，由此基于扩展CPL编写的扩展CPL业务脚本提供了对多业务接入的支持；相应的，需要在终端与业务服务器之间增加基于扩展CPL的翻译器，采用基于扩展CPL的翻译器对所述扩展CPL业务脚本进行翻译，即将扩展CPL业务脚本转换成底层代码，使业务服务器能触发并实现用户的多种业务请求。 

为使本发明的目的、技术方案和优点更加清楚明白，以下举实施例并参照附图，对本发明进一步详细说明。

如图2所示，本发明基于扩展CPL的翻译器包括：设置在基于扩展CPL的翻译器1中的系统总控模块11，系统总控模块11用于对获取的扩展CPL业务脚本进行翻译后转换成底层代码，并创建配置模块和翻译总控模块。其中，扩展CPL业务脚本的生成方式为：通过业务开发者在终端建立业务开发环境，预设置以增加消息标签以及增加多种业务能力构件标签的扩展方式扩展CPL；根据预设置的扩展CPL，基于扩展CPL编写扩展CPL业务脚本。 

此时，基于扩展CPL的翻译器对获取的扩展CPL业务脚本进行翻译的过程为：业务开发者先在终端建立业务开发环境，根据预设置的扩展CPL编写扩展CPL业务脚本；终端再将封装扩展CPL业务脚本的信息发送给基于扩展CPL的翻译器，基于扩展CPL的翻译器翻译扩展CPL业务脚本并转换成底层代码；然后，基于扩展CPL的翻译器将底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码实现与其相应的所述业务。 

基于图2的原理，如图3所示，基于扩展CPL的翻译器1进一步包括：由系统总控模块11创建的配置模块111以及翻译总控模块112，配置模块111和翻译总控模块112分别与系统总控模块11相连，且配置模块111与翻译总控模块112相连； 

其中，配置模块111用于以配置文件的方式从所述扩展CPL业务脚本的信息中提取配置信息，并获取配置信息中的扩展CPL业务脚本的路径、消息类存放路径以及业务能力构件类存放路径； 

翻译总控模块112用于根据所述配置信息对所述扩展CPL业务脚本进行翻译。 

此时，基于扩展CPL的翻译器对获取的扩展CPL业务脚本进行翻译的过程为：业务开发者先在终端建立业务开发环境，根据预设置的扩展CPL基于扩展CPL编写扩展CPL业务脚本；之后，包括两个步骤： 

a1、基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务 脚本的路径、相应于所述消息标签的消息类存放路径以及相应于所述业务能力构件标签的业务能力构件类存放路径； 

b1、配置模块将所述配置信息以及所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译。 

步骤a1和b1完成后，基于扩展CPL的翻译器将底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码，并实现与与所述扩展CPL业务脚本相应的业务。 

其中，基于扩展CPL的翻译器1还包括：依序相连的业务验证模块1121、业务翻译模块1122、文件生成模块1123以及编译模块1124，业务验证模块1121、业务翻译模块1122、文件生成模块1123或编译模块1124分别与翻译总控模块112相连。 

翻译总控模块112用于具体以调度业务验证模块1121、业务翻译模块1122、文件生成模块1123以及编译模块1124的方式对所述扩展CPL业务脚本进行翻译；业务验证模块1121用于对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块1122用于根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块1123用于根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块1124用于编译所述业务实例文件，生成可部署在所述业务服务器上的代码压缩包。 

此种情况下，基于扩展CPL的翻译器对获取的扩展CPL业务脚本进行翻译的过程为：业务开发者先在终端建立业务开发环境，根据预设置的扩展CPL基于扩展CPL编写扩展CPL业务脚本；之后，包括五个具体步骤： 

a2、基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于所述消息标签的消息类存放路径以及相应于所述业务能力构件标签的业务能力构件类存放路径；

b2、业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验，比如校验是否缺括号； 

c2、作为进行翻译核心模块的业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码； 

d2、文件生成模块根据业务翻译模块生成的业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件； 

e2、编译模块编译业务实例文件，生成可部署在业务服务器上的代码压缩包。 

步骤a2～e2执行完毕后，基于扩展CPL的翻译器将底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码实现与其相应的业务。 

其中，步骤c2具体为： 

在编译所述扩展CPL业务脚本时，首先根据扩展CPL业务脚本中所述标签的执行顺序生成与其对应的标签节点树，标签节点树上的标签节点为用于将扩展CPL业务脚本中的标签翻译成底层代码的节点，然后以前序遍历方式查找标签节点树上的标签节点，根据查找的顺序以及预先设置的converter判断当前标签节点是否与预先设置的converter对应，如果是，则调用当前标签节点所对应的converter进行处理并转换成所述底层代码，比如当标签节点为业务能力构件标签时，则调用与其所对应的converter，即业务能力构件类进行处理，并按照查找的顺序将当前生成的底层代码存储在预先设置的存储区；否则，返回异常信息后继续执行上述查找及判断操作。 

本发明基于扩展CPL翻译器的处理多业务的系统，包括终端、基于扩展CPL的翻译器以及业务服务器，终端通过基于扩展CPL的翻译器与业务服务器相连；基于扩展CPL的翻译器用于获取从所述终端发送的扩展CPL业务脚本，对该扩展CPL业务脚本进行翻译，翻译成底层代码并对其进行编译，进行批处理生成底层代码压缩包后转发给所述业务服务器；所述业务服务器用于执行所 述底层代码实现与其相应的业务。 

如图4所示，基于扩展CPL翻译器的处理多业务的方法包括以下步骤： 

步骤201、业务开发者在终端建立业务开发环境，根据预设置的扩展CPL基于扩展CPL编写扩展CPL业务脚本； 

步骤202、终端将封装扩展CPL业务脚本的信息发送给基于扩展CPL的翻译器，基于扩展CPL的翻译器翻译扩展CPL业务脚本并转换成底层代码； 

步骤203、基于扩展CPL的翻译器将底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码，并实现与所述扩展CPL业务脚本相应的所述业务。 

其中，所述步骤201中预设置扩展CPL具体为：以增加消息标签和增加多种业务能力构件标签的扩展方式扩展CPL。 

具体来说，增加消息标签实现对CPL进行本身语言机制上的扩展，增加多种业务能力构件标签实现对CPL进行附加功能即业务能力上的扩展。 

对CPL进行本身语言机制上的扩展主要基于现有的CPL语法增加支持多个业务的接口，用于实现对多个业务接入的支持，包括以下标签： 

增加上报事件的标签； 

增加变量声明的标签，变量类型可以包括局部变量、全局变量、静态变量； 

对变量赋值的标签； 

增加对传入参数的声明的标签； 

增加判断选择类型的标签(switch)，如整型数据的switch； 

增加对数据库的访问标签； 

对CPL进行业务能力上的扩展为相应于业务以增加业务能力构件标签的方式进行扩展，包括用于实现定位、发送短信、发送彩信以及GIS等业务的业务能力构件标签。 

基于上述对CPL进行本身语言机制上的扩展以及对CPL进行业务能力上的扩展方式，具体扩展的五种标签如下： 

①增加消息判断选择标签(message-switch)，message-switch为判断选择类 型(switchType)。 

由于接入多种业务，因此扩展CPL业务脚本执行到message-switch时阻塞，需等待外界消息上报，根据获取外界消息中下级标签中声明的消息类型在message-switch进行判断，即根据相应的消息类型以及业务类型信息进行分支处理，选择并执行相应业务。 

message-switch格式如下： 

<xs:element     name＝″message-switch″     type＝″MessageSwitchType″ 

substitutionGroup＝″switch″/> 

②相应的，增加消息类型标签(messageType)格式如下： 

<xs:complexType name＝″MessageType″> 

      <xs:group ref＝″Node″/> 

      <xs:attribute name＝″is″type＝″xs:string″use＝″required″″/> 

</xs:complexType> 

③相应的，增加消息判断选择类型标签(messageSwitchType)格式如下： 

<xs:complexType name＝″MessageSwitchType″> 

  <xs:complexContent> 

    <xs:extension base＝″SwitchType″> 

      <xs:sequence> 

         <xs:element         name＝″message″          type＝″MessageType″ 

minOccurs＝″0″maxOccurs＝″unbounded″/> 

         <xs:sequence minOccurs＝″0″> 

           <xs:element name＝″not-present″type＝″NotPresentAction″/> 

            <xs:element         name＝″message″        type＝″MessageType″ 

minOccurs＝″0″maxOccurs＝″unbounded″/> 

         </xs:sequence> 

         <xs:element        name＝″otherwise″        type＝″OtherwiseAction″ 

minOccurs＝″0″/> 

     </xs:sequence> 

 </xs:extension>

  </xs:complexContent> 

</xs:complexType> 

上述message-switch以及相应增加的messageType和messageSwitchType，用来定义消息标签的属性和子元素。messageType和messageSwitchType是为Message和MessageSwitch标签提供的格式模板(Schema)，schema一般用来定义XML文件的格式、定义元素的从属关系、约束条件等等。 

④增加各种消息标签。 

这些消息标签为messageType，在deploy_success\iispsce\msgcfg文件夹下有对消息标签的详细定义，格式如下： 

msgname＝CalledPartyAnswerMsg 

package＝edu.bupt.skl.cngi.service.common.msg 

其中msgname为消息名，package为消息类所在包名。 

⑤增加业务能力构件标签的声明进而增加业务能力构件标签。 

业务能力构件标签的声明中包括构件的名称、参数的名称和类型、是否有返回值、返回值的名称、是否抛出异常、对构件的调用是同步还是异步。增加的业务能力构件标签包括用于实现定位、发送短信、发送彩信以及GIS等业务的业务能力构件标签。 

实施例一： 

短信定位业务指根据用户发送的手机号码，调用相应的业务能力，将包括手机所在地的经度以及纬度的定位信息以短信或彩E的方式返回到用户终端，所使用的业务能力构件为：发送短信(sendSMS)、发送彩信(sendMulMail)、定位(getLocation)以及创建地图(creatMap)。 

基于图4的原理，当需部署在业务服务器上的业务为短信定位业务时，本实施例中对步骤201，即业务开发者首先需要在终端建立业务开发环境，然后根据预设置的扩展CPL，基于扩展CPL以及业务逻辑编写扩展CPL业务脚本的实现具体包括两个步骤： 

首先在终端建立业务生成环境的过程具体为：

创建一个文件夹，名称为CPL_^***，其中^***为年月日比如20060418，以下的<根目录>均为此格式即盘符：/CPL_^***；先将iispsce文件夹拷贝到该根目录下；然后将iispsce文件夹下iisp.cfg内的所有路径改为自己机器对应iispsce文件夹的路径；再将smslocation文件夹拷贝至盘符：/CPL_^***下，将文件夹名smslocation改为自己定义的业务名称，进入servicescript文件夹下，将此xml文件改为盒文件夹名称相同的.xml文件，更改对应的service.cfg中的配置路径。 

基于上述在终端建立业务生成环境的过程，其中对应所述iispsce文件夹的六个路径如下： 

包括schema文件及参数表文件的sce公用构件配置文件的存放路径即sceapicfgfilepath＝<根目录>\\iispsce\\apicfg\\； 

sce公用消息配置文件的存放路径即scemsgcfgfilepath＝<根目录>\\iispsce\\msgcfg\\； 

log′s configuration file的存放路径即logcfgfilepath＝<根目录>\\iispsce\\logcfg\\log_oam.xml； 

编译EJB所需要的库文件的存放路径即ejblib＝<根目录>\\iispsce\\lib\\weblogic.jar；<根目录>\\iispsce\\lib\\webservices.jar； 

翻译所需要的公共库文件的存放路径即scelib＝<根目录>\\iispsce\\lib\\comlib.jar； 

业务bean包含的MANIFEST.MF文件路径即servicemanifest＝<根目录>\\iispsce\\manifest\\service\\MANIFEST.MF。 

基于上述在终端建立业务生成环境的过程，其中首先将smslocation文件夹拷贝至盘符：/CPL_^***下，然后更改对应的service.cfg中的配置路径中包括： 

扩展CPL业务脚本路径，即： 

servicescriptpath＝<根目录>\\smslocation\\servicescript\\； 

扩展CPL业务脚本名称servicescriptname＝smslocation.xml； 

工程的构件配置文件的存放路径，即： 

projectapicfgfilepath＝<根目录>\\smslocation\\apicfg\\；

工程的msg的配置文件的存放路径，即： 

projectmsgcfgfilepath＝<根目录>\\smslocation\\msgcfg\\； 

总的输出路径即生成jar包、ear包的目录在％outputpath％\\deploymentoutputpath＝<根目录>\\smslocation\\output\\。 

在终端建立业务生成环境后，打开扩展CPL业务脚本.xml文件，进行扩展CPL业务脚本的编写包括八个具体步骤： 

a3、在XML文档开头进行说明； 

b3、定义命名空间以及包括本实施例中使用到的所有标签所在的类库，本实施例实现短信定位业务中使用了cpl标签转换类、定位标签转换类(lbs)、短信标签转换类(sms)、彩信标签转换类(mulmail)，并定义引用类对应schema所在的位置； 

c3、根据业务逻辑定义标签的具体内容，首先由“notifySmsReceptionMsg”中读取对应的短信定位业务的名称即执行顶层动作，然后每当执行到标签所代表每个具体业务即子动作时，则跳转到包括该标签具体内容的位置继续执行。也就是说对获取的多个业务，根据每个标签对应的具体业务进行判断选择执行分支处理，比如执行到″getLocationSub″标签时，根据″getLocationSub″所代表的定位子动作转到相应的包括定位标签具体内容的位置继续执行； 

d3、定义的业务能力构件标签″getLocationSub″用来实现定位业务，此时将调用业务能力构件getLocationAPI，getLocationAPI所填充的输入参数的书写必须要和schema以及API类中定义的相一致； 

e3、需定义业务能力构件标签″sendSMS SuccessSub″用来实现发送短信成功的子动作，此时将调用业务能力构件sendSMSAPI，sendSMSAPI所填充的输入参数的书写必须要和schema以及API类中定义的相一致； 

f3、定义业务能力构件标签″sendSMS_FailureSub″用来实现发送短信失败的子动作，此时将调用业务能力构件sendSMSAPI，sendSMSAPI所填充的输入参数的书写必须要和schema以及API类中定义的相一致； 

g3、定义业务能力构件标签″sendSMS_createMapSub″用来实现在发送短信 时创建地图的子动作，此时将调用业务能力构件createMapAPI，createMapAPI所填充的输入参数的书写必须要和schema以及API类中定义的相一致； 

h3、定义业务能力构件标签″sendMMSSub″用来实现发送彩信的子动作，此时将调用业务能力构件createMapAPI，createMapAPI所填充的输入参数的书写必须要和schema以及API类中定义的相一致，至此，扩展CPL业务脚本编写完毕。 

其中，实现步骤a3，即在XML文档开头进行说明具体为： 

<-xml version＝″1.0″encoding＝″UTF-> 

<!--edited with XMLSPY--> 

上述代码即为辅助信息。 

其中，实现步骤b3，即定义命名空间，定义包括本实施例使用到的所有标签所在的类库以及定义引用类对应schema所在的位置具体为： 

<cpl                             xmlns:xsi＝http://www.w3.org/2001/XMLSchema-instance 

xmlns＝″urn:ietf:params:xml:ns:cpl″ 

xmlns:lbs＝″edu:bupt:skl:cngi:service:sce:api:lbs″ 

xmlns:sms＝″edu:bupt:skl:cngi:service:sce:api:sms″ 

xmlns:mulmail＝″edu:bupt:skl:cngi:service:sce:api:mulmail″ 

xsi:schemaLocation＝″urn:ietf:params:xml:ns:cpl 

file://C:/cpl/iispsce/apischema/cpl.xsd         edu:bupt:skl:cngi:service:sce:api:lbs 

file://C:/cpl/iispsce/apischema/GetLocation.xsd 

edu:bupt:skl:cngi:service:sce:api:sms 

file://C:/cpl/iispsce/apischema/SendSMS.xsd 

edu:bupt:skl:cngi:service:sce:api:mulmail 

file://C:/cpl/iispsce/apischema/SendMulMail.xsd″> 

上述代码用来描述标签的位置，例如： 

file://C:/cpl/iispsce/apischema/cpl.xsd  edu:bupt:skl:cngi:service:sce:api:lbs指定位业务标签的位置； 

file://C:/cpl/iispsce/apischema/GetLocation.xsd  edu:bupt:skl:cngi:service:sce:api:sms指 短信业务标签的位置。 

其中实现步骤c3，即由“notifySmsReceptionMsg”中读取对应的业务名称，根据″getLocationSub″转到相应的标签具体为： 

<incoming> 

  <message-switch> 

            <message is＝″notifySmsReceptionMsg″> 

               <sub ref＝″getLocationSub″/> 

            </message> 

            </message-switch> 

</incoming> 

其中实现步骤d3，即定义的业务能力构件标签″getLocationSub″所包括的具体内容为： 

<subaction id＝″getLocationSub″> 

<lbs:getLocation 

endUser＝″$(String)(serviceContext.getAttribute(″sendAddress″))″ 

accuracy＝″Medium″ 

requester＝″$(String)(serviceContext.getAttribute(″sendAddress″))″ 

chargedParty＝″$(String)(serviceContext.getAttribute(″sendAddress″))″> 

<lbs:success><--!在定位成功的情况下读取收到的触发消息--> 

<string-switch field＝″$(String)(serviceContext.getAttribute(″message″))″> 

<string is＝″1″><--!如果消息为1，跳转到标签″sendSMS_SuccessSub″--> 

                   <sub ref＝″sendSMS_SuccessSub″/> 

</string> 

<string is＝″2″><--!如果消息为2，则跳转到标签″createMapSub″--> 

                   <sub ref＝″createMapSub″/> 

              </string> 

              </string-switch> 

              </lbs:success> 

<lbs:failure><--!若定位失败，则跳转到标签″sendSMS_FailureSub″-->

                   <sub ref＝″sendSMS_FailureSub″/> 

                </lbs:failure> 

                </lbs:getLocation> 

</subaction> 

此时，调用的业务能力构件为getLocationAPI。 

其中实现步骤e3，即定义的业务能力构件标签″sendSMS_SuccessSub″所包括的具体内容为： 

<subaction id＝″sendSMS_SuccessSub″> 

<sms:sendSMS 

destArrayOfEndUserIdentifier＝″$(String)(serviceContext.getAttribute(″send 

Address″))～～″sender＝″001″deliveryResultRequest＝″true″message＝″$″ 

您的经纬度为:经度 

[″+((edu.bupt.skl.cngi.protocol.lbs.padger.LocationInfo)(serviceContext.get 

Attribute(″locationInfo″))).getLongitude()+″] 

纬度 

[″+((edu.bupt.skl.cngi.protocol.lbs.padger.LocationInfo)(serviceContext.get 

Attribute(″locationInfo″))).getLatitude()+″]″″ 

chargedNumber＝″$(String)(serviceContext.getAttribute(″sendAddress″))″/> 

</subaction> 

此时，调用的业务能力构件为sendSMSAPI。 

其中实现步骤f3，即定义的业务能力构件标签″sendSMS_FailureSub″所包括的具体内容为： 

<subaction id＝″sendSMS_FailureSub″> 

<sms:sendSMS 

destArrayOfEndUserIdentifier＝″$(String)(serviceContext.getAttribute(″send 

Address″))～～″sender＝″001″deliveryResultRequest＝″true″message＝″ 

您好，系统定位失败，请重试。″ 

chargedNumber＝″$(String)(serviceContext.getAttribute(″sendAddress″))″/> 

</subaction>

此时，调用业务能力构件为sendSMSAPI。 

其中实现步骤g3，即定义的业务能力构件标签″sendSMS_createMapSub″所包括的具体内容为： 

<subaction id＝″createMapSub″> 

<lbs:createMap 

centerX＝″$((edu.bupt.skl.cngi.protocol.lbs.padger.LocationInfo)(serviceCont 

ext.getAttribute(″locationInfo″))).getLongitude()″ 

centerY＝″$((edu.bupt.skl.cngi.protocol.lbs.padger.LocationInfo)(serviceCont 

ext.getAttribute(″locationInfo″))).getLatitude()″           MapScale＝″3″ 

MapZoom＝″5″centerX1＝″0″centerY1＝″0″centerX2＝″0″centerY2＝″0″ 

MapWidth＝″200″MapHeight＝″200″fileName＝″$this.mapName″> 

<lbs:success> 

                     <goto ref＝″sendMMSSub″/><--!跳转至标签 

″sendMMSSub″--> 

</lbs:success> 

</lbs:createMap> 

</subaction> 

此时，调用的业务能力构件为createMapAPI。 

其中实现步骤h3，即定义的业务能力构件标签″sendMMSSub″所包括的具体内容为： 

<subaction id＝″sendMMSSub″> 

<mulmail:sendMulMail 

sender＝″$(String)(serviceContext.getAttribute(″sendAddress″))″ 

destArrayOfEndUserIdentifier＝″$(String)(serviceContext.getAttribute(″send 

Address″))～～″ 

thirdPartyPayPhone＝″$(String)(serviceContext.getAttribute(″sendAddress″)) 

″feeCode＝″1″subject＝″This is the picture showing your location.″ 

fileName＝″$this.mapName″conditionType＝″1″/> 

         </subaction>

</cpl> 

此时，调用的业务能力构件为createMapAPI，至此扩展CPL业务脚本编写完毕。 

基于图4处理多业务方法的原理，参见图5所示，所述步骤202中终端将封装扩展CPL业务脚本的信息发送给基于扩展CPL的翻译器进一步包括： 

步骤2021、基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于所述消息标签的消息类存放路径以及相应于所述业务能力构件标签的业务能力构件类存放路径； 

步骤2022、配置模块将所述配置信息和所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译。 

其中，步骤2022中作为翻译核心模块的翻译总控模块对所述扩展CPL业务脚本进行翻译为：以调度业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对扩展CPL业务脚本进行翻译。 

基于图5处理多业务方法的原理，参见图6，步骤2022中对扩展CPL业务脚本进行翻译具体包括： 

步骤20221、业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验，比如校验是否缺括号； 

步骤20222、作为进行翻译核心模块的业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码； 

步骤20223、文件生成模块根据业务翻译模块生成的业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件； 

步骤20224、编译模块编译业务实例文件，生成可部署在业务服务器上的代码压缩包。 

基于图6处理多业务方法的原理，步骤20222的具体实现过程为：

在编译所述扩展CPL业务脚本时，所述业务翻译模块先根据扩展CPL业务脚本中所述标签的执行顺序生成与其对应的标签节点树，标签节点树上的标签节点为用于将扩展CPL业务脚本中的标签翻译成底层代码的节点，然后以前序遍历方式查找标签节点树上的标签节点，根据查找的顺序以及预先设置的converter判断当前标签节点是否与预先设置的converter对应，如果是，则调用当前标签节点所对应的converter进行处理并转换成所述底层代码，比如当标签节点为业务能力构件标签，则调用与其所对应的converter，即业务能力构件类进行处理，并按照查找的顺序将当前生成的底层代码存储在预先设置的存储区；如果否，则返回异常信息后继续执行上述查找以及判断操作。 

实施例二： 

在对所述扩展CPL业务脚本的翻译过程定义的类包括： 

Interpreter用于实现基于扩展CPL的翻译器对扩展CPL业务脚本翻译的核心算法； 

AbstractTab作为业务能力构件的抽象类，指明了业务能力构件需要提供的信息； 

NodeTree用于存储由所述扩展CPL业务脚本文件生成的标签节点树； 

TabElement用于实现标签节点树中的标签节点； 

ProgramSentence用于存储一条生成的java程序语句，并包含指向其上一条java语句和下一条java语句的指针； 

FuncRegion即作用域，例如一个函数、if-else模块等。 

FuncRegionStack即作用域堆栈，最上面的作用域是当前语句需要插入的作用域。 

此种情况下，基于图6的原理，以及步骤20222的具体实现过程，在本实施例中对步骤20222的具体实现包括以下步骤： 

a4、业务开发生成环境首先调用Interpreter对象的interpret函数，将扩展CPL业务脚本文件的路径传给Interpreter对象；

b4、Interpreter对象将XML格式的所述扩展CPL业务脚本的文件内容解析成一棵标签节点树； 

c4、Interpreter对象生成一个作用域堆栈对象； 

d4、Interpreter对象调用自身的initial函数，生成一些基本固定的java语句； 

e4、在initial函数中可以生成java程序的第一条语句，这时候可以将firstSentence赋值； 

f4、调用NodeTree对象获得标签节点树的根节点； 

g4、Interpreter对象调用自身的interpretElement函数，把根节点及其此处为空的父节点传入函数； 

h4、在interpretElement函数中，将对业务能力构件标签进行解析，生成新的java语句，插入到作用域中，并改变作用域堆栈中的值； 

i4、获取标签节点的子节点，然后返回步骤g4对子节点进行递归调用处理，将所述子节点及它们的父节点传入interpretElement函数中； 

j4、处理完标签节点树中所有的节点后，Interpreter对象调用自身的writeToFile函数将生成的java语句写到文件中。 

基于图6的原理，以及步骤20222的具体实现过程，在步骤20222中，所述业务翻译模块生成标签节点树的一个实例具体为：以用于实现简单应用程序编程接口SAX解析技术的jdom方式生成与所述标签的执行顺序对应的标签节点树。预先设置的存储区为存储作用域的堆栈，存储所述底层代码具体为：以压栈的方式，将当前生成的底层代码存储在该底层代码应插入的所述存储作用域的堆栈；相应地，以出栈的方式调用该底层代码。 

实施例三： 

基于图6的原理，以及步骤20222的具体实现过程，并基于所述业务翻译模块生成标签节点树的一个实例，本实施例中，由于CPL基于XML，XML具有用于XML的简单应用程序编程接口(SAX)和文档对象模型(DOM)两种通用接口，对应不同接口采用不同的XML解析技术。本实施例采用SAX解析技术，jdom是实现了SAX的java开发包，jdom用于先将XML转换成一棵节 点树，再对节点树进行操作。因此，本实施例中，首先以jdom方式，根据扩展CPL业务脚本中所述标签的执行顺序生成与该标签执行顺序对应的标签节点树。 

相应于预先设置的converter，在扩展CPL业务脚本中定义的标签除了包括特殊标签即cpl标签、incoming标签、subaction标签以及message-swith标签之外，还包括在message-switch标签中定义的标签即默认标签(default)、其他标签(otherwise)、同步且产生条件判断标签、同步且不产生条件判断标签、同步后继标签、异步标签、异步后继标签、switch类型标签以及switch后继标签。 

其中，特殊标签用于首先根据业务类型信息进行业务处理，在查找时遇到所述特殊标签对应的标签节点时需要进行判断选择，执行分支处理。 

其他标签用于经由特殊标签对应的标签节点处理后，根据业务类型的属性信息进行业务处理，举例如下： 

例如：当遇到cpl标签节点时根据业务类型信息需要判定业务请求的触发方式； 

遇到incoming标签节点及message-swith标签节点时，根据业务类型信息需要判定具体触发业务，比如判定是呼叫业务还是发送短信业务； 

遇到subaction标签节点时，根据业务类型信息需要判定具体触发业务对应的触发内容，不同触发业务对应不同触发内容。对于其他标签来说，同一个业务有不同属性，以同步和异步两种属性为例，同步指触发业务后无需等待返回消息就可以进行处理，而异步需要等待返回消息。 

其中，特殊标签中包括的cpl标签节点，在业务脚本中是作为业务逻辑的入口点。在标准的CPL业务脚本里，业务逻辑的触发仅仅是通过呼叫业务的呼入消息和呼出消息触发的，并不需要在遇到cpl标签节点时进行判断。 

然而在扩展CPL业务脚本里，业务逻辑的触发来自协议网关层上报的消息，除了呼叫消息，包括发送短信、彩信等其他网络承载能力消息，网络承载能力指接入的不同网络融合后，在融合的网络中当提供多种业务时网络能承载业务运行的能力，也包括从互联网客户端的的用户界面触发的用户自定义消息。此 时，遇到cpl标签节点时需要进行判断，cpl标签节点是标签节点树的根节点。subaction标签节点针对所述子动作触发的业务处理。如果incoming标签节点下紧跟着message-switch标签节点即代表需进行多种业务选择，说明业务逻辑是通过协议网关层或互联网客户端的上报消息触发的；如果incoming标签节点下紧跟的不是message-switch标签节点，则默认为该业务逻辑是通过呼叫的被叫号码进行触发的。 

为了使扩展CPL业务脚本能有一个较好的扩展性，使业务开发人员根据自己的需求能够简便地开发出合适的能力标签，扩展CPL业务脚本的基于扩展CPL的翻译器应该有一个通用的规则，对除了cpl标签等几个较为特殊的标签之外的其他标签应都能适用。在翻译过程中就使用了一个通用的规则。为了实现这个通用的规则，需要对应业务能力构件标签节点的业务能力构件类提供一些信息即描述所述业务类型的属性信息，具体包括以下六类属性信息： 

业务能力构件标签节点是否产生条件判断，当一个业务能力构件标签节点下的子节点需要判断进行条件判断时，就要将它预先设置成产生条件判断的属性。例如string-switch标签节点，其下面的子节点string会进行条件判断，则string-switch标签节点就需要设置成产生条件判断的属性。再例如proxy标签节点，其下面的子节点是消息标签，并需要对这些消息标签的名字进行判断，则proxy标签节点需要设置成产生条件判断的属性。 

业务能力构件标签节点是否有默认操作，有些业务能力构件标签节点可能会有一些默认操作，比如proxy标签节点。 

业务能力构件标签节点是否是异步的，有些业务能力构件标签节点在执行完自身的操作后需要等待外界的输入才能使扩展CPL业务脚本继续运行，这时就需要将该业务能力构件标签节点置成异步的，其他的情况就只需要置成同步的即可。例如proxy标签节点，扩展CPL业务脚本在执行proxy标签节点后，需要等待呼叫网关返回呼叫转接的结果才能继续运行，因此proxy标签节点是异步的。 

业务能力构件标签节点是否是一个操作，一些业务能力构件标签节点具有 条件判断的功能，例如string标签节点，而消息类型的业务能力构件标签节点也会产生条件判断，这时基于扩展CPL的翻译器就需要根据该业务能力构件标签节点是否是一个操作来决定在翻译的代码里是否加入调用业务能力构件标签节点对应业务能力构件类的操作的语句。 

业务能力构件标签节点是否有返回值，也表示业务能力构件标签节点是否会向serviceContext里存入其处理的结果，如果业务能力构件标签节点有返回值，则需要给出能力标签结果存入serivceContext的键值。 

在扩展业务能力构件标签节点时应能正确配置标签的这些信息，如果配置的信息与功能标签节点的设计功能不符，那么生成的业务能力构件标签节点可能无法达到预期的功能。对于default标签节点需要进行特别处理。 

其中，对default标签节点的处理具体为： 

default标签节点一般都会有兄弟节点，此时default的子树翻译出的代码应包含在一个else{}作用域中；但也可能会出现default标签节点单独存在而没有其他兄弟节点的情况，此时default标签节点的子树翻译出的代码就不需要包含在一个else{}作用域中； 

有时候一些业务能力构件标签节点有默认操作，但在扩展CPL业务脚本里，该业务能力构件标签节点的子节点不包含default标签节点，这时基于扩展CPL的翻译器就需要自动将一个default标签节点加为该业务能力构件标签节点的最后一个子节点； 

在default标签节点下可能没有子节点，这时基于扩展CPL的翻译器就只需要插入调用default父节点对应的业务能力构件标签的默认操作即可。 

当遇到异步标签节点需要生成新的处理函数时，新的处理函数的命名方式采用从根节点到A节点路径上的所有节点名称的组合方式。 

总之，基于本实施例中上述对标签节点处理的原理，以前序遍历方式将标签节点树上所有的节点都遍历后，实现调用当前的标签节点所对应的converter进行处理，并转换成所述底层代码。 

其中，调用当前的标签节点所对应的converter进行处理，并转换成所述底 层代码的实现方法具体为：每次遇到标签节点都会查找并调用相应的converter，converter采用的构造方法是一个静态方法。例如当遇到标签<A attr＝abc”>时，加入的语句是“A.proc(abc)；”。 

每个converter都有同步或异步之分，同步是指业务应用层向协议网关层发送调用请求调用converter后直接返回结果的情况；而异步是指业务应用层向协议网关层发送调用请求调用converter后需先返回给协议网关层，而此后业务应用层还需等待协议网关层上报消息的情况。如果标签节点对应的converter是同步的，则直接调用converter中的函数；如果是异步的，并且该异步标签下还有子节点，说明业务应用层需要等待协议网关层的上报消息，则需要生成一个新的函数专门处理上报消息。 

例如：遇到A标签节点，且它下面还有子节点，就需要插入以下代码“ret＝A.proc()；ret.fillContext(context)；return ret；”。 

如果该异步标签下面的标签节点是叶节点即最小的子节点，则插入返回值语句，并结束当前作用域。 

如果遇到subAction标签，直接生成一个函数private iMessagesubActionId(iMessage msg)，标签里的内容按照前面所述的方法进行翻译。 

当节点下面有多个子节点的时候，表明该节点之后有一个条件判断，此时以前序遍历方式对每个子节点及其子树生成一个if{}语句块，同理对子树的处理也是一样。 

如图7所示的标签节点树，根据上述调用当前的标签节点所对应的converter进行处理，并转换成所述底层代码的实现方法的原理，将标签节点树的标签节点进行转换生成的java代码如下所示： 

Private iMessage procAIn1(iMessage msg){ 

iMessage ret＝null； 

A a＝new A()； 

ret＝a.proc()； 

ret.fillContext(context)； 

if(conditionIsB){ 

    B b＝new B()；

ret＝b.proc()； 

ret.fillContext(context)； 

if(conditionIsC){ 

   C c＝new C()； 

   ret＝c.proc()； 

   ret.fillContext(context)； 

     returnret； 

  } 

  else if(conditionIsD){ 

     D d＝new D()； 

     ret＝d.proc()； 

     ret.fillContext(context)； 

     return ret； 

  } 

} 

else if(conditionIsE){ 

    E e＝new E()； 

    ret＝e.proc()； 

    ret.fillContext(context)； 

    return ret； 

} 

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (5)

1.一种基于扩展呼叫处理语言CPL的翻译器，其特征在于，该翻译器包括设置在翻译器中的系统总控模块，所述系统总控模块用于对获取的扩展CPL业务脚本进行翻译，并创建配置模块和翻译总控模块；该翻译器还包括：业务验证模块、业务翻译模块、文件生成模块以及编译模块；其中，配置模块和翻译总控模块分别与所述系统总控模块相连，且配置模块与翻译总控模块相连，业务验证模块、业务翻译模块、文件生成模块以及编译模块分别与所述翻译总控模块相连；

所述配置模块用于以配置文件的方式从所述扩展CPL业务脚本的信息中提取配置信息，并获取配置信息中的扩展CPL业务脚本的路径、消息类存放路径以及业务能力构件类存放路径；

所述翻译总控模块用于根据所述配置信息对所述扩展CPL业务脚本进行翻译；具体为：所述翻译总控模块用于具体以调度业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块用于对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块用于根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块用于根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块用于编译所述业务实例文件，生成可部署在业务服务器上的代码压缩包。

2.一种基于扩展CPL翻译器的处理多业务的系统，其特征在于，该系统包括终端、基于扩展CPL的翻译器以及业务服务器，终端通过基于扩展CPL的翻译器与业务服务器相连；

所述基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于消息标签的消息类存放路径以及相应于业务能力构件标签的业务能力构件类存放路径；配置模块将所述配置信息以及所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译，并且翻译的过程为：该翻译总控模块以调度所述翻译器中的业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块编译所述业务实例文件，生成可部署在所述业务服务器上的代码压缩包；并将所述代码压缩包转发给所述业务服务器；

所述业务服务器用于执行所述代码压缩包的底层代码，并实现与所述扩展CPL业务脚本相应的业务。

3.一种基于扩展CPL翻译器的处理多业务的方法，其特征在于，包括以下步骤：

A、在终端建立业务开发环境，根据预设置的扩展CPL编写扩展CPL业务脚本；

B、终端将封装所述扩展CPL业务脚本的信息发送给基于扩展CPL的翻译器，基于扩展CPL的翻译器通过系统总控模块创建配置模块和翻译总控模块，终端将封装扩展CPL业务脚本的信息发送给配置模块，配置模块从所述信息中提取配置信息供翻译总控模块使用，所述配置信息包括所述扩展CPL业务脚本的路径、相应于消息标签的消息类存放路径以及相应于业务能力构件标签的业务能力构件类存放路径；配置模块将所述配置信息以及所述扩展CPL业务脚本发送给翻译总控模块，翻译总控模块根据配置信息对扩展CPL业务脚本进行翻译，并且翻译的过程为：该翻译总控模块以调度所述翻译器中的业务验证模块、业务翻译模块、文件生成模块以及编译模块的方式对所述扩展CPL业务脚本进行翻译；业务验证模块对获取的扩展CPL业务脚本进行词法以及语法校验；业务翻译模块根据所述配置信息以及所述扩展CPL业务脚本中业务描述文件所描述的信息，将扩展CPL业务脚本编译成可执行的业务实例代码；文件生成模块根据所述业务实例代码以及所述业务描述文件所描述的信息，生成最终的业务实例文件；编译模块编译所述业务实例文件，生成可部署在业务服务器上的代码压缩包；

C、所述基于扩展CPL的翻译器将所述代码压缩包的底层代码发送给业务服务器，并在业务服务器上部署业务，业务服务器执行底层代码，并实现与所述扩展CPL业务脚本相应的所述业务。

4.根据权利要求3所述的基于扩展CPL翻译器的处理多业务的方法，其特征在于，步骤A中所述预设置扩展CPL具体为：以增加消息标签和增加多种业务能力构件标签的扩展方式扩展所述呼叫处理语言CPL。

5.根据权利要求3或4所述的基于扩展CPL翻译器的处理多业务的方法，其特征在于，所述步骤B具体为：

在编译所述扩展CPL业务脚本时，所述业务翻译模块先根据扩展CPL业务脚本中所述消息标签的执行顺序生成与其对应的标签节点树，然后以前序遍历方式查找标签节点树上的标签节点，根据查找的顺序以及预先设置的标签转换类converter判断当前标签节点是否与预先设置的converter对应，如果是，则调用当前标签节点所对应的converter进行处理并转换成所述代码压缩包的底层代码，并按照查找的顺序将当前生成的底层代码存储在预先设置的存储区；如果否，则返回异常信息后，继续执行所述查找以及所述判断操作；

其中，所述业务翻译模块生成标签节点树具体为：以用于实现简单应用程序编程接口SAX解析技术的jdom方式生成与所述标签的执行顺序对应的标签节点树；

所述预先设置的存储区为存储作用域的堆栈；

存储所述底层代码具体为：以压栈的方式，将当前生成的底层代码存储在该底层代码应插入的所述存储作用域的堆栈；相应地，以出栈的方式调用该底层代码。

Images