用于多个中间件环境之间的消息流的服务质量(QOS)管理

摘要

一种管理信息系统资源以提供消息流的方法，所述消息流在多个互连的中间件域内和多个互连的中间件域之间具有一致的服务质量“QoS”级别，所述方法包括接收来自第一QoS管理器(426，564)的、表达至少一个QoS需求的QoS消息，将所述至少一个QoS需求转化为针对以通信方式耦合多个中间件域(404，406)的消息接发服务(432)的至少一个参数，在第一中间件域(404)和所述消息接发服务之间创建客户端连接用于接收所述消息流，将所述QoS消息发送到第二中间件域(406)，以及在所述消息接发服务和所述第二中间件域之间创建客户端连接用于发送所述消息流。

说明书

技术领域

本发明一般涉及信息系统，更具体地说，涉及在包括多个中间件环境的信息系统中的服务质量(QoS)管理。

背景技术

可以在网络化的信息管理系统中实现QoS管理，以优化多个并发网络应用对系统资源的使用。通常可以将在信息管理系统中的工作单元视为或任务或消息。在面向对象的系统中，基本任务可以是例如对象的执行线程。消息典型地是各种类型的信息的封装。系统趋向于是面向任务的或面向消息的。因此，已知的QoS管理方法趋向于是或面向任务的或面向消息的。

虽然用于面向任务的系统和面向消息的系统的QoS管理概念和架构可能是相似的，但是实际的实现技术趋向于是非常不同的。在面向任务的系统中，QoS管理技术一般关注区分任务执行的优先级来满足应用QoS需求。在面向消息的系统中，QoS管理技术一般关注消息接收、处理和交付的质量。质量特性(例如性能和可靠性)的含义会与面向任务的系统中的那些稍微不同。例如，消息可靠性典型地意味着交付保证、消息排序和去重复的组合。另一方面，任务可靠性典型地意味着可以成功地执行任务而无失败的概率。

当前，QoS管理在面向任务的系统中用来支持计算应用，以在分布式环境中以及时的方式完成高优先级任务。然而，没有给予用于面向消息的信息管理系统的QoS管理更多的重视。这类系统包括在其中实现面向服务的体系结构(SOA)的信息管理系统。SOA可以是例如发布/订阅、对象请求代理、对等体系结构或其组合。

在发布/订阅体系结构中，信息代理向系统的客户端应用提供服务。在分布式信息管理系统和网络中心军用系统中，信息代理在信息发布、处理和散布中扮演中心角色。被代理系统的示例包括电子邮件、信息天地(information sphere)、合作、虚拟社区和组通信。当许多并发客户端和他们的请求竞争系统资源时，在被代理的系统中可能难以满足关键客户端的需求。用于信息代理的已知资源管理方法不能区分具有不同QoS特性的客户端，使得甚至在多个中间件域之间，也可能据此管理系统资源。

发明内容

通过将一致的、策略驱动服务质量(QoS)需求应用在多个不同的面向消息中间件(MOM)环境或域内以及在其之间的消息流上，本发明的各种实施例可以解决上面所指出的不足和其他不足。

在一个实施例中，描述一种管理信息系统资源以提供在多个中间件域内和多个中间件域之间具有一致的服务质量(QoS)级别的消息流的方法。该方法包括接收来自第一QoS管理器的、表达至少一个QoS需求的QoS消息，将所述至少一个QoS需求转化为针对以通信方式耦合多个中间件域的消息接发服务的至少一个参数，在第一中间件域和所述消息接发服务之间创建客户端连接用于接收所述消息流，将所述QoS消息发送到第二中间件域，以及在所述消息接发服务和所述第二中间件域之间创建客户端连接用于发送所述消息流。

