一种面向位置服务的电信业务生成方法和系统转让专利
申请号 : CN200710062805.9
文献号 : CN100583926C
文献日 : 2010-01-20
发明人 : 孟祥武 , 杨骎 , 彭泳 , 宫云战 , 陈俊亮 , 于晓燕
申请人 : 北京邮电大学
摘要 :
权利要求 :
1、一种基于地理信息类服务描述语言GDL和扩展呼叫处理语言XPL、面 向位置服务的电信业务生成系统,包括电信网络和支持开放位置服务核心业务 OpenLS Core Services的WebGIS服务器;其特征在于:所述系统还包括:设有相互连接的业务开发平台和业务运行平台的应用服务器,其中业务开 发平台包括相互连接的XPL开发环境和GDL开发环境两部分,业务运行平台 包括都基于中间件技术的XPL运行环境和GDL运行环境两部分,XPL运行环 境与电信网络相连,GDL运行环境和支持OpenLS Core Services标准的WebGIS 服务器相连,业务实例在中间件容器中运行,依托中间件对线程池的管理而使 该业务运行环境成为高可靠性的运行平台;
XPL开发环境包括下列部件:
XPL业务脚本存储器,用于存储业务开发者使用XPL编写好的业务流程的 脚本文件;
XPL业务生成引擎,用于接收XPL脚本文件,并按照业务流程描述方法检 查脚本文件,如果发现不符合业务流程描述方法,则报错并中断后续操作;如 果脚本文件符合业务流程描述方法的要求,则把业务脚本转化为可执行代码, 并将该可执行代码送至中间件容器中运行;
GDL开发环境包括下列部件:
GDL业务脚本存储器,用于存储业务开发者使用GDL编写好的业务中有 关地理信息的部分;
GDL业务生成引擎,包括GDL翻译器和GDL构件库,用于将GDL文档 转换为GDL可执行代码;其中GDL翻译器用于接收GDL脚本文件,并按照 GDL定义的描述方法检查该脚本文件,如果发现不符合GDL描述方法,则报 错并中断后续操作;如果脚本文件符合业务流程描述方法的要求,则把业务脚 本转化为可执行代码,并将该可执行代码送至中间件容器中运行;GDL构件库 则用于GDL翻译器将业务脚本转换为可执行代码时,从该构件库中选择加载所 需构件;
所述在XPL运行环境的中间件容器中的业务实例按照XPL业务脚本中所 描述的业务流程顺序执行,在执行过程中,当执行到标签
2、根据权利要求1所述的面向位置服务的电信业务生成系统,其特征在于: 所述支持OpenLS Core Services标准的WebGIS服务器由顺序连接的OpenLS Core Services请求处理器、GIS引擎和GIS数据库所组成,OpenLS Core Services 请求处理器用于接收GDL业务实例传来的OpenLS Core Services请求和使用 GIS引擎接口,以对OpenLS Core Services请求进行处理,GIS引擎的功能是使 用GIS数据库中的地理数据对地理信息进行处理,并提供接口对外开放这些地 理信息的处理能力。
3、根据权利要求1所述的面向位置服务的电信业务生成系统,其特征在于: 所述支持OpenLS Core Services标准的WebGIS服务器能够采用第三方提供的遵 循该标准的分布式服务器,实现网络资源的复用和整合,以节省系统费用。
4、一种基于地理信息类服务描述语言GDL和扩展呼叫处理语言XPL、面 向位置服务的电信业务的生成方法,其特征在于:分别对开放地理联盟颁布的 OpenLS Core Services标准和互联网工程任务组颁布的呼叫处理语言CPL进行 改进和扩展,使得前者成为一种关于地理信息服务数据结构的描述语言或方法 GDL,后者成为一种既能够描述简单的呼叫转移类业务,又能描述复杂的呼叫 类业务和数据类业务的关于电信业务流程的业务描述方法或语言-扩展呼叫处 理语言XPL,再利用该XPL业务描述方法描述呼叫类业务和包括短信、彩信、 定位的数据类业务流程和利用GDL描述地理信息服务的数据结构,然后分别利 用XPL和GDL业务生成引擎将用XPL业务描述方法和GDL数据结构描述的 业务转换为能够部署运行的程序;所述生成方法包括下列操作步骤:(1)根据GDL定义的业务描述方法,业务开发者书写GDL脚本描述 地理服务请求;根据XPL定义的业务描述方法,业务开发者书写XPL业务 流程脚本,并在该脚本中使用标签
(2)由XPL业务生成引擎和GDL业务生成引擎分别将XPL业务脚本 文件和GDL业务脚本文件转化为各自的可执行代码;
(3)将由XPL转化为的可执行代码和由GDL转化为的可执行代码分 别部署在各自的中间件容器中运行;
(4)在受到XPL调用时,GDL可执行代码进行OpenLS Core Services 请求文档的动态生成,该动态生成包括:OpenLS Core Services请求文档结 构的动态确定和OpenLS Core Services请求标签属性值和标签所包含的字符 数据的动态确定;
(5)系统将动态生成的OpenLS Core Services请求发给支持OpenLS Core Services标准的WebGIS服务器,WebGIS服务器将处理结果返回给GDL业务实 例,GDL业务实例再将该结果返回给XPL业务实例,并保存在XPL的业务上 下文中。
5、根据权利要求4所述的方法,其特征在于:所述XPL业务描述方法在 呼叫处理语言CPL的标签基础上增添新标签,增添的新标签包括:放音标签
6、根据权利要求4所述的方法,其特征在于:所述业务上下文是指该业务 实例的运行期状态:首先按照业务流程的顺序执行标签的操作,每个标签都会 和业务当前的上下文发生交互,先从上下文中加载该标签所需信息,每个标签 的执行结果都写入上下文,从而对后续标签的运行造成影响,即业务上下文作 为中介完成标签之间的信息传递;业务上下文的存储结构是一张hash表,业务 生成系统预先确定了每个标签从该hash表中加载的信息和返回信息时所依据的 键值;该hash表用于记录业务运行时的任一时刻该业务实例的运行期状态。
7、根据权利要求4所述的方法,其特征在于:所述步骤(4)GDL可执行 代码进行的OpenLS Core Services请求文档动态生成包括下列操作:先在业务 流程中使用GDL语言对地理信息服务进行模糊描述,即大致描述OpenLS Core Services请求,但不事先确定其中的细节,该模糊描述供XPL描述的业务流程 调用;当调用发生时,由系统根据当时运行的具体情况对该模糊描述进行精确 化处理,即将该模糊描述变成一个具体的、完整的OpenLS Core Services的请 求文档;然后,系统将该请求文档发给支持OpenLS Core Services标准的WebGIS 服务器,这样业务完成一次OpenLS Core Services请求文档的动态生成。
8、根据权利要求7所述的方法,其特征在于:所述OpenLS Core Services 请求文档的动态生成方法有两种:OpenLS Core Services文档结构的动态确定和 OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定。
9、根据权利要求8所述的方法,其特征在于:所述OpenLS Core Services 请求文档结构的动态确定是指在GDL脚本的XML树中含有以生成标签作为叶 子节点时,在系统控制下,每个生成标签将变为一个或多个新增XML子树, 且这些新增XML子树的父标签仍是原生成标签的父节点;如果GDL脚本中的 所有生成标签都被进行这种生成处理后,则处理后的脚本文档的结构符合Core Services的要求;且系统进行生成标签的转换时所依据的转换逻辑存储在该标 签对应的构件里,当XPL运行到调用GDL脚本的标签
10、根据权利要求8所述的方法,其特征在于:所述OpenLS Core Services 标签属性值和标签所包含的字符数据的动态确定是指GDL文档中的标签的属 性值和标签所包含的字符数据事先并不确定,而是指定为传送给GDL业务实例 的业务上下文中的某个键所对应的值,当XPL运行到调用GDL脚本的标签
11、根据权利要求4所述的方法,其特征在于:所述步骤(5)中,系 统将OpenLS Core Services请求的处理结果保存在XPL的上下文,以便XPL 的后续业务流程使用该WebGIS的返回结果和电信网络开展有特色的增值 业务,以及建立业务流程中多个OpenLS Core Services请求的上下文关联, 使得多个OpenLS Core Services请求之间能够互相配合,增强GDL的灵活 性。
说明书 :
技术领域
本发明涉及一种集成地理信息系统和通信系统的新型电信业务生成技术, 确切地说,涉及一种以地理信息服务描述语言GDL和扩展呼叫处理语言XPL 为核心的电信业务生成系统和方法,该业务生成系统和方法能够生成将传统的 语音类与包括短信、彩信、定位等数据类以及地理信息类集成为一体的新型电 信增值业务,且本发明所提供的地理信息服务还能够方便地和使用其他方法开 发的分布式应用相集成。属于电信增值业务或电信和计算机应用技术领域。
背景技术
1、实现跨网业务比较困难:近年来,在IN与Internet业务互通上,相关 研究机构提出了一些解决方案(如IETF的PINT),但从长远观点来看,这些解 决方案不能代表网络技术的发展方向,无法从根本上解决网络融合带来的挑战。
2、IN是个封闭系统:业务生成环境SCE、业务管理系统SMP和业务控制 点SCP之间的关系是绑定的,不同供应商的各个系统之间不能互通。智能网虽 然定义了若干可重复应用的业务独立的功能块SIB,但不同厂商的SIB无法实 现很好的通用,业务开发和提供不能真正独立于智能网平台,更谈不上客户化 定制,因此,业务只能由运营商甚至设备供应商自己来开发。
3、不利于提供多种业务:智能网的封闭结构,使其只适用于支持传统电信 业务,而对多样化业务的支持非常困难;在多网融合的环境下,要想接纳更多 的角色参与到新业务的定义、设计和运营中来,更加困难。所以,很难快速提 供集成多种网络及应用系统的多样化业务。
因此,在多网融合的环境下,非常需要建立一种能够真正吸引网络运营商、 业务运营商、业务开发商和最终用户的业务支撑体系,为参与各方搭建一个能 达到多赢目的的平台。
下面简要介绍目前国内外有关电信业务生成技术的研究概况如下:
在电信领域已经研制成功一些专门用于描述呼叫业务的方法,较有影响的 有:IETF的CPL、W3C的CCXML和JAIN的SCML。这些方法特点是面向特 定需求,语言元素本身就是对业务需求的高度抽象;优点是语言简单、灵活, 开发业务的速度快,对业务开发人员的技术要求低,缺点是描述能力过于有限, 不能描述数据类业务和基于位置的服务LBS(Location-based Services)类业务。
计算机领域也已出现一些用来描述业务流程的方法,影响力较大的有BPEL 等。BPEL是一种通用的流程描述语言,其设计重点是通用性的语言元素,如 对流程的控制、对变量的控制等,这些语言元素的描述能力和JAVA等高级语 言基本属于同一水平。这种通用性语言的优势是适用面广,但是语言复杂,开 发效率较低,对开发人员的技术要求高。
比较前沿的业务生成方法的研究是基于语义网(Semantic Web)技术和利 用人工智能的方法,从用户的需求直接生成新业务。但是,这种方式还停留在 理论研究阶段。
随着下一代网络的迅速发展,业务生成技术的研究已经成为业内技术人员 所关注的焦点。现在,业务生成技术必须解决的问题主要有以下两点:
一、必须设置一种规范的方式来描述业务的需求:也就是要研究设计一种 面向特定领域的描述方式,这样才能最大限度地提高业务的开发效率,真正达 到业务“生成”的目的。随着电信网和互联网的发展,传统的呼叫类业务需求相 对淡化,而数据类业务(如短信、彩信、定位和Web上的电信类业务)方兴 未艾,并在网络融合的背景下凸现出强烈的需求。近年来随着技术的进步,LBS 类业务已被公认为是继短消息后移动增值业务的下一次发展高潮。LBS类业务 是指通过移动终端和移动网络的配合,确定移动用户当时所在的实际地理位置, 从而向用户提供其所需要的与位置相关的服务信息。它是利用用户位置信息进 行增值服务的一种移动通信与导航相融合的服务形式,如果能够发展一种面向 LBS和呼叫、数据类业务相结合的业务描述方法无疑是很有意义和价值的。
虽然面向特定领域的描述方式开发速度快,但是不可避免的缺点是局限性 强。为了在一定程度上弥补这种缺点,尽可能地适应需求的变化,可扩展性应 该是设计面向特定领域的业务描述方式时考虑的重点之一。
二、要设计能够从需求的描述到可执行程序之间实现转化的软件复用技术: 众所周知,所谓业务生成的本质是某种形式的软件复用技术。在软件工程领域, 基于构件的软件复用技术是学术界和产业界都在重点研究的一个热点。近年来 企业界在中间件技术基础上,结合软件复用思想和面向对象方法,成功地发展 出基于构件的软件开发CBSD(Component Based Software Development)技术, 通过规范标准化的运行级构件和依靠中间件提供的基础设施平台,CBSD提供 了一种自底向上、使用标准软件构件构造系统的有效途径,并得到了广泛应用。
发明内容
为了达到上述目的,本发明提供了一种基于地理信息类服务描述语言GDL 和扩展呼叫处理语言XPL、面向位置服务的电信业务生成系统,包括电信网络 和支持开放位置服务核心业务OpenLS Core Services的WebGIS服务器;其特征 在于:所述系统还包括:设有相互连接的业务开发平台和业务运行平台的应用 服务器,其中业务开发平台包括相互连接的XPL开发环境和GDL开发环境两 部分,业务运行平台包括都基于中间件技术的XPL运行环境和GDL运行环境 两部分,XPL运行环境与电信网络相连,GDL运行环境和支持OpenLS Core Services标准的WebGIS服务器相连,业务实例在中间件容器中运行,依托中间 件对线程池的管理而使该业务运行环境成为高可靠性的运行平台;
XPL开发环境包括下列部件:
XPL业务脚本存储器,用于存储业务开发者使用XPL编写好的业务流程的 脚本文件;
XPL业务生成引擎,用于接收XPL脚本文件,并按照业务流程描述方法检 查脚本文件,如果发现不符合业务流程描述方法,则报错并中断后续操作;如 果脚本文件符合业务流程描述方法的要求,则把业务脚本转化为可执行代码, 并将该可执行代码送至中间件容器中运行;
GDL开发环境包括下列部件:
GDL业务脚本存储器,用于存储业务开发者使用GDL编写好的业务中有 关地理信息的部分;
GDL业务生成引擎,包括GDL翻译器和GDL构件库,用于将GDL文档 转换为GDL可执行代码;其中GDL翻译器用于接收GDL脚本文件,并按照 GDL定义的描述方法检查该脚本文件,如果发现不符合GDL描述方法,则报 错并中断后续操作;如果脚本文件符合业务流程描述方法的要求,则把业务脚 本转化为可执行代码,并将该可执行代码送至中间件容器中运行;GDL构件库 则用于GDL翻译器将业务脚本转换为可执行代码时,从该构件库中选择加载所 需构件;
所述在XPL运行环境的中间件容器中的业务实例按照XPL业务脚本中所 描述的业务流程顺序执行,在执行过程中,当执行到标签
所述支持OpenLS Core Services标准的WebGIS服务器由顺序连接的 OpenLS Core Services请求处理器、GIS引擎和GIS数据库所组成,OpenLS Core Services请求处理器用于接收GDL业务实例传来的OpenLS Core Services请求 和使用GIS引擎接口,以对OpenLS Core Services请求进行处理,GIS引擎的 功能是使用GIS数据库中的地理数据对地理信息进行处理,并提供接口对外开 放这些地理信息的处理能力。
所述支持OpenLS Core Services标准的WebGIS服务器可以采用第三方提供 的遵循该标准的分布式服务器,实现网络资源的复用和整合,以节省系统费用。
为了达到上述目的,本发明还提供了一种基于地理信息类服务描述语言 GDL和扩展呼叫处理语言XPL、面向位置服务的电信业务的生成方法,其特征 在于:分别对开放地理联盟颁布的OpenLS Core Services标准和互联网工程任 务组颁布的呼叫处理语言CPL(Calling Process Language)进行改进和扩展,使 得前者成为一种关于地理信息服务数据结构的描述语言或方法GDL,后者成为 一种既能够描述简单的呼叫转移类业务,又能描述复杂的呼叫类业务和数据类 业务的关于电信业务流程的业务描述方法或语言-扩展呼叫处理语言XPL,再 利用该XPL业务描述方法描述呼叫类业务和包括短信、彩信、定位的数据类业 务流程和利用GDL描述地理信息服务的数据结构,然后分别利用XPL和GDL 业务生成引擎将用XPL业务描述方法和GDL数据结构描述好的业务转换为能 够部署运行的程序;所述生成方法包括下列操作步骤:
(1)根据GDL定义的业务描述方法,业务开发者书写GDL脚本描述 地理服务请求;根据XPL定义的业务描述方法,业务开发者书写XPL业务 流程脚本,并在该脚本中使用标签
(2)由XPL业务生成引擎和GDL业务生成引擎分别将XPL业务脚本 文件和GDL业务脚本文件转化为各自的可执行代码;
(3)将由XPL转化为的可执行代码和由GDL转化为的可执行代码分 别部署在各自的中间件容器中运行;
(4)在受到XPL调用时,GDL可执行代码进行OpenLS Core Services 请求文档的动态生成,该动态生成包括:OpenLS Core Services请求文档结 构的动态确定和OpenLS Core Services请求标签属性值和标签所包含的字符 数据的动态确定;
(5)系统将动态生成的OpenLS Core Services请求发给支持OpenLS Core Services标准的WebGIS服务器,WebGIS服务器将处理结果返回给GDL业务实 例,GDL业务实例再将该结果返回给XPL业务实例,并保存在XPL的业务上 下文中。
所述XPL业务描述方法在呼叫处理语言CPL的标签基础上增添新标签, 增添的新标签包括:放音标签
所述业务上下文是指该业务实例的运行期状态:首先按照业务流程的顺序 执行标签的操作,每个标签都会和业务当前的上下文发生交互,先从上下文中 加载该标签所需信息,每个标签的执行结果都写入上下文,从而对后续标签的 运行造成影响,即业务上下文作为中介完成标签之间的信息传递;业务上下文 的存储结构是一张hash表,业务生成系统预先确定了每个标签从该hash表中 加载的信息和返回信息时所依据的键值;该hash表用于记录业务运行时的任一 时刻该业务实例的运行期状态。
所述步骤(4)GDL可执行代码进行的OpenLS Core Services请求文档动态 生成包括下列操作:先在业务流程中使用GDL语言对地理信息服务进行模糊描 述,即大致描述OpenLS Core Services请求,但不事先确定其中的细节,该模 糊描述供XPL描述的业务流程调用;当调用发生时,由系统根据当时运行的具 体情况对该模糊描述进行精确化处理,即将该模糊描述变成一个具体的、完整 的OpenLS Core Services的请求文档;然后,系统将该请求文档发给支持OpenLS Core Services标准的WebGIS服务器,这样业务完成一次OpenLS Core Services 请求文档的动态生成。
所述OpenLS Core Services请求文档的动态生成方法有两种:OpenLS Core Services文档结构的动态确定和OpenLS Core Services标签属性值和标签所包含 的字符数据的动态确定。
所述OpenLS Core Services请求文档结构的动态确定是指在GDL脚本的 XML树中含有以生成标签作为叶子节点时,在系统控制下,每个生成标签将变 为一个或多个新增XML子树,且这些新增XML子树的父标签仍是原生成标签 的父节点;如果GDL脚本中的所有生成标签都被进行这种生成处理后,则处理 后的脚本文档的结构符合Core Services的要求;且系统进行生成标签的转换时 所依据的转换逻辑存储在该标签对应的构件里,当XPL运行到调用GDL脚本 的标签
所述OpenLS Core Services标签属性值和标签所包含的字符数据的动态确 定是指GDL文档中的标签的属性值和标签所包含的字符数据事先并不确定,而 是指定为传送给GDL业务实例的业务上下文中的某个键所对应的值,当XPL 运行到调用GDL脚本的标签
所述步骤(5)中,系统将OpenLS Core Services请求的处理结果保存在 XPL的上下文,以便XPL的后续业务流程使用该WebGIS的返回结果和电信网 络开展有特色的增值业务,以及建立业务流程中多个OpenLS Core Services请 求的上下文关联,使得多个OpenLS Core Services请求之间能够互相配合,增 强GDL的灵活性。
本发明是一种以地理信息服务描述语言GDL和扩展呼叫处理语言XPL为 核心的电信业务生成系统和方法,它是在申请人的发明专利申请《基于XPL的 综合多种通信手段的业务生成方法及其系统》(申请号:200610144373.1)基础 上的进一步创新和拓展,具有下述技术创新的特点:
(A)本发明在IETF的呼叫处理语言CPL的基础上进行扩展,使其不但能 描述较复杂的呼叫类业务,还能够描述短信、彩信等数据类业务。
(B)本发明在OGC颁布的OpenLS Core Services标准的基础上设计提供 一种地理信息服务的描述方法和对应的地理信息类服务的生成系统,该方法基 于XML,具有抽象层次高,简单易用,开发速度快的特点。
(C)本发明提出一种将GDL和XPL进行有机整合的电信业务生成系统和 方法,通过该系统和方法能够快捷地生成基于位置服务的电信增值业务。
(D)本发明提出的以GDL为核心的地理信息类服务的生成方法可以与其 他分布式应用进行整合,即该方法具有较好的通用性和拓展性。
总之,本发明能够生成将传统的语音类与包括短信、彩信、定位等数据类 以及地理信息类集成为一体的新型电信增值业务,且本发明所提供的地理信息 服务还能够方便地和使用其他方法开发的分布式应用相集成,具有很好的推广 应用前景。
附图说明
图2是本发明基于地理信息类服务描述语言GDL和扩展呼叫处理语言 XPL、面向位置服务的电信业务生成方法的操作步骤方框图。
图3是本发明业务流程描述方法中生成节点生成子节点的示意图。
图4是本发明应用服务器中的业务运行环境中的GDL业务实例、XPL 业务实例与WebGIS服务器进行交互实现OpenLS Core Services查询请求文 档的动态生成示意图。
图5是OGC颁布的OpenLS Core Services标准的中有关地图绘制部分的 XML的模式或规范Schema示意图。
图6是本发明对图5所示的OpenLS Core Services标准进行改进而增加的四 个生成标签:
具体实施方式
参见图1,本发明是一种基于GDL和XPL、面向位置服务和综合多种通信 手段的业务生成系统,该系统由应用服务器1(其中设有相互连接的业务开发 平台11和业务运行平台12)、支持开放位置核心服务OpenLS Core Services的 WebGIS服务器2和电信网所组成;其中业务开发平台包括XPL开发环境11A 和GDL开发环境11B两部分,业务运行平台包括相互连接的XPL运行环境12A 和GDL运行环境12B两部分,XPL运行环境12A连接电信网络,GDL运行环 境连接WebGIS服务器。
其中XPL开发环境11A的组成部件包括:XPL业务脚本存储器,用于存 储业务开发者使用XPL编写好的业务流程的脚本文件。XPL业务生成引擎,用 于接收XPL脚本文件,并按照业务流程描述方法检查脚本文件,如果发现不符 合业务流程描述方法,则报错并中断后续操作;如果脚本文件符合业务流程描 述方法的要求,则把业务脚本转化为可执行代码,并将该可执行代码送至XPL 运行环境12A的中间件容器中运行。
GDL开发环境11B的组成部件包括:GDL业务脚本存储器,用于存储业 务开发者使用GDL编写好的业务中有关地理信息部分。GDL业务生成引擎, 用于将GDL文档转换为GDL可执行代码;其中GDL翻译器用于接收GDL脚 本文件,并按照GDL定义的描述方法检查该脚本文件,如果发现不符合GDL 描述方法,则报错并中断后续操作;如果脚本文件符合业务流程描述方法的要 求,则把业务脚本转化为可执行代码,并将该可执行代码送至GDL运行环境 12B的中间件容器中运行。GDL构件库则用于GDL翻译器将业务脚本转换为 可执行代码时,从该构件库中选择加载所需构件。
XPL运行环境12A和GDL运行环境12B都设有用作业务实例的运行环境 的中间件容器,并依托中间件对线程池的管理而使该业务运行环境成为高可靠 性的运行平台。XPL运行环境12A中的业务实例按照XPL业务脚本中的描述 在适当时机(即执行到标签
本发明系统中的WebGIS服务器也可以采用第三方提供的相关设备,至少 要支持OpenLS Core Services标准的该服务器包括OpenLS Core Services请求处 理器,GIS引擎和GIS数据库三部分。OpenLS Core Services请求处理器用来接 收GDL业务实例传来的OpenLS Core Services请求和调用GIS引擎的二次开发 接口,用于完成对GDL业务实例请求的处理。可以采用第三方设备的GIS引 擎的功能是使用GIS数据库中的地理数据对地理信息进行处理,并提供接口对 外开放这些地理信息的处理能力。由于,其他分布式应用也可以如同XPL可执 行代码那样调用GDL运行环境中的GDL业务实例,因此其他的分布式应用也 可以采用GDL语言来描述地理信息业务,从而该业务生成方法和系统所生成的 地理信息服务也能够方便地与使用其他方法开发的分布式应用相集成。
参见图2,介绍本发明基于GDL和XPL、面向位置服务的电信业务的生成 方法:分别对开放地理联盟颁布的OpenLS Core Services标准和互联网工程任 务组颁布的呼叫处理语言CPL进行改进和扩展,使得前者成为一种有关地理信 息服务数据结构的描述语言或方法GDL,后者成为一种既能够描述简单的呼叫 转移类业务,又能描述复杂的呼叫类业务和数据类业务的有关电信业务流程的 业务描述方法或语言XPL,再利用该XPL业务描述方法描述呼叫类业务和包括 短信、彩信、定位的数据类业务流程和利用GDL描述地理信息服务的数据结构, 然后分别利用XPL和GDL业务生成引擎将用XPL业务描述方法和GDL数据 结构描述好的业务转换为可以部署运行的程序。本发明的业务生成方法包括下 列操作步骤:
(1)根据GDL定义的业务描述方法,业务开发者书写GDL脚本描述 地理服务请求;根据XPL定义的业务描述方法,业务开发者书写XPL业务 流程脚本,并在该脚本中使用标签
(2)由XPL业务生成引擎和GDL业务生成引擎分别将XPL业务脚本 文件和GDL业务脚本文件转化为各自的可执行代码;
(3)将由XPL转化为的可执行代码和由GDL转化为的可执行代码分 别部署在各自的中间件容器中运行;
(4)在受到XPL调用时,GDL可执行代码进行OpenLS Core Services 请求文档的动态生成,该动态生成包括:OpenLS Core Services请求文档结 构的动态确定和OpenLS Core Services请求标签属性值和标签所包含的字符 数据的动态确定;
(5)系统将动态生成的OpenLS Core Services请求发给支持OpenLS Core Services标准的WebGIS服务器,WebGIS服务器将处理结果返回给GDL业务实 例,GDL业务实例再将该结果返回给XPL业务实例,并保存在XPL的业务上 下文中。
现在对上述步骤分别作详细介绍:
(1)书写业务流程:本发明从电信增值业务领域的需求出发,在呼叫处理 语言CPL基础上扩展形成一种不但能描述简单的呼叫转移类业务,还能描述较 复杂的呼叫类业务和数据类业务的业务流程描述方法或描述语言XPL,业务开 发者在开发业务时,必须按照该XPL业务流程描述方法直接从较高的抽象层次 描述业务需求。
XPL业务流程描述方法中的业务流程呈树状结构,树中的每个节点都是一 个标签,每个节点的子节点代表业务流程下一步所要采取的操作;如果一个父 节点有多个子节点,则选择其中某个满足设定条件的子节点执行业务流程。XPL 业务流程描述方法中的标签除了CPL里的标签外,又增设了多个标签,增添的 新标签包括:放音标签
业务开发者使用XPL标签来组织和描述业务流程,每个标签除了各自名称 外,还有各自的属性。业务开发者在使用标签时要填写标签属性,填写方法有 两种:填写固定值,或填写从业务上下文中提取的特定值;后者是属性值的动 态设定方法:当业务流程执行到该标签时,系统从当前的业务上下文中提取设 定值赋给该属性。这里的XPL的业务上下文是指该业务实例的运行期状态:首 先标签按照业务流程顺序被执行,每个标签都会和业务当前的上下文发生交互, 先从上下文中加载该标签所需信息,每个标签执行的结果都写入上下文,从而 对后续标签的运行造成影响,即业务上下文则作为中介完成标签之间的信息传 递。业务上下文的存储结构是一张hash表,业务生成系统预先确定了每个标签 从该hash表中加载的信息和返回信息时所依据的键值。该hash表就记录了业 务运行时的任一时刻该业务实例的运行期状态。
XPL是本发明描述业务流程的方法或语言,GDL则是本发明描述地理信息 服务数据结构的方法或语言,它是在对开放地理联盟OGC所颁布的OpenLS Core Services标准的基础上进行改进而形成的面向地理信息服务的描述语言或 方法。
众所周知,OGC颁布了一种用于描述GIS服务的OpenLS Core Services标 准,该标准用于基于位置的五类服务:目录服务、定位、地理编码/逆地理编码、 路径规划,其中每类服务都是一种查询操作,即客户端发出一个XML形式的 查询请求,服务器端返回一个XML形式的应答,OpenLS Core Services标准用 schema规范详细定义了查询请求和应答的具体格式和内容。OpenLS Core Services的特点是抽象层次高,直接面向地理信息服务的描述,屏蔽了GIS引 擎所进行的空间操作和地图数据的细节,易于被人接受、理解。
OpenLS Core Services只是一种静态描述,即OpenLS Core Services描述的 是客户端和WebGIS服务器之间的每次请求/响应的内容,这里的客户端是指业 务生成系统在中间件容器里生成的业务。
因为OpenLS Core Services请求是一种比较复杂的基于XML的数据结构, 而且在执行业务过程中,必须先组装出这种XML请求文档,才能提交给WebGIS 服务器。所以,为了快速生成业务,本发明在业务生成系统中使用专门面向电 信增值业务的XPL语言来描述业务流程。否则,使用普通高级语言组装XML 文档会造成业务描述上的不一致和不协调,不能实现业务的快速生成。因此, 理想的方法是在描述业务时有一种专门的方法用来描述OpenLS Core Services 请求。最简单的做法是业务所需的每个请求都采用事先描述好的Core Services 请求,XPL在运行过程中只需调用指定的请求脚本即可。但是,这种静态方式 存在的问题有两个:1、由于每个Core Services请求都要事先写好,而实际业务 所发出的请求可能千变万化,这样必然造成请求脚本数目的急剧膨胀。2、难以 处理Core Services请求和业务上下文相关联的情况。例如业务先发起一次目录 请求,WebGIS服务器返回一系列的兴趣点POI,然后业务发起一个绘制地图请 求,将以前返回的POI绘制在地图上。由于业务开发者无法知道在业务运行的 过程中可能会返回哪些POI,所以事先无法写出这样的绘制地图请求。
由上述说明可知,本发明面向地理位置业务的生成系统还需要一种描述地 理信息服务的新方法,该方法不但要和XPL的业务描述方式相统一,从而满足 业务生成系统快速开发业务的要求,而且还要有较好的通用性。为此,本发明 采用在OpenLS Core Services基础上定义一种描述地理信息服务的语言GDL, GDL语言也是基于XML,即使用GDL来描述业务需求。其设计思想是提供一 种OpenLS Core Services请求文档的动态生成方法,即业务使用GDL描述出地 理信息服务的模糊描述,该模糊描述要大致描述或勾勒出OpenLS Core Services 请求的概况,但是其中的细节尚不事先确定,该模糊描述供XPL所描述的业务 流程调用。当调用发生时,系统根据当时的运行具体情况再对该模糊描述进行 精确化处理,将该模糊描述变成一个OpenLS Core Services的具体请求,系统 将该明确的请求发给支持OpenLS Core Services标准的WebGIS服务器,业务从 而完成一次动态的OpenLS Core Services请求的生成。
这种OpenLS Core Services文档的动态生成方法的具体设计手段包括两种: 一种是OpenLS Core Services文档结构的动态确定,一种是OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定。
OpenLS Core Services文档结构的动态确定的原理是:Core Services文档是 一种典型的基于XML的树状的语义结构,具有层次化的特征,即子标签是父 标签概念上的延伸或是父标签表达概念的细化(参见图5)。例如在图5中标签