WO2010037329A1 - 一种业务协商方法、系统和设备 - Google Patents

Description

一种业务协商方法、 系统和设备

本申请要求于 2008 年 09 月 27 日提交中国专利局、 申请号为 200810148830.3、 发明名称为"一种业务协商方法、 系统和设备，，的中国专利申请 的优先权， 其全部内容通过引用结合在本申请中。 技术领域

本发明实施例涉及网络通信技术领域， 特别涉及一种业务协商方法、 系统 和设备。 背景技术

随着电信网络技术和用户需求的发展， 业务的提供需要多样化， 而当业务 的多样性达到一定程度时， 不同业务之间的交互能力又制约了运营商进一步发 展更为复杂的业务。 用户迫切需要一个完整的业务供应链而不是单独访问一系 列独立的服务子系统。

为了顺应业务管理的需求， 业界普遍以业务为中心重新对运营商的各类资 源进行整合， 统一抽象出网络的各种能力和资源开放给上层业务使用， 通过架 设叠加在现网上的业务网络设备实现不同业务之间的交互和管理。 业务网络通 过业务路由器、 业务组合引擎和业务目录等核心设备来负责管理和控制业务的 交互、 消息路由、 消息检测、 业务的组合和业务描述。

随着业务网络上注册的业务的快速增加， 业务之间的交互、 以及访问日益 复杂， 同时用户对业务体验的要求也进一步增强， 体验差的、 不可靠的业务被 用户所诟病。 业务访问不稳定、 不可靠、 死板无法个性化的问题日益暴露出来, 成为业务使用及管理上的顽疾。 同时由于构成组合业务的子业务也存在不可靠、 不稳定的情况， 这使得业务体验在组合业务的使用中更为突出。 目前业务的种 类千差万别， 对业务的需求也多种多样。 传统的对传输网络的控制及调控方式 已经无法满足上述的这些要求。 发明内容

本发明实施例提供一种业务协商方法、 系统和设备， 以实现业务网络支持 多种业务需求下的业务协商。

为达到上述目的， 本发明实施例一方面提供一种业务协商方法， 包括： 获得包含多个业务的业务协商请求；

根据所述业务协商请求获取所述多个业务的需求处理结果；

根据所述需求处理结果选择目标业务， 生成与所述业务协商请求对应的业 务协商结果并反馈。

另一方面， 本发明实施例还提供一种业务需求的发布方法， 包括： 获取目标业务的业务需求信息， 根据所述业务需求信息确定存在不可识别 的业务需求；

发布所述不可识别的业务需求。

再一方面， 本发明实施例还提供一种业务协商系统， 包括： 协商代理， 所 述协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协商请求 获取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业务， 生 成与所述业务协商请求对应的业务协商结果并反馈。

再一方面， 本发明实施例还提供一种协商代理， 包括：

协商请求分析单元， 用于获得包含多个业务的业务协商请求， 分析出需要 处理的目标业务， 及协商要求；

目标业务协商单元， 用于向所述需要处理的目标业务归属的业务路由器请 求所述目标业务的业务需求信息， 接收所述目标业务归属的业务路由器针对所 述目标业务的业务需求信息反馈的需求处理结果；

协商结果生成单元， 用于根据所述需求处理结果选择目标业务， 生成与所 述业务协商请求对应的业务协商结果并反馈。

再一方面， 本发明实施例还提供一种业务路由器， 包括： 协商处理系统， 用于接收并处理目标业务的业务协商请求， 并反馈针对所 述业务协商请求的协商结果。

再一方面， 本发明实施例还提供一种业务组合引擎， 包括： 协商代理， 所 述协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协商请求 获取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业务， 生 成与所述业务协商请求对应的业务协商结果并反馈。

再一方面， 本发明实施例还提供一种业务路由器， 包括： 协商代理， 所述 协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协商请求获 取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业务， 生成 与所述业务协商请求对应的业务协商结果并反馈。

本发明实施例通过协商代理接收协商请求端的业务协商请求， 根据该业务 协商请求与业务路由器进行协商， 最后生成业务协商结果反馈至协商请求端， 实现了业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商 请求端的需求， 提高了业务协商的成功率及用户的满意度。 附图说明

为了更清楚地说明本发明实施例的技术方案， 下面将对实施例描述中所需 要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的 一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。

图 1为本发明实施例一种业务协商方法的流程图；

图 2为本发明实施例一种业务需求的发布方法的流程图；

图 3为本发明实施例业务协商系统的结构图；

图 4为本发明实施例协商代理的结构图；

图 5为本发明实施例业务路由器的一种结构图；

图 6为本发明实施例注册中心的结构图； 图 7为本发明实施例业务提供端的结构图；

图 8为本发明实施例另一种业务协商方法的流程图；

图 9为本发明实施例协商代理处理业务协商请求的流程图；

图 10为本发明实施例业务路由器协商过程的流程图；

图 11为本发明实施例发布新业务需求的一种流程示意图；

图 12为本发明实施例发布新业务需求的另一种流程示意图；

图 13为本发明实施例端口关系示意图；

图 14为本发明实施例的具体实施例的流程图。 具体实施方式

下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明的一部分实施例， 而不 是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有做出创 造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。

本发明实施例提供一种业务协商方法或一种业务选择方法， 基于业务网络 实现， 是对业务层的两个或多个备选业务在多种业务需求上进行的协商， 选择 出目标业务。 这里的多种业务需求包括但不限于业务的功能性信息 （例如： 接 口描述） 、 动态需求（例如： 价格， 安全等级等）或承载网服务质量（例如： 时延、 稳定性） 。 本发明实施例提供的一种业务协商方法还可以满足动态变化 的业务需求。 本发明实施例还可以支持不可识别的业务需求， 可以满足业务多 样化的业务需求。

图 1为本发明实施例一种业务协商方法的流程图。 如图 1所示， 本发明实 施例提供了一种业务协商方法， 包括：

步骤 S101 , 获得包含多个业务的业务协商请求。

本发明实施例中， 协商代理接收协商请求端发送的业务协商请求， 该业务 协商请求包含多个业务的业务需求信息。 步骤 S102, 向多个业务归属的业务路由器请求多个业务的业务需求信息。 步骤 S103 , 接收多个业务归属的业务路由器针对上述业务需求信息反馈的 需求处理结果。

其中， 多个业务归属的业务路由器针对业务需求信息反馈需求处理结果具 体可以为：

多个业务归属的业务路由器根据多个业务的业务需求信息， 确定需要查询 的功能设备， 并向功能设备发送携带业务需求信息的需求查询请求。 接收功能 设备根据该需求查询请求反馈的需求查询结果， 根据需求查询结果生成需求处 理结果并反馈该需求处理结果至协商代理。

本发明实施例中， 多个业务归属的业务路由器确定需要查询的功能设备， 并向确定的功能设备发送携带业务需求信息的需求查询请求具体可以为：

向承载网服务质量（Quality of Service; 以下简称： QoS )管理器发送需求 查询请求， 查询多个业务归属的业务路由器与业务承载网之间的服务质量信息； 和 /或，

向业务目录发送需求查询请求， 查询业务功能信息， 该业务功能信息包括 业务提供商信息、 业务类别信息或业务接口描述信息； 和 /或，

向注册中心发送需求查询请求， 查询业务动态信息。 该业务动态信息包括 业务需求对应的具体数值结果， 或者， 业务需求对应的查询端口信息。

当查询到的业务动态信息为业务需求对应的查询端口信息时， 在向注册中 心查询业务动态信息之后， 多个业务归属的业务路由器还可以根据该查询端口 信息向业务提供端的相应查询端口查询该业务需求对应的具体数值结果。

步骤 S104, 根据需求处理结果选择目标业务， 生成与业务协商请求对应的 业务协商结果并反馈。

在接收到多个业务归属的业务路由器反馈的需求处理结果之后， 协商代理 根据该需求处理结果选择目标业务， 并生成与接收的业务协商请求对应的业务 协商结果， 发送该业务协商结果至协商请求端。 在另一种实现方式中， 协商代理从业务协商请求中获得需要处理的目标业 务， 向多个业务归属的业务路由器发送目标业务协商请求， 请求需要处理的目 标业务的业务需求信息。 需要处理的目标业务归属的业务路由器根据目标业务 的业务需求信息， 确定需要查询的功能设备， 并向功能设备发送携带业务需求 信息的需求查询请求。 然后， 需要处理的目标业务归属的业务路由器接收上述 功能设备针对该需求查询请求反馈的需求处理结果， 根据该需求处理结果生成 目标业务协商请求对应的目标业务协商结果， 并反馈目标业务协商结果至协商 代理。 然后， 协商代理根据目标业务协商结果选择目标业务， 生成与该业务协 商请求对应的业务协商结果。

本发明实施例中， 多个业务归属的业务路由器可以根据功能设备反馈的需 求处理结果确定存在不可识别的业务需求， 并发布不可识别的业务需求。

本实施例中， 可以不改变现有的业务路由器的功能， 使业务路由器仅仅处 理消息路由的基本功能， 本实施例中业务路由器处理的功能全部由协商代理处 理。 具体地， 由协商代理获得包含多个业务的业务协商请求， 根据该业务协商 请求获得多个业务的业务需求信息， 以及针对多个业务的业务需求信息的需求 处理结果， 然后根据该需求处理结果选择目标业务， 生成与上述业务协商请求 对应的业务协商结果， 并发送该业务协商结果至协商请求端。

另外， 本实施例中， 注册中心的功能也可以集成到现有的业务路由器上， 使其成为增强型业务路由器， 这时可以在集成了注册中心功能的业务路由器上 查询业务动态信息等信息。

本实施例中， 业务协商请求包括以下信息中的一种或几种：

a ) 多个业务的业务网络地址或业务标识， 协商代理才艮据该业务网络地址或 业务标识， 路由到多个业务归属的业务路由器；

b )多个业务的业务需求信息， 协商代理根据该多个业务的业务需求信息获 取多个业务的相关业务需求；

c ) 目标业务的选择要求， 协商代理根据该选择要求选择目标业务； d )对协商过程的要求， 协商代理根据该要求对协商过程进行控制。