在另一实施例中，描述用于提供在多个互连的中间件域内和多个互连的中间件域之间具有一致的QoS级别的消息流的服务质量(QoS)桥。所述QoS桥被配置为接收来自第一QoS管理器的至少一个QoS需求，将所述至少一个QoS需求传播到第二QoS管理器，以及将所述至少一个QoS需求转化为至少一个QoS参数。所述QoS桥也被配置为使用消息接发服务来接收和使用所述至少一个QoS参数，以及协助在所述多个互连的中间件域之间的所述消息流。

在又另一实施例中，描述用于管理信息系统中的QoS的服务质量(QoS)管理系统，所述信息系统包括由至少一个处理器执行的至少第一中间件解决方案和第二中间件解决方案。所述QoS管理系统包括第一QoS管理器、QoS桥和第二QoS管理器，所述第一QoS管理器被配置为在所述至少一个处理器上执行，使得表达至少一个QoS参数的QoS消息从所述信息系统的客户端被接收；所述QoS桥被配置为在所述至少一个处理器上执行，使得所述QoS消息从所述第一QoS管理器被接收；所述第二QoS管理器被配置为在所述至少一个处理器上执行，使得由所述第二QoS管理器接收来自所述QoS桥的所述QoS消息，并且所述QoS消息被转发到所述信息系统的订阅者，以提供在客户端和订阅者之间具有一致QoS的端到端消息流。

附图说明

图1是具有面向服务体系结构(SOA)的示例性信息系统的图示；

图2是QoS管理体系结构的示例性实施例的图示；

图3是包括多个中间件域的示例性信息系统的图示；以及

图4是图3的信息系统的应用的示例性实施例的图示。如在此使用的，术语示例性指示示例，而不必是典型。

具体实施方式

以下描述在本质上仅是示例性的，并且决非意在限制应用或使用。虽然参照发布者/订阅者信息管理面向服务的体系结构(SOA)描述了一个或多个配置，但是配置并非如此有限。结合其他类型的信息系统设想其他和另外的配置，包括但不限于其他类型和另外类型的面向服务体系结构，信息管理系统和/或网络化系统。

通常，具有面向服务体系结构(SOA)的系统可以作为许多服务的集合的组成成分对待。每一服务经由清楚地定义的接口使其功能可用。在SOA中，每一服务典型地是自描述且开放的软件部件。SOA包括服务，它们的组成成分和交互。下面相对于系统客户端描述管理信息系统资源的方法。在公开号为2005/0204054的美国专利中也描述了一种管理信息系统资源的示例性方法。

图1是实现SOA的信息系统20的图示。在示例性实施例中，信息系统20具有发布/订阅SOA。发布者24发布例如关于多个话题的消息，并且例如由订阅关于特定话题的消息的有意方操作订阅者(用户)34。虽然以图示的形式示出，但是一个或多个元件应理解为包括处理器、关联的存储器和相关的硬件，其中处理器被配置为获取、解码和执行计算机指令，以实现对应于在此所描述的方法、装置或系统的一个或多个操作。同样地，计算机可读介质或机器可读介质可以与处理器一起使用以提供指令。计算机可读介质可以包括光介质(例如光盘(CD))、磁介质(例如软盘或硬盘)或固态存储器(例如随机存取存储器(RAM)或只读存储器(ROM))。

通过信息代理(InfoBroker)46将发布服务38和订阅服务42分离。发布者24和订阅者34相对于作为服务提供者的InfoBroker 46是服务请求者(在此也称为“客户端”和“应用”)。发布服务38和订阅服务42被包括在由InfoBroker 46提供给发布者24和订阅者34的公共服务50中。公共服务50也包括安全54、持久56、过滤58、融合60、分发62和发现64。也可以提供另外的服务66，例如订阅登记。信息代理46也将QoS管理服务70作为公共服务50提供给客户端24和客户端34。如下面进一步描述的，信息代理46提供对QoS管理器74的访问，客户端通过所述QoS管理器74可以协商QoS约定(QoS contract)。如下面进一步所描述的，信息代理46经由QoS管理服务70将服务质量提供给客户端24和客户端34。

