CN103942055A - 面向融合网络混合服务流程编制语言的开发系统及方法 - Google Patents

Abstract

本发明公开了一种面向融合网络混合服务流程编制语言的开发系统及方法，主要包括：业务平面，用于确定当前的业务需求是否适用于业务生成系统生成；所述业务生成系统具有良好的可扩展性，通过增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求；业务流程的脚本描述平面，主要用于完成业务的开发工作；在业务平面的业务需求确定后，使用XPL语言描述业务逻辑；可执行代码平面，用于从描述好的业务流程生成的可以部署运行的代码；网页服务接口平面，用于向业务生成系统提供开发业务所需的业务能力。采用本发明，能够利用XPL语言，搭建一个网络增值服务平台，提供下一代网络业务所需的全部业务能力。

Description

面向融合网络混合服务流程编制语言的开发系统及方法

技术领域

本发明涉及计算机软件开发技术与下一代网络（NGN）技术，尤其涉及面向融合网络混合服务流程编制语言的开发系统及方法。

背景技术

随着电信网络和互联网络向下一代网络的方向演进，如何快速灵活的开发种类丰富的新型增值业务是电信领域和计算机领域所面临的一个重要问题。

下一代网络（NGN）的业务开发，一个基本问题是如何描述业务需求。扩展标记语言（XML）由于具有易于人和机器的理解、与底层实现语言无关、易于图形化表示等优点成为业务描述语言的重要发展方向之一。基于XML的语言可以分为通用型语言和面向特定领域的专业语言两种类型。其中，通用型语言以IBM的业务流程执行语言（Business Process Execution Language，BPEL）为代表，其主要针对一般性流程的控制，接近于高级语言的水平，已经成为工作流领域的工业标准。电信领域中面向特定领域的专业语言有很多，其中面向呼叫流程控制的代表性语言有IETF的呼叫处理语言（Calling Process Language，CPL）、W3C的呼叫控制可扩展标记语言（CCXML）和JAIN论坛的服务组合管理语言（Service Composition Management Language，SCML）等，其语言元素本身就是对呼叫处理的高度抽象，这些专业语言已经或正在成为国际标准。

相比较而言，通用型语言有适用面广的优势，缺点是语言复杂，开发效率低，对开发人员的要求高。而专业语言的优点是语言简单，开发效率高，对开发人员的要求低，但不能描述特定领域以外的业务。快速的业务开发、部署业务是企业保持竞争力的关键之一，所以专业语言具有相当的研究价值。融合网络条件下通信类业务的特点应该是业务种类繁多、内容丰富、具有个性化，CPL、CCXML、SCML基本上针对传统的呼叫处理业务，不能描述短信、彩信、数据库操作等数据类业务，而且不能进行并发、循环等操作，受到的局限较大，因而不利于下一代网络的业务开发。

发明内容

有鉴于此，本发明的主要目的在于提供一种面向融合网络混合服务流程编制语言的开发系统及方法，利用面向综合通信的服务描述语言（ICSDL），如扩展呼叫处理语言(Extended-Calling Process Language，XPL)，综合呼叫、短信、彩信、web网页、Email等通信手段，搭建一个网络增值服务平台，能够提供下一代网络业务所需的全部业务能力，并能够实现较复杂的数据库操作。

本发明的另一目的在于，通过利用所述面向综合通信服务的专业语言即XPL语言，还能够提供受到限制的并发和循环操作，确保不会出现死锁和死循环。

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

面向融合网络混合服务流程编制语言的开发系统，包括业务平面、业务流程的脚本描述平面、可执行代码平面以及网页服务接口平面；其中：

业务平面，用于确定当前的业务需求是否适用于业务生成系统生成；所述业务生成系统具有良好的可扩展性，通过增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求；

业务流程的脚本描述平面，主要用于完成业务的开发工作；在业务平面的业务需求确定后，使用XPL语言描述业务逻辑；

可执行代码平面对应于所述业务流程的脚本描述平面，用于从描述好的业务流程生成的可以部署运行的代码；

网页服务接口平面，主要包括Parlay网页服务接口和其他类型的网页服务接口；所述网页服务接口平面用于向业务生成系统提供开发业务所需的业务能力。

面向融合网络混合服务流程编制语言的开发方法，其特征在于，包括：

A、采用业务平面确定当前的业务需求是否适用于业务生成系统生成；所述业务生成系统具有良好的可扩展性，通过增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求；

B、利用业务流程的脚本描述平面，完成业务的开发工作；在业务平面的业务需求确定后，使用XPL语言描述业务逻辑；

C、然后利用对应于所述业务流程的脚本描述平面的可执行代码平面，从描述好的业务流程生成的可以部署运行的代码；

D、最后通过网页服务接口平面向业务生成系统提供开发业务所需的业务能力；所述网页服务接口平面，主要包括Parlay网页服务接口和其他类型的网页服务接口。

一种包括面向融合网络混合服务流程编制语言的开发系统的网络增值服务平台，包括CPL业务脚本、OAM模块及协议网关层；其特征在于，其业务处理系统还包括业务翻译器和消息分发系统；其中：

业务翻译器，用于对扩展CPL业务脚本进行解析，得到符合EJB规范的java代码，然后生成java文件，并得到文件包；

消息分发系统，用于接收Web客户端提交的消息和协议网关层上报的消息，判断并分发到业务层中对应的业务实例；另外消息分发系统还接收来自业务实例发送的消息，判断并转发到协议网关模块。

本发明所提供的面向融合网络混合服务流程编制语言的开发系统及方法，具有以下优点：

第一，本发明通过对CPL语言进行了扩展，包括对CPL本身语法上的扩展和CPL附加功能的扩展：1）增加标签message-switch。使脚本执行到这一点的时候阻塞，等待外界信息上报，当外界信息到来时根据其下级标签中声明的消息类型进行分支处理。2）增加类型messageType和3）增加各种消息标签。4）增加能力构件标签的声明。5）增加与OAM模块接口的标签。使扩展的CPL即XPL语言支持：需要与用户进行交互的较为复杂的业务逻辑；业务的多入口；包括定位、发送短信、发送彩信以及GIS等数据业务的服务；对数据库的访问；以及业务自身主动发起的业务。

第二，本发明采用翻译器模式对扩展CPL脚本进行解析，将XML格式的脚本到语法树的翻译过程划分为前端，语法树到目标Java代码（直至EJB）的过程划分为后端。在需要做某些大的变动，如要求翻译CPL之外的语言，那么需要修改的部分只有前端，后端基本上可以不动。反过来，如果生成目标代码需要是Java语言之外的语言，那么也只需要修改后端代码生成部分，就可以达到目的，从而最大地减小了牵一发而动全身的可能。

第三，本发明还设计了一套基于上下文的构件模型和针对该模型的脚本转换——构件粘合算法，该算法依照业务脚本产生“胶水代码”，由“胶水代码”来把构件粘合起来，来控制构件的执行。这种基于上下文的构件组装机制使得构件本身得到简化，形式上更加规整，制作也变得容易，有利于扩展新的构件。构件组装方法体现为一种算法和纯粹的基于接口的构件组装方法相比虽然复杂，但对业务开发者是透明的，且相对稳定，可以进行充分复用。这种构件复用模型是适用于XPL的一种更高抽象层次的构件复用模型。

第四，本发明的开发系统采用的消息分发系统，接收业务平台系统中其他模块发送来的消息，对消息进行判断、处理，将其分发到对应的业务层的模块中去。同时，还接收来自业务层内部模块发送到平台系统中其他模块的消息，对消息进行相应的处理和判断后，将消息发送到相应的模块中去。消息分发系统接收Web客户端提交的消息和协议网关层上报的消息，判断并分发到业务层中对应的业务实例；另外消息分发子系统还接收来自业务实例发送的消息，判断并转发到协议网关模块。其内部的消息分发模块既要处理业务逻辑模块向网关下发的消息又要处理网关向业务逻辑模块上发的消息。对于下发消息直接在消息发送子模块的相应接口中调用下层网关侧提供的接口即可。

