CN1610438A - 多管理域开放业务访问结构与接口方法 - Google Patents

Abstract

多管理域开放业务访问结构与接口方法，其多管理域开放业务访问结构总流程为：(1)漫游用户FA首先需要进行异地用户身份验证和注册，(2)如果注册成功则FA再进行业务定制；如果注册不成功，则自动结束FA跨管理域的业务访问，(3)如果业务定制失败，则自动结束漫游用户FA的跨业务管理域的业务访问。如果业务定制成功，则判断FA是否是预付费用户，(4)如果是预付费用户，则检查用户FA可用消费额度，(5)如果FA不是预付费用户，则进行业务访问，(6)用户访问业务完毕后，判断是否要结束业务；(7)如果用户不要结束业务，则返回到第(4)步，“判断用户是否是预付费用户”的处理，继续用户跨管理域的业务访问。

Description

多管理域开放业务访问结构与接口方法

                        技术领域

本发明在不同的网络运营商提供的开放业务访问环境能够互连成为一个完整的开放业务访问环境，构成一个跨越不同城市、不同地区、不同国家的开放业务访问环境；同时也使得基于开放业务访问环境的电信业务用户可以在不同的城市、不同国家实现电信业务漫游，属于电信业务互连、互通的技术领域。

                        背景技术

我们目前采用的电信业务，例如本地电话、移动电话、长途电话、IP电话、800免费电话、300电话卡、96998电话卡、因特网接入、电子邮件、短信等电信业务，都是由某个电信业务供应商(例如中国电信、中国移动、中国网通、中国铁通)提供的。目前的电信业务供应商同时也是电信网络运营商，即这些电信业务供应商同时也建立和运营了各自的电信网络系统，包括光纤传输网络、电话交换网络、电信智能网和IP互联网。这种业务供应商和网络运营商合一的体制使得电信业务成为一种由网络运营商垄断的业务，这就妨碍了电信业务的发展。下一代电信网通过在现有的传输网、电话交换网、智能网和IP互联网上定义一组标准的开放业务访问结构和接口，试图从技术上分离业务供应商与网络运营商。

开放业务主要是指开放现有电信网和互联网提供的网络业务或者网络服务，使得网络应用或者网络用户直接可以提供标准的网络业务或者网络服务的访问接口，使用电信网和互联网的资源。也可以使得网络业务或者网络服务供应商基于这些访问接口，创建和定制增值业务或者增值服务。

传统的互联网和电信网主要关注网络系统之间、网络系统与网络结点之间、或者网络结点之间标准化的开放互连协议，使得网络系统之间、网络结点之间、网络系统与网络结点之间能够互连、互通、互操作。而对于网络系统或者网络结点提供的服务没有任何标准化的约束。这样，就使得传统互联网和电信网能够互连成为一个完整的网络系统，但是，在这个网络系统上的网络服务或者网络业务分别由不同的网络运营商单独提供。这就容易形成由网络运营商垄断经营网络业务或者网络服务的局面，阻碍新型网络业务和网络服务的开发和应用。

开放网络业务或者网络服务，在网络业务或者网络服务层次提供一个开放的竞争平台，这是作为融合传统电信网和互联网的下一代网络的主要特征之一。开放网络业务或者网络服务提供的功能称为“开放业务访问”(通信专业电信技术领域的术语)或者“开放服务访问”(计算机专业网络技术领域的术语)，在英文中都对应同一个英文关键词：“Open Service Access”，(缩写为OSA)。虽然这项技术属于计算机专业与通信专业的交叉学科探讨的一类技术。

目前开放业务访问技术的研究和开发主要涉及到开放业务访问的网络结构、开放业务访问的接口规范、以及开放业务访问的实现技术。

目前标准的开放业务访问结构和接口规范是国际Parlay组织(网站为www.parlay.org)发布的Parlay开放业务访问 规范(版本4.1)。该规范可以在http：//www.parlay.org/specs/index.asp网址中找到。该规范通常称为Parlay/OSA开放业务接口规范，或者简称为Parlay/OSA接口规范。

目前Parlay/OSA接口规范的一个不足之处：没有业务管理域的定义，也没有涉及到多业务管理域环境下的开放业务访问结构以及接口规范的定义。这样，目前的Parlay开放业务访问技术只能应用于单个网络运营商的单个管理域。例如中国移动作为一个移动电信网络运营商，下面还划分了多个管理域，例如江苏移动、浙江移动、福建移动等管理域，而江苏移动可以进一步分为南京移动、无锡移动、苏州移动等管理域，一般用户只在一个管理域注册和申请业务。例如南京移动的用户只需要在南京注册申请移动电话和短信业务，一旦南京用户携带手机出差到苏州，无需在苏州在注册申请移动电话业务，苏州移动只需要通过跨业务管理域的结构和连接方法将该用户身份标识传递到南京移动进行验证，一旦通过身份验证，该用户就可以在苏州使用移动电话业务。而目前Parlay开放业务访问的结构和方法尚无法支持这种跨业务管理域的电信业务漫游功能。

从开放业务访问实现的角度看，开放业务访问必须通过一组开放业务访问服务器实现，而按照Parlay/OSA规范(版本4.1)的定义，这组服务器中至少必须包括一个用于业务管理的框架服务器和一个用于具体提供开放业务访问的业务能力服务器。现有的电信网和互联网还是由其电信网运营商或者互联网运营商实现其开放业务访问，这样，各个电信网运营商或者互联网运营商可以在各自的开放业务访问的框架服务器中接受用户对开放业务的订购，管理这些用户对自己所提供的开放业务的访问权限。但是，作为开放业务的用户，必定会面临在非自己订购业务的开放业务环境下如何使用开放业务的问题。正如目前使用移动电话用户必定会面 临在非自己申请业务电话业务的区域使用移动电话业务的问题一样，开放业务访问必须提供这种跨业务管理域的开放业务访问能力。

