专利名称：通用业务系统及其实现方法
技术领域：
本发明涉及通讯系统的增值业务或运营支撑(BSS/OSS)领域，特别是一种通用业务系统以及一种通用业务系统的实现方法。
背景技术：
随着通讯业务的日益发展，产生了一批全新的业务，如短信互动、语音互动、彩信互动等增值业务。业务的多样化和用户需求的多样化需要较短的业务开发周期，并且需要提供灵活的开发手段和开发技术。现有的业务平台基本是基于JAVA2企业版(J2EE)平台或者.NET平台的定制化开发。
当前的业务系统架构如图1所示。图1所示的业务系统包括通讯的接入点(End Points)、通讯基础中间件(Communication Infrastructure)、业务组件(Service Component)、数据访问机制(Data Access Infrastructure)以及数据源(Data Source)。其中，End Point通常也称为客户端程序，可以是短信客户端、WEB客户端、无线应用协议(WAP)客户端，也可以是其他类型的客户端。Communication Infrastructure是指类似JAVA应用(Application)、.NET应用服务器(Application Server)、消息代理(MessageBroker)的消息和组件中间件。Service Component是实现具体业务逻辑的功能单元，如短信问答交互逻辑、话单查询业务逻辑等。Data AccessInfrastructure用于提供统一的访问接口访问各种类型的数据源实现数据的持久化。Data Source为存有各种数据的数据源，包括关系数据库、轻量级目录存取协议(LDAP)数据库以及Web服务(Web Service)等。
在现有的技术中都是采用基于J2EE或者.NET应用服务器的业务框架。这种框架的结构和图1中的技术架构相一致，是上述架构的基于J2EE或者.NET应用服务器的一种实现。在这种架构中，End Points一般采用简单对象访问协议(SOAP)/JAVA消息服务(JMS)等技术实现；CommunicationInfrastructure一般基于企业JAVA构件(EJB)调用、远程方法调用(RMI)、JMS等技术实现；Service Component一般基于EJB实现。
发明人在发明的过程中发现，现有技术虽然可以实现业务系统，但是其中所使用的C#或者JAVA语言都是一种编译执行的语言，当系统中的业务发生变更时，需要重新编译部署，因此，使用C#或者JAVA的开发由于自身需要重新编译部署的特性而导致其相对效率低，导致开发周期较长。并且，调试和测试比较复杂，不支持在线调试、即时修改的功能特性。
发明内容
有鉴于此，本发明实施例提出了一种通用业务系统，用以提高业务系统的开发效率和灵活性。本发明实施例还提出了一种通用业务系统的实现方法。
本发明实施例提供了一种通用业务系统，该系统包括会话控制装置和基于脚本语言的业务执行装置，其中所述会话控制装置用于根据对该会话控制装置的调用创建与所述业务执行装置的会话，并在所创建的会话中发起对所述业务执行装置的调用；所述业务执行装置根据所述会话控制装置的调用执行相应的业务脚本，并向所述会话控制装置返回业务脚本的应答。
本发明实施例还提供了一种通用业务系统的实现方法，该方法包括会话控制装置根据对该会话控制装置的调用创建与基于脚本语言的业务执行装置的会话，并在所创建的会话中发起对业务执行装置的调用；业务执行装置根据会话控制装置的调用执行相应的业务脚本，并向会话控制装置返回业务脚本的应答。
从上述方案中可以看出，本发明实施例中的通用业务系统包括接口适配装置、会话控制装置和基于脚本语言的业务执行装置，由于其中的业务执行装置是基于脚本语言的，在系统中的业务发生变更时无需重新编译，所以与现有的基于C#、JAVA的业务系统相比，使用本发明实施例的系统，可以降低业务开发的难度，提高开发的效率，减少业务开发成本。并且，本发明实施例中的通用业务系统支撑合作开发模式，允许采用合作伙伴进行业务开发，减少对关键技术人员的需求。
图1为现有技术中业务系统的结构示意图；图2为本发明实施例中通用业务系统的结构示意图；图3为本发明实施例中通用业务系统的逻辑结构图；图4为本发明实施例中通用业务系统的结构图；图5为本发明实施例中开户业务的流程示意图；图6为本发明实施例中余额查询业务的流程示意图；图7为本发明实施例中充值缴费业务的流程示意图；图8为本发明实施例中Python嵌入机制的示意图；图9为本发明实施例中Python业务脚本管理机制的示意图；图10为本发明实施例中业务脚本的组织的示意图；图11为本发明实施例中同步调用的流程示意图；图12为本发明实施例中异步调用的流程示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，以下举实施例对本发明进一步详细说明。
图2为本发明实施例中的通用业务系统的框架示意图。与图1中所示结构不同的是，在图2所示的Service Component和Data Access Infrastructure是基于动态脚本描述语言(Python)的。当然，在本发明实施例中，所采用的脚本语言并不局限于Python，也可以是工具命令语言(TCL)、Ruby等，下面具体以Python为例进行说明，显然本发明实施例所要求的保护范围并不局限于此。
图2中的Service Component和Data Access Infrastructure表示通用业务系统基于Python的一种实现，其中包括下面几个特性的增强1)在Service Component中增加对Python脚本的嵌入机制，实现Python脚本的调用，本实施例中基于Python的嵌入机制实现了对业务脚本的调用。在此，将Python脚本称为Python业务脚本。
2)使用基于Python扩展机制实现的Data Access Infrastructure，从而在Python业务脚本中可以直接访问各种类型的数据源。
下面以位于客户关系管理(CRM)系统和在线计费系统(OCS)之间的通用模型映射业务处理子系统中来具体描述本发明实施例的应用。由于CRM和OCS系统的模型之间存在差异，所以需要一个中间系统完成CRM和OCS之间的模型映射。该子系统的主要功能是完成CRM系统和OCS系统的模型映射功能，包括档案同步和实时接口映射。下文中将该系统称为通用模型映射系统(General Model Mapping System，GMMS)。
该系统的逻辑结构如图3所示。参见图3，通用模型映射系统位于CRM与OCS数据库和OCS系统之间，其相当于图2中除了数据源以外的部分。
对于图3中结构，至少可以应用于下面这两个业务场景1)CRM系统档案数据到OCS系统的同步和映射；2)CRM系统和OCS系统的实时接口，例如余额查询、充值缴费等。
应用到这两个业务场景中，通用模型映射系统的结构如图4所示。该系统由接口适配装置、会话控制装置、至少一台业务执行装置等节点组成一个集群。在本实施例中以两台业务执行装置为例进行说明，在实际应用中可以是一台或者两台以上的业务执行装置。
其中，接口适配装置相当于图2中的End Point，会话控制装置相当于图2中的Communication Infrastructure。
业务执行装置2和3主要用于部署业务执行模块和各种业务，并且这些业务都是使用Python脚本完成的，即基于Python的。在业务执行装置2和3中，业务执行模块相当于图2中的Service Component，用于根据请求执行相应的业务模块，而各个业务模块相当于图2中的Data Access Infrastructure，由对应的业务脚本实现，用于完成业务，并在完成业务之后向业务执行模块返回应答，业务执行模块再将应答返回给会话控制装置。
由于业务执行装置是基于脚本语言的，所以与现有的基于C#、JAVA的业务系统相比，使用本发明实施例的系统，可以降低业务开发的难度，提高开发的效率，减少业务开发成本。并且，本发明实施例中的通用模型映射系统支持合作开发模式，允许采用合作伙伴进行业务开发，减少对关键技术人员的需求。另外，由于提高开发效率，降低了开发的周期，所以能够快速相应客户需求，从而提升了客户的满意度。
下面介绍本发明实施例的三种典型的业务流程。
图5所示的是开户业务流程。参照图5，该流程包括以下步骤步骤101，CRM系统发起开户业务请求到GMMS系统的接口适配装置，该开户业务请求可包括用户数据、帐户数据等，其中用户数据例如用户的姓名、移动终端号码等，帐户数据例如帐户的余额、用户定购的业务等内容。
步骤102至步骤103，GMMS系统的接口适配装置完成协议转换、数据转换功能，使用转换后的数据发起到会话控制装置的开户业务调用。具体来说，接口适配装置实现从外部系统各种类型的协议到GMMS系统内部协议转换的过程，在本实施例中，所述外部系统的协议例如XML、二进制编码等，所述GMMS系统内部的协议例如XML消息等。开户业务调用的参数包括但不限于操作类型，本流程为开户；账户数据；用户数据；客户数据；业务定制；支付关系等。
步骤104至步骤105，会话控制装置创建新的会话，并根据负载均衡策略查找空闲的业务执行模块，然后发起到业务执行模块的开户业务调用。开户调用接口的参数包括但不限于开户的操作类型；账户数据；用户数据；客户数据；业务定制；支付关系等。
步骤106至步骤107，业务执行模块根据请求的类型，查找对应的业务脚本，在本流程中为开户业务脚本，并执行该开户业务脚本。
步骤108至步骤109，开户业务脚本负责开户逻辑的处理，主要是指进行从CRM系统到OCS系统的模型映射，另外，开户业务脚本还需要访问OCS数据库记录相应的开户内容，例如帐户数据、用户数据等。
步骤110至步骤113，开户业务脚本完成上述业务逻辑后调用逐层返回。即开户业务脚本将开户的结果返回给业务执行模块，业务执行模块将开户的结果返回给会话控制装置，会话控制装置将开户的结果返回给接口适配装置，接口适配装置进一步进行与步骤102中相逆的协议转换、数据转换后，将开户结果返回给CRM系统。
图6所示的为余额查询流程。参照图6，该流程包括以下步骤步骤201，CRM系统发起余额查询业务请求到GMMS系统的接口适配装置，该余额查询业务请求可包括用户数据等。
步骤202至步骤203，GMMS系统的接口适配装置完成协议转换、数据转换功能，并使用转换后的数据发起到会话控制装置的余额查询业务调用。具体转换与图5中步骤102相似，这里不再赘述。在本实施例中，余额查询调用的参数包括但不限于操作类型，本实施例为余额查询；查询类型，分为用户、客户、账户查询；与查询类型对应的用户ID、客户ID或者账户ID。
步骤204至步骤205，会话控制装置创建新的会话，并根据负载均衡策略查找空闲的业务执行模块，然后发起到业务执行模块的余额查询调用。余额查询调用的参数包括但不限于操作类型，本实施例为余额查询；查询类型，分为用户、客户、账户查询；与查询类型对应的用户ID、客户ID或者账户ID。
步骤206至步骤207，业务执行模块根据请求的类型，查找对应的业务脚本，在本流程中为余额查询脚本，并执行余额查询业务脚本。
步骤208至步骤211，余额查询业务脚本负责余额查询逻辑的处理首先将CRM系统到OCS系统的模型映射，即实现CRM系统的用户ID、客户ID或者账户ID到OCS系统对应用户ID、客户ID或者账户ID的转换，完成请求消息数据的准备；然后发送请求消息到OCS系统，并等待OCS系统的应答；收到应答消息后，把应答消息转换为CRM需要的数据。
步骤212至步骤215，余额查询业务脚本完成上述业务逻辑后调用逐层返回余额查询结果。即开户业务脚本将余额查询结果返回给业务执行模块，业务执行模块将余额查询结果返回给会话控制装置，会话控制装置将余额查询结果返回给接口适配装置，接口适配装置进一步进行与步骤202中相逆的协议转换、数据转换后，将余额查询结果返回给CRM系统。
图7所示为充值缴费流程。参照图7，该流程包括以下步骤步骤301，CRM系统发起充值缴费业务请求到GMMS系统的接口适配装置，该充值缴费业务请求可包括用户数据、帐户数据等。
步骤302至步骤303，GMMS系统的接口适配装置完成协议转换、数据转换功能，并使用转换后的数据发起到会话控制装置的充值缴费调用。具体转换与图5中步骤102相似，这里不再赘述。在本实施例中，充值缴费调用的参数包括但不限于操作类型，本实施例为充值缴费；充值缴费类型，可分为用户、客户充值缴费；与充值缴费类型对应的用户ID、客户ID；充值缴费数额。
步骤304至步骤305，会话控制装置创建新的会话，并根据负载均衡策略查找空闲的业务执行模块，然后发起到业务执行模块的调用。充值缴费调用的参数包括但不限于充值缴费的操作类型；充值缴费类型；与充值缴费类型对应的用户ID、客户ID；充值缴费数额。
步骤306至步骤307，业务执行模块根据请求的类型，查找对应的业务脚本，在本流程中为充值缴费业务脚本，并执行充值缴费业务脚本。
步骤308至步骤311，充值缴费业务脚本负责充值缴费逻辑的处理首先将来自CRM系统的模型映射为OCS系统的模型，即实现CRM系统的用户ID、客户ID到OCS系统对应用户ID、客户ID的转换，完成请求消息数据的准备；然后发送请求消息到OCS系统，并等待OCS系统的应答；收到应答消息后，把应答消息转换为CRM需要的数据。
步骤312至步骤315，充值缴费业务脚本完成上述业务逻辑后，调用逐层返回充值缴费结果。即开户业务脚本将充值缴费结果返回给业务执行模块，业务执行模块将充值缴费结果返回给会话控制装置，会话控制装置将充值缴费结果返回给接口适配装置，接口适配装置进一步进行与步骤302中相逆的协议转换、数据转换后，将充值缴费结果返回给CRM系统。
下面进一步描述本发明实施例中基于Python的Service Component的实现。前面所述的Service Component应用Python嵌入机制的实现如图8所示。
图8所示的Service Component是一个增强的Service Component，包含下面的功能特性1)业务执行机制，根据诸如命令字、版本号等业务的标识，实现到对应的Python业务脚本的调度；2)Python嵌入机制，实现诸如C++、JAVA等语言到Python脚本的调用和数据的传递，数据的传递包括输入参数、输出参数以及返回值。
另外，Python业务脚本和数据调用扩展模块、数据访问扩展模块对应于图4中的开户业务脚本、销户业务脚本、充值缴费业务脚本等。
接着描述本发明实施例中业务脚本的管理。
首先解释一下Python的脚本管理机制，如图9所示，Python采用包(package)、模块(module)的概念管理基本的功能单元。与Java类似，package代表若干个module脚本的集合，每个module脚本使用一个独立的Python脚本文件表示拥有唯一的名称，module可以包含若干个函数(function)或者类(class)以及其他功能元素。
如图10所示，本发明实施例提出了一种基于目录的业务脚本组织方案。
参见图10，${COMPONENT_HOME}/Python为所有业务逻辑脚本的根目录。每个业务逻辑的Python脚本存放在独立的子目录中，该子目录的命名可以使用业务逻辑名称和版本号表示，如图10中的ServiceA100表示ServiceA的业务逻辑脚本，该脚本的版本号为1.00。当然也可以采用其它能够对应业务脚本的命名，本发明实施例并不局限于此。
每个业务逻辑脚本的目录中至少包含下面两个Python脚本文件_init_.py，由于Python本身的语言特性，这是一个空的Python脚本，表示这个目录是一个Python包目录；process.Py，业务处理Python入口脚本，业务执行模块就是调用这个脚本实现任务的执行。
另外，可以将目录名称和分发模块请求消息中的Command Id以及版本号一一对应，这样分发模块可以通过Command Id和版本号唯一找到一个业务逻辑脚本。
在图10中还包括公共Python模块目录(common)，如数据库(DB)模块。每个模块使用一个独立的目录存储，对应到Python的一个package。
根据业务交互的模式，可以将把Python业务组件的调用分为同步调用流程和异步调用流程。同步调用流程是指业务组件和外部的End Points只有一次或者多次交互，和内部的业务组件采用同步调用的方式。异步调用流程是指业务组件和内部的业务组件采用异步调用的方式，支持自动机的处理。
同步调用流程如图11所示，其中虚线表示调用返回。参见图11，同步业务流程主要包括以下步骤步骤401，End Points发起调用。
步骤402至步骤403，ServiceA处理业务，并调用ServiceB处理业务。
步骤404至步骤405，ServiceB进行业务处理，并返回处理的结果，可以采用输出参数或者返回值的方式返回数据。
步骤406至步骤407，ServiceA继续处理业务，并把调用返回处理结果给End Points。
步骤408，End Points调用结束，继续后续的流程处理。
与图11中的同步调用处理不同，异步调用处理流程如图12所示。同样，其中的虚线表示调用返回。参见图12，异步调用处理流程包括以下步骤步骤501，End Points发起调用业务ServiceA，并在调用返回前等待下面步骤502至步骤511的处理。
步骤502至步骤504，ServiceA处理业务，然后发送请求消息到ServieB，并继续完成自己的处理。
步骤505至步骤506，ServiceB收到消息后进行业务处理，并发送应答消息把处理结果返回给A。
接着，重复步骤503～步506的流程，直到业务处理结束。
步骤507，Service A返回处理结果给End Points步骤508，End Point调用返回，继续后续的处理。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种通用业务系统，其特征在于，该系统包括会话控制装置和基于脚本语言的业务执行装置，其中所述会话控制装置用于根据对该会话控制装置的调用创建与所述业务执行装置的会话，并在所创建的会话中发起对所述业务执行装置的调用；所述业务执行装置根据所述会话控制装置的调用执行相应的业务脚本，并向所述会话控制装置返回业务脚本的应答。
2.根据权利要求1所述的通用业务系统，其特征在于，所述通用业务系统进一步包括接口适配装置，所述接口适配装置用于接收业务请求，并发起对所述会话控制装置的调用；所述会话控制装置进一步用于在收到所述业务执行装置的应答后将应答返回给所述接口适配装置。
3.根据权利要求2所述的通用业务系统，其特征在于，所述接口适配装置进一步用于对业务请求进行协议转换和/或数据转换。
4.根据权利要求1所述的通用业务系统，其特征在于，所述业务执行装置进一步用于进行业务请求中数据模型的转换。
5.根据权利要求1所述的通用业务系统，其特征在于，所述业务执行装置包括一个业务执行模块和一个或多个业务脚本，其中所述业务执行模块根据请求执行相应的业务脚本，并将业务脚本的应答返回给会话控制装置；所述业务脚本用于完成所述业务后，并向业务执行模块返回应答。
6.根据权利要求5所述的通用业务系统，其特征在于，所述业务脚本进一步用于进行业务请求中数据模型的转换。
7.根据权利要求1～6中任一项所述的系统，其特征在于，所述脚本语言为动态脚本描述语言Python、工具命令语言TCL或Ruby。
8.一种通用业务系统的实现方法，其特征在于，该方法包括会话控制装置根据对该会话控制装置的调用创建与基于脚本语言的业务执行装置的会话，并在所创建的会话中发起对业务执行装置的调用；业务执行装置根据会话控制装置的调用执行相应的业务脚本，并向会话控制装置返回业务脚本的应答。
9.根据权利要求8所述的方法，其特征在于，在会话控制装置根据对该会话控制装置的调用创建与基于脚本语言的业务执行装置的会话之前，进一步包括接口适配装置接收业务请求，并发起对所述会话控制装置的调用；在业务执行装置向会话控制装置返回业务脚本的应答之后，进一步包括会话控制装置在收到业务执行装置的应答后，将应答返回给接口适配装置。
10.根据权利要求9所述的方法，其特征在于，该方法进一步包括在接口适配装置对业务请求进行协议转换和/或数据转换。
11.根据权利要求8所述的方法，其特征在于，该方法进一步包括在业务执行模块进行业务请求中数据模型的转换。
12.根据权利要求8所述的方法，其特征在于，会话控制装置和业务执行装置之间采用同步调用或者异步调用。
13.根据权利要求8所述的方法，其特征在于，所述业务脚本以基于目录的形式存在，且每个业务脚本对应于一个子目录；所述业务执行装置根据子目录的名称调用相应的业务脚本。
14.根据权利要求8～13中任一项所述的方法，其特征在于，所述脚本语言为Python、TCL或Ruby。
全文摘要
本发明公开了一种通用业务系统，该系统包括会话控制装置和基于脚本语言的业务执行装置，其中所述会话控制装置用于根据对该会话控制装置的调用创建与所述业务执行装置的会话，并在所创建的会话中发起对所述业务执行装置的调用；所述业务执行装置根据所述会话控制装置的调用执行相应的业务脚本，并向所述会话控制装置返回业务脚本的应答。本发明还公开了一种通用业务系统的实现方法。使用本发明的技术方案，可以降低业务开发的难度，提高开发的效率，减少业务开发成本。
文档编号H04W4/12GK101056429SQ20071010667
公开日2007年10月17日 申请日期2007年5月29日 优先权日2007年5月29日
发明者孟庆光 申请人:华为技术有限公司