用于使用uddi来调解web服务的方法和设备的制作方法

专利名称：用于使用uddi来调解web服务的方法和设备的制作方法
技术领域：
本发明涉及用于对Web (网络)服务进行支持的方法和设备，尤 其涉及Web服务的动态服务质量(QoS)的管理。
背景技术：
万维网联盟(W3 C )已经将Web服务定义为被设计为支持网络上 可协同操作的机器到机器的交互的软件系统。Web服务通常仅是在能 够通过诸如因特网之类的网络被访问并且能够在宿主(host)所请求 服务的远程系统上执行的应用编程接口 (API)。例如，Web服务的 示例包括由旅行社通过因特网所提供的机票预订服务、用于建立3G 运营商所提供的HSDPA (高速下行链路分组接入)连接的呼叫建立 服务、以及用于在两个终端用户之间建立多媒体会话的服务。
已经研发了多种不同的协议和格式来管理Web服务。
UDDI (统一描述、发现和集成协议)是为用于发布和发现关于 Web服务的元数据的协议。UDDI服务器担当Web服务的服务代理 (service broker)。服务提供者能够在UDDI服务器中注册(register) 与其服务相关的信息，并且服务请求者能够联系UDDI服务器以便根 据在UDDI服务器中所存储的信息来寻找适当的服务。
WSDL (Web服务描述语言)是用于描述待提供的Web服务的 XML (可扩展标记语言)格式。例如，服务请求者可以从UDDI服务 器或从服务提供者接收WSDL文件作为服务请求的结果。WSDL文件 将对服务请求者需要了解以便使用Web服务的细节进行解释。
SOAP (简单对象访问协议)是能够被用于例如服务提供者与服 务请求者之间的通信的基于XML的消息封装格式。
UDDI服^器上的服务相关的信息。、这意味着关于服务的信P息被存;者 在UDDI服务器中并且能够在服务请求者在对所期望的服务进行搜索 中联系UDDI服务器时被搜索。如果在UDDI服务器接收到服务请求 时找到一个或数个适当服务，则其能够例如通过向服务请求者发送每个适当服务的服务提供者的地址或与每个服务相关联的WSDL文件 或URL (统一资源定位符)来进行响应。
在UDDI服务器中所存储的关于服务的信息通常将包括如下数 据例如提供服务的公司名称、服务类型以及连接到所述服务所需的 信息(例如，URL)。所述信息还可以包括QoS信息，例如Web服 务容量(即，能够支持的同时请求的数目)、关于Web服务的鲁棒性 的信息以及与Web服务的性能相关的信息。W3C的文献"QoS for Web Services: Requirements and Possible Approaches ，， http:〃www.w3c.or.kr/kr-office/TR/2003/ws画qos/描述了对于web服务的 QoS要求。
美国专利申请US2005/0235053公开了 一种用于搜索Web服务的 方法和机制，其使得服务请求者可以连同有关每个服务的服务历史的 信息一起接收可能服务的列表。服务请求者接着能够根据所接收的信 息从所述列表中选择服务。出于该目的，服务提供者将收集有关过去 所递送的服务质量的信息，即，所述服务的实际操作所产生的服务历 史，并将该信息提供给UDDI站点。
然而，从服务请求者的角度来看，现有技术的用于搜索Web服务 的机制具有缺陷，原因在于它们没有特别关注服务请求者的兴趣和需 求。服务请求者可能对特定服务具有特别的QoS要求。但是利用当今 可用的Web服务解决方案，服务请求者难以找到满足他/她的要求的 Web服务。例如，服务请求者可能希望使用Web服务来建立两个终 端用户之间的多媒体会话。请求者对于会话具有特定的QoS要求，如 传输速率、分组丟失、传输延迟和抖动延迟。利用以上所提到的W3C 文献和美国专利申请中所描述的Web服务解决方案，服务请求者通常 能够接收到与web服务的容量相关的某些信息或者与服务在过去所能 够提供的QoS相关的信息，但是这将不会为请求者给出任何关于请求 者针对他/她的会话将接收到的QoS的信息。Web服务容量根据当前 进行中的会话的数量及其QoS要求而动态变化。历史上已经提供了最 佳QoS的服务可能在请求者希望建立多媒体会话的时候由于那时大 量进行中的会话而并非是他/她的最佳选择。如果存在若干服务提供 者，则服务请求者希望从能够最佳满足他/她的QoS要求的服务提供 者那里获得服务。服务请求者将可能不会对诸如所能够支持的同时请求数量之类的一般QoS要求感兴趣。他/她主要会对现在他/她能够从 服务提供者获得的最佳服务质量是什么感兴趣。

