CN101124567A - 消息传递系统中的缓存引擎 - Google Patents

Abstract

消息发布/订购系统被要求处理大量消息，同时减少等待时间和性能瓶颈。本发明所提议的端到端中间件体系结构被设计为通过数据缓存来实现大量、低等待时间消息传递，同时具有保证的递送服务质量，所述数据缓存使用具有存储设备和存储服务的缓存引擎。在消息传递中，消息传递设备(MA)接收和路由消息，但是其首先通过将拷贝发送到CE来记录被路由的消息的全部或者子集。然后，在预定时间段中，被记录的消息在被所述消息传递系统中的任何组件请求时可用于重传，从而提供了有保证同时连接的和有保证同时不连接的服务质量以及部分数据发布服务。

Description

消息传递系统中的缓存引擎

对先前提交申请的引用

本申请要求2005年1月6日提交的名为“Event Router System andMethod”的美国临时申请序列号No.60/641,988和2005年6月8日提交的名为“Hybrid Feed Handlers And Latency Measurement”的美国临时申请序列号No.60/688,983的优先权并且通过引用而结合上述申请。

本申请与2005年12月23日提交的名为“End-To-EndPublish/Subscribe Middleware Architecture”的美国专利申请序列号11/316,778(律师签号50003-0004)有关并且通过引用而结合上述申请。

技术领域

本发明涉及数据消息传递(messaging)，更具体地说，涉及具有发布和订购(下文称作“发布/订购”)中间件体系结构的消息传递系统中的缓存引擎。

背景技术

数据消息传递基础设施所要求的日益提高的性能水平强迫联网基础设施和协议的发展。基本上，数据分发涉及各种数据源和目的地，以及各种类型的互连体系结构和数据源和目的地之间的通信模式。现有数据消息传递体系结构的示例包括轮轴轮辐式(hub-and-spoke)，对等式和存储转发式。

利用轮轴轮辐系统配置，所有通信都通过轮轴传输，这在处理量大时通常会导致性能瓶颈。因此，这种消息传递系统产生了等待时间。绕过这种瓶颈的一种方法是布署更多的服务器，并且在这些不同的服务器之间分布网络负载。但是，这种体系结构表现出可扩展性和操作问题。与具有轮轴轮辐配置的系统相比，具有对等配置的系统对应用产生了不必要的压力以处理和过滤数据，并且仅与其最慢的客户或节点一样快。而具有存储转发系统配置的系统为了提供持久性，要在将数据转发到路径中的下一个节点之前存储该数据。存储操作通常通过索引和将消息写到存储盘来实现，这可能产生性能瓶颈。此外，在消息量增大了时，索引和写入任务可能相当慢，因此可能引入额外的等待时间。

为了提供数据一致性，这些存储转发系统必须提供在没有数据丢失的情况下从任何逻辑或物理的灾难恢复的能力。这通常是用远程磁盘镜像或数据库复制技术来实现的。对这种实现的挑战是始终保证主和副站点之间的数据一致性，同时具有低等待时间。一种选择是实现同步解决方案，其中在主站点处写入的数据的每个块在其在副站点处被镜像之后认为是完整的。这种同步实现的问题在于其影响了消息层的总性能。一种替代选择是实现异步方法。然而，在该方法的情况下，避免数据丢失或损坏的挑战是在灾难发生的同时保持数据一致性。另一个挑战是保证数据更新的排序。

现有数据消息传递体系结构共有一些不足。一个共同的不足是在现有体系结构中数据消息传递依赖于驻留在应用层上的软件。这意味着消息传递基础设施要经历OS(操作系统)排队和网络I/O(输入/输出)，这可能产生性能瓶颈。另一个共同的不足是现有体系结构静态地而不是动态地使用数据传输协议，即使在某些情形下其他协议可能更合适也是如此。常见协议的一些示例包括可路由多播、广播或单播。实际上，现有体系结构中的应用编程接口(API)未被设计为实时地在传输协议之间切换。

另外，网络配置判决通常是在布署时进行的，并且通常被定义为在特定假设下对一组网络和消息传递条件进行优化。与静态(固定的)配置相关联的限制排除了实时动态网络重配置。换言之，现有体系结构是针对特定传输协议配置的，而该传输协议并不总是适合所有网络数据传输负载条件，因此，现有体系结构总是不能实时地应对改变或增大的负载能力需求。

此外，在数据消息传递去往特定的接收者或者接收者群组时，现有消息传递体系结构使用可路由多播来将数据传输过网络。但是，在针对多播建立的系统中，存在对可以用来分发数据的多播群组的数目的限制，结果，消息传递系统不再将数据发送向未被向其订购的目的地(即，不是订户的客户)。由于数据过滤，这增大了客户的数据处理负载和丢弃率。因此，由于任何原因变为过载并且不能跟上数据流的客户最终丢弃进入数据，并且稍后要求重传。重传对整个系统造成影响，因为所有客户都接收重复的传输，并且所有客户都对进入数据进行重新处理。因此，重传可能导致多播风暴，并且最终可能使整个系统瘫痪。

在系统是针对单播消息传递建立来作为减少丢弃率的一种方法时，该消息传递系统可能因为数据复制而经历带宽饱和。例如，如果多于一个客户订购了感兴趣的给定话题，则消息传递系统必须将该数据递送到每个订户，实际上，系统将该数据的不同拷贝发送到每个订户。尽管这解决了客户滤除非订购数据的问题，但是单播传输是不可扩展的，因此基本上不适合订购特定数据的大量客户群组或者消费模式极度重叠的情形。

现有体系结构的另一个共同不足是它们的协议变换较慢并且数量非常多。这是因为企业应用集成(EIA)领域中的IT(信息技术)权宜(band-aid)策略所致，在该领域中，越来越多的新技术被与遗留系统集成。

因此，在多个领域中都需要提高数据消息传递系统性能。其中性能可能需要提高的示例有速度、资源分配、等待时间等。

发明内容

本发明部分基于前述观察和利用不同的方法可以解决这种不足使得具有更好的结果这一观点。这些观察使得开发出用于大量低等待时间消息传递的端到端消息发布/订购体系结构，同时通过数据缓存而具有有保证的递送服务质量。因此，具有这种体系结构(发布/订购中间件系统)的消息传递基础设施也包括如稍后将更详细地描述的具有缓存和存储服务的缓存引擎(CE)。

一般而言，消息传递设备(MA)接收和路由消息。当被与CE紧密耦合时，其首先通过将拷贝发送到CE来记录被路由的消息的全部或者子集。然后，在预定时间段中，被记录的消息在被所述消息传递系统中的任何组件请求时可用于重传，从而提供了合并的、有保证同时连接的和有保证同时不连接的服务质量以及部分数据发布服务。

为了支持这种服务，CE被设计为跟上MA的转发速率。例如，CE被设计为具有：MA与CE之间的用于尽可能快地推送消息的高吞吐量连接、用于插入和重演来自后端CE数据库的消息的高吞吐量和灵巧缓存机制，以及高吞吐量、持久的存储装置。该设计中的考虑之一是减少重演请求的等待时间。

