CN101686173A - 一种业务协商方法、***和设备 - Google Patents

一种业务协商方法、***和设备 Download PDF

Info

Publication number
CN101686173A
CN101686173A CN200810148830A CN200810148830A CN101686173A CN 101686173 A CN101686173 A CN 101686173A CN 200810148830 A CN200810148830 A CN 200810148830A CN 200810148830 A CN200810148830 A CN 200810148830A CN 101686173 A CN101686173 A CN 101686173A
Authority
CN
China
Prior art keywords
business
demand
service
negotiation
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN200810148830A
Other languages
English (en)
Inventor
石晓旻
李彦
唐杰
马其锋
陈珊
王环
常恒
刘见锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN200810148830A priority Critical patent/CN101686173A/zh
Priority to EP09817243A priority patent/EP2330847A4/en
Priority to PCT/CN2009/074106 priority patent/WO2010037329A1/zh
Publication of CN101686173A publication Critical patent/CN101686173A/zh
Priority to US13/072,251 priority patent/US20110238840A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5006—Creating or negotiating SLA contracts, guarantees or penalties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5058—Service discovery by the service manager
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5083—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to web hosting

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例公开了一种业务协商方法、***和设备，所述业务协商方法包括：获得包含多个业务的业务协商请求；向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息；接收所述多个业务归属的业务路由器针对所述业务需求信息反馈的需求处理结果；根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果并反馈。本发明实施例实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。

Description