业务协商结果包括以下信息中的一种或几种：

a ) 目标业务的业务网络地址或业务标识， 协商代理将目标业务的业务网络 地址或业务标识返回至协商请求端；

b )协商日志， 该协商日志包括协商过程的总处理时间， 或采用的协商策略。 目标业务协商请求包括以下信息中的一种或几种：

a )需要处理的目标业务的业务网络地址或业务的标识， 业务路由器根据该 业务网络地址或业务的标识， 路由到需要处理的目标业务归属的业务路由器； b )需要处理的目标业务的业务需求信息， 业务路由器根据该需要处理的目 标业务的业务需求信息确定需要查询的功能设备；

c )对目标业务协商结果的处理要求， 业务路由器根据该处理要求对目标业 务协商结果进行处理；

d )对目标协商过程的要求， 业务路由器根据对目标协商过程的要求对协商 过程进行控制。

目标业务协商结果包括以下信息中的一种或几种：

a )协商结果标识， 该协商结果标识指示协商结果， 以及协商结果对应的信 息， 协商代理根据协商结果确定业务需求是否被满足；

b )协商日志， 该协商日志包括协商处理时间和查询的功能设备标识； c )业务需求对应的具体数值结果。

上述业务协商方法， 协商代理接收协商请求端的业务协商请求， 根据该业 务协商请求与业务路由器进行协商， 最后生成业务协商结果反馈至协商请求端， 实现了业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商 请求端的需求， 提高了业务协商的成功率及用户的满意度。

图 2为本发明实施例一种业务需求的发布方法的流程图。 如图 2所示， 本 发明实施例提供了一种业务需求的发布方法， 具体包括：

步骤 S201 , 获取目标业务的业务需求信息， 根据该业务需求信息确定存在 不可识别的业务需求。

其中， 根据该业务需求信息确定存在不可识别的业务需求具体可以为： 查询目标业务归属的业务路由器所能支持的业务需求信息， 根据查询结果 确定存在不可识别的业务需求； 或者，

根据业务需求信息， 确定需要查询的功能设备， 并向确定的功能设备发送 携带业务需求信息的需求查询请求， 接收该确定的功能设备针对该需求查询请 求反馈的需求查询结果， 才艮据需求查询结果确定存在不可识别的业务需求。

步骤 S202, 发布不可识别的业务需求。 具体可以为：

目标业务归属的业务路由器将不可识别的业务需求的信息发布到该业务路 由器上或该业务路由器对应的注册中心上， 由业务提供端获得针对该业务的不 可识别的业务需求的信息； 并接收业务提供端发送的结果信息， 该结果信息是 业务提供端针对不可识别的业务需求生成的结果信息； 然后， 将上述结果信息 更新到业务路由器或注册中心上。 或者，

目标业务所归属的业务路由器查询注册中心， 获得业务注册时提供的需求 通知端口， 通过该需求通知端口将不可识别的业务需求通知业务提供端； 接收 业务提供端发送的结果信息， 该结果信息是业务提供端针对不可识别的业务需 求生成的结果信息； 然后将上述结果信息更新到业务路由器或注册中心上。

其中， 上述结果信息包括： 不可识别的业务需求对应的具体数值； 或者， 不可识别的业务需求对应的查询端口信息。

上述业务需求的发布方法， 业务路由器通过发布业务需求， 使初期不可识 别的业务需求后期可被发现及识别， 从而使业务协商不需要限定在固定的业务 需求上。

图 3为本发明实施例业务协商系统的结构图。 如图 3所示， 为本发明实施 例提供了一种业务协商系统， 包括： 业务目录 31、 注册中心 32、 业务组合引擎 33、 承载网服务质量管理器 34、 业务路由器 35、 协商代理 36和业务提供端 37。 其中， 协商代理 36是本发明实施例新增的功能设备。 业务目录 31是业务网络上的现有设备， 在逻辑上是全网唯一的， 负责维护 网络上可见业务的端口、 提供商等功能性信息 （静态的）。

注册中心 32是业务网络上的现有设备， 在逻辑上是与业务路由器 35—— 对应的， 用于维护所有归属于该业务路由器 35的业务的信息。 这些业务的信息 包括归属业务的业务标识或业务网络地址， 以及对应的物理网络地址。 一个业 务在注册到业务路由器 35时， 提供该业务的信息。

业务组合引擎 33用于发起业务协商请求， 为协商请求端。

承载网服务质量管理器 34是业务网络上的现有设备， 用于管理底层承载网 络的服务质量功能， 包括检测物理链路层的联通状态、 传输速率、 延时、 抖动 等信息。

业务路由器 35是业务网络上的已有设备， 主要负责路由业务层消息， 基于 业务的业务网络地址将相应的业务层消息路由到目的地， 在接收到协商代理 36 的请求之后，向协商代理 36反馈针对多个业务的业务需求信息的需求处理结果。

协商代理 36用于接收协商请求端例如： 业务组合引擎 33或者业务路由器 35发送的包含多个业务的业务协商请求，协商代理 36根据该业务协商请求的内 容向备选的多个目标业务归属的业务路由器 35发起业务协商， 请求多个业务的 业务需求信息， 并根据业务路由器 35反馈的需求处理结果选择出符合协商要求 的目标业务， 生成与业务协商请求对应的业务协商结果， 并反馈给协商请求端。

业务提供端 37是业务网络上的现有设备， 用于管理及维护运行在其上的业 务。

上述业务协商系统， 协商代理 36接收协商请求端例如： 业务组合引擎 33 或业务路由器 35发送的业务协商请求， 根据该业务协商请求生成目标业务协商 请求，并与业务路由器 35进行协商，最后生成业务协商结果反馈至协商请求端， 实现了业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商 请求端的需求， 提高了业务协商的成功率及用户的满意度。

图 4为本发明实施例协商代理的结构图。 如图 4所示， 本发明实施例中的 协商代理 36包括协商请求分析单元 361、 协商过程控制单元 362、 目标业务协 商单元 363和协商结果生成单元 364。

其中， 协商请求分析单元 361 用于处理协商请求端发来的业务协商请求， 分析出需要处理的目标业务， 及协商要求， 触发协商过程控制单元 362进行后 续过程。 该协商要求可以包括：

( 1 )对协商结果的处理要求： 通过对协商结果的处理要求对协商结果进行 处理找出最终业务。 例如： 取出满足要求的业务中最快反馈的一个； 或者， 取 出满足要求业务中某需求单项最高的一个。 过滤掉反馈时间超过 10秒的结果。

( 2 )对协商过程的要求： 通过对协商过程的要求对协商过程进行控制。 例 如： 所有目标业务协商需在 10秒内完成， 否则算作失败。

协商过程控制单元 362用于按照业务协商请求中的协商要求（对这整个协 商过程的要求， 例如： 要求在 10秒内完成）及目标业务集合， 生成针对目标业 务的协商要求， 启动目标业务协商单元 363 进行对目标业务的协商。 当收到所 有目标业务的反馈结果（或按照协商要求规定结束） 时， 触发协商结果生成单 元 364生成最终结果。

目标业务协商单元 363用于与目标业务所在的业务路由器 35进行交互来进 行协商， 并将协商结果反馈给协商结果生成单元 364。

协商结果生成单元 364用于接收目标业务协商单元 363反馈的协商结果， 按照协商要求对这些协商结果进行处理， 选择出最终的目标业务并反馈给协商 请求端。

协商代理 36还可以包括： 协商要求维护单元 365 , 用于维护及管理协商要 求。

上述协商代理 36 , 协商请求分析单元 361接收协商请求端例如： 业务组合 引擎 33或业务路由器 35发送的业务协商请求， 协商过程控制单元 362根据该 业务协商请求生成目标业务协商请求， 目标业务协商单元 363与业务路由器 35 进行协商， 最后协商结果生成单元 364生成业务协商结果反馈至协商请求端， 实现了业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商 请求端的需求， 提高了业务协商的成功率及用户的满意度。

图 5为本发明实施例业务路由器的一种结构图。 如图 5所示， 本发明实施 例中的业务路由器 35是业务网络上的已有设备， 主要负责路由业务层消息， 基 于业务的业务网络地址将相应的业务层消息路由到目的地。 同时业务路由器 35 还可以对业务层消息进行格式转换， 对业务层消息进行修改和监控， 以满足多 样化的需求。

业务路由器 35还可以基于给定的业务描述路由到一个符合给定的业务类别 且完全符合给定的端口参数的业务。 本发明实施例中的业务路由器 35还具有业 务协商功能。 该业务描述可以包括业务类别和端口参数。

其中， 业务协商功能包括：

1 ) 查询业务需求的功能；

2 )判断业务需求的功能；

3 )发布业务需求并接收反馈的功能。

业务路由器 35可以包括： 协商处理系统， 用于接收并处理协商代理 36发 送目标业务的业务协商请求， 并向协商代理 36反馈针对该业务协商请求的协商 结果。

该协商处理系统可以包括： 协商处理单元 351、 业务需求分析单元 352、 需 求查询单元 353、 需求发布接收单元 354、 基 功能单元 355和业务注册处理单 元 356。

其中， 协商处理单元 351用于接收协商代理 36发送的目标业务协商请求， 并控制业务路由器 35上的协商过程， 包括： 调用业务需求分析单元 352对目标 业务协商请求进行分析， 调用需求查询单元 353对周边业务网络设备进行查询， 调用需求发布接收单元 354进行新需求发布。 同时还需要判断是否有业务需求 不能被识别， 如果有不能识别的业务需求则触发需求发布接收单元 354进行需 求发布。 当所有的业务需求都可以被识别的时候， 协商处理单元 351 还可以判断所 有的业务需求是否被满足， 并生成目标业务协商结果消息发送到协商代理 36。

针对一个目标业务， 可以有多种业务需求作为协商的依据， 这些业务需求 包括以下一种或几种：

( 1 )业务采用的交互协议， 业务采用的交互协议在业务网络上可以存储于 业务目录 31或注册中心 32上。

