CN101326508A - 智能消息传递应用编程接口 - Google Patents

Abstract

消息发布/订购***被要求处理高消息容量，同时减少等待时间和性能瓶颈。本发明所介绍的智能消息传递应用编程接口被设计用于高容量、低等待时间的消息传递。API是发布/订购中间件***的一部分。利用API，该***操作用来实时地对包括等待时间的***性能进行监视，使用基于话题和基于信道的消息通信，并且动态地优化***互连配置和消息传输协议。

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)有关并且通过引用而结合上述申请。

技术领域

本发明涉及数据消息传递中间件体系结构，并且更具体地涉及具有发布和订购(此后称为“发布/订购”)中间件体系结构的消息传递***中的应用编程接口。

背景技术

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

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

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

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

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

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

另外，在发布者和订购者之间的路径中，消息在应用之间的跳(hop)中传播，其中每一跳都引入了应用和操作***(OS)等待时间。因此，总的端到端等待时间随着跳的数目增长而增加。还有，当从发布者向订购者路由消息时，沿着路径的消息吞吐量受路径中的最慢节点所限制，并且在现有***中无法实现端到端消息传递流控制来克服该限制。

现有体系结构的另一个普遍缺点是它们的缓慢并且经常大量的协议变换。这是因为企业应用集成(EAI)领域中的IT(信息技术)权宜(band-aid)策略，其中越来越多的新技术被与遗留***集成。

因此，需要在许多区域中提高数据消息传递***的性能。性能可能需要提高之处的示例是速度、资源分配、等待时间等等。

发明内容

本发明部分地基于上述观察并基于如下观念，即可以使用不同的方法来解决这种缺点且具有更好的结果。这些观察引起了用于高容量和低等待时间的消息传递的端到端消息发布/订购中间件体系结构的产生，特别引起了智能消息传递应用编程接口(API)的产生。因此，对于与应用的通信，具有端到端消息发布/订购中间件体系结构的数据分配***可以有利地传送显著更高的消息容量并且具有显著更低的等待时间，所述端到端消息发布/订购中间件体系结构包括根据本发明的原理的智能消息传递API。为了实现该目的，本发明例如设想通过可靠、高度可用、基于会话的容错设计并通过引入以下特征的各种组合来改善API与消息传递设备之间的通信，所述特征包括：迟模式绑定、部分发布、协议优化、实时信道优化、增值计算定义语言、智能消息传递网络接口硬件、应用的DMA(直接存储器访问)、***性能监视、消息流控制、具有临时缓存的消息传输逻辑以及增值消息处理。

从而，根据如图所示并在这里概况描述的本发明的目的，一种用于应用与发布/订购中间件***之间的通信的示例性API包括通信引擎、一个或多个存根，以及进程间通信总线(我们简称为总线)。在一个实施例中，当例如多于一个应用使用单个通信引擎来接收和发送消息时，通信引擎可被实现为守护进程(Daemon)。在另一个实施例中，通信引擎可和存根一起被编译到应用中，以消除额外的守护跳。在这种情况下，通信引擎和存根之间的总线将被定义为进程内通信总线。

在该实施例中，所述通信引擎被配置为充当应用与发布/订购中间件***之间的通信的网关。所述通信引擎的操作对应用是透明的，用于使用动态选择的消息传输协议从而提供协议优化，并用于对传输信道资源和流实时地进行监视和动态控制。所述一个或多个存根被用于所述应用与所述通信引擎之间的通信。进而，所述总线被用于所述一个或多个存根与所述通信引擎之间的通信。

还是根据本发明的目的，API的第二示例包括通信引擎、一个或多个存根和总线。该实施例中的通信引擎被建立在包括消息层和消息传输层的逻辑层上，其中所述消息层包括应用递送路由引擎、管理消息层和消息路由选择引擎，并且其中所述消息传输层包括信道管理部分，所述信道管理部分用于基于***资源使用实时地控制由所述消息层处理的消息的传输路径。

上述的实施例是用于实现API的示例中的两个，并且其他示例根据附图和后面的描述将变得显而易见。总之，根据这里的描述、所述权利要求书和此后描述的附图，本发明的这些和其他特征、方面和优点将变得更加明白。

附图说明

被结合于此并组成本说明书的一部分的附图图示了本发明的各种方面，并和具体描述一起用来说明本发明的原理。为了方便，整个附图中将使用相同的标号来指示相同或相似的元件。

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

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

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