由于目前Parlay/OSA接口规范尚没有涉及业务管理域的概念，更没有提供多个业务管理域环境下开放业务访问的结构和接口规范，这样，目前的开放业务访问规范还不是一个可以商业化应用的规范。

引证文件：国际开放业务访问标准的制定机构国际Parlay组织网站上发布的Parlay开放业务访问(OSA)规范4.1。Parlay组织网站：www.parlay.org

                          发明内容

技术问题：本发明的目的是试图解决现有开放业务访问技术规范中缺少的对多管理域的支持，设计一个多管理域开放业务访问结构与接口方法。

技术方案：本发明的多管理域开放业务访问结构与接口方法，其多管理域开放业务访问结构总流程为：

(1)漫游用户FA首先需要进行异地用户身份验证和注册，

(2)如果注册成功则FA再进行业务定制；如果注册不成功，则自动结束FA跨管理域的业务访问，

(3)如果业务定制失败，则自动结束漫游用户FA的跨业务管理域的业务访问。如果业务定制成功，则判断FA是否是预付费用户，

(4)如果是预付费用户，则检查用户FA可用消费额度，并且判断是否额度太小；如果额度太小，则调用业务终止流程，终止该用户业务，如果不是额度太小，则进行业务访问，

(5)如果FA不是预付费用户，则进行业务访问，

(6)用户访问业务完毕后，判断是否要结束业务；如果要结束业务，则调用业务终止流程，终止该用户业务，

(7)如果用户不要结束业务，则返回到第(4)步，“判断用户是否是预付费用户”的处理，继续用户跨管理域的业务访问。

根据FW服务器管理员结构和ISA业务访问 隧道结构，FA访问开放业务的身份验证和注册的基本流程如下：

(1)、FA-FW，申请注册用户，

(2)、FW-FFW，FW判断FA地址标识，向FFW转发注册请求，

(3)、FFW-FW，FFW验证用户身份，返回验证和注册结果给FW，

(4)、FFW-FISA，如果验证通过，FFW将在本地ISA创建该用户对应的远地业务访问实体，

(5)、FFW-FW，如果验证通过，FFW返回该用户在本地ISA的业务调用对象引用，

(6)、FW-FA，FW向FA返回身份验证和注册结果，

(7)、FW-ISA，如果FA身份验证通过，则FW在ISA创建FA对应的业务访问对象，并且将FA的信息存入其中，同时获得该对象的引用，

(8)、FW-FA，如果FA身份验证通过，则FW向FA返回其在ISA中对应的业务访问对象的引用。

框架管理员在跨业务管理域进行身份验证和业务合同签署的处理过程如下：

(1)离线交互各自框架的默认管理员帐户注册信息，

(2)客环境的本地框架服务器FW即本地框架服务器利用默认的框架管理员帐户以及离线协商好的交互方式，向主环境框架服务器FFW(即外地框架服务器)进行默认管理员的身份验证。如果身份验证不通过，则终止跨业务管理域的身份验证，

(3)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW在线创建FW管理员帐户和协商身份验证方法，如果FFW认可创建的帐户和协商的身份验证，则接受该新建的FW管理员帐户，否则FW重新创建和协商，

(4)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW协商跨管理域的业务，

(5)如果主环境FFW同意FW提出的业务合同，则通过F2FF接口类签署业务合同，否则，继续与FW进行跨管理域的业务协商。

根据FW服务器管理员结构和ISA业务访问隧道结构，对于一个漫游到客环境的开放业务用户FA需要通过一定步骤，实现用户注册，该过程的流程如下：

(1)客环境的开放业务应用FA通过F2FA接口发出对于用户身份信息和业务定制信息加密的用户注册请求，

(2)客环境框架管理员判断是否与该漫游用户主环境签署了业务合同。如果没有，再进一步判断是否可以访问到该用户的业务主环境，如果无法查找到该漫游用户的业务主环境，则客环境框架管理员拒绝该漫游用户的注册请求，如果没有签署业务合同，但是可以找到该用户的业务主环境，则客环境框架管理员与该用户业务主环境签署业务合同，如果业务合同签署失败，则客环境框架管理员拒绝用户注册，如果已经存在与漫游用户主环境的业务合同，则客环境框架管理员透明转发用户的注册请求，

(3)主环境框架管理员解密漫游用户注册请求，代理漫游用户调用相应的用户注册服务接口，并且加密用户注册响应，连同用户注册是否成功的结果一起返回给客环境管理员，如果用户在主环境注册成功，则主环境框架功能模块FFW将请求主环境域间业务代理功能模块FISA，

(4)如果漫游用户成功注册，则客环境管理员将加密的用户注册响应报文转发给漫游用户，同时，也在客环境为漫游用户创建一个跨业务管理域的业务代理(ISA)，并将该ISA的引用传递给漫游用户，如果主环境管理员返回注册失败报文，则客环境管理员拒绝漫游用户注册，同时，就加密的用户注册响应报文转发给漫游用户，

(5)漫游用户收到注册响应报文，完成用户的注册请求。