( 2 ) 业务的性能信息， 该业务的性能信息包括： 消息从业务路由器 35发 出到业务提供端 37收到该消息的平均时长、 消息从业务路由器 35发出到业务 路由器 35收到响应的平均时长、 业务路由器 35与该业务提供端 37的网络负载 情况和网络繁忙状况中的一种或几种。 该业务的性能信息由承载网服务质量管 理器 34上报。

( 3 )业务限定， 该业务限定包括： 业务设定的可访问时间段或总访问次数。 该业务限定由业务自身上报， 注册中心 32维护。

( 4 )业务的自身状态， 该业务的自身状态包括： 业务本身繁忙状态或处理 能力。 该业务的自身状态应当查询业务提供端 37的响应接口。

( 5 ) 业务的提供商信息、 业务的接口信息， 存储于业务目录 31中。

( 6 )业务的可靠性， 该业务的可靠性为业务针对业务请求的平均访问错误 率。 该业务的可靠性应当由承载网服务质量管理器 34提供。

( 7 )可用情况， 该可用情况指业务的在线状态， 应当向业务提供端 37请 求获取。

( 8 )安全性， 该安全性包括： 提供商级别或联通区域安全等级。 该安全性 应当存于注册中心 32。

( 9 )价格： 价格 /每次， 或价格 /每流量。 价格应当存于注册中心 32。

在协商过程中， 协商处理单元 351 还需要根据目标业务协商请求中的协商 要求决定协商过程。 该协商要求可以包括：

( 1 )对协商结果的处理要求： 通过对协商结果的处理要求对协商结果进行 处理找出最终业务。 例如： 取出满足要求的业务中最快反馈的一个； 或者， 取 出满足要求业务中某需求单项最高的一个。 过滤掉反馈时间超过 10秒的结果。

( 2 )对协商过程的要求： 通过对协商过程的要求对协商过程进行控制。 例 如： 所有目标业务协商需在 10秒内完成， 否则算作失败。

业务需求分析单元 352用于接收协商处理单元 351发送的目标业务协商请 求， 并分析目标业务协商请求中的业务需求、 分析业务需求对应的功能设备， 以判断需要查询的周边业务网络的功能设备。 并触发协商处理单元 351 向对应 的功能设备进行请求。

由于承载网服务质量管理器 34维护业务的承载网服务质量相应的需求， 在 网络上是固定的不可动态增加， 对于各个业务均相同。 业务目录 31维护的是业 务的端口信息、 业务提供商等固定的信息， 是业务固定的静态信息。 而注册中 心 32维护的是业务的状态、 地址等信息， 是业务的动态信息。 因此业务需求分 析单元 352分析业务需求对应的功能设备时， 可以先分析承载网服务质量管理 器 34, 然后是业务目录 31 , 剩下的业务需求全部由注册中心 32处理。

需求查询单元 353用于接收协商处理单元 351发送的查询请求， 对相应的 周边业务网络的功能设备进行并行的查询处理， 并反馈查询结果给协商处理单 元 351。

当需求查询单元 353查询到注册中心 32时， 针对相应的需求， 如果注册中 心 32反馈的是业务需求的查询端口信息而非业务需求的结果。需求查询单元 353 需要根据业务需求的查询端口信息查询业务提供端对应的查询端口， 获取相应 的业务需求的结果。

当需求查询单元 353 确定某些业务需求在周边业务网络的功能设备无法被 识别时， 通知协商处理单元 351 , 并中断其它查询工作。 由协商处理单元 351向 需求发布接收单元 354发送新业务需求发布要求。

需求发布接收单元 354用于接收协商处理单元 351发送的新业务需求发布 要求， 进行业务需求发布。 以供后续业务提供端提供相应的针对新业务需求的 结果， 并可以支持新业务需求。

基石出功能单元 355是负责业务路由器 35基石出功能的单元， 主要处理业务层 消息路由、 消息转换等功能。

业务注册处理单元 356是业务路由器 35中负责注册业务的功能单元。 在业 务网络上， 在业务第一次接入业务网络的时候会给该业务分配该业务归属的业 务路由器 35 , 该业务需要将自身的相关信息注册到业务路由器 35上。 其中， 该 业务自身的相关信息包括： 业务的业务网络地址到业务的物理承载网络地址的 映射关系。

上述业务路由器， 协商处理单元 351接收协商代理 36发送的目标业务协商 请求， 调用业务需求分析单元 352对目标业务协商请求进行分析， 调用需求查 询单元 353对周边业务网络设备进行查询， 在需求查询单元 353确定存在不可 识别的业务需求之后， 由协商处理单元 351触发需求发布接收单元 354发布该 不可识别的业务需求。 由于业务具有多样性的特点， 相应地， 业务需求也是多 样性的， 本实施例中， 业务路由器 35通过发布业务需求， 使初期不可识别的业 务需求后期可被发现及识别， 从而使业务协商不需要限定在固定的业务需求上。

图 6为本发明实施例注册中心的结构图。 如图 6所示， 本发明实施例中， 注册中心 32还增加存储了业务的一些动态需求信息， 包括目前该业务可识别的 需求信息及对应值， 该对应值可以是具体数值， 也可是查询该需求的端口。

注册中心 32上存储的信息可以如表 1所示，

表 1

注册中心 32上存储的信息还可以如表 2所示,

表 2

如图 6所示， 本发明实施例的注册中心包括： 注册单元 321、 更新单元 322 和查询单元 323 , 其中，

注册单元 321用于处理业务的信息， 将业务的信息注册到注册中心 32上； 更新单元 322用于更新现有业务的信息。

查询单元 323用于查询现有业务的信息。

图 7为本发明实施例业务提供端的结构图。 如图 7所示， 为本发明实施例 提供了一种业务提供端， 包括： 注册单元 371、 需求管理单元 372和新需求提交 单元 373 , 其中，

注册单元 371用于将业务信息注册到业务路由器 35上。 还可用于注册业务 需求的查询端口信息。

需求管理单元 372用于管理及才艮据新的业务需求生成结果信息。

新需求提交单元 373用于将新的业务需求提交到业务路由器 35。

图 8为本发明实施例另一种业务协商方法的流程图。 如图 8所示， 本发明 实施例提供了另一种业务协商方法， 包括：

步骤 S801 , 协商代理 36接收到协商请求端发送过来的业务协商请求。该协 商请求端可以为： 业务组合引擎 33或业务路由器 35。

步骤 S802, 协商代理 36处理接收的业务协商请求，按照该业务协商请求携 带的协商要求生成目标业务集合的目标业务协商请求。