因此，根据所示并且在这里宽广描述的本发明的目的，一种示例性系统包括缓存引擎。消息传递设备和接口介质。所述缓存引擎包括：消息层，其操作用于发送和接收消息；缓存层，其具有索引服务、存储设备和存储服务，所述索引服务操作用于首先给接收到的消息编索引并且用于保持接收到的部分发布消息的镜像，所述存储服务操作用于将接收到的消息的全部或者子集存储在所述存储设备中；一个或多个物理信道接口，用于传输接收到和发送出的消息；以及具有信道管理的消息传输层，用于控制通过所述一个或多个物理信道接口中的每一个接口的消息的发送和接收。所述消息传递设备与所述缓存引擎之间的物理介质是网络构造无关的，其被配置为以太网、基于存储器的直接连接或Infiniband。

另外，前述系统可以被实现为具有设置和管理系统，其经由所述接口介质链接并且被配置为与每个消息传递设备交换管理消息。缓存引擎配置是经由来自P&M系统的管理消息并经由直接连接到所述缓存引擎的MA传送的。所述缓存引擎有效地充当基于邻居的消息传递架构中的另一个邻居。

如上所述的利用缓存引擎的各种方法能够在消息传递中提供服务质量。一种这样的方法是在具有消息传输层、管理消息层和缓存层的缓存引擎中执行的，所述缓存层具有索引和存储服务以及相关的存储设备。该方法包括以下步骤：通过所述消息传输层接收数据和管理消息；将所述管现消息转发到所述管理消息层并且将所述数据消息转发到所述缓存层，其中被转发到所述管理消息层的消息取回请求消息被路由到所述缓存层。该方法还包括以下步骤：在所述索引服务中给所述数据消息编索引，所述索引编制是基于话题的；以及基于所述索引编制将所述数据消息存储在存储装置中，其中所述数据消息被保持在所述存储装置中预定时间段，在所述预定时间段期间所述数据消息可响应于消息取回请求消息而用于重传。

因为所述数据消息不是完整的数据消息就是部分发布的数据消息并且每个数据消息具有相关话题，所以索引服务保持每个完整数据消息的主镜像。然后，对于作为部分完整消息的接收到的数据消息，所述索引服务将所述接收到的数据消息对比具有与所述部分发布消息的话题类似的相关话题的完整消息的最新主镜像进行比较，以确定应当如何更新所述主镜像。部分发布的消息和主镜像都被索引并且都可用于重传。

这些缓存引擎可以被配置和部署为由主和副CE组成的容错对，或者由多于两个CE节点组成的容错组。如果两个或多个CE被逻辑地互相链接，则它们订购相同的数据并从而保持所订购数据的唯一和一致的视图。注意到，与应用编程接口(API)很象，CE对数据的订购是基于话题的。在数据丢失的情况下，CE可以向容错组中的其他CE成员请求丢失数据的重演。同一容错组中的CE之间的数据同步是通过消息传递网络构造平行化的，消息网络构造经由MA将被订购的消息传递流量的多个拷贝智能且高效地转发到所有的缓存引擎示例。结果，这实现了用于容错和灾难恢复部署的异步数据一致性，其中，数据同步和持久性是通过消息传递网络构造来执行和保证的，而不是通过使用存储/磁盘镜像法或数据库复制技术。

总而言之，从这里的描述，所附权利要求书以及后面将描述的附图可以更好地理解本发明的这些和其他特征、方面和优点。

附图说明

被结合到说明书中并且作为说明书的一部分的附图说明了本发明的各个方面，并且与说明书一起说明本发明的原理。只要方便，在所有附图中相同的标号将用于指代相同或类似的元件。

图1示出了根据本发明原理的端到端中间件体系结构。

图1a是示出了覆盖网络(overlay network)的图。

图2是示出了利用根据本发明原理的端到端中间件体系结构实现的企业基础设施的图。

图3示出了基于信道的消息传递系统的体系结构。

图4示出了一种可能的基于话题的消息格式。

图5示出了基于话题的消息路由选择和路由选择表。

图6示出了用于MA与CE之间的通信的接口。

图7是示出了根据本发明一个实施例来配置的CE(缓存引擎)的框图。

图8示出了具有主和副缓存引擎的容错配置，并且示出了故障情况下的不同阶段。

具体实施方式

在概括涉及根据本发明多个原理和方面的各个实施例的细节之前，下面是对一些术语的简单说明，这些术语可以被用在整个说明书中。注意，该说明仅是为了澄清并且向读者给出对可能如何使用这些术语的理解，但是不是将这些术语限于使用它们的上下文中，也不是要因此限制权利要求书的范围。

术语“中间件”在计算机工业中作为一个一般术语使用，针对在两个分离的通常已存在的程序之间协调的任何编程。一般而言，中间件程序提供消息传递服务，以使得不同的应用程序可以通信。通常通过利用中间件将不同的应用程序在系统上连结到一起被称作企业应用集成(EAI)。但是，在该上下文中，“中间件”可以是一种更广的术语，用在源和目的地之间的消息传递和被布署用于实现这种消息传递的设施的上下文中；因此，中间件体系结构单独或者与下面将描述的组合覆盖了实现高效数据消息传递的联网和计算机硬件与软件组件。此外，术语“消息传递系统”或者“中间件系统”可以被用在发布/订购系统的上下文中，在该系统中，消息传递服务器对在发布者和订购者之间的消息路由选择进行管理。实际上，消息传递中间件中发布/订购的范式是可扩展的，因此是一种有力的模型。

术语“客户”可以用在客户机-服务器应用等的上下文中。在一个实例中，客户是这样一种系统或应用，其利用应用编程接口(API)注册到中间件系统，以订购信息，并且接收该中间件系统递送的数据。中间件体系结构边界内部的API是一种客户；并且外部客户是不使用该API的任何发布/订购系统(或者外部数据目的地)，并且为了与之通信，消息要通过协议变换(稍后将描述)。

术语“外部数据源”可以用在数据分发和消息发布/订购系统的上下文中。在一个示例中，外部数据源被认为是位于企业专用网络内或者外部的系统或应用，其采用常用协议之一或者其自己的消息协议发布消息。外部数据源的一个示例是市场数据交换，其发布股市报价，股市报价经由中间件系统被分发到交易员。外部数据源的另一个示例是事务性数据。注意，在后面将更详细描述的本发明的典型实现方式中，中间件体系结构采用其唯一的本地协议，来自外部数据源的数据一旦进入该中间件系统域就被转换成该唯一的本地协议，从而避免了传统系统中典型的多协议变换。

术语“外部数据目的地”也用在数据分发和消息发布/订购系统的上下文中。例如，外部数据目的地是位于企业专用网络内或外部的系统或应用，其订购经由本地/全局网络被路由的信息。外部数据目的地的一个示例可以是对由交易员发布的事务订单进行处理的前述市场数据交换。外部数据目的地的另一个示例是事务性数据。注意，在前述中间件体系结构中，去往外部数据目的地的消息从本地协议被翻译成与该外部数据目的地相关联的外部协议。

从这里的描述可以确认，可以利用每种都在中间件体系结构中实现的各种配置实现的缓存引擎(CE)以各种方式实施本发明。描述因此以图1所示的端到端中间件体系结构的示例开始。