有益效果：本发明增加了Parlay/OSA开放业务接口规范(版本4.1)中有关业务管理域的定义，扩展了不同管理域之间的开放业务访问的接口规范，使得扩展的Parlay/OSA开放业务规范能够真正应用于多业务管理域的商业化环境。

在定义业务管理域以及设计多业务管理域环境下虚拟主环境机制过程中面临主要的困难在于：首先需要确定在不同业务管理域环境下是否还可以利用现有的Parlay/OSA接口规范实现跨业务管理域的业务访问，如果利用现有的Parlay/OSA接口规范就可以实现扩展不同业务管理域的开放业务访问，则说明现有的开放业务访问技术规范已经完备，不需要进一步扩展。我们通过建立形式化的开放业务访问模型，证明现有的开放业务规范不能完成实现跨业务管理域的开放业务访问。这样，就面临第二个困难和第三个困难：如何设计跨业务管理域的虚拟主环境机制？如何在与现有开放业务访问接口规范兼容的情况下，设计跨业务管理域的开放业务访问接口规范？利用原来在网络协议方面研究的积累，通过对Parlay/OSA开放业务规范的研究，以及运用理论模型和仿真实验结合的方法，解决了后两个问题。

                       附图说明

图1是多个开放业务管理域与单一增值业务管理域示意图。

图2是开放业务的VHE结构及其应用模式示意图。

图3是跨业务管理域的开放业务访问结构示意图。

图4是跨管理域的开放业务访问涉及的交互接口示意图。

图5是管理域间业务签署流程图。

图6是漫游用户身份验证与注册流程图。

图7是漫游用户身份验证与注册基本流程图。

图8是漫游用户业务定制基本流程图。

图9是漫游用户业务访问基本流程图。

图10是漫游用户业务终止基本流程图。

图11是用户可用消费额度基本流程图。

图12是图例说明图。

图13漫游用户跨管理域业务访问总流程图。

                      具体实施方式

实际上，对于任何一种开放业务访问，都需要经历三个阶段，第一个阶段是用户注册和业务发现阶段，第二个阶段是业务调用和业务响应阶段，第三个阶段是业务结束和业务计费阶段。对于目前定义的Parlay规范而言，作为局限在一个管理域中的开放业务调用，第一个阶段和第二个阶段都由应用实体(APP)与框架实体(FW)之间交互完成，而第二个阶段由APP与业务能力服务器实体(SCS)交互完成。对于跨业务管理域的业务调用，这三个开放业务访问阶段无法像这种单一业务管理域环境下那样，直接由APP调用FW和APP调用SCS实现。因为，这是对于一个应用，需要涉及两个不同管理域的资源，需要涉及两个框架实体，需要间接调用客环境和主环境中的SCS。

为了实现跨业务管理域的开放业务访问，我们设计了以下两个方面的机制：

(1)定义了两个框架之间的交互接口，设计了应用实体通过客环境框架与主环境框架进行透明用户注册、透明业务发现的机制，以此实现跨业务管理域的开放业务访问的第一和第三阶段。这是的透明表示不需要客环境框架事先存储用户应用实体的信息，也不需要应用实体向客环境提供有关其用户身份、业务定制等方面的个体信息。这样机制既可以实现跨业务管理域的用户注册和业务发现，又可以保证在其他业务管理域不泄露用户有关开放业务的个人信息。

(2)设计了跨业务管理域的业务代理实体(ISA)，以及通过ISA跨越不同业务管理域的业务访问隧道，定义了APP与ISA、ISA与SCS以及FW与ISA的接口，使得ISA可以透明地实现对客环境中SCS和主环境中SCS业务访问的转发，可以通过与FW交互实现对跨业务管理域业务访问的统一计费。

本技术方案可以提供两个功能，其一是不同管理域之间业务协商和业务合同签署功能。其二是漫游用户跨业务管理域访问业务的过程。不同管理域之间业务合同签署的交互流程如图5所示。漫游用户跨业务管理域访问业务总流程如图13所示。

漫游用户跨业务管理域访问业务总流程的说明如下：(1)漫游用户FA首先需要进行异地用户身份验证和注册，这部分流程可见图6和图7。(2)如果注册成功则FA再进行业务定制(这部分流程见图8)；如果注册不成功，则自动结束FA跨管理域的业务访问。(3)如果业务定制失败，则自动结束漫游用户FA的跨业务管理域的业务访问。如果业务定制成功，则判断FA是否是预付费用户。(4)如果是预付费用户，则检查用户FA可用消费额度(见图11)，并且判断是否额度太小。如果额度太小，则调用业务终止流程(见图10)，终止该用户业务。如果不是额度太小，则进行业务访问(见图9)(5)如果FA不是预付费用户，则进行业务访问(见图9)。(6)用户访问业务完毕后，判断是否要结束业务。如果要结束业务，则调用业务终止流程(见图10)，终止该用户业务。(6)如果用户不要结束业务，则返回到第(4)步，“判断用户是否是预付费用户”的处理，继续用户跨管理域的业务访问。

在本技术方案中(1)跨业务管理域的透明用户身份验证和注册机制，其中包括在现有的Parlay业务规范定义的框架服务器中设计了管理员帐户，以及定义了属于不同业务管理域的框架服务器之间的交互接口。(2)基于域间业务代理(ISA)的跨业务管理域的开放业务访问隧道机制，其中包括通过域间业务代理实现业务发现、业务访问、业务计费的机制，以及定义了ISA之间的开放业务访问隧道接口、ISA与Parlay开放业务规范中定义的框架服务器(FW)、客户端应用(APP)、以及业务能力服务器(SCS)之间的接口。