第五，采取了以上第一～第四优点的业务系统，与目前使用CPL等专业语言的平台相比，采取XPL的业务系统具有面向领域范围较大、能够适用于较复杂业务的优点，更能适用于融合网络条件下的下一代网络（NGN）通信类业务。

附图说明

图1为本发明融合网络增值服务平台的总体结构示意图；

图2为本发明的业务生成系统的模型示意图；

图3为本发明的业务翻译器/模块的功能框图；

图4为本发明的业务翻译器实现的任务过程示意图；

图4a为脚本生成的树结构示意图。

图5为业务能力构件结构示意图；

图6为协议网关和业务的接口描述示意图；

图7为协议网关和业务的消息类型示意图；

图8为本发明的消息分发系统的结构示意图；

图9a为业务逻辑发送消息的合作图；

图9b为业务逻辑发送消息的序列图；

图10为面向融合网络混合服务流程编制语言的开发系统的应用实施例；

图11为代理登录脚本login.xml的示意图；

图12为代理服务脚本service.xml的示意图。

具体实施方式

下面结合附图及本发明的实施例对本发明的面向融合网络混合服务流程编制语言的开发系统及方法作进一步详细的说明。

图1为本发明融合网络增值服务平台的总体结构示意图。如图1所示，所述平台主要包括CPL业务脚本处理模块、业务生成系统、协议网关层以及操作管理和维护（OAM）系统。其中，所述业务系统进一步包括业务翻译器、业务EJB（Enterprise Java Beans）、业务运行环境、构件（库）以及消息分发系统。本发明将对上述各个部分分别进行说明。

图2为本发明的业务生成系统的模型示意图。如图2所示，为了便于对下文中基于XPL的业务生成系统进行介绍，建立业务生成系统的概念模型。我们将所述整个业务生成系统大体上划分为四个平面：即业务平面、业务流程的脚本描述平面、EJB平面和Web Services接口平面。其中：

所述业务平面，是从业务用户和业务提供者的角度出发，确定当前的业务需求是否适用于该业务生成系统生成。业务生成系统具有良好的可扩展性，如果当前的业务生成系统不能完全满足需求，可以考虑增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求。

所述业务流程的脚本描述平面，主要完成业务的开发工作。在业务平面的业务需求确定以后，使用XPL语言来描述业务逻辑。业务开发者可以直接使用XPL语言描述业务流程，也可以在图形化的开发界面里通过拖放图形化的标签控件来来开发业务，即是一种“所见即所得”的业务开发模式。

所述可执行代码平面对应于业务流程的脚本描述平面，是从描述好的业务流程生成的可以部署运行的代码。所谓的业务生成技术，其实现方法的本质就是某种形式的软件复用技术。在软件复用领域，基于构件的复用技术是当前的研究热点。基本上XPL的每个标签在代码实现上都对应着一个构件，业务生成系统事先准备好XPL中所有用到的构件并存放在构件（库）中。业务生成系统根据用XPL所描述的业务逻辑将业务流程中所涉及到的构件组装起来，并封装成EJB，形成可以实际部署运行的业务。

网页服务（Web Services）接口平面，主要包括Parlay Web Services接口和其他类型的Web Services接口。Web Services接口平面负责向业务生成系统提供开发业务所需的业务能力。

以上所述的业务生成系统，即本发明面向融合网络混合服务流程编制语言的开发系统。本发明设计并实现了一种面向综合通信服务的专业语言即XPL，通过使用所述XPL语言，综合呼叫、短信、彩信、web网页、Email等通信手段，构建一个如图1所示的网络增值服务平台，以提供下一代网络（NGN）业务所需的全部业务能力。

一、下面对面向综合通信的服务描述语言（ICSDL）作一简要介绍。

1.1面向综合通信的服务描述语言（ICSDL）：

CPL是IETF提出的一种基于XML的呼叫控制语言。它用于控制IP电话类业务，被设计成可以在服务器端或用户端分别或同时执行。CPL具有功能强大、资源消耗少、工作高效、容易实现、易于检验、运行安全、方便编写和处理、独立于操作系统/网络控制协议、可扩展性好的特点。但出于安全的考虑，CPL语言中没有提供变量、循环等特性，也不允许在服务器端运行程序，从而保证CPL能够安全在服务器端运行。CPL 推出的目的是作为更加方便的业务开发手段提供给业务提供商、第三方业务开发商和终端用户，用于进行业务定义和使用，它是IPTEL推荐的在H.323/SIP 网络系统中使用的呼叫处理语言。CPL的功能包括指定呼叫控制方式、指示呼叫操作的以及对非呼叫动作的支持功能。

但是CPL语言由于其自身的简单性和它本身的目的，目前对以下几种状况无法支持：（1）需要与用户进行交互的较为复杂的业务逻辑；（2）业务的多入口；（3）包括定位、发送短信、发送彩信以及GIS等数据业务的服务；（4）对数据库的访问；（5）业务自身主动发起的业务。

因此，需要对CPL语言进行一定的扩展，目前包括两方面的扩展——CPL本身语法上的扩展和CPL附加功能的扩展，扩展策略如下：

（1）增加标签message-switch。该标签为switchType类型。脚本执行到这一点的时候阻塞，等待外界信息上报，当外界信息到来时根据其下级标签中声明的消息类型进行分支处理。

（2）增加类型messageType；

（3）增加各种消息标签。这些标签为messageType类型。

（4）增加能力构件标签及其声明。标签的内容包括：构件的名称、参数的名称和类型、是否有返回值、返回值的名称、是否抛出异常、对构件的调用是同步还是异步。这些内容在扩展CPL schema里面声明。目前增加的构件标签包括定位、发送短信、发送彩信、GIS服务等。

（5）增加与OAM模块接口的标签，例如计费。

1.1.1  ICSDL Message-switch标签引入与Incoming标签语义扩充。

如果用扩展CPL即XPL实现的业务能够以多种触发方式来触发，那么业务种类将得到大量增加，业务的丰富性也将极大提高。我们沿用以前的incoming入口，而扩展其语义，使之能够接受除了呼叫上报消息以外的触发消息。能够较好的延续CPL的单入口式业务触发机制，对于业务开发者来说，不需要学习太多新的概念，只需要知道：在这个incoming入口，除了可以接受呼叫上报消息之外，还可以接受诸如web页面点击消息、短信触发消息、地理位置变更上报消息等等消息类型。因此对于业务开发者来说，采取扩展incoming语义方式的CPL具有较平缓的学习曲线。