步骤 S803 ,协商代理 36发送目标业务协商请求到目标业务所归属的业务路 由器 35 (多个）上。

步骤 S804, 业务路由器 35分析目标业务协商请求， 分析出需要查询的功能 设备， 并向这些需要查询的功能设备发送需求查询请求， 确定有不可识别的业 务需求。 这些功能设备包括业务目录 31、 注册中心 32、 承载网服务质量管理器 34和业务提供端 37。

业务路由器 35 确定有不可识别的业务需求具体可以为： 在业务路由器 35 查询了所有需要查询的功能设备之后， 如果没有查询到针对该业务需求的信息， 则该业务路由器 35确定该业务需求不可识别。

步骤 S805 , 业务路由器 35发布上述不可识别的业务需求， 并将发布的业务 需求通知业务提供端 37 , 业务提供端 37生成针对该业务需求的结果信息。

步骤 S806, 业务路由器 35确定所有业务需求均被处理， 则生成目标业务协 商结果信息。 所有业务需求均被处理具体可以为： 查询到了该业务需求的结果 信息或者发布了新的业务需求。

步骤 S807 , 业务路由器 35向协商代理 36反馈生成的协商结果信息。

步骤 S808 , 协商代理 36按照协商要求对反馈的协商结果信息进行处理， 选 择出最终的目标业务， 生成业务协商结果。

步骤 S809, 协商代理 36发送生成的业务协商结果至协商请求端。

上述业务协商方法， 协商代理 36接收协商请求端例如： 业务组合引擎 33 或业务路由器 35发送的业务协商请求， 根据该业务协商请求生成目标业务协商 请求，并与业务路由器 35进行协商，最后生成业务协商结果反馈至协商请求端， 实现了业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商 请求端的需求， 提高了业务协商的成功率及用户的满意度。

图 9为本发明实施例协商代理处理业务协商请求的流程图。 如图 9所示， 本发明实施例提供了一种协商代理处理业务协商请求， 具体包括：

步骤 S901 ,协商代理 36的协商请求分析单元 361接收协商请求端发送的业 务协商请求。 该协商请求端可以为业务组合引擎 33或业务路由器 35。 步骤 S902, 协商请求分析单元 361分析出需要处理的目标业务集合及协商 要求。

步骤 S903 , 协商请求分析单元 361触发协商过程控制单元 362开始进行业 务协商。

步骤 S904, 协商过程控制单元 362按照业务协商请求中的协商要求及目标 业务集合， 生成针对目标业务的目标业务协商请求。

步骤 S905 , 协商过程控制单元 362发送目标业务协商请求到目标业务协商 单元 363进行对目标业务的协商。

步骤 S906, 目标业务协商单元 363按照目标业务协商请求的要求与目标业 务所归属的业务路由器 35进行交互并接收业务路由器 35反馈的目标业务协商 结果消息。 由于目标业务有多个， 所以目标业务协商单元 363 需要和多个业务 路由器 35进行交互。

步骤 S907 , 目标业务协商单元 363将目标业务的协商结果反馈给协商结果 生成单元 364。 目标业务协商单元 363可以在收到全部的目标业务的协商结果后 统一反馈， 或者单个反馈目标业务的协商结果。

步骤 S908 , 目标业务协商单元 363接收到了所有目标业务路由器 35的反馈 后向协商过程控制单元 362发送完成通知。

步骤 S909, 协商过程控制单元 362收到所有目标业务的反馈结果时， 触发 协商结果生成单元 364生成最终结果。 其中， 触发协商结果生成单元 364生成 最终结果的过程也可以按照协商要求的规定发起， 例如： 等待 10秒， 然后触发 协商结果生成单元 364处理所有反馈了结果的目标业务， 这时步骤 S909可以在 步骤 S908之前执行。

步骤 S910, 协商结果生成单元 364接收目标业务协商单元 363反馈的协商 结果， 按照协商要求对这些协商结果进行处理， 选择出最终的目标业务， 生成 业务协商结果。

步骤 S911 , 协商结果生成单元 364发送业务协商结果给协商请求端。 在本实施例中， 当需要使用到协商要求时， 可以到协商要求维护单元 365 查询协商要求。

上述协商代理处理业务协商请求的流程， 协商代理 36的协商请求分析单元 361接收协商请求端发送的业务协商请求，协商过程控制单元 362根据该业务协 商请求生成目标业务协商请求， 目标业务协商单元 363与业务路由器 35进行协 商， 最后协商结果生成单元 364生成业务协商结果反馈至协商请求端， 实现了 业务网络支持多种业务需求下的业务协商， 满足了业务交互， 以及协商请求端 的需求， 提高了业务协商的成功率及用户的满意度。

图 10为本发明实施例业务路由器协商过程的流程图。 如图 10所示， 本发 明实施例业务路由器协商过程， 具体包括：

步骤 S 1001 ,业务路由器 35的协商处理单元 351接收协商代理 36发送的目 标业务协商请求。

步骤 S 1002,协商处理单元 351请求业务需求分析单元 352进行业务需求分 步骤 S 1003 ,业务需求分析单元 352分析出该目标业务协商请求中携带的业 务需求、 分析业务需求对应的功能设备， 以确定需要查询的周边网络的功能设 备。 并将查询结果反馈给协商处理单元 351。

步骤 S 1004,协商处理单元 351按照业务需求分析单元 352的分析结果调用 需求查询单元 353对周边网络的功能设备进行查询。

步骤 S1005 , 需求查询单元 353向承载网服务质量管理器 34查询业务路由 器 35到业务之间的承载网上的服务质量信息。

步骤 S 1006 , 承载网服务质量管理器 34返回查询结果。

步骤 S1007 , 需求查询单元 353向业务目录 31查询业务功能相关的信息， 该业务功能相关的信息包括业务提供商、 业务类别和业务接口描述信息。

步骤 S 1008 , 业务目录 31返回查询结果。

步骤 S 1009, 需求查询单元 353向注册中心 32查询业务动态信息。 步骤 S1010, 注册中心 32返回查询结果。

其中， 步骤 S1005〜步骤 S1010是并行发起的， 并且根据业务需求分析单元 352的分析结果可以省略相应的步骤。

步骤 S1011, 需求查询单元 353判断注册中心 32反馈的是业务需求的查询 端口信息还是业务需求的结果。 如果返回的是业务需求的查询端口信息， 则执 行步骤 S1012, 否则直接执行步骤 S1014。

步骤 S1012, 需求查询单元 353按照查询端口信息向业务提供端 37的相应 查询端口发送查询请求。

步骤 S1013, 业务提供端 37反馈相应的查询结果。

步骤 S1014, 需求查询单元 353判断是否存在无法被周边设备识别的业务需 求（例如： 某业务需求不可以被承载网服务质量管理器 34识别； 或者， 某业务 需求不在所有周边设备的可支持的业务需求列表上）。 如果有则执行步骤 S1015〜步骤 S1021, 否则执行步骤 S1022。

步骤 S1015, 需求查询单元 353向协商处理单元 351发送通知消息， 告知协 商处理单元 351 有不支持的业务需求， 该通知消息包含有不支持的业务需求的 标记。

步骤 S1016, 协商处理单元 351处理协商要求， 确定针对该协商要求的处理 方法。 例如： 当指定某协商要求为可选而不是必选时， 则可以不做处理。 如果 某协商要求为必选， 则执行步骤 S1017 ~步骤 S1018。

步骤 S1017, 协商处理单元 351反馈目标业务协商结果给协商代理 36, 该 目标业务协商结果为该目标业务不符合要求， 因为关键需求不可识别。

步骤 S1018, 协商处理单元 351向需求查询单元 353发送终止查询消息， 终 止正在进行的并行查询工作， 以避免无谓的系统资源浪费。

步骤 S1019,优选地， 协商处理单元 351向需求发布接收单元 354发布新增 业务需求的请求。

步骤 S1020, 需求发布接收单元 354进行业务需求发布， 以供后续业务提供 端 37提供相应的针对新业务需求的结果， 从而可以支持新的业务需求。

步骤 S1021 ,需求发布接收单元 354反馈需求发布结果给协商处理单元 351。 步骤 S 1022, 需求查询单元 353判断出是否所有的业务需求查询工作完毕。 没完就继续等待， 否则执行步骤 S 1023。

步骤 S 1023 , 需求查询单元 353通知协商处理单元 351所有处理完毕， 并反 馈所有业务需求的查询结果。

步骤 S 1024,协商处理单元 351按照协商要求对所有业务需求的查询结果进 行处理， 判断该目标业务是否满足协商要求。

步骤 S1025 , 协商处理单元 351反馈目标业务协商结果给协商代理 36。 该 目标业务协商结果可以为目标业务符合协商要求， 或者当目标业务不满足业务 需求时， 该目标业务协商结果可以为目标业务不符合协商要求。

上述业务路由器的协商过程， 协商处理单元 351接收协商代理 36发送的目 标业务协商请求， 调用业务需求分析单元 352对目标业务协商请求进行分析， 调用需求查询单元 353对周边业务网络设备进行查询， 在需求查询单元 353确 定存在不可识别的业务需求之后， 由协商处理单元 351 触发需求发布接收单元 354发布该不可识别的业务需求。 本实施例中， 业务路由器 35进行业务协商， 通过发布业务需求， 使初期不可识别的业务需求后期可被发现及识别， 从而使 业务协商不需要限定在固定的业务需求上。

图 11为本发明实施例发布新业务需求的一种流程示意图。如图 11所示，本 发明实施例发布新业务需求， 包括：

步骤 S1101 ,业务路由器 35的需求发布接收单元 354接收协商处理单元 351 发送的发布新增业务需求的请求消息。

步骤 S 1102,需求发布接收单元 354将相应的新增业务需求的信息更新到对 应的注册中心 32上， 等待业务提供端 37的查询。

步骤 S 1103 , 注册中心 32反馈更新成功。

其中， 步骤 S 1102〜步骤 S 1103为优选方案， 新增业务需求的信息也可存储 于业务路由器 35上。

步骤 S 1104 , 需求发布接收单元 354反馈新业务需求的发布情况给协商处理 单元 351。

步骤 S 1105 , 业务提供端 37的需求管理单元 372检测其归属的业务路由器 35 上是否发布了针对该业务路由器 35自身的新增业务需求。 具体可以为： 由器 35上是否发布了针对该业务路由器 35自身的新增业务需求；

b )业务提供端 37可以事先向业务路由器 35订阅业务需求改动通知， 在业务 需求改动之后， 会有相应的通知消息通知业务提供端 37其归属的业务路由器 35 上是否发布了针对该业务路由器 35自身的新增业务需求。

步骤 S1106, 业务路由器 35查询注册中心 32是否有针对新增业务的需求。 步骤 S1107 , 注册中心 32反馈新增业务需求。

步骤 S1108 , 业务路由器 35将新增业务需求的信息发送给业务提供端 37。 步骤 S1109 , 业务提供端 37生成针对新增业务需求的结果信息。 该新增业务 需求的结果信息可以是对应新增业务需求的具体数值结果， 也可以是对应新增 业务需求的查询端口信息。

步骤 S1110 , 业务提供端 37向业务路由器 35的需求发布接收单元 354发送新 增业务需求的协商结果。

步骤 S1111 , 业务路由器 35的需求发布接收单元 354更新新增业务需求的协 商结果到注册中心 32上。

步骤 S 1112, 注册中心 32反馈更新结果。

步骤 S 1113 ,需求发布接收单元 354通知协商处理单元 351该新增业务需求 已经被支持。

步骤 S 1114,协商处理单元 351判断该次协商过程是否完成，如果没有完成， 则将该业务需求标记为可识别并进行后续的协商过程。 这样， 便于在较为长期 的协商过程中， 对新增的业务需求快速响应。 其中， 步骤 S1113和步骤 S1114为可选步骤。

本实施例通过发布业务需求， 使初期不可识别的业务需求后期可被发现及 识别， 从而使业务协商不需要限定在固定的业务需求上。

图 12为本发明实施例发布新业务需求的另一种流程示意图。 如图 12所示， 本发明实施例发布新业务需求， 包括：

步骤 S1201,业务提供端 37向其归属的业务路由器 35的业务注册处理单元 356发送注册业务的需求通知端口信息。

步骤 S1202, 业务注册处理单元 356注册上述信息到注册中心 32。

步骤 S 1203, 注册中心 32反馈注册成功。

步骤 S1204, 业务路由器 35向业务提供端 37反馈注册成功。

步骤 S1205,业务路由器 35的需求发布接收单元 354接收协商处理单元 351 发送的新增业务需求的发布请求。

步骤 S1206, 需求发布接收单元 354查询注册中心 32, 查询目标业务对应 的需求通知端口信息。

步骤 S1207, 注册中心 32对需求通知端口信息进行反馈。

步骤 S1208, 需求发布接收单元 354向业务提供端 37的需求通知端口发送 新增业务需求的通知信息。

步骤 S1209, 业务提供端 37生成针对新增业务需求的结果信息。

其中， 该新增业务需求的结果信息可以是对应业务需求的具体数值结果， 也可以是对应的需求查询端口。

步骤 S1210,业务提供端 37向业务路由器 35的需求发布接收单元 354发送 新增业务需求对应的结果信息。

步骤 S1211, 业务路由器 35的需求发布接收单元 354更新该新增业务需求 对应的结果信息到注册中心 32上。

步骤 S1212, 注册中心 32反馈更新结果。

步骤 S1213,需求发布接收单元 354通知协商处理单元 351该业务需求已经 被支持。

步骤 S1214,协商处理单元 351判断该次协商过程是否完成，如果没有完成， 则将该业务需求标记为可识别并进行后续的协商过程。 这样， 便于在较为长期 的协商过程中， 对新增的业务需求快速响应。