跨管理域开放业务访问的总体结构

以下对开放业务访问体系结构和接口的扩展基于以下几条规则：(1)在不同业务管理域，具有相同的开放业务平台的前提下，虚拟主环境(VHE)业务功能是由开放业务访问(OSA)平台提供的业务代理功能实现的。这里的业务代理是对现在Parlay/OSA定义的框架概念的一种扩展。(2)这种业务代理没有关于完整业务逻辑的描述，仅仅只有业务访问的控制逻辑，这种业务访问控制逻辑是不同业务管理域之间协商确定的。(3)为了简化对问题的讨论，这里只研究单一的增值业务管理域在不同的开放业务管理域平台中的VHE问题。

(1)业务管理域

一个业务管理域是指具有完整的业务登记、业务发布、用户注册、业务定制、业务访问和业务计费功能的一组Parlay/OSA服务器的集合。这组服务器集合中包括了Parlay/OSA业务规范中定义的框架服务器和业务能力服务器。

如果一个开放业务平台中存在多个不同的具有完整业务登记、业务发布、用户注册、业务定制、业务访问和业务计费功能的Parlay/OSA服务器集合，则这种开放业务平台就是一种多业务管理域的开放业务平台。

目前Parlay/OSA业务规范尚不支持跨业务管理域的业务访问，以下将扩展Parlay/OSA业务规范，用于支持跨业务管理域的业务访问。

(2)主环境与客环境

主环境是指用户注册、订购业务、定制业务所在的业务管理域。否则，该业务管理域就是该用户的客环境。

虚拟主环境(VHE)是指用户在客环境还可以像在主环境那样进行用户注册、业务定制和业务调用。

虚拟主环境是通过跨业务管理域的用户注册、业务定制和业务调用功能提供的一个移动业务环境。

对于开放业务平台而言，跨越业务管理域的VHE是针对不同的开放业务管理域，也就是针对不同的网络运营商提供的开放业务访问域。而这里的用户可以是开放业务平台之上的增值业务供应商，也可以是开放业务平台之上增值业务的用户。

(3)主环境业务代理

OSA平台为了支持跨业务管理域的开放业务访问，需要在客环境中构建一个主环境业务调用和执行的环境。这种执行环境仅仅是一种主环境中业务的代理。

只有在不同的开放业务管理域中，才需要引入业务代理的概念，才需要进一步扩展Parlay的业务规范。这种业务代理具有安全可控的特性，能够辅助

增值业务在其他开放业务管理域方便地构建临时的增值业务执行环境，转发对增值业务逻辑的执行。

这种开放业务平台提供的VHE功能，实际上可以屏蔽了增值业务的VHE功能。只要开放业务提供VHE功能，则在单个开放业务管理域上提供的增值业务，就可以在提供VHE的多个相互建立业务访问协议的开放业务管理域之上执行相应的增值业务。这样，可以真正方便增值业务的开发和部署。

这种开放业务平台的VHE结构实际上就是基于开放业务的网络互连形式。这里需要解决的问题是：能否通过第三方业务管理域实现主管理域与客管理域之间的交互？如图2所示，假定用户U及其增值业务A都是在开放业务管理域D1中申请和注册的，则以上问题可以表述为：D3能否通过D2实现与D1的交互，使得U在D3中仍然可以使用自己定购的增值业务A？

这样，就需要增加框架到框架之间的接口类，实现非直接连接的业务管理域的身份验证机制、业务协商转发机制、以及业务合同签署机制。这里也涉及逐级身份验证和访问控制机制的问题。这种不同业务管理域之间的身份验证机制、业务协商控制机制、业务合同签署机制、以及业务访问控制机制是本技术方案的发明点。

扩展的 VHE实体以及与Parlay已经定义的实体的关系如图3所示。扩展VHE定义的实体主要是域间业务代理(英文缩写ISA)，其余都是在Parlay中定义的实体。只是由于涉及到两个不同的业务管理域，并且这里站在客环境角度定义实体。这样，主环境的应用称为外部应用(英文缩写FAPP)，主环境中的框架和业务能力服务器分别称为外部框架(英文缩写FFW)、外部业务能力服务器(英文缩写FSCS)和外部域间业务代理(英文缩写FISA)。客环境中的框架(英文缩写FW)和业务能力服务器(英文缩写SCS)与Parlay业务规范中定义一致。

为了实现跨业务管理域之间的业务发现、业务访问和业务计费，需要建立跨业务管理域之间的业务访问隧道，也就是图3中ISA与FISA之间的业务访问隧道。这里跨业务管理域的业务代理及其跨业务管理域的业务访问 隧道是本技术方案的另一个发明点。

这些实体之间的关系可以表示为框架之间的交互接口F2FF，域间业务代理与外部业务代理服务器之间的交互接口I2FI，外部框架与外部业务代理服务器之间的交互接口FF2FI，外部业务代理服务器与外部业务能力服务器交互接口FI2FS，外部应用与框架之间的交互接口FA2F，框架与域间业务代理之间的交互接口F2I，外部应用与域间业务代理之间的交互接口FA2I，以及客环境中框架与业务能力服务器之间的交互接口F2S。

在定义跨业务管理域的业务访问接口中，主要扩展的是F2FA、F2FF、FA2I、I2F、I2S以及I2FI接口。其中前2类是漫游用户身份验证和注册类接口，后4类是跨业务管理域的业务发现、业务访问和业务计费类接口。

跨管理域用户身份验证及注册的基本处理流程

