专利名称：基于xpl的综合多种通信手段的业务生成方法及其系统的制作方法
技术领域：
本发明涉及一种下一代电信网络综合性通信业务的生成技术，确切地说，涉及一种基于Web服务和扩展呼叫处理语言XPL的综合多种通信手段的业务生成系统和方法，该业务生成系统和方法不仅具有较强的语音类业务生成能力，同时还具有较强的短信、彩信、Email、定位、web应用的后台业务逻辑，以及数据库操作等数据类业务的生成能力。属于电信增值业务或电信和计算机应用
背景技术：
目前，国内外有关业务生成技术的研究概况简介如下在电信领域已经研制出一些专门用于描述呼叫业务的方法，较有影响的有IETF的CPL、W3C的CCXML和JAIN的SCML等。这些方法特点是面向特定需求，语言元素本身就是对业务需求的高度抽象，优点是语言简单、灵活，开发业务的速度快，对业务开发人员的技术要求低，缺点是不能描述特定领域以外的业务。
计算机领域也已出现一些用来描述业务流程的方法，影响力较大的有BPEL等。BPEL是一种通用的流程描述语言，其设计重点是通用性的语言元素，如对流程的控制，对变量的控制等，这些语言元素的能力和JAVA等高级语言基本属于同一水平。这种通用性语言的优势是适用面广，但是语言复杂，开发效率较低，对开发人员的技术要求高。
比较前沿的业务生成研究是基于语义网(Semantic Web)技术和利用人工智能的方法，从用户的需求直接生成新业务，但是，这种方式还停留在理论研究的阶段。
随着下一代网络的迅速发展，业务生成技术的研究已经成为业内技术人员所关注的焦点。现在，业务生成技术必须解决的问题主要有以下三点一、必须要设置一种规范的方式来描述业务的需求也就是要研究设计一种面向特定领域的描述方式，这样才能最大限度地提高业务的开发效率，真正达到业务“生成”的目的。近年来，随着电信网和互联网的发展，传统的呼叫类业务需求相对淡化，而数据类业务(如短信、彩信、定位、以及Web上的电信类业务)方兴未艾，并在网络融合的背景下凸现出强烈的需求。虽然面向特定领域的描述方式开发速度快，但是不可避免的缺点是局限性强。为了在一定程度上弥补这种缺点，尽可能地适应发展、变化的需求，可扩展性应该是设计面向特定领域的描述方式时考虑的重点之一。
二、要设计能够从需求的描述到可执行程序之间实现转化的软件复用技术众所周知，所谓业务生成，其本质是某种形式的软件复用技术。在软件工程领域，基于构件的软件复用技术是学术界和产业界都在重点研究的一个热点。近年来企业界在中间件技术基础上，结合软件复周思想和面向对象方法，成功地发展出基于构件的软件开发(Component Based Software Development)技术，通过标准化运行级构件的规范和依靠中间件提供的基础设施平台，CBSD提供了一种自底向上、使用标准软件构件构造系统的有效途径，并得到广泛应用。而CBSD提供自底向上的软件复用途径，目前关注的重点主要局限于二进制构件的标准化工作，如CORBA(Common Object Request Broker Architecture)，EJB(Enterprise JAVA Bean)和DCOM(Distributed Component Object Model)。CBSD仅仅提供在实现层次上支持构件交互的基础机制，缺少指导开发过程的系统化方法，特别是对高抽象层次的构件组装无能为力。而这些恰恰是从具体的应用需求描述到可执行程序之间进行转化所必需解决的关键技术。
三、设计业务生成环境的架构时必须考虑网络融合的背景Parlay/OSA被认为是下一代网络中传统的电信类业务的主要业务接入架构，Parlay/OSA对外提供API接口，使得IT开发人员也可利用它开发电信增值业务。但是传统的基于CORBA的API开发模式使Parlay/OSA应用的开发门槛仍然比较高。Web Services是实现Intemet应用之间共享的新的分布式技术，基于通用的网络协议(例如HTTP、SMTP等)和标准的XML(Extensible Markup Language)协议实现松散的客户端/服务器应用模式，基于WSDL(Web Service DefinitionLanguage)实现动态绑定后，使得支持XML和通用网络协议的应用就可实现交互。与CORBA相比，Web Services的开发模式更简单，有更强大的开发队伍和更丰富的开发资源。因此把Web Services引入Parlay/OSA架构中，通过进一步封装Parlay/OSA API，并对外提供Web服务(Web Services)接口，则外部Web服务客户端就可以通过通用网络协议访问电信网络资源。基于WebServices的Parlay web services已经使得广大IT开发人员利用Web Services开发工具在电信网络以外快速、有效地开发电信增值业务成为现实。此外，在电信领域以外，随着Internet的发展，很多公司都将其自身业务能力通过WebServices向外界开放，Web Services技术已经成为解决异构网络融合问题的一个有效手段。业务生成环境和技术必须要采用基于面向服务的构架(SOA)体系，以Parlay/OSA API和其他的标准Web Services接口连接底层基础网络，这样才能适用于目前网络融合条件下的业务生成技术。
目前，电信领域的增值业务大多由智能网(IN)来提供。尽管智能网将其提供的增值业务已从基础网络中剥离出来，并在以语音业务占主导的时代做出了重大贡献，但是智能网体系结构在网络演进和网络融合的大背景下，也越发显现出不足，主要包括1、实现跨网业务比较困难近年来，在IN与Internet业务互通上，相关研究机构提出了一些解决方案(如IETF的PINT)，但从长远观点来看，这些解决方案不能代表网络技术的发展方向，无法从根本上解决网络融合带来的挑战。
2、IN是个封闭系统业务生成环境SCE、业务管理系统SMP和业务控制点SCP之间是绑定的，不同供应商之间的系统不能互通。智能网虽然定义了若干可重复应用的业务独立的功能块SIB，但不同厂商的SIB无法实现很好的通用，业务开发和提供不能真正独立于智能网平台，更谈不上客户化定制，因此，业务只能由运营商甚至设备供应商自己来开发。
3、不利于多种业务的提供智能网的封闭结构，使其只适用于支持传统电信业务，而对多样化业务的支持非常困难，更加难以在多网融合的环境下，接纳更多的角色参与到新业务的定义、设计和运营中来，所以，很难快速提供集成多种网络及应用系统的多样化业务。
因此，在多网融合的环境下，非常需要建立一种能够真正吸引网络运营商、业务运营商、业务开发商和最终用户的业务支撑体系，为参与各方搭建一个能达到多赢目的的平台。
发明内容
有鉴于此，本发明的目的是提供一种基于Web服务和扩展呼叫处理语言XPL的综合多种通信手段的业务生成系统和方法，本发明较好地解决了现有技术存在的各种缺陷，在较高抽象层次上提出一种融合网络条件下的描述面向综合性通信类业务的业务生成方法和对应于该方法的业务生成系统，使用本发明方法及系统，一个经过简单培训的业务开发人员能够以较快速度、比较容易地开发出内容较为丰富的通信类业务。
为了达到上述目的，本发明提供了一种基于XPL的综合多种通信手段的业务生成系统，包括Web Services网关和电信网/因特网；其特征在于所述业务生成系统还包括设有相互连接的业务开发平台和业务运行平台的应用服务器，其中业务运行平台通过Web Services网关接入电信网/因特网，所述Web Services网关用于屏蔽电信网和Internet的差异，向该业务生成系统开放底层网络能力；其中业务开发平台的组成部件包括业务图形化开发工具，用于提供拖拉式可视化控件来开发业务，即采用图形化方法组织业务流程，使业务流程显得简洁、直观，并将图形化的业务流程转换成业务流程脚本文件；所述每个控件对应于业务流程描述方法中的一个标签；所述业务流程脚本文件可以由人工直接书写，以取代图形化开发工具；业务生成引擎，用于接收业务流程脚本文件，并按照业务流程描述方法检查脚本文件，如果发现不符合业务流程描述方法，则报错并中断后续操作；如果脚本文件符合业务流程描述方法的要求，则采用基于构件的软件复用方法，把业务脚本转化为可执行代码，并将该可执行代码送至中间件容器中运行；构件库，用于业务生成引擎将业务脚本转换为可执行代码时，从该构件库中选择加载所需构件，以便把业务脚本中的描述单元所对应的构件按照业务脚本所描述的流程进行组装；所述业务脚本中的标签是需求的描述单元，对应的功能实现单元是构件；其中业务运行平台的组成部件包括中间件容器，用于提供业务实例的运行环境、并对线程池进行管理而使之具有高可靠性的运行平台；在该中间件容器中运行有多个业务实例；消息分发器，用于建立网络侧向业务发起的调用和业务实例之间的映射关系，即当网络侧向业务发起一个调用时，由消息分发器来决定是发起一个新的业务实例来响应该调用，还是选择一个对应的、已有的业务实例来响应该调用；并通过Web Service网关接入底层网络的基本通信能力。
为了达到上述目的，本发明还提供了一种基于XPL的综合多种通信手段的业务生成方法，其特征在于对互联网工程任务组颁布的呼叫处理语言CPL(calling process language)进行扩展，形成一种既能够描述简单的呼叫转移类业务，又能描述具有顺序执行、选择执行、变量控制、循环控制和并发控制能力的复杂的呼叫类业务和数据类业务的业务描述方法或语言-扩展呼叫处理语言XPL，然后利用该XPL业务描述方法描述呼叫类业务和包括短信、彩信、Email、定位，web应用的后台业务逻辑与数据库操作的数据类业务；再利用所述业务生成系统和相应的构件模型和构件组装方法，将用XPL业务描述方法描述好的业务转换为可以部署运行的程序，即将网络开放的Web Services接口和构件所具有的业务能力组织起来，形成满足需求的业务；所述业务生成方法包括下列操作步骤(1)根据XPL定义的业务描述方法，业务开发者利用图形化开发工具或手工书写XPL业务流程脚本；(2)由业务生成引擎将XPL业务脚本文件转化为可执行代码采用基于上下文的构件模型和针对该模型的脚本转换-构件粘合算法依照XPL业务脚本产生“胶水代码”，再用“胶水代码”把各个独立的构件粘合组装在一起，使构件能够按照业务流程依次执行，形成完整的可部署执行的程序；(3)将可执行代码部署在中间件容器中运行。
所述XPL业务描述方法还具有下述功能变量的声明和定义，保证循环和并发控制的安全，以供业务开发者在开发业务时，按照该XPL业务描述方法描述业务需求，编写出一个或多个业务脚本；使用XPL业务描述方法编写的业务脚本分为两种描述业务执行流程的业务流程脚本和描述对数据库的操作方法、以供业务流程调用的数据库操作脚本，描述业务流程的每个脚本文件会被指定的包括呼叫、短信、web网页点击或其它触发条件触发执行，触发结果是在中间件容器中产生一个业务实例；数据库操作脚本则是利用已有的数据库操作描述方法来描述对数据库表进行的增加、删除、查找或其它操作，包括可采用中间件容器EJB的容器管理的持久实体Bean描述的对数据库操作的方法，数据库操作脚本设定数据库的操作方法以后，通过在业务流程脚本中调用之，来实现在业务流程中嵌入的数据库操作。
所述XPL业务描述方法在呼叫处理语言CPL的标签基础上增添有新标签，该业务描述方法所描述的业务流程呈树状结构，树中的每个节点都是一个标签，每个节点的子节点代表业务流程下一步所要采取的操作；如果一个父节点有多个子节点，则选择其中某个满足设定条件的子节点执行业务流程；增添的新标签包括从以<subaction>定义的业务子流程外的业务流程跳转到<subaction>所定义的子流程的<sub>、在以<subaction>定义的业务子流程中使用而重新进入该子流程的<goto>、用于声明变量的<declare>和定义变量的<assign>、放音标签<runUI>、放音收号标签<runUIandCollectInfo>、发送短信的<sendSMS>、发送彩信的<sendMMS>、发送电子邮件的<sendEmail>、取得移动用户当前位置的<getLocation>、完成一个第三方发起的呼叫的<makeCall>，用来调用数据库操作脚本里定义的数据库操作方法的<SQL_Operation>，向消息队列中发送消息<sendMessage>，从消息队列中接收消息<pickMessage>；其中表示业务流程起始点的标签<incoming>不仅用于响应网络上报给应用服务器的呼叫触发事件，还包括网关上报给应用服务器的短信、web网页点击或其它触发事件，来产生业务实例；业务开发者使用上述标签来组织和描述业务流程；所述标签除了各自名称外，每个标签还有各自的属性，业务开发者在使用标签时要填写标签属性，填写方法有两种填写固定值，或填写从业务上下文中提取的特定值；后者是属性值的动态设定方法当业务流程执行到该标签时，系统从当前的业务上下文中提取设定值赋给该属性。
所述业务流程中的循环操作是这样实现的在业务流程中以标签<subactionid＝“”>为根定义一棵脚本子树，表示一段可复用的业务子流程，标签属性id为子树名称，在该脚本子树内使用<goto ref＝“”>重新进入该子流程，标签属性ref为指定的子树名称；为保证业务流程中不出现死循环，采用接受用户行为驱动的回溯控制机制在使用<goto>进行循环操作时，<goto>和属性ref所指向的<subaction>之间、即循环体内至少设有一个分段标签和响应标签构成的组合，以便在每次循环的执行过程中，业务都必须要等待网络侧的调用，且系统规定了业务处于等待的最长时间，以保证业务流程中不会出现死循环；所述业务流程中的并发控制是这样实现的采用XPL业务描述方法书写的每个脚本经过网络触发后形成多个实例，这些业务实例通过共享消息队列通信，完成实例之间的协作，形成并发操作；业务流程在执行到<sendMessage>时，系统将消息放入消息队列，且在<sendMessage>的属性中指明该消息，业务流程在执行到<pickMessage>时，系统从消息队列读取满足设定条件的消息，且在<pickMessage>的属性中指明该设定条件；所述消息是由业务开发者在书写业务流程脚本时指明、自行定义的一系列字符串组成的集合，相当于确定各个实例之间交互的协议；所述设定条件是由业务开发者在书写业务流程脚本时指明的对字符串的集合内的各个字符串设定的条件，包括是否包含特定的字符串，是否等于特定的字符串；如果消息队列中有满足该设定条件的消息，则成功地从消息队列中提取出该消息，并将该消息放入业务上下文，业务流程继续往下执行，否则，等待满足该设定条件的消息，直到超时后，业务流程走超时的分支；系统规定了所有消息接收者处于等待的最长时间，以保证处于并发状态的业务实例之间不会出现死锁，实现并发操作的安全性。
所述步骤(1)业务描述方法直接从需求的抽象层次上描述业务，由标签指示系统自动完成Web Services操作当从网络侧调用业务侧的Web Services接口时，执行一段由标签组成的业务流程，直到这段业务流程运行结束，完成这次调用并将结果返回给调用者；所述这段业务流程称为业务流程片段，是整个业务流程的一部分或全部，也呈树状结构；在没有网络侧主动调用的情况下，业务逻辑不会自主执行，即由标签组成的整个业务流程是由单个或多个所述的由网络侧发起的Web Services消息触发的业务流程片段拼接而成；在这些业务流程片段的执行过程中，业务流程可以调用网络侧的Web Services接口，调用结束后业务流程继续执行，直到到达当前这个业务流程片段的末尾；网络在发起下一次Web Service调用时，系统将执行该业务片段紧邻的下一个业务流程片段；由标签组成的整个业务流程被划分成各个业务流程片段，取决于不同标签的相应特性，业务开发者用标签描述好业务流程后，系统根据标签特性自动地将整个业务流程划分为各个业务流程片段。
所述XPL业务描述方法对XML标签在原有的标签名称和标签属性两种特征基础上，增添一个新特征，即将所有标签分为三类响应标签、分段标签和普通标签，XPL业务描述方法中的每个标签事先都已设定属于且只属于其中某一类树状业务流程片段的根节点是响应标签，叶节点是分段标签，其他节点是普通标签；除<incoming>外的响应标签是其他业务流程片段的某个分段标签的直接后续节点；业务开发者用标签描述好业务流程后，系统根据其中各个标签的归属类别把业务流程划分为多个业务流程片段；当网络侧向业务侧发起Web Services调用，且该调用是该业务实例生命周期里的首次调用时，系统将会执行以<incoming>为根的业务流程片段，直到执行到该业务流程片段的某个分段标签时，完成对该调用的响应；若网络侧向业务侧发起下一次Web Services调用时，系统将会执行该业务流程片段紧邻连接的下一个业务流程片段，若该分段标签有多个子标签-响应标签，即和该业务流程片段邻接的有多个后续业务流程片段时，系统将在这些后续业务流程片段中间选择一个继续执行，方法是每个响应标签和业务侧的Web Services接口在系统中一一对应，根据网络侧调用的不同接口来触发执行相对应的业务流程片段；按照这种方法，业务在网络侧发起的Web Services调用的触发下，从<incoming>执行到整个业务流程结束。
所述基于上下文构件模型中，每个构件都有设定的可选为空的前置条件键和后置条件键，以便构件在运行前先从上下文中载入前置条件，运行结束后向上下文回写后置条件；所述构件是一个类，必须实现下述四个方法void loadContext()，功能是从上下文中加载前置条件键所对应的信息；boolean willBeTrigered()，功能是判断该标签是否满足运行条件，实现业务流程描述方法的选择操作；void process()，功能是实现该标签的主要业务逻辑；void fillContext()，功能是将标签运行结果写入到上下文中后置条件键所对应的位置。
所述脚本转换-构件粘合算法包括下列操作步骤(1)将脚本文件分拆成多个业务流程片段，每个业务流程片段对应一个Web Services调用函数，用来响应网络侧向业务侧发起的Web Services调用；所述函数名是从脚本树的根到业务片段的根所经过的标签的名称所顺序组成的字符串，系统同时记录业务运行至当前时所经历的标签的节点名称序列，从而实现各个函数被网络顺序调用；(2)对以<subaction>定义的业务流程子树进行如同步骤(1)的类似处理，即<subaction>定义的脚本子树也被设定成一个被业务自身调用的函数，其函数名为<subaction>属性id的值；(3)对前述两个步骤中形成的所有业务流程片段和业务流程子树进行前序遍历，并在遍历过程中把标签对应的构件用“胶水代码”粘合起来，形成与业务片段对应的、用于响应网络侧向业务侧发起的Web Services调用函数或被业务自身调用的函数体内的代码；所述胶水代码是将构件按照上下文模型将各个构件依照业务流程顺序组装起来，将各个独立构件组合成可执行的程序。
所述步骤(2)中，在XPL业务描述方法的当前描述能力不能满足需求时，采用下述操作来增强业务生成系统的能力，以使该业务描述方法具有可扩展性(1)在XPL业务描述方法中增加新的标签，以加强业务流程描述方法的功能，并指明该新增标签属于响应标签、分段标签，普通标签中的哪一类，若是响应标签，需指明对应的Web Services接口；(2)在业务生成系统的构件库中，按照构件模型制作新标签所对应的构件，以便将来由系统的构件组装框架自动完成构件的组装。
所述步骤(2)中构件的实现语言和“胶水代码”所使用的语言没有限制，可以使用C++、或JAVA，或其他语言，转化后的可执行代码在中间件容器中运行，所述中间件容器没有特殊要求，可选用EJB容器、Spring容器、CORBA容器、或其它中间件容器。
所述消息分发器的功能是业务逻辑和网络通过Web Services接口进行交互时，Web Services接口中的各个参数值会和对应的某个具体的业务实例形成关联关系，因此在消息分发器中设有一个描述Web Services接口中的各个参数和业务实例的对应关系表，网络侧调用业务侧的Web Services接口时，查找该接口中参数值所对应的业务实例，即通过无状态的Web Services接口中的参数的值和有状态的业务实例之间建立关联，从而使得网络侧调用业务侧的WebServices接口时系统能够在中间件中众多的业务实例中找到对应的业务实例；当网络侧调用指定的Web Services接口、且按照传入的参数找不到业务实例时，消息分发器将产生一新的业务实例；无论从业务侧调用网络侧的Web Services接口，还是从网络侧调用业务侧的Web Services接口，该调用都将经过消息分发器，并同时按照实际传入的参数值对表中的对应参数进行修改，对WebServices接口中的各个参数和业务实例对应关系表实现动态维护，提高消息分发器的灵活性。
本发明是一种基于Web服务和扩展呼叫处理语言XPL的综合多种电信手段的业务生成系统和业务生成方法，本发明具有下述技术和功能特点
(A)本发明系统除了有较强的语音类业务生成能力外，同时还具有较强的短信、彩信、Email、定位、web应用的后台业务逻辑和数据库操作等数据类业务的生成能力。
(B)本发明提出的XPL业务流程描述方法的实质是提出一套面向特定应用领域的Web Services组合方法，使得整个业务生成系统采用基于服务的架构(SOA)技术，系统开放性好，特别适用于融合网络条件下的业务生成。
(C)本发明提出的XPL业务流程描述方法对业务流程的控制力强，可以进行变量的声明和赋值，具有选择操作、循环操作和并发操作能力，并且能够保证业务流程的安全性，不会出现死循环和死锁。
(D)本发明提出的XPL业务流程描述方法体现了面向特定领域的高度抽象性首先对业务能力的封装上整个业务生成系统通过Web Services接口接入底层的通信能力，如短信、彩信、呼叫，放音，收号，web点击等，这些网络能力都通过特定标签影射在业务流程描述方法中，该业务流程描述方法也提供了组织这些Web Services接口所暴露的业务能力的具体方法。此外，对第三方提供的业务能力，也可以通过增加标签的方式融入到业务流程描述方法中。开发业务的时候，底层的Web Services接口细节对于业务开发者是完全透明的，业务开发者只需要了解标签即可。
业务流程描述方法对Web Services交互协议的映射作用本发明业务流程描述方法基于扩展的XML-XPL，通过XML中的Schema可以对业务流程描述方法进行形式化的定义，Schema规定了分段标签和响应标签之间的对应关系。比如分段标签<proxy>的子标签只能从响应标签<noanswer>、<busy>、<calleeonhook>、<timeout>中选取，表示将当前呼叫转接到指定的被叫方后，下一步只能是被叫无应答、被叫忙、通话结束被叫挂机、或超时状态。若有其它子标签，则脚本不能通过schema检验，将提示出错。即业务流程描述方法的schema包含了Web Serwices接口的交互操作协议。通过业务流程描述方法可以将与Web Services接口的互操作协议相关联的业务逻辑错误检验出来，提高业务生成能力的准确性。
图1是本发明基于Web服务和扩展呼叫处理语言XPL的综合多种通信手段的业务生成系统结构组成示意图。
图2是图1中图形化开发工具的图形化开发界面示意图。
图3是本发明基于Web服务和扩展呼叫处理语言XPL的综合多种通信手段的业务生成方法的操作步骤方框图。
图4是本发明业务流程描述方法中循环操作示意图。
图5是本发明业务生成方法中Web服务事件模型示意图。
图6是使用本发明图形化开发工具开发的第一实施例业务流程图。
图7是使用本发明图形化开发工具开发的第二实施例中描述代理的登陆/注销行为脚本“login.xml”流程图。
图8是使用本发明图形化开发工具开发的第二实施例中描述用户打入电话后的业务行为的流程脚本“service.xml”流程图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。
参见图1，本发明是一种基于XPL的综合多种通信手段的业务生成系统，该系统由应用服务器1(其中设有相互连接的业务开发平台11和业务运行平台12)、Web Services网关2和电信网/因特网所组成；其中业务运行平台11通过Web Services网关2接入电信网/因特网，Web Services网关用于屏蔽电信网和Internet的差异，向该业务生成系统开放底层网络能力；其中业务开发平台11的组成部件包括图形化开发工具、业务生成引擎和构件库。
下面具体介绍这些组件通过提供拖拉式可视化控件来开发业务的图形化开发工具中，每个控件与业务流程描述方法中的一个标签相对应，以便采用图形化方法组织业务流程(参见图2)；与手写的业务流程脚本相比，该业务流程更加简洁、直观。再将图形化的业务流程转换成业务流程脚本文件；也可以人工直接书写业务流程脚本文件，以取代图形化开发工具。不管是图形化开发还是手工书写，所描述的业务流程脚本文件都交给业务生成引擎，以检查是否满足业务流程描述方法的要求。
业务生成引擎，用于接收业务流程脚本文件，并按照业务流程描述方法检查脚本文件，如果发现不符合业务流程描述方法，则报错并中断后续操作；如果脚本文件符合业务流程描述方法的要求，则采用基于构件的软件复用方法；也就是说业务脚本中的标签是需求的描述单元，对应的功能实现单元是构件，在转化过程中业务生成引擎把业务脚本中的描述单元所对应的构件按照业务脚本所描述的流程组装起来，并转化为可执行代码，再将该可执行代码送至中间件容器中运行。
构件库，用于业务生成引擎将业务脚本转换为可执行代码时，从该构件库中选择加载所需构件，以便把业务脚本中的描述单元所对应的构件按照业务脚本所描述的流程进行组装。
业务运行平台的组成部件包括中间件容器和消息分发器。其中采用已有产品的中间件容器用于提供业务实例的运行环境、并对线程池进行管理而使之具有高可靠性的运行平台；在中间件容器中运行有多个业务实例；消息分发器用于建立网络侧向业务发起的调用和业务实例之间的映射关系，即当网络侧向业务发起一个调用时，由消息分发器来决定是发起一个新的业务实例来响应该调用，还是选择一个对应的、已有的业务实例来响应该调用；并通过Web Service网关接入底层网络的基本通信能力。
参见图3，介绍本发明基于XPL的综合多种通信手段的业务生成方法对互联网工程任务组颁布的呼叫处理语言CPL进行扩展，形成一种既能够描述简单的呼叫转移类业务，又能描述具有顺序执行、选择执行、变量控制、循环控制和并发控制能力的复杂的呼叫类业务和数据类业务的业务描述方法或语言-扩展呼叫处理语言XPL，然后利用该XPL业务描述方法描述呼叫类业务和包括短信、彩信、Email、定位，web应用的后台业务逻辑与数据库操作的数据类业务；再利用业务生成系统和相应的构件模型和构件组装方法，将用XPL业务描述方法描述好的业务转换为可以部署运行的程序，然后，将网络开放的WebServices接口和构件所提供的业务能力组织起来，形成满足需求的业务。本发明业务生成方法的具体操作步骤是(1)根据XPL定义的业务描述方法，业务开发者利用图形化开发工具或手工书写XPL业务流程脚本；(2)由业务生成引擎将XPL业务脚本文件转化为可执行代码采用基于上下文的构件模型和针对该模型的脚本转换-构件粘合算法依照XPL业务脚本产生“胶水代码”，再由“胶水代码”把构件组装起来，形成完整的可部署执行的程序；(3)将可执行代码部署在中间件容器中运行。
现在对上述步骤分别作详细介绍(一)书写业务流程本发明从电信增值业务领域的需求出发，在呼叫处理语言CPL(calling process language)的基础上进行扩展，形成一种不但能够描述简单的呼叫转移类业务，还能描述较复杂的呼叫类业务和数据类业务的扩展的业务流程描述方法或描述语言XPL，业务开发者在开发业务时，必须按照该XPL业务流程描述方法直接从较高的抽象层次描述业务需求。
使用XPL业务流程描述方法编写的业务脚本分成两种描述业务执行流程的业务流程脚本和描述对数据库的操作方法、以供业务流程调用的数据库操作脚本。描述业务流程的每个脚本文件会被指定的包括呼叫、短信、web网页点击或其它触发条件触发执行，触发结果是在中间件容器中产生一个业务实例；数据库操作脚本则是利用现有的数据库操作描述方法来描述对数据库表进行的增加、删除、查找等操作，例如可采用EJB的容器管理的持久实体Bean描述文件中的数据库操作的方法，数据库操作脚本设定数据库的操作方法之后，通过在业务流程脚本中调用之，来实现业务流程中嵌入数据库操作。
以下介绍XPL业务流程描述方法中的业务流程的描述情况XPL业务流程描述方法所描述好的业务流程呈树状结构，树中的每个节点都是一个标签，每个节点的子节点代表业务流程下一步所要采取的操作；如果一个父节点有多个子节点，则选择其中某个满足设定条件的子节点执行业务流程。
XPL业务流程描述方法的标签除了CPL中的标签外，又增设了多个标签；因此XPL业务流程描述方法中的标签包括表示业务流程起始点的<incoming>、定义可复用的业务子流程的<subaction>、从该业务子流程以外的业务流程跳转到<subaction>所定义的子流程的<sub>、在以<subaction>定义的业务子流程中使用而重新进入该子流程的<goto>、使用<sub>和<goto>可以在业务流程的其他地方引用相关的子流程，从而复用该子流程，简化流程描述，用于声明变量的<declare>和定义变量的<assign>；还有设定转接号码的<location>、转接电话的<proxy>、放音标签<runUI>、放音收号标签<runUIandCollectInfo>、发送短信的<sendSMS>、发送短信的<sendMMS>、发送电子邮件的<sendEmail>、取得移动用户当前位置的<getLocation>、完成一个第三方发起的呼叫的<makeCall>，用来调用数据库操作脚本里定义的数据库操作方法的<SQL_Operation>，向消息队列中发送消息<sendMessage>，从消息队列中接收消息<pickMessage>。其中<incoming>标签既用于响应网络上报给应用服务器的呼叫触发事件中，也包括网关上报给应用服务器的短信、web网页点击或其它触发事件来产生业务实例。
业务开发者配合使用上述各种标签来组织和描述业务流程，完成业务流程的描述。标签除了各自名称外，每个标签还有各自的属性，业务开发者在使用标签时必须填写标签属性，填写方法有两种填写固定值，或填写从业务上下文中提取的特定值；后者是属性值的动态设定方法当业务流程执行到该标签时，系统从当前的业务上下文中提取设定值赋给该属性。
由于使用业务生成系统来开发业务的技术人员通常比较了解业务的需求，但是对具体的开发技术并不是特别精通；而业务生成系统的研制目的是让一个经过简单培训的业务开发技术人员使用该业务生成系统能够比较容易地开发、研制新业务，这样对于业务生成系统来说，一个不可或缺的要求是能够确保所生成的业务的可靠性，不能够出现死循环、死锁现象，否则的话就会对应用服务器造成很大冲击。目前，基于XML的呼叫类业务描述方法解决死循环的方法是只要用户挂机，就结束业务；但是，这只适用于单纯的呼叫类通信业务。因为呼叫类业务有明显的呼叫会话，可以监听用户挂机事件来结束当前的业务，避免死循环对应用服务器的冲击。这种单纯的处理方法并不适用于本发明综合通信业务的生成方法，因为融合的通信手段较多，而且将来会融进更多的通信手段，所以就不能单靠监听用户挂机事件来结束当前业务；这样对于呼叫以外的死循环就无法处理。
本发明业务流程中的循环操作是这样实现的在业务流程中以标签<subaction id＝“”>为根定义一棵脚本子树，表示一段可复用的业务子流程，标签属性id为子树名称，在该脚本子树内使用<goto ref＝“”>重新进入该子流程，标签属性ref为指定的子树名称。此外，本发明在XPL流程描述方法中加入限制，以保证业务的描述层面不会出现死循环。具体的说，电信网络是一个终端(电话、网页等)用户驱动的网络，所以网络侧对业务侧的调用也是用户行为驱动的结果，即调用的生命周期不会超过用户行为的生命周期。如果循环操作是用户行为所控制的话，即当网络侧调用业务侧时才能发生回溯，那么这种回溯就不会一直进行下去，是一种受到用户行为驱动的回溯控制机制。具体实现方法如下XPL业务流程描述方法规定，使用<goto>进行循环操作时，<goto>和属性ref指向的<subaction>之间(即循环体内)至少要有一个分段标签和响应标签构成的组合，在每次循环的执行过程中，业务都必须要等待网络侧的调用，且系统规定了业务处于等待的最长时间，以保证业务流程中不会出现死循环。
由于业务、网络和用户所构成的系统非常庞大，考虑到异常情况，XPL业务流程描述方法中的所有异步标签都有超时<timeout>子标签，其含义是网络出现异常而没有调用业务接口，或用户长时间无响应、用户行为生命周期已结束，或用户行为和Web Services接口之间的失配，没有为用户的相关行为定义WebServices接口，当出现这三种情况时，业务不会无限时地等待，业务流程会沿着<timeout>的分枝运行。<timeout>也是一种响应标签。
参见图4，分段标签执行完成后，若在非<timeout>子标签的路径上发生回溯，说明用户行为的生命周期还未结束；否则，XPL业务流程描述方法规定<timeout>和<goto>之间至少设有一个分段标签，以保证回溯的发生一定是受用户行为所驱动的。该图中，虚线箭头表示起点到终点之间可能有其它标签，实线箭头表示起点到终点之间没有其它标签。从图中可看到，timeout没有发生时，表明用户在正常使用业务；否则，业务流程一定退出循环(图中走第2个<timeout>)。因此，采用本发明XPL业务流程描述方法描述的业务流程不存在死循环，随用户的退出而最终结束。
本发明XPL业务流程描述方法还提供一种简单、松散的并发操作采用XPL业务流程描述方法书写的每个脚本经过网络触发会形成多个实例，这些业务实例通过共享消息队列通信，完成实例之间的协作，形成并发操作。业务流程在执行到<sendMessage>时，系统将消息放入消息队列，业务流程在执行到<pickMessage>时，系统从消息队列读取消息。其中消息是由业务开发者在书写业务流程脚本时指明、自行定义的一系列字符串组成的集合，相当于确定各个实例之间交互的协议，该消息在<sendMessage>的属性中指明，消息接收者在接受消息时，需指明该消息所需满足的条件，该条件在<pickMessage>的属性中指明，如果消息队列中有满足该条件的消息，则成功接收消息；否则，处于等待状态，直到超时；系统规定了所有消息接收者处于等待的最长时间，以保证处于并发状态的业务实例之间不会出现死锁，实现并发操作的安全性。
本发明使用XPL业务流程描述方法对底层网络所暴露的Web Services接口进行组合，即用XPL业务流程描述方法描述的业务通过Web Services接口和底层网络进行交互，所以该业务流程描述方法可以看成一种专业型Web Services组合方法。该业务流程描述方法直接从需求的较高抽象层次上描述业务，再由标签指示系统自动完成Web Services操作当从网络侧调用业务侧的WebServices接口时，执行一段由标签组成的业务逻辑，直到这段业务流程运行结束，完成这次调用并将结果返回给调用者，这段业务流程称为业务流程片段，是整个业务流程的一部分或者全部，也呈树状结构；在没有网络侧主动调用的情况下，业务逻辑不会自主执行，即由标签组成的整个业务流程是由单个或多个这样的网络侧发起的Web Services消息触发的树状业务流程片段拼接而成，在这些业务流程片段的执行过程中，业务流程可以同步调用网络侧的WebServices接口，调用结束后，业务流程继续执行，直到到达当前这个业务流程片段的末尾。网络在发起下一次Web Service调用时，系统将执行该业务片段紧邻的下一个业务流程片段；由标签组成的整个业务流程被不同的标签划分成各个业务流程片段，取决于不同标签的相应特性，业务开发者用标签描述好业务流程后，系统根据标签特性自动地将整个业务流程划分为各个业务流程片段。
参见图5，业务逻辑什么时候响应完成一次网络向业务侧发起的WebServices调用(图5中以带有粗实线箭头表示网络调用业务的Web Services接口，以带有阴影的空心箭头表示业务调用网络的Web Services接口，带有阴影的矩形方框则表示业务流程片断)，是在XPL业务流程描述方法所介绍的业务流程中明显指出的。XPL业务描述方法的标签分为响应标签(图5中以带有斜纹的圆点表示)、分段标签(图中以带有阴影的圆点表示)，普通标签(图中以空心圆点表示)三类。一个树状的业务流程片段的根节点是响应标签，叶节点是分段标签，其他节点是普通标签。响应标签(除了<incoming>之外)通常是其他业务流程片段的某个分段标签的直接后续节点。图5所示的是一个树状业务流程中实际执行的一条分支和网络侧发生交互的情况。当遇到分段标签时，就会结束当前的这次调用，然后业务等待网络侧向业务侧的下一次调用。下一次调用到达时将会调用紧邻相连接的下一个业务流程片段，该业务流程片段的头部是一个响应标签，且在业务脚本里面是上一个分段标签的子标签。如果上一个分段标签有多个子标签，则这些子标签都是响应标签，且其中每个响应标签都和业务侧的Web Services在系统中一一对应，再根据网络侧调用接口的不同来区分是哪个业务流程片段被触发执行。图中以空心箭头表示业务侧向网络侧发起的Web Services调用。
(二)由业务生成引擎将业务脚本文件转化为可执行代码介绍业务执行引擎的工作原理和工作步骤-如何将写好的XPL业务脚本转化为可执行代码。
众所周知，业务生成技术的实质是某种形式的软件复用技术。XPL业务流程描述方法的标签是需求的描述单元，对应的能力实现单元是构件，因此，基于构件的软件复用是研究和应用的重点。
本发明提供一种基于业务上下文的构件组装框架，其中业务生成系统又定义了一种业务上下文模型来对参与到业务流程中的各个角色进行整合。这些角色主要分为构件和网络，它们会对业务的上下文产生影响。
首先构件按照业务流程顺序被执行，每个构件都会和业务当前的上下文发生交互，先从上下文中加载该构件所需信息，每个构件执行的结果都对上下文造成影响，从而对后续构件的运行造成影响，即业务上下文则作为中介完成构件之间的信息传递。保存整个业务的业务上下文是一张hash表，业务生成系统预先确定了每个构件从该hash表中加载的信息和返回信息时所依据的键值。其次网络和业务之间通过Web Services接口进行交互，网络除了触发业务执行外，还将该业务以外的信息通过Web Services接口的输入参数传递进入业务，也写入上下文，从而影响构件的执行效果；并且业务的运行效果也通过Web Services接口的输出参数反馈给网络。本发明业务生成系统规定每个从网络侧发起的Web Services调用的输入输出参数都是业务上下文hash表的一部分。建立业务上下文模型可以从业务上下文这个同一视角来组织和维护各个角色所需要和所产生的数据信息，方便业务生成系统的运作。
目前，基于接口的构件组装方法很多，许多方法是依靠构件调用其它构件的接口来完成构件的组装，即构件的执行是被其他构件所调用的结果。本发明的构件组装与传统意义上的构件组装的区别在于(1)业务开发者用XPL业务描述方法来描述业务流程，不直接进行构件组装，而由系统完成构件组装，系统在实现构件组装上使用统一的方法来完成；(2)如果沿用基于接口的构件组装模式，则例如顺序执行、选择等流程操作也必须在构件内部实现，这样的构件就比较复杂，最好能将流程控制等共性内容从构件中剥离出去，系统在完成从XPL脚本到可执行代码转化过程中把这些共性内容添加进去。
因此，本发明设计了一套基于上下文的构件模型和针对该模型的XPL脚本转换方法—构件粘合算法，该算法依照业务脚本产生“胶水代码”，用“胶水代码”把各个独立构件粘合在一起，使构件能够按照业务流程依次执行，形成完整的可部署执行的程序。
每个构件都有特定的前置条件键P和后置条件键E(P和E也可为空)。构件在运行前先从上下文中载入前置条件，运行结束后向上下文回写后置条件。构件是一个类，必须实现下述四个方法(此处仅是定性说明)void loadContext()，功能是从上下中加载前置条件键P所对应的信息boolean willBeTrigered()，功能是判断该标签是否满足运行条件，实现业务流程描述方法的选择操作void process()，功能是实现该标签的主要业务逻辑void fillContext()，功能是将标签运行结果写入到上下文中后置条件键E所对应的位置。
本发明的脚本转换—构件粘合算法的具体操作步骤是(1)将XPL脚本文件分拆成多个业务流程片段，每个业务流程片段对应一个Web Services调用函数，用来响应网络侧向业务侧发起的Web Services调用；其中函数名是从脚本树的根到业务片段的根所经过的标签的名称顺序组成的字符串，系统同时计录下业务运行至当前时所经历的标签的节点名称序列，从而实现各个函数被网络顺序调用；(2)对以<subaction>定义的业务流程子树进行和步骤(1)类似的处理，即<subaction>定义的脚本子树也被设定成一个被业务自身调用的函数，其函数名为<subaction>属性id的值；(3)对前述两个步骤中形成的所有业务流程片段和业务流程子树进行前序遍历，并在遍历过程中把标签对应的构件用“胶水代码”粘合起来，形成与业务片段对应的、用于响应网络侧向业务侧发起的Web Services调用函数或被业务自身调用的函数体内的代码；其中胶水代码是将构件按照上下文模型将各个构件依照业务流程顺序组装起来，将各个独立构件组合成可执行的程序。例如下述示意性的伪码所示translationFromTreeToCode(Node node){在中间件构件的调用函数体的末尾插入斜体字符串，以形成函数体中的代码“Component com＝new”+标签node对应的构件类的名称+“()；”//生成该标签对应的构件“com.loadContext()；”//载入该构件的前置条件“if(com.wilBeTrigered(){”//判断前置条件能否触发该构件，如不能，则尝试运行下一个兄弟节点“ret＝com.process()；”//前置条件满足，执行该构件的功能“ret.fillContext()；”//向业务上下文回写该构件的后置条件“recordRunTimeLogicTrace(”+标签的名称+“)；”//记录已经运行过的标签形成的轨迹Node childNode＝getnextChild(node)；//取得node的下一个子节点while(childNode！＝null)translationFromTreeToCode(childNode)；在EJB方法函数体的末尾插入字符串形成函数体中的代码“}”}上述斜体字符串就是在中间件构件的调用函数中形成的“胶水代码”，recordRunTimeLogicTrace为一辅助方法，其作用是配合中间件构件的调用函数名称，系统在响应Event事件的时候，就能正确选择调用业务片段。
本发明这种基于上下文的构件组装机制使得构件本身结构被简化，形式上更规范、整齐，制作也比较容易，有利于扩展新构件。作为一种算法，构件组装方法虽然比纯粹的基于接口的构件组装方法要复杂些，但其对业务开发人员是透明的，且相对稳定，可以多次复用。这种构件复用模型是适用于本发明业务流程描述方法的一种更高抽象层次的构件复用模型。
此外，上述转化方法使得本发明XPL业务流程描述方法具有较强的可扩展性，例如该业务流程描述方法中当前的描述能力不能够满足需求时，可以采用如下操作来增强业务生成系统的能力(1)在XPL业务流程描述方法中增加新的标签，以加强该业务流程描述方法的功能，并指明该新增标签属于响应标签、分段标签，普通标签中的哪一类，若是响应标签，指明对应的Web Services接口；
(2)在业务生成系统的构件库中，按照构件模型制作新标签所对应的构件，将来由系统的构件组装框架自动完成对构件的组装。
这样，本发明的业务生成系统可以随着技术的演进不断扩充，具有较强的扩展性能。
(三)可执行代码的部署运行前述从业务脚本到可执行代码的转化方法是一种构件组装方法，对于构件的实现语言和“胶水代码”所使用的语音都没有限制，可以使用C++、JAVA、或其他语言。转化后的可执行代码运行于中间件容器，同样，对于中间件技术也没有限制，可以根据需要选择EJB容器、Spring容器、CORBA容器、或其它中间件容器，将转化后的可执行代码部署在适用的中间件容器中即可。
由于目前Web Services技术标准对短暂性有状态服务、异步请求/响应、以及和异步触发器通知交互方式支持不足，当从网络侧调用业务侧的Web Services接口时，需要判断当前的这次调用是要发起一个新的业务实例响应该调用，还是在已有的业务实例中选择一个满足条件的来响应该调用。本发明的业务生成方法不强调过强的通用性，而是在所适用的业务需求基础上抽象出对业务实例的控制机制，为业务开发者屏蔽掉这部分工作。业务运行环境采用一种消息分发方式来实现这种机制。
业务逻辑和网络在通过Web Services接口进行交互时，通常Web Services接口中的各个参数值会和某个具体业务实例形成对应的关联关系。比如网页在调用后台的业务逻辑的Web Services接口时，该Web Services接口中需要有一个参数表明该网页的id，类似于网页cookie的概念，该id就和业务实例有一一对应关系。又如当业务逻辑指示网络将当前的呼叫转接到指定号码时，业务实例和该指定的被叫号码就建立了一个对应关系，当网络通过调用业务侧WebServices接口，通知业务逻辑被叫忙、或者无应答等被叫状态时，可以通过WebServices接口中的被叫号码这个参数找到刚才的业务实例。
Web Services接口中的参数在业务被部署的时候，可以根据需要由业务开发者在业务运行平台的消息分发器中进行注册，该参数称为注册参数。在消息分发器中设置一个描述Web Services接口中的所有注册参数和业务实例对应关系的表格。网络侧调用业务侧的Web Services接口时，在该关系表中查找该接口中参数值所对应的业务实例，以便在无状态的Web Services调用和有状态的业务实例之间建立关联；当网络侧调用指定的Web Services接口且按照传入的参数值找不到业务实例时，消息分发器将产生一新的业务实例；无论从业务侧调用网络侧的Web Services接口，还是从网络侧调用业务侧的Web Services接口，都将经过消息分发器，并同时按照实际传入的参数值对表中的对应参数进行修改，对Web Services接口中的各个参数和业务实例对应关系表实现动态维护，提高消息分发器的灵活性。
本发明已经试验实施，并在系统上进行业务生成方法的试验实施，下面简要介绍本发明的两个试验实施例，即使用XPL业务流程描述方法描述业务的范例第一个试验实施例的业务场景是用户从Web页面发起一个点击拨号业务，该业务试图建立主叫和被叫之间的通话，若连接不成功，则分别向主叫和被叫发送一条短信通知；若连接成功，分别向主叫和被叫发送一条彩信名片。下面的XPL脚本描述了该业务服务器侧的业务逻辑。业务中Web页面等部分需要另外手动开发，在此不作说明。为了描述方便，彩信名片图片采用网络上的指定URL。该范例采用完整的XML形式描述，其中标签<makeCall>为分段标签，<incoming>、<fail>、<succeed>为响应标签，其余均为普通标签<！—从Web页面来的触发业务的消息--->
<incoming>
<！—试图建立双方通话，callingparty和calledparty为主、被叫，context中存放incoming消息中网络侧传给业务侧的参数--->
<makeCall callingparty＝”context.callingparty”calledparty＝”context.calledparty”>
<！—建立双方通话失败--->
<fail>
<！—转入名为“failure”的子树--->
<sub ref＝“failure”>
</fail>
<！—建立双方通话成功--->
<succeed>
<！—转入名为“success”的子树--->
<sub ref＝“success”>
</succeed>
</makeCall>
</incoming>
<！—定义名为“failure”的子树--->
<subaction id＝“failure”>
<！—发送短信--->
<sendSMS des＝”context.callingparty”content＝”您有一个未接通的呼叫”>
<sendSMS des＝”context.calledparty”content＝”您有一个未接通的呼叫”>
</sendSMS>
</subaction>
<！—定义名为“success”的子树--->
<subaction id＝“success”>
<！—发送彩信--->
<sendMMS des＝”context.callingparty”content＝”您有一张彩信名片”URL＝“http://*****.jpg”>
<sendMMS des＝”context.calledparty”content＝”您有一张彩信名片”URL＝“http://*****.png”>
</sendSMS>
</subaction>
如果使用本发明系统中的业务图形化开发工具，则上述业务流程的形式就会变得非常简洁和直观(参见图6)，这里就不再赘述。
由于第二个试验实施例的业务流程比较复杂，为了清晰起见，没有采用完整的XPL形式的描述方法，只是给出了业务流程的图形化表述。该业务综合了选择、循环、并发操作，以及短信、彩信、放音收号等较为复杂的业务能力。其业务场景是某公司有多位业务代理，每位业务代理使用手机都可以在任意时间和地点通知业务开始工作，接受客户的电话咨询；如果客户拨打特服号码，业务分配一个代理为他服务。该业务流程脚本分为两个一个是描述代理的登录/注销行为脚本“login.xml”(参见图7)，内容是业务代理使用短消息登录，通知服务器开始工作，或者使用短消息注销，通知服务器退出工作状态。另外一个是描述用户打入电话后的业务行为的流程脚本“service.xml”(参见图8)，主要功能是为用户分配一个空闲的业务代表，并试图建立业务代表和该用户之间的通话，并且在操作过程中配合放音、短信、彩信等操作。业务脚本实例之间通过消息队列协同工作，消息队列数据结构说明Q_Name＝“agent”，S个数为1，数值为代理手机号；Q_Name＝“counting”，S个数为1，数值为固定字符串“counting”，该队列作为计数器表示当前可服务的代理人数；Q_Name＝“user”，S个数为1，数值为客户手机号。
业务流程脚本说明代理发送验证码短信到特服号(参见图7)，若队列agent中已有该代理手机号①，完成注销流程；否则，在数据库中查找对应的验证码进行验证②(简单起见，省略CMP和EJB_QL书写的脚本)。如果查找不成功，就给代理发送短信提示③，如果查找成功，则将代理手机号放入队列agent④，并将当前可服务的代理人数加1⑤，短信提示登陆成功⑥。客户拨打特服号码接入系统(参见图8)，进入user队列排队①，客户是否排第一位②，如果不是第一位，给客户放音③让客户等待；<run_UI>是分段标签，网络上报放音结束事件<ui_End>驱动<goto>进入循环体wait_in_line_1，发生超时<timeout>或用户挂机事件<calleronhook>后，则将该用户从队列user中清除④，并结束业务。如果客户排在第一位，则查看当前是否有可服务的代理⑤，若没有，则放音等待，若有，则将agent中所有代理手机号作为呼转的目标地址⑥，并开始顺呼⑦，并与最先摘机的代理建立连接，代理挂机⑧，将计数器counting加1⑨，给用户发送代理的彩信名片(简单起见，通过URL访问彩信图片)⑩。代理在工作期间可以自由使用手机，不可避免的顺呼⑦有可能不成功，业务会向代理发一条短信指示agent中排第一的代理稍后给用户回电(11)，(12)。
权利要求
1.一种基于XPL的综合多种通信手段的业务生成系统，包括Web Services网关和电信网/因特网；其特征在于所述业务生成系统还包括设有相互连接的业务开发平台和业务运行平台的应用服务器，其中业务运行平台通过WebServices网关接入电信网/因特网，所述Web Services网关用于屏蔽电信网和Internet的差异，向该业务生成系统开放底层网络能力；其中业务开发平台的组成部件包括业务图形化开发工具，用于提供拖拉式可视化控件来开发业务，即采用图形化方法组织业务流程，使业务流程显得简洁、直观，并将图形化的业务流程转换成业务流程脚本文件；所述每个控件对应于业务流程描述方法中的一个标签；所述业务流程脚本文件可以由人工直接书写，以取代图形化开发工具；业务生成引擎，用于接收业务流程脚本文件，并按照业务流程描述方法检查脚本文件，如果发现不符合业务流程描述方法，则报错并中断后续操作；如果脚本文件符合业务流程描述方法的要求，则采用基于构件的软件复用方法，把业务脚本转化为可执行代码，并将该可执行代码送至中间件容器中运行；构件库，用于业务生成引擎将业务脚本转换为可执行代码时，从该构件库中选择加载所需构件，以便把业务脚本中的描述单元所对应的构件按照业务脚本所描述的流程进行组装；所述业务脚本中的标签是需求的描述单元，对应的功能实现单元是构件；其中业务运行平台的组成部件包括中间件容器，用于提供业务实例的运行环境、并对线程池进行管理而使之具有高可靠性的运行平台；在该中间件容器中运行有多个业务实例；消息分发器，用于建立网络侧向业务发起的调用和业务实例之间的映射关系，即当网络侧向业务发起一个调用时，由消息分发器来决定是发起一个新的业务实例来响应该调用，还是选择一个对应的、已有的业务实例来响应该调用；并通过Web Service网关接入底层网络的基本通信能力。
2.一种基于XPL的综合多种通信手段的业务生成方法，其特征在于对互联网工程任务组颁布的呼叫处理语言CPL进行扩展，形成一种既能够描述简单的呼叫转移类业务，又能描述具有顺序执行、选择执行、变量控制、循环控制和并发控制能力的复杂的呼叫类业务和数据类业务的业务描述方法或语言-扩展呼叫处理语言XPL，然后利用该XPL业务描述方法描述呼叫类业务和包括短信、彩信、Email、定位，web应用的后台业务逻辑与数据库操作的数据类业务；再利用所述业务生成系统和相应的构件模型和构件组装方法，将用XPL业务描述方法描述好的业务转换为可以部署运行的程序，即将网络开放的WebServices接口和构件所具有的业务能力组织起来，形成满足需求的业务；所述业务生成方法包括下列操作步骤(1)根据XPL定义的业务描述方法，业务开发者利用图形化开发工具或手工书写XPL业务流程脚本；(2)由业务生成引擎将XPL业务脚本文件转化为可执行代码采用基于上下文的构件模型和针对该模型的脚本转换-构件粘合算法依照XPL业务脚本产生“胶水代码”，再用“胶水代码”把各个独立的构件粘合组装在一起，使构件能够按照业务流程依次执行，形成完整的可部署执行的程序；(3)将可执行代码部署在中间件容器中运行。
3.根据权利要求2所述的业务生成方法，其特征在于所述XPL业务描述方法还具有下述功能变量的声明和定义，保证循环和并发控制的安全，以供业务开发者在开发业务时，按照该XPL业务描述方法描述业务需求，编写出一个或多个业务脚本；使用XPL业务描述方法编写的业务脚本分为两种描述业务执行流程的业务流程脚本和描述对数据库的操作方法、以供业务流程调用的数据库操作脚本，描述业务流程的每个脚本文件会被指定的包括呼叫、短信、web网页点击或其它触发条件触发执行，触发结果是在中间件容器中产生一个业务实例；数据库操作脚本则是利用已有的数据库操作描述方法来描述对数据库表进行的增加、删除、查找或其它操作，包括可采用中间件容器EJB的容器管理的持久实体Bean描述的对数据库操作的方法，数据库操作脚本设定数据库的操作方法以后，通过在业务流程脚本中调用之，来实现在业务流程中嵌入的数据库操作。
4.根据权利要求2所述的业务生成方法，其特征在于所述XPL业务描述方法在呼叫处理语言CPL的标签基础上增添有新标签，该业务描述方法所描述的业务流程呈树状结构，树中的每个节点都是一个标签，每个节点的子节点代表业务流程下一步所要采取的操作；如果一个父节点有多个子节点，则选择其中某个满足设定条件的子节点执行业务流程；增添的新标签包括从以<subaction>定义的业务子流程外的业务流程跳转到<subaction>所定义的子流程的<sub>、在以<subaction>定义的业务子流程中使用而重新进入该子流程的<goto>、用于声明变量的<declare>和定义变量的<assign>、放音标签<runUI>、放音收号标签<runUIandCollectInfo>、发送短信的<sendSMS>、发送彩信的<sendMMS>、发送电子邮件的<sendEmail>、取得移动用户当前位置的<getLocation>、完成一个第三方发起的呼叫的<makeCall>，用来调用数据库操作脚本里定义的数据库操作方法的<SQL_Operation>，向消息队列中发送消息<sendMessage>，从消息队列中接收消息<pickMessage>；其中表示业务流程起始点的标签<incoming>不仅用于响应网络上报给应用服务器的呼叫触发事件，还包括网关上报给应用服务器的短信、web网页点击或其它触发事件，来产生业务实例；业务开发者使用上述标签来组织和描述业务流程；所述标签除了各自名称外，每个标签还有各自的属性，业务开发者在使用标签时要填写标签属性，填写方法有两种填写固定值，或填写从业务上下文中提取的特定值；后者是属性值的动态设定方法当业务流程执行到该标签时，系统从当前的业务上下文中提取设定值赋给该属性。
5.根据权利要求2所述的业务生成方法，其特征在于所述业务流程中的循环操作是这样实现的在业务流程中以标签<subaction id＝“”>为根定义一棵脚本子树，表示一段可复用的业务子流程，标签属性id为子树名称，在该脚本子树内使用<goto ref＝“”>重新进入该子流程，标签属性ref为指定的子树名称；为保证业务流程中不出现死循环，采用接受用户行为驱动的回溯控制机制在使用<goto>进行循环操作时，<goto>和属性ref所指向的<subaction>之间、即循环体内至少设有一个分段标签和响应标签构成的组合，以便在每次循环的执行过程中，业务都必须要等待网络侧的调用，且系统规定了业务处于等待的最长时间，以保证业务流程中不会出现死循环；所述业务流程中的并发控制是这样实现的采用XPL业务描述方法书写的每个脚本经过网络触发后形成多个实例，这些业务实例通过共享消息队列通信，完成实例之间的协作，形成并发操作；业务流程在执行到<sendMessage>时，系统将消息放入消息队列，且在<sendMessage>的属性中指明该消息，业务流程在执行到<pickMessage>时，系统从消息队列读取满足设定条件的消息，且在<pickMessage>的属性中指明该设定条件；所述消息是由业务开发者在书写业务流程脚本时指明、自行定义的一系列字符串组成的集合，相当于确定各个实例之间交互的协议；所述设定条件是由业务开发者在书写业务流程脚本时指明的对字符串的集合内的各个字符串设定的条件，包括是否包含特定的字符串，是否等于特定的字符串；如果消息队列中有满足该设定条件的消息，则成功地从消息队列中提取出该消息，并将该消息放入业务上下文，业务流程继续往下执行，否则，等待满足该设定条件的消息，直到超时后，业务流程走超时的分支；系统规定了所有消息接收者处于等待的最长时间，以保证处于并发状态的业务实例之间不会出现死锁，实现并发操作的安全性。
6.根据权利要求2所述的业务生成方法，其特征在于所述步骤(1)业务描述方法直接从需求的抽象层次上描述业务，由标签指示系统自动完成WebServices操作当从网络侧调用业务侧的Web Services接口时，执行一段由标签组成的业务流程，直到这段业务流程运行结束，完成这次调用并将结果返回给调用者；所述这段业务流程称为业务流程片段，是整个业务流程的一部分或全部，也呈树状结构；在没有网络侧主动调用的情况下，业务逻辑不会自主执行，即由标签组成的整个业务流程是由单个或多个所述的由网络侧发起的WebServices消息触发的业务流程片段拼接而成；在这些业务流程片段的执行过程中，业务流程可以调用网络侧的Web Services接口，调用结束后业务流程继续执行，直到到达当前这个业务流程片段的末尾；网络在发起下一次Web Service调用时，系统将执行该业务片段紧邻的下一个业务流程片段；由标签组成的整个业务流程被划分成各个业务流程片段，取决于不同标签的相应特性，业务开发者用标签描述好业务流程后，系统根据标签特性自动地将整个业务流程划分为各个业务流程片段。
7.根据权利要求6所述的业务生成方法，其特征在于所述XPL业务描述方法对XML标签在原有的标签名称和标签属性两种特征基础上，增添一个新特征，即将所有标签分为三类响应标签、分段标签和普通标签，XPL业务描述方法中的每个标签事先都已设定属于且只属于其中某一类树状业务流程片段的根节点是响应标签，叶节点是分段标签，其他节点是普通标签；除<incoming>外的响应标签是其他业务流程片段的某个分段标签的直接后续节点；业务开发者用标签描述好业务流程后，系统根据其中各个标签的归属类别把业务流程划分为多个业务流程片段；当网络侧向业务侧发起Web Services调用，且该调用是该业务实例生命周期里的首次调用时，系统将会执行以<incoming>为根的业务流程片段，直到执行到该业务流程片段的某个分段标签时，完成对该调用的响应；若网络侧向业务侧发起下一次Web Services调用时，系统将会执行该业务流程片段紧邻连接的下一个业务流程片段，若该分段标签有多个子标签-响应标签，即和该业务流程片段邻接的有多个后续业务流程片段时，系统将在这些后续业务流程片段中间选择一个继续执行，方法是每个响应标签和业务侧的Web Services接口在系统中一一对应，根据网络侧调用的不同接口来触发执行相对应的业务流程片段；按照这种方法，业务在网络侧发起的Web Services调用的触发下，从<incoming>执行到整个业务流程结束。
8.根据权利要求2所述的业务生成方法，其特征在于所述基于上下文构件模型中，每个构件都有设定的可选为空的前置条件键和后置条件键，以便构件在运行前先从上下文中载入前置条件，运行结束后向上下文回写后置条件；所述构件是一个类，必须实现下述四个方法void loadContext()，功能是从上下文中加载前置条件键所对应的信息；boolean willBeTrigered()，功能是判断该标签是否满足运行条件，实现业务流程描述方法的选择操作；void process()，功能是实现该标签的主要业务逻辑；void fillContext()，功能是将标签运行结果写入到上下文中后置条件键所对应的位置。
9.根据权利要求2所述的业务生成方法，其特征在于所述脚本转换-构件粘合算法包括下列操作步骤(1)将脚本文件分拆成多个业务流程片段，每个业务流程片段对应一个Web Services调用函数，用来响应网络侧向业务侧发起的Web Services调用；所述函数名是从脚本树的根到业务片段的根所经过的标签的名称所顺序组成的字符串，系统同时记录业务运行至当前时所经历的标签的节点名称序列，从而实现各个函数被网络顺序调用；(2)对以<subaction>定义的业务流程子树进行如同步骤(1)的类似处理，即<subaction>定义的脚本子树也被设定成一个被业务自身调用的函数，其函数名为<subaction>属性id的值；(3)对前述两个步骤中形成的所有业务流程片段和业务流程子树进行前序遍历，并在遍历过程中把标签对应的构件用“胶水代码”粘合起来，形成与业务片段对应的、用于响应网络侧向业务侧发起的Web Services调用函数或被业务自身调用的函数体内的代码；所述胶水代码是将构件按照上下文模型将各个构件依照业务流程顺序组装起来，将各个独立构件组合成可执行的程序。
10.根据权利要求2或3或4或7或8所述的业务生成方法，其特征在于所述步骤(2)中，在XPL业务描述方法的当前描述能力不能满足需求时，采用下述操作来增强业务生成系统的能力，以使该业务描述方法具有可扩展性(1)在XPL业务描述方法中增加新的标签，以加强业务流程描述方法的功能，并指明该新增标签属于响应标签、分段标签，普通标签中的哪一类，若是响应标签，需指明对应的Web Services接口；(2)在业务生成系统的构件库中，按照构件模型制作新标签所对应的构件，以便将来由系统的构件组装框架自动完成构件的组装。
11.根据权利要求2所述的业务生成方法，其特征在于所述步骤(2)中构件的实现语言和“胶水代码”所使用的语言没有限制，可以使用C++、或JAVA，或其他语言，转化后的可执行代码在中间件容器中运行，所述中间件容器没有特殊要求，可选用EJB容器、Spring容器、CORBA容器、或其它中间件容器。
12.根据权利要求2所述的业务生成方法，其特征在于所述消息分发器的功能是业务逻辑和网络通过Web Services接口进行交互时，Web Services接口中的各个参数值会和对应的某个具体的业务实例形成关联关系，因此在消息分发器中设有一个描述Web Services接口中的各个参数和业务实例的对应关系表，网络侧调用业务侧的Web Services接口时，查找该接口中参数值所对应的业务实例，即通过无状态的Web Services接口中的参数的值和有状态的业务实例之间建立关联，从而使得网络侧调用业务侧的Web Services接口时系统能够在中间件中众多的业务实例中找到对应的业务实例；当网络侧调用指定的Web Services接口、且按照传入的参数找不到业务实例时，消息分发器将产生一新的业务实例；无论从业务侧调用网络侧的Web Services接口，还是从网络侧调用业务侧的Web Services接口，该调用都将经过消息分发器，并同时按照实际传入的参数值对表中的对应参数进行修改，对Web Services接口中的各个参数和业务实例对应关系表实现动态维护，提高消息分发器的灵活性。
全文摘要
一种基于XPL的综合多种通信手段的业务生成方法和系统，系统包括设有业务开发平台和业务运行平台的应用服务器、Web Services网关和电信网/因特网。业务生成方法是对呼叫处理语言CPL进行扩展，形成一种既能描述简单呼叫转移类业务，又能描述复杂呼叫类业务和数据类业务的业务描述方法或语言－XPL，业务开发者用图形化开发工具或手工书写XPL业务脚本，再利用该系统和相应的构件模型与构件组装方法，将XPL脚本转换为可以部署运行的程序，即将网络开放的Web Services接口具有的业务能力组织起来，形成满足需求的业务。本发明是一种在较高抽象层次上融合网络条件下开发综合性通信类业务的方法和系统，业务开发人员使用本发明，能以较快速度开发内容较为丰富的通信类业务。
文档编号G06F9/46GK1972296SQ20061014437
公开日2007年5月30日 申请日期2006年12月5日 优先权日2006年12月5日
发明者孟祥武, 杨骎, 彭泳, 宫云战, 陈俊亮, 于晓燕 申请人:北京邮电大学