一种面向位置服务的电信业务生成方法和系统

摘要

一种基于GDL和XPL、面向位置服务的电信业务生成系统和方法，系统包括：设有相互连接的业务开发平台(包括XPL和GDL的开发环境)和业务运行平台(包括XPL和GDL的运行环境)的应用服务器，与XPL运行环境连接的电信网络，与GDL运行环境连接、支持OpenLS Core Services标准的WebGIS服务器。业务生成方法是：分别对OpenLS Core Services标准和CPL进行改进和扩展，形成描述地理信息服务数据结构的语言GDL和扩展呼叫处理语言XPL，再利用其分别描述电信业务流程和地理信息服务的数据结构，然后分别利用各自业务生成引擎将结合XPL和GDL两者描述好的业务转换为可以部署运行的程序，快速形成内容丰富、满足需求的通信类业务。

说明书

技术领域

本发明涉及一种集成地理信息系统和通信系统的新型电信业务生成技术，确切地说，涉及一种以地理信息服务描述语言GDL和扩展呼叫处理语言XPL为核心的电信业务生成系统和方法，该业务生成系统和方法能够生成将传统的语音类与包括短信、彩信、定位等数据类以及地理信息类集成为一体的新型电信增值业务，且本发明所提供的地理信息服务还能够方便地和使用其他方法开发的分布式应用相集成。属于电信增值业务或电信和计算机应用技术领域。

背景技术

目前，电信领域的增值业务大多由智能网(IN)来提供。尽管智能网将其提供的增值业务从基础网络中剥离出来，并在以语音业务占主导的时代做出了重大贡献，但是智能网体系结构在当前网络演进和网络融合的大背景下，已经越来越显现出不足之处；主要包括：