这种示例性体系结构组合了许多有益特征，这些有益特征包括：消息传递公共概念、API、容错、设置和管理(P&M)、服务质量(QoS-合并的，尽力而为的、有保证同时连接的、有保证同时不连接的，等等)、有保证递送QoS的持久缓存、命名空间和安全性服务的管理、发布/订购生态系统(核心、入口和出口组件)、传输透明的消息传递、基于邻居的消息传递(一种作为轮轴轮辐、对等和存储转发之间的混合体的模型，该模型使用基于订购的路由选择协议，可以在必要时将订购传播到所有邻居)、迟绑定模式、部分发布(与所有数据相对，仅发布改变的信息)和动态分配网络和系统资源。后面将说明，发布/订购系统有益地结合了中间件体系结构的容错设计。注意，发布/订购生态系统的核心MA部分使用前述本地消息传递协议(对于中间件系统本地的)，而入口和出口部分，边沿MA则分别向该本地协议翻译或者从该本地协议翻译。

除了发布/订购系统组件之外，图1的图还示出了它们之间的逻辑连接和通信。从图可见，所示的中间件体系结构是分布式系统的中间件体系结构。在具有这种体系结构的系统中，两个截然不同的物理组件之间的逻辑通信是利用消息流和相关联的消息协议建立起来的。消息流包含两类消息之一：管理和数据消息。管理消息用于管理和控制不同的物理组件、管理对数据的订购，等等。数据消息用于在源和目的地之间传输数据，并且在典型的发布/订购消息传递中，存在数据消息的多个发送者和多个接收者。

利用所示结构配置和逻辑通信，该具有中间件体系结构的分布式发布/订购系统被设计来执行多种逻辑功能。一种逻辑功能是消息协议翻译，该功能有利地在边沿消息传递设备(MA)组件处执行。第二种逻辑功能是将消息从发布者路由到订购者。注意，这些消息被路由过整个发布/订购网络。因此，路由选择功能由其中传播消息的每个MA执行，即，从边沿MA 106a-b(或者API)到核心MA 108a-c，从一个核心MA到另一个核心MA，最终到达边沿MA(例如，106b)或者API 110a-b。API 110a-b经由程间通信总线(套接字、共享存储器等)与应用112_1-n通信。

第三种逻辑功能是针对不同类型的有保证的递送服务质量存储消息，包括例如有保证同时连接的和有保证同时不连接的。第四种功能是将这些消息递送到订购者。如图所示，API 106a-b将消息递送到订购应用112_1-n。

在该发布/订购中间件体系结构中，系统配置功能以及其他管理和系统性能监控功能由P&M 102、104系统管理。配置包括发布/订购中间件系统网络和组件的物理和逻辑配置。监控和报告包括监控所有网络和系统组件的健康和自动地或按照要求把结果报告给日志。P&M系统经由管理消息来执行其配置、监控和报告功能。另外，P&M系统允许系统管理员定义与通过整个发布/订购网络路由的消息中每一个消息相关的消息命名空间。相应地，发布/订购网络可被物理地和/或逻辑地分成基于命名空间的子网。

P&M系统用一个或多个MA来管理发布/订购中间件系统。这些MA取决于它们在系统中的角色被布署为边沿MA或者核心MA。边沿MA在大多方面与核心MA类似，除了其包括协议翻译引擎之外，协议翻译引擎将消息从外部协议翻译成本地协议和从本地协议翻译成外部协议。因此，一般来说，发布/订购系统中间件体系结构的边界(即端到端发布/订购中间件系统边界)由其中存在MA 106a-b和API 110a-b的其边沿表征；并且在这些边界内，存在核心MA 108a-c。

注意，系统体系结构不被限制到特定的受限的地理区域，并且实际上，系统体系结构被设计为超越区域或国家边界，甚至跨越大洲。在这种情形中，一个网络中的边沿MA可以经由现有的联网基础设施与地理上远离的另一个网络中的边沿MA通信。

在典型的系统中，核心MA 108a-c将在该系统内部发布的消息路由向边沿MA或API(例如，API 110a-b)。尤其是在核心MA中的路由选择图被设计来用于最大量、低等待时间并且高效地路由选择。此外，核心MA之间的路由选择可以实时动态改变。对于穿过多个节点(核心MA)的给定的消息传递路径，路由选择的实时改变是基于一个或多个度量的，这些度量包括网络利用、总地端到端等待时间、通信量、网络延迟、丢失和抖动。

或者，不是从两条或多条不同的路径中动态选择最佳执行路径，而是MA可以基于消息复制执行多路径路由选择，并且从而通过所有路径发送相同的消息。位于不同路径的汇聚点处的所有MA将丢弃复制的消息，仅转发第一个到达的消息。这种路由选择方法具有使低等待时间的消息传递基础设施最优化的优点；尽管这种路由选择的缺点是基础设施需要更多的网络带宽来传送复制的流量。

边沿MA具有这样的能力：将进入消息的任何外部消息协议转换成中间件系统的本地消息协议；以及从本地消息协议转换成外出消息的外部协议。即，在消息进入发布/订购网络域(入口)时，外部协议被转换成本地(例如，Tervela^TM)消息协议；并且在消息离开发布/订购网络域(出口)时，本地协议被转换成外部协议。边沿MA的另一个功能是将已发布的消息递送到订购了的外部数据目的地。

另外，边沿和核心MA 106a-b和108a-c都能够在转发消息之前存储消息。可以实现该功能的一种方法是利用缓存引擎(CE)118a-b。一个或多个CE可以被连接到相同的MA。理论上，不认为API具有这种存储转发能力，尽管实际上API 110a-b可以在将消息递送到应用之前存储消息，并且其可以在将从应用接收到的消息递送到核心MA、边沿MA或者另一个API之前存储它们。

在MA(边沿或核心MA)具有到CE的活动连接时，其将被路由的消息的全部或者子集转发到CE，CE将它们写到存储区域中以实现持久性。在预定时间段中，被记录的消息可在被请求时用于重传。其中实现了这种特征的示例有数据中继、部分发布和各种服务质量级别。部分发布在减少网络和客户负载方面是有效的，因为其要求仅发送更新的信息，而不是所有信息。

为了说明路由选择图可能如何实现路由选择，图1中示出了发布/订购路由选择路径的数个示例。在该图示中，发布/订购网络的中间件体系结构在发布者和订购者之间提供了五条或更多的通信路径。

第一通信路径将外部数据源链接到外部数据目的地。从外部数据源114_1-n接收到的已发布消息被翻译成本地(例如，Tervela^TM)消息协议，然后被边沿MA 106a路由。本地协议消息可以从边沿MA 106a被路由的一条路线是到外部数据目的地116n。该路径被称作通信路径1a。在这种情形中，本地协议消息被转换成适于该外部数据目的地的外部协议消息。本地协议消息可以从边沿MA 106b被路由的另一条路线是内部通过核心MA 108b。该路径被称作通信路径1b。沿着该路径，核心MA 108b将本地消息路由到边沿MA 106a。但是，在边沿MA 106a将本地协议消息路由到外部数据目的地116₁之前，其将它们转换成适于该外部数据目的地116₁的外部消息协议。可见，这种通信路径不要求API将消息从发布者路由到订购者。因此，如果发布/订购系统被用于外部源到目的地的通信，则该系统无需包括API。