一种业务协商方法、***和设备
技术领域
本发明实施例涉及网络通信技术领域，特别涉及一种业务协商方法、***和设备。
背景技术
随着电信网络技术和用户需求的发展，业务的提供需要多样化，而当业务的多样性达到一定程度时，不同业务之间的交互能力又制约了运营商进一步发展更为复杂的业务。用户迫切需要一个完整的业务供应链而不是单独访问一系列独立的服务子***。
为了顺应业务管理的需求，业界普遍以业务为中心重新对运营商的各类资源进行整合，统一抽象出网络的各种能力和资源开放给上层业务使用，通过架设叠加在现网上的业务网络设备实现不同业务之间的交互和管理。业务网络通过业务路由器、业务组合引擎和业务目录等核心设备来负责管理和控制业务的交互、消息路由、消息检测、业务的组合和业务描述。
随着业务网络上注册的业务的快速增加，业务之间的交互、以及访问日益复杂，同时用户对业务体验的要求也进一步增强，体验差的、不可靠的业务被用户所诟病。业务访问不稳定、不可靠、死板无法个性化的问题日益暴露出来，成为业务使用及管理上的顽疾。同时由于构成组合业务的子业务也存在不可靠、不稳定的情况，这使得业务体验在组合业务的使用中更为突出。目前业务的种类千差万别，对业务的需求也多种多样。传统的对传输网络的控制及调控方式已经无法满足上述的这些要求。
发明内容
本发明实施例提供一种业务协商方法、***和设备，以实现业务网络支持多种业务需求下的业务协商。
为达到上述目的，本发明实施例一方面提供一种业务协商方法，包括：
获得包含多个业务的业务协商请求；
向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息；
接收所述多个业务归属的业务路由器针对所述业务需求信息反馈的需求处理结果；
根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果并反馈。
另一方面，本发明实施例还提供一种业务需求的发布方法，包括：
获取目标业务的业务需求信息，根据所述业务需求信息确定存在不可识别的业务需求；
发布所述不可识别的业务需求。
再一方面，本发明实施例还提供一种业务协商***，包括：业务路由器和协商代理，
所述协商代理，用于接收包含多个业务的业务协商请求，向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息，接收所述业务路由器针对所述业务需求信息反馈的需求处理结果，根据所述需求处理结果选择目标业务，生成并反馈与所述业务协商请求对应的业务协商结果；
所述业务路由器，用于接收所述协商代理的请求，向所述协商代理反馈针对所述多个业务的业务需求信息的需求处理结果。
再一方面，本发明实施例还提供一种协商代理，包括：
协商请求分析单元，用于获得包含多个业务的业务协商请求，分析出需要处理的目标业务，及协商要求；
目标业务协商单元，用于向所述需要处理的目标业务归属的业务路由器请求所述目标业务的业务需求信息，接收所述目标业务归属的业务路由器针对所述目标业务的业务需求信息反馈的需求处理结果；
协商结果生成单元，用于根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果并反馈。
再一方面，本发明实施例还提供一种业务路由器，包括：
协商处理***，用于接收并处理目标业务的协商请求，并反馈针对所述协商请求的协商结果。
本发明实施例通过协商代理接收协商请求端的业务协商请求，根据该业务协商请求与业务路由器进行协商，最后生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例一种业务协商方法的流程图；
图2为本发明实施例一种业务需求的发布方法的流程图；
图3为本发明实施例业务协商***的结构图；
图4为本发明实施例协商代理的结构图；
图5为本发明实施例业务路由器的一种结构图；
图6为本发明实施例注册中心的结构图；
图7为本发明实施例业务提供端的结构图；
图8为本发明实施例另一种业务协商方法的流程图；
图9为本发明实施例协商代理处理业务协商请求的流程图；
图10为本发明实施例业务路由器协商过程的流程图；
图11为本发明实施例发布新业务需求的一种流程示意图；
图12为本发明实施例发布新业务需求的另一种流程示意图；
图13为本发明实施例端口关系示意图；
图14为本发明实施例的具体实施例的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例提供一种业务协商方法，基于业务网络实现，是对业务层的两个或多个备选业务在多种业务需求上进行的协商，这里的多种业务需求包括但不限于业务的功能性信息(例如：接口描述)、动态需求(例如：价格，安全等级等)或承载网服务质量(例如：时延、稳定性)。本发明实施例提供的一种业务协商方法还可以满足动态变化的业务需求。本发明实施例还可以支持不可识别的业务需求，可以满足业务多样化的业务需求。
如图1所示，为本发明实施例一种业务协商方法的流程图，包括：
步骤S101，获得包含多个业务的业务协商请求。
本发明实施例中，协商代理接收协商请求端发送的业务协商请求，该业务协商请求包含多个业务的业务需求信息。
步骤S102，向多个业务归属的业务路由器请求所述多个业务的业务需求信息。
步骤S103，接收多个业务归属的业务路由器针对上述业务需求信息反馈的需求处理结果。
其中，多个业务归属的业务路由器针对业务需求信息反馈需求处理结果具体可以为：
多个业务归属的业务路由器根据多个业务的业务需求信息，确定需要查询的功能设备，并向所述功能设备发送携带业务需求信息的需求查询请求。接收所述功能设备根据该需求查询请求反馈的需求处理结果，并反馈该需求处理结果至协商代理。
本发明实施例中，多个业务归属的业务路由器确定需要查询的功能设备，并向确定的功能设备发送携带业务需求信息的需求查询请求具体可以为：
向承载网服务质量管理器发送需求查询请求，查询多个业务归属的业务路由器与业务承载网之间的服务质量检测信息；和/或，
向业务目录发送需求查询请求，查询业务功能信息，该业务功能信息包括业务提供商信息、业务类别信息或业务端口描述信息；和/或，
向注册中心发送需求查询请求，查询业务动态信息。该业务动态信息包括业务需求对应的具体数值结果，或者，业务需求对应的查询端口信息。
当查询到的业务动态信息为业务需求对应的查询端口信息时，在向注册中心查询业务动态信息之后，多个业务归属的业务路由器还可以根据该查询端口信息向业务提供端的相应查询端口查询该业务需求对应的具体数值结果。
步骤S104，根据需求处理结果选择目标业务，生成与业务协商请求对应的业务协商结果并反馈。
在接收到多个业务归属的业务路由器反馈的需求处理结果之后，协商代理根据该需求处理结果选择目标业务，并生成与接收的业务协商请求对应的业务协商结果，发送该业务协商结果至协商请求端。
在另一种实现方式中，协商代理从业务协商请求中获得需要处理的目标业务，向多个业务归属的业务路由器发送目标业务协商请求，请求需要处理的目标业务的业务需求信息。需要处理的目标业务归属的业务路由器根据目标业务的业务需求信息，确定需要查询的功能设备，并向所述功能设备发送携带业务需求信息的需求查询请求。然后，需要处理的目标业务归属的业务路由器接收上述功能设备针对该需求查询请求反馈的需求处理结果，根据该需求处理结果生成目标业务协商请求对应的目标业务协商结果，并反馈目标业务协商结果至协商代理。然后，协商代理根据目标业务协商结果选择目标业务，生成与该业务协商请求对应的业务协商结果。
本发明实施例中，多个业务归属的业务路由器可以根据功能设备反馈的需求处理结果确定存在不可识别的业务需求，并发布不可识别的业务需求。
本实施例中，可以不改变现有的业务路由器的功能，使业务路由器仅仅处理消息路由的基本功能，本实施例中业务路由器处理的功能全部由协商代理处理。具体地，由协商代理获得包含多个业务的业务协商请求，根据该业务协商请求获得所述多个业务的业务需求信息，以及针对所述多个业务的业务需求信息的需求处理结果，然后根据该需求处理结果选择目标业务，生成与上述业务协商请求对应的业务协商结果，并发送该业务协商结果至业务提供端。
另外，本实施例中，注册中心的功能也可以集成到现有的业务路由器上，使其成为增强型业务路由器，这时可以在集成了注册中心功能的业务路由器上查询业务动态信息等信息。
本实施例中，业务协商请求包括以下信息中的一种或几种：
a)多个业务的业务网络地址或业务标识，协商代理根据该业务网络地址或业务标识，路由到多个业务归属的业务路由器；
b)多个业务的业务需求信息，协商代理根据该多个业务的业务需求信息获取多个业务的相关业务需求；
c)目标业务的选择要求，协商代理根据该选择要求选择目标业务；
d)对协商过程的要求，协商代理根据该要求对协商过程进行控制。
业务协商结果包括以下信息中的一种或几种：
a)所述目标业务的业务网络地址或业务标识，协商代理将所述目标业务的业务网络地址或业务标识返回至协商请求端；
b)协商日志，所述协商日志包括协商过程的总处理时间，或采用的协商策略。
目标业务协商请求包括以下信息中的一种或几种：
a)所述需要处理的目标业务的业务网络地址或业务的标识，业务路由器根据该业务网络地址或业务的标识，路由到需要处理的目标业务归属的业务路由器；
b)所述需要处理的目标业务的业务需求信息，业务路由器根据该需要处理的目标业务的业务需求信息确定需要查询的功能设备；
c)对所述目标业务协商结果的处理要求，业务路由器根据该处理要求对目标业务协商结果进行处理；
d)对目标协商过程的要求，业务路由器根据对目标协商过程的要求对协商过程进行控制。
目标业务协商结果包括以下信息中的一种或几种：
a)协商结果标识，所述协商结果标识指示协商结果，以及所述协商结果对应的信息，协商代理根据协商结果确定业务需求是否被满足；
b)协商日志，所述协商日志包括协商处理时间和所述查询的功能设备标识；
c)业务需求对应的具体数值结果。
上述业务协商方法，协商代理接收协商请求端的业务协商请求，根据该业务协商请求与业务路由器进行协商，最后生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
如图2所示，为本发明实施例一种业务需求的发布方法的流程图，具体包括：
步骤S201，获取目标业务的业务需求信息，根据该业务需求信息确定存在不可识别的业务需求。
其中，根据该业务需求信息确定存在不可识别的业务需求具体可以为：
查询目标业务归属的业务路由器所能支持的业务需求信息，根据查询结果确定存在不可识别的业务需求；或者，
根据业务需求信息，确定需要查询的功能设备，并向确定的功能设备发送携带业务需求信息的需求查询请求，接收该确定的功能设备针对该需求查询请求反馈的需求查询结果，根据需求查询结果确定存在不可识别的业务需求。
步骤S202，发布不可识别的业务需求。具体可以为：
目标业务归属的业务路由器将不可识别的业务需求的信息发布到该业务路由器上或该业务路由器对应的注册中心上，由业务提供端获得针对该业务提供端自身的不可识别的业务需求的信息；并接收所述业务提供端发送的结果信息，该结果信息是所述业务提供端针对所述不可识别的业务需求生成的结果信息；然后，将上述结果信息更新到业务路由器或注册中心上。或者，
目标业务所归属的业务路由器查询注册中心，获得业务注册时提供的需求通知端口，通过该需求通知端口将不可识别的业务需求通知业务提供端；接收所述业务提供端发送的结果信息，该结果信息是所述业务提供端针对所述不可识别的业务需求生成的结果信息；然后将上述结果信息更新到业务路由器或注册中心上。
其中，上述结果信息包括：不可识别的业务需求对应的具体数值；或者，不可识别的业务需求对应的查询端口信息。
上述业务需求的发布方法，业务路由器通过发布业务需求，使初期不可识别的业务需求后期可被发现及识别，从而使业务协商不需要限定在固定的业务需求上。
如图3所示，为本发明实施例业务协商***的结构图，包括：业务目录31、注册中心32、业务组合引擎33、承载网服务质量管理器34、业务路由器35、协商代理36和业务提供端37。其中，协商代理36是本发明实施例新增的功能设备。
业务目录31是业务网络上的现有设备，在逻辑上是全网唯一的，负责维护网络上可见业务的端口、提供商等功能性信息(静态的)。
注册中心32是业务网络上的现有设备，在逻辑上是与业务路由器35一一对应的，用于维护所有归属于该业务路由器35的业务的信息。这些业务的信息包括归属业务的业务标识或业务网络地址，以及对应的物理网络地址。一个业务在注册到业务路由器35时，提供该业务的信息。
业务组合引擎33，用于发起业务协商请求，为协商请求端。
承载网服务质量管理器34是业务网络上的现有设备，用于管理底层承载网络的服务质量功能，包括检测物理链路层的联通状态、传输速率、延时、抖动等信息。
业务路由器35，业务路由器35是业务网络上的已有设备，主要负责路由业务层消息，基于业务的业务网络地址将相应的业务层消息路由到目的地，在接收到协商代理36的请求之后，向协商代理36反馈针对多个业务的业务需求信息的需求处理结果。
协商代理36用于接收协商请求端例如：业务组合引擎33或者业务路由器35发送的包含多个业务的业务协商请求，协商代理36根据该业务协商请求的内容向备选的多个目标业务归属的业务路由器35发起业务协商，请求所述多个业务的业务需求信息，并根据业务路由器35反馈的需求处理结果选择出符合协商要求的目标业务，生成与所述业务协商请求对应的业务协商结果，并反馈给协商请求端。
业务提供端37是业务网络上的现有设备，用于管理及维护运行在其上的业务。
上述业务协商***，协商代理36接收协商请求端例如：业务组合引擎33或业务路由器35发送的业务协商请求，根据该业务协商请求生成目标业务协商请求，并与业务路由器35进行协商，最后生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
如图4所示，为本发明实施例协商代理的结构图，本发明实施例中的协商代理36包括协商请求分析单元361、协商过程控制单元362、目标业务协商单元363和协商结果生成单元364。
其中，协商请求分析单元361，用于处理协商请求端发来的业务协商请求，分析出需要处理的目标业务，及协商要求，触发协商过程控制单元362进行后续过程。该协商要求可以包括：
(1)对协商结果的处理要求：通过对协商结果的处理要求对协商结果进行处理找出最终业务。例如：取出满足要求的业务中最快反馈的一个；或者，取出满足要求业务中某需求单项最高的一个。过滤掉反馈时间超过10s的结果。
(2)对协商过程的要求：通过对协商过程的要求对协商过程进行控制。例如：所有目标业务协商需在10s内完成，否则算作失败。
协商过程控制单元362，用于按照业务协商请求中的协商要求(对这整个协商过程的要求，例如：要求在10秒内完成)及目标业务集合，生成针对目标业务的协商要求，启动目标业务协商单元363进行对目标业务的协商。当收到所有目标业务的反馈结果(或按照协商要求规定结束)时，触发协商结果生成单元364生成最终结果。
目标业务协商单元363，用于与目标业务所在的业务路由器35进行交互来进行协商，并将协商结果反馈给协商结果生成单元364。
协商结果生成单元364，用于接收目标业务协商单元363反馈的协商结果，按照协商要求对这些协商结果进行处理，选择出最终的目标业务并反馈给协商请求端。
协商代理36还可以包括：协商要求维护单元365，用于维护及管理协商要求。
上述协商代理36，协商请求分析单元361接收协商请求端例如：业务组合引擎33或业务路由器35发送的业务协商请求，协商过程控制单元362根据该业务协商请求生成目标业务协商请求，目标业务协商单元363与业务路由器35进行协商，最后协商结果生成单元364生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
如图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)对协商结果的处理要求：通过对协商结果的处理要求对协商结果进行处理找出最终业务。例如：取出满足要求的业务中最快反馈的一个；或者，取出满足要求业务中某需求单项最高的一个。过滤掉反馈时间超过10s的结果。
(2)对协商过程的要求：通过对协商过程的要求对协商过程进行控制。例如：所有目标业务协商需在10s内完成，否则算作失败。
业务需求分析单元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所示，为本发明实施例注册中心的结构图，本发明实施例中，注册中心32还增加存储了业务的一些动态需求信息，包括目前该业务可识别的需求信息及对应值，该对应值可以是具体数值，也可是查询该需求的端口。
注册中心32上存储的信息可以如表1所示，
表1
  归属业务标识   物理网地址   可识别业务需求及对应值需求＝对应值(对应值可以是具体的结果数值，也可是查询该需求的端口)   不可识别的业务需求
  shenlong.map.xxx   222.222.111.111   安全级别＝shenlongMap.REQinterface.securityLevel业务可访问时段＝9:00～18:00；业务可访问次数＝100/day   价格
  Baidu.map.xxx