在一个实施例中，发布者24和订阅者34可以动态地发现InfoBroker 46并且使用前述服务50。这类服务可以具有不同的QoS特性，并且这类服务的交互可以是动态的和分离的。在性能、可靠性、时间性和安全性方面，不同的发布者24和订阅者34可能具有不同的QoS需求。例如，某些发布者24可能具有比其他发布者高的优先级，并且可能要求将它们的消息在较快的响应时间内以正确的顺序保证交付。类似地，某些订阅者34可能比其他订阅者更关键，因此在接收消息时要求较短的延迟。

作为服务提供者，InfoBroker 46可以将一个或多个QoS保证提供给一个或多个发布者24和/或订阅者34。InfoBroker 46可以限制发布者24和/或订阅者34的一个或多个行为，例如每一时间单元接收或交付消息的速率和/或消息载荷大小。为了处理多个并发客户端(例如发布者24和订阅者34)的QoS需求，QoS管理服务70包括这类服务，例如进入控制80、预测82、资源管理84、监控86和自适应88。

发布者24和订阅者34可以向InfoBroker 46表达它们的QoS需求并且协商QoS约定。QoS约定可以是暂时的或永久的。以此方式，QoS约定可以在每一会话基础上是暂时的或对具有特定角色的客户端是永久的。InfoBroker 46提供用于满足与客户端的QoS约定的资源和机制。InfoBroker 46在执行QoS约定期间监控系统状态，并且提供合适的自适应服务。

在一种配置中，InfoBroker 46导出QoS管理器74以使其QoS管理服务70对客户端可用。客户端24和/或客户端34将其QoS需求作为可扩展标记语言(XML)消息发送给QoS管理器74。在接收达成协议的QoS约定之后，客户端使用该约定作为其与InfoBroker 46交互(例如发送和/或接收消息)的背景(context)。

在图1中示例的体系结构为作为QoS服务提供者的InfoBroker 46提供覆盖QoS管理的多个方面的部件服务。例如InfoBroker 46可以分析应用QoS需求并且可以基于策略以及当前的和预测的未来系统状态，做出进入控制决定。InfoBroker 46可以调拨系统资源和机制以满足QoS需求，并且可以在运行时间监控和调整系统行为。

通常，在信息系统20中，根据QoS特性来指定服务50的QoS需求。QoS特性描述服务请求者和服务提供者两者都理解的具体方面或约束。例如，QoS特性可以划分为四个类别：性能、可靠性、时间性和安全性。可以将一组QoS参数与每一类别关联，例如如下所示。与性能类别关联的参数是：响应时间、消息吞吐量、载荷大小、发布/订阅容积率和端到端延迟。与可靠性类别关联的参数是：交付保证、去重复、消息顺序、丢失概率、错误率、重试阈值、消息持续性和关键性。与时间性类别关联的参数是：生存时间、最后期限、恒定位速率、帧速率和优先级。与安全性类别关联的参数是消息签名和加密。

应该注意，QoS特性和参数的前述分类是示例性的。可以设想QoS各方面的其他和/或另外的特征化和/或分类。在示例实施例中，基于QoS特性和参数的前述分类，基于XML的语言使得服务请求者能够将一个或多个QoS需求表达为QoS消息。

图2是示例性QoS管理体系结构300的图示。QoS管理体系结构300可以包括部件服务、它们的交互和例如通过现成商品(COTS)监控工具与外部服务(如实时主机和网络状态监控)的接口。关键部件服务包括QoS管理器308、建立服务312、策略管理器316、资源管理器320、预测服务324、操作服务328、保持服务332、监控服务336、自适应服务340和诊断服务344。在监控服务和QoS诊断服务之间的交互348遵循登记和通知模式，而在其他服务之间的交互352是基于请求和答复模式。如下面进一步所描述的，诊断服务344经由COTS监控工具364与外部服务(如实时主机356和网络360)相接。