发明内容
如以上所提到的，从服务请求者的角度来看，当今可用的Web 服务解决方案并未关注QoS支持。因此，本发明的目的是提供用于支 持Web服务中的动态QoS要求的方法和设备。
借助于根据本发明的UDDI服务器和UDDI服务器中的方法来实 现上述目的。
本发明的第一实施例提供了一种用于对由多个服务提供者向多 个服务请求者提供的Web服务进行调解(mediate)的UDDI服务器。 UDDI服务器包括用于存储与Web服务相关联的信息的Web服务寄存 器。Web服务寄存器包括用于存储分别与每个Web服务相关联的QoS 状态信息的数据集合。QoS状态信息是关于相关联的Web服务能够为 服务请求者提供的当前QoS的信息。UDDI服务器还包括用于根椐从 服务提供者接收的动态服务状态信息对存储在所述数据集合中的QoS 状态信息进行周期性地更新的装置。
本发明的第二实施例提供了一种在用于对由多个服务提供者向 多个服务请求者提供的Web服务进行调解的UDDI服务器中的方法。 所述方法包括在UDDI服务器中注册至少一个Web服务的步骤。该注 册步骤包括存储与每个Web服务相关联的信息，所述信息包括与每个 Web服务相关联的QoS状态信息。QoS状态信息是关于相关联的Web 服务能够向服务请求者提供的当前QoS的信息。此外，所述方法包括 根据分别从每个Web服务的服务提供者接收的动态服务状态信息对 所存储的QoS状态信息进行周期性地更新的步骤。
本发明进一步的实施例提供了 一种用于响应于服务请求而选择 满足服务请求者的QoS要求的Web服务的方法和UDDI服务器。
本发明的优势在于允许将动态QoS纳入考虑的Web服务调解 (mediation)。本发明提供了对QoS供应的支持，这使得UDDI服务 器可以通过将服务提供者与满足服务请求者要求的Web服务进行匹 配而为服务请求者提供更好的服务。
本发明的另 一个优势在于其提供了对服务提供者的资源进行更好的资源管理的工具。根据本发明，由于可以考虑到不同服务提供者 的容量，所以服务请求可以更好地在不同服务提供者之间分布。因此， 可以避免因服务请求而使不具有可用容量的服务提供者过载，而是作 为替代将服务请求导向具有可用容量的服务提供者。这可能对各方都 会更为有利的，原因在于向服务请求者提供质量很差的服务或者根本 不提供服务会损害服务提供者的声誉。
本发明实施例进一步的优势在于它可以提供对Web "良务的更快 递送，原因在于可以避免对Web服务的不必要的请求。由于根据本发 明实施例的UDDI服务器能够给出与满足服务请求者的QoS要求的 Web服务相关的信息，所以这是可能的。因此，服务请求者可以避免 向无法支持该服务请求者的要求的Web服务做出请求。
本发明实施例又另一优势在于可能提供通过偏好(preference)寄 存器来定制(customize)对Web服务的请求。
通过阅读以下结合附图所进行的详细描述，本发明实施例的更多 优势和特征将变得显而易见。