跨管理域的开放业务访问可以分成以下几个阶段：(1)管理域之间身份验证和签署合同。(2)漫游用户身份验证与注册。(3)漫游用户业务定制。(4)漫游用户业务调用。(5)漫游用户业务终止。另外还包括一个定时检查用户可用消费额度的系统检查。这些阶段涉及的交互接口如图4所示。

在跨业务管理域的身份验证和业务合同签署机制中，首先引入一个管理员帐户的概念。FW原来仅仅是身份验证和访问控制的一个实体，即仅仅是一个接收请求的被动服务实体，而不是一个发起请求的应用实体。如果需要引入虚拟主环境的管理功能，则需要引入一种跨业务管理域的管理实体，这也就是框架的管理员帐户，这样，才能进行FW管理员帐户的身份验证和业务合同的签署操作。

这里框架管理员帐户分成初始默认管理员帐户(相当于UNIX系统中的root帐户)和授权管理员帐户(相当于UNIX系统中的实际使用帐户)。默认管理员帐户是系统预先设置的，默认管理员帐户的安全设置是采用离线安全方式传递的。授权管理员帐户是由默认管理员帐户创建的、实际执行跨业务管理域业务合同签署、业务协商的帐户。

框架管理员在跨业务管理域进行身份验证和业务合同签署的处理过程如图5所示，具体过程说明如下：

(1)离线交互各自框架的默认管理员帐户注册信息。

(2)客环境的本地框架服务器FW(即本地框架服务器)利用默认的框架管理员帐户以及离线协商好的交互方式，向主环境框架服务器FFW(即外地框架服务器)进行默认管理员的身份验证。如果身份验证不通过，则终止跨业务管理域的身份验证。

(3)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW在线创建FW管理员帐户和协商身份验证方法。如果FFW认可创建的帐户和协商的身份验证，则接受该新建的FW管理员帐户。否则FW重新创建和协商。

(4)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW协商跨管理域的业务。

(5)如果主环境FFW同意FW提出的业务合同，则通过F2FF接口类签署业务合同。否则，继续与FW进行跨管理域的业务协商。

根据FW服务器管理员结构和ISA业务访问隧道结构，对于一个漫游到客环境的开放业务用户(即一个开放业务应用)FA需要通过一定步骤，实现用户注册。该过程的流程图如图6所示，具体过程的说明如下。

(1)客环境的开放业务应用FA通过F2FA接口发出对于用户身份信息和业务定制信息加密的用户注册请求。

(2)客环境框架管理员判断是否与该漫游用户主环境签署了业务合同，如果没有，再进一步判断是否可以访问到该用户的业务主环境。如果无法查找到该漫游用户的业务主环境，则客环境框架管理员拒绝该漫游用户的注册请求。如果没有签署业务合同，但是可以找到该用户的业务主环境，则客环境框架管理员与该用户业务主环境签署业务合同。如果业务合同签署失败，则客环境框架管理员拒绝用户注册。如果已经存在与漫游用户主环境的业务合同，则客环境框架管理员透明转发用户的注册请求。

(3)主环境框架管理员解密漫游用户注册请求，代理漫游用户调用相应的用户注册服务接口，并且加密用户注册响应，连同用户注册是否成功的结果一起返回给客环境管理员。如果用户在主环境注册成功，则主环境框架功能模块FFW将请求主环境域间业务代理功能模块FISA为

(4)如果漫游用户成功注册，则客环境管理员将加密的用户注册响应报文转发给漫游用户，同时，也在客环境为漫游用户创建一个跨业务管理域的业务代理(ISA)，并将该ISA的引用传递给漫游用户。如果主环境管理员返回注册失败报文，则客环境管理员拒绝漫游用户注册，同时，就加密的用户注册响应报文转发给漫游用户。

(5)漫游用户收到注册响应报文，完成用户的注册请求。

图6所示漫游用户身份验证与注册的流程过于描述了验证的细节，以下我们将采用反映开放业务访问本质的基本流程描述跨业务管理域的开放业务访问。作为对照，以下将描述一个漫游用户身份验证与注册的基本流程。

根据FW服务器管理员结构和ISA业务访问隧道结构，FA访问开放业务的身份验证和注册的基本流程如图7所示，具体过程说明如下：(1)FA-FW，申请注册用户。(2)FW-FFW，FW判断FA地址标识，向FFW转发注册请求。(3)FFW-FW，FFW验证用户身份，返回验证和注册结果给FW。(4)FFW-FISA，如果验证通过，FFW将在本地ISA创建该用户对应的远地业务访问实体。(5)FFW-FW，如果验证通过，FFW返回该用户在本地ISA的业务调用对象引用。(6)FW-FA，FW向FA返回身份验证和注册结果。(7)FW-ISA，如果FA身份验证通过，则FW在ISA创建FA对应的业务访问对象，并且将FA的信息存入其中，同时获得该对象的引用。(8)FW-FA，如果FA身份验证通过，则FW向FA返回其在ISA中对应的业务访问对象的引用。

为了实现跨业务管理域的业务管理类扩展功能，主要需要扩展两种类型接口，一种是漫游用户与客环境框架之间的接口，另一种是客环境框架与主环境框架之间接口。

漫游用户与客环境框架之间接口主要提供以下功能：(1)漫游用户的身份验证。(2)漫游用户在客环境中注册。其中身份验证过程对于客环境框架服务器是透明的，而用户注册必须向客环境框架服务器提供反映其身份特征的基本信息。