QoS管理器308组织客户端的QoS服务的建立和操作。如前面参照图1讨论的，QoS管理器308为客户端提供访问QoS管理服务的接口。如下面进一步所描述的，给定以XML QoS消息表达的QoS需求，建立服务312可以为客户端设立QoS约定。也如下面进一步所描述的，建立服务312使用策略管理器316、预测服务324和资源管理器320。如果不能建立约定，则建立服务312向代表客户端做出建立请求的QoS管理器308报告。

策略管理器316检查QoS策略368以确保客户端的QoS需求中的参数被允许用于客户端的角色，并且如果允许，策略管理器316检查需要什么资源和机制来满足该需求。资源管理器320提供包括用于系统资源的保留、分配和释放的资源生命周期管理。由于资源典型地位于主机356的平台，因此资源管理器320定义通用QoS管理功能的抽象类。平台的示例是对象管理组开发的公共对象请求代理体系结构(CORBA)、Sun Microsystems公司(圣克拉拉(Santa Clara)，加利福利亚州)开发的Java平台企业版(J2EE)和微软公司(雷德蒙德(Redmond)，华盛顿州)开发的.NET架构。如下面进一步所描述的，针对每一主机平台实现具体的资源类。

预测服务324根据若干关键系统参数(例如存储器使用、CPU负载、网络吞吐量、延迟)跟踪系统状态。预测服务324也根据请求使用各种预测算法在一小段时间窗口中预测未来系统状态。

操作服务328使用初始化进程330来初始化用于QoS约定的资源配置，并且在执行QoS约定期间协调服务。保持服务332可以保持用于QoS约定的一个或多个关键QoS参数，并且可以根据针对这类参数的阈值交叉点激活自适应服务340。监控服务336采样并且集合资源的使用和可用级别，并且测量性能，例如真实的吞吐量和延迟值。监控服务336登记诊断服务344的状态判定，当判定变为真时(例如由于系统状态的改变)，诊断服务344返回通知。

为了恢复正常范围内的关键QoS参数，自适应服务340动态地改变资源和机制372。自适应服务340也可以对客户端的约定违约采取措施。这类措施可以包括例如减慢来自客户端的消息接受，该客户端远远超出其达成协议的发布速率进行发布。例如，当所观察到的参数以低于它的阈值返回时，保持服务332可以请求自适应服务340根据QoS约定恢复QoS级别。自适应机制372可以是插件。因此可以静态地配置并基于策略动态地选择合适的自适应机制372。

诊断服务344使用推理技术(例如使用因果网络)来将低级别系统信号集合成关于系统状态的属性。诊断服务344获得来自监控工具364的实时输入，即时集合数据，并且将数据存储在仓库376中。诊断服务344也可以根据值变化来评估对属性的任何判定并且触发对有意方(例如监控服务336)的通知。

通过询问QoS服务提供者(例如参照图1所描述的信息代理)或通过使用发现服务，客户端经由QoS管理器308访问QoS管理服务。在示例实施例中，QoS管理器308是QoS管理体系结构300中客户端为QoS服务与其直接接口的唯一部件。

中间件域是具有一个管理域的环境，在该管理域内中间件解决方案将服务提供给客户端应用的集合。中间件域的示例包括Apache Software Foundation开发的ActiveMQ消息代理、JBoss应用服务器、IBM公司(阿蒙克(ArMond)，纽约州)开发的WebSphere、数据分发服务(DDS)、波音公司(芝加哥，伊利诺斯州)开发的系统通用操作环境的系统(SOSCOE)和CORBA。如针对信息系统20所描述的，在保持QoS支持的同时，能够将消息从一个中间件域散布到另一中间件域将是有利的。