然而，扩展incoming语义带来的问题是：判断究竟是呼叫消息还是别的消息触发的业务时，显然需要一种类似于CPL里的string-switch那样的分支判断功能语句。在CPL中，switch类型的语句有以下几种：string-switch（对字符串内容进行判断），address-switch（对呼叫地址的所有或者部分进行判断），language-switch（对会话使用的语言类型进行判断），priority-switch（对会话的优先级进行判断）以及time-switch（对呼叫到达的时刻进行判断）。在这些switch中，如果要最大化地利用现有基础而不作大的变动，那么最有可能的候选者就是string-switch。只需要在incoming后面紧接一个string-switch，并且对处在这个位置的string-switch的处理流程做一些特殊处理，使之有别于原始意义上的string-switch，而能够对消息的类型进行判断就可以了。问题在于，业务并不只是在开始的时候需要对消息类型进行判断。在对CPL该语言本身进行分析的过程中，可以发现，出现业务“暂停”的地方为proxy。例如，当呼叫触发某业务时，经过一系列其它处理流程，业务逻辑决定要接续呼叫，于是这里出现了proxy标签。这时候，proxy后面所跟的busy/noanswer等标签，都是一种提示，即：proxy是下发呼叫接续消息给协议网关的动作发出者，之后进入“等待”，也就是“业务暂停”状态。业务的继续执行，是由协议网关来控制的：要么返回接续成功指示，要么返回各种接续失败指示。接到这些指示以后，proxy后继的标签就会沿着相应的分支走下去。这就是一个典型的“业务暂停”案例。在实际的业务中，不仅仅是proxy处才需要这样的暂停。假设这样的业务需求出现了，原始CPL显然是无法满足要求。因此，要达到我们的要求，需要在proxy之后引入一种“业务暂停”机制，使得业务在启用“业务暂停”的这一点能够暂停下来，等待事件的发生，从而再根据事件的类型（也就是消息的类型）来判断往下的分支如何执行。在本业务中，可以想象，在proxy之后，可以启动定时器定时15分钟，时间到达的时候通知业务逻辑；之后就是业务暂停点，它后面可以跟timeout标签（新引入，表示超时事件到达）、onhook标签（新引入，表示通话方挂机）等标签。在定时器超时以后，业务逻辑就会执行到业务暂停点，判断是timeout事件，于是执行timeout分支，后面的业务逻辑就可以任意地进行呼叫控制和用户提示音操作了。可见，引入业务暂停点，做到了原CPL不可能做到的事情，很好地提高了业务的交互性。并且以终极搜索业务为研究案例而言，业务暂停点应用最多的情况就是等待座席的web界面按钮点击，这些点击也会作为消息下发给业务逻辑，因此用业务暂停点来捕捉这些点击事件是再合适不过的了。为了清晰，以及与原始CPL结构统一起见，将业务暂停点的形式也规定为“message-switch”。

定义：当message-switch紧接在incoming之后出现时，该message-switch认为是作为异步形式出现，它的作用就是判断触发业务的消息是呼叫消息还是其它消息，之后跟message标签，用于划分不同分支。当message-switch出现在业务逻辑的其他部分时，该message-switch认为是同步，也就是它需要等待外界消息触发方能继续往下执行。

该标签在脚本中表示脚本运行到这点之后便阻塞，直到由外界消息到来才继续往下运行，将收到的消息与message-switch标签下级定义的各种消息类型进行比较，如果找到匹配的消息标签，就执行相应消息标签下面指定的动作。如果没有找到匹配消息，默认处理就是结束业务。所以业务编写者在编写业务的时候就要考虑完备在该点可能收到的消息。此外，也可以考虑提供”default”标签，表示对找不到匹配消息的默认处理。视开发中的需求而定。

1.1.2  ICSDL中间变量标签variables的引入。

在业务逻辑的执行过程当中，能力构件会产生一些数据结果，输入消息也会携带数据，这些数据往往可以被后面运行的能力构件使用。比如在一个业务逻辑中，可能会先调用获得位置信息的能力元素获取用户的位置，然后生成地图图片的构件需要使用这个位置信息去生成相应的图片。这种数据在业务逻辑描述语言中被称为中间数据。中间数据可以保存在外存（如，数据库）中，再通过提供访问外存的能力元素来获取中间数据。但是如果中间数据的使用比较频繁，势必会降低业务的运行速度。因此有必要将这些数据以中间数据的形式保存在内存中，并提供一种合适的方式对内存中的中间数据进行访问。

1.1.3  ICSDL等待输入消息通信能力的扩展。

虽然在CPL语言中一些标签已经能够提供等待消息的能力，如proxy标签，但是这些标签都是功能标签，与具体应用相关，无法满足业务通用性的需求，因此专门扩展了一个通用的等待输入消息的标签——recvMessage。在一般情况下，recvMessage需要等待外界的输入，然后根据输入的消息转入不同的分支。但如果recvMessage出现在紧接着incoming元素的情况下，由于此时业务必定已经收到一条触发业务的消息，所以recvMessage就不需要再等待外界的输入，而直接判断这条触发业务的消息的名称即可，也就是说紧接着incoming的recvMessage元素不需要等待外界的输入。

由于在某一时刻等待的消息可能会有多种，因此在该标签下就可能会有多个消息节点，每个消息节点代表一种收到的消息。这与proxy有些类似，但不同的是，proxy后等待的消息是固定的，可以在schema里明确定义，而recvMessage等待的消息则是随着业务的不同而不同，因此schema里其子节点就无法直接写成消息的名称。为了解决这个问题，recvMessage的子节点统一使用标签message，该标签有一个属性name表示收到的消息的名称。通过这种方式，业务开发者就可以动态地根据自身业务的需求写上需要等待的消息名称而又遵守了脚本的schema。

在前面曾经提到，收到的消息有可能需要将其携带的参数赋给脚本中的一些中间变量。Message标签实际上就是消息节点，因此，当需要赋值的时候，在message下面需要增加parameters和parameter两种子标签，添加的方式与前面相同，在此不再赘述。

1.1.4  ICSDL的循环控制Goto标签。

除了扩充构件、message-switch以外，还需要对语法结构增加循环语句就是goto。CPL原先设计有sub标签，它可以理解为函数调用，即可以调用在它之前声明过的action，而事实上也可以理解为一种特殊的goto，只不过是单方向的goto，也就是只能够跳转到在sub语句之前。为了提高程序的效率，同时又不破坏程序的良好结构，有控制地使用一些goto语句是有必要的。在实际业务场景中，最经常遇到的跳转情况就是循环放音收号，这是不可避免的回跳型goto。对于终极搜索业务来说，座席不断接听新用户来话也是在该座席登录以后的整个会话过程中——也就是座席脚本执行的过程中——的回跳型循环过程。另一种是非回跳型跳转，例如从等待状态根据用户的输入或者类似的外界条件来多次跳转到不同的action（例如循环地发送短信、email等）然后又跳回等待状态——这在今天的手机导航业务中可以很明显地看出来。因此如果继续沿用CPL纯线性顺序执行机制，那么这些用户体验丰富的特色业务都将成为不可能。综合考虑兼容性和功能性，决定在扩展CPL中添加goto标签。这样既保留了原有sub语句的定义，又满足了新的跳转要求。goto标签与sub标签的使用方式基本相同，所不同的只是它的语义是可以跳转到在任何地方声明的subaction。

1.1.5  ICSDL业务能力构件标签的扩展。

脚本语言将会包含许多与具体应用相关的业务能力标签，比如呼叫能力标签、短信能力标签、GIS能力标签等，这些标签不仅是网络能力在脚本语言中的简单表示，有的标签可以具有一些简单的逻辑性。软件构件技术提高了代码的可重用性能力，因此可以将这些能力标签对应的功能用软件构件技术进行实现，在业务脚本中被称为业务能力构件（简称构件）。构件与具体应用相关，随着以后应用环境和网络能力的增加，构件的数量也会随之增加。业务能力构件是一个较为复杂的技术，本文将在后文中给出构件的较为详细的设计。在脚本schema中构件标签都继承自Node类型。

1.1.6  ICSDL扩展能力标签描述文件。

ICSDL扩展能力标签是指用来表示通信网支持的呼叫控制能力以及其他支撑网能力等的能力标签。在不引起混淆的前提下，所述的能力标签也可称为构件。目前系统内建的能力标签包括短信发送/接收能力、呼叫控制能力、定位能力等。随着网络能力的不断扩充和丰富，会出现更多的网络能力，这时候就可以通过在业务脚本中使用扩充能力标签来增加业务的功能。扩充能力标签时，要求遵循扩展语法，并且能力提供者要提供能够调用的相应Java类。书写规范：参见能力标签扩展schema。