注册中心32上存储的信息还可以如表2所示，
表2
  归属业务标识   物理网地址   可识别业务需求及对应值需求＝对应值(对应值可以是具体的结果数值，也可是查询该需求的端口)   新增需求通知端口地址
  shenlong.map.xxx   222.222.111.111   安全级别＝shenlongMap.REQinterface.securityLevel业务可访问时段＝9:00～18:00；业务可访问次数＝100/day   shenlongMap.REQNotificationInterface
如图6所示，本发明实施例的注册中心包括：注册单元321、更新单元322和查询单元323，其中，
注册单元321，用于处理业务的信息，将业务的信息注册到注册中心32上；
更新单元322，用于更新现有业务的信息。
查询单元323，用于查询现有业务的信息。
如图7所示，为本发明实施例业务提供端的结构图，包括：
注册单元371，用于将业务信息注册到归属业务路由器35上。还可用于注册业务需求的查询端口信息。
需求管理单元372，用于管理及根据新的业务需求生成结果信息。
新需求提交单元373，用于将新的业务需求提交到业务路由器35。
如图8所示，为本发明实施例另一种业务协商方法的流程图，包括：
步骤S801，协商代理36接收到协商请求端发送过来的业务协商请求。该协商请求端可以为：业务组合引擎33或业务路由器35。
步骤S802，协商代理36处理接收的业务协商请求，按照该业务协商请求携带的协商要求生成目标业务集合的目标业务协商请求。
步骤S803，协商代理36发送目标业务协商请求到目标业务所归属的业务路由器35(多个)上。
步骤S804，业务路由器35分析目标业务协商请求，分析出需要查询的功能设备，并向这些需要查询的功能设备发送需求查询请求，确定有不可识别的业务需求。这些功能设备包括业务目录31、注册中心32、承载网服务质量管理器34和业务提供端37。
业务路由器35确定有不可识别的业务需求具体可以为：在业务路由器35查询了所有需要查询的功能设备之后，如果没有查询到针对该业务需求的信息，则该业务路由器35确定该业务需求不可识别。
步骤S805，业务路由器35发布上述不可识别的业务需求，并将发布的业务需求通知业务提供端37，业务提供端37生成针对该业务需求的结果信息。结果信息或者发布了新的业务需求。
步骤S807，业务路由器35向协商代理36反馈生成的协商结果信息。
步骤S808，协商代理36按照协商要求对反馈的协商结果信息进行处理，选择出最终的目标业务，生成业务协商结果。
步骤S809，协商代理36发送生成的业务协商结果至协商请求端。
上述业务协商方法，协商代理36接收协商请求端例如：业务组合引擎33或业务路由器35发送的业务协商请求，根据该业务协商请求生成目标业务协商请求，并与业务路由器35进行协商，最后生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
如图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生成最终结果的过程也可以按照协商要求的规定发起，例如：等待10s，然后触发协商结果生成单元364处理所有反馈了结果的目标业务，这时步骤S909可以在步骤S908之前执行。
步骤S910，协商结果生成单元364接收目标业务协商单元363反馈的协商结果，按照协商要求对这些协商结果进行处理，选择出最终的目标业务，生成业务协商结果。
步骤S911，协商结果生成单元364发送业务协商结果给协商请求端。
在本实施例中，当需要使用到协商要求时，可以到协商要求维护单元365查询协商要求。
上述协商代理处理业务协商请求的流程，协商代理36的协商请求分析单元361接收协商请求端发送的业务协商请求，协商过程控制单元362根据该业务协商请求生成目标业务协商请求，目标业务协商单元363与业务路由器35进行协商，最后协商结果生成单元364生成业务协商结果反馈至协商请求端，实现了业务网络支持多种业务需求下的业务协商，满足了业务交互，以及协商请求端的需求，提高了业务协商的成功率及用户的满意度。
如图10所示，为本发明实施例业务路由器协商过程的流程图，具体包括：
步骤S1001，业务路由器35的协商处理单元351接收协商代理36发送的目标业务协商请求。
步骤S1002，协商处理单元351请求业务需求分析单元352进行业务需求分析。
步骤S1003，业务需求分析单元352分析出该目标业务协商请求中携带的业务需求、分析业务需求对应的功能设备，以确定需要查询的周边网络的功能设备。并将查询结果反馈给协商处理单元351。
步骤S1004，协商处理单元351按照业务需求分析单元352的分析结果调用需求查询单元353对周边网络的功能设备进行查询。
步骤S1005，需求查询单元353向承载网服务质量管理器34查询业务路由器35到业务之间的承载网上的服务质量检测信息。
步骤S1006，承载网服务质量管理器34返回查询结果。
步骤S1007，需求查询单元353向业务目录31查询业务功能相关的信息，该业务功能相关的信息包括业务提供商、业务类别和业务端口描述信息。
步骤S1008，业务目录31返回查询结果。
步骤S1009，需求查询单元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。
步骤S1022，需求查询单元353判断出是否所有的业务需求查询工作完毕。没完就继续等待，否则执行步骤S1023。
步骤S1023，需求查询单元353通知协商处理单元351所有处理完毕，并反馈所有业务需求的查询结果。
步骤S1024，协商处理单元351按照协商要求对所有业务需求的查询结果进行处理，判断该目标业务是否满足协商要求。
步骤S1025，协商处理单元351反馈目标业务协商结果给协商代理36。该目标业务协商结果可以为目标业务符合协商要求，或者当目标业务不满足业务需求时，该目标业务协商结果可以为目标业务不符合协商要求。
上述业务路由器的协商过程，协商处理单元351接收协商代理36发送的目标业务协商请求，调用业务需求分析单元352对目标业务协商请求进行分析，调用需求查询单元353对周边业务网络设备进行查询，在需求查询单元353确定存在不可识别的业务需求之后，由协商处理单元351触发需求发布接收单元354发布该不可识别的业务需求。本实施例中，业务路由器35进行业务协商，通过发布业务需求，使初期不可识别的业务需求后期可被发现及识别，从而使业务协商不需要限定在固定的业务需求上。
如图11所示，为本发明实施例发布新业务需求的一种流程示意图，包括：
步骤S1101，业务路由器35的需求发布接收单元354接收协商处理单元351发送的发布新增业务需求的请求消息。
步骤S1102，需求发布接收单元354将相应的新增业务需求的信息更新到对应的注册中心32上，等待业务提供端37的查询。
步骤S1103，注册中心32反馈更新成功。
其中，步骤S1102～步骤S1103为优选方案，新增业务需求的信息也可存储于业务路由器35上。
步骤S1104，需求发布接收单元354反馈新业务需求的发布情况给协商处理单元351。
步骤S1105，业务提供端37的需求管理单元372检测其归属业务路由器35上是否发布了针对该业务路由器35自身的新增业务需求。具体可以为：
a)业务提供端37可以通过定期轮训或随机检测的方式检测其归属业务路由器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上。
步骤S1112，注册中心32反馈更新结果。
步骤S1113，需求发布接收单元354通知协商处理单元351该新增业务需求已经被支持。
步骤S1114，协商处理单元351判断该次协商过程是否完成，如果没有完成，则将该业务需求标记为可识别并进行后续的协商过程。这样，便于在较为长期的协商过程中，对新增的业务需求快速响应。
其中，步骤S1113和步骤S1114为可选步骤。
本实施例通过发布业务需求，使初期不可识别的业务需求后期可被发现及识别，从而使业务协商不需要限定在固定的业务需求上。
如图12所示，为本发明实施例发布新业务需求的另一种流程示意图，包括：
步骤S1201，业务提供端37向其归属的业务路由器35的业务注册处理单元356发送注册业务的需求通知端口信息。
步骤S1202，业务注册处理单元356注册上述信息到注册中心32。
步骤S1203，注册中心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所示，为本发明实施例端口关系示意图。本发明实施例中，端口关系如下：
(1)协商请求端和协商代理36之间的端口：协商端口I1；
(2)协商代理36和业务路由器35之间的端口：目标业务协商端口I2；
(3)业务路由器35和业务目录31之间的端口：查询端口I3；
(4)业务路由器35和注册中心32之间的端口：查询端口I4和需求注册端口I5；
(5)业务路由器35和业务提供端37之间的端口：查询端口I6；
(6)业务路由器35和承载网服务质量管理器34之间的端口：查询端口I7和需求发布接收端口I8。
下面对上述各端口进行详细描述。
1、协商端口I1
协商端口的入口消息为：业务协商请求，包括以下信息：
1)备选的多个目标业务的业务网络地址或业务的标识，用来寻址到目标业务所归属的业务路由器35的信息；
2)业务需求，包括：
a)确定要处理的目标业务的范围，可以支持对1)指定的多个目标业务进行差异化处理，例如：All就是全部处理，或者，指定需要处理的目标业务的序号；
b)业务需求的名字，例如：价格、稳定性、交互协议或提供商等；
c)对业务需求的处理模式，例如：严格匹配、高于或低于等；
d)对业务需求的要求值；
3)协商要求，例如：多久时间之内返回协商结果是有效的，选出完全满足的或者是选出最快回复的，可以包括以下两个部分：
a)对协商结果的处理要求：通过该要求对协商结果进行处理找出最终的目标业务。例如：选择满足要求的业务中最快反馈的一个作为最终的目标业务；或者，取出满足要求的业务中某需求单项最高的一个作为最终的目标业务；或者，过滤掉反馈时间超过10s的协商结果；或者，在多个满足要求的业务中按照优先级筛选协商结果。
b)对协商过程的要求：通过该要求对协商过程进行控制，该协商过程指从协商代理36收到协商请求到协商代理36返回协商结果的过程。例如：所有目标业务的协商需在10s内完成，否则算作失败，即没有满足要求的业务。
一个以XML(eXtensible Marked Language，可扩展标记语言)描述的业务协商请求可以如下所示：
<？xml version＝″1.0″encoding＝″UTF-8″？>
<ServiceNegotiationRequest>
    <AddressSet>
       <address id＝″1″>Service Address1</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，1，3</claim>
         </ClaimForResult>
    </ClaimForNegotiation>