图3是通过信息系统400的消息流的图示，所述信息系统包括多个中间件域，例如中间件域404和中间件域406。虚线指示消息流，而实线指示约定协商(也称为控制流)。在示例实施例中，信息系统400具有发布/订阅SOA实现。发布者408发布例如关于多个话题的消息，并且例如通过订阅关于特定话题的消息的有意方来操作订阅者410。多个QoS管理器426和QoS管理器428安排用于客户端的QoS服务的建立和操作。如前面参照图1所讨论的，QoS管理器426和QoS管理器428为客户端提供访问QoS管理服务的接口。信息系统400也包括QoS桥430和消息接发服务432，以在保持QoS属性的同时，协助从发布者408到订阅者410的穿过多个中间件域的端到端消息流。

如上面所描述的，QoS指系统(例如信息系统400)在不同的优先级级别将服务提供给客户端(例如发布者408和订阅者410)的能力。对于面向消息的系统，QoS指对客户端、中间件和网络进行的消息传输和处理分配不同的性能级别。QoS管理涉及设置和控制QoS属性，QoS属性例如但不限于吞吐量、延迟、抖动(时变)、丢失率、持续性和持久性。QoS需求和QoS约定是这些属性的集合。QoS需求指定由应用请求的消息收发性能的级别，并且QoS约定指定给应用准予(即“允诺”)的性能级别。此外，在示例实施例中，如果没有指定QoS需求，则暗示缺省的QoS需求集。例如，缺省的QoS需求集可以包括“允诺”尽力而为。

端到端消息流开始于在生产者(例如发布者408)处产生消息，并且终止于由消费者(例如订阅者410)消费消息。在由多个异种中间件域组成的系统中，端到端消息流也将包括在中间件解决方案之间的传输，以及在所有中间件解决方案内的传输。保持QoS属性是实时的、任务紧急环境的基本部件。系统端点和消息处理中间级必须遵循指定服务需求的QoS约定。典型地，已知的中间件技术提供某个级别的QoS支持。然而，QoS支持级别随着技术的不同而不同，随着从流之间的相对优先级到概念(如流量整形和数据持续性)的不同而不同。

QoS桥430使得中间件解决方案404和中间件解决方案406能够共享与各自的客户端应用已经建立的QoS约定，使得向不同中间件域上的应用之间的消息流提供在多个互连的中间件环境或域内和其之间一致的QoS级别。中间件域404和中间件域406中的QoS管理器426和QoS管理器428各自将特定的协议(在图3中未示出)用于经由QoS桥430传播(即转发和接收)已建立的QoS约定。QoS管理器426和QoS管理器428使用该协议，使得当将消息转发到不同的中间件域时，在一个中间件域中与发布者已经建立的约定中的QoS设置可以用作QoS需求。例如，在发布者408和QoS管理器426之间建立的约定可以用作从QoS桥430发送到QoS管理器428的QoS需求。

QoS管理器426负责与在其域中的应用(例如发布者408)建立和保持QoS约定。QoS管理器426接收来自发布者408的QoS需求，并且建议由QoS策略446和可用资源指示的约定。当发布者408接受时，约定变成有约束力的。QoS管理器426通过将QoS约定转化为针对中间件域404的一组QoS参数并且在该组QoS参数和发布者408之间设置关联来应用该约定。例如，当发布者408接受QoS约定时，QoS管理器426创建到发布者408的中间件连接，并且在连接中设置QoS参数。

QoS管理器426也将QoS需求发送到QoS桥430，QoS桥430依次将该QoS需求传播到其他中间件域，例如中间件域406。QoS桥430是专门化的QoS管理器。更具体地说，QoS桥430是中间件域之间的QoS管理器。QoS桥430与QoS管理器和消息接发服务(例如QoS管理器426和消息接发服务432)进行交互，而不是与客户端应用和中间件解决方案进行交互。消息接发服务432提供两个或更多个中间件域之间的互操作性，所述互操作性包括实施在QoS管理器426和QoS桥430之间建立的每一消息流的QoS设置。在示例实施例中，将到达消息接发服务432而无明确的QoS需求的消息流处理为与缺省的QoS需求集关联，例如保证尽力而为方式的一组QoS需求。