图1是图示用于实现Web服务的一般系统体系结构的示意性框图。
图2是图示根据本发明实施例的用于实现Web服务的系统体系结 构的示意性框图。
图3a是图示根据本发明实施例的QoS模型的第一示例的示意性 框图。
图3b是图示根据本发明实施例的QoS模型的第二示例的示意性 框图。
图4是图示根据本发明的UDDI服务器中的方法实施例的流程图。
图5是图示根据本发明的可替换实施例的用于实现Web服务的系 统体系结构的示意性框图。
图6是图示根据本发明实施例的UDDI服务器(如图5所示的 UDDI服务器)中的方法的流程图。
图7是图示根据本发明实施例的UDDI服务器中用于管理请求队 列的方法的流程图。
具体实施例方式
现在将参考其中示出了本发明优选实施例的附图对本发明进行 更为全面的描述。然而，本发明可以以许多不同形式来实现，并且不
应被理解为局限于这里所阐释的实施例；相反，对于本领域技术人员 而言，提供这些实施例以使得本公开内容全面和完整并且将全面传达 本发明的范围。在附图中，相同的附图标记表示相同部件。
图1示意性图示了用于实现Web服务的一般体系结构。服务提供 者11已经实施了供其他人经由诸如因特网之类的网络开放使用的 Web服务lla。为了推广Web服务，服务提供者向担当Web服务代 理的UDDI服务器12注册Web服务lla。注册步骤13可以包括月良 务提供者传送诸如服务提供者名称、服务类型和访问服务所需信息之 类的信息。服务提供者还可以向UDDI服务器传送描述Web服务的 WSDL文件。UDDI服务器12存储从服务提供者12所接收的关于Web 服务lla的信息以及与Web服务器寄存器14中由其他服务提供者所 提供的其他Web服务相关的信息。希望使用特定类型的Web服务的 服务请求者15可以通过向UDDI服务器12发送搜索请求16来寻找 适当的服务。例如，假设服务请求者可能想要在线预订机票，Web服 务lla为旅行预订服务并且服务提供者12例如是旅行社。搜索请求 16于是将指示服务请求者想要搜索旅行预订服务。UDDI服务器12 将针对旅行预订服务检查Web服务寄存器14并在搜索响应17中返回 与所注册的任何旅行预订服务相关的信息。在这种情况下，UDDI服 务器12将在搜索响应17中发送关于Web服务lla并且可能还与向 UDDI服务器注册的其他旅行预订服务相关的信息。根据UDDI服务 器对特定Web服务所存储的信息类型，搜索响应例如可以包括诸如服 务提供者名称、用于访问服务或WSDL文件的URL之类的信息。搜 索响应17后面可以是，服务请求者15连接18到服务提供者11以请 求使用Web服务lla。服务提供者11接着可以通过向服务请求者15 发送WSDL文件来进行响应，所述WSDL文件向服务请求者提供了 使用所述服务所需的所有信息。在这种情况下，WSDL文件例如可以 指定诸如期望起飞时间、目的地和航线之类的参数，服务提供者应当 在使用Web服务lla时发送这些参数。根据WSDL文件中的信息，可以在服务请求者15处建立Web服务客户端20。在服务请求者已经 从UDDI服务器12接收到描述服务的WSDL文件的情况下，服务请 求者能够接着开始直接使用Web服务而无需首先联系服务提供者以 接收WSDL文件。
应当注意的是，有许多不同方式来实现Web服务并且图1和以上 描述仅构成一个示例。
如以上所提到的，从服务请求者的角度来看，当今可用的Web 服务解决方案没有关注QoS支持。然而，本发明的实施提供了用于支 持Web服务中的动态QoS要求的方法和UDDI服务器。
图2是图示根据本发明实施例的UDDI服务器21的示意性框图。 所述UDDI服务器包括Web服务寄存器22，其中存储与由不同服务 提供者24所提供的Web服务23相关的信息。Web服务寄存器对于 向UDDI服务器所注册的每个Web服务而言具有一个记录25。每个 记录25包括服务规范26,其是包含与服务相关的诸如服务类型、月良 务提供者名称、到服务的URL等之类的完全静态的数据的数据集合。 根据本发明的该实施例的Web服务寄存器中的记录还将包括含有与 相关联的Web服务能够向服务请求者提供的当前QoS相关的QoS状 态信息的服务状态数据集合27。与在服务规范26中存储的数据相比， 在服务状态数据集合27中存储的数据通常是高度动态的。对于用于 HSDPA连接的呼叫建立的Web服务而言，服务状态数据集合例如可 以包括诸如Web服务所能够提供的当前传输速率之类的数据。该传输 速率依赖于同时进行的会话数量并且由此将随Web服务负载的变化 而变4匕。
根据从不同服务提供者所接收的更新信息对存储在服务状态数 据集合中的QoS状态信息进行周期性地更新。例如，这些更新可以响 应于从服务提供者接收到周期性地自动推送(push)消息而发生，或 者借助于UDDI服务器所进行的周期性地主动拉取(pull)来进行。 向UDDI服务器传输经更新的动态QoS状态信息的模式可以取决于 Web服务。例如，可以使用推送来更新经常被i青求的流行Web服务 的QoS状态信息，而拉取则被用于更新QoS状态更新并非那么关4建 的不常被请求的服务。但是许多用于向UDDI服务器传输更新的不同 方案也是可能的，并且所实施的方案是选择的问题。QoS状态信息例如可以被承载于不同服务提供者与UDDI服务器之间的SOAP消息中。
UDDI服务器21任选地还可以包括QoS模型寄存器28。 QoS模型寄存器包括多个预定义QoS模型29。 QoS模型均指定多个QoS参数字段并且表示Web服务的QoS简档(profile) 。 QoS模型可以作为服务状态数据集合27的模板。使用具有预定义QoS模型集合的QoS模型寄存器将简化服务状态数据集合27的处理。
如所提到的，QoS模型寄存器28中的每个条目(即，每个QoS模型)具有表示Web服务的QoS简档的多个字段。图3a和3b图示了 QoS模型的两个示例。图3a图示了尤其适于描述用于建立数据连接的服务的QoS简档的QoS模型31。 QoS模型31包括用于存储传输速率、分组丟失、传输延迟、峰值速率和平均速率的字段32、 33、 34、34a和34b。图3b图示了尤其适于描述用于建立多媒体会话的服务的QoS简档的QoS模型35。 QoS模型35包括用于存储传输速率、分组丢失、传输延迟和抖动延迟的字段36、 37、 38和39。所^使用的QoS参数由此将取决于Web服务的类型。可能相关的一些其他QoS参数示例为最大速率、平均速率、最小速率、分辨率、采样速率等，或者与音频、视频和数据的质量相关的参数。
许多不同服务使用相同的QoS模型是可能的。使用相同的QoS模型将使得更容易对相同类型的Web服务进行比较。如果Web服务对应于若千不同类型的服务的组合，则Web服务与若干QoS模型相关联也是可能的。
如果使用QoS模型寄存器28，则优选地，当新的服务在UDDI服务器12处被注册时，其必须与至少一个QoS模型29相关联。如果没有一个QoS模型与所述服务相符(fit)，则能够创建新的QoS模型并将其存储在QoS模型寄存器28中。优选地，这应当由UDDI服务器以受控的方式来进行。
不保证QoS要求的服务23可以与QoS模型寄存器28中的NULL(空)条目相关联。
一旦注册了服务并选择了 QoS模型，UDDI服务器就将使用所选择的QoS模型作为模板来创建用于QoS监视的服务状态数据集合27。服务状态数据集合27被链接(link)到所注册的服务。如以上所提到的，服务状态数据集合27的内容将根据从Web服务的提供者周期性地接收的或在请求时所接收的信息而被动态更新。服务状态数据集合的内容将指示相关联的Web服务当前所能够支持的最高QoS要求。
当使用QoS模型时，服务请求者40的设备可适于将QoS要求的集合直接包括在服务请求41中。可替换地，服务请求者可以针对没有QoS要求的特定类型的服务向UDDI服务器发送服务请求，并且UDDI服务器可以通过向服务请求者发送包括与所请求服务类型相对应的QoS模型的消息42来对服务请求进行响应，以便指示服务请求者可以在QoS要求的集合中指定什么QoS参数。服务请求者将接着通过在响应消息43中指定期望的QoS要求来进行响应，并且UDDI服务器21在已经从服务请求者40接收到期望的QoS要求之后将开始查找适当的服务。
根据以上描述，对于本领域技术人员而言将会很明显的是，本发明的实施方式需要对根据现有技术的UDDI服务器进行一些适配。自然选择是通过向UDDI服务器提供新的软件来实施本发明，不过以固件、硬件或其组合的实施方式也是可行的。例如，UDDI服务器21将必须被适配成使得Web服务寄存器被安排为存储QoS状态信息。UDDI服务器还将必须被配备以用于与服务提供者进行通信以接收和更新QoS状态信息的装置。这样的更新装置在图2中示意性图示并且由附图标记44来表示。所述更新装置通常以软件来实施，并且优选地被安排为使用已有的用于与服务提供者进行通信的接口 。
除UDDI服务器中的适配之外，还要求服务提供者的设备的一些适配，原因在于服务提供者应当能够向UDDI服务器提供服务状态信息，并且周期性地向UDDI服务器发送该信息的更新。此外，服务提供者还应当具有必要装置以便例如在其当前可用容量方面跟踪(keeptrackof)其自己的QoS状态。还有必要对服务请求者的设备进行一定的适配。根据本发明的实施例，服务请求者应当具有用于向UDDI服务器传送QoS要求的装置。如果使用QoS模型，则服务请求者例如应当能够获得QoS模型并且将QoS要求表示成与适当QoS模型相对应。对本领域技术人员很明显的是，这样的适配通常在软件中进行。
图4是图示根据本发明的UDDI服务器中的方法实施例的流程图。在步骤401,开始在Web服务寄存器中注册新的Web服务。这可以通过UDDI从服务提供者接收注册请求而被发起。根据该实施例，所
述方法接着在步骤402继续，其中搜索QoS模型寄存器，以查明是否存在与待注册的Web服务相符的预定义QoS模型。如果没有找到相符的QoS模型，则创建相符的QoS模型并将其存储在QoS模型寄存器中，步骤403。在步骤404中选择相符的QoS模型与所述Web服务相关联。在步骤405中，根据所选择的QoS模型为所述Web服务创建服务状态数据集合。接着，将从服务提供者所提供的QoS状态信息存储在服务状态数据集合中，步骤406。此后，完成Web服务的注册，除其他之外，这尤其可以包括在Web服务寄存器中存储以上所提到的Web服务的服务规范，步骤407。当注册完成时，所述方法将继续以更新步骤408,其中根据通过UDDI服务器所发起的主动拉取或服务
信息，对所存储的服务的QoS状态信息进行周期性地更新。
以上所提到的对UDDI进行适配以存储和监视与Web服务能够提供给服务请求者的当前QoS相关的信息将使得UDDI可以向服务请求者提供更好的服务请求响应。然而，如果如图5所示以及以下将要描述的那样在UDDI服务器中实施多个附加特征，贝'J UDDI能够向服务请求者提供甚至更好的服务。
图5是根据本发明的可替换实施例的UDDI服务器50的示意性框图。UDDI服务器50包括Web服务寄存器22,其列出不同Web服务提供者24-1， ...， 24-N所提供的多个Web服务。多个服务请求者40-1, ...， 40-M可以联系UDDI以便寻找期望的Web服务。Web月良务寄存器22包括每个所注册Web服务的记录25,其中每个记录25包括服务规范26和服务状态数据集合27，所述服务状态数据集合27具有如上所述的被动态更新的内容。根据本发明的该实施例，UDDI服务器50还包括决策制订功能(decision making function DMF ) 51。DMF 51被安排成使用在服务状态数据集合27中所存储的QoS状态信息和服务请求者所提供的QoS要求来为服务请求者选择Web服务。
当UDDI从例如服务请求者40-1接收到对于期望服务类型的服务请求Rl以及QoS要求集合时，DMF 51将处理所述服务请求并从Web服务寄存器中所注册的期望类型的Web服务中选择Web服务，以使得如相关联的服务状态数据集合27中所存储的QoS状态信息所指示的，所选择的Web服务能够提供的当前QoS满足所述QoS要求集合。UDDI接着将在服务请求响应消息中向服务请求者发送与所选择的Web服务相关的信息。由此，服务请求者将接收与已知满足服务请求者的QoS要求的单个Web服务相关的信息，而不是从UDDI接收的可能的Web服务的列表。从服务请求者的角度来看，与现有技术的解决方案相比，这被认为是非常有吸引力的，原因在于其为服务请求者省去了可能必须在多个Web服务之间进行选择的麻烦。根据现有技术的解决方案，服务请求者甚至不了解UDDI已经发送了与其相关的信息的Web服务是否合适，原因在于根据现有技术没有提供与满足服务请求者的QoS要求的Web服务能力相关的信息。
图5所示的UDDI服务器50还可选地包括偏好寄存器52。在偏好寄存器52中可以存储与服务请求者40-1,…，40-M和/或服务提供者24-l， ...， 24-N相关的更多静态偏好信息。在偏好寄存器中所存储的偏好信息通常并非是服务请求特定的。其可以是来自他人的评价(rating)，优选的收费方案、优选的服务提供者/请求者、QoS参数的权重(weight)等。并不排除还可以在偏好寄存器中存储实际的QoS要求，例如，如果服务请求者总是请求具有相同QoS要求的相同服务的话。但QoS要求通常并不存储在偏好寄存器中。服务请求者例如能够根据定价策略、先前接收的服务等来不断地更新偏好寄存器。
如果使用了偏好寄存器52,如以下将进一步详细解释的，DMF
应当适于在选择Web服务时考虑存储在偏好寄存器中的相关偏好信自
可选地，UDDI服务器50此外可以包括一个或数个请求队列53。可以为在UDDI中注册的每个Web服务类型提供 一 个请求队列。如果对于所注册的Web服务而言当前没有可用容量，则针对特定类型的Web服务的服务请求可以被放入与所述特定类型的Web服务相关联的请求队列中，以使得与所述服务请求相关联的偏好和/或QoS要求能够得以满足。所述服务请求被放入请求队列中以等待可用容量。
UDDI服务器50的DMF优选地被安排为使其对Web力良务的选择不仅基于QoS要求和所请求Web服务的QoS状态信息，而且还基于所存储的与服务请求者和/或服务提供者相关的任何存储的偏好信息以及请求队列状态。DMF并不限于任何特定类型的决策制订或选择算法。可以使用许多不同的算法。当存在多个适合的Web服务可供选4奪时，例如可以使用选择具有最大容量的算法、随机选择算法和循环机制。
图6是图示根据本发明实施例的诸如UDDI服务器50之类的UDDI服务器中的方法示例的流程图。图6图示了如何为服务请求选择适当的Web服务。在步骤501中，接收服务请求。即使请求队列不为空，也立即处理所述请求，这是因为有许多将服务请求存储在队列中的理由。首先应当检查新的服务请求。在步骤502中，UDDI服务器的DMF将找出不同服务提供者所提供的、能够提供所请求类型的服务的所有Web服务。在步骤502中所找到的Web服务在这里被称作第一 Web服务集合。在步骤503中，由DMF使用偏好寄存器52中的信息对第一 Web服务集合进行第一过滤。例如，该步骤将移除服务提供者所提供的、偏好寄存器的偏好信息指出无论Web服务的状态如何也永远不被用于当前服务请求者的那些Web服务。剩余Web服务的集合在这里被称作第二 Web服务集合并且被临时保存用于所述服务请求。在步骤504中，由DMF获取与第二 Web服务集合相关联的、并被存储在Web服务寄存器中的QoS状态信息。在步骤505中，使用来自服务请求者的QoS要求再次对第二集合进行过滤以得到第三Web服务集合，其包括根据其相关联的QoS状态信息而满足所述QoS要求的那些Web服务。如果在步骤506a中发现第三集合为空，则在步骤506b中将服务请求存储在请求队列53中。否则，根据该实施例，将在步骤507中使用偏好寄存器52中的偏好信息对Web服务进行排序(rank)。排序中所使用的参数可以是定价、可信度、请求者与提供者之间的关系、QoS参数的权重等。如果若干Web服务具有相同的最高排名(ranking)，则能够使用许多算法来进行选择。非常简单的 一种算法为随机选择。将随机选出具有最高排名的Web服务之一。也可以使用循环方法，即依次选择Web服务。略为先进的算法将考虑Web服务的当前可用容量。可以选择具有最高可用容量的Web服务，以使得能够在所有Web服务上均匀分布负载。甚至能够在决策制订时使用与请求队列53中的当前请求相关的信息。如果存在等待特定Web服务获得足够容量的请求，则如果存在具有相同排名的其他可用Web服务，就避免该特定Web服务用于其他服务请求。在DMF中能够使用多种算法。然而，在步骤508中，DMF根据某一决策制订算法来选择Web服务。在步骤509中，向服务请求者发送具有关于所选择的Web服务的信息的服务请求响应。
如果使用一个或数个请求队列，则存在若干不同的对请求队列中的请求进行管理的方式。例如，可以以预定间隔进行新的检查来查明请求队列中的任何服务请求是否可以得到满足。 一种可选方式是在针对与请求队列相关联的Web服务类型更新QoS状态信息时执行检查。图7是图示这种实施例的流程图。图7图示了 DMF51如何在更新与Web服务相关的QoS状态信息时管理请求队列53的示例。在步骤601中，更新Web服务的QoS状态信息。(假设容量增加，但是存在若干QoS参数， 一些可能增加而其他可能减少。根据该实施例，针对每个服务状态更新进行检查)。在步骤602中，检查与针对其进行了更新的服务类型相关联的请求队列53。如果请求队列为空，则将没有动作发生，步骤608。否则，在步骤603中，取出请求队列中的第一服务请求以供处理。在步骤604中，当如以上结合图6的步骤503所描述的那样，在接收到请求时，DMF检查Web服务是否处于以上所提到的所创建的第二 Web服务集合中。如果不处于第二集合中，则没有动作发生，步骤608。否则，该过程进行至步骤605，在那里对照所更新的QoS状态信息来检查QoS要求。如果Web服务能够满足QoS要求，则在步骤606中选择Web服务并且将服务请求响应发送回请求者。否则，该过程将继续在步骤607中取得队列中的下一个请求，并且接着将在步骤604开始过程步骤的重复。如果服务请求为请求队列53中的最后请求，则没有动作发生，步骤608。
根据本发明以上所描述的实施例，提供具有大容量的Web服务的服务提供者很可能被分配给服务请求者。本发明还向UDDI服务器的提供者提供了新的商业机会的可能性。UDDI服务器的提供者例如可以提供服务级别方案，其中服务提供者可以向UDDI服务器提供者支付费用以使其服务被排在UDDI服务器中的高质量(premium)级别的服务中。如果存在若干可从中进行选择的、能够满足QoS要求的Web服务，则UDDI可以被安排成总是比在服务级别方案中具有较低级别的任意其他Web服务更为优先地选择高质量级别的服务。
如以上所提到的，现有技术的UDDI服务器仅提供了服务查找服务而并不支持QoS供应。另一方面，本发明的实施例提供了对QoS 供应的这种支持并且还提供了用于高效资源管理的工具。由于UDDI 服务器担当Web服务的代理，所以希望所迷代理为服务提供者和服务 请求者这二者提供最佳可能服务。服务请求者想要得到能够满足其 QoS要求的服务。服务提供者的目标是使其系统资源最大化并且为尽 可能多的满意用户提供服务。这可以通过本发明的实施例来实现。
本领域技术人员根据以上描述将会意识到，为了实施所描述的本 发明的不同实施例，对软件、固件和/或硬件进行修改是必要和/或适 当的。
然采用了特定术语，、但是它们仅以 一般和说^性的含2来使用而并非 用于限制，本发明的范围在以下权利要求中给出。
权利要求
1.一种用于对由多个服务提供者(24)向多个服务请求者(40)提供的Web服务(23)进行调解的UDDI服务器(21，50)，所述UDDI服务器包括用于存储与所述Web服务相关联的信息的Web服务寄存器(22)，其中所述Web服务寄存器包括用于存储分别与每个Web服务相关联的QoS状态信息的数据集合(27)，所述QoS状态信息是关于相关联的Web服务能够向服务请求者提供的当前QoS的信息，用于根据从所述多个服务提供者接收的动态服务状态信息，对存储在所述数据集合(27)中的所述QoS状态信息进行周期性地更新的装置(44)。
2. 如权利要求1所述的UDDI服务器(21 )，进一步包括QoS 模型寄存器(28)，其包括多个预定义QoS模型(29, 31， 35 ),每 个预定义QoS模型指定多个QoS参数字段(32， 33, 34， 36， 37， 38， 39),其中每个QoS模型表示Web服务的QoS简档并且可以用 作为用于多个所述数据集合(27)的模板。
3. 如权利要求2所述的UDDI服务器(21),其中所述多个QoS 参数字段包括用于以下QoS参数中至少一个的字段传输速率、分组 丢失、传输延迟、抖动延迟、最大速率、最小速率、平均速率、分辨 率或采样速率。
4. 如权利要求2或3所述的UDDI服务器(21 )，其中Web服 务寄存器(22 )被安排成将待注册的第一 Web服务与至少一个预定义 QoS模型(29 )相关联以创建与第一 Web服务相关联的第 一数据集合， 其包含由所述至少一个预定义QoS模型所指定的多个QoS参数字段。
5. 如权利要求2-4中任一项所述的UDDI服务器(21),其中 QoS模型寄存器(28 )被安排成在没有一个现有的预定义QoS模型(29 ) 与将要在Web服务寄存器中注册的第二 Web服务相符的情况下注册 新的QoS模型，并且其中Web服务寄存器被安排成将第二 Web服务 与新的QoS模型相关联以创建与第二 Web服务相关联的第二数据集 合(27 )。
6. 如权利要求1-5中任一项所述的UDDI服务器(21),其中 用于更新所述QoS状态信息的所述装置(44 )被安排成在UDDI服务器接收到与来自与数据集合相关联的Web服务的服务提供者(24 )的 推送消息中的数据集合相关的动态服务状态信息时对所述数据集合 (27)之一的QoS状态信息进行更新。
7. 如权利要求1-5中任一项所述的UDDI服务器(21)，其中 用于更新所述QoS状态信息的所述装置(44 )被安排成周期性地拉取 所述Web服务之一的服务提供者(24)以便请求与所述Web服务相 关的动态服务状态信息并且根据所接收的动态服务状态信息，对与 Web服务相关联的数据集合(27)中存储的QoS状态信息进行更新。
8. 如权利要求1 - 5中任一项所述的UDDI服务器(21)，其中 用于更新所述QoS状态信息的所述装置(44 )被安排成根据作为推送 信息或者作为由UDDI服务器周期性地拉取的信息而从与数据集合相 关联的Web服务的服务提供者递送的服务状态信息来对所述数据集 合(27)之一的QoS状态信息进行更新，并且其中UDDI服务器被安 排成根据Web服务类型对服务状态信息的递送模式进行适配。
9. 如权利要求1-8中任一项所述的UDDI服务器(50),其中 UDDI服务器进一步包括决策制定功能(51),其被安排成处理来自所述服务请求者的服务请求，所述服务请求者均与QoS 要求集合相关联；并且分别为每个服务请求从在所述Web服务寄存器(22)中注册的所 述Web服务中选择Web服务，以使得在与Web服务相关联的数据集 合(27)中存储的QoS状态信息所指示的、Web服务所能够提供的当 前QoS满足与服务请求相关联的QoS要求集合。
10. 如权利要求9所述的UDDI服务器(50)，其中UDDI服务 器进一步包括偏好寄存器(52)，其中可以在偏好寄存器(52)中存 储关于所述服务请求者(40)或服务提供者(24)的偏好的偏好信息， 并且其中决策制定功能(51 )进一步被安排成选择Web服务以使得其 还与在所述偏好寄存器中存储的服务请求者和/或服务提供者的偏好 信息相匹配。
11. 如权利要求IO所述的UDDI服务器(50),其中所述偏好信 息包括以下信息类型中的一个或数个关于Web服务评价的信息、优 选收费方案、优选服务提供者或请求者、不接受的服务提供者或请求 者、或QoS要求的权重或QoS要求。
12. 如权利要求9所述的UDDI服务器(50)，其中UDDI服务 器进一步包括至少一个请求队列(53)，如果不存在满足与服务请求 相关联的QoS要求的可用Web服务，则能够将所述服务请求存储在 所述请求队列中。
13. 如权利要求10或11所述的UDDI服务器(50),其中所述 UDDI服务器进一步包括至少一个请求队列(53),如果不存在满足 与服务请求相关联的QoS要求的、并且还与存储在所述偏好寄存器(52 )中的服务请求者和/或服务提供者的偏好信息相匹配的可用Web 服务，则能够将所述服务请求存储在所述请求队列中。
14. 如权利要求13所述的UDDI服务器(50),其中所述决策制 定功能(51 )进一步被安排成在选择Web服务之前检查所述请求队列(53 )的状态并且选择Web服务以使得所述请求队列中所存储的服务 请求尽可能多地得到满足。
15. 如权利要求9-13中任一项所述的UDDI服务器(50),其 中所述决策制定功能(51 )被安排成在存在若干可能选择的Web服务 时根据决策算法来选择Web服务。
16. —种在用于对由多个服务提供者(24 )向多个服务请求者(40 ) 提供的Web服务进行调解的UDDI服务器(21, 50)中的方法，所述 方法包括以下步骤在UDDI服务器中注册(401-407)至少一个Web服务(23)， 所述注册步骤包括存储与每个Web服务相关联的信息，所述信息包括 与每个Web服务相关联的QoS状态信息，所述QoS状态信息是关于 相关联的Web服务能够向服务请求者提供的当前QoS的信息；以及根据分别从每个Web服务的服务提供者接收的动态服务状态信 息，对所述存储的QoS状态信息进行周期性地更新(408 )。
17. 如权利要求16所述的方法，其中所述注册步骤进一步包括 从QoS模型寄存器(28)中选择(404)将与每个Web服务相关联的 QoS模型(29)，所述QoS模型寄存器(28)包括多个预定义QoS 模型，每个预定义QoS模型指定多个QoS参数字段(32， 33， 34， 36, 37， 38， 39)，利用所选择的QoS模型作为模板为每个Web服 务创建数据集合(27 )并且将所述QoS状态信息映射到所述数据集合 中。
18. 如权利要求16所述的方法，其中所述注册步骤进一步包括 在QoS模型寄存器(28)中搜索(402)分别与每个Web服务的类型相符的QoS模型(29),所述QoS模型寄存器(28)包括多个预定义QoS模型，每个预定义QoS模型指定多个QoS参数字段， 如果找到用于第一 Web服务的相符的QoS模型，贝'J选择(404)所述相符的QoS模型以与第一 Web服务相关联； 利用所选择的相符的QoS模型作为模板为第一 Web服务创建(405 )数据集合(27);并且将与第一 Web服务相关联的所述QoS状态信息映射(406 )到所述数据集合中，如果没有找到用于第一 Web服务的相符的QoS模型，则定义(403)与第一 Web服务的类型相符的新的QoS模型； 在QoS模型寄存器中注册新的QoS模型； 选择(404)所述新的QoS模型以与第一 Web服务相关联； 利用所选择的新的QoS模型作为模板为第一 Web服务创建 (405 )数据集合(27);并且将与第一 Web服务相关联的所述QoS状态信息映射(406 )到所述数据集合中。
19. 如权利要求16- 18中任一项所述的方法，其中更新所述QoS 状态信息的所述步骤(408 )包括周期性地接收来自Web服务的服务 提供者的推送消息中的动态服务状态信息。
20. 如权利要求16- 18中任一项所述的方法，其中更新所述QoS 状态信息的所述步骤(408 )包括周期性地从Web服务的服务提供者 拉取动态服务状态信息。
21. 如权利要求16-20中任一项所述的方法，进一步包括步骤 从所述服务请求者之一接收(501)服务请求，所述服务请求与QoS要求集合相关联；以及选择(502-508 ) UDDI服务器中所注册的所述至少一个Web服务 之一，所述选择步骤包括将所述QoS要求集合与UDDI中所存储的 QoS状态信息进行比较并且选择一个Web服务以使得如与所述一个 Web服务相关联的QoS状态信息所指示的、所述一个Web服务所能 够提供的当前QoS满足与服务请求相关联的QoS要求集合，在响应消息中向从其接收到服务请求的服务请求者发送(509 ) 关于所选择的一个Web服务的信息。
22. 如权利要求21所述的方法，其中所述选择步骤进一步包括 搜索(502 )在UDDI中注册的所述至少一个Web服务以寻找与服务请求中所请求的Web服务的类型相对应的第一 Web服务集合， 以及使用偏好信息对所述第一 Web服务集合进行过滤(503 ),以便 得到遵照所述偏好信息的第二 Web服务集合，所述偏好信息是已经在 UDDI服务器中预存储的与从其接收到服务请求的服务请求者的偏好 相关的信息，其中从所述第二 Web服务集合中选择一个Web服务。
23. 如权利要求22所述的方法，其中所述选择步骤进一步包括 通过将所述QoS要求集合与UDDI中所存储的QoS状态信息进行比 较来过滤(505 )所述第二 Web服务集合以得到第三Web服务集合， 其均与指示每个web服务将分别满足所述QoS要求集合的QoS状态 信息相关联，其中从所述第三Web服务集合中选择一个Web服务。
24. 如权利要求21-23中任一项所述的方法，其中如果没有在 所述选择步骤中找到适合的Web服务，则将服务请求存储(506b)在 请求队列中。
全文摘要
本发明涉及用于对由多个服务提供者(24)向多个服务请求者(40)提供的Web服务(23)进行调解的UDDI服务器(50)以及UDDI服务器(50)中的方法。根据本发明的UDDI服务器适于提供对于在Web服务调解中考虑动态服务质量的支持。UDDI服务器包括Web服务寄存器(22)，其包括用于存储QoS状态信息的数据集合(27)。QoS状态信息是关于相关联的Web服务能够向服务请求者提供的当前QoS的信息。根据从服务提供者接收的动态服务状态信息，对存储在数据集合(27)中的QoS状态信息进行周期性地更新。UDDI服务器可选地包括决策制定功能(51)，其用于选择满足服务请求者的QoS要求集合的Web服务。
文档编号H04L29/08GK101637006SQ200780052164
公开日2010年1月27日 申请日期2007年3月14日 优先权日2007年3月14日
发明者威 黄 申请人:艾利森电话股份有限公司