</ServiceNegotiationRequest>
上述业务协商请求描述了以下内容：
a)业务地址：三个备选的目标业务；
b)业务需求：针对所有的业务均要求在协议上为SOAP(Simple ObjectAccess Protocol，简单对象访问协议)、价格上低于10和稳定性上高于98(可选)；
c)协商要求：对协商过程要求在90内返回协商结果，对协商结果要求按照指定的(2，1，3)优先级挑选最优的。
协商端口I1的出口消息为业务协商结果，包括以下信息：
1)最终业务的业务网络地址或业务的标识；
2)协商日志，用来记录协商过程的一些信息，例如：协商总处理时间，采用的协商策略等。
一个以XML描述的业务协商结果如下所示：
<？xml version＝″1.0″encoding＝″UTF-8″？>
<ServiceNegotiationResult>
    <address>service address 1</address>
    <log>time＝40；suitable candidate＝2；</log>
</ServiceNegotiationResult>
上述业务协商结果描述了以下内容：
a)最终业务地址：1个；
b)协商日志：记录了协商过程占用的时长为40，满足需求的备选业务有两个(最终选择了一个)。
2、目标业务协商端口I2
目标业务协商端口I2的入口消息为目标业务协商请求，包括以下信息：
1)目标业务的业务网络地址或业务的标识，用来寻址到目标业务所归属的业务路由器35的信息，业务路由器35根据该业务网络地址或业务的标识，路由到需要处理的目标业务归属的业务路由器；
2)对业务的需求信息，这些信息是协商代理36根据业务协商请求中的业务需求信息中对应该目标业务而抽取的需求信息，业务路由器35根据该需要处理的目标业务的业务需求信息确定需要查询的功能设备；
3)对协商的要求，对协商的要求是协商代理36根据业务协商请求中的协商要求进行的处理生成和目标业务相关的要求。也包括两个部分：
a)对目标业务协商结果的处理要求，业务路由器35根据该处理要求对目标业务协商结果进行处理；
b)对目标协商过程的要求，业务路由器35根据对目标协商过程的要求对协商过程进行控制。
一个以XML描述的目标业务协商请求如下所示：
<？xml version＝″1.0″encoding＝″UTF-8″？>
<TargetServiceNegotiationRequest>
    <address>service Address 1</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)对协商的要求：对协商过程要求在70s内返回协商结果，如果有业务路由器不可识别的业务需求，那么就直接反馈业务不符合要求，如果有新的业务需求则发布。