图2a是示出了具有创建网络骨干网非居间化的消息设备(MA)的企业基础设施物理布署的图。

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

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

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

图6示出了智能消息传递应用编程接口(API)。

图7示出了自适应消息流控制的影响。

图8a和图8b示出了智能网络接口卡(NIC)的配置。

图9示出了基于会话的容错(fault tolerant)设计。

图10示出了消息传递设备(MA)到API的接口。

具体实施方式

这里的描述提供了根据本发明的各种实施例的消息发布-订购***的端到端中间件体系结构的细节，特别是智能消息传递应用编程接口(API)的细节。在概括这些各种实施例的细节之前，下面是对本说明书中所使用的术语的简单说明。注意，该说明仅是为了澄清并且向读者给出对可能如何使用这些术语的理解，但是不是将这些术语限于使用它们的上下文中，也不是要因此限制权利要求书的范围。

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

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

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

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

术语“总线”通常被用来描述互连，并且其可以是基于硬件或软件的互连。例如，术语总线可被用来描述诸如使用套接字和共享存储器的进程间通信链路，并且其还可被用来描述诸如函数调用这样的进程内链接。从这里的描述可以确认，可以利用在中间件体系结构中以各种配置实现的智能消息传递应用编程接口(此后称为“API”)以各种方式实施本发明。描述因此以图1所示的端到端中间件体系结构的示例开始。

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

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

利用所示结构配置和逻辑通信，该具有发布/订购中间件体系结构的分布式消息传递***被设计来执行多种逻辑功能。一种逻辑功能是消息协议翻译，该功能有利地在边沿消息传递设备(MA)组件处执行。这是因为发布/订购中间件***的边界内的通信是利用针对消息的本地协议独立于下层传输逻辑被执行的。这就是将这种体系结构称为传输透明基于信道的消息传递体系结构的原因。

第二种逻辑功能是将消息从发布者路由到订购者。注意，这些消息被路由过整个发布/订购网络。因此，路由选择功能由其中传播消息的每个MA执行，即，从边沿MA 106a-b(或者API)到核心MA 108a-c，从一个核心MA到另一个核心MA，最终到达边沿MA(例如，106b)或者API110a-b。API 110a-b经由进程间通信总线(套接字、共享存储器等)或经由诸如函数调用这样的进程内通信总线与应用112_1-n通信，以发布和订购消息。

第三种逻辑功能是针对不同类型的有保证的递送服务质量存储消息，包括例如有保证同时连接的和有保证同时不连接的。这是通过添加存储转发功能来实现的。

第四种功能是将这些消息递送到订购者。(如图所示，API 106a-b将消息递送到订购应用112_1-n)。

在这种发布/订购中间件体系结构中，***配置功能以及其他管理和***性能监控功能由P&M***管理。配置涉及发布/订购中间件***网络和组件的物理和逻辑配置。监控和报告涉及对所有网络和***组件的健康进行监控并且自动报告结果，这是按照每个要求进行的或者被记入日志。P&M***利用管理消息执行其配置、监控和报告功能。另外，P&M***允许***管理员定义与被路由遍该发布/订购***的每个消息相关联的消息命名空间。因此，发布/订购网络可以物理地和/或逻辑地被划分成基于命名空间的子网络。

P&M***管理具有一个或多个MA的发布/订购中间件***。这些MA取决于它们在***中的角色被布署为边沿MA或者核心MA。边沿MA在大多方面与核心MA类似，除了其包括协议翻译引擎之外，协议翻译引擎将消息从外部协议翻译成本地协议和从本地协议翻译成外部协议。因此，一般来说，消息传递***中发布/订购中间件体系结构的边界(即，端到端发布/订购中间件***边界)由其中存在边沿MA 106a-b和API110a-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 106a被路由的另一条路线是内部通过核心MA 108b。该路径被称作通信路径1b。沿着该路径，核心MA 108b将本地消息路由到边沿MA 106a。但是，在边沿MA 106a将本地协议消息路由到外部数据目的地116₁之前，其将它们转换成适于该外部数据目的地116₁的外部消息协议。可见，这种通信路径不要求API将消息从发布者路由到订购者。因此，如果发布/订购***被用于外部源到目的地的通信，则该***无需包括API。