1、实现跨网业务比较困难：近年来，在IN与Internrnet业务互通上，相关研究机构提出了一些解决方案(如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、面向位置服务的电信业务生成系统和业务生成方法，本发明较好地解决了现有技术存在的各种缺陷，在较高抽象层次上提出一种描述基于位置的服务LBS的电信增值业务的生成方法和应用于该方法的业务生成系统，使用本发明方法及系统，业务开发人员只要经过简单培训，就能够以较快速度、比较容易地开发出内容较为丰富的通信类业务。

为了达到上述目的，本发明提供了一种基于地理信息类服务描述语言GDL和扩展呼叫处理语言XPL、面向位置服务的电信业务生成系统，包括电信网络和支持开放位置服务核心业务OpenLS Core Services的WebGIS服务器；其特征在于：所述系统还包括：设有相互连接的业务开发平台和业务运行平台的应用服务器，其中业务开发平台包括相互连接的XPL开发环境和GDL开发环境两部分，业务运行平台包括都基于中间件技术的XPL运行环境和GDL运行环境两部分，XPL运行环境与电信网络相连，GDL运行环境和支持OpenLS CoreServices标准的WebGIS服务器相连，业务实例在中间件容器中运行，依托中间件对线程池的管理而使该业务运行环境成为高可靠性的运行平台；

XPL开发环境包括下列部件：

XPL业务脚本存储器，用于存储业务开发者使用XPL编写好的业务流程的脚本文件；

XPL业务生成引擎，用于接收XPL脚本文件，并按照业务流程描述方法检查脚本文件，如果发现不符合业务流程描述方法，则报错并中断后续操作；如果脚本文件符合业务流程描述方法的要求，则把业务脚本转化为可执行代码，并将该可执行代码送至中间件容器中运行；

GDL开发环境包括下列部件：

GDL业务脚本存储器，用于存储业务开发者使用GDL编写好的业务中有关地理信息的部分；

GDL业务生成引擎，包括GDL翻译器和GDL构件库，用于将GDL文档转换为GDL可执行代码；其中GDL翻译器用于接收GDL脚本文件，并按照GDL定义的描述方法检查该脚本文件，如果发现不符合GDL描述方法，则报错并中断后续操作；如果脚本文件符合业务流程描述方法的要求，则把业务脚本转化为可执行代码，并将该可执行代码送至中间件容器中运行；GDL构件库则用于GDL翻译器将业务脚本转换为可执行代码时，从该构件库中选择加载所需构件。

所述在XPL运行环境的中间件容器中的业务实例按照XPL业务脚本中所描述的业务流程顺序执行，在执行过程中，当执行到标签<GDL_Operation>时，按照该标签的属性所指明的GDL脚本名称，调用GDL运行环境中该的GDL脚本所对应的业务实例，XPL业务实例接入电信网络，从而使用电信资源；所述在GDL运行环境的中间件容器中的业务实例连接支持OpenLS Core Services标准的WebGIS服务器，从而使用地理信息资源；且该GDL业务实例也可以向其他的分布式应用开放，使得其它的分布式应用也可以采用GDL描述地理信息服务，实现该系统所生成的地理信息服务和使用其他方法开发的分布式应用相集成。

所述支持OpenLS Core Services标准的WebGIS服务器由顺序连接的OpenLS Core Services请求处理器、GIS引擎和GIS数据库所组成，OpenLS CoreServices请求处理器用于接收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业务流程脚本，并在该脚本中使用标签<GDL_Operation>调用指定的GDL脚本；

(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 CoreServices标准的WebGIS服务器，WebGIS服务器将处理结果返回给GDL业务实例，GDL业务实例再将该结果返回给XPL业务实例，并保存在XPL的业务上下文中。

所述XPL业务描述方法在呼叫处理语言CPL的标签基础上增添新标签，增添的新标签包括：放音标签<runUI>、放音收号标签<runUIandCollectInfo>、发送短信的<sendSMS>、发送彩信的<sendMMS>、发送电子邮件的<sendEmail>、取得移动用户当前位置的<getLocation>、完成一个第三方发起的呼叫的<makeCall>，用来调用指定的GDL业务脚本的<GDL_Operation>；此外，其中表示业务流程起始点的标签<incoming>不仅用于响应网络上报给应用服务器的呼叫触发事件，还包括网关上报给应用服务器的短信、web网页点击或其它触发事件，用来产生业务实例；

所述业务上下文是指该业务实例的运行期状态：首先按照业务流程的顺序执行标签的操作，每个标签都会和业务当前的上下文发生交互，先从上下文中加载该标签所需信息，每个标签的执行结果都写入上下文，从而对后续标签的运行造成影响，即业务上下文作为中介完成标签之间的信息传递；业务上下文的存储结构是一张hash表，业务生成系统预先确定了每个标签从该hash表中加载的信息和返回信息时所依据的键值；该hash表用于记录业务运行时的任一时刻该业务实例的运行期状态。

所述步骤(4)GDL可执行代码进行的OpenLS Core Services请求文档动态生成包括下列操作：先在业务流程中使用GDL语言对地理信息服务进行模糊描述，即大致描述OpenLS Core Services请求，但不事先确定其中的细节，该模糊描述供XPL描述的业务流程调用；当调用发生时，由系统根据当时运行的具体情况对该模糊描述进行精确化处理，即将该模糊描述变成一个具体的、完整的OpenLS Core Services的请求文档；然后，系统将该请求文档发给支持OpenLSCore Services标准的WebGIS服务器，这样业务完成一次OpenLS Core Services请求文档的动态生成。

所述OpenLS Core Services请求文档的动态生成方法有两种：OpenLS CoreServices文档结构的动态确定和OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定。

所述OpenLS Core Services请求文档结构的动态确定是指在GDL脚本的XML树中含有以生成标签作为叶子节点时，在系统控制下，每个生成标签将变为一个或多个新增XML子树，且这些新增XML子树的父标签仍是原生成标签的父节点；如果GDL脚本中的所有生成标签都被进行这种生成处理后，则处理后的脚本文档的结构符合Core Services的要求；且系统进行生成标签的转换时所依据的转换逻辑存储在该标签对应的构件里，当XPL运行到调用GDL脚本的标签<GDL_Operation>时，系统将XPL业务实例的上下文传送给GDL业务实例，GDL业务实例发现当前存在生成标签时，就调用该标签所对应的构件，同时将XPL业务实例的上下文传入该构件，由存储在该构件中的转换逻辑来确定：在传入的上下文影响下最终产生的新增XML子树数量和每个新增XML子树的形状；如果当前的生成标签所对应的构件不能满足需求，则添加新的标签，同时在系统中添加对应的新构件，以满足需求；

所述OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定是指GDL文档中的标签的属性值和标签所包含的字符数据事先并不确定，而是指定为传送给GDL业务实例的业务上下文中的某个键所对应的值，当XPL运行到调用GDL脚本的标签<GDL_Operation>时，系统将该XPL业务实例的上下文传给GDL业务实例，然后从上下文中提取出该键所对应的实际值，完成OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定；这种标签属性值的动态确定的方法使得GDL和XPL能够更好地集成。

所述步骤(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为核心的地理信息类服务的生成方法可以与其他分布式应用进行整合，即该方法具有较好的通用性和拓展性。

总之，本发明能够生成将传统的语音类与包括短信、彩信、定位等数据类以及地理信息类集成为一体的新型电信增值业务，且本发明所提供的地理信息服务还能够方便地和使用其他方法开发的分布式应用相集成，具有很好的推广应用前景。

附图说明

图1是本发明基于地理信息类服务描述语言GDL和扩展呼叫处理语言XPL、面向位置服务的电信业务生成系统结构组成示意图。

图2是本发明基于地理信息类服务描述语言GDL和扩展呼叫处理语言XPL、面向位置服务的电信业务生成方法的操作步骤方框图。

图3是本发明业务流程描述方法中生成节点生成子节点的示意图。

图4是本发明应用服务器中的业务运行环境中的GDL业务实例、XPL业务实例与WebGIS服务器进行交互实现OpenLS Core Services查询请求文档的动态生成示意图。

图5是OGC颁布的OpenLS Core Services标准的中有关地图绘制部分的XML的模式或规范Schema示意图。

图6是本发明对图5所示的OpenLS Core Services标准进行改进而增加的四个生成标签：<Overlay_DC_POIs>、<Overlay_DC_RouteGeometrys>、<Overlay_DC_Positions>、<Overlay_DC_Maps>，用于GDL标准中对地图绘制的定义，这四个新增标签在GDL文档中出现在标签<Overlay>位置上的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

参见图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业务脚本中的描述在适当时机(即执行到标签<GDL_Operation>时)，按照该标签的属性所指明的GDL脚本名称，调用GDL运行环境中该GDL脚本所对应的业务实例后，该XPL业务实例接入电信网络，以使用电信资源。GDL业务实例连接支持OpenLSCore Services标准的WebGIS服务器，以使用地理信息资源。

本发明系统中的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业务流程脚本，并在该脚本中使用标签<GDL_Operation>调用指定的GDL脚本；

(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里的标签外，又增设了多个标签，增添的新标签包括：放音标签<runUI>、放音收号标签<runUIandCollectInfo>、发送短信的<sendSMS>、发送彩信的<sendMMS>、发送电子邮件的<sendEmail>、取得移动用户当前位置的<getLocation>、完成一个第三方发起的呼叫的<makeCall>，用来调用指定的GDL业务脚本的<GDL_Operation>；此外，其中表示业务流程起始点的标签<incoming>不仅用于响应网络上报给应用服务器的呼叫触发事件，还包括网关上报给应用服务器的短信、web网页点击或其它触发事件，来产生业务实例。

业务开发者使用XPL标签来组织和描述业务流程，每个标签除了各自名称外，还有各自的属性。业务开发者在使用标签时要填写标签属性，填写方法有两种：填写固定值，或填写从业务上下文中提取的特定值；后者是属性值的动态设定方法：当业务流程执行到该标签时，系统从当前的业务上下文中提取设定值赋给该属性。这里的XPL的业务上下文是指该业务实例的运行期状态：首先标签按照业务流程顺序被执行，每个标签都会和业务当前的上下文发生交互，先从上下文中加载该标签所需信息，每个标签执行的结果都写入上下文，从而对后续标签的运行造成影响，即业务上下文则作为中介完成标签之间的信息传递。业务上下文的存储结构是一张hash表，业务生成系统预先确定了每个标签从该hash表中加载的信息和返回信息时所依据的键值。该hash表就记录了业务运行时的任一时刻该业务实例的运行期状态。

XPL是本发明描述业务流程的方法或语言，GDL则是本发明描述地理信息服务数据结构的方法或语言，它是在对开放地理联盟OGC所颁布的OpenLSCore Services标准的基础上进行改进而形成的面向地理信息服务的描述语言或方法。

众所周知，OGC颁布了一种用于描述GIS服务的OpenLS Core Services标准，该标准用于基于位置的五类服务：目录服务、定位、地理编码/逆地理编码、路径规划，其中每类服务都是一种查询操作，即客户端发出一个XML形式的查询请求，服务器端返回一个XML形式的应答，OpenLS Core Services标准用schema规范详细定义了查询请求和应答的具体格式和内容。OpenLS CoreServices的特点是抽象层次高，直接面向地理信息服务的描述，屏蔽了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 CoreServices标签属性值和标签所包含的字符数据的动态确定。

OpenLS Core Services文档结构的动态确定的原理是：Core Services文档是一种典型的基于XML的树状的语义结构，具有层次化的特征，即子标签是父标签概念上的延伸或是父标签表达概念的细化(参见图5)。例如在图5中标签<Overlay>表示在地图上叠加一个地图对象，当<POI>、<Geometry>、<Position>、<Map>这4种标签分别作为<Overlay>的子标签的时候，其含义分别是在地图上叠加兴趣点、路径、位置、地图。同理，这4种标签也可以通过各自的子标签来进一步明确各自的含义(为了简化，图5中没有进一步展开说明)。GDL利用了这种层次化特点，业务开发者书写的GDL脚本所构成的Core Services语义树可以缺少某些“枝叶”，仅构成一个模糊的含义，由系统来将这些“枝叶”补全，从而明确成完整的含义。

OpenLS Core Services文档结构的动态确定是指在GDL脚本的XML树中含有一些特殊的叶子标签，称之为生成标签。每个生成标签将在系统的控制下变为一个或多个新增XML子树，新增XML子树的父节点仍是原生成标签的父节点。如果一个GDL脚本中的所有生成标签都被这样处理，那么处理后脚本文档的基本结构符合Core Services的要求。

参见图3，假设在Core Services标准中标签A有若干个子标签B，在CoreServices标准的基础上增加标签A的生成标签C_B(圆圈表示普通标签，带有阴影的圆圈表示生成标签)，增加了生成标签C_B的Core Services标准形成了新的GDL文法。使用GDL描述的原始XML文档的结构如图3(A)所示，则当该文档经动态确定处理后，文档结构变为图3(B)所示，其中标签B1可以有自己的子标签，生成标签C_B只能是叶子标签，节点B2～Bn都是由标签C_B生成的，它们也都可以有自己的子标签。

在业务生成系统中，系统进行标签C_B转换时，所依据的转换逻辑是使用高级语言编写在标签C_B对应的构件里。当XPL运行到调用GDL脚本的标签<GDL_Operation>时，通过<GDL_Operation>的属性值来指明需要调用的GDL脚本。当调用发生的时候，系统将XPL业务实例的上下文传送给GDL业务实例，GDL业务实例发现当前存在生成标签C_B，就调用该生成标签C_B所对应的构件，并进行GDL文档结构的动态确定：在调用的同时将XPL业务实例的上下文传入该构件，由存储在该构件中的转换逻辑来确定在传入的上下文的影响下最终的实际替换效果：产生几个B标签，以及每个B标签的子树的形状和状态。即GDL文档中生成标签所对应的构件在执行时，将会受到XPL运行状态因素的影响，从而达到GDL文档结构的动态确定，使得该功能的使用更加通用、灵活，更好地和XPL集成。如果当前的C_B所对应的构件不能满足需求，则需要添加新的标签，同时在系统中添加对应的新构件来满足需求，即成为一种构件化开发思想的应用。

OpenLS Core Services请求标签属性值和标签所包含的字符数据的动态确定是指：用GDL所书写的文档中的标签的属性值和标签所包含的字符数据事先都不确定，而是设置为传送给GDL业务实例的业务上下文中的某个键所对应的值。当XPL运行到调用GDL脚本的标签<GDL_Operation>时，系统将XPL业务实例的上下文传送给GDL业务实例，然后从上下文中提取出该键所对应的实际数值，完成OpenLS Core Services标签属性值和标签所包含的字符数据的动态确定。这种标签属性值的动态确定方法也实现了使GDL和XPL更好地集成的目的。

参见图4，当系统完成了OpenLS Core Services文档的动态生成，即将采用GDL的原始模糊描述转换为一个OpenLS Core Services的具体查询请求后，将该请求发送给支持OpenLS Core Services的WebGIS服务器，WebGIS服务器再将处理结果返回给GDL业务实例，GDL业务实例又将该结果返回给XPL业务实例，并保存在XPL的业务上下文中。其中OpenLS Core Services查询请求文档的动态生成就是GDL文档经GDL业务生成引擎转变为GDL可执行代码所完成的主要功能。

将OpenLS Core Services请求的查询结果保存在XPL的上下文中的目的是两点：(1)XPL的后续业务流程可以使用WebGIS的返回结果进行多种富有特色的业务，比如在业务在发起一次目录查询请求后，WebGIS服务器返回一系列的兴趣点POI信息，就可以充分利用XPL所具有的电话转接，发送短信等业务能力，将当前的呼叫转接到某个POI的电话上或将某个POI信息以短信方式发送给用户。(2)可以建立业务流程中OpenLS Core Services请求的上下文关联，例如业务在发起一次目录查询请求后，WebGIS服务器返回一系列兴趣点POI信息，然后业务需要发起一个绘制地图请求，将前面返回的POI绘制在地图上。由于在上下文中已经保存了需要绘制的POI，则在描述地图绘制的GDL脚本中就可以通过对文档结构的动态确定方式，将要绘制的POI嵌入到绘制地图的OpenLS Core Services请求中。

现在以地图绘制为例，说明GDL语言中有关地图绘制的定义方法，这里主要以地图绘制为例介绍这种OpenLS Core Services请求文档结构是如何动态确定的，并不介绍GDL的语法细节。

参见图5，该图展示了OGC所颁布的OpenLS Core Services标准的中有关地图绘制部分的XML的模式或规范Schema。在该Schema中标签<Overlay>表示将在基础地图上叠加一个对象，这个对象可以是一个POI、一条路径、一个地点、或另一幅地图。

参见图6，本发明在上述标准中增加四个生成标签：<Overlay_DC_POIs>、<Overlay_DC_RouteGeometrys>、<Overlay_DC_Positions>、<Overlay_DC_Maps>，形成GDL对地图绘制所做的定义，这四个新增标签在GDL文档中出现在标签<Overlay>所能够出现的位置上。其中<Overlay_DC_POIs>的含义是按照传入的业务上下文将其中所有的POI都放在OpenLS Core Services绘制地图的请求中，即业务上下文中有多少个POI，就会有多少个新增的以POI为子节点的<Overlay>来生成标签<Overlay_DC_POIs>。其他3个标签的含义类似。这只是目前的GDL的定义，如果在实际使用中有新的需求，则增加新的替换标签和对应的构件即可。

下面以目录服务为例，说明GDL语言对于目录查询服务的定义方法。这里主要以一个GDL描述的目录查询服务为例，介绍这种OpenLS CoreServices请求文档标签属性和标签所包含的字符数据的动态确定方法，并不介绍GDL的语法细节。

下面是一个用GDL书写的请求文档实例，为了说明简单，在这个实例中只包含标签属性和标签所包含的字符数据的动态确定，不包括实际应用中的OpenLS Core Services请求文档结构的动态确定。该请求文档的含义是查找距离设定位置指定距离之内的中国餐馆，文档中的标签<gml:pos>内的字符数据表示设定位置的经纬度，这里使用动态确定方法，所设定的位置是从XPL传入的上下文中提取的，并且这个数值是在XPL操作中通过给手机定位后产生的结果。文档中标签<MaximumDistance>的属性值“value”表示指定的最大距离，这里也使用动态确定的方法，指定的最大距离是从XPL的上下文中提取的数值，并且，该数值是XPL操作中放音收号的结果。如果调用这段GDL请求文档的XPL在调用之前先进行了定位操作和放音收号操作，然后调用了这段GDL文档，那么这个GDL请求文档的实际运行时的含义就是查找距用户当前所在位置指定距离以内的中国餐馆，该指定距离是用户使用电话在提示音的引导下所拨入的键值。

    <DirectoryRequest SortCriteria＝“distance”>//目录请求，结果按距离排序

       <POILocation>

         <WithinDistance>

                  <Position>//位置的说明

                      <Point>

                        <gml:pos>Context.longitude Context.latitude</gml:pos>

                      </Point>

               </Position>

               <MaximumDistance value＝“Context.collectInfoResult”/>

       </WithinDistance>

   </POILocation>

   <POIProperties directoryType＝″Yellow Pages″>//黄页查询

        <POIProperty name＝″NAICS_type″value＝″Restaurant″/>//兴趣点类型

        <POIProperty name＝″NAICS_subType″value＝″Chinese″/>//兴趣点类型

   </POIProperties>

</DirectoryRequest>

由此可见，本发明采用的GDL描述方法提供了一种基于XML的地理信息服务的描述方法，该描述方法的发展来自OGC所颁布的面向LBS的OpenLS Core Services标准，对于地理信息服务的开发人员而言，该方法抽象层次高，屏蔽了地理服务的实现细节，使得GDL适合作为一种面向业务生成的地理信息服务描述语言。

如前所述，本发明的GDL描述方法能够和XPL实现良好的集成，且集成两者后的业务生成系统能够提供一种基于位置服务的电信增值业务的生成方法。此外，GDL业务实例提供给XPL业务实例所调用的接口是传统的分布式接口，没有其它特殊要求，因此其他分布式应用也可以像XPL业务实例那样来调用GDL业务实例，只要这些其他分布式应用提供了类似XPL的上下文保存机制即可。这样做的好处是其他分布式应用也能够和GDL进行集成，利用GDL方便、快捷地开发地理信息服务的优势。

此外，当前可伸缩矢量图SVG作为一种基于XML的图形描述方式在WebGIS领域已经得到了重视和应用。由于目前的XPL不具备处理SVG数据的能力，因此当XPL调用GDL所描述的地图绘制类服务时候，支持OpenLS Core Services的WebGIS服务器只能返回图片形式的地图，如果其他分布式应用具有可伸缩矢量图SVG的处理能力，就可以将支持OpenLSCore Services的WebGIS服务器绘制的地图设置成SVG格式，再将SVG格式的地图返回给该分布式应用，由该分布式应用可利用支持SVG的工具对SVG格式的地图进行编辑操作，方便地在该分布式应用的本地执行该地图的放大、缩小等编辑操作，即不再需要下述繁琐操作：每次改变地图的显示效果时，都要重新调用GDL文档，以便重新生成以图片形式的地图。