1.1.7  ICSDL支持多脚本交互的扩展标签。

复杂业务需要多个脚本来描述多个独立子业务流程，这些脚本之间的交互需要通过消息队列来进行。脚本通过指定消息队列的名称来说明自己使用到哪些消息队列，每个脚本可以往消息队列中写消息，也可以从消息队列中取消息，也可以既读又写。通过在参与交互的各个脚本中商定好需要使用的消息队列的名称，就可以实现多脚本之间的交互。

为此，引入notify_message和pick_message标签，向名为bufferName的字符串链表添加一个记录，此标签是同步的。向本脚本树对应的字符串链表查找满足匹配条件的记录，此标签是同步的。

1.1.8  ICSDL数据库访问语法元素。

为了能够在业务逻辑描述语言中能够访问和修改数据库里的数据，在业务逻辑描述语言中专门定义了相应操作的构件，目前包含最常用的添加、删除、查询和更新操作。这些功能都可以以构件的形式提供。

1.1.9  ICSDL其他扩展。

扩展CPL为了能够支持强大的业务逻辑能力，需要能够在脚本中嵌入表达式，以便在运行时获取并处理各种数据。为此，规定用“$”作为表达式的起始标识，在此符号后，紧接表达式的内容，可以为各种算术、逻辑运算表达式，也可以是从业务运行上下文ServiceContext（见后文）中提取内容并进行运算。当构件的参数为数组时（主要是于数据库查询操作的参数），脚本中可以用“~~”作为数组的各个元素的分隔符，将各个元素的值隔开，从而可以将一个数组放在XML标签的一个属性中。

二、下面我们对基于构件的I-VASDL解析器的设计与实现过程进行说明。

根据前述内容，我们采用翻译器模式来进行CPL脚本的解析。面对以XML格式出现的CPL脚本时，所需要做的工作是将XML文档解析成树型结构，之后再通过某种方式映射成翻译类语法树，最后进行代码生成。这样，可将XML脚本到语法树的翻译过程划分为前端，语法树到目标Java代码（直至EJB）的过程划分为后端。这样划分的优点是：当如果需要做某些大的变动，例如，如果要求翻译CPL之外的语言，那么需要修改的部分只有前端，后端基本上可以不动。反过来，如果生成目标代码需要是Java语言之外的语言（如由于技术的选择或者政策等原因要求使用EJB以外的技术），那么也只需要修改后端代码生成部分，就可以达到目的，从而最大地减小了牵一发而动全身的可能。

具体的前端主要组成部分包括：DOM（Document Object Model）解析器和Converter类组。后端主要组成部分是CodeGenerator类组。前端将XML文本经过DOM引擎解析之后成为DOM树对象，每个节点就映射为一个个Element对象，之后由一个称为ConverterFactory的核心类，将Element树映射到Converter树（这里用了一次翻译器模式），至此为前端。后端从Converter树开始，由每个Converter类（准确地说，是Converter的Converter的各个子类）再将自己映射为CodeGenerator树，每个CodeGenerator子类进行实际的语境分析和最终Java代码生成。到CodeGenerator为止，翻译器所做的工作已经完成了从CPL脚本到Java主要代码的转换工作，要成为最终可运行的EJB模块，还需要依赖于相当一部分的周边工作。这些工作主要包括Java类的最终生成、EJB配置文件的生成、业务EJB的打包（如果使用到数据库的话，还需要涉及到数据库EJB的配置文件生成和EJB打包）、运行依赖库的生成、最终EAR包的打包，至此，一个可运行的EJB模块即告成。如图3所示的一个完整的业务，包括CPL脚本、业务数据描述文件以及业务配置文件，它们均由业务开发者提供。

图3为本发明的业务翻译器/模块的功能框图。如图3所示，该业务翻译模块，主要包括：

CPL脚本：定义了业务的流程，包括对各个功能构件的调用、消息的收发和处理等。

CPL脚本管理模块：对下层模块屏蔽CPL脚本的物理位置，即无论CPL脚本是以物理文件形式还是以数据库表项或者其它形式存在，此模块都能够分别对待，无差别地向下层模块提供CPL脚本的内容。

树结构生成模块：根据上层模块传进来的CPL脚本，生成脚本对应的树。以便下层模块对其进行解析、翻译。

CPL解析模块：为业务翻译模块的核心。它根据树结构生成模块生成的树结构，对其进行语义分析，并结合上下文，生成相应的Java代码（详细翻译算法参见后文）。它要用到的几大数据结构包括：扩展CPL Schema、业务运行上下文(Service Context)、符号表。

这里，扩展CPL Schema是本业务平台对基本CPL Schema进行扩展后的Schema。业务运行上下文(Service Context)，是某特定业务实例运行时存储变量以及上下文交互信息等内容的环境对象。Service Context用于存储业务运行时数据。随着业务的不同，它们运行时所需要维护的数据也不同，例如呼叫／web消息等外界消息中的属性，以及调用构件的返回值等等。这些数据需要存储在业务EJB中。由于这些数据的类型各不相同，因此用统一的名－值对映射来存储比较好。这样的名－值对映射就是由Service Context来维护的。符号表，用来保存解析过程中识别的符号，便于后继的代码生成。

Java代码生成模块：根据CPL解析模块解析的结果，以及上述几大数据结构，进行适当综合，代码写入，最终生成可编译的Java代码。

这里，业务数据描述文件，描述了该业务使用到的数据库表及其对应的程序语言数据结构。业务配置文件，描述业务在部署时的一些配置项。

配置文件管理模块：对下层模块屏蔽上述两类业务相关信息文件的物理位置。

配置模块：根据配置信息，结合Java代码，生成与之相符合的部署配置文件。

翻译器主要实现将XML格式的业务逻辑描述文件和业务数据描述文件转换成遵循EJB规范的java文件和部署描述符文件并最终编译、打包成可以在EJB容器中部署的ear文件。

翻译过程有多个子任务需要完成，如图4所示，显示了这些子任务（由于对业务逻辑描述文件和业务数据数据描述文件的子任务相同，因此这里不再单独区分开来）。其中：

子任务一：脚本验证。这一步主要是对脚本文件进行验证，如果验证通过则生成一棵DOM树为后面的子任务作准备。

子任务二：代码生成。对于业务逻辑描述文件，这一步遍历前一步得到的DOM树的每个DOM节点，根据DOM节点代表的构件的类型进行翻译，生成符合EJB规范的java代码，包括Home接口、Remote接口和Bean文件的代码，以及部属描述符文件。对于数据描述文件，这一步也是遍历前一步得到的DOM树节点，根据节点的名称生成实体bean的LocalHome文件、Local文件、Bean文件、PK文件以及部署描述符文件。

子任务三：文件生成。这一步是将上一步生成的java代码和部属描述符文件的内容写到相应的文件当中。

子任务四：编译、打包。     这一步是将上一步生成的java文件进行编译生成class文件，然后将class文件与部署描述符文件打成jar包，最后再将根据业务逻辑文件生成的jar包和根据业务数据文件生成的jar包打到ear包中。

2.1  ICSDI业务脚本验证。

由于语法验证可以通过schema直接进行验证，因此在这里不再赘述。

将数据查询操作返回结果赋给中间变量的验证也比较特殊，由于返回结果在构件配置文件中无法定义，因此需要查询数据描述文件，获得结果名称和结果类型的信息，然后进行验证。

2.2  ICSDL业务翻译规则。

2.2.1 业务逻辑描述文件翻译的设计。业务逻辑描述文件将被翻译成有状态的Session Bean，翻译出的文件需要考虑如何与外界交互，如何维护业务实例的状态等问题。

2.2.2 构建标签的翻译。每个构件标签在翻译时都要先生成一个函数，调用构件的代码都在这个函数作用域中。为了使函数名称唯一，可以将从脚本中根节点到此标签节点的路径上的所有节点名称合在一起作为函数名称。