客环境框架与主环境框架之间接口主要提供以下功能：(1)创建实际执行的框架管理员。(2)协商管理域之间的开放业务访问。(3)签署管理域之间的开放业务访问合同。(4)透明地转发漫游用户的身份验证请求和晌应报文。(5)转发漫游用户注册请求和响应报告，并且通告漫游用户注册结果。跨管理域的业务访问的基本处理流程

漫游到客环境的用户，如果通过身份验证之后，则进行访问开放业务接口的业务发现和业务定制的过程如流程图8所示，具体过程说明如下：(1)FA-ISA：FA向ISA发送查询指定业务的请求报告(注：业务特征的描述需要包括标准的业务特征标识、一般的业务功能描述等)。(2)ISA-FW：向本地FW转发业务查询请求报文。(3)ISA-FISA：向用户主环境的ISA转发业务查询请求报文。(4)FISA-FFW：用户主环境ISA向本地FW转发业务查询请求报文。(5)FW-ISA：本地FW向ISA返回可以调用的业务接口。(6)FFW-FISA：用户主环境的FW向本地的ISA返回业务查询的结果。(7)FISA-ISA：用户主环境的ISA向用户漫游到客环境的ISA返回业务查询结果。(8)ISA-FA：用户漫游所在的客环境ISA向漫游用户FA返回所有可以选择的业务，以及相应的计费策略。(9)FA-ISA：漫游用户FA向所在客环境ISA确定选择的业务。(10)根据FA的选择结果，ISA-SCS或ISA-FISA：ISA在SCS创建即将访问的业务对象，同时就FA的业务请求转发给FISA，请求FISA创建相应的业务访问对象。(11)根据FA对业务访问选择的结果，SCS-ISA或者FISA-ISA：返回创建的业务访问对象的引用。(12)ISA-FA：ISA向漫游用户FA返回业务对象的引用。

漫游到客环境用户，一旦选择了业务，并且已经获得了对该类业务对象的引用，则该漫游用户就可以通过该业务访问接口，访问相应的业务。漫游用户访问过程如流程图9所示，具体过程说明如下：(1)FA-ISA：漫游用户利用业务对象的引用，调用相应的业务。(2)根据业务对象引用的URI，确定进一步的交互：ISA-SCS或ISA-FISA，即如果是访问客环境业务，则将业务调用转发给SCS，如果是访问用户主环境业务，则ISA将业务调用转发给FISA。(3)根据FA发出的业务对象引用的URI(全球资源标识，这里假定业务对象全部采用万维网服务中的URI标识)确定下一步交互：SCS-ISA或FISA-ISA，即或者本地SCS返回业务调用的响应，或者FISA返回业务调用的响应。(4)ISA-FA：ISA向FA返回业务调用响应。(5)FA-ISA：漫游用户通知ISA，调用业务成功，结束业务调用；或者业务调用成功，维持这种调用状态；调用业务失败，结束业务调用；调用业务失败，重新选择可用业务。

漫游到客环境用户，一旦完成了业务访问，则需要通过业务代理终止其业务访问，并且进行业务的即时计费。漫游用户终止其业务的流程图如图10所示，其主要过程说明如下：(1)FA-ISA：漫游用户FA通知ISA对指定业务对象引用(英文缩写为SOR)的业务访问结束，请求给出即时计费报告。(2)ISA-SCS：如果该业务访问是本地访问，则ISA请求SCS结束对应的业务对象引用，返回该业务对象引用的计费报告。(3)ISA-FISA：如果该业务访问是用户主环境的业务访问，则属于远地业务访问，则ISA请求FISA结束对应的业务对象引用，返回该业务对象引用的计费报告。(4)SCS-ISA：如果是本地业务访问，则SCS关闭所指定业务对象，返回计费报告。(5)FISA-ISA：如果是外地业务访问，则FISA请求FSCS关闭指定业务对象，返回计费报告。(6)ISA-FA：ISA综合所有该业务对象的计费报告，提交给FA。

漫游到客环境用户，在执行业务期间，ISA中的计费代理将定时计算该用户已经消费的费用，比较用户可用的费用，确定是否需要向用户发出业务终止警告，是否需要终止用户正在进行的业务。该用户消费额度检查的流程见图11，具体过程说明如下：(1)ISA-SCS：ISA根据FA用户目前使用的业务对象，向SCS查询指定业务对象的计费报告。(2)ISA-FISA：ISA根据FA用户目前使用的业务对象，向FISA查询指定业务对象的计费报告。(3)SCS-ISA：SCS向ISA返回指定业务对象的计费报告。(4)FISA-ISA：FISA向ISA返回指定业务对象的计费报告。(5)根据综合计费报告与FA用户现有费用的情况，决定是否需要向FA返回业务终止警告，是否需要终止该FA正在使用的业务。

为了实现FA访问开放业务的过程，必须设计与ISA相关的一组接口规范，这里包括ISA之间的隧道接口规范，ISA-SCS接口规范，ISA-FW接口规范，ISA-FA接口规范。

ISA之间隧道接口规范主要包括：业务发现类接口(这类接口有状态维护的需求，首先是发现业务，此时需要保留发现业务的用户标识以及被发现业务的对象管理器标识，随后如果该用户可能选择该业务，则就立即根据发现业务管理对象的标识，创建服务于该用户的业务对象的实例。如果在一段时间内，该用户不选择该业务，则自动终止该用户的会话，释放保持的状态)、业务访问类接口(这类接口主要是透明转发业务访问请求和响应，这里不需要维护业务调用会话。这里会产生问题：对于原来需要会话的业务访问，ISA是否需要维持会话？答案应该是不需要)、业务计费类接口(这类接口是ISA主动发起的业务调用，本身需要维护一个业务访问状态，同时还需要创建一个响应对象)。