被称作通信路径2的另一条通信路径利用API 110b将外部数据源114n链接到一个应用。从外部数据源接收到的已发布的消息在边沿MA106a处被翻译成本地消息协议，然后被该边沿MA路由到核心MA 108a。从第一核心MA 108a出发，这些消息被路由过另一个核心MA 108c到达API 110b。从该API出发，这些消息被递送到订购应用(例如，112₂)。因为该通信路径是双向的，所以在另一个实例中，消息可以沿着反向路径从订购应用112_1-n到达外部数据目的地116n。在每个实例中，核心MA接收本地协议消息并且路由本地协议消息，而边沿MA接收外部或者本地协议消息，并且分别路由本地或外部协议消息(边沿MA将这种外部消息协议翻译成本地消息协议/从本地消息协议翻译成这种外部消息协议)。每个边沿MA可以将入口消息同时路由到本地协议信道和外部协议信道。结果，每个边沿MA可以将入口消息同时路由到外部和内部客户，其中内部客户消耗本地协议消息，而外部客户消耗外部协议消息。这种能力使得消息传递基础设施能够与遗留应用和系统无缝并且平滑地集成。

被称作通信路径3的另一条通信路径链接两个应用，这两个应用都利用API 110a-b。这些应用中的至少一个发布消息或者订购消息。已发布的消息到订购应用的递送或者来自发布应用的已发布消息的递送是利用位于发布/订购网络边沿的API实现的。在应用订购消息时，核心或者边沿MA之一将消息路由向该API，该API然后在数据正准备被递送到它们时通知订购应用。从应用发布的消息经由该API被发送到该API被“注册”到其的核心MA 108c。

注意，通过“注册”(登录)到一个MA，该API变为在逻辑上连接到该MA。API通过发送注册(“登录”请求)消息到MA来发起到该MA的连接。在注册之后，该API可以通过将其订购消息发送到该MA来订购特定的感兴趣的话题。话题被用于发布/订购消息传递，来定义共享的访问域和消息的目标，因此，订购一个或多个话题允许接收和发送具有这种话题注释的消息。P&M将周期授权更新发送到网络中的MA，每个MA相应地更新其自己的表格。因此，如果发现API要被授权来订购特定的话题(该MA利用路由选择授权表来验证该API的授权)，则该MA激活到该API的逻辑连接。然后，如果该API被适当地注册到核心MA 108c，则核心MA 108c将数据路由到第二API 110，如图所示。在其他示例中，该核心MA 108b可以通过额外的一个或多个核心MA(未示出)路由消息，这一个或多个核心MA将消息路由到API 110b，AP 110b然后将消息递送到订购应用112_1-n。

可见，通信路径3不要求存在边沿MA，因为其不涉及任何外部数据消息协议。在一个对这里通信路径给出示例的实施例中，企业系统被配置有新闻服务器，该新闻服务器向雇员发布关于多种话题的最新新闻。为了接收到新闻，雇员经由利用API的新闻浏览器应用订购它们感兴趣的话题。

注意，中间件体系结构允许订购一个或多个话题。此外，这种体系结构通过允许消息注释中的通配符，从而利用单个订购请求订购一组相关的话题。

被称作通信路径4的又一条通信路径是与P&M系统102和104相关联的多条路径之一，这些路径中的每条将P&M链接到发布/订购网络中间件体系结构中的MA之一。在P&M系统和每个MA之间往返的消息是管理消息，管理消息用于对该MA进行配置和监控。在一种系统配置中，P&M系统直接与MA通信。在另一种系统配置中，P&M系统通过其他MA与一些MA通信。在又一种配置中，P&M系统可以直接或者间接与MA通信。

在典型的实现方式中，中间件体系结构可以被布署在网络上，该网络具有交换机、路由器和其他联网设备，并且其采用基于信道的消息传递，该消息传递能够通过任何类型的物理介质通信。这种网络构造无关的基于信道的消息传递的一种示例性实现方式是基于IP的网络。在这种环境中，所有发布/订购物理组件之间的所有通信都通过UDP(数据报协议)执行，并且传输可靠性由消息传输层实现。图1a示出了根据本原理的覆盖网络。

如图所示，覆盖通信1、2和3可以经由交换机214a-c、路由器216和子网218a-c在三个核心MA 208a-c之间发生。换言之，这些通信路径可以建立在下层网络之上，所述下层网络包括联网基础设施，例如子网、交换机和路由器，并且如上所述，这种体系结构可以跨越较大的地理区域(不同的国家甚至不同的大洲)。

根据本发明原理的前述和其他端到端中间件体系结构可以被实现在各种商业环境中的各种企业基础设施中。图2示出了一种这样的实现方式。

在该企业基础设施中，市场数据分发工厂12被构建在发布/订购网络之上，该发布/订购网络用于将来自各个市场数据交换设备320_1-n的股票市场报价路由到交易员(未示出的应用)。这种覆盖解决方案依赖于下层网络提供例如MA之间和这种MA和P&M系统之间的互连。到API 310_1-n的市场数据递送是基于应用订购的。利用这种基础设施，利用应用(未示出)的交易员将来自API 310_1-n的交易单通过发布/订购网络(经由核心MA308 a-b和边沿MA 306b)放置回市场数据交换设备320_1-n。

逻辑上，发布/订购网络的物理组件被构建在类似于开放系统互连(OSI)参考模型的1到4层的消息传输层之上。OSI模型的1到4层分别是物理层、数据链路层、网络层和传输层。

因此，在本发明的一个实施例中，发布/订购网络通过例如在所有网络交换机和路由器或者网络交换机和路由器的子集中插入一个或多个消息传递线路卡，从而可以被直接布署到下层网络/架构中。在本发明的另一个实施例中，发布/订购网络可以作为网状覆盖网络(其中，所有物理组件都被彼此连接)而被布署。例如，4个MA的完全网状网络是这样的网络，其中，每个MA被连接到其3个对等MA中的每个。在典型实现方式中，发布/订购网络是下述组件的网状网络：一个或多个外部数据源和/或目的地、一个或多个设置和管理(P&M)系统、一个或多个消息传递设备(MA)、一个或多个可选缓存引擎(CE)，以及一个或多个可选应用编程接口(API)。

很明显，遍及发布/订购网络的通信是利用用于与下层传输逻辑独立的消息的本地协议实现的。这就是将这种体系结构称作传输透明基于信道的消息传递体系结构的原因。

图3更详细地示出了基于信道的消息传递体系结构320。一般而言，消息传递源和目的地之间的每条通信路径被认为是一条消息传递信道。每条信道326_1-n利用信道源和信道目的地之间的接口328_1-n通过物理介质建立。每条这样的信道是针对专门的消息协议建立的，所述消息协议例如是本地(例如，Tervela^TM)消息协议或其他。仅边沿MA(对发布/订购网络的入口和出口进行管理的那些MA)利用信道消息协议(外部消息协议)。基于信道消息协议，信道管理层324确定进入和外出消息是否要求协议翻译。在每个边沿MA处，如果进入消息的信道消息协议不同于本地协议，则信道管理层324将在将要处理的消息传递到本地消息层330之前，通过将它们发送过协议翻译引擎(PTE)332，从而执行协议翻译。同样，在每个边沿MA处，如果外出消息的本地消息协议不同于信道消息协议(外部消息协议)，则信道管理层324将在将要处理的消息路由到传输信道326_1-n之前，将它们发送过协议翻译引擎(PTE)332，从而执行协议翻译。从而，信道对与物理介质的接口328_1-n、与该物理介质相关联的特定网络和传输逻辑、以及消息组件或者片段进行管理。