每个构件都会有一个构件类，当遇到代表构件的标签时，在翻译代码里添加调用构件接口函数的语句。由于构件是无状态的，因此接口函数可以设计成静态函数。接口函数的参数分为两种：一种是内建的参数，表示该参数的赋值自动取自脚本内建的中间变量；一种是非内建的参数，表示该参数的赋值由业务开发者在脚本中指定。在翻译构件的时候，每种类型的构件都会有固定的翻译方法。构件的类型、名称以及接口函数的信息翻译器可以通过读取构件的属性配置文件来获取。

2.2.3 产生条件分支标签的翻译。由于在schema里没有指定脚本中必须写上默认逻辑输出节点，因此当在条件分支里没有出现默认节点时，需要添加默认子节点，且根据默认节点的意义可以判断出默认节点应作为最后一个条件分支节点去解释，亦即在前序遍历中默认子节点应被添加为产生条件分支的标签节点的最右边的子节点。

自动添加的默认节点后没有子节点，其语义表示采取脚本语言设计的默认操作，在翻译的时候，可以返回默认消息DefaultRetMessage的实例。消息分发层在收到此消息后转换成合适的消息，比如业务实例在收到一条呼叫消息后返回的消息是DefaultRetMessage。则消息分发层应该返回一条让呼叫网关自行处理后面呼叫的消息。

在翻译逻辑输出分支节点时，除了默认节点外，每个分支节点要生成一个if作用域，而默认节点应生成一个else作用域。但如果只有默认节点作为逻辑输出节点，则在翻译的时候不需要加上else作用域。这些作用域都包含在产生条件分支标签节点生成的函数作用域中。在每个作用域里要加上设置该分支逻辑中下一个处理函数的名称的语句。

2.2.4等待消息标签节点的翻译。这些节点在执行完后需要等待外界的输入消息，因此业务逻辑在执行完该节点后应该结束执行，并等待直到新的消息输入。因此，该节点应该产生两个函数，第一个函数里包含调用该类型节点的代码，第二个函数包含等待消息的代码，且第二个函数作为第一个函数的后继，第二个函数可以称为回调函数，以“Callback”作结尾。

该类型节点的子节点必定是消息分支节点，因而回调函数中的代码将采用产生条件分支作用域，等同于条件分支作用域的翻译方法。

2.2.5 叶子标签节点的翻译。对于没有子节点的标签节点（包括在翻译过程中添加的默认节点default或otherwise），即叶子标签节点，除了sub和goto外，其他的节点都表示在执行完该节点代表的功能后，脚本逻辑结束了。因此，在该节点所生成的函数作用域中将下一个处理函数的名称设置成空字符串，还需要将返回消息标志成最后一条消息，表示业务逻辑已执行完毕，供消息分发模块维护业务实例的生命周期。

2.2.2.6 翻译规则。由于通用业务平台中脚本要被翻译成EJB程序，因此这里翻译器将以翻译成EJB程序作为描述基础。

对于Home接口文件、Remote接口文件和部属描述符文件，由于它们里面的内容比较固定，与具体脚本的名称及内容没有太大联系，所以可以直接生成，而不用遍历脚本文件。而对于Bean文件，其内容与脚本文件有紧密联系，因此只有在遍历脚本文件后才能生成文件内容，下面将介绍生成Bean文件内容的翻译规则。

2.2.7 代码生成的优化。分析各种类型标签的翻译规则可以发现，每种类型的标签在被翻译的过程中都需要一些信息，比如同步且无逻辑输出类型的构件标签，只需要知道构件接口函数的参数；异步类型构件标签，还需要知道其下面都有哪些消息分支；而recvMessage标签，还需要知道recvMessage标签是否在incoming标签下。需要哪些信息对每种类型的标签是固定的，但这些信息在脚本中以何种语法格式进行表达则可能会随着脚本schema的变化而改变。为了减小语法格式对翻译规则的影响，可以将代码生成子任务划分成两个阶段：翻译信息的转换和翻译规则的实施。

翻译信息的转换：解析脚本生成的DOM树结点，获取对应类型标签翻译时所需要的信息，这个阶段与脚本的具体语法格式有紧密的联系；

翻译规则的实施：根据前一阶段获取的信息实施具体的翻译工作，该阶段与具体语法格式没有联系。

两个阶段的划分，可以带来两个好处：其一，如果脚本语言的语法格式在以后发生了变化，比如构件接口函数参数赋值在脚本中采取构件标签子节点的形式表达，则只需要更改第一阶段中获取函数参数赋值的方法即可，而不需要改动具体的翻译算法，减小了翻译器的改动量。其二，如果需要扩展翻译器实现对其他语言的翻译，由于翻译器受语言语法格式的影响较小，因而翻译器的改动量也就减小了。比如实现XTML语言的翻译器的情况。XTML语言中的功能也是通过构件的方式进行提供，其构件也完全可以划分成本脚本语言中构件的类型，因此XTML语言翻译器完全可以采用构件标签的翻译规则。

三、ICSDL业务构件设计。

业务能力构件（以下简称构件）是实现一定功能的代码段，它是对网络能力API的进一步封装。当业务流程执行到某个构件时，构件可以从外界获取信息实现逻辑功能，并向外界返回数据结果；此外，构件在执行完成后可能会产生多种结果分支，使逻辑流程出现分支。根据前面对构件功能的描述，构件的结构如图5所示。主要包括：

逻辑输入模块：每个构件被调用在脚本中表现为一个标签节点，根据前面的描述业务逻辑描述语言采用树状结构，因此每个业务构件都会有一个逻辑输入，表示逻辑已经转入该构件的执行。

逻辑输出模块：构件在执行完后业务逻辑的执行将要转到别的业务构件，逻辑输出指向了下一个将要执行的构件。一个构件的逻辑输出就是其逻辑执行流程中的下一个构件的逻辑输入。有的构件在执行完后可能会有多个逻辑输出，而有的构件可能没有逻辑输出，即构件执行完后业务流程立即结束。逻辑输出在脚本里表示成构件节点的子节点。

数据输入模块：每个构件在运行的时候可能需要从外界获取一些信息，外界信息可以是业务开发者在脚本里使用的常量，也可以是脚本中的自定义变量保存的业务实例中间数据。

数据输出模块：构件在执行完后可能需要产生一些数据，这些数据可以被以后的构件所使用，构件可以将这些数据赋给脚本中的自定义变量。

构件功能实现模块：这是构件功能逻辑的实现所在。

脚本需要解释器进行解释分析，构件的动态增加性会给脚本解释器带来一个问题：如果构件的语法格式与构件的具体含义关联在一起，那么解释器就需要识别出构件的具体含义，然后进行解释。这样，每增加一个构件，就需要改动一次解释器。为了能够在不需要改变脚本解释器的情况下将新增的构件添加到脚本中，就需要脚本为构件在语法格式上定义标准的形式，构件遵从这些形式融入到脚本中，解释器只需要能正确解释这些标准的形式就可以解释所有的构件了。这种关系类似于插座和插件的关系，脚本语言提供的标准接口就是插座，而构件就是插件，构件通过这些插座插入到脚本语言中，即便以后增加了新的插件，只要这些新的插件遵从已有的插座接口，这些插件仍旧可以通过插座插入到脚本中。不同的构件往往会有不同的特质，比如有些构件可能会有输出结果，有些构件就没有；有些构件在完成功能后产生的结果只有成功和失败，而有些构件可能会有更多的输出结果；有些构件在执行完后立即执行其下面的构件节点，而有些构件在执行完后可能需要等待外界的消息再执行下面的构件节点。可以对构件按这些特质进行归纳分类，每种类型的构件具有固定的语法格式，为方便构件标签的翻译，本脚本语言中的构件被划分为以下几种类型：

