[发明专利]智能消息传递应用编程接口

说明书

对先前提交申请的引用

本申请要求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)等待时间。因此，总的端到端等待时间随着跳的数目增长而增加。还有，当从发布者向订购者路由消息时，沿着路径的消息吞吐量受路径中的最慢节点所限制，并且在现有系统中无法实现端到端消息传递流控制来克服该限制。