换言之，信道对到物理层322的OSI传输进行管理。对信道资源的优化基于每条信道被执行(例如，基于消耗模式对物理介质的消息密度优化，所述消耗模式包括带宽、消息大小分布、信道目的地资源和信道健康统计)。然后，因为通信信道是网络构造无关的，所以不要求特定类型的架构。实际上，任何架构介质都将工作，例如，ATM、Infiniband或者以太网。

顺便提及，在例如单个消息被分割到多个帧或者多个消息被打包到单个帧中时，可能需要消息分段或重组。消息分段或重组在消息被递送到信道管理层之前被执行。

图3进一步示出了在具有中间件体系结构的网络中的多种可能的信道实现方式。在一种实现方式340中，通信是利用通过太网交换的网络的多播，经由基于网络的信道执行的，其中以太网交换的网络充当用于这种通信的物理介质。在这种实现方式中，源从其IP地址经由其UDP端口将消息发送向具有其关联UDP端口的目的地群组(被定义为IP多播地址)。在这种实现方式的变体342中，源和目的地之间的通信是利用UDP单播通过以太网交换的网络实现的。源从其IP地址经由其UDP端口将消息发送向在其相应的IP地址处具有UDP端口的选择目的地。

在另一种实现方式344中，信道是利用本地Infiniband传输协议通过Infiniband互连建立的，其中Infiniband架构是物理介质。在这种实现方式中，信道是基于节点的，并且源和目的地之间的通信是利用它们各自的节点地址基于节点的。在又一种实现方式346中，信道是基于存储器的，例如RDMA(远程直接存储器访问)，并且在这里被称作直接连接(DC)。利用这种类型的信道，消息从源机器被直接发送到目的地机器的存储器，从而绕过CPU处理来应对从NIC到应用存储器空间的消息，并且可能避免了将消息封装成网络分组的网络开销。

至于本地协议，一种方法利用前述本地Tervela^TM消息协议。概念上，Tervela^TM消息协议与基于IP的协议类似。每个消息包含消息头部和消息有效负载。消息头部包含多个字段，其中一个字段用于话题信息。如上所述，话题由客户用来订购共享的信息域。

图4示出了一个可能的基于话题的消息格式。如图所示，消息包括头部370和主体372和374，主体372和374包括有效负载。示出了两类消息，即，数据和管理消息，这两类消息具有不同的消息体和有效负载类型。头部包括用于以下内容的字段：源和目的地命名空间标识、源和目的地会话标识、话题序列号和希望时间戳，另外，其还包括话题注释字段(该字段优选是可变长度的)。

话题可以被定义为基于标记的字符串，例如T1.T2.T3.T4，其中T1、T2、T3和T4是可变长度的字符串。在一个示例中，话题可以被定义为NYSE.RTF.IBM 376，该字符串是包含IBM股票实时报价的消息的话题注释。在一些实现方式中，消息中的话题注释可能被编码或者被映射到一个关键字，关键字可以是一个或多个整数值。然后，每个话题会被映射到一个唯一的关键字，并且话题和关键字之间的映射数据库将由P&M系统维护，并且通过线路被更新到所有MA。结果，在API订购或者发布一个话题时，MA能够返回用于消息的话题字段的关联的唯一关键字。

优选地，订购格式将遵循与消息话题相同的格式。但是，订购格式还支持与任何话题子字符串匹配或者与话题正则表达式模式匹配的通配符。对通配符到实际话题的映射的处理可以依赖于P&M系统，或者根据通配符或模式匹配请求的复杂度由MA处理。

模式匹配可以遵循下面的示例中提供的规则。

示例#1：具有通配符T1.^*.T3.T4的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4匹配，但是不与T1.T2.T3.T4.T5匹配

示例#2：具有通配符T1.^*.T3.T4.^*的字符串将不与T1.T2a.T3.T4、T1.T2b.T3.T4匹配，但是与T1.T2.T3.T4.T5匹配

示例#2：具有通配符T1.^*.T3.T4.[^*](第五个元素可选)的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4、以及T1.T2.T3.T4.T5匹配，但是不与T1.T2.T3.T4.T5.T6匹配

示例#4：具有通配符T1.T2^*.T3.T4的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4匹配，但是不与T1.T5a.T3.T4匹配

示例#5：具有通配符T1.^*.T3.T4.＞(任何数目的结尾元素)的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4、T1.T2.T3.T4.T5和T1.T2.T3.T4.T5.T6匹配

图5示出了基于话题的消息路由选择。如图所示，话题可以被定义为基于标记的字符串，例如，T1.T2.T3.T4，其中T1、T2、T3和T4是可变长度的字符串。可见，具有特定话题注释400的进入消息被有选择地路由到通信信道404，并且路由选择确定是基于路由选择表402作出的。话题订购到信道的映射定义路由，并且用来将消息传递遍整个发布/订购网络。所有这些路由或者说订购和信道之间的映射的超集定义路由选择表。路由选择表也被称作订购表。用于利用基于字符串的话题进行路由选择的订购表可以以多种方式被构造，但是优选配置为对其大小以及路由选择查找速度进行优化。在一种实现方式中，订购表可以被定义为动态散列图结构，而在另一种实现方式中，订购表可以被布置在树结构中，如图5中的图所示。

树包括由边连接的节点(例如，T₁、…、T₁₀)，其中话题订购的每个子字符串对应于树中的一个节点。映射到给定的订购的信道被存储在订购的叶子节点上，每个叶子节点指示该话题订购来自的信道的列表(即，通过其接收到订购请求)。该列表指示哪个信道应接收其话题注释与该订购匹配的消息的拷贝。如图所示，消息路由选择查找将消息话题作为输入，然后利用该话题的每个子字符串对树进行解析，来定位与进入消息话题相关联的不同信道。例如，T₁，T₂，T₃，T₄和T₅被导向信道1、2和3；T₁、T₂和T₃被导向信道4；T₁、T₆、T₇、T_*和T₉被导向信道4和5；T₁，T₆，T₇，T₈和T₉被导向信道1；以及T₁、T₆、T₇、T_*和T₁₀被导向信道5。

尽管对路由选择表的结构的选择是要对路由选择表的查找进行优化，但是查找的性能还取决于用于找到与进入消息话题匹配的一个或多个话题订购的搜索算法。因此，路由选择表结构应当能够适应这种算法，反之亦然。减小路由选择表的大小的一种方式是允许路由选择算法有选择地将订购传播遍整个发布/订购网络。例如，如果订购看来是已被传播的另一个订购的子集(例如，整个字符串的一部分)，则无需传播该子集订购，因为MA已具有该订购的超集的信息。