同步且无逻辑输出类型构件：这种构件在执行完后不需要等待外界输入即可直接执行下一个构件，同时这种构件不会产生输出结果，如success、failure等，亦即这种构件的节点不会有输出结果子节点。比如CPL语言中原有的redirect和reject构件就属于这种类型，因为它们的后面不能跟子节点。

同步且有逻辑输出类型构件：这种构件在执行完后不需要等待外界输入即可直接执行下一个构件，同时这种构件会产生多个输出结果，如success、failure等，亦即这种构件的子节点必须是输出结果子节点，否则该构件的节点不能带子节点。比如发送短信构件，其输出结果子节点可以是success、failure。只有在输出结果子节点下面才可以跟其他的构件节点。

异步类型构件：这种类型的构件是指当该构件执行完毕后，需要等待外界的输入，根据外界的输入继续执行后面的逻辑。这种构件的节点包含消息子节点，如果在脚本中没有指定任何输出结果子节点，则会有一个默认的default子节点作为输出节点，并执行默认的操作。CPL中的proxy构件就是这种类型的构件，proxy在执行完前转呼叫的动作后，等待前转返回的消息。

选择类型构件：这种类型构件是名称以“-switch”为结尾的节点表示的构件，它表示将根据某些中间数据的值进行匹配选择，产生条件分支。其分支子节点在本文中被称为选择后继节点。

与其他产生条件分支的节点不同的是，选择后继节点要执行构件动作。以string-switch为例，string-switch表示对字符串进行比较，而真正的比较动作是其选择后继节点——string节点完成的，即具体是跟哪个参数比较，是精确匹配还是模糊匹配等都是由string节点完成的。因此，只有在遇到选择后继节点时才真正执行构件，然后根据构件的逻辑输出判断逻辑是否该沿着对应选择后继节点的分支走下去。这里可以规定当选择后继节点代表的构件的逻辑输出是success时则执行该分支，其他的任何逻辑输出都表示逻辑不走该选择后继节点分支，但是这个逻辑输出不在脚本中表达出来。选择后继节点下直接跟其他的构件节点。选择类型构件执行完后也不需要等待外界的输入，而是直接可以运行后面的逻辑。

异步：在调用完这种构件的API后，业务逻辑需要阻塞等待消息；

这里，消息是指业务逻辑实例从网关或web客户端获得的消息，允许业务开发者自己定义；Switch类型，是脚本语言中的条件判断类型，例如cpl中原有的switch类型以及扩展的<message-switch>，switch类型的标签没有对应的构件，其属性将作为switch后继标签属性的一部分；Swich后继，是例如cpl中的<string>、<time><address><priority>以及扩展的<message>，它们除了包括自己的属性外，还包括所在的switch标签的属性。

通常情况下，脚本解释器在执行过程中需要一些信息，包括：构件的类型；构件输出的数据结果；构件实现中调用接口的参数类型。但脚本的schema无法提供这些信息，因此需要为构件专门设计一个配置文件来指定这些信息，解释器通过读取构件属性文件中的信息即可获得构件的类型和调用参数。

这里主要说明系统核心部件即业务生成引擎的主要实现技术。业务生成技术的本质就是某种形式的软件复用技术。基于构件的软件复用是目前研究和应用的重点。当前基于接口的构件组装方法讨论得较多，这种方法依靠构件直接调用其它构件的接口（或者通过所谓的连接子进行调用）完成构件的组装。XPL这种应用场合的构件组装与一般意义上的构件组装的区别在于：

1）业务开发者用XPL描述业务流程，并不直接进行构件组装，构件组装需由系统完成，系统在构件组装的实现上需要统一的方法来自动实现；

2）如果沿用基于接口的构件组装模式，那么如顺序执行、选择等流程操作也必须实现在构件的内部，构件会比较复杂，可以考虑将构件中流程控制等共性的东西从构件中剥离出去，系统在完成从XPL到可执行代码转化的过程中再把这些共性的东西加入。

基于此，我们设计了一套基于上下文的构件模型和针对该模型的脚本转换——构件粘合算法，该算法依照业务脚本产生“胶水代码”，由“胶水代码”来把构件粘合起来，来控制构件的执行。

XPL的标签是需求的描述单元，对应的能力实现单元是构件。每个构件都有特定的前置条件键P和后置条件键E（P和E也可为空）。构件在运行前先从上下文中载入前置条件，运行结束后向上下文回写后置条件。构件是一个类，必须实现4个方法：

void  loadContext()::=<从上下中加载P所对应的信息>。

boolean  willBeTrigered()::=<判断该标签是否满足运行的条件，实现XPL的选择操作>。

void  process()::=<实现该标签的主要业务逻辑>。

void  fillContext()::=<将标签运行结果写入到上下文中E所对应的地方>。

采用脚本转换——构件粘合算法：

1）按定义2将XPL脚本文件拆成多棵业务片段构成的树tree，每棵tree对应一个EJB商务方法，该方法将用来响应Event事件。因为要满足各个方法之间被网络调用的次序，方法名定为从Flow的根到tree的根所经过标签的名称组成的字符串。

2）将<subaction>进行和响应标签同样的处理，即<subaction>定义的脚本子树也拆成业务逻辑片段，和步骤1所不同的是对应的EJB方法被业务自己调用，因此对应一个EJB私有方法，方法名为<subaction>属性id的值。

3）对在步骤1）、2）中形成的所有业务片段树进行一种特殊的前序遍历，在遍历的过程中把标签对应的构件用“胶水代码”粘合起来，形成业务片段对应的EJB方法内的代码。如下述伪码所示。

斜体部分即为将在EJB方法中形成的“胶水代码”， recordRunTimeLogicTrace为一辅助方法，作用配合EJB商务方法的名称，系统在响应Event事件的时候就能正确选择调用业务片段。  

这种基于上下文的构件组装机制使得构件本身得到简化，形式上更加规整，制作也变得容易，有利于扩展新的构件。构件组装方法体现为一种算法和纯粹的基于接口的构件组装方法相比虽然复杂，但对业务开发者是透明的，且相对稳定，可以进行充分复用。这种构件复用模型是适用于XPL的一种更高抽象层次的构件复用模型。

四、ICSDL业务运行时消息分发器即消息分发系统的实现。

CPL翻译器生成的业务可执行文件部署在通用业务平台中运行时，需要引入消息分发系统来支持生成的业务的运行。分析如下：

1）在通用业务平台系统中，底层协议网关模块实现的上报消息的接口是基于Web Service的Parlay X接口，而生成的业务可执行文件对外提供的是EJB的远端接口。当两种不同的接口要交互消息时，需要一个中间层来进行接口调用之间的转换。如图6所示为协议网关和业务的接口描述示意图。

由于Parlay X规范根据所使用的网络能力的不同，定义的协议网关层与应用层间的接口也就不同。协议网关层在上报消息时，调用的接口并不是统一的，同时传递的消息也没有统一的格式。而生成的业务都具有统一的接口，统一的入口出口消息，统一的运行方式。因此业务在处理底层协议网关上报的消息时，需要在业务可执行文件和协议网关之间增加一个子系统，来完成对接口的映射、消息的转换。如图7所示为协议网关和业务的消息类型示意图。

 图8为本发明的消息分发系统的结构示意图。如图8所示的消息分发系统的位置可知，消息分发模块是业务层的关键模块之一，它接收业务平台系统中其他模块发送来的消息，对消息进行判断、处理，将其分发到对应的业务层的模块中去。与此同时，它还接收来自业务层内部模块发送到平台系统中其他模块的消息，对消息进行相应的处理和判断后，将消息发送到相应的模块中去。具体来说：消息分发系统接收Web客户端提交的消息和协议网关层上报的消息，判断并分发到业务层中对应的业务实例；另外消息分发子系统还接收来自业务实例发送的消息，判断并转发到协议网关模块。消息分发模块既要处理业务逻辑模块向网关下发的消息又要处理网关向业务逻辑模块上发的消息。对于下发消息直接在消息发送子模块的相应接口中调用下层网关侧提供的接口即可；而对于上发的消息处理较为复杂，应能根据上报的消息信息判断出是否需要建立业务运行实例，发给哪个业务运行实例等。

