与服务的实时组合相关联的服务发现的制作方法

专利名称：与服务的实时组合相关联的服务发现的制作方法
技术领域：
本发明总体涉及通信，具体涉及用于在通信系统中提供服务实时组合的方法、设 备和系统。
背景技术：
通信系统不断发展和演进。不同类型的通信系统(例如因特网协议(IP)、基于连 接的语音通信等等)之间的汇聚正在快速发展。近来已经使用了短语“下一代网络”(NGN) 来描述与这种演进相关联的各种活动。如国际电信联盟(ITU)所定义的，NGN是基于分组的 网络，能够提供服务(包括电信服务)并能够利用多种宽带的、具有QoS能力的传输技术， 其中，与服务相关的功能独立于下层的与传输相关的技术。NGN也将很可能提供用户对不同 服务提供商的无限制访问，并将支持一般化的移动性，继而将向最终用户提供一致的服务 供应。所谓“Web服务”是可能在NGN中变得平常的另一特征。Web服务提供例如驻 留于不同基础实施且可由不同公司运营的软件实体之间的可互操作性的机制。典型地， Web服务被定义为使用例如标准组Web服务描述语言(WSDL)、简单对象访问协议(SOAP) 和统一描述、发现和集成(UDDI)来提供分布式服务。对于感兴趣的读者来说，WDSL的描 述可以在线找到，如位于 http //www. w3. org/TR/2004/ffD-wsdl20-20040803/ 的 “Web ServicesDescription Language (WSDL) Version 2. OPart 1 :Core Language, W3Cfforking Draft 3, August 2004”，其公开通过引用合并于此。类似地，SOAP的描述可以在线找 至IJ，如位于 http://www.w3.org/TR/soaDl2-DartO/ 的 “SOAP Version 1. 2Part O Primer (Second Edition), W3C Recommendation 27 April 2007”，其公开通过引用合并于 此。此外，对于 UDDI,可以在 http //uddi. org/pubs/uddi v3. htm 找到题为“UDDI Version 3.0.2 UDDI Spec Technical Committee Draft, Dated 20041019” 的标准文献，其公开通 过引用合并于此。Web服务可以被表征为一种用于将应用功能作为服务暴露给软件客户端或服务器 应用的技术。此外，Web服务允许通过以新方式组合现有功能来快速创建新服务。这个过 程通常称为组合(composition)或编排(orchestration)。典型地，使用超文本传输协议 (HTTP)作为承载，利用XML编码的SOAP消息来访问Web服务。然而，HTTP是针对不需要实 时属性的、基于事务的客户端/服务器请求模式而设计的。对此，考虑在用户通过点击HTTP 超链接来获取网页时可能出现的可变且有时较大的延迟。随着端到端实时通信服务的用户 对服务交互和快速组合的日益增长的需求，还需要将Web服务范例应用至这种实时域。此外，这种努力也没有考虑显式中间寻址。相反，现有网络要么仅考虑适用于应 用发起的SIP服务寻址(例如，通过令应用使用第二协议(例如HTTP)来执行实际方法调 用)，要么仅将服务寻址基于SIP路由(这提供了一种拙劣的方式将中间服务引入会话发起 序列)。这使得现有SIP服务寻址基于无法实现实时服务组合的能力。相应地，通过在通信系统中提供用于与服务的 实时组合相关联的中间寻址的技术来解决这种需要将是有利的。

发明内容
根据示例实施例，一种服务发现方法，包括接收会话发起协议(SIP)消息，所述 SIP消息包括简单对象访问协议(SOAP)封包和SOAP动作首部，所述SOAP动作首部指示所 述SIP消息包括统一描述、发现和集成(UDDI)服务发现请求；解析所述SOAP封包，以标识 所述SOAP封包内的SOAP动作首部；访问UDDI注册中心以获得服务列表；以及转发所述服 务列表。根据另一示例实施例，一种通信节点，包括作为下列之一而操作的处理器会话 发起协议(SIP)代理和SIP用户代理服务器(UAS)，用于接收SIP消息，所述SIP消息包括 简单对象访问协议(SOAP)封包和SOAP动作首部，所述SOAP动作首部指示所述SIP消息包 括统一描述、发现和集成(UDDI)服务发现请求；SOAP解析器/分派器，用于从所述SIP消 息中解析所述SOAP封包；以及UDDI注册中心，响应于UDDI服务发现请求，提供能够经由所 述通信节点而访问的服务的列表。