ISA-FW接口主要实现ISA的创建、业务发现、以及业务计费功能，包括两类接口：(1)创建和管理ISA对象类接口(这里管理指在规定时间可以关闭所创建的ISA对象实例)。(2)业务发现类接口，用于发现在本管理域的业务，并且准备创建对应的业务对象。(3)业务计费类接口。

ISA-SCS接口主要实现业务访问请求和响应的转发。对于具有会话要求的业务访问，该接口根据需要，提供相应的会话管理功能。

跨业务管理域的开放业务访问功能的实现与Parlay开放业务规范定义的单个管理域开放业务访问功能的实现方法基本相同，都是采用基于一种分布处理环境的软件实现。可以选择的分布处理环境包括基于分布对象计算的CORBA(公共对象请求代理体系结构)实现技术，或者基于面向服务计算的万维网服务实现技术。跨业务管理域的开放业务访问实现与单一管理域唯一可能不同之处是：根据跨业务管理域的业务量大小，可以选择采用单一的域间业务代理(ISA)服务器。即ISA功能单独在一台服务器上实现。如果跨业务管理域的业务量不大，可以将ISA与Parlay定义的框架服务器合并在一个物理服务器上。

该技术发明可以在现有的电信网之上加载一层开放业务平台之后，就可以实现基于开放业务平台之上的各种电信增值业务的漫游功能。给功能的几个实现实例如下：

实现实例一：北京到巴黎的商业用户的综合电信业务漫游。住在北京的王先生到法国巴黎参加国际电信联盟(ITU-T)的一个学术会议，随身携带了商务型多功能手机，可以打电话、收发短信、具有网络接口可以访问因特网、收发邮件，并且配备有视频摄像头。王先生在国内通过开放业务供应商已经申请了移动电话、短信、因特网访问、收发邮件和视频会议等电信业务。王先生已经知道，法国已经与中国可以通过跨管理域的开放业务访问接口互连、互通。

王先生到达巴黎，一下飞机就打开多功能手机，该手机自动呼叫巴黎本地负责开放业务接入的开放业务框架服务器(FW)，该FW从其手机号就可以判断这是从中国漫游过来的用户，由于巴黎与中国已经利用这里发明的跨管理域开放业务访问技术相互连接，所以，巴黎的FW就到北京的框架服务器(FFW)验证王先生身份并且在北京FFW注册，同时北京FFW将王先生原来在北京已经申请的业务通过加密形式经过FW转发给王先生手机。至此，王先生的多功能手机已经在巴黎完成用户注册。

此时王先生手机出现了业务定制的提示，王先生选择全部保留国内申请的业务，这样，王先生这种业务定制请求就会传到巴黎的域间业务代理(ISA)服务器，ISA根据查询本地的FW和北京这里的域间业务代理(FISA)服务器，向王先生提供了一个最适合于王先生业务定制要求的、并且价格最低的默认配置以及其他可选配置提交给王先生，王先生选择了默认配置。在默认配置中，电话、短信、因特网访问、收发电子邮件都采用巴黎本地业务能力服务器(SCS)提供的业务，而视频会议采用北京当地的业务能力服务器(SCS)提供的业务，因为巴黎尚无法提供这类中国专用的业务。至此，王先生已经完成了漫游到巴黎的业务定制，下面就可以像在国内一样使用原来申请的电信业务了。

随后在巴黎的几天，王先生通过巴黎的SCS使用电话、短信、因特网访问、收发邮件业务，偶尔通过北京的SCS与国内同时召开视频会议，商量有关项目的问题。每次王先生通过电话、访问过因特网或者开过视频会议后，巴黎的ISA会自动将所用业务发生的费用情况传递给王先生，王先生可以浏览一下，也可以不予关注。因为王先生是具有无业务消费额度限制的用户。

实现实例二：北京到巴黎的官方代理综合电信业务漫游：李先生是北京某政府机构的官员，到巴黎参与有关政府采购的商务谈判，随身携带了与李先生一样的商务型多功能手机。同样，李先生下了飞机后就立即打开手机，采用与王先生一样的方式通过北京的FFW完成了用户注册。

此时李先生手机也出现了业务定制的提示，李先生也选择全部保留国内申请的业务，这样，李先生这种业务定制请求就会传到巴黎的域间业务代理(ISA)服务器，ISA根据查询本地的FW和北京这里的域间业务代理(FISA)服务器，向李先生提供了一个最适合于李先生业务定制要求的、并且价格最低的默认配置以及其他可选配置提交给李先生。但是，国家对政府官员出国使用开放业务有明确规则，必须选择注册地的开放业务。这样，李先生没有接收巴黎ISA提供的默认配置，而是选择全部采用北京FSCS提供业务的较为安全的业务配置，当然，这样配置的费用较高。但这是国家统一支付的费用。

随后在巴黎的几天，李先生在巴黎依然可以使用在国内申请的各种电信业务，并且是在国内开放业务服务器上具体实现这些业务。十分安全可靠。

实现实例三：北京到巴黎的游客综合电信业务漫游：张先生是北京市民，利用“十一”长假到法国旅游，他随身携带了一个基于开放业务访问的移动电话(手机)。他在北京申请了预付费的移动电话和短信业务。张先生到达巴黎后，一下飞机就打开手机，与王先生和李先生一样，他也完成了在北京FW的用户注册。