基于前述，优选的消息路由选择协议是基于话题的路由选择协议，其中授权在订户和相应的话题之间的映射中指示出。授权是针对每个订户或者订户群组/类别指定的，指示该订购有权消耗何种消息或者该产生者(发布者)可以产生(发布)哪些消息。这些授权是在P&M系统中定义的，被传输到发布/订购网络中的所有MA，然后被MA用来创建和更新它们的路由选择表。

所有在发布/订购网络中被路由的消息都在特定信道上被接收或者发送。MA利用这些信道与发布/订购网络中的所有其它物理组件通信。然而，有时候这些接口被中断或者目的地不能跟上负载。在这些情形或其它类似情形中，消息可以被从存储设备召回并且被重传。因此，无论何时需要存储和转发功能，MA都可以有效地与缓存引擎(CE)相关联。另外，因为可靠性、可用性和一致性在企业操作中经常是必须的，所以发布/订购中间件系统可被设计用于容错，其组件中的多个被部署为容错系统。

例如，MA可被部署为容错MA对，其中第一MA被称为主MA，并且第二MA被称为副MA或容错MA(FT MA)。然后，为了存储和转发操作，CE(缓存引擎)可以被连接到主或副的核心/边缘MA。当主或副MA具有到CE的活动连接时，其将被路由的消息的全部或者子集转发给该CE，该CE把它们写到存储区域中以实现持久性。在预定时间段内，然后这些消息当被请求时可用于重传。另外，如图2所示，CE可被部署为容错CE对，其中在发生故障时副CE接管主CE。

如图6所示，CE经由物理介质直接连接到MA，并且其被设计为在高容量和低等待时间的消息传递环境中提供存储转发体系结构的特征。随后，图7是图示了根据本发明一个实施例而配置的CE的框图。

CE 700执行许多功能。对于消息数据持久性，一个功能包括接收由MA转发的数据消息、利用不同的消息头部字段给它们编索引，并且将它们存储在存储区域710中。另一个功能包括对来自MA的消息取回请求进行响应，并且重发已被丢失或未被接收到(并因而被客户再次请求)的消息。

一般来说，CE被建立在与MA相同的逻辑层之上。然而，其本地(例如Tervela^TM)消息传递层被大为简化。因为与被路由到发布/订购网络中的另一个物理组件相比，所有消息都在CE处被本地处理并被递送到其管理消息层714或其缓存层702，所以不需要路由引擎逻辑。如前所述，管理消息除了用于被转发到缓存层702的取回请求之外，通常用于管理目的。所有的数据消息被转发到缓存层，缓存层使用索引服务712首先用基于话题的索引来给消息编索引，然后被转发到存储服务708，用来将消息存储在存储区域701(例如RAID、磁盘等)中。所有的数据消息都被保持在存储区域710中预定义的时间段，存储区域710经常是冗余持久存储器。索引服务712负责“垃圾收集”活动，并且通知存储服务708何时需要从存储区域丢弃过期的数据消息。

CE可以是基于软件的解决方案或者是嵌入式解决方案。更具体的说，CE可被配置为在高端服务器中的操作系统(OS)上运行的软件应用程序。这种服务器可以包括用来增加进出MA的数据传输速率的高性能NIC(网络接口卡)。在另一种配置中，CE是用于使进出MA的网络I/O(输入/输出)加速和使进出存储区域的存储I/O加速的嵌入式解决方案。这种嵌入式解决方案可被设计用于高效地将数据流式传送一个或多个磁盘。因此，为了总的提高性能，CE的实现被设计用于使MA-CE-存储数据传输速率最大化并且用于使被请求的消息的取回等待时间最小化。

例如，为了使MA与CE之间的数据传输最大化，它们的通信链路被实现为直接10Gigabit/s以太网光纤互连或者任何其他高吞吐量且低等待时间的互连，例如Myrinet。并且，为了增大该链路上的吞吐量，CE可以把尽可能多的消息封装到单个大帧中。另外，基于软件的CE经由远程直接存储器访问与MA通信，直接存储器访问绕过了CPU(中央处理器)和OS，从而使吞吐量最大化并使等待时间最小化。然后，为了使存储I/O效率最大化，CE在多个存储设备之间分发磁盘I/O。在一个实现中，CE使用分布式数据库逻辑和分布式高性能冗余存储技术的组合。另外，为了使被请求的消息的取回等待时间最小化，CE的一个实现在把这些消息转储(flush)到存储设备之前使用RAM(随机访问存储器)来保持索引和最新消息或者最常取回的消息。

当与MA接口连接时，CE处理两种类型的消息，一种类型是正常或者说完整的数据消息，并且另一种是不完整或部分发布的数据消息。具体地说，当CE 700的索引服务712接收到部分发布的消息时，其将该消息对比同一话题的上次已知的完整消息进行比较，同一话题的上次已知的完整消息也被描述为该部分发布消息的主镜像。索引服务712在RAM(未示出)中为所有的完整消息保持主镜像。部分发布的消息(具有新值的消息更新)代替了消息的主镜像中的旧值，同时保持了未被从而更新的未改变的值。与任何其他数据消息很象，部分发布的消息被编索引并且可用于重传。并且，象由CE记录的任何其他消息一样，主镜像除了可能被提供作为不同的消息类型或者其消息头部标志可能具有指示其为主镜像的不同值之外也可用于重传。实际上，主镜像可能对应用有价值，并且使用他们相应的API，这种应用可以在任何给定时候请求部分发布的消息流的主镜像。随后，这种应用接收部分发布的消息更新。

为了提供合并的、有保证同时连接的和有保证同时不连接的服务质量(QoS)，消息网络构造必须始终提供数据持久性和完整性。为了提供容错的持久缓存解决方案，这些缓存引擎可被配置和部署为由主和副CE对组成的容错对，或者由多于两个CE节点组成的容错组。如果两个或更多缓存引擎经由基于相同话题的订购而互相逻辑链接，则它们订购相同的数据并从而保持被订购数据的唯一和一致的视图。在数据丢失的情况下，缓存引擎可以向容错组中的其他缓存引擎成员请求丢失数据的重传。同一容错组中的缓存引擎之间的数据同步是通过消息传递网络构造平行化的，消息网络构造经由MA将被订购的消息传递流量的多个拷贝智能且高效地转发到所有的缓存引擎示例。结果，这实现了用于容错和灾难恢复部署的异步数据一致性，其中，与使用存储/磁盘镜像法或数据库复制技术相比，数据同步和持久性是通过消息传递网络构造来执行和保证的。

利用用于冗余和数据一致性的消息传递网络构造的益处之一是与数据和索引(用于数据库复制)和/或磁盘存储开销(用于远程磁盘镜像)相比减少了由同步流量引起的带宽使用，因为在缓存引擎之间只有数据被同步。第二个益处是解决了消息排序，因为消息传送层已经保证了关于任何给定订购的消息的顺序。

为了进一步进行说明，图8示出了具有缓存引擎容错对配置的消息传递设备，并且描述了API从主MA到副MA的故障转移过程。

在CE故障时间之前，即在阶段#1处，两个缓存引擎都接收相同的订购消息传递流量，因为它们都订购了相同的话题。当主缓存引擎发生故障时，事件#2，MA检测到故障，然后转移到副MA(其接管主MA)，副MA依次使API也转移到副MA。在晚些时候，主缓存引擎恢复运行，事件#3；其将重新启动其订购，并且当接收到数据时，其将检测关于其所有订购的数据丢失。将通过发送一个或多个根据每个订购的重传请求到副缓存引擎来请求该丢失数据。数据同步阶段将在主和副缓存引擎之间开始，从而使用消息传递逻辑。