附图示意了示例实施例，其中图1 (a)描述了根据示例实施例的包括SOAP净荷的SIP消息的发送；图1 (b)示出了根据示例实施例的包括SOAP净荷的SIP消息的确认；图2是示意了根据示例实施例的方法的流程图；图3是示意了根据另一示例实施例的另一方法的另一流程图；图4描述了根据示例实施例的通信设备；图5示意了根据示例实施例的中间节点；图6示意了根据示例实施例的包括中间节点的系统；图7是示意了根据示例实施例的方法的流程图；图8和9示意了根据示例实施例的端点之间的服务发现；图10和11示意了根据示例实施例的与中间节点相关联的服务发现；以及图12是示意了根据示例实施例的服务发现方法的流程图。
具体实施例方式
对示例实施例的以下详细描述参照附图。在不同附图中，相同的参考标号标识相 同或相似的元件。此外，以下详细描述不限制本发明。取而代之地，本发明的范围由所附权 利要求限定。 根据在上述相关应用中描述的示例实施例，通过针对SOAP消息的会话发起协 议(SIP)传输绑定来提供对针对服务的实时组合的需要的解决方案。例如，可在httD:// tools, ietf. orR/html/rfc3261 在线找到的题为 “Session Initiation Protocol, RFC 3261, authored by Rosenberg et. al. ,IETF 2002” 的标准文献中描述了 SIP 信令，其公开 通过引用合并于此。如其中所述，SIP提供了一种用于对与一个或多个参与者的会话进行 创建、修改和终止的应用层控制(信令)协议。这些会话包括例如，因特网电话呼叫、多媒体分发和多媒体会议。SIP邀请用于创建会话并承载允许参与者商定兼容媒体类型集合的 会话描述。“代理服务器”用在SIP环境中以帮助将请求路由至用户当前位置、针对服务对 用户进行认证和授权、实现提供商呼叫路由策略并向用户提供特征。本申请尤为感兴趣的 是，SIP通过使用确保最小事务延迟的定时器来提供实时服务。SIP服务请求可以被表征为例如⑴发起应用的请求，例如玩象棋游戏的请求；或 者(2)针对要提供的某种数据或要作为更复杂交互的一部分而执行的某种事务的请求。根 据所考虑的是这两种情况中的哪一种，所需的服务寻址 不同。对于前一种情况(1)，这里称 为“应用发起情况”，SIP用于定位和提供参数以将请求与可发起的应用(例如多媒体电话 应用、聊天应用、象棋应用等)进行匹配。在这种情况下，所发起的应用将使用会话中SIP 信令或某种其他协议来接管应用专用信令。因此，为了支持涉及应用发起的SIP服务请求， 对精确服务标识和/或服务参数供应的需要一般是不存在的或至少非常有限的。取而代之 地，对于这种SIP请求，服务能力的标识更加重要。第二种情况(2)，这里称为“商业方法集成情况”，涉及通过来自多个或多或少独 立的参与功能的复杂功能的组合(例如，在建立SIP会话时发布线路状态通知)来访问服 务。例如，每当用户想要或需要请求网络中的特定服务(与请求提供特定能力的任何服务 不同)时，或者每当输入参数对于执行服务而言是必要的时，这种商业方法集成情况就适 用。因此，与应用发起情况不同，在商业方法集成情况中，精确标识所请求的服务和/或提 供服务参数的能力是重要的，而指定所请求能力的能力不那么重要。本发明的示例实施例 寻求促进商业方法集成情况。然而，SIP服务寻址一般被视为仅适用于应用发起，从而需要 使用SIP发起的应用使用第二协议(例如HTTP)来执行商业方法调用。这使得现有SIP服 务寻址基于本身对实时服务组合无效的能力。相应地，这些示例实施例提供了针对SOAP消息的SIP传输绑定，即，使用SIP作为 承载在SOAP节点之间传输SOAP消息的示例技术。商业集成情况的现实世界示例将提供这 种传输绑定的效用的示例。例如，假定电视频道与对正在广播的节目之一的慈善呼叫的电 话号码相关联(例如在IPTV多播会话中)。当Alice例如使用她在网页上已找到的、所提供 的链接来呼叫该电视频道时，在将呼叫转接至她可与电视节目主持人之一进行交谈的电视 演播室之前，该呼叫被实时路由至向她收取捐赠的慈善支付服务。根据示例实施例，这可以 通过使用SIP作为承载、利用SOAP所支持的寻址机制来实时完成。例如，通过将SOAPAction 首部添加至SIP消息，可以将SIP用户代理服务器(UAS)标识为SIP净荷中的SOAP封包的 最终接收者。此外，WSDL接口可以用于描述正在请求的web服务的语义，以供对应工具自 动产生客户桩(client stub)以使用该服务。对此应注意，WSDL 2. O已经从WSDL 1. O中 的“PortTypes”移植到“Interfaces”，然而，两者中的任一个都可以用作指向特定服务(即 Web服务)的机制的示例，并可以在SIP/S0AP绑定中使用。见例如以上通过引用而合并的 文献WSDL 2. O第2. 2节。类似地，根据这些示例实施例，在SOAPAction首部中提供的“方 法”提供了正在请求的服务的类型的指示符，其中Web服务可以提供多个不同的服务变型。 这样，以具体到足以将用户连接至特定服务实例或接口的方式，在SIP消息中提供与服务 的位置、标识和/或输入参数相关联的信息。一些详细示例如下。首先从SIP/S0AP消息本身开始，以下提出根据示例实施例承载一个或多个SOAP 数据元素作为净荷的SIP消息的各种示例。在SIP内容中提供SOAPAction首部，以使接收SIP端点能够确定是否转发嵌入的SOAP封包以进行进一步处理，例如接收节点是否支持 SOAPAction首部中标识的Web服务。根据这些示例实施例，在针对SOAP的SIP传输绑定中 提供的SOAPAction首部一般使用如下URI语法SOAPAction :“URI”根据这些示例实施例的SOAPAction首部的更具体示例包括统一资源名称(URN)。 本领域技术人员可以认识到，URN是通过特定名字空间中的名称对资源进行标识的URI。在 这些示例实施例的上下文中，可以如下将URN语法提供给SOAPAction首部SOAPAction: "urn:<NID>:<NSS>"其中NID是名字空间标识符，遵循例如在URN Syntax, RFC 2141，R. Moats, IETF 1997中描述的用于NID的语法，并且NSS具有以下语法NSS “〈Interface〉！ <methodName>，，SOAPAction首部URI指示了在SIP消息中嵌入的SOAP消息(根据这 些实施例， SIP消息承载SOAP消息)的最终接收者。通过将SOAPAction首部添加至SIP消息，可以 通过使用URN的名字空间专用部分来对接口和方法进行寻址。这使得SIP代理以及特定消 息的路由路径上的其他节点能够正确处理该消息。SOAP消息体引用由所寻址的接口提供的 方法。在SOAPAction首部中，紧接在分隔符(在本示例实施例中是感叹号)之后表示该方 法。然而，本领域技术人员将认识到，根据其他示例实施例，任何未保留的字符或无其他含 义的字符可以用作SOAPAction首部中接口与方法之间的分隔符。以下考虑根据这些示例实施例可在SIP/S0AP消息中使用的SOAPAction首部以及 SOAP消息体的另一示例。SOAPAct i on “urn:stockservice-ericsson_com:QuoteBean ！ GetLastTradePrice，，<soap:Body><m:GetLastTradePrice xmlns:m = " urn:stockservice-ericsson-com" ></m:GetLastTradePrice)</soap:Body>在本示例中，在SOAPAction首部中，引用了接口 QuoteBean。由QuoteBean提供的 方法称为GetLastTradePrice。在SOAPAction首部中，在感叹号之后引用了该方法。SOAP 消息体可以包含与指定方法相关的更多细节，包括参数。例如，以下考虑更详细的示例。其 中，通过SOAP净荷而访问的Web服务提供股票报价。更具体地，该特定SOAP消息从称为 “QuoteBean”的接口请求Ericsson股票的当前价格的最新报价。该代码片断使Alice能够 请求她将从表示Bob (可能是股票经纪人)的UAS接收到的股票报价。该报价将作为SOAP 封包在例如2000K消息中从Bob返回。备选地，Alice的设备与Bob的设备之间的路由上 的SIP代理可以向Alice提供报价，在这种情况下，就已经在SOAPAction首部中对SIP代 理节点进行寻址。INVITE sip:bobiericsson. com SIP/2. OVia:SIP/2. 0/UDP pc33. atlanta. com ；branch = z9hG4bKnashds8Max-Forwards:70To:Bob<sip:bobibiloxi. com>
From:Alice<sip:aliceiatlanta. com> ；tag = 1928301774Call-ID:a84b4c76e66710CSeq:314159INVITEContact:<sip:aliceipc33. atlanta. com>Content-Type:text/xml ； charset = utf-8SOAPAct ion : “urn : stockservice-ericsson-com: QuoteBean ！ GetLastTradePrice，，< ？ xml versi n=〃 1.0" ？ ><soap:Envelopexmlns:soap = " http:/schemas. xmlsoap. org/soap/envelope/"soa: encodingstyle = " http://schemas.xmlsoap.org/soap/ encoding/" ><soap:Body><m:GetLastTradePrice xmlns:m = " urn:stockservice-er icsson-com" ><symbol>ERIC B</symbol></m:GetLastTradePrice)</soap:Body></soap:Envelope)其中再次注意，SOAPAction首部被添加至标准SIP首部的列表，并在上述示例中 以粗体显示。SOAPAction首部包含标识Web服务的统一资源标识符(URI)(可选地，该Web 服务可以被描述为WSDL接口(QuoteBean)和方法名称(GetLastTradePrice))，从而提供根 据这些示例实施例的用于精确地标识所请求的服务的机制。此外，在本示例中，在SOAP封 包中提供了参数“ERIC B”，以更完整地指定正在请求的服务，S卩，提供具有符号ERIC B的 Ericsson股票的当前股价。然而，可以认识到，一些服务请求可能需要更多参数(或不需要 参数)来完整地指定所期望的服务，由此，根据这些示例实施例的SIP/S0AP消息可以包含 所需数目的参数。已经示意了示例SIP/S0AP组合的一些代码片断以及用于实现所嵌入的SOAP消息 的SIP传输绑定的示例SOAP语法，现在将讨论根据这些示例实施例的、采用这种消息来调 用服务的实时组合的一些更高层实现方式。图1(a)示意了根据这些示例实施例的应用或 设备使用SOAP客户端来构造SOAP封包以调用web服务方法，同时发起发端节点100与接收 节点110之间的SIP会话的一种方式。其中，客户端应用200使用应用编程接口(API)，利 用SOAP客户端202来创建SOAP消息，例如具有SOAP消息体的SOAP封包，可选地，该SOAP 消息体具有用于指示要请求的服务的附加参数。然后，该SOAP消息(以上提供了其示例) 作为由SIP用户代理客户端(UAC) 204产生的SIP消息(例如SIP INVITE消息)中的全部 或部分净荷与SOAPAction首部一起传送。SIP UAC 204可以使用通过WSDL接口语法产生 的客户桩来创建SOAPAction首部和封包。然而可以认识到，如果特定服务请求不需要会话 发起，则也可以使用不同于SIP INVITE的SIP消息(例如SIP0PTI0NS或MESSAGE)来承载 根据这些示例实施例的SOAP净荷。
SIP UAC 204通过例如用户数据报协议(UDP)/IP或传输控制协议(TCP)/IP链路(有线或无线)，将该消息发送至作为SIP净荷的一部分而提供的SOAPAction首部所指示 的最终目的地。当然，可以存在居间节点(图2(a)中未示出)，例如SIP代理。最终目的地 (接收节点110)包含SIP用户代理服务器(UAS) 206以及SOAP端点208，SOAP端点208能 够解析该SOAP消息，并经由服务专用API将其分派至作为SIP净荷而承载的SOAPAction首 部中指示的对应Web服务，例如Web服务210或212之一。SIP UAS 206处理SOAPAction 首部，以确定是否应当继续将SOAP封包净荷传送至SOAP解析器/分派器208。对此应注 意，SIP消息的最终接收者可以与其中承载的SOAP封包的最终接收者不同或者相同。例如 在Alice呼叫慈善长时间电视节目的上述情况下，位于Alice的用户设备和与将该呼叫处 理至电视节目主持人相关联的应用服务器之间的SIP代理节点可以执行该SOAP封包向慈 善支付服务(向她收取捐赠)的路由。因此，在这后一种情况下，当居间SIP代理节点接收 到SIP/S0AP消息时，其对SOAPAction首部的分析将向该节点通知该SOAP封包应当在本 地处理，并且其解析器/分派器208将提取该SOAP封包并继续将其传送至对支付进行处理 的Web服务210、212。然后，将SIP消息继续转发至其最终目的地上，例如VoIP应用服务器 (图1(a)中未示出)。UAS 206例如可以被预先配置为包括接收节点110内当前部署的Web服务210、 212的列表，以协助处理SOAPAction首部。典型地，如图1(b)所示，将在SIP 2000K消息的 净荷中提供对SOAP消息的响应，该消息从SIP UAS 230返回至客户端。例如，由Web服务210和212提供的Web服务可以被定义为一种软件系统，该软件 系统被设计为支持网络上可互操作的机器对机器交互。在一些实现方式中，Web服务可以 作为可经由网络(如因特网)访问的Web API而被提供，并在容纳所请求的服务的远程系 统上执行。然而，在以上关于图1(a)和1(b)所示的示例实施例中，Web服务210和212是 包括SOAP解析器/分派器208和SIP UAS 206在内的接收节点的一部分。类似地，元件 200、202和204是与正在传输的S0AP/SIP消息相关联的发端节点的一部分。因此，假定SIP UAS 230在处理SOAPAction首部的过程中找到了匹配，则Web服务210、212中对应的一个 将向接收节点110提供经由SOAP封包而请求的服务。还可以认识到，可以将多于或少于2 个Web服务与给定接收节点110集成。提供接口和方法指示的SOAPAction首部以及SOAP封包可以如上所示在SIP消 息内由其自身来提供，或者利用其他内容来提供。例如，通过使用多用途因特网邮件扩展 (MIME)多部分，除了嵌入的SOAP信息之外，SIP消息还可以包含会话描述协议(SDP)或其 他内容，作为净荷。以下提供了根据示例实施例的这种类型的多部分SIP消息的示例。INVITE sip:bobibiloxi. comSIP/2. OVia:SIP/2. 0/UDP pc33. atlanta. com ；branch = z9hG4bKnashds8To:Bob<sip:bobibiloxi. com>From:Alice<sip:aliceiatlanta. com> ；tag = 1928301774Call-ID:a84b4c76e66710CSeq:314159INVITEMax-Forwards:70Date:Thu，21Feb 200213:02:03GMT
Contact:<sip:aliceipc33. atlanta. com>Content-Type:multipart/mixed ；boundary = boundary42Content-Length:568—boundary42Content-Type:message/sipINVITE sip:bobibiloxi. com SIP/2.0...Content-Type:application/sdpContent-Length:147v = 0ο = UserA 28908445262890844526IN IP4 here, coms = Session SDPc = IN IP4 pc33. atlanta. comt = 00m = audio 49172RTP/AVP 0a = rtpmap:OPCM U/8000—boundary42Content-Type:text/xmlSOAPAction : "urn : stockquote-bi Ioxi-com: QuoteBean ！ GetLastTradePrice，，< ？ xml version =" 1.0" ？ ><soap:Envelope...其中可以看到，在MIME多部分中定义的Content-Type首部提供了 一种结构，其 中，根据这些示例实施例，除了 SOAPAction首部以及可选的SOAP封包体之外，SIP消息还 可以包含净荷。基于以上描述，可以认识到，这些示例实施例提出了各种方法(例如用于通信的 方法)。图2的流程图中示意了一个这种方法。其中，在步骤300，发送包括SOAP封包和SOAP 动作首部在内的SIP消息。在步骤302接收该SIP消息，并在步骤303对SOAPAction首部 进行评估，以确定该SOAP封包是否是针对该特定接收节点的。如果是，则对该SIP/S0AP消 息进行解析，以从SIP消息中去除SOAP封包(步骤304)。然后，在步骤306，可以将该SOAP 封包继续传送至对应的Web服务。然后，在步骤308，可以将SOAP封包和SOAPAction首部 所指示的服务提供给SIP消息的接收者。当然，给定这些示例实施例的基本特征，图2中所 示的示例方法还可以进一步概括为例如图3所示。其中在步骤400，发送包括对服务进行标 识的简单对象访问协议(SOAP)封包和SOAP动作首部在内的会话发起协议(SIP)消息，即， 针对SOAP消息的会话发起协议(SIP)传输绑定。因此，显而易见，通过将Web服务(SOAP、WSDL和UDDI)与SIP进行组合，这些示例 实施例使例如应用开发者能够访问可在SIP的会话建立阶段期间交织的多种因特网服务。 此外，SIP服务组合可以通过提供用于服务的实时组合的设施，来缩短新的创新最终用户服务进入市场的时间，以及开启通过SIP的商业对商业交互。以上提供了这些技术的一些应 用示例。这里可以想到许多其他示例。例如，在集成呈现通知和多媒体会话建立的环境中， 考虑以下内容。当Alice呼叫Bob时，她也选择指示对于她的所有观看者，她的呈现应当被 设置为忙。当正在建立会话时，Alice家庭域中的应用服务器向呈现代理通知她的活动状 态为忙，即利用与SIP会话建立消息一起传送至应用服务器的SOAPAction首部和/或其 他SOAP数据元素。然后，Alice的呈现列表上所有的观看者现在将看到在呼叫持续时间内 Alice的呈现状态变化。上述和其他用于通信的示例系统和方法可以由一个或多个处理器来实现，该一个 或多个处理器执行存储器设备中包含的指令序列。这种指令是可以从其他计算机可读介质 (如辅助数据存储设备)读入存储器设备的。对存储器设备中包含的指令序列的执行使处 理器例如如上所述进行操作，以发送或接收SIP/S0AP消息。在备选实施例中，可以使用硬 连线电路来取代软件指令或与软件指令相结合，以实现这些示例实施例。还可以认识到，这些实施例可以采取各种物理形式，并可以用在例如各种消费电 子产品中，这些消费电子产品包括(但不限于)智能电话、个人数字助理(PDA)、膝上型电 脑等。一般而言，发送或接收如上所述的SIP/S0AP消息的通信设备可以包括图4所示的一 般通信设备的元件。其中，通信设备500可以包括处理器502(或多个处理器内核)、存储 器504，可选地包括一个或多个辅助存储设备506、在处理器502上运行且使用存储器504 的操作系统508、以及一个或多个对应应用程序510。可以提供接口单元512以便于设备 500与网络其余部分或其他端到端设备之间的通信，或者可以将接口单元512集成进处理 器502。如果设备500通过空中接口进行通信，则可以包括无线收发器(未示出)，作为接 口单元512的一部分。服务中间点上述示例描述了端点之间SIP/S0AP消息的交换以提供服务的实时组合，以及其 他内容。然而，SIP/S0AP消息也可以穿过多个中间点。在SIP中，这个概念可以通过例如 通过支持SOAP的SIP服务器或SIP终端发送SOAP消息来实现。可以通过SOAP角色首部 属性来标识中间点。SOAP封包(SIP消息净荷的一部分)中的角色URI标识了将充当将对 该首部进行处理的中间节点的PortType (或如上所述的接口)。与这种中间处理节点相关 联的语法可以例如描述如下soap:role = "urn!application:PortType ！ method"然后，随后的SOAP首部名称应当与角色中提出的！ method相对应，其中，首部值 是针对该方法的参数(中的至少一个)。为了提供一些上下文以有助于理解根据这些示例实施例的中间点的角色以及中 间寻址，考虑了以下服务场景。假定作为股票经纪人的Alice呼叫她的客户Bob以讨论购 买。当她发起呼叫会话(例如VoIP呼叫)时，她还选择包括两个服务，这两个服务将提供 要在呼叫开始时向Bob呈现的数据。例如，这两个服务可以是Bob的证券投资服务和Alice 的具有一些历史图表和关键数字的购买候选列表。为了实现这一点，Alice向Bob发送的 会话发起消息包括对Bob的证券投资服务和Alice的候选服务的服务请求。当该消息由相 应服务截取时，数据被收集并被插入消息体中。最终，该消息到达Bob，向Bob呈现他的证券 投资内容以及购买候选列表。同时，Bob听到Alice的问候，并且对话开始。例如，承载具有要由中间节点处理以实现该服务场景的首部的SOAP的示例SIP消息可以如下产生INVITE sip:bob@biloxi. com SIP/2.0Via:SIP/2. 0/UDP pc33. atlanta. com ；branch = z9hG4bKnashds8Max-Forwards: 70To :Bob<sip :bob@biloxi. com>From:Alice<sip:alice@atlanta. com> ；tag = 1928301774Call-ID:a84b4c76e66710
CSeq:314159INVITEContact: <sip: alice@pc33. atlanta. com>Content-Type:text/xml ；charset = utf-8SOAPAction: “urn:chargingservice-atIanta-com:ChargingService ！ addChargingRecord，，SOAPAction:"urn: stockservice-biloxi-com: QuoteBean ！ GetLastTradePrice，，〈？ xml version=" 1.0" >〈soap: Envelopexmlns:soap = “ http://schemas. xmlsoap, org/soap/envelope/"soap:encodingStyle = “ http://schemas. xmlsoap, org/soap/encoding/“ >
〈soap: Header〉<p:addChargingRecord xmlns:ρ =，，chargingservice. atlanta. com，，soap:role = ” urn:chargingservice-atlanta-com:ChargingService ！ addChargingRecord，，>〈P:chargingld>alice@atlanta. com</p:chargingld>〈P:event>quoteRequest</ρ:event></ρ: addChargingRecord)〈/soap: Header〉<soap:Body><m:GetLastTradePrice xmlns:m = “ stockservice. biloxi. com" ><symbol>ERIC B</symbol></m:GetLastTradePrice>〈/soap: Body〉</soap: Envelope)在上述代码片断示例中，第一个粗体代码行指示预期要由根据本示例实施例的中 间节点进行操作的SOAP动作首部。在相同代码片断中的再下方，对该SOAP首部进行加粗， 该SOAP首部与从该中间节点请求的服务和向该中间节点的关联寻址相对应(即S0ap:r0le 参数)。中间节点的示例实施例如图5所示，该中间节点可以用于执行如上所述的对SIP/ SOAP消息的处理。其中，中间节点600在例如连接至IP网络的计算设备(例如图4所示 的)上进行操作。中间节点600包括例如SIP代理602、SOAP解析器/分派器604以及一 个或多个Web服务604。SIP代理602是使中间节点600能够接收和代理SIP消息的实体。SIP代理602可以帮助将请求路由至用户当前位置、针对服务对用户进行认证和授权、实现 提供商呼叫路由策略、向用户提供特征以及提供注册功能等等，该注册功能允许用户上载 其当前位置以供代理服务器使用。例如，一般地，SIP代理602可以根据RFC 3261 (其公开通过引用合并于此)中规 定的针对代理的规范来执行操作。元件602的代理功能具有以下效果中间节点600(包 含SIP代理602)将不会终止会话发起的路由，而是处理SOAP封包，将结果附加至净荷(因 此修改了 SIP消息的原始内容)并转发至在SIP请求URI中指示的目的地。该代理也可以 通过使用在RFC 3261中规定的记录路由来将其自身添加至后续SIP消息收发。中间节点 (包括SIP代理)与根据这些示例实施例的端点之间的一个区别在于，端点将终止会话路 由。因此，一旦SIP消息到达端点，基于网络的数据的附加背载就不能被添加至SIP消息。 SIP中间节点600 (包括SIP代理602)可以例如实现为例如图4所示的服务器，但是也可 以 实现为相同物理节点或服务器上的、逻辑上分离的“节点”。SOAP解析器604对由SIP消息承载的SOAP封包内的SOAP首部进行解析。此外， 布置在中间点600上的还有SOAP分派器602，SOAP分派器602能够调用与被寻址(例如， 使用SOAPAction首部和具有如上述代码片断中所示的角色参数的SOAP首部来寻址)至中 间节点600的SOAP首部相关联的Web服务606。在现在将关于图6和7描述的端到端消息 收发示例的上下文中，将更好地理解中间节点600的这些和其他特征。图6示意了两个SIP端点可以经由SIP代理或中间节点600 (该节点也包括SOAP 中间点)互相连接的一种示例方式。图7是示意了与其相关联的示例方法的流程图。其中， 第一端点620 (例如Alice的节点)正在运行应用程序612，应用程序612创建包含引用中 间节点600的首部在内的SOAP封包，其中，中间节点600位于向B方(即在本示例中是使 用被指定为端点622的设备的被叫方(Bob))的路由上的SIP代理602上。Alice的客户端 应用程序612使用SIP UAC 204，例如通过IP网络610，来发送包含SOAP封包作为净荷数 据的SIP消息。当接收SIP消息(步骤700)时，SIP代理602可以首先扫描SIP消息以检 测SIP消息是否包括SOAP封包。如果SIP代理602未检测到SIP消息内的SOAP封包或净荷，并且假定SIP消息本 身不寻址至SIP代理602，则中间节点600将向前转发该SIP消息，例如向另一中间点(或 最终目的地)。另一方面，如果SIP代理602检测到SIP消息内的SOAP净荷，则SIP代理 602调用面向SOAP解析器/分派器604的API。SOAP解析器/分派器604通过由SIP代理 602调用的API来接收原始包含在SIP消息净荷中的SOAP封包，并解析该SOAP封包以查 找SOAP首部(步骤702)。因此，根据一个示例实施例，SIP代理602从SIP/S0AP消息中剥 离出SOAP封包，并仅将SOAP封包传送至SOAP解析器/分派器604以进行进一步处理。因 此，使用上述代码片断作为示例，SIP代理602可以剥离出以下代码并将其传送至SOAP解 析器/分派器604 〈soap Envelopexmlnssoap = “ http://schemas. xmlsoap. org/soap/envelope/"soap:encodingStyle = “ http://schemas. xmlsoap. org/soap/encoding/“ >〈soap: Header〉<p:addChargingRecord xmlns:ρ =，，chargingservice· atlanta·com，，soap : role =” urn :chargingservice-atlanta-com: ChargingService ！ addChargingRecord，，>〈P: chargingld>alice@atlanta. com</ ρ: chargingld>〈P:event>quoteRequest</p:event></ρ: addChargingRecord)〈/soap: Header〉<soap:Body><m:GetLastTradePrice xmlns:m =” stockservice. biloxi. com“ ><symbol>ERIC B</symbol></m:GetLastTradePrice)〈/soap: Body〉</soap: Envelope)如果SOAP解析器/分派器604找到的SOAP首部与所布置的、与该特定中间节点 600相关联的Web服务606相匹配(步骤704)，则SOAP分派器604使用服务专用API来调 用所布置的Web服务606中的对应方法(步骤706)。与导向端点622的SIP/S0AP消息内的 代码部分相比，导向中间节点600的SIP/S0AP消息内的代码部分之间的一个示例区别在于 位于SOAP首部中的角色参数，SOAP首部还包含对由PortType/Interface提供的方法的输 入参数。另一方面，端点622仅涉及对SIP/S0AP消息中的实际SOAP消息体(与SOAP首部 相对)进行处理。通过提供与包含匹配角色参数的多个SOAP首部配对的多个SOAPAction 首部，可以对来自端点之间的路由上的多个中间点的处理进行链状相接，以提供每个中间 点能够访问的服务。因此，再次使用上述示例代码片断，SOAP解析器/分派器604可以经 由其API，将中间节点600接收的SIP/S0AP消息的以下部分继续向对应的Web服务606传 送<soap: Header)<paddChargingRecord xmlns:p = “ chargingservice. atlanta. com，，soap:role ="urn:chargingservice-atlanta-com:ChargingService ！ addChargingRecord，，><p:chargingld>aliceiatlanta. com</ ρ:chargingld><p:event>quoteRequest</ρ:event></ρ:addChargingRecord)</soap:Header)在完成对在SOAP封包内提供的服务请求的处理之后，Web服务606可以将结果转发至路由上的下一 SIP节点。例如，可以通过对中间节点600接收到的原始SIP消息进行 修改(步骤708)，例如通过将从Web服务606接收到的结果附加至原始SIP消息的净荷，来 发送该结果。然而，可以认识到，在特定情况下，在SOAP首部中指示的SOAP方法的中间处理不返回结果。在这种情况下，不需要将结果附加至SIP消息净荷。如果接收到的SIP/S0AP消息中的原始SOAP封包包含了与可经由该特定中间节点600访问的Web服务相匹配的SOAP动作首部，则SIP代理602将具有修改后的净荷的SIP 消息沿其路由进一步代理至最终目的地。当SIP消息到达其原始目的地时，端点622处的 处理可以如以上关于图1-4所述的那样进行。可以认识到，尽管在图6的示例实施例中仅 示意了单一中间节点600，但是典型实现方式可以包括沿端点间的路由布置的多个中间节 点600，其中的一些或全部可以访问不同的Web服务，并将如上所述对接收到的SIP/S0AP消 息进行操作。此外，消息端点622处的接收UAS 206也将具有对接收到的SIP/S0AP消息内 的多个SOAP封包进行扫描的能力，这些封包包含来自沿途经过的中间点的结果。使用UDDI的服各发现根据这些示例实施例，为了提供动态服务组合，还提供了供客户端和应用程序发 现现有服务的能力。更具体地，示例实施例提供用于使用UDDI来发现这种服务的方法、系 统、设备和软件，其中SIP作为传输。通过在根据这些示例实施例的SIP消息中使用UDDI API请求作为净荷，UDDI注册中心可以例如驻留在支持基于SIP的SOAP的移动设备上的 SIP服务器上。用户可以向注册中心发送包含针对服务的UDDI查询在内的SIP消息。UDDI 查询API提供了例如fincLservice方法，该方法用于发现与针对特定商业实体而提供的准 则相匹配的服务。例如，categoryBag自变量包含对服务能力进行描述的属性。为了示意 这些服务发现技术，图8提供了示例实施例，示出了分别包含应用程序804和UDDI注册中 心806的两个端点800和802。其中，所谓A方设备800(即主叫方)包括用于向B方802(即被叫方)发起会话 (例如SIP会话)的应用程序804。应用程序804使用UDDI客户端805，UDDI客户端805创 建 UDDI find_service 请求。UDDIf ind_service 请求被传送至 SIP UAC 807，SIP UAC 807 在将该请求发送至B方端点802之前，将该UDDI请求嵌入SIP INVITE净荷中的SOAP封包 内。例如，应用程序804可以呼叫UDDI客户端805，以创建包含find_service请求在内的 SOAP封包。SOAP封包被返回至应用程序804，应用程序804接着将该封包继续传送至SIP UAC 807, SIP UAC 807继而将构造SIP INVITE消息并附加该SOAP封包作为净荷数据。B方设备802包含SIP UAS 808，SIP UAS 808接收包括UDDI请求在内的SIP INVITE消息并解析净荷。如果在接收到的SIP消息中找到SOAP封包，则通过API将该SOAP 封包传送至SOAP解析器/分派器810。SOAP解析器/分派器810从SOAP封包内解析出 UDDI fincLservice请求，并调用其分派器(示意为SOAP解析器810的一部分，但是可以 被实现为单独实体)。SOAP解析器/分派器810的分派器部分经由关联的API来调用位于 B方设备上的UDDI注册中心806，这导致服务(例如上述Web服务)的列表被返回至SOAP 解析器/分派器810。当B方设备或端点802上的UDDI注册中心806返回该消息时，SOAP解析器/分 派器810将所返回的ServiceList嵌入SOAP封包中。然后将该SOAP封包传送至SIP UAS 808，SIP UAS 808继而将该SOAP封包放入SIP 2000K响应的净荷中。这后一消息收发事 件在图9中示意，其中使用相同的参考标号来表示与以上关于图8示出和描述的相同或类 似的元件。更详细的示例将提供对与服务发现相关的这些示例实施例的进一步了解。考虑与示例场景相关联的以下代码片断示例，其中Alice从她的设备/端点802发送SIP INVITE 消息，该消息包括UDDI find_service请求，以向Bob的端点802和对应的UDDI注册中心 806查询哪些服务经由Bob的端点802可用/可访问。INVITE sip:bobibiloxi. com SIP/2.0Via:SIP/2. 0/UDP pc33. atlanta. com ；branch = z9hG4bKnashds8Max-Forwards: 70To:Bob<sipbobibiloxi. com>From:Alice<sip:aliceiatlanta. com> ；tag = 1928301774
Call-ID:a84b4c76e66710CSeq:314159INVITEContact:<sip:aliceipc33. atlanta. com>Content-Type:text/xml ； charset = utf-8SOAPAction: "urn:bob-biloxi-com:UDDI_inquiry_api ！ find_service"< ？ xml version = " 1.0〃 encoding = " utf-8 “ ？ ><soap:Envelopexmlns:xsi = http://www. w3. org/2001/XMLSchema-instancexmlns:xsd = http://www. w3. org/2001/XMLSchemaxmlns: soap =" http://schemas.xmlsoap.org/soap/envelopc/" ><soap:Body><find_service businessKey =" Keyl"generic = " 2.0〃maxRows = " 15〃xmlns=" urn:uddi-org:api_v2" ><findQualifiers><findQualifier/><findQualifier/></findQualifiers>〈name = " " />〈name = " " /><categoryBag><keyedReference tModel Key=" tModel Keyl"keyName = " tModeIKeyl Name"keyValue = " tModelKeyl Value" /><keyedReference tModelKey = " tModel Key2"keyName = " tModelKey2Name "keyValue = " tModelKey2Value" /></categoryBag>
<tModelBag><tModelKey>tModelKey3</tModelKey><tModelKey>tModelKey4</tModelKey></tModelBag></find_service>〈/soap: Body〉</soap:Envelope)其中，粗体代码行是SOAPAction首部，该SOAPAction首部指示了在从端点800发 送至端点802的SIP/S0AP消息中包括嵌入的UDDIfincLservice请求。来自Bob的端点 802的对应代码响应例如可以表示如下SIP/2. 0 2000KVia:SIP/2. 0/UDP serverlO. biloxi. com ；branch = z9hG4bK4b43c2ff8. 1；received = 192. 0. 2. 3Via:SIP/2. 0/UDPbigbox3. site3. atlanta. com ；branch = z9hG4bK77ef4c2312983. 1；received = 192. 0. 2. 2Via:SIP/2. 0/UDP pc33. atlanta. com ；branch = z9hG4bKnashds8；received = 192. 0. 2. 1To:Bob<sip:bobibiloxi. com>:tag = a6c85cfFrom:Alice<sip:aliceiatlanta. com> ；tag = 1928301774Call-ID:a84b4c76e66710CSeq:314159INVITEContact:<sip:bobil92. 0. 2. 4>Content-Type:text/xml ； charset = utf-8Content-Length:131< ？ xml version = " 1.0〃 encoding = " utf-8 “ ？ ><soap:Envelopexmlns:xsi = http://www. w3. org/2001/XMLSchema-instancexmlns:xsd = http://www. w3. org/2001/XMLSchemaxmlns: soap =" http://schemas.xmlsoap.org/soap/envelope/" >〈soap: Body〉<serviceList generic=" 2.0〃operator = " MyCompany"truncated = " false"xmlns = " urn: uddi-org: api_v2 " ><serviceInfos><serviceInfo serviceKey =，，ServiceKeyl "businessKey =，，Keyl" >
〈name = “ “ />〈name = “ “ /></serviceInfo><serviceInfo serviceKey =" ServiceKey2"businessKey =" Key2" >〈name = “ “ /><name=〃 “ /></serviceInfo></serviceInfos></serviceList>〈/soap: Body〉</soap:Envelope)UDDI注册中心806也可以位于中间节点而不是位于如上所述且在图8和9中示意 的端点中。在这些示例实施例中，UDDI find_service请求和对应的响应可以被嵌入在例如 在端点(例如A方和B方)之间发送的SIP INVITE和SIP 2000K消息内。图10示出了包 含UDDI注册中心的中间节点1000。其中，与端点1002相关联的应用程序1001 (例如与移 动设备相关联的操作系统)使用UDDI客户端1004来创建UDDIfincLservice请求。UDDI find_service请求被嵌入SOAP封包中并被放入由SIP UAC 1006经由IP网络1007发送的 SIP INVITE消息的净荷中。作为位于SIP端点1002和1010之间的路由上的中间节点1000 的一部分，SIP代理1008截取该SIP消息。SIP代理1008检测净荷中的SOAP封包，并将其 发送至SOAP解析器/分派器1012。SOAP解析器/分派器1012解析出UDDI find_service 方法，并向UDDI注册中心1014调用该UDDIfincLservice方法。UDDI注册中心1014返回 其服务列表，例如，可经由其他API从中间节点1000得到的Web服务的列表，并且，将得到 的服务列表存储在例如SOAP解析器/分派器1012中。SIP代理1008通过将记录路由首部 添加至原始SIP消息，将其自身添加至SIP信令路径，然后，SIP消息的修改版本被代理至 原始目的地(在本示例中是端点1010)。根据这些示例实施例，为了将服务发现请求寻址至中间UDDI注册中心1014，可以 以与用于对中间节点600进行寻址的上述方式类似的方式，在SOAP封包内提供SOAP首部。 然而，可以将附加参数添加至SOAP首部，以通知与所寻址的中间节点1000相关联的SOAP 解析器/分派器1012存储ServiceList并将所存储的ServiceList与当前SIP对话相关 联。例如，考虑以下代码片断，其中，在封包(以下示出)中将SOAPAction首部与SOAP首 部进行配对，以实现服务发现请求向中间节点的这种寻址<soap:Header)<pfind—service xmlns:p =" sip-proxy, atlanta. com"soap:role = "urn:sip-proxy-atlama-com:UDDI_inquiry_api ！ f ind_ service，，><p:S0APRcsult>callback</p:SOAPResult></p:find_service></soap:Header)
注意，在上述代码中，参数“SOAPResult”的值为“callback(返回调用)”。这是一 种示例机制，通过这种机制，SOAP解析器/分派器1012将识别出它们要以上述方式进行操 作，并可以被UDDI客户端1004添加至服务发现请求。例如，当看到SOAP首部中的该参数 时，SOAP解析器/分派器1012将自动存储来自soap:role所指示的web服务的结果，并产 生将被传送至SIP代理1008的返回调用(函数指针或对象引用)。该返回调用具有当接收 到与该返回调用相关联的对话的响应时SIP代理1008正在调用的一般方法。该返回调用 由SOAP解析器/分派器1012实现，SOAP解析器/分派器1012将所存储的来自web服务 的结果插入SIP消息的净荷中。此外，提供了 SOAP动作首部中的参数以告知SIP代理1008对其自身进行记录路 由，即，将其自身放置在对话的返回路径上。向SOAPAction首部添加的参数可以例如如下 所示地实现
SOAPAction: "urnsip-proxy-atlanta-com:UDDI_inquiry_api ！ find_service" ；record-route注意被附加至SOAPAction首部的记录路由参数。记录路由参数在SOAPAction首 部中的存在将请求与在SOAPAction首部值中引用的urn相匹配的中间节点1000将记录 路由首部添加至被转发给由SIP URI指示的目的地的SIP消息。例如，创建服务发现请求 的节点的SIP UAC1006可以将记录路由参数添加至SOAPAction首部。如图11所示，当将SIP 2000K响应从B方端点1010返回时，由于被添加至原始 SIP/S0AP消息的记录路由首部，使得该响应经过SIP代理1008。SIP代理1008使用先前存 储的返回调用(例如函数指针或对象引用)来调用保存来自先前fincLservice调用的结 果的SOAP解析器/分派器1012。SOAP解析器/分派器1012将UDDI ServiceList插入被 放入SIP 2000K净荷中的SOAP封包中。因此，根据示例实施例的服务发现方法可以包括图12的流程图所示的步骤。其 中，在步骤1200，接收包括简单对象访问协议(SOAP)封包和SOAP动作首部在内的会话发 起协议(SIP)消息，该SOAP动作首部指示SIP消息包括统一描述、发现和集成(UDDI)服务 发现请求。在步骤1202，对该SOAP封包进行解析以标识SOAP封包内的SOAP动作首部，例 如，该SOAP动作首部指示服务发现请求是对接收节点发出的。响应于此，在步骤1204，访 问UDDI注册中心以获得服务列表。在步骤1206，例如如上所述直接或间接地转发该服务列 表。通过将SIP与UDDI相结合，根据这些示例实施例的服务发现变得与实时通信会话 发起密切相关。这意味着，根据被叫方的可用服务或者通过路由上的某个中间点，可以对会 话进行重新协商。此外，被叫方自身的设备或路由上的服务中间点可以将SIP和UDDI服务 的结合添加至会话发起。这开启了对服务和实时通信将结合的多种可能性，以提供更丰富 的用户体验以及可能的服务和通信场景的数目增加。上述示例实施例在所有方面都是示意而非限制本发明。因此，本发明能够在详细 实现中进行许多变型，本领域技术人员从这里包含的描述中可以导出这些变型。所有这种 变型和修改都被视为在所附权利要求所限定的本发明的范围和精神之内。除非有明确描 述，在本申请的描述中使用的元件、动作或指令不应被解释为对于本发明而言是至关重要 或必不可少的。此外，如这里所使用的，冠词“一”应包括一项或多项。
权利要求
一种服务发现方法，包括接收会话发起协议(SIP)消息(1200)，所述会话发起协议(SIP)消息包括简单对象访问协议(SOAP)封包和SOAP动作首部，所述SOAP动作首部指示所述SIP消息包括统一描述、发现和集成(UDDI)服务发现请求；解析所述SOAP封包，以标识所述SOAP封包内的所述SOAP动作首部(1202)；访问UDDI注册中心以获得服务列表(1204)；以及转发所述服务列表(1206)。
2.根据权利要求1所述的方法，其中，所述SIP消息是SIPINVITE消息。
3.根据权利要求1所述的方法，其中，所述SIP消息是与会话不相关的SIP消息。
4.根据权利要求3所述的方法，其中，所述SIP消息是OPTIONS消息和MESSAGE消息之一。
5.根据权利要求1所述的方法，其中，所述SIP消息还包括会话描述协议(SDP)。
6.根据权利要求5所述的方法，其中，所述SIP消息是使用MIME多部分来构造的。
7.根据权利要求1所述的方法，其中，所述转发所述服务列表的步骤还包括 将所述SIP消息修改为包括记录路由首部；接收对所述SIP消息的响应； 将所述服务列表添加至所述响应；以及 转发所述响应。
8.根据权利要求1所述的方法，其中，所述服务列表是在接收所述SIP消息的节点处可 用的Web服务的列表。
9.根据权利要求1所述的方法，其中，所述S0AP封包包括参数，所述参数指示中间节点 存储所述服务列表并响应于所述SIP消息而转发所述服务列表。
10.一种通信节点(500、802、1000)，包括作为下列之一进行操作的处理器(502)会话发起协议(SIP)代理(1008)和SIP用户 代理服务器(UAS，808)；所述处理器(502)接收SIP消息，所述SIP消息包括简单对象访问 协议(S0AP)封包和S0AP动作首部，所述S0AP动作首部指示所述SIP消息包括统一描述、 发现和集成(UDDI)服务发现请求；S0AP解析器/分派器(810、1012)，用于从所述SIP消息中解析所述S0AP封包；以及 UDDI注册中心(806、1014)，响应于所述UDDI服务发现请求，提供能够经由所述通信节 点而访问的服务列表。
11.根据权利要求10所述的通信节点，其中，所述服务列表包括Web服务的列表，还包括能够经由所述通信节点而访问的多个Web服务实体中的每一个与所述S0AP解析器/ 分派器之间对应的应用编程接口(API)。
12.根据权利要求10所述的通信节点，其中，如果所述处理器(502)作为SIP代理进行操作，则所述处理器(502)将所述SIP消息修改为包括记录路 由首部，接收对所述SIP消息的响应，将所述服务列表添加至所述响应，并转发所述响应。
13.根据权利要求10所述的通信节点，其中，如果所述处理器(502)作为SIP UAS进行操作，则所述处理器(502)将所述SIP消息修改为包括所述服务列表。
14.根据权利要求10所述的通信节点，其中，所述SOAP封包包括参数，所述参数指示中 间节点存储所述服务列表并响应于所述SIP消息而转发所述服务列表。
15.根据权利要求10所述的通信节点，其中，所述SIP消息是SIPINVITE消息。
16.根据权利要求10所述的通信节点，其中，所述SIP消息是与会话不相关的SIP消信息
17.根据权利要求16所述的通信节点，其中，所述SIP消息是OPTIONS消息和MESSAGE 消息之一。
18.根据权利要求10所述的通信节点，其中，所述SIP消息还包括会话描述协议 (SDP)。
19.根据权利要求18所述的通信节点，其中，所述SIP消息是使用MIME多部分来构造的。
全文摘要
本发明通过针对简单对象访问协议SOAP消息的会话发起协议SIP传输绑定，提供了实时服务组合。可以在SIP消息中包括SOAP动作首部和SOAP封包，以标识所请求的服务。SIP消息接收者可以解析出SOAP封包，并将其转发至对应的Web服务。包括SIP代理在内的中间节点可以对输入的SIP/SOAP消息进行评估，并提供其能够访问的所请求的服务。通过添加统一描述、发现和集成(UDDI)服务请求和响应，来便于服务发现。
文档编号H04L29/06GK101836423SQ200880112981
公开日2010年9月15日 申请日期2008年9月11日 优先权日2007年10月26日
发明者托尔比约恩·达伦 申请人:艾利森电话股份有限公司