其中， 步骤 S1213和步骤 S1214为可选步骤。

本实施例通过发布业务需求， 使初期不可识别的业务需求后期可被发现及 识别， 从而使业务协商不需要限定在固定的业务需求上。

图 13为本发明实施例端口关系示意图。 如图 13所示， 本发明实施例中， 端口关系如下：

( 1 )协商请求端和协商代理 36之间的端口： 协商端口 II；

( 2 )协商代理 36和业务路由器 35之间的端口： 目标业务协商端口 12;

( 3 ) 业务路由器 35和业务目录 31之间的端口： 查询端口 13;

( 4 )业务路由器 35和注册中心 32之间的端口： 查询端口 14和需求注册端 口 15;

( 5 ) 业务路由器 35和业务提供端 37之间的端口： 查询端口 16;

( 6 )业务路由器 35和承载网服务质量管理器 34之间的端口： 查询端口 17 和需求发布接收端口 18。

下面对上述各端口进行详细描述。

1、 协商端口 II

协商端口的入口消息为： 业务协商请求， 包括以下信息：

1 )备选的多个目标业务的业务网络地址或业务的标识， 用来寻址到目标业 务所归属的业务路由器 35的信息；

2 ) 业务需求， 包括：

a )确定要处理的目标业务的范围， 可以支持对 1 )指定的多个目标业务进 行差异化处理， 例如： All就是全部处理， 或者， 指定需要处理的目标业务的序 号； b ) 业务需求的名字， 例如： 价格、 稳定性、 交互协议或提供商等； c )对业务需求的处理模式， 例如： 严格匹配、 高于或低于等；

d )对业务需求的要求值；

3 )协商要求， 例如： 多久时间之内返回协商结果是有效的， 选出完全满足 的或者是选出最快回复的， 可以包括以下两个部分：

a )对协商结果的处理要求： 通过该要求对协商结果进行处理找出最终的目 标业务。 例如： 选择满足要求的业务中最快反馈的一个作为最终的目标业务； 或者， 取出满足要求的业务中某需求单项最高的一个作为最终的目标业务； 或 者， 过滤掉反馈时间超过 10秒的协商结果； 或者， 在多个满足要求的业务中按 照优先级陣选协商结果。

b )对协商过程的要求： 通过该要求对协商过程进行控制， 该协商过程指从 协商代理 36收到业务协商请求到协商代理 36返回协商结果的过程。 例如： 所 有目标业务的协商需在 10秒内完成， 否则算作失败， 即没有满足要求的业务。

一个以 XML ( extensible Marked Language, 可扩展标记语言 )描述的业务 协商请求可以如下所示：

<?xml version:" 1.0" encoding="UTF-8" ?>

<ServiceNegotiationRequest>

<AddressSet>

<address id="l">Service Address 1 </address>

<address id="2">Service Address2</address>

<address id="3">Service Address3</address>

</AddressSet>

<DemandForServices>

<demand id=" 1 " scope="all" pattern="match" isOptional="false"> <item>protocol</item>

<value>soap</value>

</demand>

<demand id="2" scope="all" pattern="lower" isOptional="false"> <item>price</item>

<value> 10</value>

</demand>

<demand id="3" scope="all" pattern="higher" isOptional="true">

<item>stability</item>

<value>98</value>

</demand>

</DemandForServices>

<ClaimForNegotiation>

<ClaimForProcess>

<claim id=" 1 " type="time limit">90</claim>

</ClaimForProcess>

<ClaimForResult>

<claim id=" 1 " type="priority list">2,l,3</claim>

</ClaimForResult>

</ClaimForNegotiation>

</ServiceNegotiationRequest>

上述业务协商请求描述了以下内容：

a )业务地址： 三个备选的目标业务；

b ) 业务需求： 针对所有的业务均要求在协议上为 SOAP ( Simple Object Access Protocol,简单对象访问协议）、价格上低于 10和稳定性上高于 98(可选）； c )协商要求： 对协商过程要求在 90 内返回协商结果， 对协商结果要求按 照指定的 （2, 1 , 3 )优先级^ %选最优的。

协商端口 II的出口消息为业务协商结果， 包括以下信息：

1 ) 最终业务的业务网络地址或业务的标识；

2 )协商日志， 用来记录协商过程的一些信息， 例如： 协商总处理时间， 采 用的协商策略等。

一个以 XML描述的业务协商结果如下所示： <?xml version:" 1.0" encoding="UTF-8" ?>

<ServiceNegotiationResult>

<address>service address l</address>

<log>time=40; suitable candidate=2;</log>

</ServiceNegotiationResult>

上述业务协商结果描述了以下内容：

a )最终业务地址： 1个；

b )协商日志： 记录了协商过程占用的时长为 40, 满足需求的备选业务有两 个（最终选择了一个）。

2、 目标业务协商端口 12

目标业务协商端口 12的入口消息为目标业务协商请求， 包括以下信息： 1 ) 目标业务的业务网络地址或业务的标识， 用来寻址到目标业务所归属的 业务路由器 35的信息， 业务路由器 35根据该业务网络地址或业务的标识， 路 由到需要处理的目标业务归属的业务路由器；

2 )对业务的需求信息， 这些信息是协商代理 36根据业务协商请求中的业 务需求信息中对应该目标业务而抽取的需求信息， 业务路由器 35根据该需要处 理的目标业务的业务需求信息确定需要查询的功能设备；

3 )对协商的要求， 对协商的要求是协商代理 36根据业务协商请求中的协 商要求进行的处理生成和目标业务相关的要求。 也包括两个部分：

a )对目标业务协商结果的处理要求， 业务路由器 35 根据该处理要求对目 标业务协商结果进行处理；

b )对目标协商过程的要求， 业务路由器 35根据对目标协商过程的要求对 协商过程进行控制。

一个以 XML描述的目标业务协商请求如下所示：

<?xml version:" 1.0" encoding="UTF-8" ?>

<TargetServiceNegotiationRequest>

<address>service Address l</address> <DemandForServices>

<demand id=" 1 " scope="all" pattern="match" isOptional="false"> <item>protocol</item>

<value>soap</value>

</demand>

<demand id="2" scope="all" pattern="lower" isOptional="false"> <item>price</item>

<value> 10</value>

</demand>

<demand id="3" scope="all" pattern="higher" isOptional="true">

<item>stability</item>

<value>98</value>

</demand>

</DemandForServices>

<ClaimForNegotiation>

<ClaimForProcess>

<claim id=" 1 " type="time limit">90</claim>

<claim id="2" type="if have new req then false">true</claim> <claim id="3" type="publish new req">true</claim>

</ClaimForProcess>

<ClaimForResult />

</ClaimForNegotiation>

</TargetServiceNegotiationRequest>

上述目标业务协商请求描述了以下内容：

a )业务地址： 目标业务的业务网络地址；

b )对业务的需求： 要求采用 SOAP协议、 价格上低于 10和稳定性上高于 98 (可选）；

c )对协商的要求： 对协商过程要求在 70 秒内返回协商结果， 如果有业务 路由器不可识别的业务需求， 那么就直接反馈业务不符合要求， 如果有新的业 务需求则发布。

目标业务协商端口 12的出口消息为目标业务协商结果， 包括以下信息：

1 )协商结果标识， 标识出协商的结果及信息， 例如： 目标业务是否可以满 足对业务的需求， 如果不满足， 是由于有业务需求不满足， 还是业务需求不能 被识别。 在业务需求不能被识别的时候， 其它业务需求是否继续处理完， 如果 处理完是否全部满足要求；

2 ) 目标业务针对业务需求所对应的值（可选）；

3 ) 日志： 用来记录协商过程的一些信息， 例如： 协商处理时间， 查询的周 边设备标记等。

一个以 XML描述的目标业务协商结果如下所示：

<?xml version:" 1.0" encoding="UTF-8" ?>

<TargetServiceNegotiationResult>

<Result> 101 </Result>

<DemandDetail>

<demand id=" 1 ">

<item>protocol</item>

<value>soap</value>

</demand>

<demand id="2">

<item>price</item>

<value>5</value>

</demand>

<demand id="3">

<item>stability</item>

<value>99</value>

</demand>

</DemandDetail>

</TargetServiceNegotiationResult> 上述目标业务协商结果描述了以下内容：

a)协商结果标识： 101, 101表示目标业务不满足要求， 有新的业务需求， 终止了其它业务需求的查询， 且新的业务需求被发布；

b) 目标业务对应值： 价格 =5, 稳定性 = 99 (可选）；

c)协商日志： 记录了协商过程占用的时长为 40 秒， 查询的周边设备为业 务目录、 业务注册中心和业务提供端。

3、 需求注册端口 15

需求注册端口 15的入口消息包括：

a)业务的标识： 要注册的端口所对应的业务网络地址或标识；

b )接收需求通知消息的端口的信息。

需求注册端口 15的出口消息包括： 该业务需求注册的结果（成功或失败）。

4、 需求发布接收端口 18

需求发布接收端口 18的总入口消息包括：

a)发布新增需求请求；

b) 业务的标识： 目标业务的网络地址或标识；

c) (可选）新业务需求信息： 不能识别的新业务需求信息的名称， 对业务 需求的描述信息。

需求发布接收端口 18的总出口消息包括：

a)新需求对应结果信息通知；

b) 业务的标识： 目标业务的网络地址或标识；

c)新业务需求信息的对应结果信息， 该信息可以是对应需求的具体数值结 果， 也可以是对应的需求查询端口。

需求发布接收端口 18的新需求查询消息和订阅新增需求改动消息， 按照实 际的实现方案 （轮询方式或订阅通知方式）可以任选一个。

a)轮询方式

入口消息包括： 业务的标识， 要查询的业务所对应的业务网络地址或标识； 出口消息包括： 对新业务的需求信息描述， 这些信息是目前业务路由器 35 不能识别的目标业务的需求信息； 以及， 业务需求的描述信息 （可选）。

b )订阅通知方式

入口消息包括：

1 ) 业务的标识， 要订阅的业务所对应的业务网络地址或标识；