在本发明的一个实施例中，数据同步流量将经过如图8所示的消息传递网络构造一同步路径#1。该路径可被配置为不超过预定义的消息速率或预定义的带宽。这对灾难恢复配置可以是至关重要的，在灾难恢复配置中主和副缓存引擎位于不同的地理位置中，利用诸如WAN链路或专用光纤连接这样的减少带宽的站点间链路。

可替代地，在本发明的另一个实施例中，数据同步流量将经过诸如Infiniband或Myrinet这样的替代高速互连直接链路或交换机，以使同步流量与常规的消息传送流量隔离。这样一种替代同步路径#2可被用作同步流量的主或后备链路。该链路可被静态地配置为专用同步路径，或者可以基于总消息传递网络构造负载来实时动态地选择。缓存引擎或者消息传递设备可以做出决定，以使同步流量离开消息传递网络构造而移向该替代同步路径。

当同步完成时，事件#4，主CE准备好接管。此时，主MA可以变为活动，或者在副CE和/或MA发生故障之前保持不活动。

总而言之，本发明提供了一种用于传输消息的新方法，更具体地说，具有容错持久缓存能力的端到端发布/订购中间件体系结构，其提高了消息传递系统的效率，简化了缓存解决方案的可管理性并且减少了各种水平的有保证的递送服务质量的恢复等待时间。尽管已参考本发明的某些优选版本相当详细地描述了本发明，但是其他版本也是可能的。因此，所附权利要求书的精神和范围不应当被限于对这里所包含的优选版本的描述。

Claims (53)

1.一种消息传递系统，包括：

一个或多个应用；

多个消息传递设备，其操作用于接收和路由消息，包括去往和来自所述应用；以及

多个缓存引擎，其以容错配置布置，其中一个或多个缓存引擎连接到所述多个消息传递设备当中的每个指定的消息传递设备，并且其中所述多个缓存引擎中的每一个相应地订购话题，并且逻辑地链接到被连接到相应地订购相同话题的缓存引擎的所述指定消息传递设备中的任何一个，以提供冗余，使得订购相同话题的一组缓存引擎中的所有缓存引擎接收相同的消息数据并且保持与所述话题相关的所有消息流量的一致、同步的视图。

2.如权利要求1所述的消息传递系统，具有用于路由所述消息流量的消息传递网络构造，所述消息传递网络构造包括所述多个消息传递设备并且被操作用来经由所述消息传递网络构造来提供一致、同步的视图，或者，如果在缓存引擎之间存在直接连接，则经由该直接连接来提供一致、同步的视图，其中实时故障转移是由消息传递设备或缓存引擎基于消息传递网络构造的负载来决定的。

3.如权利要求2所述的消息传递系统，其中，所述直接连接包括高速直接连接或交换机。

4.如权利要求3所述的消息传递系统，其中，所述高速直接连接包括Infiniband或Myrinet互连。

5.如权利要求1所述的消息传递系统，其中，为了保持一致的同步视图，每个缓存引擎被操作用来利用预定义的带宽和/或消息速率来获得所述消息数据。

6.如权利要求1所述的消息传递系统，操作使得当一个或多个缓存引擎发生故障时，连接到相同消息传递设备的保持活动的任何其他缓存引擎接管发生故障的缓存引擎，并且如果未剩下活动的缓存引擎或者当任何其他故障涉及该消息传递设备时，被逻辑链接到发生故障的消息传递设备的缓存引擎的另一个消息传递设备接管发生故障的消息传递设备，其中任何接管对逻辑连接到故障缓存引擎和/或消息传递设备的所述一个或多个应用是透明的。

7.如权利要求6所述的消息传递系统，还操作使得已经恢复的任何发生故障的缓存引擎通过请求保持活动的另一个缓存引擎将丢失数据发送给它来取回所述丢失数据。

8.如权利要求1所述的消息传递系统，其中，每个缓存引擎具有：

消息层，其操作用于发送和接收消息，

具有索引服务的缓存层，其操作用于首先给接收到的消息编索引并且用于保持接收到的部分发布的消息的镜像，

存储设备和存储服务，所述存储服务操作用于将接收到的消息中的全部或者子集存储在所述存储设备中，

一个或多个物理信道接口，用于传输接收到和发送出的消息，以及

具有信道管理的消息传输层，用于控制通过所述一个或多个物理信道接口中的每一个接口的消息的发送和接收。

9.如权利要求8所述的消息传递系统，其中，每个缓存引擎中的所述存储设备操作用于允许被存储的接收到的消息临时地保持为在来自所述缓存引擎的请求时可用于重传。

10.如权利要求1所述的消息传递系统，还包括消息传递网络构造以及设置和管理系统，所述设置和管理系统经由消息传递网络构造链接到所述消息传递设备并且被配置用于与每个消息传递设备交换管理消息。

11.如权利要求1所述的消息传递系统，其中，每个消息传递设备还操作用于通过动态地选择消息传输协议和消息路由选择路径来执行消息的路由选择。

12.如权利要求1所述的消息传递系统，其中，所述消息传递网络构造包括互连，所述互连是基于信道的、网络构造无关的物理介质。

13.如权利要求12所述的消息传递系统，其中，所述互连被配置为以太网、基于存储器的直接连接或Infiniband。

14.如权利要求12所述的消息传递系统，其中，所述互连被配置为操作用于高吞吐量和低等待时间的直接10Gigabit以太网光纤互连或Myrinct互连。

15.如权利要求1所述的消息传递系统，其中，所述消息是用模式和有效负载来构造的，所述模式和有效负载在消息进入所述消息传递系统时被互相分离并且在消息离开所述消息传递系统时被组合。

16.如权利要求10所述的消息传递系统，其中，所述消息和管理消息具有基于话题的格式，每个消息具有头部和有效负载，所述头部除源和目的地命名空间标识字段之外还包括话题字段。

17.如权利要求1所述的消息传递系统，其中，所述消息包括具有话题字段的订购消息，所述话题字段具有可变长度字符串，所述可变长度字符串具有任意数目的通配符字符，用于如果任何话题子字符串和所述订购消息具有相同数目的话题子字符串则将其与这种话题匹配。

18.如权利要求1所述的消息传递系统，其中，所述缓存引擎操作用于提供包括消息数据存储和转发功能的服务质量功能。

19.如权利要求8所述的消息传递系统，其中，所述与每个缓存引擎相关的存储设备包括多个存储装置，所述多个存储装置操作用于分布式消息输入/输出。

20.如权利要求8所述的消息传递系统，其中，所述每个缓存引擎中的消息层包括操作用于处理管理消息的管理消息层。

21.如权利要求8所述的消息传递系统，其中，所述每个消息缓存引擎中的消息层操作用于从所述缓存层取回所请求的消息并且用于将接收到的消息格式化为具有头部字段和有效负载。

22.如权利要求8所述的消息传递系统，其中，所述缓存层还包括随机访问存储器，并且其中所述索引服务还操作用于在所述随机访问存储器中保持所述镜像。