目标业务协商端口I2的出口消息为目标业务协商结果，包括以下信息：
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)协商日志：记录了协商过程占用的时长为40s，查询的周边设备为业务目录、业务注册中心和业务提供端。
3、需求注册端口I5
需求注册端口I5的入口消息包括：
a)业务的标识：要注册的端口所对应的业务网络地址或标识；
b)接收需求通知消息的端口的信息。
需求注册端口I5的出口消息包括：该业务需求注册的结果(成功或失败)。
4、需求发布接收端口I8
需求发布接收端口I8的总入口消息包括：
a)发布新增需求请求；
b)业务的标识：目标业务的网络地址或标识；
c)(可选)新业务需求信息：不能识别的新业务需求信息的名称，对业务需求的描述信息。
需求发布接收端口I8的总出口消息包括：
a)新需求对应结果信息通知；
b)业务的标识：目标业务的网络地址或标识；
c)新业务需求信息的对应结果信息，该信息可以是对应需求的具体数值结果，也可以是对应的需求查询端口。
需求发布接收端口I8的新需求查询消息和订阅新增需求改动消息，按照实际的实现方案(轮询方式或订阅通知方式)可以任选一个。
a)轮询方式
入口消息包括：业务的标识，要查询的业务所对应的业务网络地址或标识；
出口消息包括：对新业务的需求信息描述，这些信息是目前业务路由器35不能识别的目标业务的需求信息；以及，业务需求的描述信息(可选)。
b)订阅通知方式
入口消息包括：
1)业务的标识，要订阅的业务所对应的业务网络地址或标识；
2)接收改动通知的端口地址：当有新增业务需求的时候会触发业务路由器35发送变动通知给需求发布接收端口I8；
3)(可选)需求类别：用来指定所订阅的业务的类别，只有指定类别的业务才通知；
4)(可选)需求排除类别：用来指定所排除订阅的业务的类别，只有非指定类别的业务才通知。
出口消息包括：订阅结果(成功或失败)。
下面通过一具体实施例对本发明的实施过程进行介绍。
在业务网络上，用户A请求执行组合服务“基于位置的地图服务”，业务内容为显示出针对用户当前位置的周边地图信息，业务网络的业务组合引擎33负责执行该服务，在组合业务执行过程中需要先调用位置服务后调用地图服务。在该组合业务的描述中关于地图服务有一个正选服务Google的地图服务(正常流程执行中调用的服务)，同时还有两个备选服务：百度的地图服务和神龙地图的地图服务。在执行中业务组合引擎33获知Google的地图服务正在维护，需要使用备选服务进行替代。则由于有两个备选服务，业务组合引擎33想确定目前最合适的一个备选服务替代正选服务。如图14所示，具体包括：
步骤S1401，业务组合引擎33向协商代理36发送业务协商请求。
该业务协商请求中包括两个备选服务的业务网络地址、包括对这些服务的需求信息：要求采用SOAP协议、要求价格都要低于10、要求稳定性要高于98(可选)。
同时针对第二个服务(神龙地图)单独设定了安全级别要求为：高于2。对协商的要求的规定为：对协商过程的要求90s内完成，对各个业务需求的协商优先级设定为价格优先，然后是交互协议，最后是稳定性。
采用XML描述的业务协商请求如下所示：
<input>
    <AddressSet>
       <address id＝″1″>*** map address</address>
       <address id＝″2″>shenlong map address</address>
    </AddressSet>
    <DemandforServers>
       <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>
       <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＝″1″type＝″priorityList″>2，1，3</demand>
         </DemandforResult>
     </DemandforNegotiation>
</input>
步骤S1402，协商代理36分析该业务协商请求并生成目标业务协商请求。
协商代理36分析处理该协商请求，针对两个目标业务分别生成目标业务协商请求：包括目标业务的业务网络地址和针对目标业务的需求信息。其中，针对目标业务的需求信息与步骤S1401中设置的需求信息相同。针对目标业务的协商要求，时间限制在70s内，如果有不可识别的业务需求则按照业务不符合，立即返回，同样的也可以设置发布业务后等待业务反馈，直到超出时间限制，如有不可识别的业务需求则发布，反馈结果中要求有查询的设备和具体的查询值信息。
例如：针对百度地图的目标业务协商请求具体可以为：
<input>
    <Address>*** map address</Address>
    <DemandforServers>
       <demand id＝″1″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″>
             <item>stability</item>
             <value>98</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>
针对神龙地图业务的目标业务协商请求具体可以为：
<input>
    <Address>shenlong map address</Address>
    <DemandforServers>
       <demand id＝″1″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″>
             <item>stability</item>
             <value>98</value>
         </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>