被称作通信路径2的另一条通信路径利用API 110b将外部数据源114n链接到一个应用。从外部数据源接收到的已发布的消息在边沿MA106a处被翻译成本地消息协议，然后被该边沿MA路由到核心MA 108。从第一核心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的交易单通过发布/订购网络(经由核心MA308a-b和边沿MA 306b)放置回市场数据交换设备320_1-n。

图2a中示出了下层物理布署的一个示例。如图所示，MA被直接彼此连接，并且被直接***到网络和子网，在网络和子网中消息传递流量的客户和发布者被物理连接。在这种情形中，互连应当是直接连接，即，MA之间的直接连接和它们与P&M***之间的直接连接。这使得能够实现网络骨干网非居间化，以及消息传递流量与其他企业应用流量物理分离。有效地，MA可以被用来移除对用于消息传递流量的传统路由网络的依赖。

在物理布署的这种示例中，诸如市场数据交换设备之类的外部数据源或者目的地被直接连接到边沿MA，例如，边沿MA1。诸如市场交易应用之类的消息传递流量消耗或发布应用被直接连接到子网1-12。这些应用具有至少两条路线，用于订购、发布或者与其他应用通信；它们可以或者利用企业骨干网或者利用消息传递骨干网，其中企业骨干网包括多层冗余的路由器和交换机，它们传送所有的企业应用流量，包括但不限于，消息传递流量；消息传递骨干网包括经由集成交换机彼此直接互连的边沿和核心MA。