2 )接收改动通知的端口地址： 当有新增业务需求的时候会触发业务路由器 35发送变动通知给需求发布接收端口 18;

3 ) (可选） 需求类别： 用来指定所订阅的业务的类别， 只有指定类别的业 务才通知；

4 ) (可选） 需求排除类别： 用来指定所排除订阅的业务的类别， 只有非指 定类别的业务才通知。

出口消息包括： 订阅结果（成功或失败）。

下面通过一具体实施例对本发明的实施过程进行介绍。

在业务网络上， 用户 A请求执行组合服务"基于位置的地图服务"， 业务内 容为显示出针对用户当前位置的周边地图信息， 业务网络的业务组合引擎 33负 责执行该服务， 在组合业务执行过程中需要先调用位置服务后调用地图服务。 在该组合业务的描述中关于地图服务有一个正选服务 Google的地图服务（正常 流程执行中调用的服务）， 同时还有两个备选服务： 百度的地图服务和神龙地图 的地图服务。 在执行中业务组合引擎 33获知 Google的地图服务正在维护， 需 要使用备选服务进行替代。 则由于有两个备选服务， 业务组合引擎 33想确定目 前最合适的一个备选服务替代正选服务。 图 14为本发明实施例的具体实施例的 流程图。 如图 14所示， 具体包括：

步骤 S1401 , 业务组合引擎 33向协商代理 36发送业务协商请求。

该业务协商请求中包括两个备选服务的业务网络地址、 包括对这些服务的 需求信息： 要求采用 SOAP协议、 要求价格都要低于 10、 要求稳定性要高于 98 (可选）。 同时针对第二个服务（神龙地图）单独设定了安全级别要求为： 高于 2。 对 协商的要求的规定为： 对协商过程的要求 90秒内完成， 对各个业务需求的协商 优先级设定为价格优先， 然后是交互协议， 最后是稳定性。

采用 XML描述的业务协商请求如下所示：

<input>

<AddressSet>

<address id=" 1 ">baidu map address</address>

<address id="2">shenlong map address</address>

</AddressSet>

<DemandforS ervers>

<demand id="l" scope="all" pattern="match" isOptional="false"> <item>protocol</item>

<value>soap</value>

</demand>

<demand id="2" scope="all" pattern="lower" isOptional="false">

<item>price</item>

<value> 10</value>

</demand>

<demand id="3" scope="all" pattern="higher" isOptional="true"> <item>stability</item>

<value>98</value>

</demand>

<demand id="3" scope="2" pattern="higher" isOptional=" false "> <item>SecurityLevel</item>

<value>2</value>

</demand>

</DemandforServers>

<DemandforNegotiation>

<DemandforProcess> <demand id=" 1 " type="timeLimit">90</demand>

</DemandforProcess>

<DemandforResult>

<demand id="l " type="priorityList">2, 1 ,3^</demand>

</DemandforResult>

</DemandforNegotiation>

</input>

步骤 S1402, 协商代理 36分析该业务协商请求并生成目标业务协商请求。 协商代理 36分析处理该业务协商请求， 针对两个目标业务分别生成目标业 务协商请求： 包括目标业务的业务网络地址和针对目标业务的需求信息。 其中， 针对目标业务的需求信息与步骤 S1401 中设置的需求信息相同。 针对目标业务 的协商要求， 时间限制在 70秒内， 如果有不可识别的业务需求则按照业务不符 合， 立即返回， 同样的也可以设置发布业务后等待业务反馈， 直到超出时间限 制， 如有不可识别的业务需求则发布， 反馈结果中要求有查询的设备和具体的 查询值信息。

例如： 针对百度地图的目标业务协商请求具体可以为：

<input>

<Address>baidu map address</Address>

<DemandforS ervers>

<demand id="l " pattern="match" isOptional="false">

<item>protocol</item>

<value>soap</value>

</demand>

<demand id="2" pattern="lower" isOptional="false">

<item>price</item>

<value> 10</value>

</demand>

<demand id="3" pattern="higher" isOptional="true"> vaue98/vauell <v<>

yesab/eitmtilititm <><>

¾deadd3s〇oamemn i itinlt A>==""""

/deadmn <>

5vaue0/vaue 2l1l <><>

Av

<>

<>

<>

deadmn i4 tmn < <>=""

yp¾qdeadd3eubsNeweme/deadmn i tlihRtmn <><>="" -"

ypqdeaddeaveNeweeaseue/deadmn i2 t ifHRThnFltTmn <v<>="" - "

ypdeaddee70/deadmn i ttimLimimn <><>==" --- - eadoocessDmnfrPr <>

geado¾eoaoDmnftitin <>

/eadosevesDmnfrTr <v

/deadmn <>

vaue98/vauell <v<> yesaetmtttm <><> </demand>

<demand id="4" pattern="higher" isOptional="false">

<item>SecurityLevel</item>

<value>2</value>

</demand>

</DemandforServers>

<DemandforNegotiation>

<DemandforProcess>

<demand id=" 1 " type="timeLimit">70</demand>

<demand id="2" type="ifHaveNewReqThenFalse">true</demand>

<demand id="3" type="publishNewReq">true</demand>

<demand id="4" type="ResultDetail">Req Result</demand>

</DemandforProcess>

<DemandforResult/>

</DemandforNegotiation>

</input>

针对神龙地图业务的目标业务协商请求与针对百度地图的目标业务协商请 求的不同之处在于有额外的安全等级方面的要求。

步骤 S 1403 , 业务路由器 35 处理目标业务协商请求， 查询周边功能 设备。

百度地图和神龙地图所分别归属的业务路由器 35收到目标业务协商请求。 下面以神龙地图的归属路由器 35为例， 百度地图业务的目标业务协商请求的处 理与之类似。 业务路由器 35分析目标业务协商请求， 分析出需要查询的周边设 备， 并向这些周边设备发送业务需求的查询请求。 这些周边设备包括业务目录 31、 注册中心 32、 承载网服务质量管理器 34、 业务提供端 37。 本实施例中对业 务的需求包括协议、 价格、 稳定性和安全等级， 因此业务路由器 35确定需要查 询业务目录 31 (协议）、 承载网服务质量管理器 34 (稳定性）、 注册中心 32 (价 格和安全等级）。 在弱路由的实现方案中， 去上述周边设备的哪个单元查询也可 以在目标业务协商请求中规定好。

以下为发送到业务目录 31 的查询消息， 向承载网服务质量管理器 34发送 的查询消息与之类似：

<ServiceID>shenlong map</ServiceID>

<QuerySet>

<query type="protocol"/>

</QuerySet>

反馈消息：

<QueryResult>

<result type="protocol"> soap </result>

</QueryResult>

发送到注册中心 32的查询消息：

<ServiceID>shenlong map</ServiceID>

<QuerySet>

<query type="price"/>

<query type="securityLevel"/>

</QuerySet>

反馈消息：

<QueryResult>

<result type=" securityLevel" pattern="interface"> shenlongMap.REQinterface.securityLevel</result>

<result type=" price">UNKNOW</result>

</QueryResult>

发送到注册中心 32的查询消息查询价格和安全级别， 但是存储于注册中心 32中的安全级别并非是安全级别的结果信息，而是业务提供端 37相应的需求查 询接口。 而价格信息并没有存储于注册中心 32中， 所以查询结果为 UNKNOW。

针对安全级别信息由于查询到的信息为查询接口， 业务路由器 35会按照接 口信息生成相应的查询请求向对应的 Λ良务端口进行查询： 查询请求消息：

<ServiceID>shenlong map</ServiceID>

<InterfaceAdress> shenlongMap.REQinterface.securityLeve /InterfaceAdress > 反馈消息：

<QueryResult>

<result">3</result>

<info>This is security Level of shenlong map</info>

<log>...</log>

</QueryResult>

步骤 S1404, 业务路由器 35发布新的业务需求。

业务路由器 35 判断出有不可识别的新业务需求（价格）， 按照协商要求中 规定的

<demand id="3 " type="publishNewReq">true</demand> 进行新业务需求的发布过程。

业务需求的第一种发布过程： 业务路由器 35将不可识别的业务需求发布到 注册中心 32上。

<ServiceID>shenlong map</ServiceID>

<wanted>

<item type="price"/>

</wanted >

业务提供端 37查询到有针对该业务的新业务需求发布，获取该新业务需求， 然后生成相应的结果， 并反馈到业务路由器 35。

<ServiceID>shenlong map</ServiceID>

<matched>

<item type="price">5<item>

</matched>

业务路由器 35更新该结果信息到注册中心 32上。

业务需求的第二种发布过程： 业务路由器 35查询注册中心 32上业务注册 的需求通知接口。

<ServiceID>shenlong map</ServiceID>

反馈消息：

<ServiceID>shenlong map</ServiceID>

<REQNotificationInterface>

shenlongMap.REQNotificationlnterface

</REQNotificationInterface >

业务路由器 35按照该需求通知端口通知相应的需求信息并等待业务反馈。 典型消息：

<ServiceID>shenlong map</ServiceID>

<InterfaceAdress>shenlongMap.REQNotificationInterface</InterfaceAdress> <REQ>

<Type>price<Type>

<Description>...<Description>

</REQ>

反馈消息：

<REQ>

<item type="price">5</item>

</REQ>

业务路由器 35更新该信息到注册中心 32上。

步骤 S1405 , 业务路由器 35反馈目标业务协商结果。

根据协商要求， 当有不可识别的业务需求时， 则反馈该业务为不符合业务 需求。 而反馈的目标业务协商结果要包括设备和需求的值。

<demand id="2" type="ifHaveNewReqThenFalse">true</demand> <demand id="4" type="ResultDetail">Device and Req</demand> 神龙地图反馈的目标业务协商结果为： 目标业务不符合要求， 而且有需求 不被识别， 并发布了相应的需求， 针对需求的结果值列出。

<output> <Result> 102(false/ publish new requirement/return immediately) </Result> <Detail>

<demand>

<item id=" 1 " type="protocol">soap</item>

<item id="2" type="price">5</item>

<item id="3" type=" stability ">99</item>

<item id="4" type="SecurityLevel">UNKNOW</item> </demand>

</Detail>

<Log>time=40;Device=Service Quality, Service Catalog, Service

Register,Service;</Log>

</output>

如果在协商要求中设定为发布新的需求并等待业务提供端 37的反馈， 则业 务路由器 35会等待业务提供端 37的反馈直到超出协商要求的时间， 才反馈协 商结果。 如果在这个时间内业务提交了满足业务的需求则反馈结果为：

<Result>201 (success/ publish new requirement/waiting)</Result> 或者，

<Result>202(false/ publish new requirement/waiting)</Result> 百度地图反馈的目标业务协商结果为： 目标业务符合要求。 所有需求均识 别。

<output>

<Result>l 01 (success) </Result>

<Detail>

<demand>

<item id=" 1 " type="protocol">soap</item>

<item id="2" type="price">7</item>

<item id="3" type=" stability ">99</item>

</demand>

</Detail> <Log>time=50;Device=Service Quality, Service Catalog, Service

Register;</Log>

</output>

步骤 S1406, 协商代理 36处理目标业务协商结果， 生成业务协商结果。 协商代理 36判断出百度地图满足协商要求， 而神龙地图不满足， 则反馈百 度地图作为最终协商结果。 如果二者均满足， 则按照协商要求中的优先级选择 优先级最高的一个， 或者选择反馈最快的一个。

<Output>

<Candidate>

<address>baidu map address</address>

</Candidate>

<Log>time=40; suitable candidates=l ; </Log>

</output>

本发明实施例提供一种业务协商方法、 系统和设备， 根据业务网络中业务 路由器的特点， 使业务网络可以支持多种业务需求下的业务协商功能， 满足业 务交互的需求， 以及业务协商请求者的需求， 协商出最适合业务， 提高了业务 使用的成功率及用户的满意度。

由于业务具有多样性的特点， 相应地， 针对业务协商的需求也是多样性的， 本发明实施例通过发布业务需求， 使初期不可识别的需求可被后期发现及识别 而不需要限定在固定的业务需求上。

本发明除上述实现方式外， 还可将协商代理的功能集成到业务组合引擎上， 将协商代理的功能集成到现有业务网络中的业务组合引擎上， 成为一种增强型 的业务组合引擎， 可以实现对组合过程中调用的子业务进行协商。

另外， 还可将协商代理的功能集成到现有业务网络中的业务路由器上， 使 其成为增强型的业务路由器， 支持在智能路由或其它场合下的对业务进行协商 的功能。 在这种方式下， 具有协商代理功能的增强型业务路由器担当本发明实 施例中协商代理的角色， 与其他业务路由器进行交互以实现本发明实施例的方 案。

本发明实施例中， 还可将注册中心的功能集成到现有业务网络的业务路由 器上， 这时原有注册于注册中心上的信息均注册到业务路由器上， 由集成了注 册中心功能的业务路由器上维护相应的信息， 成为增强型的业务路由器， 从而 本发明实施例中注册、 查询、 更新和维护信息的实体均为业务路由器而非注册 中心。 业务路由器与注册中心交互的功能也将在业务路由器自身上实现。

本发明实施例中， 还可将注册中心管理的信息和业务目录管理的信息进行 融合或者交换。 在现有的业务网络上， 注册中心维护业务的动态信息， 以及非 功能性的一些信息， 这些非功能性的一些信息包括业务状态和业务物理网络地 址信息。 而业务目录维护业务的功能性信息， 该业务的功能性信息包括接口描 述信息和交互协议信息等。

在进行组网部署时， 可以按照各种业务需求（例如： 降低成本）将注册中 心管理的信息和业务目录管理的信息进行融合， 或者将注册中心管理的信息和 业务目录管理的信息进行交换。 在这种方案下， 业务路由器或协商代理在根据 业务需求信息确定需要查询的功能设备时， 就需要进行相应的更改， 例如： 某 些向业务目录查询的业务需求可能需要转向注册中心查询， 而某些向注册中心 查询的业务需求可能需要转向业务目录查询。

本发明实施例中， 由于网络部署及设备兼容的原因， 在业务路由器的处理 能力有限的情况下， 可以更改为弱路由方案， 具体为：

业务路由器不对业务需求的查询结果进行任何处理， 而是直接将业务需求 的查询结果反馈给协商代理， 由协商代理进行协商处理过程。 这种方案下， 本 发明实施例相应的更改为， 业务路由器的入口消息更改： 没有对协商结果的要 求部分， 业务路由器的出口消息更改， 不再是协商结果， 而是直接反馈业务需 求的对应值。

本发明实施例中， 主要是由业务路由器主控进行对业务的各种需求的查询 和判断。 作为备选方案， 由于业务网络的部署的特殊性（例如： 业务路由器不 一定可以访问到业务目录）， 则一种方案是协商代理代替业务路由器进行相应的 查询和判断功能（例如： 由协商代理查询业务目录）。 这时， 业务路由器仅仅处 理消息路由的基本功能， 业务路由器处理的功能全部由协商代理处理。 具体地， 由协商代理获得包含多个业务的业务协商请求， 根据该业务协商请求获得多个 业务的业务需求信息， 以及针对多个业务的业务需求信息的需求处理结果， 然 后根据该需求处理结果选择目标业务， 生成与上述业务协商请求对应的业务协 商结果， 并发送该业务协商结果至业务提供端。

通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发明 可以通过硬件实现， 也可以借助软件加必要的通用硬件平台的方式来实现。 基 于这样的理解， 本发明的技术方案可以以软件产品的形式体现出来， 该软件产 品可以存储在一个非易失性存储介质 （可以是 CD-ROM, U盘， 移动硬盘等） 中， 包括若干指令用以使得一台计算机设备（可以是个人计算机， 服务器， 或 者网络设备等）执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图， 附图中的模 块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进 行分布于实施例的装置中， 也可以进行相应变化位于不同于本实施例的一个或 多个装置中。 上述实施例的模块可以合并为一个模块， 也可以进一步拆分成多 个子模块。

上述本发明实施例序号仅仅为了描述， 不代表实施例的优劣。

以上公开的仅为本发明的几个具体实施例， 但是， 本发明并非局限于此， 任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

权 利 要 求

1、 一种业务协商方法， 其特征在于， 包括：

获得包含多个业务的业务协商请求；

根据所述业务协商请求获取所述多个业务的需求处理结果；

根据所述需求处理结果选择目标业务， 生成与所述业务协商请求对应的业 务协商结果并反馈。

2、 如权利要求 1所述的业务协商方法， 其特征在于， 所述根据所述业务协 商请求获取所述多个业务的需求处理结果具体包括；

根据所述业务协商请求向维护所述多个业务的业务需求信息的一个或多个 功能设备发送需求查询请求；

接收所述一个或多个功能设备根据所述需求查询请求反馈的需求处理结 果。

3、 如权利要求 2所述的业务协商方法， 其特征在于， 所述根据所述业务协 商请求向维护所述多个业务的业务需求信息的一个或多个功能设备发送需求查 询请求具体包括：

根据所述业务协商请求判断需要查询的含有所述多个业务的业务需求信息 的一个或多个功能设备；

向所述功能设备发送需求查询请求。

4、 如权利要求 1或 2所述的业务协商方法， 其特征在于， 所述根据所述需 求处理结果选择目标业务具体包括：

根据所述业务协商请求或系统预设策略处理所述需求处理结果， 选择出目 标业务。

5、 如权利要求 3所述的业务协商方法， 其特征在于， 所述向所述功能设备 发送需求查询请求具体包括：

查询所述多个业务的服务质量信息；

查询所述多个业务的业务功能信息； 和 /或 查询所述多个业务的业务动态信息。

6、 如权利要求 1所述的业务协商方法， 其特征在于， 所述根据所述业务协 商请求获取所述多个业务的需求处理结果具体包括；

向所述多个业务归属的业务路由器发送需求查询请求；

接收所述多个业务归属的业务路由器针对所述需求查询请求反馈的需求处 理结果。

7、 如权利要求 6所述的业务协商方法， 其特征在于， 所述多个业务归属的 业务路由器仅转发需求查询请求给功能设备， 并接收和转发所述功能设备针对 所述需求查询请求所反馈的需求查询结果。

8、 如权利要求 7所述的业务协商方法， 其特征在于， 在所述多个业务归属 的业务路由器仅转发需求查询请求给功能设备之前， 进一步包括：

所述多个业务归属的业务路由器根据所述需求查询请求， 确定需要查询的 含有所述多个业务的业务需求信息的一个或多个功能设备。

9、 如权利要求 8所述的业务协商方法， 其特征在于， 所述多个业务归属的 业务路由器仅转发需求查询请求给功能设备具体包括：

查询所述多个业务的服务质量信息；

查询所述多个业务的业务功能信息； 和 /或

查询所述多个业务的业务动态信息。

10、 如权利要求 3或 8所述的业务协商方法， 其特征在于， 进一步包括： 才艮据所述功能设备反馈的需求处理结果确定存在不可识别的业务需求， 并 发布所述不可识别的业务需求。

1 1、 如权利要求 1所述的业务协商方法， 其特征在于， 所述根据所述业务 协商请求获取所述多个业务的需求处理结果具体包括：

向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息， 使 得所述多个业务归属的业务路由器针对所述业务需求信息反馈需求处理结果。

12、 如权利要求 1 1所述的业务协商方法， 其特征在于， 所述多个业务归属 的业务路由器针对所述业务需求信息反馈需求处理结果具体包括： 所述多个业务归属的业务路由器根据所述多个业务的业务需求信息， 确定 需要查询的功能设备， 并向所述功能设备发送需求查询请求， 所述需求查询请 求携带所述业务需求信息；

接收所述功能设备根据所述需求查询请求反馈的需求处理结果； 反馈所述需求处理结果至协商代理。

13、 如权利要求 1 1所述的业务协商方法， 其特征在于， 所述向所述多个业 务归属的业务路由器请求所述多个业务的业务需求信息具体包括：

协商代理从所述业务协商请求中获得需要处理的目标业务；

向所述多个业务归属的业务路由器发送目标业务协商请求， 请求所述需要 处理的目标业务的业务需求信息。

14、 如权利要求 13所述的业务协商方法， 其特征在于， 所述多个业务归属 的业务路由器包括所述需要处理的目标业务归属的业务路由器；

所述多个业务归属的业务路由器针对所述业务需求信息反馈需求处理结果 具体包括：

所述需要处理的目标业务归属的业务路由器根据所述目标业务的业务需求 信息， 确定需要查询的功能设备， 并向所述功能设备发送需求查询请求；

接收所述功能设备针对所述需求查询请求反馈的需求处理结果； 根据所述需求处理结果生成与所述目标业务协商请求对应的目标业务协商 结果；

反馈所述目标业务协商结果至所述协商代理。

15、 如权利要求 14所述的业务协商方法， 其特征在于， 所述根据所述需求 处理结果选择目标业务， 生成与所述业务协商请求对应的业务协商结果具体包 括：

所述协商代理根据所述目标业务协商结果选择目标业务， 生成与所述业务 协商请求对应的业务协商结果。

16、 如权利要求 12或 14所述的业务协商方法， 其特征在于， 所述向所述 功能设备发送需求查询请求具体包括：

所述多个业务归属的业务路由器向承载网服务质量管理器发送需求查询请 求， 查询服务质量信息；

向业务目录发送需求查询请求， 查询业务功能信息； 和 /或

向注册中心发送需求查询请求， 查询业务动态信息。

17、 如权利要求 16所述的业务协商方法， 其特征在于， 所述业务动态信息 包括业务需求对应的具体数值或者业务需求对应的查询端口信息；

当查询到的业务动态信息为所述业务需求对应的查询端口信息时，还包括： 所述多个业务归属的业务路由器根据所述查询端口信息向业务提供端的相 应查询端口查询所述业务需求对应的具体数值。

18、 如权利要求 12或 14所述的业务协商方法， 其特征在于， 还包括： 所述多个业务归属的业务路由器根据所述功能设备反馈的需求处理结果确 定存在不可识别的业务需求， 并发布所述不可识别的业务需求。

19、 如权利要求 1、 6或 11所述的业务协商方法， 其特征在于， 所述业务 协商请求包括以下信息中的一种或几种：

所述多个业务的业务网络地址、 所述多个业务的业务标识、 所述多个业务 的业务需求信息、 所述目标业务的选择要求和对协商过程的要求。

20、 如权利要求 1、 6、 11所述的业务协商方法， 其特征在于， 所述业务协 商结果包括以下信息中的一种或几种：

所述目标业务的业务网络地址、 所述目标业务的业务标识和协商日志。

21、 如权利要求 13所述的业务协商方法， 其特征在于， 所述目标业务协商 请求包括以下信息中的一种或几种：

所述需要处理的目标业务的业务网络地址、 所述需要处理的目标业务的业 务的标识、 所述需要处理的目标业务的业务需求信息、 对目标业务协商结果的 处理要求和对目标协商过程的要求。

22、 如权利要求 14所述的业务协商方法， 其特征在于， 所述目标业务协商 结果包括以下信息中的一种或几种：

协商结果标识、 协商日志和所述业务需求对应的具体数值。

23、 如权利要求 16所述的业务协商方法， 其特征在于， 所述注册中心可以 集成在业务路由器上， 所述方法中注册中心处理的功能可由业务路由器处理。

24、 如权利要求 1、 2、 3、 6或 8所述的业务协商方法， 其特征在于， 所述 需求处理结果为所述多个业务的业务需求信息的查询结果。

25、 一种业务需求的发布方法， 其特征在于， 包括：

获取目标业务的业务需求信息， 根据所述业务需求信息确定存在不可识别 的业务需求；

发布所述不可识别的业务需求。

26、 如权利要求 25所述的业务需求的发布方法， 其特征在于， 所述根据所 述业务需求信息确定存在不可识别的业务需求具体包括：

获取所能支持的业务需求信息， 根据查询结果确定存在不可识别的业务需 求； 或者

根据所述业务需求信息， 确定需要查询的功能设备， 并向所述功能设备发 送携带所述业务需求信息的需求查询请求， 接收所述功能设备针对所述需求查 询请求反馈的需求查询结果， 根据所述需求查询结果确定存在不可识别的业务 需求。

27、 如权利要求 25所述的业务需求的发布方法， 其特征在于， 所述发布所 述不可识别的业务需求具体包括：

将所述不可识别的业务需求的信息发布到目标业务归属的业务路由器上或 所述业务路由器对应的注册中心上或业务目录上， 由业务提供端获得针对所述 业务的不可识别的业务需求的信息；

接收所述业务提供端发送的结果信息， 所述结果信息是所述业务提供端针 对所述不可识别的业务需求生成的结果信息； 将所述结果信息更新到所述业务路由器或所述注册中心或所述业务目录。

28、 如权利要求 27所述的业务需求的发布方法， 其特征在于， 所述发布所 述不可识别的业务需求具体包括：

查询注册中心或业务目录， 获得业务注册时提供的需求通知端口， 通过所 述需求通知端口将所述不可识别的业务需求通知业务提供端；

接收所述业务提供端发送的结果信息， 所述结果信息是所述业务提供端针 对所述不可识别的业务需求生成的结果信息；

将所述结果信息更新到所述业务路由器或所述注册中心或业务目录。

29、 如权利要求 27或 28所述的业务需求的发布方法， 其特征在于， 所述 结果信息包括： 所述不可识别的业务需求对应的具体数值结果或者所述不可识 别的业务需求对应的查询端口信息。

30、 一种业务协商系统， 其特征在于， 包括： 协商代理，

所述协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协 商请求获取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业 务， 生成与所述业务协商请求对应的业务协商结果并反馈。

31、如权利要求 30所述的业务协商系统，其特征在于，还包括业务路由器， 所述业务路由器， 用于接收和转发所述协商代理发送的需求查询请求， 并 接收和转发需求处理结果给所述协商代理。

32、如权利要求 30所述的业务协商系统，其特征在于，还包括业务路由器， 所述业务路由器， 用于接收所述协商代理的请求， 向所述协商代理反馈针 对所述多个业务的业务需求信息的需求处理结果。

33、 如权利要求 30所述的业务协商系统， 其特征在于， 还包括以下设备中 的一种或多种：

业务目录， 用于维护业务功能信息， 所述业务功能信息包括业务提供商信 息、 业务类别信息或业务接口描述信息；

注册中心， 用于维护业务动态信息， 所述业务动态信息包括业务标识或业 务网络地址， 以及所述业务标识或业务网络地址对应的物理网络地址； 业务组合引擎， 用于发起业务协商请求；

承载网服务质量管理器， 用于管理底层承载网络的服务质量功能， 包括检 测物理链路层的联通状态、 传输速率、 延时和抖动信息中的一种或几种。

34、 如权利要求 30所述的业务协商系统， 其特征在于， 所述协商代理具体 为一个独立的功能实体， 或者集成在业务组合引擎上， 或者集成在所述业务路 由器上。

35、 如权利要求 33所述的业务协商系统， 其特征在于， 所述注册中心具体 为一个独立的功能实体， 或者集成在所述业务路由器上。

36、 如权利要求 31所述的业务协商系统， 其特征在于， 所述业务路由器除 路由业务层消息之外的功能可以集成到所述协商代理上。

37、 一种协商代理， 其特征在于， 包括：

协商请求分析单元， 用于获得包含多个业务的业务协商请求， 分析出需要 处理的目标业务， 及协商要求；

目标业务协商单元， 用于向所述需要处理的目标业务归属的业务路由器请 求所述目标业务的业务需求信息， 接收所述目标业务归属的业务路由器针对所 述目标业务的业务需求信息反馈的需求处理结果；

协商结果生成单元， 用于根据所述需求处理结果选择目标业务， 生成与所 述业务协商请求对应的业务协商结果并反馈。

38、 如权利要求 37所述的协商代理， 其特征在于， 还包括：

协商过程控制单元， 用于根据所述协商请求分析单元获得的业务协商请求 中的协商要求及需要处理的目标业务， 生成目标业务协商请求。

39、 如权利要求 37所述的协商代理， 其特征在于， 还包括：

协商要求维护单元， 用于维护及管理协商要求。

40、 一种业务路由器， 其特征在于， 包括：

协商处理系统， 用于接收并处理目标业务的业务协商请求， 并反馈针对所 述业务协商请求的协商结果。

41、 如权利要求 40所述的业务路由器， 其特征在于， 所述协商处理系统包 括：

协商处理单元， 用于接收协商代理发送的请求， 并控制业务路由器上的协 商过程；

业务需求分析单元， 用于接收所述协商处理单元发送的请求， 分析所述请 求中的业务需求信息， 根据所述业务需求信息确定需要查询的功能设备， 并触 发所述协商处理单元发送携带所述业务需求的需求查询请求；

需求查询单元， 用于接收所述协商处理单元发送的需求查询请求， 向所述 功能设备发送需求查询请求， 并接收所述功能设备反馈的需求处理结果， 触发 所述协商处理单元反馈所述需求处理结果至所述协商代理。

42、 如权利要求 41所述的业务路由器， 其特征在于，

所述需求查询单元还用于根据所述需求处理结果确定存在不可识别的业 务， 在确定存在不可识别的业务之后， 通知所述协商处理单元；

所述协商处理单元还用于发送新业务需求发布要求；

所述协商处理系统还包括：

需求发布接收单元， 用于接收所述协商处理单元发送的新业务需求发布要 求， 发布所述不可识别的业务需求。

43、 一种业务组合引擎， 其特征在于， 包括： 协商代理，

所述协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协 商请求获取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业 务， 生成与所述业务协商请求对应的业务协商结果并反馈。

44、 一种业务路由器， 其特征在于， 包括： 协商代理，

所述协商代理， 用于获得包含多个业务的业务协商请求； 根据所述业务协 商请求获取所述多个业务的需求处理结果； 根据所述需求处理结果选择目标业 务， 生成与所述业务协商请求对应的业务协商结果并反馈。