消息分发模块，用于处理Web客户端和业务逻辑模块、网关和业务逻辑模块之间的交互信息。Web客户端或者网关向业务逻辑模块上报事件时，都需要通过消息分发模块进行，消息分发模块根据消息类型、参数等信息，创建或找到对应的业务实例来处理，并将业务逻辑处理的结果返回给Web客户端/网关。另外，当业务逻辑模块要使用网络能力时，也需要通过消息分发模块进行，消息分发模块在调用底层网关来实现具体地对网络能力的调用的同时，还保存一些与业务运行相关的信息，以便于此后网关上报消息时，能找到对应的业务实例。

4.1 消息分发系统所支持的接口。按照与消息分发子系统交互的接口实现方法、接口模块的不同，分为协议网关上报消息接口、Web客户端提交消息接口和业务发送消息接口。

4.2 协议网关上报消息接口。协议网关上报消息接口是由协议网关发起的、到消息分发系统的Web Service接口，本接口基于标准的Parlay X规范，同时对Parlay X接口规范做了适当的扩展，来适应通用业务平台对业务能力的需求。

4.3 Web客户端提交消息接口。这类接口是Web客户端与消息分发子系统之间的接口。如，procWebMsg：Web客户端向业务提交信息。

4.4 业务发送消息接口。业务发送消息接口是由业务发起的、到消息分发系统的Web Service接口：如，makeACall：业务发起呼叫；getCallInformation：业务调用该接口来获得一个呼叫的信息等。

如图8所示的本发明的消息分发系统的结构示意图。根据所完成的功能的不同，其中的消息分发模块进一步包括四个子模块：消息发送子模块、消息接收子模块、业务管理子模块和业务实例管理子模块。其中：

业务实例管理子模块，用于完成业务实例的创建、维护以及删除功能。设计该模块的目的在于，当业务层创建或查找业务实例的规则改变时，只改变业务实例管理器的实现即可，而不用修改处理消息的各个接口的实现，降低了消息处理接口与业务实例管理之间的耦合性。例如消息接收模块在处理网关上报的消息时，需要找到或者新建处理该消息的业务实例，消息接收模块只需调用对应的业务实例管理器的接口来获取业务实例，而由业务实例管理器来决定是创建一个业务实例还是在已经创建的业务实例中查找，对消息接收模块屏蔽了业务实例查找的实现细节。

消息发送子模块和消息接收子模块，用于根据消息分发系统接收到的消息的方向的不同，将处理协议网关模块、Web客户端的消息的模块成为消息接收模块，而把处理业务实例模块的消息的模块成为消息发送模块。两个模块完成的功能就是实现接收到的外部消息与业务层内部消息的相互映射，实现对外部消息的屏蔽。这样在外部的接口改变时，例如协议网关模块与业务模块的接口改变时，就可以只修改消息接收模块内部的实现，实现协议网关消息到内部消息的映射，消息分发子系统内部的接口不需改变。

业务管理子模块，设计该业务管理子模块的目的是为了提高系统的可扩展性。该业务管理子模块，用于与OAM模块进行消息交互，一旦与OAM的接口改变，只需要修改业务管理子模块，而无须改变其他模块。

其中：业务管理子模块，用于实现与管理业务相关信息的功能，包括：

1）业务查询。2）业务配置信息查询。3）业务能力鉴权。4）业务有效性验证。5）心跳检测。6）处理业务信息改变的通知。

4.4 业务逻辑向网络能力Web Services发送消息的过程。

请参考图8，如图9a所示为业务逻辑发送消息的合作图、如图9b所示为业务逻辑发送消息的序列图。该业务逻辑发送消息的过程主要包括：

步骤1：业务逻辑模块调用消息发送模块向网络能力模块发送消息。对于每一个网络能力提供的发送消息的接口，消息发送模块也给应用提供相同的接口。之所以通过消息发送模块来使用网络能力，是为了在发送消息的同时由业务实例管理模块来保存与业务实例相关的信息，如对业务实例的引用。

步骤2：消息发送模块调用网络能力模块的接口发送消息。

步骤3：发送消息调用完毕，网络能力模块给消息发送模块返回值。

步骤4：消息发送模块根据返回值，调用业务管理模块记录一些业务运行相关的信息。

步骤5：业务管理模块调用业务实例管理模块保存业务运行相关的信息。

步骤6：消息发送模块将返回值返回给业务逻辑模块。

五、具体实现示例。

图10为本发明面向融合网络混合服务流程编制语言的开发系统的应用实施例。如图10所示，该系统包括系统总控模块（Controller）、配置模块（developenviroment）、翻译总控模块（interpretation）、业务验证模块（validation）、业务翻译模块（enception）、文件生成模块（filegeneraion）、编译模块（compliation）。其中：

系统总控模块创建配置模块和翻译总控模块；配置模块取得脚本路径等配置信息供翻译模块使用；翻译总控模块为调度业务验证模块、业务翻译模块、文件生成模块、编译模块的核心；后四个模块按照业务的生成流程，顺次为前端和后端的关系，前者的输出作为后者的输入。

系统总控模块，负责创建配置模块和翻译总控模块，获取配置信息并进行翻译。

配置模块，通过配置文件等方式，获取关于脚本存放路径、消息类存放路径、构件类存放路径等信息，供翻译/编译模块使用。

翻译总控模块，调度其下属4个模块，进行翻译工作。

业务验证模块，使用扩展CPL schema等规范，对业务开发者提供的业务脚本进行词法和语法等校验。

业务翻译模块，综合各种业务描述文件提供的信息，将业务脚本编译成可执行的EJB代码。

文件生成模块，综合业务翻译模块生成的代码和业务脚本的信息，生成完整的EJB Java文件。

编译模块，用于编译EJB Java文件，生成可部署的jar/ear包。

六、应用场景示例。

6.1 点击拨号业务。

该实例比较简单，下面给出完整的业务脚本。业务场景是：用户从web页面发起一个点击拨号业务，试图建立主要方和被叫方的通话，若不成功，向主叫方和被叫方发送一条短信通知，若成功，向主叫方和被叫方发送一条彩信名片，描述方便起见，彩信名片采用网络上的指定URL。这个业务实例包含了短信和彩信操作，CPL、CCXML、SCML均无法描述。

6.2 语音陪聊业务。

业务场景是：有陪聊代理多人，代理使用手机以短信的方式通知业务其开始工作，开始接受客户的电话咨询；客户拨打特服号码，业务分配一个代理为他服务。该业务由两个脚本构成，脚本login.xml用来处理代理通过短信登陆/注销系统,脚本service.xml用来处理用户的呼叫。这项业务综合使用了呼叫、放音、短信、数据库操作等基本能力，以及循环、并发等流程控制手段，并实现了代理和客户的排队，CPL、CCXML、SCML无法完成这样逻辑复杂，内容丰富的业务。

图11为代理登录脚本login.xml的示意图，图12为代理服务脚本service.xml的示意图。本发明限于篇幅，未将语音陪聊业务用XPL描述其完整的业务流程和对业务流程的说明写成XML形式。