在图3中也图解说明用于在多个中间件域之间的端到端通信的示例性方法。发布者类型客户端应用408通过将其QoS需求提交到QoS管理器426来启动500消息流。QoS需求是以独立于中间件的语言撰写的。QoS管理器426基于接收到的QoS需求、QoS策略446和可用资源，创建502独立于中间件的QoS约定。独特的标识符与该约定关联。QoS约定可以还基于，但不限于仅基于：QoS需求、操作者角色、内容类型用户账户、可用的计算资源(本地的和/或远程的)和可用的网络资源。

QoS管理器426将独立于中间件的QoS约定转化508为中间件特定的资源规划。该资源规划包含满足该约定需要的计算资源和网络资源的级别。QoS约定被发送512到发布者408，并且发布者408接收该约定。发布者408将接受消息发布516到QoS管理器426，并且将消息的发布加入518到消息流。

QoS管理器426实现522资源规划。为消息流分配在资源规划中调出的计算资源和网络资源。在示例实施例中，资源规划和QoS约定用于下述中的至少一个：确定计算资源的分配(例如用于缓冲器的存储器和用于服务紧急优先级流的专用线程)，设置进程和线程优先级，以及例如用合适的DiffServ代码点标注网络分组。

QoS管理器426将QoS需求散布524到QoS桥430。QoS桥430获得从源中间件域(即发布的来源)接收到的QoS需求，并且与消息接发服务432进行交互528以创建与起始中间件域的客户端连接，用于接收消息流。QoS桥430也使用桥策略530将接收到的QoS需求转化为针对消息接发服务432的一组QoS参数，所述消息接发服务将中间件域404和中间件域406连接在一起。QoS桥430也将接收到的用于消息流的QoS需求散布到下游中间件域406，对其不做改变或根据桥策略530进行修改。

如上面所描述的，在目的地中间件域406处的QoS管理器428执行与起始QoS管理器426相同的步骤。换句话说，QoS管理器428创建534“本地”QoS约定和等价的资源规划、保留资源、将约定发送到客户端(在此情况下是QoS桥430)、并且一旦接受即实现资源规划。

客户端应用(例如订阅者410)用它们各自的中间件406订阅536消息流。由于该步骤独立于其他控制流通信，因此该订阅可以在任何时间点发生。

在替代实施例中，在QoS管理器426和QoS桥430之间散布524发布者408和QoS管理器426之间适当位置的QoS约定，而不是来自发布者408的QoS需求。在源域404处QoS管理器426所准予的是比发布者408所请求的低得多的QoS级别的控制流的情况下，对于下游域406，保留原始需求中所请求的资源级别不是有益的。通过散布QoS约定而不是原始QoS需求，可以避免不必要的麻烦的资源保留。

图4是上面所描述的信息系统400的应用的示例性实施例的图示。图4图解说明用于将策略驱动的QoS应用在多个中间件域之间的消息流的信息系统548。在示例实施例中，寄生在JBoss中间件552上的遗留系统的客户端应用550需要与寄生在SOSCOE中间件556上的高级系统的客户端应用554共享信息。服务代理560扮演客户端应用550和中间件平台552之间的仲裁人。服务代理562代表中间件平台556为客户端应用554执行相同的功能。服务代理560包括QoS管理器564而服务代理562包括QoS管理器566。QoS桥570使得来自中间件域552的消息能够与中间件域556共享。QoS桥570是特定类型的QoS管理器，其为消息流接收来自QoS管理器564的QoS需求，并且与QoS管理器566一起工作来将相同的QoS需求组应用在同一消息流的附加部分上。

高级系统、遗留系统和数据库系统是可以在各种中间件域中操作的系统示例。服务代理560和服务代理562在指定于中间件的系统和独立于中间件的系统之间进行转化。此外，服务代理560和服务代理562验证这些系统并且批准和管理它们的服务需求。当关联的中间件平台缺少消息优先级区分时，服务代理560和服务代理562根据所设立的QoS约定也可以区分消息流中单个消息的传送的优先级。

