WO2008046287A1

WO2008046287A1 - Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services

Info

Publication number: WO2008046287A1
Application number: PCT/CN2007/002371
Authority: WO
Inventors: Qiuling Pan; Yang Zhao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-10-13
Filing date: 2007-08-08
Publication date: 2008-04-24
Also published as: BRPI0719254A2; US20090196308A1; CN101163120A; EP2079197A4; EP2079197A1; CN101163120B

Description

协调不同业务提供者提供的业务的方法和系统技术领域

本发明涉及通信领域，尤其涉及协调不同业务提供者提供的业务的技术。背景技术

随着电信业务的蓬勃发展，各运营商逐步由单一的话音运营商向综合信息运营商进行转型。在向综合信息运营商的转型过程中，运营商迫切需要大量、并且丰富多样的业务或信息。然而随着业务的发展和深入，业务呈现出越来越多的特性和复杂度。为了减少整个业务流程体系中业务之间的交互障碍和复杂度，以及满足人们日益广泛的需求，迫切需要一种技术来规范业务与业务之间的发现 /交互机制。

目前业界广泛使用的是提供业务服务的 OS A/Parlay ( Open Service Architecture,开放业务架构 /Parlay )机制，和基于 ΟΜΑ( Open Mobile Alliance, 开放移动联盟）引擎环境提供的 OSE ( Open Systems Environment, 开放系统环境）机制。

所述 OSA/Parlay机制的应用体系架构如图 1所示，包括 Application Server (应用服务器）、 Parlay Gateway ( Parlay网关）以及 API ( Application Programming Interface, 应用编程接口 )。所述 Parlay网关由才匡架 ( Framework ) 和一个或多个业务能力特征（SCF )组成。其中所述业务能力特征是对网络所提供功能的抽象，所述 API位于应用服务器与 Parlay网关之间，通过这个开放、标准的接口，业务开发商、独立软件提供商（ISV )等可以获得使用现有网络资源的能力，方便、灵活的开发新业务，从而为客户提供所需要的业务。

所述 Application Server, 由第三方业务供应商或网络运营商提供，用以开发各种业务，以便提供给终端用户使用。所述 Parlay Gateway包括 Parlay服务器，它为 Parlay客户端提供各种基本业务能力的支持，使 Parlay客户端的业务能够有控制的、安全的进入到各通信网内。 Parlay客户端通过调用 API访问 Parlay服务器，它们之间可以釆用 CORBA (公共对象请求代理架构）、 WEB Service ( WEB服务）、 JAIN SPA ( JAVA高级智能网业务提供者接口）等分布对象技术进行通信。

所述 OSE机制是由 OMA组织提出的另一种提供开放业务的技术，其提供分层的、模块化的、开放的业务生成和执行环境，满足业务快速、有效、低成本发展的需要。其摒弃原来垂直的业务模型 "Silo", 划分业务组成各种引擎 (如呈现，位置，设备管理，彩信等等），再在 OSE的执行环境中进行管理和雇用。其应用体系架构如图 2所示，包括：执行环境、各种引擎、策略执行实体和底层网络资源，所述各种引擎通过 12接口获取底层网络资源，并应用所述底层网络资源生成业务；所述执行环境通过 II接口管理所述各种引擎中的业务；所述各个引擎还有各自暴露的 10接口连接所述策略执行实体，用来获取策略信息，在执行各个引擎的固有功能之时同时考虑运营商或者终端用户的设定策略。

随着 OSE技术的发展，众多业界企业开始研究融合重用 OSA/Parlay和 OSE 二者能力的技术，以便在原有 OSA/Parlay技术的基础上，或者在将来部署的业务网络里，能够兼容 OSA/Parlay和 OSE两者的能力，为业务开发和业务组合提供更广泛的基础，提供更统一的封装能力，以便避免重复开发等浪费。另一方面， OS A/Parlay架构和 OSE架构中的业务提供者中所支持的业务能力会存在不一致的情况，因此若要实现二者的共同配置，必须解决不同的业务提供者能够对同一业务请求进行处理的问题，以便协调不同业务提供者提供给移动用户的业务。系统 ) 网络里面配置 iFC ( Initial Filter Criteria; 初始过滤规则 )来解决不同的业务提供者能够对同一业务请求进行处理的问题。然而，这种通过配置核心网的方式不符合业务独立，分层的思想，限制了业务环境的灵活性；同时，复杂的 iFC配置会加重网络的负担，会导致整个网络处理业务的效率下降。并且，随着业务的增加，经常修改 iFC容易引起网络不稳定，可能埋下巨大隐患。发明内容

本发明提供一种协调不同业务提供者提供的业务的方法和系统，通过本发明，能够使处于不同架构的不同业务提供者均能够为用户提供相应的业务，为业务开发提供了更灵活的方式，更丰富的手段。

本发明实施例通过如下的技术方案实现：

本发明提供一种协调不同业务提供者提供的业务的方法，其包括：业务适配分发中心 SADC获得发送端的业务请求后，根据接收端的相关业务数据，将业务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端。

本发明还提供一种协调不同业务提供者提供的业务的系统，其包括：发送端，用于发送业务请求；

业务适配分发中心 SADC, 用于获得发送端的业务请求后，根据接收端的相关业务数据，将业务请求转换为所述接收端所能够支持的标准形式，然后将所述业务请求传送到所述接收端。

本发明还提供一种业务适配分发中心，其包括：

信息传输单元和业务交换单元；

所述信息传输单元，用于接收发送端的业务请求，并将其传送给所述业务交换单元；并将所述业务交换单元发送的经过转换处理后的业务请求发送给接收端；

所述业务交换单元，用于获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为所述接收端所能够支持的标准形式，然后将其传送给所述信息传输单元。由上述本发明提供的技术方案可以看出，本发明中， SADC 获得发送端的业务请求后，根据接收端的相关业务数据，将业务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端，因此通过本发明，能够使处于不同架构的不同业务提供者均能够为用户提供相应的业务，协调了处于不同架构的不同业务提供者为用户提供的业务，为业务开发提供了更灵活的方式，更丰富的手段。例如能够协调基于 Parlay和基于 OSE技术提供给移动用户的业务的部署和提供，实现了将已有的 Parlay 组件配置到近年发展起来的 OSE环境中，不仅能够节省资源，保护运营商的投资，而且为业务开发提供了更灵活的方式，更丰富的手段。

另外，本发明通过 SADC修改业务提供者与上层应用实体间交互信息的调用格式，为上层应用实体提供了统一接口。附图说明

图 1为背景技术提供的 OSA/Parlay机制的应用体系架构示意图；图 2为背景技术提供的 OSE机制的应用体系架构示意图；

图 3为本发明第一实施例的流程图；

图 4为本发明第一实施例中，在作为业务请求者的客户端订阅呈现业务，并且业务提供者均支持所述呈现业务的情况下的处理流程；

图 5为本发明第一实施例中，在所述 SADC根据业务提供者的所支持的相关业务数据修改所述 SIP请求消息中的相关数据的情况下的处理流程；图 6为本发明第二实施例的流程图；

图 7为本发明第二实施例中，在作为业务请求者的客户端订阅呈现业务，并且业务提供者不支持呈现业务中的一些功能的情况下的处理流程；

图 8为本发明第三实施例的流程图；

图 9为本发明第五实施例的结构原理图；

图 10为本发明第六实施例的结构原理图。

词语解释：

PAM ( Presence and Availability Management , 呈现业务管理）。具体实施方式

本发明实施例为了对不同业务提供者提供的业务进行协调，在作为发送端的业务请求者和作为接收端的业务提供者之间，和 /或，在作为发送端的业务提供者与作为接收端的业务提供者的上层应用实体之间，设置了一种 SADC ( Service Adaptor/Dispatcher Center, 业务适配分发中心 )。

当 SADC设置在作为发送端的业务请求者和作为接收端的业务提供者之间时，由于业务请求者与业务提供者之间所支持的调用格式是相同的，此时 SADC 主要用来处理当业务请求者所请求的业务内容与业务提供者所能够支持的业务内容不一致的情况。当业务请求消息到达 SADC后， SADC根据业务请求者的业务请求消息中的所请求的业务内容，以及其它附带的信息，比如号段等信息，通过策略的控制选取合适的业务提供者，并根据接收端的业务数据，对不符合所述业务提供者所支持的业务请求进行转换，然后将符合标准形式的业务请求消息发送给所选择的业务提供者；所述业务提供者返回相应的业务结果。这样能够在业务提供者提供给移动用户的业务与所述移动用户所请求的业务中的某些业务功能出现不一致时，继续提供所述移动用户所请求的业务中的其它的业务功能。当业务提供者提供给移动用户的业务与所述移动用户所请求的业务出现不一致时，所述 SADC也可以不对所述业务请求进行转换，而直接中止所述业务请求。

当所述 SADC设置在作为发送端的业务提供者与作为接收端的业务提供者的上层应用实体之间时，由于业务提供者与业务提供者的上层应用实体之间所支持的业务内容一致，并且业务提供者知道上层应用实体釆用的服务技用格式会存在不同，例如釆用 OSA/Parlay技术的业务提供者所支持的调用格式为函数调用格式，而釆用 OSE技术的上层应用实体所支持的调用格式为消息调用格式，此时所述 SADC主要用来将不符合上层应用实体所支持的业务请求的调用格式进行转换，然后将符合标准形式的业务请求消息发送给所述上层实体，这样可以为业务提供者的上层应用实体提供统一的接口。

本发明第一实施例是一种协调不同业务提供者提供的业务的方法，该实施例中， SADC根据接收到的业务请求和设定的策略选择相应的业务提供者，然后根据作为接收端的业务提供者的相关业务数据判断业务提供者是否支持所述业务请求中所请求的业务，若支持，则将所述业务请求传送到所述业务提供者；若不支持，则根据业务提供者的相关业务数据修改所述业务请求中的消息内容，并将修改后的业务请求传送到相应的业务提供者。该实施例的具体实施过程如图 3所示，包括如下内容：

步骤 S101 , 作为发送端的业务请求者发送业务请求到核心网，所述核心网将所述业务请求转发到业务适配分发中心 SADC。

请求消息中携带的目的地址为 SADC的地址。业务请求中还包含有业务数据等消息内容，以及业务请求者所使用的号码、业务请求者的优先级级别和 /或负载均衡原则等信息。

步骤 S102 , SADC根据业务请求和设定的策略选择相应的业务提供者作为接收端。

设定的策略包括号段与业务提供者间的对应原则、优先级级别与业务提供者间的对应原则和 /或负载均衡原则。

SADC根据所述业务请求中包含的业务请求者的所使用的号码、业务请求者的优先级级别和 /或负载均衡原则等信息去匹配设定的策略中的信息，如果匹配到，则按照所匹配到的策略信息对应的原则选择相应的业务提供者作为接收端。

步骤 S103 , 根据业务提供者的相关业务数据判断业务提供者，如 Parlay网关、 OSE引擎网关，是否支持所述业务请求中所请求的业务，若支持，则执行步骤 S104; 若不支持，则执行步骤 S105。

步骤 S104, 将该业务请求传送到业务提供者，然后执行步骤 S106。

步骤 S105 , 根据业务提供者的相关业务数据修改所述业务请求中的相关数据，并将修改后的业务请求传送到相应的业务提供者，然后执行步骤 S106。

步骤 S105中，当 SADC发现业务提供者不支持业务请求中所请求的业务后，其会根据业务提供者的相关业务数据对所述业务请求消息中的相关数据进行修改，使其符合所述业务提供者所支持的消息内容。 SADC 获取业务提供者的相关业务数据的方式有两种：第一种方式： SADC 事先保存有业务提供者所支持的业务数据，并周期性地从所述业务提供者中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。

第二种方式： SADC 获得业务请求者的业务请求后，根据所述业务请求通过查询的方式获取到相应的业务提供者中的相关业务数据。

步骤 S106, 业务提供者根据业务请求消息中所请求的业务进行相应的处理，并返回相应的业务成果。

当在业务提供者和其上层应用实体间设置有 SADC时，在步骤 S106中，当业务提供者接收到业务请求消息后，可以通过 SADC修改所述业务请求消息的调用格式，使其符合业务提供者的上层应用实体能够支持的调用格式，然后再将修改后的业务请求消息发送给所述业务提供者的上层应用实体，然后由业务提供者的上层应用实体提供相应的业务成果。可以看出，业务提供者通过 SADC这样处理后，其可以为上层应用实体提供统一的接口。

当然，在步骤 S106中，业务提供者也可以不对业务请求消息的格式进行修改，但这样，不同业务提供者连接的上层应用实体就不容易做到统一，必须对上层的业务应用进行^ ί 改。

步骤 S107, SADC将所述业务成果返回给所述业务请求者。

在步骤 S107中， SADC通过某些消息携带业务成果，在发送所述消息之前，需要将所述消息的内容修改为所述业务请求者所支持的消息内容，之后再发送给所述业务请求者。

下面以业务请求者的客户端作为发送端订阅呈现业务，并且业务提供者 Parlay网关或 OSE引擎网关作为接收端支持所述呈现业务为例对本发明提供的第一实施例进行详细说明，如图 4所示：

首先，业务请求者的客户端作为发送端，发送订阅呈现业务的 SIP请求消息给核心网 SIP/IP Core, 请求消息中携带的目的地址为 SADC的地址。所述请求消息中还包括有订阅呈现体（presentity )的信息，触发事件 Event为呈现（Presence ) 业务等消息内容，以及业务请求所使用的号段信息。随后，所述 SIP/IP Core通过 SIP订阅请求消息中携带的目的地址将所述 SIP订阅请求消息转发到 SADC。

接着， SADC根据业务请求所使用的号码去匹配设定的策略中的号段，如果匹配到，则根据所述设定的策略中的原则选定一个业务提供者作为接收端，可以是 Parlay网关，也可以是 OSE引擎网关。

然后， SADC根据所选定的业务提供者所支持的业务数据判断所述业务提供者是否支持所请求的呈现业务，当获知到业务提供者支持所请求的业务后，则修改所述 SIP请求消息携带的目的地址，将所述 SIP请求消息发送到所述业务提供者。

业务提供者根据所述 SIP请求消息返回 200 OK的 SIP响应消息给所述 SADC, 其中携带着相应的业务成果。

SADC返回 200 OK的 SIP响应消息给所述 SIP/IP Core。

SIP/IP Core返回 200 OK的 SIP响应消息给所述客户端。

对于业务提供者不支持业务请求者所请求的业务的处理，主要针对 Parlay 架构和 OSE架构中所支持的业务数据不一致的情况：例如 OSE架构中的呈现业务支持 Filtering (过滤）功能，即能够设定接收 Presentity (呈现体）等呈现信息。而早期的 Parlay网关不支持这种 Filtering (或者其它功能，如 Partial Notification, Partial Publication )功能。此时，如果在 OSE域的客户端发送订阅消息订阅要求过滤功能的 Parlay呈现业务的信息时，如果 Parlay网关不能支持要求过滤功能的 Parlay呈现业务，将会出现业务处理不一致的情况。这时需要所述 SADC根据业务提供者的所支持的相关业务数据修改所述 SIP请求消息中的相关数据。具体实现如图 5所示，包括：

业务请求者的客户端作为发送端，发送 SIP订阅请求消息；所述 SIP订阅请求消息中携带的目的地址为 SADC的地址。所述业务请求中还包含有业务数据等消息内容，以及业务请求者所使用的号码、业务请求者的优先级级别和 /或负载均衡原则等信息。

核心网 SIP/IP Core将 SIP订阅请求消息发送到 SADC； SADC根据 SIP订阅请求消息和设定的策略选定业务提供者为 Parlay网关。具体实现与上述实例中的相关描述雷同，这里不再详细描述。

然后 SADC根据业务提供者 Parlay网关的相关业务数据判断出其不支持过滤功能，则将 SIP请求消息中要求过滤功能的信息去掉，使其达到 Parlay 网关所能够支持的消息内容。

然后 SADC将修改后的 SIP订阅请求消息发送给所述 Parlay网关；

Parlay网关返回 200 OK的 SIP响应消息给所述 SADC。

SADC返回 200OK的 SIP响应消息给所述 SIP/IP Core。

SIP/IP Core返回 200OK的 SIP响应消息给所述客户端。

本发明第二实施例是另一种协调不同业务提供者提供的业务的方法，该实施例中， SADC根据接收到的业务请求和设定的策略选择相应的业务提供者作为接收端，然后根据业务提供者的相关业务数据判断业务提供者是否支持业务请求中所请求的业务，若支持，则将所述业务请求传送到业务提供者；若不支持，则丟弃所述业务请求，并返回提供业务失败的信息以及相应的失败原因值。当业务请求到达作为接收端的业务提供者后，业务提供者根据其上层应用实体所支持的业务数据对所述业务请求中的调用格式进行修改，使其符合上层应用实体所支持的调用格式，然后发送给上层应用实体，上层应用实体与业务提供者进行交互共同完成业务提供的任务。该实施例的具体实施过程如图 6所示，包括如下内容：

步骤 S201 , 作为发送端的业务请求者发送业务请求到核心网，所述核心网将业务请求转发到业务适配分发中心 SADC。

步骤 S202 , SADC根据所述业务请求和设定的策略选择相应的业务提供者作为接收端。设定的策略中包含的策略信息，以及所述步骤 S202的具体实现与第一实施例中的相关描述雷同，这里不再详细描述。步骤 S203， SADC根据所述业务提供者的相关业务数据判断所述业务提供者，如 Parlay网关、 OSE引擎网关，是否支持所述业务请求中所请求的业务，若支持，则执行步骤 S204; 若不支持，则执行步骤 S205 , 即丟弃所述业务请求，并返回提供业务失败的信息以及相应的失败原因值。

步骤 S204, 将业务请求传送到业务提供者，然后执行步骤 S206,

步骤 S206 , 业务提供者根据业务请求消息中所请求的业务进行相应的处理，并返回相应的业务成果。

当在业务提供者和其上层应用实体间设置有 SADC时，在步骤 S206中，当业务提供者接收到业务请求消息后，可以通过 SADC修改业务请求消息的格式，使其符合业务提供者的上层应用实体能够支持的调用格式，然后再将修改后的业务请求消息发送给业务提供者的上层应用实体，然后由业务提供者的上层应用实体与所述业务提供者进行信息交互，共同完成业务提供的任务，返回相应的业务成果。可以看出，业务提供者通过 SADC这样处理后，其可以为上层应用实体提供统一的接口。

当然，在步骤 S206中，业务提供者也可以不对业务请求消息的调用格式进行修改，但这样处理后，不同业务提供者连接的上层应用实体就不容易做到统一，必须对上层的业务应用进行修改。

步骤 S207, SADC将所述业务成果返回给业务请求者。

在步骤 S207中， SADC通过某些消息携带业务成果，在发送所述消息之前，同样需要将所述消息的内容修改为所述业务请求者所支持的消息内容，之后再发送给所述业务请求者。

下面以作为业务请求者的客户端订阅呈现业务，并且业务提供者不支持所述呈现业务中的一些功能为例对本发明提供的第二实施例进行详细说明，如图 7所示：

业务请求者的客户端作为发送端，发送 SIP订阅请求消息，所述 SIP订阅请求消息携带要求订阅过滤功能的呈现业务；

核心网 SIP/IP Core将 SIP订阅请求消息发送到 SADC; SADC根据设定的策略选定业务提供者为 Parlay网关；

然后 SADC根据业务提供者 Parlay网关的相关业务数据判断出其不支持过滤功能，则丟弃所述 SIP订阅请求消息，并返回提供业务失败的信息以及相应的失败原因值给所述 SIP/IP Core。

SIP/IP Core返回提供业务失败的信息以及相应的失败原因值给所述客户端。

本发明第三实施例是第三种协调不同业务提供者提供的业务的方法，该实施例中， SADC 获得作为发送端的业务提供者的业务请求后，根据作为接收端的业务提供者的上层应用实体的相关业务数据，将业务请求转换为业务提供者的上层应用实体所支持的调用格式，然后将所述业务请求传送到所述业务提供者的上层应用实体。该实施例的具体实施过程如图 8 所示，包括如下内容：

步骤 S301 , 当作为发送端的业务提供者接收到业务请求后，将所述业务请求发送给 SADC。

步骤 S302, SADC根据业务提供者的上层应用实体的相关业务数据，修改所述业务请求中的调用格式，并将修改后的业务请求传送到相应的上层应用实体。

例如，如果所述上层应用实体是釆用 OSE技术的应用实体，而业务提供者为釆用 OSA/Parlay技术的 Parlay网关，则需将业务请求消息中的 Parlay网关所支持的调用格式转换为上层应用实体所支持的调用格式。

以呈现业务的订阅功能为例，如某 Parlay网关的函数调用格式为： SubscribePresence(SbuscribePresenceRequest, SubscribeResponse) 其中，请求消息 SbuscribePresenceRequest包含以下两个参数：

Presentity(xsd:anyURI)

Attributes (PresenceAttributeType)

转换为消息调用格式后得到的 OSE的呈现业务的订阅功能的业务请求如下： SUBSCRIBE sip:user2@soho.com SIP/2.0

Via: SIP/2.0/UDP userl .huawei.com;branch=z9hG4bKnashds7

Max-Forwards: 70

From: <sip:userl@ soho . com>;tag=31415

To: <sip:user2@ soho.com>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 61 SUBSCRIBE

Event: presence

Expires: 7200

Accept: application/pidf+xml

Contact: userl . soho.com

Content-Type: application/simple-filter+xml

Content-Length: ...

其中， Presentity(xsd:anyURI)对应 OSE呈现订阅消息的 <sip:user2 soho.com> ) , 用来提供呈现业务被订阅者的地址， Attributes (PresenceAttributeType)对应 OSE 中呈现订阅消息中 Content-Type: application/simple-filter+xml , 用来指定订阅的 Presence信息的类型。

步骤 S302中， SADC获取业务提供者的上层应用实体的相关业务数据的方式有两种：

第一种方式： SADC 事先保存有业务提供者的上层应用实体所支持的业务数据，并周期性地从所述业务提供者的上层应用实体中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。

第二种方式： SADC 获得作为发送端的业务提供者的业务请求后，根据业务请求通过查询的方式获取到相应的业务提供者的上层应用实体中的相关业务数据。

步骤 S303 , 上层应用实体获得所述业务请求后，与所述业务提供者进行信息交互，完成业务提供的任务，然后将所述业务成果返回给 SADC。

步骤 S304, SADC将所述业务成果返回给所述作为发送端的业务提供者。在步骤 S304中， SADC通过某些消息携带业务成果，在发送所述消息之前，需要将所述消息的调用格式修改为所述业务请求者所支持的调用格式，之后再发送给作为发送端的业务提供者。

本发明第四实施例是一种协调不同业务提供者提供的业务的系统，其包括发送端、接收端和 SADC。

SADC 获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为接收端所能够支持的标准形式，然后将业务请求传送到接收端；当接收端根据业务请求提供相应的业务成果后， SADC 将所述业务成果发送给发送端。

当发送端为业务请求者、接收端为业务提供者时，系统还可以包括核心网，用于转发作为发送端的业务请求者发送的业务请求给 SADC; 以及，用于转发 SADC返回的业务成果给业务请求者。在这种情况下，系统中的各个元器件间的信号传递关系如下：

作为发送端的业务请求者发送业务请求消息到核心网，核心网通过其内的核心部件将业务请求消息转发到 SADC;

SADC 获得业务请求者的业务请求后，根据设定的策略选定相应的业务提供者，然后根据作为接收端的业务提供者的相关业务数据，判断业务提供者是否支持业务请求中所请求的业务中的功能，如果支持，则将业务请求消息转发到业务提供者。具体实施过程与本发明提供的第一实施例中的相关描述雷同，这里不再详细描述。

如果所选定的业务提供者不支持业务请求中所请求的业务中的一些功能，则釆取两种措施转换所述业务请求：

第一种：修改接收到的业务请求消息中的内容，将所述业务请求消息中业务提供者不支持的业务功能去掉，然后将修改后的业务请求消息传送到相应的业务提供者。具体实施过程与本发明第一实施例中的相关描述雷同，这里不再详细描述。

第二种：直接丟弃所述业务请求消息，并返回提供业务失败的信息以及失败原因值。具体实施过程与本发明第二实施例中的相关描述雷同，这里不再详细描述。

所述 SADC将所述业务成果发送给业务请求者。

当发送端为业务提供者，接收端为业务提供者的上层应用实体时，所述系统中的各个元器件间的信号传递关系如下：

当作为发送端的业务提供者接收到业务请求后，将其发送给 SADC;

SADC根据业务提供者的上层应用实体的相关业务数据修改所述业务请求中的调用格式，并将修改后的业务请求传送到相应的上层应用实体。 SADC 获取上层应用实体的相关业务数据的处理过程与第三实施例中的相关描述雷同，这里不再详细描述。

上层应用实体获得所述业务请求后，与所述业务提供者进行信息交互，完成业务提供的任务，然后将所述业务成果返回给 SADC。

SADC 将业务成果返回给作为发送端的业务提供者。这一部分的具体实施过程与第一实施例中的相关描述雷同，这里不再详细描述。

本发明第五实施例是一种业务适配分发中心，其结构如图 9所示，包括业务交换单元和信息传输单元。

当所述 SADC中没有业务提供者所支持的业务数据信息时，所述业务适配分发中心中还可以进一步包括业务数据获取单元。

所述业务数据获取单元保存有作为接收端的业务提供者的上层应用实体所支持的业务数据，并周期性地从所述接收端中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。或者，当业务请求到达业务适配分发中心后，业务适配分发中心通过所述业务数据获取单元根据所述业务请求通过查询的方式获取到相应的接收端中的相关业务数据。

当作为发送端的业务提供者的业务请求到达业务适配分发中心后，所述信息传输单元接收到后，将其传递给所述业务交换单元。

所述业务交换单元根据所述业务提供者的上层应用实体的业务数据修改所述业务请求，使其符合所述业务提供者的上层应用实体所支持的调用格式，并将修改后的业务请求传送到所述业务提供者的上层应用实体。业务适配分发中心的具体处理过程与本发明提供的第三实施例中的相关描述雷同，这里不再详细描述。

所述业务提供者的上层应用实体根据接收到的业务请求与作为发送端的业务提供者进行交互，并根据交互信息提供相应的业务成果，并将所述业务成果返回给业务适配分发中心；

业务适配分发中心通过业务交换单元对携带所述业务成果的消息的调用格式进行修改，使其能够符合作为发送端的业务提供者所能够支持的调用格式，然后通过所述信息传输单元将其发送出去。

本发明提供的第六实施例是一种业务适配分发中心，其结构如图 10所示，包括策略管理单元、路由确定单元、业务交换单元和信息传输单元。当业务适配分发中心中没有业务提供者所支持的业务数据信息时，业务适配分发中心还可以进一步包括业务数据获取单元。

所述策略管理单元管理一些设定的策略信息；所述设定的策略信息的详细描述与第一实施例中的相关描述雷同，这里不再详细描述。

所述业务数据获取单元保存有作为接收端的业务提供者所支持的业务数据，并周期性地从所述接收端中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。或者，当业务请求到达业务适配分发中心后，所述业务数据获取单元根据所述业务请求，通过查询的方式获取到相应的作为接收端的业务提供者中的相关业务数据。

当业务请求到达业务适配分发中心后，所述路由确定单元根据所述策略管理单元中的策略信息选定相应的业务提供者作为接收端；然后将所选定的业务提供者告知所述业务交换单元。

所述业务交换单元判断所述业务提供者是否支持所述业务请求中所请求的业务，若支持，则将所述业务请求传送到所述业务提供者；若不支持，则根据所述业务提供者的业务数据修改所述业务请求的内容，使其符合所述业务提供者所支持的消息内容，并将修改后的业务请求传送到所述业务提供者。业务适配分发中心的具体处理过程与本发明提供的第一实施例中的相关描述雷同，这里不再详细描述。

所述业务提供者根据接收到的业务请求提供相应的业务成果，并将所述业务成果返回给业务适配分发中心。

业务适配分发中心通过所述业务交换单元将携带所述业务成果的消息的内容进行修改，使其能够符合作为发送端的业务请求者所能够支持的消息内容，然后将其发送出去。

上述一些处理过程中是以呈现业务为例进行说明的，但本发明不限于仅仅应用呈现业务，本发明还可以应用于任何 Parlay和 OSE提供的业务如位置业务 Location, 策略业务 Policy等。而且，本发明不局限于应用到 OSA/Parlay 和 OSE这两种技术共存的系统中，还可以应用于解决其它系统中具有不同业务提供能力的业务提供者中遇到的同样问题，例如 ParlayX系统。

由上述本发明实施例提供的具体实施方案可以看出，本发明实施例中，业务适配分发中心 SADC获得业务请求者的业务请求后，根据接收端的相关业务数据，将业务请求转换为接收端所支持的形式，将所述业务请求传送到所述接收端，因此通过本发明，能够协调不同业务提供者提供给移动用户的业务，例如能够协调基于 Parlay和基于 OSE技术提供给移动用户的业务的部署和提供，实现了将已有的 Parlay组件配置到近年发展起来的 OSE环境中，也可保护已往开发的应用运用新的引擎，不仅能够节省资源，保护运营商的投资，并且为业务开发提供了更灵活的方式，更丰富的手段。

另外，本发明实施例通过 SADC修改相应的业务请求消息，能够防止提供给移动用户的业务出现不一致的现象发生。

另外，本发明实施例通过 SADC修改业务提供者与上层应用实体间交互信息的调用格式，为上层应用实体提供了统一接口。发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

权利要求

1、一种协调不同业务提供者提供的业务的方法，其特征在于，包括：业务适配分发中心 SADC获得发送端的业务请求后，根据接收端的相关业务数据，将业务请求转换为接收端所支持的形式，将所述业务请求传送到所述接收端。

2、如权利要求 1所述的方法，其特征在于，所述业务请求包括调用格式，所述根据接收端的相关业务数据将业务请求转换为接收端所支持的形式，将所述业务请求传送到所述接收端的过程，具体包括：

所述业务适配分发中心 SADC根据接收端的相关业务数据，将业务请求中的调用格式转换为接收端所支持的调用格式，然后将所述业务请求传送到所述接收端。

3、如权利要求 1所述的方法，其特征在于，所述业务请求包括业务内容，所述根据接收端的相关业务数据，将业务请求转换为接收端所支持的形式，将所述业务请求传送到所述接收端的过程，具体包括：

所述业务适配分发中心 SADC根据接收端的相关业务数据将业务请求中的内容转换为接收端所支持的消息内容，将所述业务请求传送到所述接收端。

4、如权利要求 3所述的方法，其特征在于，还包括：

业务适配分发中心 SADC获得发送端的业务请求后，根据业务请求和设定的策略选择相应的接收端。

5、如权利要求 3所述的方法，其特征在于，所述根据接收端的相关业务数据将业务请求中的内容转换为接收端所支持的消息内容，将所述业务请求传送到所述接收端的过程，具体包括：

所述 SADC根据所述接收端的相关业务数据，判断所述接收端是否支持所述业务请求所请求的业务，若确定出所述接收端不支持所述业务请求所请求的业务后，将所述业务请求中的内容转换为接收端支持的消息内容，将所述业务请求传送到所述接收端；或，

所述 SADC根据所述接收端的相关业务数据，判断所述接收端支持所述业务请求所请求的业务后，若确定出所述接收端支持所述业务请求中所请求的业务后，则将所述业务请求传送到所述接收端。

6、如权利要求 1至 5任意一项所述的方法，其特征在于，还包括：所述 SADC获得发送端的业务请求后，根据所述业务请求通过查询的方式获取到相应的接收端中的相关业务数据；或，

所述 SADC中保存有接收端所支持的业务数据，并从所述接收端中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。

7、如权利要求 6所述的方法，其特征在于，还包括：

SADC接收通过核心网转发的业务请求，所述业务请求来自发送端。

8、一种协调不同业务提供者提供的业务的系统，其特征在于，包括：发送端，用于发送业务请求；

业务适配分发中心 SADC,用于获得发送端的业务请求后，根据接收端的相关业务数据，将业务请求转换为所述接收端所能够支持的形式，将所述业务请求传送到所述接收端。

9、如权利要求 8所述的系统，其特征在于，还包括：核心网，用于转发所述发送端发送的业务请求给所述 SADC; 以及，用于转发所述 SADC返回的业务成果给所述发送端。

10、一种业务适配分发中心，其特征在于，包括：

信息传输单元和业务交换单元；

所述业务交换单元，用于获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为所述接收端所能够支持的形式 , 将其传送给所述信息传输单元。

11、如权利要求 10所述的业务适配分发中心，其特征在于，还包括：业务数据获取单元，用于当获得发送端的业务请求后，根据所述业务请求通过查询的方式获取到相应的接收端中的相关业务数据；或，用于保存有接收端所支持的业务数据，并从所述接收端中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。

12、如权利要求 10或 11所述的业务适配分发中心，其特征在于，所述业务交换单元还用于当所述业务适配分发中心获得发送端的业务请求后，根据接收端的相关业务数据将业务请求中的调用格式转换为接收端所支持的调用格式，将所述业务请求传送到所述信息传输单元。

13、如权利要求 10或 11所述的业务适配分发中心，其特征在于，还包括：策略管理单元和路由确定单元；

所述策略管理单元，用于管理设定的策略信息；

所述路由确定单元，用于根据所述策略管理单元中的策略信息选择相应的接收端。

14、如权利要求 13所述的业务适配分发中心，其特征在于，所述业务交换单元还用于根据所述路由确定单元选择的接收端的相关业务数据，判断所述接收端是否支持所述业务请求所请求的业务，若确定出所述接收端不支持所述业务请求所请求的业务后，将所述业务请求中的内容转换为所述接收端支持的消息内容，将所述业务请求传送到所述信息传输单元；若确定出所述接收端支持所述业务请求中所请求的业务后，则将所述业务请求传送到所述信息传输单元。