23.如权利要求8所述的消息传递系统，其中，所述由所述缓存层接收和保持的每个部分发布消息的镜像包括更新和未被更新改变的旧值。

24.如权利要求9所述的消息传递系统，其中，所述消息临时保持在所述存储设备中以便可用于重传的时间段是预先确定的。

25.如权利要求8所述的消息传递系统，其中，所述存储设备是冗余的持久存储设备。

26.如权利要求1所述的消息传递系统，其被提供作为基于软件或基于嵌入式的配置。

27.如权利要求1所述的消息传递系统，其被嵌入在在操作系统上运行的软件应用程序中。

28.如权利要求1所述的消息传递系统，其中，所述消息传递流量的一致、同步的视图使得所述消息传递系统可以提供消息传递服务质量，所述消息传递服务质量包括部分发布、合并的、有保证同时连接的和有保证同时不连接的中的一个或者组合。

29.一种用于在消息传递系统中提供服务质量的方法，包括：提供

布置具有多个消息传递设备的消息传递网络构造；

以容错配置来布置多个缓存引擎，其中一个或多个缓存引擎连接到所述多个消息传递设备当中的每个指定的消息传递设备；

通过订购话题将所述多个缓存引擎中的每一个逻辑链接到与这种缓存引擎共同订购类似话题的一个或多于一个的其他缓存引擎所连接到的指定消息传递设备中的任何一个，以提供冗余，

对于订购相同话题的每组缓存引擎，使所述组中的所有缓存引擎同步，使得所述组中的所有缓存引擎接收相同的消息数据并且保持与这种话题相关的所有消息流量的一致、同步的视图，并且其中这种同步使得能够提供消息传递服务质量。

30.如权利要求29所述的方法，其中，消息传递服务质量包括部分发布、合并的、有保证同时连接的和有保证同时不连接的消息传递。

31.如权利要求29所述的方法，还包括，当一个或多个缓存引擎发生故障时，通过连接到相同消息传递设备并且保持活动的任何其他缓存引擎来接管发生故障的缓存引擎，如果未剩下活动的缓存引擎或者当任何其他故障涉及该消息传递设备时，则通过被逻辑链接到所述发生故障的缓存引擎的另一个消息传递设备来接管发生故障的消息传递设备。

32.如权利要求29所述的方法，还包括在所述缓存引擎中的每一个与一个或多个应用之间经由其相应的指定消息传递设备进行接口连接，其中任何故障转移对所述逻辑连接到发生故障的缓存引擎和/或消息传递设备的一个或多个应用是透明的。

33.如权利要求29所述的方法，其中，保持一致、同步的视图是经由所述消息传递网络构造来实现的，或者，如果在缓存引擎之间存在直接连接，则经由这种直接连接来保持一致、同步的视图，其中实时故障转移是由消息传递设备或者缓存引擎基于消息传递网络构造的负载来决定的。

34.一种用缓存引擎来提供服务质量的方法，包括

在具有消息传输层、管理消息层以及带有索引服务和相关存储设备的缓存层的缓存引擎中，执行以下步骤：

通过所述消息传输层接收数据和管理消息；

将所述管理消息转发到所述管理消息层并且将所述数据消息转发到所述缓存层，其中被转发到所述管理消息层的消息取回请求消息被路由到所述缓存层；

在所述索引服务中给所述数据消息编索引，所述索引编制是基于话题的；以及

基于所述索引编制将所述数据消息存储在存储装置中，其中所述数据消息被保持在所述存储装置中预定时间段，在所述预定时间段期间所述数据消息可响应于消息取回请求消息而用于重传。

35.一种用于利用如权利要求34所述的缓存引擎来提供服务质量的方法，其中，所述数据消息是完整的数据消息或者是部分发布的数据消息。

36.一种用于利用如权利要求35所述的缓存引擎来提供服务质量的方法，其中，每个数据消息具有相关的话题，其中所述索引服务保持每个完整数据消息的主镜像，并且对于作为部分完整消息的接收到的数据消息，所述索引服务将所述接收到的数据消息对比具有与所述部分发布消息的话题类似的相关话题的完整消息的最新主镜像进行比较，以确定应当如何更新所述主镜像。

37.一种用于利用如权利要求35所述的缓存引擎来提供服务质量的方法，其中，所述部分发布的消息被编制索引并且可用于重传。

38.一种用于利用如权利要求36所述的缓存引擎来提供服务质量的方法，其中，所述主镜像被编制索引并且可用于重传。

39.一种消息传递系统中的缓存引擎，包括：

消息层，其操作用于发送和接收消息；

缓存层，其具有索引服务、存储设备和存储服务，所述索引服务操作用于首先给接收到的消息编索引并且用于保持接收到的部分发布消息的镜像，所述存储服务操作用于将接收到的消息的全部或者子集存储在所述存储设备中，在所述存储设备中所述消息临时保持为在被请求时可用于重传；

一个或多个物理信道接口，用于传输接收到和发送出的消息；以及

具有信道管理的消息传输层，用于控制通过所述一个或多个物理信道接口中的每一个接口的消息的发送和接收。

40.如权利要求41所述的缓存引擎，其被部署为容错缓存引擎对或容错缓存引擎组的一部分并具有容错能力，其中当发生故障时，副缓存引擎接管主缓存引擎。

41.如权利要求42所述的缓存引擎，其中，所述消息层包括操作用于处理管理消息的管理消息层。

42.如权利要求39所述的缓存引擎，其中，所述消息层操作用于从所述缓存层取回所请求的消息并且用于将接收到的消息格式化为具有头部字段和有效负载。

43.如权利要求39所述的缓存引擎，其中，所述缓存层还包括随机访问存储器，并且其中所述索引服务还操作用于在所述随机访问存储器中保持所述镜像。

44.如权利要求39所述的缓存引擎，其中，所述由所述缓存层接收和保持的每个部分发布消息的镜像包括更新和未被更新改变的旧值。

45.如权利要求39所述的缓存引擎，其中，所述消息临时保持在所述存储设备中以便可用于重传的时间段是预先确定的。

46.如权利要求39所述的缓存引擎，其中，所述存储设备是冗余的持久存储设备。

47.如权利要求39所述的缓存引擎，其被提供作为基于软件或基于嵌入式的配置。

48.如权利要求39所述的缓存引擎，其被嵌入在在操作系统上运行的软件应用程序中。

49.如权利要求39所述的缓存引擎，其操作用于提供部分数据发布服务以及有保证同时连接的和有保证同时不连接的消息递送服务质量。

50.如权利要求39所述的缓存引擎，其中，所述存储设备包括多个存储装置，所述多个存储装置操作用于分布式消息输入/输出

51.如权利要求1所述的消息传递系统，还包括操作用于所述缓存引擎的管理操作的设置和管理系统。

52.如权利要求1所述的消息传递系统，还包括一个或多个应用编程接口，所述一个或多个应用编程接口操作用于允许所述应用以本地消息格式进行发布和订购。

53.如权利要求1所述的消息传递系统，还包括一个或多个协议翻译引擎，所述一个或多个协议翻译引擎与所述消息传递设备中的任何一个相关并且操作用于允许所述应用以外部消息格式进行发布和订购。

Images