上面所描述的实施例提供了有效的端到端QoS管理体系结构，其允许在不同的中间件解决方案之间接发消息。在服务代理中的QoS管理器和QoS桥将QoS需求转化为合适的特定于中间件的目标格式，以提供必要的资源分配来支持可预测、自适应、有保证的消息递送和优先级路由。

上面描述的方法和系统使得QoS需求/约定能够指定用于从端点到端点的整个消息流的处理。中间件域和中间级(桥接)节点一致地实施QoS约定。QoS策略可重定义并且用于控制来自QoS需求的QoS约定设立，将QoS需求/约定转化为特定于中间件的资源规划，以及将QoS需求/约定转化为网络参数设置。

上面描述的前述各种配置也可以另外视为包含与具有存储器的处理器一起使用的机器可读介质。机器可读介质可以包括使处理器接收来自信息系统客户端的、将一个或多个QoS需求表达为一个或多个参数值的QoS消息的指令。机器可读介质也包括使处理器基于一个或多个参数值与客户端建立用于服务质量的约定的指令。机器可读介质包括使处理器基于该约定将信息系统的一个或多个资源分配给客户端的指令。此外，机器可读介质包括将所接收到的QoS消息散布到下游中间件域的指令。

在实现了前述QoS管理系统的配置的SOA中，InfoBroker可以将区分的服务提供给不同角色和QoS需求的客户端。因此InfoBroker可以优化资源的分配和使用以满足来自许多并发客户端的需求。高度重要的客户端比较不重要的客户端取得更多的资源或资源使用的更多共享。上面描述的QoS管理系统在保持QoS需求的同时，也允许在多个中间件域之间的端点到端点消息传送。

前述系统的配置可以用来管理网络吞吐量，以基于优先级提供可靠的信息递送。因为以面向对象的方法对资源建模，因此前述方法使得在多个中间件平台上能够进行统一的资源管理和多态的资源分配。

上面所描述的基于XML的QoS语言为应用提供了灵活的和可扩展的方式，以用QoS特性的各种方面表达QoS需求。因此可以将在单个架构中集成和处理QoS特性的所有方面的体系结构提供给QoS服务提供者。在前述系统中，将信息系统的资源建模为软件对象，以提供在多个中间件平台之间的多态资源分配。在单个架构中管理用于任务和消息两者的QoS特性。例如通过在系统中间件层中的QoS服务提供者，并发应用的QoS需求被满足。

基于其效用，资源被划分为多个类别，在运行时间极大地简化他们的配置。前述资源分配方法可以是基于策略的，并且容易进行修改和扩展。该方法通过有效地管理所分配的资源，比起较不重要的客户端显然地为高度重要的客户端缩短了延迟。当客户端的运行时行为改变以实施客户端QoS约定时，配置可以适应资源分配。

可以以权利要求格式将另外的实施例描述如下：

A11.一种用于提供消息流的服务质量(QoS)桥，该消息流在多个互连的中间件域内和在多个互连的中间件域之间具有一致的QoS级别，所述QoS桥被配置为接收来自第一QoS管理器的至少一个QoS需求，将所述至少一个QoS需求传播到第二QoS管理器，以及将所述至少一个QoS需求转化为至少一个QoS参数，所述QoS桥被配置为使用消息接发服务来接收和实施所述至少一个QoS参数，以及协助在所述多个互连的中间件域之间的所述消息流。

A12.根据权利要求A11所述的QoS桥，其中所述至少一个QoS需求包括基于QoS策略和可用资源中的至少一个的QoS约定。

A13.根据权利要求A11所述的QoS桥，其中所述QoS桥提供在所述多个互连的中间件域之间具有一致QoS的端到端消息流。

虽然已经根据各种特定的实施例描述了本发明，但是本领域技术人员将认识到可以在权利要求的精神和范围内修改实施本发明。