CN101124566A - 端到端的发布/订购中间件体系结构 - Google Patents
端到端的发布/订购中间件体系结构 Download PDFInfo
- Publication number
- CN101124566A CN101124566A CNA2005800460945A CN200580046094A CN101124566A CN 101124566 A CN101124566 A CN 101124566A CN A2005800460945 A CNA2005800460945 A CN A2005800460945A CN 200580046094 A CN200580046094 A CN 200580046094A CN 101124566 A CN101124566 A CN 101124566A
- Authority
- CN
- China
- Prior art keywords
- message
- transmission device
- message transmission
- management
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
要求消息发布/订购系统(10)用处理大量消息,同时减小延迟和性能瓶颈。本发明所提出的端到端的中间件体系结构通过用基于邻居的路由减少中间跳、引入高效的本地至外部和外部至本地的协议转换、实时监控包括延迟在内的系统性能、采用基于话题和基于信道的消息通信并且动态地优化系统互连配置和消息传输协议,而被设计为用于高容量、低延迟的消息传递。
Description
对在先递交的申请的引用
本申请要求2005年1月6日递交的标题为“Event Router System andMethod”、序号为60/641,998的美国临时申请和2005年6月8日递交的标题为“Hybrid Feed Handlers And Latency Measurement”、序号为60/688,983的美国临时申请的优先权并且通过引用而将其合并。
技术领域
本发明涉及数据消息传递,更具体地说,涉及发布/订购系统的中间件体系结构。
背景技术
数据消息传递基础设施所要求的日益提高的性能水平强迫联网基础设施和协议的发展。基本上,数据分发涉及各种数据源和目的地,以及各种类型的互连体系结构和数据源和目的地之间的通信模式。现有数据消息传递体系结构的示例包括轮轴轮辐式(hub-and-spoke),对等式和存储转发式。
利用轮轴轮辐系统配置,所有通信都通过轮轴传输,这在处理量大时通常会导致性能瓶颈。因此,这种消息传递系统产生了等待时间。绕过这种瓶颈的一种方法是布署更多的服务器,并且在这些不同的服务器之间分布网络负载。但是,这种体系结构表现出可扩展性和操作问题。与具有轮轴轮辐配置的系统相比,具有对等配置的系统对应用产生了不必要的压力以处理和过滤数据,并且仅与其最慢的客户或节点一样快。而具有存储转发系统配置的系统为了提供持久性,要在将数据转发到路径中的下一个节点之前存储该数据。存储操作通常通过索引和将消息写到存储盘来实现,这可能产生性能瓶颈。此外,在消息量增大了时,索引和写入任务可能相当慢,因此可能引入额外的等待时间。
现有数据消息传递体系结构共有一些不足。一个共同的不足是在现有体系结构中数据消息传递依赖于驻留在应用层上的软件。这意味着消息传递基础设施要经历OS(操作系统)排队和网络I/O(输入/输出),这可能产生性能瓶颈。另一个共同的不足是现有体系结构静态地而不是动态地使用数据传输协议,即使在某些情形下其他协议可能更合适也是如此。常见协议的一些示例包括可路由多播、广播或单播。实际上,现有体系结构中的应用编程接口(API)未被设计为实时地在传输协议之间切换。
另外,网络配置判决通常是在布署时进行的,并且通常被定义为在特定假设下对一组网络和消息传递条件进行优化。与静态(固定的)配置相关联的限制排除了实时动态网络重配置。换言之,现有体系结构是针对特定传输协议配置的,而该传输协议并不总是适合所有网络数据传输负载条件,因此,现有体系结构总是不能实时地应对改变或增大的负载能力需求。
此外,在数据消息传递去往特定的接收者或者接收者群组时,现有消息传递体系结构使用可路由多播来将数据传输过网络。但是,在针对多播建立的系统中,存在对可以用来分发数据的多播群组的数目的限制,结果,消息传递系统不再将数据发送向未被向其订购的目的地(即,不是订户的客户)。由于数据过滤,这增大了客户的数据处理负载和丢弃率。因此,由于任何原因变为过载并且不能跟上数据流的客户最终丢弃进入数据,并且稍后要求重传。重传对整个系统造成影响,因为所有客户都接收重复的传输,并且所有客户都对进入数据进行重新处理。因此,重传可能导致多播风暴,并且最终可能使整个系统瘫痪。
在系统是针对单播消息传递建立来作为减少丢弃率的一种方法时,该消息传递系统可能因为数据复制而经历带宽饱和。例如,如果多于一个客户订购了感兴趣的给定话题,则消息传递系统必须将该数据递送到每个订户,实际上,系统将该数据的不同拷贝发送到每个订户。尽管这解决了客户滤除非订购数据的问题,但是单播传输是不可扩展的,因此基本上不适合订购特定数据的大量客户群组或者消费模式极度重叠的情形。
现有体系结构的另一个共同不足是它们的协议变换较慢并且数量非常多。这是因为企业应用集成(EIA)领域中的IT(信息技术)权宜(band-aid)策略所致,在该领域中,越来越多的新技术被与遗留系统集成。
因此,在多个领域中都需要提高数据消息传递系统性能。其中性能可能需要提高的示例有速度、资源分配、等待时间等。
发明内容
本发明部分基于前述观察和利用不同的方法可以解决这种不足使得具有更好的结果这一观点。这些观察使得开发出用于大量低等待时间消息传递的端到端消息发布/订购体系结构。因此,具有根据本发明原理的端到端消息发布/订阅中间件体系结构的数据分发系统可以有利地在极低等待时间的情况下路由大量的消息,这是通过减少具有基于邻居的路由选择和网络非居间化(disintermediation)的中介跳,引入高效的本地到外部和外部到本地协议转换、实时监控系统性能(包括等待时间)、布署基于话题和基于通道的消息通信、以及动态并且智能地对系统互连配置和消息传输协议进行优化,等等。另外,这种系统可以利用数据缓存提供有保证的递送服务质量。
结合资源分配,根据本发明的数据分发系统带来了实时动态分配可用资源的优点。就此而言,与传统的静态配置方法相反,本发明设想了一种系统,该系统具有用于资源分配的实时、动态、经学习的方法。其中可以对资源分配进行实时优化的示例包括网络资源(带宽、协议、路径/路由的利用)和客户系统资源(CPU、存储器和盘空间的利用)。
结合监控系统拓扑和性能,根据本发明的数据分发系统有益地区分开消息级和帧级等待时间测量。在某些情形中,这些测量之间的相关提供了有竞争力的商业优点。换言之,等待时间的本质和程度可以指示最佳数据和数据资源,而其又可以用在商业过程中,并且提供有竞争力的优势。
因此,根据所示并且在这里宽广描述的本发明的目的,具有发布/订阅中间件体系结构的一种示例性系统包括:一个或多于一个的消息传递设备,被配置用于接收并路由消息;互连;以及设置和管理系统,通过所述互连而链接并且被配置用于与每个消息传递设备交换管理消息。在这样的系统中,消息传递设备通过动态地选择消息传输协议和消息路由路径而执行消息的路由。
另外,所述发布/订购系统可以被从设置和管理系统而被集中式监控和配置。这提供了用于授权、用户管理、数字权限管理、模式等的易管理并且可缩放的单点配置。
而且,上述系统可以用一个或多个命名空间域来实现,并且,如果实际上存在多于一个的空间域,则系统还包括用于在命名空间域之间连接的域互连介质。该域互连介质例如可以是联网基础设施。
在另一个实施例中,具有发布/订购中间件体系结构的企业系统包括:市场数据传递基础设施,其具有一个或多个用于接收和路由市场数据消息的消息传递设备;市场订单路由基础设施,其具有一个或多个用于接收和路由交易订单消息的消息传递设备;以及中间基础设施,其分别与所述市场数据传递基础设施和所述市场订单路由基础设施通信链接。在该系统中,中间基础设施包括一个或多于一个被配置为用于接收和路由所述市场数据消息和所述交易订单消息的消息传递设备、互连、以及设置和管理系统,所述设置和管理系统通过所述互连而链接,并且被配置为用于与每个消息传递设备交换管理消息,所述消息传递设备包括市场数据传递基础设施和市场订单路由基础设施中的消息传递设备。此外,所述消息传递设备中的每一个还被配置为用于通过动态地选择消息传输协议和消息路由路径而执行其所接收的消息的路由。
而且,在这样的企业系统中,存在用于发布市场数据消息的市场数据源和用于接收市场数据消息并且用于发布交易订单消息的市场数据客户(外部数据目的地)。所述市场数据客户包括一个或多个应用。因此,中间件基础设施包括应用编程接口,该应用编程接口在所述应用程序的每一个和这样的应用编程接口所注册到的中间基础设施中的消息传递设备的一个之间。所述应用编程接口用于将市场数据消息传递到应用,并且从应用传递交易订单消息。该系统还包括用于分别将进入和外出消息在本地消息协议和外部消息协议之间进行翻译的协议变换引擎。
总之,本发明的这些和其它特征、方面和优点将从这里的描述、所附的权利要求书和下文所描述的附图中被更好地理解。
附图说明
包含在本说明书中并且构成本说明书一部分的附图示出了本发明的各个方面,并且与说明一起用于说明其原理。为了方便,在所有附图中将使用相同的标号来指示相同或相似的元件。
图1示出了根据本发明原理的端到端的中间件体系结构。
图1a是示出覆盖网络的图。
图2是示出用根据本发明原理的端到端的中间件体系结构所实现的企业基础设施的图。
图2a是示出在消息传递装置(MA)创建网络骨干网非居间化的情况下的企业基础设施物理部署的图。
图3示出了基于信道的消息传递系统体系结构。
图4示出了一种可能的基于话题的消息格式。
图5示出了基于话题的消息路由选择和路由选择表。
图6是示出根据本发明一个实施例的设置和管理(P&M)系统的框图。
图7示出了具有基于命名空间的拓扑的消息传递(发布/订购)系统。
图8是示出P&M系统和消息传递装置中的一个之间的通信的图。
图9是示出根据本发明原理而配置的MA的框图。
图10示出了用于在MA和CE(缓存引擎)之间通信的接口。
图11示出了用于在MA和应用编程接口(API)之间通信的接口。
图12是示出根据本发明一个实施例而配置的CE的框图。
图13是根据本发明一个实施例而配置的API的框图。
图14示出了根据本发明原理的利用基于会话的容错配置所设计的系统。
具体实施方式
在概述根据本发明的各个方面和原理的各种实施例的细节之前,下面是对一些术语的简单说明,这些术语可以被用在整个说明书中。注意,该说明仅是为了澄清并且向读者给出对可能如何使用这些术语的理解,但是不是将这些术语限于使用它们的上下文中,也不是要因此限制权利要求书的范围。
术语“中间件”在计算机工业中作为一个一般术语使用,针对在两个分离的通常已存在的程序之间协调的任何编程。一般而言,中间件程序提供消息传递服务,使得不同的应用程序可以通信。通常通过利用中间件将不同的应用程序在系统上连结到一起被称作企业应用集成(EAI)。但是,在该上下文中“中间件”可以是一种更广的术语,用在源和目的地之间的消息传递和被布署用于实现这种消息传递的设施的上下文中;因此,中间件体系结构单独或者与下面将描述的组合覆盖了实现高效数据消息传递的联网和计算机硬件与软件组件。此外,术语“消息传递系统”或者“中间件系统”可以被用在发布/订购系统的上下文中,在该系统中,消息传递服务器对在发布者和订购者之间的消息路由选择进行管理。实际上,消息传递中间件中发布/订购的范式是可扩展的,因此是一种有力的模型。
术语“客户”可以用在客户机-服务器应用等的上下文中。在一个实例中,客户是这样一种系统或应用,其利用应用编程接口(API)注册到中间件系统,以订购信息,并且接收该中间件系统递送的数据。中间件体系结构边界内部的API是一种客户;并且外部客户是不使用该API的任何发布/订购系统(或者外部数据目的地),并且为了与之通信,消息要通过协议变换(稍后将描述)。
术语“外部数据源”可以用在数据分发和消息发布/订购系统的上下文中。在一个示例中,外部数据源被认为是位于企业专用网络内或者外部的系统或应用,其采用常用协议之一或者其自己的消息协议发布消息。外部数据源的一个示例是市场数据交换,其发布股市报价,股市报价经由中间件系统被分发到交易员。外部数据源的另一个示例是事务性数据。注意,在后面将更详细描述的本发明的典型实现方式中,中间件体系结构采用其唯一的本地协议,来自外部数据源的数据一旦进入该中间件系统域就被转换成该唯一的本地协议,从而避免了传统系统中典型的多协议变换。
术语“外部数据目的地”也用在数据分发和消息发布/订购系统的上下文中。例如,外部数据目的地是位于企业专用网络内或外部的系统或应用,其订购经由本地/全局网络被路由的信息。外部数据目的地的一个示例可以是对由交易员发布的事务订单进行处理的前述市场数据交换。外部数据目的地的另一个实施例是事务性数据。注意,在前述中间件体系结构中,去往外部数据目的地的消息从本地协议被翻译成与该外部数据目的地相关联的外部协议。
从这里的描述可以确认,可以利用每种都在中间件体系结构中实现的各种配置以各种方式实施本发明。图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经由程间通信总线(套接字、共享存储器等)与应用1121-n通信。
第三种逻辑功能是针对不同类型的有保证的递送服务质量存储消息,包括例如有保证同时连接的和有保证同时不连接的。第四种功能是将这些消息递送到订购者。如图所示,API 106a-b将消息递送到订购应用1121- n。
在该发布/订购中间件体系结构中,系统配置功能以及其他管理和系统性能监控功能由P&M系统管理。另外,MA取决于它们在网络中的角色被布署为核心MA或者边沿MA。边沿MA在大多方面与核心MA类似,除了其包括协议翻译引擎之外,协议翻译引擎将消息从外部协议翻译成本地协议和从本地协议翻译成外部协议。因此,一般来说,发布/订购系统中间件体系结构的边界由其中存在MA 106a-b和API 110a-b的其边沿表征;并且在这些边界内,存在核心MA 108a-c。
在典型的系统中,核心MA 108a-c将在该系统内部发布的消息路由向边沿MA或API(例如,API 110a-b)。尤其是在核心MA中的路由选择图被设计来用于最大量、低等待时间并且高效地路由选择。此外,核心MA之间的路由选择可以实时动态改变。对于穿过多个节点(核心MA)的给定的消息传递路径,路由选择的实时改变是基于一个或多个度量的,这些度量包括网络利用、总地端到端等待时间、通信量、网络延迟、丢失和抖动。
或者,不是从两条或多条不同的路径中动态选择最佳执行路径,而是MA可以基于消息复制执行多路径路由选择,并且从而通过所有路径发送相同的消息。位于不同路径的汇聚点处的所有MA将丢弃复制的消息,仅转发第一个到达的消息。这种路由选择方法具有使低等待时间的消息传递基础设施最优化的优点;尽管这种路由选择的缺点是基础设施需要更多的网络带宽来传送复制的流量。
注意,系统体系结构不被限制到特定的受限的地理区域,并且实际上,系统体系结构被设计为超越区域或国家边界,甚至跨越大洲。在这种情形中,一个网络中的边沿MA可以经由现有的联网基础设施与地理上远离的另一个网络中的边沿MA通信。
边沿MA具有这样的能力:将进入消息的任何外部消息协议转换成中间件系统的本地消息协议;以及从本地消息协议转换成外出消息的外部协议。即,在消息进入发布/订购网络域(入口)时,外部协议被转换成本地(例如,TervelaTM)消息协议;并且在消息离开发布/订购网络域(出口)时,本地协议被转换成外部协议。边沿MA的另一个功能是将已发布的消息递送到订购了的外部数据目的地。
另外,边沿和核心MA 106a-b和108a-c都能够在转发消息之前存储消息。可以实现该功能的一种方法是利用缓存引擎(CE)118a-b。一个或多个CE可以被连接到相同的MA。理论上,不认为API具有这种存储转发能力,尽管实际上API 110a-b可以在将消息递送到应用之前存储消息,并且其可以在将从应用接收到的消息递送到核心MA、边沿MA或者另一个API之前存储它们。
在MA(边沿或核心MA)具有到CE的活动连接时,其将被路由的消息的全部或者子集转发到CE,CE将它们写到存储区域中以实现持久性。在预定时间段中,这些消息然后可在被请求时用于重传。其中实现了这种特征的示例有数据中继、部分发布和各种服务质量级别。部分发布在减少网络和客户负载方面是有效的,因为其要求仅发送更新的信息,而不是所有信息。
为了说明路由选择图可能如何实现路由选择,图1中示出了发布/订购路由选择路径的数个示例。在该图示中,发布/订购网络的中间件体系结构在发布者和订购者之间提供了五条或更多的通信路径。
第一通信路径将外部数据源链接到外部数据目的地。从外部数据源1141-n接收到的已发布消息被翻译成本地(例如,TervelaTM)消息协议,然后被边沿MA 106a路由。本地协议消息可以从边沿MA 106a被路由的一条路线是到外部数据目的地116n。该路径被称作通信路径1a。在这种情形中,本地协议消息被转换成适于该外部数据目的地的外部协议消息。本地协议消息可以从边沿MA 106a被路由的另一条路线是内部通过核心MA 108b。该路径被称作通信路径1b。沿着该路径,核心MA 108b将本地消息路由到边沿MA 106a。但是,在边沿MA 106a将本地协议消息路由到外部数据目的地1161之前,其将它们转换成适于该外部数据目的地1161的外部消息协议。可见,这种通信路径不要求API将消息从发布者路由到订购者。因此,如果发布/订购系统被用于外部源到目的地的通信,则该系统无需包括API。
被称作通信路径2的另一条通信路径利用API 110b将外部数据源114n链接到一个应用。从外部数据源接收到的已发布的消息在边沿MA106a处被翻译成本地消息协议,然后被该边沿MA路由到核心MA 108。从第一核心MA 108a出发,这些消息被路由过另一个核心MA 108c到达API 110b。从该API出发,这些消息被递送到订购应用(例如,1122)。因为该通信路径是双向的,所以在另一个实例中,消息可以沿着反向路径从订购应用1121-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然后将消息递送到订购应用1121-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被构建在发布/订购网络之上,该发布/订购网络用于将来自各个市场数据交换设备3201-n的股票市场报价路由到交易员(未示出的应用)。这种覆盖解决方案依赖于下层网络提供例如MA之间和这种MA和P&M系统之间的互连。到API 3101-n的市场数据递送是基于应用订购的。利用这种基础设施,利用应用(未示出)的交易员将来自API 3101-n的交易单通过发布/订购网络(经由核心MA308 a-b和边沿MA 306b)放置回市场数据交换设备3201-n。
图2a中示出了下层物理布署的一个示例。如图所示,MA被直接彼此连接,并且被直接插入到网络和子网,在网络和子网中消息传递流量的客户和发布者被物理连接。在这种情形中,互连应当是直接连接,即,MA之间的直接连接和它们与P&M系统之间的直接连接。这使得能够实现网络骨干网非居间化,以及消息传递流量与其他企业应用流量物理分离。有效地,MA可以被用来移除对用于消息传递流量的传统路由网络的依赖。
在物理布署的这种示例中,诸如市场数据交换设备之类的外部数据源或者目的地被直接连接到边沿MA,例如,边沿MA 1。诸如市场交易应用之类的消息传递流量消耗或发布应用被直接连接到子网1-12。这些应用具有至少两条路线,用于订购、发布或者与其他应用通信。应用可以或者利用企业骨干网或者利用消息传递骨干网,其中企业骨干网包括多层冗余的路由器和交换机,传送所有的企业应用流量,例如,消息传递流量;消息传递骨干网包括经由集成交换机彼此直接互连的边沿和核心MA。利用替换骨干网具有这样的优点:将消息传递流量与其他企业应用流量隔离,从而更好地控制消息传递流量的性能。在一种实现方式中,位于子网6中的应用逻辑或者物理上连接到核心MA 3,利用TervelaTM API,订购或者发布本地协议的消息流量。在另一种实现方式中,位于子网7中的应用逻辑上或者物理上连接到边沿MA 1,订购或者发布外部协议的消息传递流量,其中MA利用集成的协议变换引擎模块执行协议变换。
逻辑上,发布/订购网络的物理组件被构建在类似于开放系统互连(OSI)参考模型的1到4层的消息传输层之上。OSI模型的1到4层分别是物理层、数据链路层、网络层和传输层。
因此,在本发明的一个实施例中,发布/订购网络通过例如在所有网络交换机和路由器或者网络交换机和路由器的子集中插入一个或多个消息传递线路卡,从而可以被直接布署到下层网络/架构中。在本发明的另一个实施例中,发布/订购网络可以作为网状覆盖网络(其中,所有物理组件都被彼此连接)而被布署。例如,4个MA的完全网状网络是这样的网络,其中,每个MA被连接到其3个对等MA中的每个。在典型实现方式中,发布/订购网络是下述组件的网状网络:一个或多个外部数据源和/或目的地、一个或多个设置和管理(P&M)系统、一个或多个消息传递设备(MA)、一个或多个可选缓存引擎(CE),以及一个或多个可选应用编程接口(API)。
后面将更详细地说明,在企业操作中,可靠性、可用性和一致性通常都是必需的。为此,发布/订购系统可以被设计为容错的,其中其组件中的若干个被布署为容错系统。例如,MA可以被布署为容错MA对,其中第一MA被称作主MA,第二MA被称作副MA或者容错MA(FT MA)。同样,对于存储转发操作,CE(缓存引擎)可以被连接到主或副核心/边沿MA。在主或副MA具有到CE的活动连接时,其将所路由的消息的全部或者子集转发向该CE,该CE将它们写入存储区域以实现持久性。在预定时间段内,这些消息然后可用于根据要求用于重传。
很明显,遍及发布/订购网络的通信是利用用于与下层传输逻辑孤立的消息的本地协议实现的。这就是将这种体系结构称作传输透明基于信道的消息传递体系结构的原因。
图3更详细地示出了基于信道的消息传递体系结构320。一般而言,消息传递源和目的地之间的每条通信路径被认为是一条消息传递信道。每条信道3261-n利用信道源和信道目的地之间的接口3281-n通过物理介质建立。每条这样的信道是针对专门的消息协议建立的,所述消息协议例如是本地(例如,TervelaTM)消息协议或其他。仅边沿MA(对发布/订购网络的入口和出口进行管理的那些MA)利用信道消息协议(外部消息协议)。基于信道消息协议,信道管理层324确定进入和外出消息是否要求协议翻译。在每个边沿MA处,如果进入消息的信道消息协议不同于本地协议,则信道管理层324将在将要处理的消息传递到本地消息层330之前,通过将它们发送过协议翻译引擎(PTE)332,从而执行协议翻译。同样,在每个边沿MA处,如果外出消息的本地消息协议不同于信道消息协议(外部消息协议),则信道管理层324将在将要处理的消息路由到传输信道3261-n之前,将它们发送过协议翻译引擎(PTE)332,从而执行协议翻译。从而,信道对与物理介质的接口3281-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到应用存储器空间的消息,并且可能避免了将消息封装成网络分组的网络开销。
至于本地协议,一种方法利用前述本地TervelaTM消息协议。概念上,TervelaTM消息协议与基于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示出了基于话题的消息路由选择。如图所示,话题可以被定义为基于标记的字符串,例如,T1.T2.T3.T4,其中T1、T2、T3和T4是可变长度的字符串。可见,具有特定话题注释400的进入消息被有选择地路由到通信信道404,并且路由选择确定是基于路由选择表402作出的。话题订购到信道的映射定义路由,并且用来将消息传递遍整个发布/订购网络。所有这些路由或者说订购和信道之间的映射的超集定义路由选择表。路由选择表也被称作订购表。用于利用基于字符串的话题进行路由选择的订购表可以以多种方式被构造,但是优选配置为对其大小以及路由选择查找速度进行优化。在一种实现方式中,订购表可以被定义为动态散列图结构,而在另一种实现方式中,订购表可以被布置在树结构中,如图5中的图所示。
树包括由边连接的节点(例如,T1、…、T10),其中话题订购的每个子字符串对应于树中的一个节点。映射到给定的订购的信道被存储在订购的叶子节点上,每个叶子节点指示该话题订购来自的信道的列表(即,通过其接收到订购请求)。该列表指示哪个信道应接收其话题注释与该订购匹配的消息的拷贝。如图所示,消息路由选择查找将消息话题作为输入,然后利用该话题的每个子字符串对树进行解析,来定位与进入消息话题相关联的不同信道。例如,T1,T2,T3,T4和T5被导向信道1、2和3;T1、T2和T3被导向信道4;T1、T6、T7、T*和T9被导向信道4和5;T1,T6,T7,T8和T9被导向信道1;以及T1、T6、T7、T*和T10被导向信道5。
尽管对路由选择表的结构的选择是要对路由选择表的查找进行优化,但是查找的性能还取决于用于找到与进入消息话题匹配的一个或多个话题订购的搜索算法。因此,路由选择表结构应当能够适应这种算法,反之亦然。减小路由选择表的大小的一种方式是允许路由选择算法有选择地将订购传播遍整个发布/订购网络。例如,如果订购看来是已被传播的另一个订购的子集(例如,整个字符串的一部分),则无需传播该子集订购,因为MA已具有该订购的超集的信息。
基于前述,优选的消息路由选择协议是基于话题的路由选择协议,其中授权在订户和相应的话题之间的映射中指示出。授权是针对每个订户或者订户群组/类别指定的,指示该订购有权消耗何种消息或者该产生者(发布者)可以产生(发布)哪些消息。这些授权是在P&M系统中定义的,被传输到发布/订购网络中的所有MA,然后被MA用来创建和更新它们的路由选择表。
每个MA通过追踪何人被插入(请求订购)到何种消息中来更新其路由选择表。但是,在将路由添加到其路由选择表之前,MA必须针对发布/订购网络的授权对订购进行检查。MA验证可能是邻居MA、P&M系统、CE或者API的订购实体被授权如此执行。如果该订购是有效的,则路由将被创建并且被添加到路由选择表。然后,因为一些授权可能是预先已知的,所以系统可以被布署以预定义授权,并且在引导时这些授权可以被字段加载。例如,诸如配置更新之类的一些特定管理消息可能总是被转发遍网络,并且因此在启动时被自动载入。
除了其在订购过程中的角色之外,P&M系统具有多种其他管理功能。这些额外的功能包括发布/订购系统配置和健康健康和报告。配置涉及对发布/订购系统网络和组件的物理和逻辑配置。监控和报告涉及对所有网络和系统组件的健康进行监控并且自动报告结果,这是按照要求进行的或者被记入日志。
图6是示出根据本发明一个实施例的设置和管理(P&M)系统的框图。如图所示,P&M系统500可以被部署为与发布/订购网络中的一个或多个MA通信的孤立装置。在可替换的实施例中,P&M系统可以被集成到MA中。
P&M系统通过管理消息执行其配置、监控和报告功能,所述管理消息是从装置消息层502中的管理消息层506获得的。与网络中其它组件的通信是通过具有所有上述信道管理的消息传输层504完成的,上述信道管理对于根据本发明原理配置的系统中的组件来说是典型的。然而,不同于直接与物理介质接口交互的MA中的消息传输层,P&M系统经常实现在操作系统528(OS)之上,消息传输层通过该OS与物理介质接口(接口1...N)通信。因此,为了支持各种类型的通道,对于可能没有其他方式对OS可用的每种物理介质,OS可能要求特定的驱动器。对于该介质,OS可能还要求特定的接口卡(例如,直接连接接口卡或者Infiniband接口卡)。
P&M系统还使用网络管理栈508来与基于网络的管理服务通信。这种基于网络的服务的示例包括SNMP(简单网络管理协议)、syslog、HTTP/HTTPS(基于安全套接字层的超文本传送协议),Telnet/SSH(安全壳协议)。
P&M可以具有构建在多个功能块之上的图形用户界面(GUI)510。这些功能块的示例包括配置管理器512、实时监控模块514、历史趋势块516,以及商业逻辑/应用报告块518。配置管理器功能块对发布/订购网络中包含的所有物理组件的配置进行处理。这些组件中的每个的配置520涉及多个方面,包括例如安全性、加密、认证、授权(关于允许哪些用户订购何种话题的权限)、以及拓扑(包括这些不同的组件直接的通信路径)。
实时监控功能块514监听(嗅探)在发布/订购网络中发生的各种事件522。这些事件的示例包括来自API的新订购请求、连接到发布/订购网络的新订户、对联网的发布/订购系统中的不同硬件组件的实时统计、所有MA的路由选择表的大小,以及资源利用水平。
历史趋势块516优选被紧密链接到实时监控系统,因为趋势可以根据被实时监控的事件随事件而被建立。就此而言,历史趋势块从实时监控子系统获取其输入,在实时数据库中存储每个数据点。历史趋势块然后可以查询该实时数据库,并且将其取回的事件作为时间的函数绘制出图表。该块可以进一步被用来追踪发布/订购网络随时间的行为模式。
商业逻辑报告块518通过将随时间变化的事件模式的未经处理数据相关联来提供另一个级别的报告,以便帮助实现商业判决实现过程。在一种实现方式中,商业逻辑报告块将低层消息和网络度量数据(一般是未经处理数据)翻译成商业度量,网络度量数据的示例包括消息和帧速率、网络延迟、抖动和丢失数据。
另外可选地,实时监控和商业逻辑报告块被用来监控服务级别协议(SLA),并且验证随时间变化特定的服务级别是否得到满足。在SLA未得到满足时,其允许理解并且获得问题在于何处和问题是如何被观察到的合法证据,假设所有方都同意这种报告的有效性。此外,建立历史度量的趋势可能有助于帮助理解消息基础设施中的改变,并且其可能使得能够洞悉长期消息传递流量模式。结果,其成为商业判决处理中非常有价值的输入。
另外,P&M系统允许管理员定义一个消息命名空间,该消息命名空间与在整个给定的发布/订购网络中路由的消息中的每一个相关联。因此,发布/订购网络可以被物理地和/或逻辑地分成基于命名空间的子网。这种基于命名空间的拓扑在图7中示出。命名空间对于每个发布/订购子网来说是唯一的。因此,在组合的发布/订购网络中,每个发布/订购子网具有指派给它的唯一的命名空间。在本示例中,发布/订购网络由两个发布/订购子网组成,就具有命名空间“命名空间1”的第一个和具有命名空间“命名空间2”的第二个。实际上,命名空间管理特征(在图6的项目520、512中)提供这样的能力:定义不同的管理域并且允许穿越这些不同的管理域的基于话题的消息通信同时避免话题冲突或复制。
在一个示例中,发布/订购子网“A”发布向发布/订购子网“B”路由的新闻更新,并且子网“C”发布也向子网“B”路由的新闻更新。然而,如果子网“A”和“C”发布关于同一话题的相同的新闻更新,则子网“B”可以因为它们相关联的命名空间而区分来自“A”的新闻和来自“C”的新闻。在许多示例中,这些命名空间域将是不同的组织内部域。在其它示例中,这些域将是不同的组织或者合法实体域。换言之,命名空间特征可以被一个组织用来将对其数据或内容的授权限制到组织内或组织外的某些用户。对于组织内的用户,这是通过向这些用户发送命名空间许可而完成的;而对于该组织外的用户,这是通过向向这些用户提供MA的组织发布命名空间许可证实现的。
如上所述,系统组件的配置和监控两者都是通过管理消息的通信执行的。因此,为了与MA通信,P&M系统使用基于信道的消息传递栈508(以及消息层502、消息传输层504和信道管理526)。图8是示出P&M系统和MA中的一个之间的通信的图。
现在转向消息传递设备(MA),图9是示出根据本发明原理而配置的MA的框图。在本发明的一种实现方式中,MA是孤立的设备。在另一种配置中中,MA是诸如路由器或交换机之类的任何网络物理组件内部的嵌入式组件。在所示MA的实施例中,它被分成三个不同的功能部分。第一部分602包括上述网络管理服务(例如NTP、SNMP、Syslog、Telnet/SSH、HTTP/HTTPS等)。这些服务是在诸如TCP/IP栈604之类的标准网络栈之上建立的,并且它们例如可以使用专用以太网网络接口卡(NIC)606。在一个实施例中,专用NIC的使用提供了一种将管理流量与数据消息传递流量物理上隔离的方式。第二部分被定义为消息传递栈608,消息传递栈608具有在上部的消息层(例如TervelaTM消息层)610和在其下面的传输消息层612。消息传递栈608处理任何进入MA或者从MA出去的消息传递流量。第三部分614包括内部服务。这些服务在MA内使用,并且没有任何直接外部接口。这些内部服务的示例包括诸如本地和远程管理、记录、实时监控和历史趋势服务之类的系统管理服务。可以通过内部通信总线616用来自上述第一和第二部分中的任何部分的呼叫来请求内部服务。
换言之,这些内部服务通过由本地消息传递层610产生的管理消息或者经由网络管理栈602而间接与P&M系统通信。它们追踪系统的常规健康,包括特定的性能量度以及消息传递层和下层的物理介质的统计。这些统计可以在每个信道的基础上被存储,或者它们可以通过计算整个系统的随时间变化的移动加权平均而被聚集。
除了上述内部服务之外,另一种内部服务是时间戳服务(TSS)624,TSS 624可以用于请求精确的时间戳。在一种配置中,TSS基于由MA直接接收的GPS信号。或者,使用MA的内部处理器时钟而不是GPS信号。然而,时钟需要被周期性地更新并且与外部时间源同步。网络时间协议(NTP)或者另一个相当的源经常被用于该目的并且在这里也是合适的。对于具有多个MA的系统来说,通过使用诸如NTP之类的标准网络时间协议,内部TSS可以在多个MA之间被同步。尤其是,一个主MA将被同步于外部时间源,然后,发布/订购网络中的邻近MA将它们自己与主MA同步。MA之间的时间同步可以通过使用特定的管理消息协议来交换时间信息而被实现。或者,时间同步可以用嵌入在每个数据消息中的时间信息来实现,每个数据消息在整个发布/订购网络中路由。
在所示出的MA中,本地(例如TervelaTM)消息传递层610具有许多角色,这些角色中的两个是路由本地协议消息和处理本地管理消息。管理消息可以是API的注册请求、来自API的订购请求、来自P&M系统的配置更新等等。管理消息通常是具有特定管理话题的标准消息。因此,MA将必须在任何消息可以在MA中本地传递之前订购特定管理消息(至管理话题)。初始管理话题订购可以被作为“静态”(混合)路线插入在路由表中,这些静态路线在系统中被预定义,用于管理消息的传递。这些所谓的静态路线将管理订购本地路由到特定的MA,该特定的MA向消息路由引擎指示其应该本地传递匹配管理消息。
无论何时消息在MA中产生并且被该MA路由或者被经由该MA转发,消息路由引擎(MRE)620都搜索具有与消息话题匹配的订购的信道。希望路由表的查找将返回满足这个标准的一个或多个信道的列表。然而,如果返回的信道列表为空,则消息将被丢弃而不是转发。另外,如果返回的信道列表不为空,则消息的副本将被发送到该列表中的每一个信道。优选地,信道管理模块不是发送消息的单独副本到每个信道,而是仅将消息的一个副本保持在存储器中,并且其另外留意多少个信道正在获得和传输该信息。当所有信道完成在它们自己的物理介质上发送消息时,引用计数回到零,然后信道管理可以释放分配给该消息的存储器。这是如何优化系统资源的分配和使用的一个示例,该这种情况中,存储缓冲器在消息传输层中。
注意到在MRE 620将消息传递到用于所有需要消息副本的信道的消息传输层612之前,MRE获得并基于对这些信道上的消费模式和分配给这些信道的系统资源的统计。该监控和统计跟踪任务是通过协议优化服务(POS)执行的。
如果POS确定在源、目的地或者两者处的系统和信道资源未被最优地使用,则其可以调整信道配置,或者甚至创建新的信道,这个新的信道将更好地使用系统和信道资源。例如,通过监控与系统和信道资源相关联的量度,例如延迟和丢弃率,POS可以在这些量度高于或低于预定阈值的情况下改变信道通信协议。丢弃率被定义为从所接收消息的总数中舍弃的消息的百分比。消息在它们被经由多播信道传递到它们的目的地(例如API)并且目的地没有相同的订购模式时被舍弃。如果丢弃率超过百分比阈值,则MA可以决定将信道通信从多播切换至单播,或者在现有的多播信道上重新分布订购。
如上所述,发布/订购网络可以建立在基于IP的网络之上。在这种情况中,MA可以具有多个单播信道,多个单播信道具有不同的客户,这些客户订购相同的话题。所有这些信道可以共享相同的介质带宽。如果消息速率急剧增加,则MA在必须将同一消息的多个副本发送到所有客户的情况下可能不再高效地使用介质的可用带宽。因此,POS可能决定从基于单播的信道协议切换至基于多播的信道协议,该基于多播的信道协议将向位于同一介质上的所有客户仅发送消息的一个副本。为了从一种类型的信道协议切换至另一种类型的信道协议,在MA 600上运行的POS 622模块将通知(一个或多个)API上的POS,需要创建另一个信道以优化信道资源。当信道被创建并且就绪时,MA从旧的信道切换到新的信道。
然后,对于边缘MA的特定情况,当信道将进入的消息传递到信道管理模块时,第一个检查是验证消息协议是否不同于本地消息协议。如果确实不同,则信道管理模块将请求协议翻译引擎618把进入的消息转换为本地(例如TervelaTM)消息协议。当消息被转换时,其被传给(TervelaTM)消息传递层610。另外,在核心MA的情况中,当信道处理进入的消息时,消息被传给假设所有信道在使用本地消息协议的本地(TervelaTM)消息传递层,因此,所有消息已经具有本地消息格式。
如前所述,所有在发布/订购网络中被路由的消息都在特定信道(见消息传输层612内部)上被接收或者发送。MA用这些信道与发布/订购网络中的所有其它物理组件通信。这些通信接口被在图中表示,其中,在图8中,接口被示出用于P&M系统和MA之间的通信,在图10中,接口被示出用于MA和CE(缓存引擎)之间的通信,以及在图11中,接口被示出用于MA和API之间的通信。
有时候这些接口被中断或者目的地不能跟上负荷。在这些情形或其它类似情形中,消息可以被从存储装置读回并且被重新发送。因此,无论何时需要诸如存储和转发功能的消息数据存储,MA都可以有效地与缓存引擎(CE)相关联。CE通过物理介质直接连接到MA(如图1和图10所示),并且其被设计为在高容量和低延迟消息传递环境中提供存储转发体系结构的特征。图12是示出根据本发明一个实施例而配置的CE的框图。
CE 700执行许多功能。对于消息数据持久性,一个功能涉及接收由MA所转发的数据消息、用不同的消息头部字段对它们做索引并且将它们存储在存储区域710中。另一个功能涉及对来自MA的消息取回请求进行响应并且重新发送被丢失或未接收到的消息(并且被客户再次这样请求)。
一般来说,CE建立在与MA相同的逻辑层之上。然而,其本地(例如TervelaTM)消息传递层被大大简化。因为与被路由到发布/订购网络中的另一个物理组件相比,所有消息都在CE处被本地处理并传递到其管理消息层714或其缓存层702,所以不需要路由引擎逻辑。如前所述,管理消息除了用于被转发到缓存层702的取回请求之外,通常用于管理目的。所有的数据消息被转发到缓存层,缓存层使用索引服务712来首先对消息做索引,然后用存储服务708将消息存储在存储区域701中。所有的数据消息都被存储预定义的时间段。索引服务712负责“垃圾收集”活动并且通知存储服务708需要什么时候从存储区域舍弃过期的数据消息。
除了CE之外,MA还与前述的API通信。图13是根据本发明一个实施例而配置的API的框图。
所示出的API 800是API通信引擎802和API存根(stub)804的组合,API存根804遵从并且链接到使用该API的所有应用程序806。通信引擎的一个实现方式是可以是数据守护程序(daemon)。API存根和API通信引擎之间的通信是通过进程间通信总线808完成的,进程间通信总线808是用诸如套接字或者共享存储器之类的机制实现的。API存根804在包括C、C++、Java和.NET的各种编程语言中可用。在一些示例中,API本身可以在各种语言中可用。API在各种操作系统平台上运行,这些操作系统平台的三种示例是WindowsTM、LinuxTM和SolarisTM。或者,API通信引擎和存根可以在编译时与像单片API一样的应用程序合并,以消除对在应用服务器上产生另外进程的需要。
与CE很像,API通信引擎建立在可以在MA中找到的逻辑层上。为了能够与MA通信,API也具有消息传输层810。然而,因为不同于直接与物理介质接口交互的MA,API在大多数的实现方式中都位于操作系统之上(与具有P&M系统的情况一样),所以API和MA中的消息传输层彼此不同。为了支持不同类型的信道,对于在缺省的情况下不被OS以其它方式支持的每种物理介质,OS可以要求特定驱动器用于每种物理介质。OS也可以要求用于插入特定的物理介质卡。例如,诸如直接连接(DC)或Infiniband之类的物理介质要求特定接口卡,并且要求其相关联的OS驱动器允许消息传输层在信道上发送消息。
API中的消息传递层812也与MA中的消息传递层有些类似。然而,主要的差别在于进入的消息在API和MA中分别沿着不同的路径。在API中,数据消息被发送到应用传递路由引擎814(较少的模式绑定),并且管理数据被发送到管理消息层816。应用传递路由引擎除了不是将信道映射到订购,而是将应用程序(806)映射到订购之外,表现得与消息路由引擎818类似。因此,当进入的消息到达时,应用传递路由引擎查找所有的订购应用程序,然后将该消息的副本或者对该消息的引用发送到它们全部。
在一些实现方式中,应用传递路由引擎负责迟模式绑定特征。如前所述,本地(TervelaTM)消息传递协议以原始和压缩格式提供信息,该格式不包含下层的数据的结构和定义。因此,消息传递系统有利地减小其带宽利用,并且又允许增加的消息容量和吞吐量。当API接收到数据消息时,API将原始数据绑定到其模式,允许应用程序透明地访问信息。模式通过提供字段命名、字段类型和其在消息体中的偏移位置之间的映射而定义消息的内容结构。因此,应用程序可以请求特定字段命名而不用知道其在消息中的位置,并且API使用偏移来定位该信息并将其返回到应用程序中。
在很大程度上,外出的消息使用与MA中相同的输出逻辑。在该示例中,API具有协议优化服务(POS)820,该POS 820跟踪关于消费模式以及系统和信道资源利用的统计(与在MA中一样完成)。然而,不同于对什么时候改变信道配置作出其自己决定的MA中的POS,API中的POS充当其所链接到的MA中的主POS的从属。当MA上的POS决定改变信道配置时,其远程地控制API处的从POS。
如上所述,对于系统的可用性和可靠性以及消息数据的一致性和持久性,有利的是将系统配置为容错系统。优选地,系统被设计为具有如图14所示的基于会话的容错配置。另一种可能的配置是完全的失效备援(failover),但是在本示例中,我们选择基于会话的容错。
会话包括两个MA之间或者一个MA和一个API(例如910)之间的通信。会话可以是主动的或被动的。该配置使用主MA和副MA(例如906和908)。如果发生失效,则MA或者API可以决定将会话从主MA906切换到副MA 908。当会话经历连通性和/或诸如CPU、存储器、接口等之类的系统资源的失效时,发生失效。连通性问题是按照下层的信道而定义的。例如,当丢失、延迟和/或抖动随时间变化而不正常地增加时,基于IP的信道将经历连通性问题。对于基于存储器的信道来说,连通性问题可以按照存储器地址冲突等来定义。
总的来说,基于会话的容错设计具有在所有会话中的仅一个或者一个子集在经历问题时不影响所有会话的优点。也就是说,当会话经历一些性能问题时,该会话被从主MA(例如906)移至副容错(FT)MA 908,而不影响与主MA 906相关联的其它会话。因此,例如API1-4被示出仍然具有它们各自的与主MA 902(作为主动MA)的主动会话,而API5具有与FT MA 908的主动会话。
主MA和副MA可以被看作使用某种基于信道的逻辑以将逻辑信道地址映射到物理信道地址的单个MA。例如,对于基于IP的信道,API或者MA可以通过更新MA逻辑地址的ARP缓存条目使其指向副MA的物理MAC地址,而将有问题的会话定向到副MA。
总之,本发明提供了一种用于消息传递的新方法,更具体地说,提供了一种改善消息传递系统效用的端到端的中间件体系结构。虽然参考其某些优选版本,用相当多的细节描述了本发明,但是其它版本也是可以的。因此,所附权限要求书的精神和范围不应局限于包含在这里的优选版本的描述。
权利要求书(按照条约第19条的修改)
1.一种具有中间件体系结构的系统,该系统包括:
一个或多于一个消息传递设备,被配置为用于接收并路由消息;
互连;以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,
其中,每个消息传递设备还被配置为用于通过实时地动态地选择消息传输协议和消息路由路径而执行消息的路由。
2.如权利要求1所述的系统,其中,所述设置和管理系统被配置为用于执行与所述管理消息相关联的功能,所述功能包括系统配置、健康和性能监控和报告。
3.如权利要求1所述的系统,其中,所述设置和管理系统被配置为用于管理订购,所述订购包括客户和外部数据目的地对一个或多个数据消息话题的订购,以及消息传递设备对管理消息话题的订购。
4.如权利要求1所述的系统,其中,每个消息传递设备被配置为边缘消息传递设备或者核心消息传递设备。
5.如权利要求4所述的系统,其中,每个边缘消息传递设备被链接到消息变换引擎,该消息变换引擎用于将进入的消息从外部协议变换为本地协议,并且用于将所路由的消息从所述本地协议变换为所述外部协议。
6.如权利要求1所述的系统,其中,所述消息传输协议被选择为单播、多播或者广播协议之一。
7.如权利要求1所述的系统,还包括一个或多个应用编程接口,所述应用编程接口被配置为用于在一个或多个应用和所述消息传递设备中的相应一个之间接口连接。
8.如权利要求7所述的系统,其中,所述相应消息传递设备和所述一个或多个应用编程接口用于通过在单个帧中包含一条或多条消息而彼此通信。
9.如权利要求7所述的系统,其中,所述应用中的每一个被配置为用于将包括注册和订购请求的请求发送到所述消息传递设备中的相应一个,其中,所述设置和管理系统还被配置为用于处理数字权限管理,其中每个相应的消息传递设备向所述设置和管理系统确认并报告试图向其注册或订购的应用是否被授权这样作。
10.如权利要求7所述的系统,其中,所述应用编程接口中的每一个被逻辑地链接到所述消息传递设备中的相应一个,所述消息传递设备中的所述相应一个被通过基于话题的订购而注册到所述应用编程接口中的所述每一个。
11.如权利要求7所述的系统,其中,所述消息传递设备包括所述应用编程接口所注册到的一个或多个消息传递设备。
12.如权利要求10所述的系统,其中,所述基于话题的订购中的每一个都通过订购请求而被建立,并且其中单个订购请求能够建立对一组相关话题的订购。
13.如权利要求1所述的系统,其中,所述互连是互联网络,所述一个或多个消息传递设备以及设置和管理系统被部署在所述网络上,所述网络配置有任何数目的路由器、交换机和子网。
14.如权利要求1所述的系统,其中,其中所述互连是基于信道的、网络构造无关的物理介质。
1 5.如权利要求1所述的系统,其中,所述一个或多个消息传递设备、所述设置和管理系统以及所述互连包含传输逻辑。
16.如权利要求15所述的系统,被配置为用于传输透明基于信道的消息传递,其中消息被以孤立于所述传输逻辑的本地协议格式传送。
17.如权利要求1所述的系统,还包括一个或多个外部源和外部目的地,其中,所述消息传递设备包括一个或多个边缘消息传递设备和一个或多个核心消息传递设备,每个边缘消息传递设备都与协议翻译引擎相关联,并且在外部协议和本地协议之间翻译消息,每个核心消息传递设备都进行具有所述本地协议的消息的通信,所述外部源和目的地与所述边缘消息传递设备通信,所述边缘消息传递设备又使用基于邻居的消息路由与所述核心消息传递设备通信。
18.如权利要求17所述的系统,其中,每个边缘消息传递设备用于将进入的消息同时路由到本地协议客户和外部协议客户两者。
19.如权利要求1所述的系统,其中,所述消息是用模式和有效负载构建的,所述模式和有效负载在所述消息进入所述系统时被彼此分开并且在所述消息离开所述系统时被合并。
20.如权利要求1所述的系统,其中,所述设置和管理系统执行命名空间管理功能,该命名空间管理功能包括数字权限管理。
21.如权利要求20所述的系统,其中,利用所述命名空间管理,订购了与特定命名空间相关联的话题的客户或者外部目的地被授权发布和订购用这样的话题所标识的消息。
22.如权利要求1所述的系统,其中,每个消息传递设备具有路由选择表,消息在消息传递设备之间的路由是基于邻居的,以使得每个消息传递设备被配置为用于将消息经由其信道之一路由到订购了经由该信道所传输的消息的全部或者子集的邻居,并且,其中每个消息传递设备还被配置为用于优化其订购和信道之间的映射,以减小在仅订购所述消息的子集的邻居处的丢弃率。
23.如权利要求22所述的系统,其中,所述路由选择表具有多个结构中的一个,所述结构中的两个是树结构和动态图结构。
24.如权利要求1所述的系统,其中,所述消息和管理消息具有基于话题的格式,每个消息具有头部和有效负载,所述头部除了包括源和目的地命名空间标识字段之外,还包括话题字段。
25.如权利要求24所述的系统,其中,所述话题字段包括可变长度的串或关键字,所述关键字是一个唯一值,其中对于多个关键字,所述设置和管理系统还配置有用于保持每个这样的关键字和其相应的话题之间的映射的数据库,所述设置和管理系统还被配置为用于关于该映射中的任何变化而更新所述消息传递设备中的每一个。
26.如权利要求1所述的系统,其中,所述消息包括具有话题字段的订购消息,该话题字段具有可变长度的串,所述可变长度字符串具有任意数目的通配符字符,用于如果任何话题子字符串和所述订购消息具有相同数目的话题子字符串则将其与这种话题匹配。
27.如权利要求1所述的系统,其中,所述消息传输协议和所述消息路由路径的动态选择基于系统拓扑、来自所述设置和管理系统的健康和性能报告,并且其涉及动态资源分配、动态信道创建、动态信道选择,或者它们的任何组合。
28.如权利要求1所述的系统,具有超越地区、国家或者大洲界限的边界,在每个地区、国家或者大洲中具有一个或多个子系统,其中所述子系统被通过联网基础设施链接,并且每个子系统包括设置和管理系统、互连和一个或多个消息传递设备。
29.如权利要求1所述的系统,其中,所述设置和管理系统被集成到所述消息传递设备之一中或者被实现为孤立装置。
30.如权利要求1所述的系统,其中,每个消息传递设备包括:
链接到物理接口管理功能块的网络管理栈;
包含系统管理服务功能块和时间戳服务功能块的服务块,所述系统管理服务功能块和时间戳服务功能块两者都通过网络管理内部通信逻辑总线链接到所述网络管理栈;以及
与消息传输层通信的本地消息层,所述消息传输层和本地消息层两者都通过消息传递内部通信逻辑总线链接到所述服务块。
31.如权利要求30所述的系统,其中,所述本地消息层包括管理消息层、消息路由引擎、消息传输和消息接收逻辑,以及主协议优化服务。
32.如权利要求30所述的系统,其中,所述消息传输层包括信道管理,并且其中消息路由路径的所述动态选择包括信道的选择和创建中的一者或多者。
33.如权利要求32所述的系统,其中,每个信道被配置为用于基于网络、基于节点或者基于存储器的传输协议,并且与到网络构造无关的物理介质的物理接口相关联。
34.如权利要求33所述的系统,其中,所述物理介质被配置为以太网、基于存储器的直接连接或者Infiniband。
35.如权利要求1所述的系统,其中,所述设置和管理系统包括链接到配置功能块和监控功能块的消息传输层和本地消息层,所述监控模块又通过进程间通信总线连接到管理块,所述管理块包括配置管理、实施监控、历史趋势和应用业务报告功能块。
36.如权利要求35所述的系统,其中,所述设置和管理系统还包括以下之一或二者:
一侧连接到所述监控功能块,并且另一侧连接到所述操作系统的所述网络栈的网络管理服务;以及
连接到所述管理块的用户接口。
37.如权利要求33所述的系统,其中,所述互连包括传输信道和所述物理介质,所述消息传递设备通过所述传输信道和所述物理介质与所述设置和管理系统通信。
38.如权利要求1所述的系统,还包括一个或多个缓存引擎,每个缓存引擎操作连接到相应的消息传递设备,用于提供服务质量功能,包括消息数据存储和转发功能。
39.如权利要求38所述的系统,其中,每个缓存引擎包括与本地消息层连接的缓存层,所述本地消息层又连接到消息传输层,其中所述缓存层包括存储装置、存储服务和索引服务。
40.如权利要求1所述的系统,其中,所述消息传递设备中的一个或多个通过应用编程接口操作连接到应用,该应用编程接口被注册到这样的消息传递设备,并且在所述应用和所述消息传递设备之间传递数据。
41.如权利要求40所述的系统,其中,每个消息传递设备包括主协议优化服务,并且每个应用编程接口包括响应于其相应的主协议优化服务的从协议优化服务。
42.如权利要求40所述的系统,其中,每个应用编程接口包括通信引擎和一个或多个链接到其的应用存根。
43.如权利要求42所述的系统,其中,所述通信引擎是数据守护程序。
44.如权利要求40所述的系统,其中,每个应用编程接口被部署在客户应用主机中的操作系统之上。
45.如权利要求40所述的系统,其中,每个应用编程接口包括:
用于将消息传递到所述应用的应用传递引擎;以及
用于处理管理消息的管理消息层。
46.如权利要求1所述的系统,其中,所述设置和管理系统和所述消息传递设备中的每一个被配置为用于容错。
47.如权利要求46所述的系统,其中,所述消息传递设备以容错对的方式布置,每一对包括主消息传递设备和副消息传递设备,所述副消息传递设备在会话失效的情况下从所述主消息传递设备接管这样的会话,而不干扰所述主消息传递设备上的其它主动会话。
48.一种具有发布/订购中间件体系结构的系统,该系统包括:
一个或多个命名空间域;以及
如果存在多于一个空间域,则用于在所述命名空间域之间进行连接的域互连介质,
其中,每个命名空间域包括:
一个或多于一个消息传递设备,被配置为用于接收和路由消息,
互连,以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,
其中,每个消息传递设备还被配置为用于通过动态选择消息传输协议和消息路由路径而执行消息路由。
49.一种具有发布/订购中间件体系结构的企业系统,该企业系统包括:
市场数据传递基础设施,具有一个或多个用于接收和路由市场数据消息的消息传递设备;
市场订单路由基础设施,具有一个或多个用于接收和路由交易订单消息的消息传递设备;以及
中间基础设施,分别与所述市场数据传递基础设施和所述市场订单路由基础设施通信链接,其中,所述中间基础设施包括:
一个或多于一个消息传递设备,被配置为用于接收和路由所述市场数据消息和所述交易订单消息,
互连,以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,所述消息传递设备包括所述市场数据传递基础设施和所述市场订单路由基础设施中的所述消息传递设备,
其中,所述消息传递设备中的每一个还被配置为用于通过动态选择消息传输协议和消息路由路径而执行对其接收到的消息的路由。
50.如权利要求49所述的企业系统,还包括:
市场数据源,用于发布所述市场数据消息;以及
市场数据客户,用于接收所述市场数据消息并且用于发布所述交易订单消息,所述市场数据客户包括一个或多个应用,
其中,所述中间基础设施包括在所述应用的每一个和这样的应用编程接口所注册到的所述中间基础设施中的所述消息传递设备的一个之间的应用编程接口,所述应用编程接口用于将所述市场数据消息传递到所述应用并且从所述应用传递交易订单消息。
51.如权利要求49所述的企业系统,还包括协议变换引擎,并且其中,所述市场数据传递基础设施和所述市场订单路由基础设施中的消息传递设备被配置为边缘消息传递设备,所述中间基础设施中的消息传递设备被配置为核心消息传递设备,其中每个边缘消息传递设备采用其相应的协议变换引擎以在外部协议和本地协议之间变换消息,其中每个核心消息传递设备被配置为用于处理所述本地协议的消息。
52.如权利要求49所述的系统,其中,所述消息传递设备被互连以提供网络非居间化。
53.如权利要求49所述的系统,其中,所述消息传递设备中的一个或多个是交换或路由设备中的嵌入组件。
54.一种用于在具有发布/订购中间件体系结构的系统中路由消息的方法,该方法包括:
提供并安排具有一个或多于一个消息传递设备的消息传递网络构造;
在所述消息传递设备的特定一个中实时地动态地选择消息传输协议和消息路由路径;以及
将至少一条消息从所述特定消息传递设备路由到目的地。
55.如权利要求54所述的方法,其中所述目的地包括所述消息传递设备中的另一个、逻辑地链接到所述特定消息传递设备的应用编程接口或者包括这两者。
56.如权利要求54所述的方法,还包括:
将所述消息传递设备中的每一个与设置和管理系统互连;以及
在所述设置和管理系统与所述消息传递设备中的至少一个之间交换至少一条管理消息,所述管理消息与系统配置、健康、性能监控、报告和命名空间管理中的一个或多个相关联。
57.如权利要求54所述的方法,还包括在所述路由之前将所述至少一条消息从外部协议变换为本地协议。
58.如权利要求54所述的方法,还包括将所述至少一条所路由的消息从本地协议变换为外部协议。
59.如权利要求54所述的方法,还包括:
将应用编程接口逻辑地链接到所述消息传递设备中的特定一个;以及
通过基于话题的订购将所述应用编程接口注册到所述特定消息传递设备。
60.如权利要求54所述的方法,还包括将所述至少一条消息存储在缓存引擎中,该缓存引擎操作连接到所述一个或多于一个消息传递设备,用于提供服务质量功能。
61.如权利要求60所述的方法,还包括将所存储的消息转发到逻辑链接到所述一个或多于一个消息传递设备中的一个的应用编程接口、所述一个或多于一个消息传递设备中的至少一个,或者其组合。
Claims (53)
1.一种具有中间件体系结构的系统,该系统包括:
一个或多于一个消息传递设备,被配置为用于接收并路由消息;
互连;以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,
其中,每个消息传递设备还被配置为用于通过实时地动态地选择消息传输协议和消息路由路径而执行消息的路由。
2.如权利要求1所述的系统,其中,所述设置和管理系统被配置为用于执行与所述管理消息相关联的功能,所述功能包括系统配置、健康和性能监控和报告。
3.如权利要求1所述的系统,其中,所述供应装置被配置为用于管理订购,所述订购包括客户和外部数据目的地对一个或多个数据消息话题的订购以及消息传递设备对管理消息话题的订购。
4.如权利要求1所述的系统,其中,所述消息传递设备包括边缘消息传递设备和核心消息传递设备中的一个或多个。
5.如权利要求1所述的系统,其中,每个边缘消息传递设备被链接到消息变换引擎,该消息变换引擎用于将进入的消息从外部协议变换为本地协议并且用于将所路由的消息从所述本地协议变换为所述外部协议。
6.如权利要求1所述的系统,其中,所述消息传输协议被选择为单播、多播或者广播协议之一。
7.如权利要求1所述的系统,还包括一个或多个应用编程接口,所述应用编程接口被配置为用于在一个或多个应用程序和所述消息传递设备中的一个之间进行接口连接。
8.如权利要求7所述的系统,其中,所述消息传递设备和所述一个或多个应用编程接口用于通过在单个帧中包含一条或多条消息而彼此通信。
9.如权利要求1所述的系统,其中,所述应用程序中的每一个被配置为用于将包括注册和订购请求的请求发送到所述消息传递设备中的相应一个,其中,所述设置和管理系统还被配置为用于处理数字权限管理,其中每个相应的消息传递设备向所述设置和管理系统确认并报告试图向其注册或订购的应用是否被授权这样作。
10.如权利要求1所述的系统,其中,所述应用编程接口中的每一个被逻辑地链接到消息传递设备,该消息传递设备被通过基于话题的订购而注册到所述应用编程接口中的所述每一个。
11.如权利要求10所述的系统,其中,所述消息传递设备包括所述应用编程接口所注册到的一个或多个消息传递设备。
12.如权利要求1所述的系统,其中,所述订购是基于话题的并且每一个都被通过订购请求而建立,并且单个订购请求能够建立对一组相关话题的订购。
13.如权利要求1所述的系统,其中,所述互连是互连网络,所述消息传递设备以及设置和管理系统被部署在所述网络上,所述网络配置有任何数目的路由器、交换机和子网。
14.如权利要求1所述的系统,其中,其中所述互连是基于信道的、网络构造无关的物理介质。
15.如权利要求1所述的系统,其中,所述消息传递设备、设置和管理系统以及互连包含传输逻辑。
16.如权利要求15所述的系统,被配置为用于传输透明基于信道的消息传递,其中消息被以孤立于所述传输逻辑的本地协议格式传送。
17.如权利要求1所述的系统,还包括一个或多个外部源和外部目的地,其中,所述消息传递设备包括一个或多个边缘消息传递设备和一个或多个核心消息传递设备,每个边缘消息传递设备都与协议翻译引擎相关联,并且在外部协议和本地协议之间翻译消息,每个核心消息传递设备都进行具有所述本地协议的消息的通信,所述外部源和目的地与所述边缘消息传递设备通信,所述边缘消息传递设备又使用基于邻居的消息路由与所述核心消息传递设备通信。
18.如权利要求17所述的系统,其中,边缘MA用于将进入的消息同时路由到本地协议客户和外部协议客户两者。
19.如权利要求1所述的系统,其中,所述消息是用模式和有效负荷构建的,所述模式和有效负荷在消息进入所述系统时被彼此分开并且在消息离开所述系统时被合并。
20.如权利要求1所述的系统,其中,所述设置和管理系统执行命名空间管理功能,该命名空间管理功能包括数字权限管理。
21.如权利要求1所述的系统,其中,利用所述命名空间管理,订购了与特定命名空间相关联的话题的客户或者外部目的地被授权发布和订购用这样的话题所标识的消息。
22.如权利要求1所述的系统,其中,每个消息传递设备具有路由表,消息在消息传递设备之间的路由是基于邻居的,以使得每个消息传递设备被配置为用于将消息经由其信道之一路由到订购了经由该信道所传输的消息的全部或者一个子集的邻居,并且,每个消息传递设备还被配置为用于优化其订购和信道之间的映射,以减小在仅订购所述消息的一个子集的邻居处的丢弃率。
23.如权利要求1所述的系统,其中,所述路由表具有多个结构中的一个,所述结构中的两个是树结构和动态具有图结构。
24.如权利要求1所述的系统,其中,所述消息和管理消息具有基于话题的格式,每个消息具有头部和有效负载,所述头部除了包括源和目的地命名空间标识字段之外,还包括话题字段。
25.如权利要求24所述的系统,其中,所述话题字段包括可变长度的串或关键字,所述关键字是一个唯一值,其中针对多个关键字,所述设置和管理系统配置有用于保持每个这样的关键字和其相应的话题之间的映射的数据库,所述设置和管理系统还被配置为用于关于该映射中的任何变化而更新所述消息传递设备中的每一个。
26.如权利要求24所述的系统,其中,所述消息包括具有话题字段的订购消息,该话题字段具有可变长度的串,该串具有用于将其与所提供的任何话题子串匹配的任何数目的通配符,以使得这样的话题和所述订购消息具有相同数目的话题子串。
27.如权利要求1所述的系统,其中,传输协议和消息路由路径的所述动态选择基于系统拓扑、来自所述设置和管理系统的健康和性能报告,并且其涉及动态资源分配和动态信道创建和/或选择中的一者或者两者都涉及。
28.如权利要求1所述的系统,具有超越地区、国家或者大洲界限的边界,在每个地区、国家或者大洲中具有子系统,其中所述子系统被通过联网基础设施链接并且每个子系统包括设置和管理系统、互连和一个或多个消息传递设备。
29.如权利要求1所述的系统,其中,所述设置和管理系统被集成到所述消息传递设备之一中或者被实现为孤立装置。
30.如权利要求1所述的系统,其中,每个消息传递设备包括:链接到物理接口管理功能块的网络管理栈;包含系统管理服务功能块和时间戳服务功能块的服务块,所述系统管理服务功能块和时间戳服务功能块两者都通过网络管理内部通信逻辑总线链接到所述网络管理栈;以及与消息传输层通信的本地消息层,所述消息传输层和本地消息层两者都通过消息传递内部通信逻辑总线链接到所述服务块。
31.如权利要求30所述的系统,其中,所述本地消息层包括管理消息层、消息路由引擎、消息传输和消息接收逻辑,以及主协议优化服务。
32.如权利要求30所述的系统,其中,所述消息传输层包括信道管理,并且,消息路由路径的所述动态选择包括信道的选择和/或创建。
33.如权利要求32所述的系统,其中,每个信道被配置为用于基于网络、基于节点或者基于存储器的传输协议,并且与到网络构造无关的物理介质的物理接口相关联。
34.如权利要求33所述的系统,其中,所述物理介质被配置为以太网、基于存储器的直接连接或者Infiniband。
35.如权利要求1所述的系统,其中,所述设置和管理系统包括链接到配置功能块和监控功能块的消息传输层和本地消息层,所述监控模块又通过进程间通信总线连接到管理块,所述管理块包括配置管理、实施监控、历史趋势和应用业务报告功能块。
36.如权利要求35所述的系统,其中,所述设置和管理系统还包括下列中的一者或者两者都包括:一侧连接到所述监控功能块并且另一侧连接到所述操作系统的所述网络栈的网络管理服务;以及连接到所述管理块的用户接口。
37.如权利要求32所述的系统,其中,所述互连包括所述传输信道利物理介质,所述消息传递设备通过所述传输信道和物理介质与所述设置和管理系统通信。
38.如权利要求1所述的系统,还包括一个或多个缓存引擎,每个缓存引擎操作连接到相应的消息传递设备,用于提供服务质量功能,包括消息数据存储和转发功能。
39.如权利要求38所述的系统,其中,每个缓存引擎包括与本地消息层连接的缓存层,所述本地消息层又连接到消息传输层,其中所述缓存层包括存储装置、存储服务和索引服务。
40.如权利要求1所述的系统,其中,所述消息传递设备中的一个或多个通过应用编程接口操作连接到应用,该应用编程接口被注册到这样的消息传递设备,并且在所述应用和所述消息传递设备之间传递数据。
41.如权利要求40所述的系统,其中,每个消息传递设备包括主协议优化服务,并且每个应用编程接口包括响应于其相应的主协议优化服务的从协议优化服务。
42.如权利要求40所述的系统,其中,每个应用编程接口包括通信引擎和一个或多个链接到其的应用程序存根。
43.如权利要求42所述的系统,其中,所述通信引擎是数据守护程序。
44.如权利要求40所述的系统,其中,每个应用编程接口被部署在客户应用主机中的操作系统之上。
45.如权利要求40所述的系统,其中,每个应用编程接口包括:用于将消息传递到所述应用程序的应用传递引擎;以及用于处理管理消息的管理消息层。
46.如权利要求1所述的系统,其中,所述消息传递设备中的每一个以及设置和管理系统被配置为用于容错。
47.如权利要求46所述的系统,其中,所述消息传递设备以容错对的方式布置,每一对包括主消息传递设备和副消息传递设备,所述副消息传递设备在会话失效的情况下从所述主消息传递设备接管这样的会话,而不干扰所述主消息传递设备上的其它主动会话。
48.一种具有发布/订购中间件体系结构的系统,该系统包括:
一个或多个命名空间域;以及
如果存在多于一个的空间域,则包括用于在所述命名空间域之间进行连接的领域互连介质,
其中,每个命名空间域包括:
一个或多于一个的消息传递设备,被配置为用于接收和路由消息,
互连;以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,
其中,每个消息传递设备还被配置为用于通过实时地、动态地选择消息传输协议和消息路由路径而执行消息的路由。
49.一种具有发布/订购中间件体系结构的企业系统,该企业系统包括:
市场数据传递基础设施,具有一个或多个用于接收和路由市场数据消息的消息传递设备;
市场订单路由基础设施,具有一个或多个用于接收和路由交易订单消息的消息传递设备;以及
中间基础设施,分别与所述市场数据传递基础设施和所述市场订单路由基础设施通信链接,其中,所述中间基础设施包括:
一个或多于一个的消息传递设备,被配置为用于接收和路由所述市场数据消息和所述交易订单消息,
互连;以及
设置和管理系统,通过所述互连而链接并且被配置为用于与每个消息传递设备交换管理消息,所述消息传递设备包括所述市场数据传递基础设施和所述市场订单路由基础设施中的所述消息传递设备;
其中,所述消息传递设备中的每一个还被配置为用于通过实时地、动态地选择消息传输协议和消息路由路径而执行消息的路由。
50.如权利要求49所述的企业系统,还包括:
市场数据源,用于发布所述市场数据消息;以及
市场数据客户,用于接收所述市场数据消息并且用于发布所述交易订单消息,所述市场数据客户包括一个或多个应用程序,
其中,所述中间基础设施包括应用编程接口,该应用编程接口在所述应用程序的每一个和这样的应用编程接口所注册到的所述中间基础设施中的所述消息传递设备的一个之间,所述应用编程接口用于将所述市场数据消息传递到所述应用程序并且从所述应用程序传递交易订单消息。
51.如权利要求49所述的企业系统,还包括协议变换引擎,并且其中,所述市场数据传递基础设施和所述市场订单路由基础设施中的消息传递设备被配置为边缘消息传递设备,所述中间基础设施中的消息传递设备被配置为核心消息传递设备,其中每个边缘消息传递设备采用其相应的协议变换引擎以在外部协议和本地协议之间变换消息,其中每个核心消息传递设备被配置为用于处理所述本地协议的消息。
52.如权利要求1所述的系统,其中,所述消息传递设备被互连以提供网络非居间化。
53.如权利要求1所述的系统,其中,所述消息传递设备中的一个或多个是交换或路由设备中的嵌入组件。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US64198805P | 2005-01-06 | 2005-01-06 | |
US60/641,988 | 2005-01-06 | ||
US60/688,983 | 2005-06-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101124566A true CN101124566A (zh) | 2008-02-13 |
Family
ID=39086087
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800460945A Pending CN101124566A (zh) | 2005-01-06 | 2005-12-23 | 端到端的发布/订购中间件体系结构 |
CNA2005800461011A Pending CN101133380A (zh) | 2005-01-06 | 2005-12-23 | 基于硬件的消息传递设备 |
CNA200580046095XA Pending CN101124567A (zh) | 2005-01-06 | 2005-12-23 | 消息传递系统中的缓存引擎 |
CNA2005800460930A Pending CN101326508A (zh) | 2005-01-06 | 2005-12-23 | 智能消息传递应用编程接口 |
CNA2006800018954A Pending CN101151604A (zh) | 2005-01-06 | 2006-01-06 | 消息发布/订购系统中的设置和管理 |
Family Applications After (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800461011A Pending CN101133380A (zh) | 2005-01-06 | 2005-12-23 | 基于硬件的消息传递设备 |
CNA200580046095XA Pending CN101124567A (zh) | 2005-01-06 | 2005-12-23 | 消息传递系统中的缓存引擎 |
CNA2005800460930A Pending CN101326508A (zh) | 2005-01-06 | 2005-12-23 | 智能消息传递应用编程接口 |
CNA2006800018954A Pending CN101151604A (zh) | 2005-01-06 | 2006-01-06 | 消息发布/订购系统中的设置和管理 |
Country Status (1)
Country | Link |
---|---|
CN (5) | CN101124566A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101964782A (zh) * | 2009-07-23 | 2011-02-02 | 佳能株式会社 | 使用sip进行数据通信的信息处理设备及其控制方法 |
CN102754370A (zh) * | 2010-02-10 | 2012-10-24 | 阿尔卡特朗讯公司 | 用于检测透明时钟的同步失效的方法及相关的保护机制 |
CN104205779A (zh) * | 2012-04-06 | 2014-12-10 | 交互数字专利控股公司 | 端对端内容递送服务的优化 |
CN104813616A (zh) * | 2012-08-28 | 2015-07-29 | 塔塔咨询服务有限公司 | 发布数据的可靠性的动态选择 |
CN112241150A (zh) * | 2019-07-17 | 2021-01-19 | Abb瑞士股份有限公司 | 工业过程控制系统中的信道映射的方法 |
CN114827307A (zh) * | 2022-04-14 | 2022-07-29 | 中国建设银行股份有限公司 | 基于多数据系统的数据共享方法、系统及服务器 |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8452835B2 (en) * | 2009-12-23 | 2013-05-28 | Citrix Systems, Inc. | Systems and methods for object rate limiting in multi-core system |
US20120135676A1 (en) * | 2010-11-26 | 2012-05-31 | Industrial Technology Research Institute | System and method for deployment and management of interactive regional broadcast services |
CN103677549B (zh) * | 2012-09-11 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 一种数据处理方法与装置 |
EP2913752A4 (en) * | 2012-10-23 | 2016-07-13 | Nec Corp | RULE DISTRIBUTION SERVER, AND EVENT PROCESSING SYSTEM, METHOD, AND PROGRAM |
WO2014194452A1 (zh) | 2013-06-03 | 2014-12-11 | 华为技术有限公司 | 消息发布与订阅的方法及装置 |
CN104579605B (zh) * | 2013-10-23 | 2018-04-10 | 华为技术有限公司 | 一种数据传输方法及装置 |
US9984158B2 (en) * | 2014-03-18 | 2018-05-29 | Axis Ab | Finding services in a service-oriented architecture (SOA) network |
CN104618466A (zh) * | 2015-01-20 | 2015-05-13 | 上海交通大学 | 基于消息传递的负载均衡和过负荷控制系统及其控制方法 |
CN105991579B (zh) * | 2015-02-12 | 2019-05-28 | 华为技术有限公司 | 信息发送方法、相关网络设备以及系统 |
US9407585B1 (en) * | 2015-08-07 | 2016-08-02 | Machine Zone, Inc. | Scalable, real-time messaging system |
CN107306248B (zh) * | 2016-04-19 | 2023-04-28 | 广东国盾量子科技有限公司 | 一种光量子交换机及其通信方法 |
US9608928B1 (en) * | 2016-07-06 | 2017-03-28 | Machine Zone, Inc. | Multiple-speed message channel of messaging system |
CN106210101B (zh) * | 2016-07-20 | 2019-06-18 | 上海携程商务有限公司 | 消息管理系统及消息管理方法 |
CN107819734A (zh) * | 2016-09-14 | 2018-03-20 | 上海福赛特机器人有限公司 | 一种基于网络套接字的程序间通讯方法及通讯系统 |
EP3598374A4 (en) * | 2017-03-16 | 2020-09-02 | Softbank Corp. | RELAY DEVICE AND PROGRAM |
CN108390917B (zh) * | 2018-01-25 | 2021-02-02 | 珠海金山网络游戏科技有限公司 | 智能发送消息方法和装置 |
EP3609108B1 (en) * | 2018-08-09 | 2021-04-28 | Tata Consultancy Services Limited | Method and system for message based communication and failure recovery for fpga middleware framework |
TWI678087B (zh) * | 2018-11-22 | 2019-11-21 | 財團法人工業技術研究院 | 訊息佇列發佈與訂閱之同步方法及其系統 |
CN110532113B (zh) * | 2019-08-30 | 2023-03-24 | 北京地平线机器人技术研发有限公司 | 信息处理方法、装置、计算机可读存储介质及电子设备 |
CN115086403A (zh) * | 2022-04-27 | 2022-09-20 | 中国科学院上海微系统与信息技术研究所 | 一种针对泛在异构接入的边缘计算网关微服务架构 |
-
2005
- 2005-12-23 CN CNA2005800460945A patent/CN101124566A/zh active Pending
- 2005-12-23 CN CNA2005800461011A patent/CN101133380A/zh active Pending
- 2005-12-23 CN CNA200580046095XA patent/CN101124567A/zh active Pending
- 2005-12-23 CN CNA2005800460930A patent/CN101326508A/zh active Pending
-
2006
- 2006-01-06 CN CNA2006800018954A patent/CN101151604A/zh active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101964782A (zh) * | 2009-07-23 | 2011-02-02 | 佳能株式会社 | 使用sip进行数据通信的信息处理设备及其控制方法 |
CN102754370A (zh) * | 2010-02-10 | 2012-10-24 | 阿尔卡特朗讯公司 | 用于检测透明时钟的同步失效的方法及相关的保护机制 |
US9300422B2 (en) | 2010-02-10 | 2016-03-29 | Alcatel Lucent | Method for detecting a synchronization failure of a transparent clock and related protection schemes |
CN104205779A (zh) * | 2012-04-06 | 2014-12-10 | 交互数字专利控股公司 | 端对端内容递送服务的优化 |
CN104813616A (zh) * | 2012-08-28 | 2015-07-29 | 塔塔咨询服务有限公司 | 发布数据的可靠性的动态选择 |
CN104813616B (zh) * | 2012-08-28 | 2019-02-15 | 塔塔咨询服务有限公司 | 发布数据的可靠性的动态选择的系统及方法 |
CN112241150A (zh) * | 2019-07-17 | 2021-01-19 | Abb瑞士股份有限公司 | 工业过程控制系统中的信道映射的方法 |
CN114827307A (zh) * | 2022-04-14 | 2022-07-29 | 中国建设银行股份有限公司 | 基于多数据系统的数据共享方法、系统及服务器 |
CN114827307B (zh) * | 2022-04-14 | 2024-04-19 | 中国建设银行股份有限公司 | 基于多数据系统的数据共享方法、系统及服务器 |
Also Published As
Publication number | Publication date |
---|---|
CN101151604A (zh) | 2008-03-26 |
CN101133380A (zh) | 2008-02-27 |
CN101124567A (zh) | 2008-02-13 |
CN101326508A (zh) | 2008-12-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101124566A (zh) | 端到端的发布/订购中间件体系结构 | |
US9253243B2 (en) | Systems and methods for network virtualization | |
CA2594267C (en) | End-to-end publish/subscribe middleware architecture | |
US10367852B2 (en) | Multiplexed demand signaled distributed messaging | |
US8370522B2 (en) | Performing multicast communication in computer networks by using overlay routing | |
US20110185082A1 (en) | Systems and methods for network virtualization | |
Fox et al. | A scaleable event infrastructure for peer to peer grids | |
Demmer et al. | The design and implementation of a session layer for delay-tolerant networks | |
Heikkinen et al. | UbiBroker: event-based communication architecture for pervasive display networks | |
Guo et al. | A three-layer network management system | |
Thenmozhi et al. | CONTENT BASED DATA TRANSFER MECHANISM FOR EFFICIENT BULK DATA TRANSFER IN GRID COMPUTING ENVIRONMENT | |
Crowcroft et al. | Large-Scale Event Distribution in Heterogeneous Networks | |
Ko et al. | An Adaptive Fault-Tolerance QoS for Whiteboard Errors Based on RCSM for Ubiquitous Computing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1118111 Country of ref document: HK |
|
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20080213 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1118111 Country of ref document: HK |