此时张先生手机上也出现了业务定制的提示，张先生觉得在巴黎只要与北京交互短信就可以了，所以，仅仅选择了短信业务，并且是通过巴黎本地的SCS提供相应的业务。

随后几天张先生在巴黎依然可以使用短信业务，因为游玩的十分高兴，同时在国内习惯上认为短信十分便宜，所以，与亲戚和同事通了不少短信。一天张先生突然收到一条短信，通知他还剩余可以发送10条短信的消费额度。他十分奇怪，觉得自己出国前已经预付了足够的费用。一查询费用，才发现在巴黎向国内发送短信，每条不是相当于一角人民币的费用，而是相当于3元人民币的费用。以后张先生在发送短信时也注意节省，愉快地度过了在法国的旅游假期。

Claims (4)

1、一种多管理域开放业务访问结构与接口方法，其特征在于多管理域开放业务访问结构总流程为：

1)漫游用户FA首先需要进行异地用户身份验证和注册，

2)如果注册成功则FA再进行业务定制；如果注册不成功，则自动结束FA跨管理域的业务访问，

3)如果业务定制失败，则自动结束漫游用户FA的跨业务管理域的业务访问。如果业务定制成功，则判断FA是否是预付费用户，

4)如果是预付费用户，则检查用户FA可用消费额度，并且判断是否额度太小；如果额度太小，则调用业务终止流程，终止该用户业务，如果不是额度太小，则进行业务访问，

5)如果FA不是预付费用户，则进行业务访问，

6)用户访问业务完毕后，判断是否要结束业务；如果要结束业务，则调用业务终止流程，终止该用户业务，

7)如果用户不要结束业务，则返回到第(4)步，“判断用户是否是预付费用户”的处理，继续用户跨管理域的业务访问。

2、根据权利要求1所述的多管理域开放业务访问结构与接口方法，其特征在于根据FW服务器管理员结构和ISA业务访问隧道结构，FA访问开放业务的身份验证和注册的基本流程如下：

1)、FA-FW，申请注册用户，

2)、FW-FFW，FW判断FA地址标识，向FFW转发注册请求，

3)、FFW-FW，FFW验证用户身份，返回验证和注册结果给FW，

4)、FFW-FISA，如果验证通过，FFW将在本地ISA创建该用户对应的远地业务访问实体，

5)、FFW-FW，如果验证通过，FFW返回该用户在本地ISA的业务调用对象引用，

6)、FW-FA，FW向FA返回身份验证和注册结果，

7)、FW-ISA，如果FA身份验证通过，则FW在ISA创建FA对应的业务访问对象，并且将FA的信息存入其中，同时获得该对象的引用，

8)、FW-FA，如果FA身份验证通过，则FW向FA返回其在ISA中对应的业务访问对象的引用。

3、根据权利要求1所述的多管理域开放业务访问结构与接口方法，其特征在于框架管理员在跨业务管理域进行身份验证和业务合同签署的处理过程如下：

1)离线交互各自框架的默认管理员帐户注册信息，

2)客环境的本地框架服务器FW即本地框架服务器利用默认的框架管理员帐户以及离线协商好的交互方式，向主环境框架服务器FFW(即外地框架服务器)进行默认管理员的身份验证。如果身份验证不通过，则终止跨业务管理域的身份验证，

3)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW在线创建FW管理员帐户和协商身份验证方法，如果FFW认可创建的帐户和协商的身份验证，则接受该新建的FW管理员帐户，否则FW重新创建和协商，

4)客环境的本地框架服务器FW可以通过F2FF接口类向主环境框架服务器FFW协商跨管理域的业务，

5)如果主环境FFW同意FW提出的业务合同，则通过F2FF接口类签署业务合同，否则，继续与FW进行跨管理域的业务协商。

4、根据权利要求1所述的多管理域开放业务访问结构与接口方法，其特征在于根据FW服务器管理员结构和ISA业务访问隧道结构，对于一个漫游到客环境的开放业务用户FA需要通过一定步骤，实现用户注册，该过程的流程如下：

1)客环境的开放业务应用FA通过F2FA接口发出对于用户身份信息和业务定制信息加密的用户注册请求，

2)客环境框架管理员判断是否与该漫游用户主环境签署了业务合同，如果没有，再进一步判断是否可以访问到该用户的业务主环境，如果无法查找到该漫游用户的业务主环境，则客环境框架管理员拒绝该漫游用户的注册请求，如果没有签署业务合同，但是可以找到该用户的业务主环境，则客环境框架管理员与该用户业务主环境签署业务合同，如果业务合同签署失败，则客环境框架管理员拒绝用户注册，如果已经存在与漫游用户主环境的业务合同，则客环境框架管理员透明转发用户的注册请求，

3)主环境框架管理员解密漫游用户注册请求，代理漫游用户调用相应的用户注册服务接口，并且加密用户注册响应，连同用户注册是否成功的结果一起返回给客环境管理员，如果用户在主环境注册成功，则主环境框架功能模块FFW将请求主环境域间业务代理功能模块FISA，

4)如果漫游用户成功注册，则客环境管理员将加密的用户注册响应报文转发给漫游用户，同时，也在客环境为漫游用户创建一个跨业务管理域的业务代理(ISA)，并将该ISA的引用传递给漫游用户，如果主环境管理员返回注册失败报文，则客环境管理员拒绝漫游用户注册，同时，就加密的用户注册响应报文转发给漫游用户，

5)漫游用户收到注册响应报文，完成用户的注册请求。

Images