消息队列数据结构说明：Q_Name =“agent”，S个数为1，值为代理手机号；Q_Name =“counting”，S个数为1，值为固定字符串“counting”，该队列作为计数器表示当前可服务的代理人数；Q_Name =“user”，S个数为1，值为客户手机号。

参考图11，脚本login.xml流程说明：代理发送验证码短信到特服号，若队列agent中已有该代理手机号①，完成注销流程，否则在数据库中查找对应的验证码进行验证②（简单起见省略CMP和EJB_QL书写的脚本），不成功给代理发送短信提示③，若成功将代理手机号放入队列agent④，当前可服务的代理人数加1⑤，短信提示登陆成功⑥。

参考图12，脚本service.xml流程说明：客户拨打特服号码接入系统，进入user队列排队①，客户是否排第一位②，不是的话给客户放音③让客户等待，<run_UI>是分段标签，网络上报放音结束事件<ui_End>驱动<goto>进入循环体wait_in_line_1，发生超时<timeout>或用户挂机事件<calleronhook>则将该用户从队列user中清除④并结束业务。若客户排第一位则查看当前是否有可服务的代理⑤，若没有放音等待，若有将agent中所有代理手机号作为呼转的目标地址⑥并开始顺呼⑦，和最先摘机的代理建立连接，代理挂机⑧，将计数器counting加1⑨，给用户发送代理的彩信名片（简单起见通过URL访问彩信图片）⑩。代理在工作期间自由使用手机，不可避免的⑦有可能不成功，业务会向代理发一条短信指示agent中排第一的代理稍后给用户回电。

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

Claims (10)

1.面向融合网络混合服务流程编制语言的开发系统，其特征在于，包括业务平面、业务流程的脚本描述平面、可执行代码平面以及网页服务接口平面；其中：

业务平面，用于确定当前的业务需求是否适用于业务生成系统生成；所述业务生成系统具有良好的可扩展性，通过增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求；

业务流程的脚本描述平面，主要用于完成业务的开发工作；在业务平面的业务需求确定后，使用XPL语言描述业务逻辑；

可执行代码平面对应于所述业务流程的脚本描述平面，用于从描述好的业务流程生成的可以部署运行的代码；

网页服务接口平面，主要包括Parlay网页服务接口和其他类型的网页服务接口；所述网页服务接口平面用于向业务生成系统提供开发业务所需的业务能力。

2.根据权利要求1所述面向融合网络混合服务流程编制语言的开发系统，其特征在于，所述增加XPL语言的标签和新开发对应的构件包括：

switchType类型的标签，messageType类型的标签及各种消息标签；增加能力构件标签的声明，所述标签的内容包括：构件的名称、参数的名称和类型、是否有返回值、返回值的名称、是否抛出异常、对构件的调用是同步还是异步；以及增加与OAM模块接口的标签。

3.根据权利要求2所述面向融合网络混合服务流程编制语言的开发系统，其特征在于，所述增加XPL语言的标签和新开发对应的构件，进一步包括：

语义扩充的Incoming标签，中间变量标签variables，循环控制Goto标签，业务能力构件标签扩展schema以及支持多脚本交互的扩展标签notify_message和pick_message标签。

4.根据权利要求1至3任一所述面向融合网络混合服务流程编制语言的开发系统，其特征在于，所述增加XPL语言的标签和新开发对应的构件，主要用于：

需要与用户进行交互的复杂业务逻辑；

业务的多入口，包括定位、发送短信、发送彩信以及GIS等数据业务的服务；

对数据库的访问；以及

业务自身主动发起的业务。

5.根据权利要求1所述面向融合网络混合服务流程编制语言的开发系统，其特征在于，所述可执行代码平面通过使用业务生成技术，使XPL的每个标签在代码实现上都对应着一个构件，业务生成系统事先准备好XPL中所有用到的构件并存放在构件库中；所述业务生成系统根据用XPL所描述的业务逻辑将业务流程中所涉及到的构件组装起来，并封装成EJB，形成可以实际部署运行的业务。

6.面向融合网络混合服务流程编制语言的开发方法，其特征在于，包括：

A、采用业务平面确定当前的业务需求是否适用于业务生成系统生成；所述业务生成系统具有良好的可扩展性，通过增加XPL语言的标签和新开发对应的构件，扩展业务生成系统的能力来满足业务的需求；

B、利用业务流程的脚本描述平面，完成业务的开发工作；在业务平面的业务需求确定后，使用XPL语言描述业务逻辑；

C、然后利用对应于所述业务流程的脚本描述平面的可执行代码平面，从描述好的业务流程生成的可以部署运行的代码；

D、最后通过网页服务接口平面向业务生成系统提供开发业务所需的业务能力；所述网页服务接口平面，主要包括Parlay网页服务接口和其他类型的网页服务接口。

7.一种包括面向融合网络混合服务流程编制语言的开发系统的网络增值服务平台，包括CPL业务脚本、OAM模块及协议网关层；其特征在于，其业务处理系统还包括业务翻译器和消息分发系统；其中：

业务翻译器，用于对扩展CPL业务脚本进行解析，得到符合EJB规范的java代码，然后生成java文件，并得到文件包；

消息分发系统，用于接收Web客户端提交的消息和协议网关层上报的消息，判断并分发到业务层中对应的业务实例；另外消息分发系统还接收来自业务实例发送的消息，判断并转发到协议网关模块。

8.根据权利要求7所述的网络增值服务平台，其特征在于，所述业务翻译器主要包括：

CPL脚本管理模块，用于对下层模块屏蔽CPL脚本的物理位置，即无论CPL脚本是以物理文件形式还是以数据库表项或者其它形式存在，此模块都能够分别对待，无差别地向下层模块提供CPL脚本的内容；

树结构生成模块，用于根据上层模块传进来的CPL脚本，生成脚本对应的树，以便下层模块对其进行解析、翻译；

CPL解析模块，用于根据树结构生成模块生成的树结构，对其进行语义分析，并结合上下文，生成相应的Java代码；

Java代码生成模块，用于根据CPL解析模块解析的结果和相应的数据结构，进行综合、代码写入，最终生成可编译的Java代码。

9.根据权利要求7所述的网络增值服务平台，其特征在于，所述消息分发系统包括消息分发模块，其进一步包括消息发送子模块、消息接收子模块、业务管理子模块和业务实例管理子模块；其中：

消息发送子模块和消息接收子模块，用于根据消息分发系统接收到的消息的方向的不同，将处理协议网关模块、Web客户端的消息的模块成为消息接收模块，而把处理业务实例模块的消息的模块成为消息发送模块；所述两个子模块完成的功能是实现接收到的外部消息与业务层内部消息的相互映射，实现对外部消息的屏蔽；

业务管理子模块，用于与OAM模块进行消息交互，实现与管理业务相关信息的功能，提高系统的可扩展性；

业务实例管理子模块，用于完成创建、保存、查找、删除业务实例的功能。

10.根据权利要求7所述的网络增值服务平台，其特征在于，所述服务平台中的面向融合网络混合服务流程编制语言的开发系统进一步包括业务能力构件，其主要包含：

逻辑输入模块，每个构件被调用在脚本中表现为一个标签节点，根据前面的描述业务逻辑描述语言采用树状结构，因此每个业务构件都会有一个逻辑输入，表示逻辑已经转入该构件的执行；

逻辑输出模块，构件在执行完后业务逻辑的执行将要转到别的业务构件，逻辑输出指向了下一个将要执行的构件；

数据输入模块，每个构件在运行的时候可能需要从外界获取一些信息，外界信息为从业务开发者在脚本里使用的常量，或脚本中的自定义变量保存的业务实例中间数据；

数据输出模块，构件在执行完后可能需要产生一些数据，所述数据能够被以后的构件使用，构件将所述的数据赋给脚本中的自定义变量；

构件功能实现模块，为构件功能逻辑的实现所在。