利用替换骨干网具有这样的优点：将消息传递流量与其他企业应用流量隔离，从而更好地控制消息传递流量的性能。在一种实现方式中，位于子网6中的应用逻辑上或者物理上连接到核心MA3，利用Tervela API订购或者发布本地协议的消息流量。在另一种实现方式中，位于子网7中的应用逻辑上或者物理上连接到边沿MA1，订购或者发布外部协议的消息传递流量，其中该MA利用集成的协议变换引擎模块执行协议变换。逻辑上，发布/订购网络的物理组件被构建在类似于开放***互连(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将在将要处理的消息路由到传输信道3261-n之前，将它们发送过协议翻译引擎(PTE)332，从而执行协议翻译。从而，信道对与物理介质的接口3281-n、与该物理介质相关联的特定网络和传输逻辑、以及消息组件或者片段进行管理。

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

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

图3进一步示出了在具有中间件体系结构的网络中的多种可能的信道实现方式。在一种实现方式340中，通信是利用通过太网交换的网络的多播，经由基于网络的信道执行的，其中以太网交换的网络充当用于这种通信的物理介质。在这种实现方式中，源从其IP地址经由其UDP端口将消息发送向具有在其关联的IP地址上的各个UDP端口的目的地群组(因此是多播)。在这种实现方式的变体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包括有效载荷。示出了两类消息，即，数据和管理消息，这两类消息具有不同的消息体和有效载荷类型。头部包括用于以下内容的字段：源和目的地命名空间标识、源和目的地会话标识、话题序列号和希望时间戳，另外，其还包括话题注释字段(该字段优选是可变长度的)。话题可以被定义为基于标记的字符串，例如，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匹配

示例#3：具有通配符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示出了基于话题的消息路由选择，其中话题通常被定义为基于标记(token)的字符串，例如，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必须针对发布/订购网络的授权对订购进行检查。MA验证可能是邻居MA、P&M***、CE或者API的订购实体被授权如此执行。如果该订购是有效的，则路由将被创建并且被添加到路由选择表。然后，因为一些授权可能是预先已知的，所以***可以被布署以预定义授权，并且在引导时这些授权可以被字段加载。例如，诸如配置更新之类的一些特定管理消息可能总是被转发遍网络，并且因此在启动时被自动载入。

在给出了对具有发布/订购中间件体系结构的消息传递***的上述描述的情况下，可以明白，在处理用于应用的消息传递时，智能消息传递应用编程接口(在此简称为API)在这种***中具有重要的角色。应用依赖于API来进行所有消息传递，包括进行注册、发布和订购。注册包括把管理注册请求发送到一个或多个MA，所述一个或多个MA确认API和应用的授权以便进行注册。一旦它们的注册被确认，则应用可以订购和发布关于被授权的任何话题的信息。相应地，我们现在转向对根据本发明的原理配置的API的细节进行描述。图6是图示了API的框图。

在该图示中，API是API通信引擎602和API存根(stub)604的组合。通信引擎602是通常所说的在操作***下运行的用于处理计算机***希望接收的周期***请求的程序；但是在一些情况下，其被嵌入在应用本身当中并因而是进程内通信总线。通信引擎程序将请求转发给其他合适的程序(或进程)。在这种情况下，API通信引擎起应用与发布/订购中间件***之间的网关的作用。如所指的，API通信引擎通过动态地选择传输协议和动态地调节单个帧中要封装的消息的数目来管理与MA之间的应用通信。被封装在单个帧中的消息的数目取决于多个因素，例如MA和API主机中的消息速率和***资源利用。

应用使用API存根604来与API通信引擎进行通信。通常，使用远程过程调用(RPC)的应用程序是用存根进行编译的，该存根用所请求的远程过程来替换该程序。存根接受RPC并将其转发给远程过程，远程过程在完成时将结果返回存根，以将结果传递给进行RPC的程序。在一些情况下，API存根与API通信引擎之间的通信是经由进程间通信总线完成的，所述进程间通信总线是使用诸如套接字或共享存储器这样的机制来实现的。API存根可以用各种编程语言得到，这些编程语言包括C、C++，Java和.NET。API本身可以用多种语言完整得到，并且其可以在不同的操作***上运行，包括微软Windows^TM，Linux^TM和Solaris^TM。

API通信引擎602和API存根604被编译并被链接到正在使用API的所有应用606。API存根与API通信引擎之间的通信是经由进程间通信总线608完成的，所述进程间通信总线是使用诸如套接字或共享存储器这样的机制来实现的。API存根604可以用各种编程语言得到，这些编程语言包括C、C++，Java和.NET。在一些情况下，API本身可以用多种语言得到。API在不同的操作***平台上运行，其中的三个示例是Windows^TM，Linux^TM和Solaris^TM。

API通信引擎被建立在诸如消息传输层610这样的逻辑层上。和与物理介质接口直接交互的MA不同，API多数实现在操作***之上并且其消息传输层经由OS进行通信。为了支持不同类型的信道，OS对于其默认不支持的每种物理介质可能需要特定的驱动程序。OS还可能要求用户***特定的物理介质卡。例如，诸如直接连接(DC)或Infiniband这样的物理介质需要特定接口卡和其相关的OS驱动程序，以允许消息传输层在信道上发送消息。

API中的消息传递层612也有点类似于MA中的消息传递层。然而主要差异在于进入消息在API和MA中分别沿着不同的路径前进。在API中，数据消息被发送到应用递送路由引擎614(更少的模式约束)并且管理消息被发送到管理消息层616。除了将应用(606)映射到订购而非将信道映射到应用之外，应用递送路由引擎的行为类似于消息路由选择引擎618。因此，当进入消息到达时，应用递送路由引擎查找所有的订购应用，然后将该消息的副本或者对该消息的引用发送到所有这些订购应用。

在一些实现中，应用递送路由引擎负责迟计划绑定(late schemabinding)特征。如前所述，本地(例如Tervela^TM)消息传递协议以原始且压缩的格式提供信息，该格式不包含底层数据的结构和定义。结果，消息传递***有利地减小其带宽利用并从而允许增加的消息容量和吞吐量。当API接收到数据消息时，API将原始数据绑定到其计划，从而允许应用透明地访问信息。计划通过提供域名、域类型与域在消息主体中的偏移位置之间的映射来定义消息的内容结构。因此，应用可以请求特定域名而无需知道该域在消息中的位置，并且API使用偏移来定位该信息并将其返回给应用。在一个实现中，当应用请求从/向MA进行订购或发布时，计划是由MA提供的。

在很大程度上，外出消息遵循与MA中相同的输出逻辑。的确，API可以和MA一样具有协议优化服务(POS)620。然而，发布/订购中间件***是按照基于主从的配置用分布在MA与API通信引擎之间的POS来进行配置的。然而，与MA中自行决定何时改变信道配置的POS不同，API中的POS充当其所链接到的MA中的主POS的从属。主POS和从POS都对***和网络资源随时间消逝的消耗计划进行监视。从POS把这些资源消耗计划的全部、子集或汇总传送给主POS，并且主POS基于这些计划来确定如何把消息递送给API通信引擎，包括通过选择传输协议来把消息递送给API通信引擎。例如，从单播、多播或广播消息传输协议当中选择的传输协议对环境不总是适合。因此，当MA上的POS决定改变信道配置时，其远程地控制API处的从POS。

在消息传递发布/订购中间件***中执行其角色时，API优选对应用透明，这是因为其使得用于处理应用请求的***资源利用最小化。在一种配置中，API通过执行零拷贝消息接收(即省略从网络接收到的消息的应用存储空间的拷贝)来优化存储器拷贝的数目。例如，API通信引擎将缓冲(存储空间)引入网络接口卡，以将进入消息直接写入API通信引擎的存储空间。这些消息对应用变得可经由共享存储器进行访问。类似地，API执行从应用的存储空间直接到网络的零拷贝消息传递。

在另一种配置中，API使得用于执行消息接收和发送任务所需的CPU处理量减少。例如，API通信引擎执行批量消息接收和发送任务，而不是一次接收或发送一条消息，从而使CPU处理周期的数目减少。这种批量消息传输经常涉及消息队列。因此，为了使端到端等待时间最小化，批量消息传输需要把保持消息排队的时间限制为小于可接受的等待时间阈值。

为了保持上述的透明性，API对由应用发布或订购的消息进行处理。为了减少***带宽使用并从而增加***吞吐量，以原始且压缩的格式来传送消息信息。因此，当API接收到数据消息时，API将原始数据绑定到其计划，从而允许应用透明地访问信息。计划通过提供域名、域类型与域在消息主体中的偏移位置之间的映射来定义消息的内容结构。结果，应用可以请求特定域名而无需知道该域在消息中的位置，并且API使用偏移来定位该信息并将其返回给应用。附带提及，为了更有效地利用带宽，应用可以订购一话题，其中其请求仅接收来自消息流的更新后的信息。由于这种订购，MA将新消息与先前递送的消息进行比较并且仅将更新发布给应用。

另一种实现提供了在订购应用与API之间以预先商定的格式呈现接收到的或发布的数据的能力。该内容转换是由呈现引擎执行的并基于由应用提供的数据呈现格式。数据呈现格式可被定义为底层数据计划与应用数据格式之间的映射。例如，应用可以以XML格式发布和使用数据，API将在该XML格式与底层消息格式之间来回进行转换。

API还被设计用于实时信道优化。具体地说，MA与API通信引擎之间的通信是在一条或多条信道上执行的，其中每条信道传输与一个或多个订购或发布相对应的消息。MA和API通信引擎不断地监视通信路径中的每条路径并且动态地优化可用资源。这是通过使与数据发布/订购有关的处理开销最小化并保留用于发布和订购应用的必需和预期的***资源来完成的。

在一个实现中，API通信引擎使能了实时信道消息流控制特征，用于防止一个或多个应用用完可用的***资源。该消息流控制特征是由订购的QoS(服务质量)控制的。例如，对于上次已知值或尽力而为型QoS，处理较少的优质数据常常比处理较多的劣质数据更重要。例如，如果数据质量是通过其时效来测量的，则仅处理最新信息可能会更好。另外，API通信引擎将信道队列的当前状态通知给MA，而不是等待队列溢出并把处理旧数据的负担留给应用和丢失最新数据。

图7图示了实时消息流控制(MFC)算法的影响。根据该算法，信道队列的大小可以作为阈值参数工作。例如，通过特定信道递送的消息在接收设备侧积累在其信道队列中，并且随着该信道队列的增长其大小可能达到一高阈值，一旦其大小超过该高阈值，信道就可能无法跟上进入消息流。当接近这种情况(其中信道处于达到其最大容量的危险中)时，接收消息传递设备在信道队列溢出之前可以激活MFC。当队列缩小并且其大小变得小于一低阈值时，MFC被关闭。高与低阈值之间的差被设为足够用来产生所谓的迟滞行为，其中MFC在比其被关闭时的队列大小值更高的队列大小值处被开启。该阈值差避免了当队列大小在高阈值周围徘徊时否则将会发生的消息流控制的频繁开关振荡。因此，为了避免消息传递接收者侧的队列溢出，可以用将速率保持在最大信道容量之下的实时、动态MFC来将进入消息的速率保持在控制中。

作为在信道队列接近其容量时丢失消息的基于迟滞的MFC算法的替代，实时动态MFC可以操作用来混合数据或对订购队列应用某合并算法。然而，因为该操作可能需要另外的消息变换，所以MA可能后退到慢转发路径而不是留在快转发路径上。这将避免消息变换对消息传递吞吐量产生消极影响。另外的消息变换是由与协议翻译引擎类似的处理器执行的。这种处理器的示例包括NPU(网络处理单元)、语义处理器、MA上的单独微引擎等等。

为了更高的效率，实时合并或订购级的消息处理可被分配在发送者和接受者之间。例如，在订购级的消息处理仅被一个订购者请求的情况下，与在发送者侧执行它相比，将它向下推至接收者侧是合理的。然而，如果数据的多于一个消费者正请求相同的订购级消息处理，则在上游的发送者侧执行它将会更合理。在信道的发送者和接收者侧之间分配工作负荷的目的是最优地使用可用的组合处理资源。

当信道把多个消息封装在单个帧中时，其可以通过释放一些处理资源而将消息等待时间保持在最大可接受等待时间之下并且减轻接收侧的压力。接收更少的大帧有时比处理许多小帧更有效。对于可能在使用包括CPU、存储器和NIC的一般计算机硬件组件的典型OS上运行的API而言尤其是如此。典型的NIC被设计为对每个接收到的帧生成OS中断，这从而减少了API把消息递送给订购应用所可用的应用级别的处理时间。

如图7所进一步示出，如果信道队列的当前水平越过了最大阈值，则MA压制该特定信道上的消息速率，以减少API通信引擎上的负载并允许应用返回稳定状态。在该压制过程中，取决于服务的订购质量，将使最新消息优先于旧消息。如果队列回到正常负载水平，则API可以通知MA禁用信道消息流控制。

在上述实现的一个变种中，消息流控制特征是在消息传递路由路径(去/来自应用)的API侧实现的。每当消息需要被递送给订购应用时，API通信引擎就可以做出判定，以在服务的订购质量允许的情况下以有利于跟随更新消息的方式丢弃消息。

总之，在API中或在MA中，消息流控制可以应用不同的压制策略，其中API通信引擎或者被连接到该API通信引擎的MA可以执行基于订购的数据合并(亦称为数据混合)，而不是有利于新消息而丢弃旧消息。换言之，丢弃的数据未被完全丢失而是被与最新数据混合。在一个实施例中，可以在给定的API和其MA之间为所有信道全局地定义这种消息流控制压制策略，并且可以根据P&M***将该策略配置为合并的服务质量。该QoS将应用于订购该合并QoS的所有应用。在另一个实施例中，该压制策略可以经由来自应用的API函数调用来自定义，从而提供了一些灵活性。在这种特殊情况下，API通信引擎在与MA建立信道时传达压制策略。信道配置参数是在该阶段期间在API通信引擎与MA之间商定的。

注意到当该自定义压制策略是在订购级而非在消息级实现的时，应用可以在订购给定话题时定义策略。基于订购的压制策略然后被加入该特定订购的信道配置。

API通信引擎可被配置为提供增值消息处理；API所连接到的MA也可以这样做。对于增值消息处理，应用可以订购给定订购或一组订购的在线(inline)增值消息处理服务。该服务将随后被执行或被应用于所订购的消息流。另外，应用可以使用高级消息处理语言来注册一些伪代码，用来引用消息中的域(例如NEWFIELD＝(FIELD(N)+FIELD(M))/2，这样用等于域N和M的算术平均的值在消息的末端定义了新域的建立)。这些增值消息处理服务在新消息被处理时可以要求服务专用状态被保持和更新。将以与定义域相同的方式来定义这些状态，并且将以伪代码重新使用它们(例如STATE(0)+＝FIELD(N)，这意味着状态号码0是FIELD(N)的累加和)。这些服务可被默认定义在***中并且应用在订购特定话题时只需使能这些服务，或者它们可以是自定义的。总之，可以通过API通信引擎或被连接到该API的MA来执行这种在线增值消息处理服务。

与在线增值消息处理服务类似，基于内容的访问控制列表(ACL)可以取决于实现而被部署在API通信引擎或MA上或者被部署在这两者上。例如假定股票交易员可能仅当IBM价格高于$50时对具有IBM报价的消息有兴趣，否则其优选丢弃所具有的报价低于该值的所有消息。为此，API(或MA)还能够定义基于内容的ACL并且应用将定义基于订购的ACL。基于订购的ACL可以是使用消息中的域来表达的ACL条件和以REJECT、ACCEPT、LOG的形式或另一合适方式表达的ACL动作的组合。这种ACL的一个示例是：((FIELD(n)＜VALUE，ACCEPT，REJECT|LOG)。

为了进一步提高效率，API通信引擎可被配置为把消息处理中的一些转给智能消息传递网络接口卡(NIC)。该智能消息传递NIC被提供用于通过以硬件执行完整的网络堆栈来绕过联网I/O，用于执行从I/O卡直接到应用存储空间的DMA并且用于管理消息传递可靠性，包括重传和临时缓存。智能消息传递NIC可以进一步执行信道管理，包括如上所述的消息流控制、增值消息处理和基于内容的ACL。图8a和图8b中分别图示了这种智能消息传递NIC的两种实现。图8a图示了存储互连卡808，并且图8b图示了消息传递卸载卡810。这两种实现都包括主机CPU 802、主机存储器804和PCI主机桥806。

正如众所周知的，稳定性、可用性和一致性在企业操作中经常是必须的。为此，发布/订购中间件***可被设计用于容错，其组件中的多个被部署为容错***。例如，MA可被部署为容错MA对，其中第一MA被称为主要MA，并且第二MA被称为次要MA或容错MA(FT MA)。此外，为了存储和转发操作，CE(缓存引擎)可以被连接到主要或次要的核心/边缘MA。当主要或次要MA具有到CE的活动连接时，其把路由消息的全部或子集转发给该CE，该CE把它们写入存储区域用于保持。在预定时间段内，然后这些消息当被请求时可用于重传。

图10中示出了容错设计的一个示例。在该示例中，***是基于会话的容错。另一种可能的配置是完全故障转移(failover)，但是在该示例中我们已经选择了基于会话的容错。会话被定义为两个MA之间或者一个MA与一个API之间的通信。会话包括两个MA之间或者一个MA与一个API之间的通信(例如910)并且其可以是主动或被动的。如果故障发生，则MA或API可以决定把会话从主要MA 906切换到次要MA 908。当会话经历连接性和/或诸如CPU、存储器、接口等这样的***资源的故障时，故障就会发生。连接性问题是根据底层信道来定义的。例如，基于IP的信道在损失、延迟和/或抖动随着时间异常地增加时将经历连接性问题。对于基于存储器的信道，连接性问题可根据存储地址冲突等来定义。每当会话经历一些连接性和/或***资源问题时，MA或API就决定把会话从主要MA切换到次要MA。

在一个实现中，主要和次要MA可被看作是使用一些基于信道的逻辑来将逻辑信道地址映射到物理信道地址的单个MA。例如，对于基于IP的信道，API或MA可以通过把MA逻辑地址的ARP缓存条目更新为指向次要MA的物理MAC地址来把有问题的会话重定向到次要MA。

总之，基于会话的容错设计具有当只有所有会话中的一个或子集经历问题时不影响所有会话的优势。就是说，当会话经历一些性能问题时，该会话被从主要MA(例如906)移动到次要容错(FT)MA 908，而不影响与该主要MA 906相关的其他会话。所以，例如AP1-4被示出为仍具有与主要MA 902(作为活动MA)的相应活动会话，而AP5具有与FT MA 908的活动会话。

在与相应MA进行通信时，API使用经由一个或多个物品或智能消息传递卸载NIC连接的物理介质。图10图示了用于API与MA之间的通信的接口。

总之，本发明提供了一种进行消息传递的新方法，更具体地说，提供了一种具有智能消息传递应用编程接口的新的发布/订购中间件***。虽然已经参照本发明的某些优选版本相当详细地描述了本发明，但是其它版本也是可能的。因此，所附权利要求书的精神和范围应当不限于这里所包含的对优选版本的描述。

Claims (36)

1.一种用于应用与发布/订购中间件***之间的通信的应用编程接口，包括：

通信引擎，其被配置为充当用于应用与具有所述通信引擎的发布/订购中间件***之间的通信的网关，其中所述通信引擎的操作对应用而言是透明的，用于使用动态选择的消息传输协议并用于对传输信道资源和流实时地进行监视和动态控制；

一个或多个存根，用于所述应用与所述通信引擎之间的通信；以及

总线，用于所述一个或多个存根与所述通信引擎之间的通信。

2.如权利要求1所述的应用编程接口，其中，所述总线是进程间通信总线或进程内通信总线。

3.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于动态地调节被封装在一个帧中的消息的数目。

4.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于基于会话的容错。

5.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于消息的临时缓存。

6.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于增值消息处理。

7.如权利要求6所述的应用编程接口，其中，所述增值消息处理包括基于内容的访问控制列表的部署，其中所述列表中的每个条目与一个访问条件和动作相关联。

8.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于向所述发布/订购中间件***中的消息传递设备进行注册并变得逻辑上连接到所述消息传递设备。

9.如权利要求8所述的应用编程接口，其中，所述注册是将请求记入日志并且订购是基于话题的，其中话题定义了所述应用编程接口对之具有发布/订购授权的共享访问域。

10.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于迟计划绑定。

11.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于部分消息发布。

12.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于所述应用对被存储的消息进行直接存储器访问。

13.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于处理批量消息传递。

14.如权利要求12所述的应用编程接口，其中，处理所述批量消息传递包括消息排队，所述消息排队带有限制以避免队列溢出和通信等待时间。

15.如权利要求1所述的应用编程接口，其中，所述实时消息传输资源和流控制使用如下策略：或者识别并不顾旧消息，或者使消息混合。

16.如权利要求15所述的应用编程接口，其中，所述策略被全局地应用于与所述应用编程接口相关的所有消息传输路径。

17.如权利要求15所述的应用编程接口，其中，所述策略是用户定义的。

18.如权利要求15所述的应用编程接口，其中，所述策略在应用订购时被定义和实现。

19.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于以原始压缩数据格式处理消息并把所述原始数据绑定到其计划。

20.如权利要求6所述的应用编程接口，其中，所述增值消息处理是在应用注册期间定义的。

21.如权利要求1所述的应用编程接口，其中，所述通信引擎还操作用于卸载到接口卡的消息处理。

22.如权利要求1所述的应用编程接口，其中，所述发布/订购中间件***包括消息传递设备，并且其中在所述消息传递设备与所述应用编程接口之间以基于主从的配置分配协议优化，其中所述应用编程接口作为从方。

23.如权利要求2所述的应用编程接口，其中，所述进程间通信总线如果被使用则是使用套接字或共享存储器来实现的，并且所述进程内通信总线如果被使用则是使用函数调用来实现的。

24.一种用于应用与发布/订购中间件***之间的通信的应用编程接口，包括：

通信引擎，其被配置为充当用于应用与发布/订购中间件***之间的通信的网关，所述通信引擎具有包括消息层和消息传输层的逻辑层，其中所述消息层包括应用递送路由引擎、管理消息层和消息路由选择引擎，并且其中所述消息传输层包括信道管理部分，所述信道管理部分用于基于***资源使用来实时地控制由所述消息层处理的消息的传输路径；

一个或多个存根，用于所述应用与所述通信引擎之间的通信；以及

总线，用于所述一个或多个存根与所述通信引擎之间的通信。

25.如权利要求24所述的应用编程接口，其中，所述通信引擎被部署在操作***之上。

26.如权利要求24所述的应用编程接口，其中，所述操作***包括用于接口卡的驱动程序，其中所述信道管理部分通过所述接口卡与用于向和从所述应用传输消息的物理介质接口连接。

27.如权利要求26所述的应用编程接口，其中，所述接口卡是操作用于存储器互连或用于消息处理卸载的网络接口卡。

28.如权利要求26所述的应用编程接口，其中，所述接口卡包括基于硬件的联网I/O(输入/输出)堆栈并且操作用于用于传输的直接存储器访问和缓存。

29.如权利要求24所述的应用编程接口，其中，所述消息路由选择引擎包括传输协议优化服务部分。

30.如权利要求24所述的应用编程接口，其中，所述应用递送路由引擎操作用于把应用映射到话题订购。

31.如权利要求24所述的应用编程接口，其中，所述信道管理部分控制多个信道并且所述应用递送路由引擎基于所述映射把消息递送给应用。

32.如权利要求30所述的应用编程接口，其中，所述管理消息层处理管理消息并且所述路由和应用递送路由引擎处理数据消息。

33.如权利要求23所述的应用编程接口，其中，所述通信引擎和所述一个或多个存根被编译并被链接到如下应用，所述应用使用所述应用编程接口来与所述发布/订购中间件***进行通信。

34.如权利要求23所述的应用编程接口，其中，所述通信引擎还操作用于迟绑定计划。

35.如权利要求34所述的应用编程接口，其中，所述应用递送路由引擎操作用于把计划绑定到原始消息数据，从而允许所述应用透明地访问消息信息。

36.如权利要求1所述的应用编程接口，还包括呈现引擎，其操作用于使来往于所述应用的进入消息和外出消息在应用数据格式与消息传递数据计划之间进行转换。

Images