针对神龙地图业务的目标业务协商请求与针对百度地图的目标业务协商请求的不同之处在于有额外的安全等级方面的要求。
步骤S1403，归属业务路由器35处理目标业务协商请求，查询周边功能设备。
百度地图和神龙地图所分别归属的业务路由器35收到目标业务协商请求。下面以神龙地图的归属路由器35为例，百度地图业务的目标业务协商请求的处理与之类似。业务路由器35分析目标业务协商请求，分析出需要查询的周边设备，并向这些周边设备发送业务需求的查询请求。这些周边设备包括业务目录3l、注册中心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.securityLevel</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.REQNotificationInterface
</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>101(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>*** map address</address>
    </Candidate>
    <Log>time＝40；suitable candidates＝1；</Log>
</output>
本发明实施例提供一种业务协商方法、***和设备，根据业务网络中业务路由器的特点，使业务网络可以支持多种业务需求下的业务协商功能，满足业务交互的需求，以及业务协商请求者的需求，协商出最适合业务，提高了业务使用的成功率及用户的满意度。
由于业务具有多样性的特点，相应地，针对业务协商的需求也是多样性的，本发明实施例通过发布业务需求，使初期不可识别的需求可被后期发现及识别而不需要限定在固定的业务需求上。
本发明除上述实现方式外，还可将协商代理的功能集成到业务组合引擎上，将协商代理的功能集成到现有业务网络中的业务组合引擎上，成为一种增强型的业务组合引擎，可以实现对组合过程中调用的子业务进行协商。
另外，还可将协商代理的功能集成到现有业务网络中的业务路由器上，使其成为增强型的业务路由器，支持在智能路由或其它场合下的对业务进行协商的功能。在这种方式下，具有协商代理功能的增强型业务路由器担当本发明实施例中协商代理的角色，与其他业务路由器进行交互以实现本发明实施例的方案。
本发明实施例中，还可将注册中心的功能集成到现有业务网络的业务路由器上，这时原有注册于注册中心上的信息均注册到业务路由器上，由集成了注册中心功能的业务路由器上维护相应的信息，成为增强型的业务路由器，从而本发明实施例中注册、查询、更新和维护信息的实体均为业务路由器而非注册中心。业务路由器与注册中心交互的功能也将在业务路由器自身上实现。
本发明实施例中，还可将注册中心管理的信息和业务目录管理的信息进行融合或者交换。在现有的业务网络上，注册中心维护业务的动态信息，以及非功能性的一些信息，这些非功能性的一些信息包括业务状态和业务物理网络地址信息。而业务目录维护业务的功能性信息，该业务的功能性信息包括接口描述信息和交互协议信息等。
在进行组网部署时，可以按照各种业务需求(例如：降低成本)将注册中心管理的信息和业务目录管理的信息进行融合，或者将注册中心管理的信息和业务目录管理的信息进行交换。在这种方案下，业务路由器或协商代理在根据业务需求信息确定需要查询的功能设备时，就需要进行相应的更改，例如：某些向业务目录查询的业务需求可能需要转向注册中心查询，而某些向注册中心查询的业务需求可能需要转向业务目录查询。
本发明实施例中，由于网络部署及设备兼容的原因，在业务路由器的处理能力有限的情况下，可以更改为弱路由方案，具体为：
业务路由器不对业务需求的查询结果进行任何处理，而是直接将业务需求的查询结果反馈给协商代理，由协商代理进行协商处理过程。这种方案下，本发明实施例相应的更改为，业务路由器的入口消息更改：没有对协商结果的要求部分，业务路由器的出口消息更改，不再是协商结果，而是直接反馈业务需求的对应值。
本发明实施例中，主要是由业务路由器主控进行对业务的各种需求的查询和判断。作为备选方案，由于业务网络的部署的特殊性(例如：业务路由器不一定可以访问到业务目录)，则一种方案是协商代理代替业务路由器进行相应的查询和判断功能(例如：由协商代理查询业务目录)。这时，业务路由器仅仅处理消息路由的基本功能，业务路由器处理的功能全部由协商代理处理。具体地，由协商代理获得包含多个业务的业务协商请求，根据该业务协商请求获得所述多个业务的业务需求信息，以及针对所述多个业务的业务需求信息的需求处理结果，然后根据该需求处理结果选择目标业务，生成与上述业务协商请求对应的业务协商结果，并发送该业务协商结果至业务提供端。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (30)

1、一种业务协商方法，其特征在于，包括：
获得包含多个业务的业务协商请求；
向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息；
接收所述多个业务归属的业务路由器针对所述业务需求信息反馈的需求处理结果；
根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果并反馈。
2、如权利要求1所述的方法，其特征在于，所述多个业务归属的业务路由器针对所述业务需求信息反馈需求处理结果具体包括：
所述多个业务归属的业务路由器根据所述多个业务的业务需求信息，确定需要查询的功能设备，并向所述功能设备发送携带所述业务需求信息的需求查询请求；
接收所述功能设备根据所述需求查询请求反馈的需求处理结果；
反馈所述需求处理结果至协商代理。
3、如权利要求1所述的方法，其特征在于，所述向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息具体包括：
协商代理从所述业务协商请求中获得需要处理的目标业务；
向所述多个业务归属的业务路由器发送目标业务协商请求，请求所述需要处理的目标业务的业务需求信息。
4、如权利要求3所述的方法，其特征在于，所述多个业务归属的业务路由器包括所述需要处理的目标业务归属的业务路由器；
所述多个业务归属的业务路由器针对所述业务需求信息反馈需求处理结果具体包括：
所述需要处理的目标业务归属的业务路由器根据所述目标业务的业务需求信息，确定需要查询的功能设备，并向所述功能设备发送携带所述业务需求信息的需求查询请求；
接收所述功能设备针对所述需求查询请求反馈的需求处理结果；
根据所述需求处理结果生成所述目标业务协商请求对应的目标业务协商结果；
反馈所述目标业务协商结果至所述协商代理。
5、如权利要求4所述的方法，其特征在于，所述根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果具体包括：
所述协商代理根据所述目标业务协商结果选择目标业务，生成与所述业务协商请求对应的业务协商结果。
6、如权利要求2或4所述的方法，其特征在于，所述确定需要查询的功能设备，并向所述功能设备发送携带所述业务需求信息的需求查询请求，具体包括：
所述多个业务归属的业务路由器向承载网服务质量管理器发送需求查询请求，查询所述多个业务归属的业务路由器与业务承载网之间的服务质量检测信息；和/或，
向业务目录发送需求查询请求，查询业务功能信息，所述业务功能信息包括业务提供商信息、业务类别信息或业务端口描述信息；和/或，
向注册中心发送需求查询请求，查询业务动态信息。
7、如权利要求6所述的方法，其特征在于，所述业务动态信息包括所述业务需求对应的具体数值或者所述业务需求对应的查询端口信息；
当查询到的业务动态信息为所述业务需求对应的查询端口信息时，还包括：
所述多个业务归属的业务路由器根据所述查询端口信息向所述业务提供端的相应查询端口查询所述业务需求对应的具体数值。
8、如权利要求2或4所述的方法，其特征在于，还包括：
所述多个业务归属的业务路由器根据所述功能设备反馈的需求处理结果确定存在不可识别的业务需求，并发布所述不可识别的业务需求。
9、如权利要求1所述的方法，其特征在于，所述业务协商请求包括以下信息中的一种或几种：
所述多个业务的业务网络地址或业务标识，所述多个业务的业务需求信息，所述目标业务的选择要求和对协商过程的要求；
其中：
所述协商代理根据所述业务网络地址或业务标识，路由到所述多个业务归属的业务路由器；
所述协商代理根据所述多个业务的业务需求信息获取所述多个业务的相关业务需求；
所述协商代理根据所述选择要求选择目标业务；
所述协商代理根据所述要求对所述协商过程进行控制。
10、如权利要求1所述的方法，其特征在于，所述业务协商结果包括以下信息中的一种或几种：
所述目标业务的业务网络地址或业务标识和协商日志；
其中：
所述协商代理将所述目标业务的业务网络地址或业务标识返回至协商请求端；
所述协商日志包括协商过程的总处理时间，或采用的协商策略。
11、如权利要求3所述的方法，其特征在于，所述目标业务协商请求包括以下信息中的一种或几种：
所述需要处理的目标业务的业务网络地址或业务的标识，所述需要处理的目标业务的业务需求信息，对目标业务协商结果的处理要求和对目标协商过程的要求；
其中：
业务路由器根据所述业务网络地址或业务的标识，路由到所述需要处理的目标业务归属的业务路由器；
所述业务路由器根据所述需要处理的目标业务的业务需求信息确定需要查询的功能设备；
所述业务路由器根据所述处理要求对所述目标业务协商结果进行处理；
所述业务路由器根据所述对目标协商过程的要求对协商过程进行控制。
12、如权利要求4所述的方法，其特征在于，所述目标业务协商结果包括以下信息中的一种或几种：
协商结果标识、协商日志和所述业务需求对应的具体数值；
其中：
所述协商结果标识指示协商结果，以及所述协商结果对应的信息，协商代理根据所述协商结果确定业务需求是否被满足；
所述协商日志包括协商处理时间和所述查询的功能设备标识。
13、如权利要求1、2、4、6、7或11所述的方法，其特征在于，所述方法中业务路由器处理的功能可由协商代理处理。
14、如权利要求6所述的方法，其特征在于，所述注册中心可以集成在业务路由器上，所述方法中注册中心处理的功能可由业务路由器处理。
15、一种业务需求的发布方法，其特征在于，包括：
获取目标业务的业务需求信息，根据所述业务需求信息确定存在不可识别的业务需求；
发布所述不可识别的业务需求。
16、如权利要求15所述的方法，其特征在于，所述根据所述业务需求信息确定存在不可识别的业务需求具体包括：
查询所述目标业务归属的业务路由器所能支持的业务需求信息，根据查询结果确定存在不可识别的业务需求；或者，
根据所述业务需求信息，确定需要查询的功能设备，并向所述功能设备发送携带所述业务需求信息的需求查询请求，接收所述功能设备针对所述需求查询请求反馈的需求查询结果，根据所述需求查询结果确定存在不可识别的业务需求。
17、如权利要求15所述的方法，其特征在于，所述发布所述不可识别的业务需求具体包括：
所述目标业务归属的业务路由器将所述不可识别的业务需求的信息发布到所述业务路由器上或所述业务路由器对应的注册中心上，由业务提供端获得针对所述业务提供端的不可识别的业务需求的信息；
接收所述业务提供端发送的结果信息，所述结果信息是所述业务提供端针对所述不可识别的业务需求生成的结果信息；
将所述结果信息更新到所述业务路由器或所述注册中心。
18、如权利要求17所述的方法，其特征在于，所述发布所述不可识别的业务需求具体包括：
所述目标业务所归属的业务路由器查询注册中心，获得业务注册时提供的需求通知端口，通过所述需求通知端口将所述不可识别的业务需求通知业务提供端；
接收所述业务提供端发送的结果信息，所述结果信息是所述业务提供端针对所述不可识别的业务需求生成的结果信息；
将所述结果信息更新到所述业务路由器或所述注册中心。
19、如权利要求17或18所述的方法，其特征在于，所述结果信息包括：所述不可识别的业务需求对应的具体数值结果；或者，所述不可识别的业务需求对应的查询端口信息。
20、一种业务协商***，其特征在于，包括：业务路由器和协商代理，
所述协商代理，用于接收包含多个业务的业务协商请求，向所述多个业务归属的业务路由器请求所述多个业务的业务需求信息，接收所述业务路由器针对所述业务需求信息反馈的需求处理结果，根据所述需求处理结果选择目标业务，生成并反馈与所述业务协商请求对应的业务协商结果；
所述业务路由器，用于接收所述协商代理的请求，向所述协商代理反馈针对所述多个业务的业务需求信息的需求处理结果。
21、如权利要求20所述的***，其特征在于，还包括以下设备的一种或多种：
业务目录，用于维护业务功能信息，所述业务功能信息包括业务提供商信息、业务类别信息或业务端口描述信息；
注册中心，用于维护业务动态信息，所述业务动态信息包括业务标识或业务网络地址，以及所述业务标识或业务网络地址对应的物理网络地址；
业务组合引擎，用于发起业务协商请求；
承载网服务质量管理器，用于管理底层承载网络的服务质量功能，包括检测物理链路层的联通状态、传输速率、延时和抖动信息中的一种或几种。
22、如权利要求20所述的***，其特征在于，所述协商代理具体为一个独立的功能实体，或者集成在业务组合引擎上，或者集成在所述业务路由器上。
23、如权利要求20所述的***，其特征在于，所述注册中心具体为一个独立的功能实体，或者集成在所述业务路由器上。
24、如权利要求20所述的***，其特征在于，所述业务路由器除路由业务层消息之外的功能可以集成到所述协商代理上。
25、一种协商代理，其特征在于，包括：
协商请求分析单元，用于获得包含多个业务的业务协商请求，分析出需要处理的目标业务，及协商要求；
目标业务协商单元，用于向所述需要处理的目标业务归属的业务路由器请求所述目标业务的业务需求信息，接收所述目标业务归属的业务路由器针对所述目标业务的业务需求信息反馈的需求处理结果；
协商结果生成单元，用于根据所述需求处理结果选择目标业务，生成与所述业务协商请求对应的业务协商结果并反馈。
26、如权利要求25所述协商代理，其特征在于，还包括：
协商过程控制单元，用于根据所述协商请求分析单元获得的业务协商请求中的协商要求及需要处理的目标业务，生成目标业务协商请求。
27、如权利要求25所述协商代理，其特征在于，还包括：
协商要求维护单元，用于维护及管理协商要求。
28、一种业务路由器，其特征在于，包括：
协商处理***，用于接收并处理目标业务的协商请求，并反馈针对所述协商请求的协商结果。
29、如权利要求28所述业务路由器，其特征在于，所述协商处理***包括：
协商处理单元，用于接收协商代理发送的请求，并控制业务路由器上的协商过程；
业务需求分析单元，用于接收所述协商处理单元发送的请求，分析所述请求中的业务需求信息，根据所述业务需求信息确定需要查询的功能设备，并触发所述协商处理单元发送携带所述业务需求的需求查询请求；
需求查询单元，用于接收所述协商处理单元发送的需求查询请求，向所述功能设备发送需求查询请求，并接收所述功能设备反馈的需求处理结果，触发所述协商处理单元反馈所述需求处理结果至所述协商代理。
30、如权利要求29所述业务路由器，其特征在于，
所述需求查询单元还用于根据所述需求处理结果确定存在不可识别的业务，在确定存在不可识别的业务之后，通知所述协商处理单元；
所述协商处理单元还用于发送新业务需求发布要求；
所述协商处理***还包括：
需求发布接收单元，用于接收所述协商处理单元发送的新业务需求发布要求，发布所述不可识别的业务需求。
CN200810148830A 2008-09-27 2008-09-27 一种业务协商方法、***和设备 Pending CN101686173A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN200810148830A CN101686173A (zh) 2008-09-27 2008-09-27 一种业务协商方法、***和设备
EP09817243A EP2330847A4 (en) 2008-09-27 2009-09-22 METHOD, SYSTEM AND APPARATUS FOR SERVICE NEGOTIATION
PCT/CN2009/074106 WO2010037329A1 (zh) 2008-09-27 2009-09-22 一种业务协商方法、***和设备
US13/072,251 US20110238840A1 (en) 2008-09-27 2011-03-25 Method, system, and device for service negotiation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200810148830A CN101686173A (zh) 2008-09-27 2008-09-27 一种业务协商方法、***和设备

Publications (1)

Publication Number Publication Date
CN101686173A true CN101686173A (zh) 2010-03-31

Family

ID=42049155

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810148830A Pending CN101686173A (zh) 2008-09-27 2008-09-27 一种业务协商方法、***和设备

Country Status (4)

Country Link
US (1) US20110238840A1 (zh)
EP (1) EP2330847A4 (zh)
CN (1) CN101686173A (zh)
WO (1) WO2010037329A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102136990A (zh) * 2010-06-09 2011-07-27 华为技术有限公司 一种业务叠加网络的业务路由方法及***
CN102271320A (zh) * 2010-06-03 2011-12-07 中兴通讯股份有限公司 业务协商方法及***
CN102811134A (zh) * 2012-07-31 2012-12-05 苏州阔地网络科技有限公司 一种网络会议漂移控制方法及***
CN106021427A (zh) * 2016-05-16 2016-10-12 中国银行股份有限公司 一种动态交互方法、装置及***
CN107431669A (zh) * 2015-10-26 2017-12-01 华为技术有限公司 协商对象的选择方法、响应发现消息的方法、相关装置
TWI746190B (zh) * 2020-09-14 2021-11-11 鼎新電腦股份有限公司 用於偵測業務系統的電子裝置及其偵測方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9715544B2 (en) 2010-08-17 2017-07-25 International Business Machines Corporation Online location sharing through an internet service search engine
WO2013019206A1 (en) * 2011-08-01 2013-02-07 Intel Corporation Witnessed ad-hoc uservices
US9832257B2 (en) * 2013-05-02 2017-11-28 Intel Corporation Service acquisition techniques for wireless communications systems
CN104702529A (zh) * 2013-12-09 2015-06-10 华为软件技术有限公司 控制业务带宽的方法、***和设备
CN106878169B (zh) * 2016-08-18 2020-08-04 阿里巴巴集团控股有限公司 一种业务路由方法和装置
US10284730B2 (en) 2016-11-01 2019-05-07 At&T Intellectual Property I, L.P. Method and apparatus for adaptive charging and performance in a software defined network
US10454836B2 (en) * 2016-11-01 2019-10-22 At&T Intellectual Property I, L.P. Method and apparatus for dynamically adapting a software defined network
US10469376B2 (en) 2016-11-15 2019-11-05 At&T Intellectual Property I, L.P. Method and apparatus for dynamic network routing in a software defined network
US10039006B2 (en) 2016-12-05 2018-07-31 At&T Intellectual Property I, L.P. Method and system providing local data breakout within mobility networks
US10264075B2 (en) * 2017-02-27 2019-04-16 At&T Intellectual Property I, L.P. Methods, systems, and devices for multiplexing service information from sensor data
US10469286B2 (en) 2017-03-06 2019-11-05 At&T Intellectual Property I, L.P. Methods, systems, and devices for managing client devices using a virtual anchor manager
US10212289B2 (en) 2017-04-27 2019-02-19 At&T Intellectual Property I, L.P. Method and apparatus for managing resources in a software defined network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2249824C (en) * 1998-10-08 2007-02-06 Northern Telecom Limited Service capable network
US7042851B1 (en) * 2000-10-26 2006-05-09 Lucent Technologies Inc. Service creation and negotiation in a wireless network
SE0104080D0 (sv) * 2001-12-05 2001-12-05 Ericsson Telefon Ab L M A method and apparatus for negotiating mobile services
US7894815B2 (en) * 2005-10-21 2011-02-22 Electronics And Telecommunications Research Institute Device for providing hand-off quality of service of inter-access systems and method thereof
CN100493216C (zh) * 2007-04-03 2009-05-27 华为技术有限公司 一种集团总机的集团总机短信处理方法和服务器

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102271320A (zh) * 2010-06-03 2011-12-07 中兴通讯股份有限公司 业务协商方法及***
CN102271320B (zh) * 2010-06-03 2016-01-20 中兴通讯股份有限公司 业务协商方法及***
CN102136990A (zh) * 2010-06-09 2011-07-27 华为技术有限公司 一种业务叠加网络的业务路由方法及***
CN102136990B (zh) * 2010-06-09 2013-11-06 华为技术有限公司 一种业务叠加网络的业务路由方法及***
US8780883B2 (en) 2010-06-09 2014-07-15 Huawei Technologies Co., Ltd. Service routing method and system on service overlay network
CN102811134A (zh) * 2012-07-31 2012-12-05 苏州阔地网络科技有限公司 一种网络会议漂移控制方法及***
CN107431669A (zh) * 2015-10-26 2017-12-01 华为技术有限公司 协商对象的选择方法、响应发现消息的方法、相关装置
US10972356B2 (en) 2015-10-26 2021-04-06 Huawei Technologies Co., Ltd. Method for selecting negotiation counterpart, method for responding to discovery message, and related apparatus
CN106021427A (zh) * 2016-05-16 2016-10-12 中国银行股份有限公司 一种动态交互方法、装置及***
CN106021427B (zh) * 2016-05-16 2022-01-07 中国银行股份有限公司 一种动态交互方法、装置及***
TWI746190B (zh) * 2020-09-14 2021-11-11 鼎新電腦股份有限公司 用於偵測業務系統的電子裝置及其偵測方法

Also Published As

Publication number Publication date
EP2330847A1 (en) 2011-06-08
EP2330847A4 (en) 2012-04-04
US20110238840A1 (en) 2011-09-29
WO2010037329A1 (zh) 2010-04-08

Similar Documents

Publication Publication Date Title
CN101686173A (zh) 一种业务协商方法、***和设备
JP6684850B2 (ja) 分散台帳システム、分散台帳サブシステム、および、分散台帳ノード
CN101299754B (zh) 具有动态用户界面的终端用户控制配置***
CN101065947B (zh) Web服务注册和操作方法和***
CN100426242C (zh) 供应数据处理***中识别、保留和逻辑供应资源的方法和***
CN109246251A (zh) 一种微服务调用方法、装置、***、设备及可读存储介质
KR100545443B1 (ko) 브릿지, 결합 방법, 결합 시스템 및 컴퓨터 판독가능한 기록 매체
CN101883107B (zh) 实现上下文感知业务应用的方法和相关装置
KR101296321B1 (ko) 오픈 ａｐｉ 기반 콘텐츠 서비스 인터페이스 제공 시스템 및 방법
CN102591724A (zh) 消息交互方法及装置
CN103942055A (zh) 面向融合网络混合服务流程编制语言的开发***及方法
US20090327406A1 (en) Bus system
CN101453730B (zh) 一种支持多运营支撑***的装置和方法
CN102694803A (zh) 一种soa服务提供方法及***
JP2005202851A (ja) 仮想私設組織に対するポリシの実施システム及びその方法
CN103458313A (zh) 一种互联网电视快速定位目标资源的方法及***
CN101127774B (zh) 初始过滤规则的优先级处理方法
CN101521592B (zh) 一种建立打印机snmp代理的方法及装置
JP2002304352A (ja) 情報配信サーバー装置
CN101257495B (zh) 一种语义消息传输方法及通讯***以及消息处理装置
Rana et al. Service design patterns for computational grids
KR101146742B1 (ko) ＳａａＳ의 분산된 세션 관리 방법 및 그 관리 시스템
Huang et al. Dynamic Web service selection for workflow optimisation
CN113840013A (zh) 一种分级管理的文档***
KR102003941B1 (ko) 서비스 공통 실행 환경에서의 서비스 통합 관리 시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20100331