CN101192942A - 控制发布保持的方法以及发布/订购代理器 - Google Patents

Abstract

提供了在发布/订购系统中对发布的保持进行管理的方法、数据处理系统和计算机程序。发布器向发布/订购代理器发送新发布，其中标记是否应该与以前的保持发布相关联地保持该新发布。发布/订购代理器通过与以前的保持发布一起保持新发布来响应这样的标记。新发布消息的内容或者“有效载荷”可以添加到以前的保持消息中，从而导致包括多个发布消息中的信息的单个保持消息。

Description

控制发布保持的方法以及发布/订购代理器

技术领域

本发明涉及数据处理网络内的通信与数据存储管理，更具体地，本发明提供用于在发布/订购消息环境中控制消息的保持的设备、方法和计算机程序。

背景技术

在消息网络中，消息可以经由提供路由的、以及在多种情况下提供转换和其它服务的一个或多个“消息代理器”，从一个数据处理系统传递到另一个数据处理系统。虽然可以在分布式代理器网络内的各个点实现代理器功能，但是代理器通常位于网络内的通信集线器处。

多个消息代理器支持发布/订购通信范例。这包括发布器发送能够由已经在接收该类型的通信中注册他们的兴趣的一组订购器所接收的通信，发布应用通常不需要知道是哪个订购器对其感兴趣。发布/订购允许订购器接收感兴趣区域(例如，股票价格或者诸如新闻短讯或者特殊报价的事件)中的最新信息，而不需要非得积极主动地并且重复地向每个发布器请求该信息。

一般的发布/订购环境具有多个发布器应用，其经由代理器通过网络向位于远程设备上的潜在的多个订购器应用发送消息。因为通过中间代理器的通信不要求每个发布器和每个订购器之间的专用连接，所以发布器与订购器之间是分离的，这与紧紧连接的传统的客户机-服务器范例相比，大大地简化了网络布局。订购器向代理器注册，以及识别他们想要为其接收发布消息的信息的种类，并且将该信息存储在代理器。在多个发布/订购的实施方式中，订购器指定表示他们想要接收的信息的一个或多个主题名称。当发布器发送他们的消息到代理器时，发布器给消息分配主题名称，并且代理器使用匹配引擎来对所接收的消息的主题与它所存储的注册订购器的订购信息进行比较。这个比较确定该消息应该转发给哪个订购器。主题常常被分层地指定，例如使用字符串格式“root/levelltopicName/level2topicName”，以使能使用迭代遍历主题分层的匹配算法来对所接收消息中指定的主题与订购进行比较。订购能够与主题树内的结点相关联。

虽然订购匹配常常包括检验消息标题内的主题字段，但是匹配可以附加地或者另外地包括检验其它消息标题字段或者检验消息内容，以及基于附加信息而过滤消息。例如，实现Java^TM Message Service(JMS)的消息代理器通常允许基于消息属性(而不是基于是消息内容或“有效载荷”的应用数据)而过滤。消息代理器可以执行附加功能，例如执行数据内容或者格式变换，或者相反，在转发它们给订购器之前处理接收消息。(Java和所有基于Java的商标是Sun Microsystems公司的商标)。

支持发布/订购范例以及允许按消息内容过滤的、市场上可得到的消息代理器产品的示例是IBM公司的WebSphere Message Broker，如2006年7月在IBM公司的文件“IBM WebSphere Message Broker Version 6 Release 0-Introduction”和2006年7月在IBM公司的“IBM WebSphere Message BrokerVersion 6 Release 0-Publish/Subscribe”中所描述的。消息代理器可以与处理通过异类网络提供可靠消息传递的复杂性的下层消息传递产品相关联。IBM公司的WebSphere MQ消息产品是提供这样的消息功能的产品示例，并在包括2005年6月在IBM发布的参考编号GC34-6590-01“WebSphere MQClients”的IBM公司的多个发布文件中得到描述。(IBM和WebSphere是国际商业机器公司的注册商标)。

发布/订购范例是传播信息到多个用户的有效方法，并且对发布器和/或订购器的组能够随时间改变以及对发布器和/或订购器的数量很大的环境尤其有用。一些订购仅仅当订购应用连接到代理器时保持为活动的。这些订购被称为是 “非持久的”。因为“非持久的”订购器很可能错过多个想要的发布，所以许多其它订购是“持久的”并且保持活动的，直到该订购应用明确地取消订购时为止。当订购器重连接时，为了检索，在代理器处拥有匹配未连接的“持久”订购器的订购的发布。当“持久”订购器不再希望接收发布时，订购器能够从代理器取消订购(或者取消订购特定的主题或者主题组)。

虽然该订购和取消订购的能力使持久订购器在他们所接收的发布的控制之下，但是通常在每个订购器的执行-在代理器处开始订购和取消订购操作-中存在一些等待时间。在依赖于低带宽或者订购器与代理器之间的不可靠连接的通信环境中，在订购器能够获得任何发布之前，等待时间会导致显著的延迟。在订购操作之后，在代理器接收匹配新订购器的订购的任何发布之前，也可能存在相当大的延迟。对于一些订购器应用，这样的延迟将是可接受的；但是一些订购器应用尽可能快地需要发布的信息。

在发布已经被转发到当前注册的订购器的组之后，一些发布/订购代理器删除每个发布。用这样的代理器，在每个订购器通过代理器注册各个订购信息之后，他们仅仅接收通过该代理器所收到的发布。然而，一些发布/订购代理器实现可选的“保持”策略，由此，代理器保持由代理器收到的适合于某主题的最新发布的副本(通常每个主题只保持一条消息)。这样的保持发布可以保存在代理器的高速缓冲存储器或其它存储器中。这对于希望快速接收他们感兴趣的主题的最新发布的新订购器来说是有用的-不需要必须等待将要由各个发布器发送的新发布-以及对于不常见的发布的主题的订购器来说也是有用的。

举例来说，考虑正在移动电话或者PDA上运行的货币转换器应用。该应用需要发布外币兑换率来执行货币转换。当最新调用货币转换器应用时，信任不同工作日发布的兑换率，很容易产生错误，因此该应用需要从发布/订购代理器处获得最新的兑换率信息。然而，用户可能不想等待兑换率发布器发出他们的下一次广播发布。因为下一次发布的兑换率信息可能是不可接受的，所以该应用用户可能设法快速做出关于是否购买商品、等待几分钟或者甚至几秒钟的决定。如果代理器保持它已经接收的最新兑换率发布，则一旦他们订购，这就能够被转发到新订购的货币转换器应用，而不需要等待发布器的下一次发布。

在保持发布的典型实施方式中，发布器设置保持标志，而代理器通过保持该发布来响应该保持标志。发布器还可以指定保持发布的终止时间(在其之后发布数据无效或者无用)。当到达终止时间时，代理器删除保持消息。

在其它应用中，新订购器不仅仅接收最后发布是有用的。累积信息或许比仅仅看单个发布更有用。该问题的一个解决办法是除发布/订购消息代理器之外，还使用重放服务器。重放服务器保持大量数据，使得以前发布的消息是可获得的，并且如果需要时能够被检索到，但是相关联的处理和存储开销相对应地大。重放服务器是独立于发布/订购代理器的实体，因此结合订购匹配和内容以及代理器的形式转换是一项重要的任务。

另一可能的解决办法是代理器为每个主题保持预定数量N的发布。然而，依赖于预定数量是不灵活的，仍然存在如何决定适当的N值的问题(平衡存储开销与给新订购器保持发布的收益)。预定值N对于标识哪些发布组具有累积显著性并且应该集中在一起、以及哪些发布应该独立地处理是没有用的。典型的发布/订购代理器忽视发布之间的潜在关系，因此具有累积显著性的发布的分组目前依赖于订购器应用的分析。

发明内容

本发明第一方面提供一种用于在发布/订购系统中对发布的保持进行控制的方法。该方法包括发布器发送新发布，该新发布标记是否应该与以前的保持发布一起保持该新发布。发布/订购代理器通过与以前的保持发布一起保持新发布来响应这样的标记。

在优选的实施例中，新发布的内容或者“有效载荷”能够添加到以前的保持发布上，从而导致含有附加信息的单个保持发布。这对于代理器和新订购器两者都具有潜在的优点。第一，由于标题信息的复制，具有多个发布所建立的内容的单个保持发布所需要的存储量往往小于包含同样数据内容的多个保持发布所需要的存储量。第二，一旦代理器已经执行添加操作，则代理器的存储管理和数据存取操作比代理器总是需要追踪一组相关联的保持发布时的简单。第三，使用传统技术能够给新订购器提供单个保持发布，然而如果添加新内容到保持发布，则订购器将获得一组发布的信息内容。如果该组发布具有累积显著性，则添加信息可以导致单个保持发布，其对于新订购器来说比仅仅保持有关每个主题的最新发布的常规方法更有用。

在基于主题的发布/订购系统中，发布器给出的关于发布保持的标记可以包括发布器指定的指令，其用于代理器添加新发布的内容到适合于各个发布主题的最新保持发布上。在发布器系统内，例如，该新能力可以实现为新的API调用或者适合于由发布器应用使用的可选属性。在该实施例中，发布器API通过向标题信息或者发布消息的内容增加添加指令来响应新API调用或者属性。

同时，代理器优选地实现保持管理器，其响应于“添加”指令或者另一累积保持指令而实现新功能。具体地，发布/订购代理器可以通过向代理器的存储库中的各个保持发布中增加新发布(优选地，仅仅新发布的内容或者“有效载荷”)来响应添加指令。优选地，代理器还响应“不添加”指令(或者没有“添加”指令)来刷新以前的保持发布。然后代理器可以保持发送给具有不添加指令的代理器的新发布。

根据本发明的一个实施例，包含添加指令的新发布被分别添加到用于各个发布主题的当前保持发布上，直到接收到不包含添加指令的新发布时为止。然后，以前保持的发布由新的“不添加”发布所覆盖。然后能够如前所述添加随后的发布。

在另一实施例中，响应于发布器指示一起保持某些消息的愿望，在代理器中累积一组发布消息作为分离的但是相关联的消息。这样具有以与原来发布相同的形式保持消息的优点，而代理器不需要必须创建具有添加内容的修改消息，因此代理器不需要花很大的努力就能管理最初转发(到第一组订购器)的消息和随后转发给新订购器的加上添加内容的消息之间的潜在的差异。

关于是否添加相关消息内容到单个保持发布或者是否保持一组相关的但是分离的消息的决定将取决于特定应用的需要。

本发明的第二方面提供一种用于发布/订购通信网络的发布/订购代理器。该代理器包括：从发布器接收发布的装置；标识发布器指定的、是否应该与以前的保持发布相关联地保持该发布的标记的装置；和响应于发布器指定的标记，与以前的保持发布相关联地保持新发布的装置。

本发明的第三方面提供一种在通信网络内发布消息到发布/订购代理器的消息客户机，该发布/订购消息客户机包括：用于调用向发布/订购代理器发送消息的操作的装置；以及用于在消息内指定应该由代理器与以前保持的消息相关联地保持该消息的装置。在由消息客户机实现的消息API内优选地实现用于调用的装置和用于指定的装置。在一个实施例中，用于指定应该与以前保持的发布相关联地保持该消息的装置包括调用发送操作的API调用的可选属性。消息客户机可以包括：调用该发送操作以及指定保持需要的应用程序，和实现消息传递协议以及路由功能、以通过网络向发布/订购代理器传递消息的消息传递部件。

上述方法的步骤和系统的某些部件可以以计算机程序代码来实现，并且可作为计算机程序产品来获得。这样的程序产品包括记录在记录介质上的程序代码，用于控制在执行程序代码的数据处理设备上的操作的执行，以实现上述方法。用于经由诸如因特网的数据传送媒介下载的计算机程序是可获得的。本发明的各部件也可以以硬件来实现。

附图说明

下面参考附图，以举例的方式更详细地描述本发明的实施例，其中：

图1是表示根据本发明实施例的发布/订购数据处理网络的示意图；

图2是表示根据本发明的一个实施例的方法的步骤的流程图；

图3是表示根据本发明的另一实施例的方法的步骤的流程图；

图4示出在发布器消息客户机系统中执行的操作。

具体实施方式

以下描述本发明的多个方面和实施例，包括用于在分布式数据处理网络内实现本发明的方法、计算机程序和数据处理设备。该实施例仅仅作为说明性示例描述，以确保完全地理解本发明和它的优点。本发明并不局限于所述的说明性实施例。

在来自发布器的标记的控制下，实施例使新发布消息能在发布/订购代理器中与以前保持的发布一起保持。这使具有累积显著性的发布组能被一起保持，作为关于每个主题保持所有的发布或者仅仅保持一个发布的替换，以便新订购器能够从代理器处获得具有累积显著性的最新保持发布组。

因为成本的原因以及为了促进事务的发展，发布/订购匹配引擎以计算机程序代码来实现是常见的。通常，包括所述发布/订购代理器、发布器应用和订购器应用的本发明的若干个部件可以用计算机程序代码来实现。该代码可以用诸如C++、Java^TM、或者SmallTalk的面向对象编程语言或者用诸如C编程语言的过程编程语言来编写。这些程序代码部件可以在通用计算机或者专用数据处理设备上执行。如以下更详细地确认，实现本发明的一些特征和方面的程序代码可以全部在单个数据处理设备上执行，或者可以分布在诸如局域网(LAN)、广域网(WAN)、或者因特网的数据处理网络的多个数据处理系统中。在这样的网络内的不同系统和设备之间的连接可以是有线或者无线的，并且不局限于任一特定的通信协议或者数据格式，以及在这样的网络中的数据处理系统可以是异类系统。

在很多情况下，发布/订购代理器将在大容量、高性能、网络连接的数据处理系统上实现-因为这样的系统能够为大量的发布器和订购器维持高性能发布吞吐量。该发布/订购代理器可以是边缘服务器的部件(即代理器可以是一组网络服务器或者应用服务器部件中的一个)或者网络网关设备。然而，具有少量代码足迹的 “微代理器”解决办法近年来已经得到发展并且已经在例如远程遥测应用中使用，因此现在说，发布器、订购器、和发布/订购代理器全部都可以在各类数据处理系统和设备的任一个上实现是正确的。因此本发明能够在包括无线连接PDA和自动传感器设备的网络中、以及在包括复杂和高性能的计算机系统的网络中实现。

对于本领域技术人员来说很明显，分布式发布/订购通信网络的各个部件能够以软件或者硬件(例如使用电子逻辑电路)实现。例如，发布/订购匹配引擎70能够由硬件比较器实现，该硬件比较器对发布消息内的主题名称与存储订购内的主题名称进行比较。然后在电子电路内处理比较器的指示匹配或者不匹配的输出信号，以便控制消息是否转发给特定的订购器。由一些发布/订购匹配引擎实现的过滤步骤可以由电子过滤器(一种电子电路)实现-尤其在将要施加过滤器的数据值能够表示为信号振幅的地方。

因此，很明显，本发明适用于各类操作环境并且可以使用硬件和软件的各个组合实现。在每种情况下，本发明提供发布/订购通信环境中的订购匹配的增强的基于事件的管理。特定地，本发明的实施例使订购器能定义时间上不可预测的活动和非活动事件，使得订购匹配能够由发布/订购代理器接通和断开，而不需要订购器重复地发布“订购”和“取消订购”的请求。

图1示出已经实现了本发明实施例的简单的发布/订购消息网络。运行在各个数据处理系统30、40上的一组发布器应用10、20能够发布能由在各个数据处理系统80、90、100上运行的多个订购器应用50、60、70所接收的消息。发布器10、20发送消息到正在网络内的另一数据处理系统120上运行的发布/订购消息代理器110。订购器向代理器指定他们希望接收到的消息类型(例如，消息主题名称)。消息代理器对所接收的发布与该组订购器50、60、70的订购信息进行比较-例如将所接收消息的标题内的主题名称和与代理器相关联的订购目录或者表内的主题名称相比较，以标识任何匹配。在发布器和订购器之间他们不需要直接连接并且不需要彼此的地址信息。作为替代，发布器10、20向代理器110发送消息，包括诸如消息主题的消息类型信息；订购器在他们所发送给代理器的订购信息中指定他们的需求；然后代理器传递所接收的消息给对所接收的类型的接收消息感兴趣的订购器。

在图1的示例中，发布器10、20和订购器50、60、70依赖下层消息客户机130、140、170、180、190的消息传递功能，以处理考虑典型的异类分布式网络的复杂性的消息路由和格式化操作，以及使用消息队列来提供异步消息处理能力。在其它实施例中，消息客户机的消息传递功能可以被替代实现为发布器应用的整体特征。

消息代理器110包括订购匹配引擎150和代理器的数据处理系统120的库内的相关联的订购目录或者表160。在一些实施例中，消息代理器与经由网络通信与远程消息客户机130、140、170、180、190互操作的本地消息系统(例如IBM WebSphere MQ消息产品)接口，但是在本实施例中，代理器的数据处理系统120的消息路由和格式化特征被实现为代理器110本身的整体特征。特定地，对于每个消息客户机，代理器110的接收器和发送器部件200、210包括通信栈和协议处理模块，用于编组消息的消息代理器的内部表示为规范的字节格式，以及从规范的字节格式中解编组(demarshal)消息的消息代理器的内部表示，以允许消息流过网络连接。通信栈可以存取用于与外部网络通信的TCP/IP套接字(socket)。消息代理器110听取用于重新建立客户连接的特定的TCP端口。在收到入站连接请求时，消息代理器自举用于该客户的通信栈。该栈响应于维持与客户的连接以及监控套接字连接的当前状态。通信栈自举协议处理模块，而协议处理模块处理消息格式和通信协议的解码和编码，以便完成能够由消息代理器消耗的内部对象表示。例如，协议模块将来自发布器客户机的入站消息解编组为对象形式，以及提交他们给用于匹配注册订购和用于传递给订购器的发布/订购匹配引擎。

匹配引擎对所接收的发布与当前注册的订购组进行比较，以标识0、1或多个匹配。在本实施例中，这包括如在本领域已知的以及如以上所述的主题匹配。如果订购器应用50、60、70当前向代理器注册，并且分别被标识为SUBSCRIBER1、SUBSCRIBER2和SUBSCRIBER3，则在代理器中拥有的简单订购目录如下：

SUB SCRIBER1：TOPIC1，TOPIC3

SUB SCRIBER2：TOPIC2，TOPIC4

SUB SCRIBER3：TOPIC1

通常，每个主题表示为与订购匹配引擎150使用的分层主题树相对应的分层字符串格式。例如，TOPIC1可以是格式“root/levelltopicName/level2topicName”，所以匹配引擎能够遍历分层来检查匹配订购，如之前所述。经受附加到主题匹配的任一消息过滤后，由代理器接收的关于TOPIC1的所有消息将转发到SUBSCRIBER1和SUBSCRIBER3。接收的关于TOPIC2的消息将只转发到SUBSCRIBER2；关于TOPIC3的消息将只转发到SUBSCRIBER1；而关于TOPIC4的消息将只转发到SUBSCRIBER2。

对于图1的特定实施例，让我们假定所有订购器具有非持久的订购，因此对于当前未连接的订购器来说，以每个订购器为基础，在代理器中不保持消息。还让我们假定没有高容量的重放服务器。换句话说，将每个发布转发到当前的注册的订购器组，其已经订购接收关于在发布消息内指定的特定消息主题的发布，但是在本特定实施例中，没有保存代表当前未连接的持久订购器的消息。

然而，虽然没有以每个订购器为基础保存发布，但是本发明提供了对保持发布的支持，如下所述。

由已知发布器应用使用的示例消息API包括响应于发布器指定主题名称、指定或者附加信息数据、并且可选地设置“保持”标志，向代理器发送消息的sendMessage(发送消息)操作。主题名称是一组预定主题名称中的一个，其中该组中的每个主题名称可由消息代理器110解释，并且可以由一个或多个订购器指定为感兴趣的主题。当由发布器指定时，主题名称和保持标志被包括在发送消息的标题内。消息数据也包括在消息内。由发布器设置“保持”标志是向代理器发出的指令：复制该消息到代理器的消息库中，以及当该消息是关于特定主题的最新接收消息时，保持库中的副本。sendMessage API调用的格式可以是：

sendMessage(TOPIC_NAME，DATA，RETAIN_FLAG)

其中TOPIC_NAME可以是标识一个预定主题的分层字符串，DATA是消息的数据内容，而RETAIN_FLAG是表示逻辑“真”(即消息应该被保持在代理器中)或者“假”(消息不应该被保持)的值。例如，消息可以通过发出API调用来发布，诸如：

sendMessage(″greenhouse/temperature″，″34 degrees″，true)

其中主题是“greenhouse/temperature(绿房子/温度)”，消息数据是小数据项“34 degrees(度)”，而保持标志值设置为“true(真)”。

代理器将在主题“greenhouse/temperature”下保持消息数据“34 degrees”的副本，直到接收到关于该主题的具有不同数据值(例如“32 degrees”)的消息时为止。然后新的数据值将覆盖以前的值。保持消息的这种实施方式(如迄今为止在以上最后几段所描述的)在本领域是已知的。

然而，在本发明中，保持标志设置为“真”的消息并不一定覆盖现有的保持消息，而是可以将其添加(或相反与其结合)到以前保持的关于同一主题的消息上。

在本实施例中，保持特征由是消息代理器110的部件的保持管理器220来实现。如果保持标志已经设置为“真”，则保持管理器接收所收到的关于任一主题的每个消息的消息数据的副本。该标志没有设置为“真”的消息不被传递到保持管理器中。当然，保持标志可以通过使用值1和0表示“真”和“假”、或者使用具有能指示发布器是否需要所保持的消息的效果的任一其它表达式来实现。

图2提供根据本发明的第一示例实施例的消息代理器110内的处理序列的示意图。该处理序列仅仅是本发明的一个可能的实施方式，以下参考图3等等描述附加的示例。发布器10向代理器110发送(300)消息，包括能够取真值或者假值的保持标志和其它的添加标志。以下参考图4将更详细地描述在发布器系统中执行的操作。以下还将更详细地描述添加标志。发布消息由接收器侧通信栈和协议处理器200处理(310)，然后检验(320)保持标志来确定发布器是否想要在代理器中保持消息。如果保持标志设置为假，则消息被传递到订购匹配引擎150。订购匹配引擎150比较(330)消息标题内的主题信息与以前由代理器110存储的订购160来标识所有的匹配订购。如果没有主题匹配(或者如果不满足其它过滤条件)，则删除(340)消息。一个或多个订购和发布消息之间的正匹配导致消息使用传统的技术转发(350)到一个或多个标识订购器。然后订购器用由他们自己的应用逻辑指定的任何方法来接收(360)和处理消息。

然而，如果保持标志被确定(320)设置为真，则消息被传递到保持管理器220。保持管理器从消息标题的附加字段中提取值来确定(370)消息是否应该添加到现有的关于指定主题的保持消息中，或者是否应该覆盖任何以前所保持的消息。附加消息标题字段在sendMessage API调用中被指定如下：

sendMessage(TOPIC_NAME，DATA，RETAIN_FLAG，APPEND_FLAG)

其中APPEND_FLAG的逻辑值可以是“真”或者“假”。如果附加值是“真”，则消息数据被添加(380)到关于该主题的以前所保持的消息上，并且被保存(390)到保持发布的库230中。添加消息数据包括：从以前保持的发布中复制消息数据，以及从最新接收的关于同一主题的发布中提取消息数据，然后生成新的消息，其中所提取的新数据被添加到以前保持的数据中。在第一实施例中，库230中拥有的消息标题信息相对于以前保持的发布来说没有改变(即仅仅通过添加操作而扩大了消息内容)。有时，订购器应用不需要处理消息标题中所拥有的信息，并且由于在关于同一主题的连续发布之间，大量标题信息是完全相同的，则当添加消息时，不需要改变库230中的消息标题信息。在第二实施例中，其中发布日期和时间是订购器应用所感兴趣的，以前保持的发布的消息标题或者保持不变，或者由已经添加到保持发布的新接收发布的消息标题所代替，这取决于订购器应用的需要。在再一实施例中，其中通过消息标题字段的许可，添加消息的消息标题可以合并(例如包括一组添加登录记录的第一和最后发布的日期与时间)。

符合上述新格式的第一示例sendMessage API调用如下：

sendMessage(″application/log″，″09-Mar-2006 11:23:42

com.ibm.myapplication.MyClassException：java.lang.NullPointerException″，true，true)

如果关于该主题的多个消息被在代理器中接收，并且他们每个都具有设置为“真”的添加标志，则在代理器中拥有的、用于该指定主题的消息数据能够随着时间的过去在库230中被建立，诸如以下示例：

“09-Mar-2006 11:25:12 com.ibm.myapplication.MyClassException：Java.lang.NullPointerException

09-Mar-2006 11:24:30 com.ibm.myapplication.MyClassException：Java.lang.NullPointerException

09-Mar-2006 11:23:42 com.ibm.myapplication.MyClassException：Java.lang.NullPointerException”

在第一实施例中，当需要时，该组添加消息能够由新的保持发布刷新和覆盖(400)。是否刷新的决定可能是检验定时器到期的结果，作为是否添加的确定(370)的一部分，或者例如，确定(370)可以响应添加标志已经设置为“假”的sendMessage()API调用。对于发布器应用，根据在应用内的执行的发展，能够做出关于何时添加到保持发布、以及何时刷新和覆盖保持发布的决定。例如，当应用重新开始或者当新执行进程开始时，新登录可以开始，以及该重新开始能够是刷新以前的保持消息和开始保持新登录记录的正确时间点。发布器应用执行的其它重复阶段可以是刷新保持消息的适当点。

对保持消息的保持和刷新的这个柔性控制是对仅仅保持最后N个消息的改进，因为后者会留给订购器在诸如用于不同应用执行的登录记录的不相关的保持发布之间进行区分的任务。

在一个实施例中，不保持发布消息的决定由保持管理器220解释，作为从如图2所示的库230中刷新(410)现有的保持发布的指令(因为不这样做会使过时的保持消息留在库中)。在另一实施例中，保持管理器完全不管具有保持标志设置为假的任何消息。

在本发明的一个实施例中，由订购匹配引擎处理以及最终转发到注册订购器的消息是最新的保持发布——即，或者已经覆盖了(400)以前的保持发布的最新接收发布，或者添加(380)接收消息到以前的保持消息的最新结果。转发包含累积数据(即添加消息)的单个消息给当前的订购器组、或者转发最新接收发布(即不添加)是否对他们更有用，则将取决于特定的应用环境。在涉及发布器应用内的当前执行进程的登录记录的情况下，具有附加内容的消息可以是转发最有用的项目，因为接收订购器然后能够通过处理单个消息而不必从多个发布消息中集合信息来处理有关的登录记录组。

然而，在其它实施例中，附加消息仅仅用于“新近的”订购器和间歇订购器-以响应于新订购来提供快速的更新机制。因此，接收新发布时连接到代理器的订购器将接收该新发布，如果该新发布匹配它们的订购的话(即相对于传统的发布/订购解决办法没有任何变化，不具有保持管理器添加或相反的相关联的消息，以及在保持管理器和订购匹配引擎150之间没有虚线箭头)。该实施方式将导致新近的订购器接收不同于当前订购器的格式(在单个消息中添加)的发布信息，但是由于数据内容将是相同的，对于许多订购器应用，不同格式的发出将不会产生问题。

如果对新的订购器应用来说，在库230中由保持管理器220建立的累积数据组比单个保持消息更有用，则本发明的“添加”特征实现了对已知的保持发布解决办法的改进。对于多个不同类型的订购器应用，诸如需要了解接收数据值内的事件频率或者模式而不仅仅是单个数据值的多个监控应用，这将是真的。回到兑换率示例，货币的相对值是增加还是减少与用户完全有关。在订购器应用是监控处理异常的另一示例中，单个异常未必需要订购器应用的任何活动，但是高频异常可以指示需要迫切注意的问题。

如果新订购器能够连接足够久的时间来接收足够多的新发布消息的序列，则即使没有本发明的添加特征，随着时间的过去，新订购器也能得到发布消息数据内的事件频率或者模式。然而，一些订购器将只能够短暂地连接，而且一些订购器应用的用户将希望一旦订购则能快速地接收结果。因此存在多个应用类，本发明为其提供对已知解决办法的改进。

本发明的实施例使“服务质量”的新选项能提供给订购器。例如，如果保持管理器从最新的相关消息组累积数据(诸如用于当前应用执行进程的所有登录)，则订购器可以不需要持久的订购。非持久的订购和由保持管理器保持的消息子集可能满足，而单个最新发布或者最后N个发布消息可能不满足。只有不频繁地和暂时地连接到代理器的订购器可以从由保持管理器220使用的库230中获得足够的信息，因此也许能避免在代理器中存储大量过时消息。

在本发明的另一实施例中，添加消息到以前的保持消息的指令可以通过使用发送消息的新API调用来指定，例如：

appendMessage(TOPIC_NAME，DATA)

由于使用appendMessage()发送的任一消息都想要保持，所以不需要保持标志。想要为特定主题刷新和覆盖保持消息组的消息能够继续使用巳知的API调用格式：

sendMessage(TOPIC_NAME，DATA，RETAIN_FLAG)

或者可以提供另一新的API调用，例如：

ReplaceMessage(TOPIC_NAME，DATA)

上述appendMessage()调用在发布器应用的API中调用操作，来以与前述示例sendMessage(TOPIC_NAME，DATA，RETAIN_FLAG，APPEND_FLAG)相同的方式发送消息。

第一示例appendMessage()调用如下：

appendMessage(″application/log″，″09-Mar-2006 11:23:42

com.ibm.myapplication.MyClassException：Java.lang.NullPointerException″)

不管实现以上哪种接口实施方式，或者任一其它实施方式，通常都希望消息代理器可配置为设置保持添加消息组的最大消息长度。诸如最大消息长度或者超时时段的属性还可以在API调用中指定。对于保持管理器如何响应达到最大大小的添加消息内容，存在各种实施方式的选项。在一个实施例中，保持管理器创建与第一保持消息相关联的第二保持消息，以及继续向第二保持消息添加数据，直到其达到最大大小或者刷新保持消息时为止。在另一实施例中，刷新或者截断过大的保持消息，以便能够添加更多新近发布的信息。

在另一实施例中，通过累积库230中的、相互关联的一组保持消息，可以响应appendMessage()API调用(或者一个上述其它接口选项)。这是对保持具有附加消息内容的单个发布的另一选择。通过标识在与新订购有关的库230中保持的相关联的消息组，保持管理器220响应新近的订购器，并且转发该组发布到新订购器。这种保持发布为独立的然而相关联的消息的方法确保将发送给“新近”订购器的保持发布每个等同于发送给其它订购器的发布。

图2提供表示处理发布消息的方法的流程图，其中在消息向订购器转发之前，这些消息可以添加到其它消息上，而图3示出另一实施方式，其中随匹配引擎150处理消息之后，执行保持管理器的处理。在这个实施例中，接收的发布能够被转发到当前注册订购器，而不必等待保持管理器完成它的处理。

参考图3，接收消息来标识当前感兴趣的订购器的处理仅仅是传统的，但是保持管理器考虑来自发布器的标记，该发布器关心新发布的消息是否应该与作为保持消息所拥有的较早的发布相关联地保持。代理器接收(500)新发布并且传递该发布给订购匹配引擎。订购匹配引擎比较(510)主题信息和消息内容的可能的其它标题信息与一组存储订购，如在本领域是已知的。如果标识至少一个匹配订购，则转发(520)发布到各个订购器。还传递发布到保持管理器220，其在该实施例中执行(530)检验发布是否将被保持。如在上述实施例中，这个检验可以包括检验发布消息标题内的保持标志，以及可能根据由保持管理器施加的一组规则来检验定时器或者主题名称或者其它标准。如果将不保持消息，则现在可以从代理器中删除(540)消息。

如果保持标志及其它标准的检验确定发布消息应该保持在代理器中，则然后确定(550)新发布是否应该与一个或多个以前的保持发布一起保持，或者新发布是否应该是关于该主题的唯一保持发布。如上所述，确定(550)可以包含检验发布消息标题字段内的添加标志，或者响应appendMessage()API调用。如果确定新发布应该被保持，但是不应该与以前的发布结合，则将新发布另存为用于特定消息主题的新保持发布-覆盖(560)关于同一主题的以前的保持发布。如果确定发布消息应该与一个或多个以前的发布相结合，则通过与以前的保持发布相关联地保存(570)新发布来更新库230。在更新库230中，最初的保持发布具有添加给它的指针，其指针标识关于同一主题的下一保持发布的存储位置。当需要时能够增加新发布和指针。这组相关联的发布被保持在库230中，直到“新近”订购器需要时或者直到超时或者刷新指令时为止。

在本发明的另一实施例中，在消息已经与匹配引擎的处理并行地通过接收器侧通信栈和协议处理器200之后，保持管理器可以接收该消息。

在另一实施例中，能够实现保持管理器来保持所接收的关于任意以及每个主题的或者用于预定主题子集的最新消息，而不必依赖于“保持”标志。能够实现保持管理器来保持仅仅关于预定主题子集的和只有“保持”标志已经设置为真的消息。

用于向发布/订购代理器发布消息的典型消息客户机系统包括实现消息API的发布器应用，和用于向发布/订购代理器的数据处理系统传送消息的消息传递部件。如图4所示，消息客户机应用使用上述消息API来调用(600)发送消息操作，包括指定诸如保持需要的参数。消息API插入(610)消息保持标记到消息的标题字段中。消息客户机系统的消息传递部件实现消息传递协议和路由功能，以向代理器传递(620)消息。

很明显，对本领域技术人员来说，在本发明的范围内可以对上述实施例进行各种修改和补充，并且以下陈述的权利要求不应该解释为局限于以上详细描述的特定说明性实施例。

Claims (10)

1.一种用于在发布/订购系统中对发布的保持进行控制的方法，该方法包括：

发布/订购代理器从发布器接收发布；

该发布/订购代理器标识发布器指定的、是否应该与以前的保持发布相关联地保持该发布的标记；以及

该发布/订购代理器通过与该以前的保持发布相关联地保持该新发布来响应该发布器指定的标记。

2.根据权利要求1所述的方法，其中该发布器指定的标记包括添加指令，与该以前的保持发布相关联地保持该新发布的步骤包括：向该以前的保持发布内的数据中添加所接收发布中的数据。

3.根据权利要求1所述的方法，其中与该以前的保持发布相关联地保持该新发布的步骤包括：与描述独立的发布之间的联系的信息一起保持该多个独立的发布。

4.根据前述任一权利要求所述的方法，其中该发布/订购代理器响应没有所述发布器指定的标记，对于仍然需要保持的发布，覆盖以前的保持发布。

5.根据权利要求4所述的方法，其中所接收的发布包括具有消息标题和消息主体的消息，其中该消息标题包括指示该发布器是否需要保持该消息主体的第一字段和包括该发布器指定的、是否应该与以前的保持发布相关联地保持该消息主体的标记的第二字段。

6.根据前述任一权利要求所述的方法，用于基于主题的发布/订购系统，其中订购器指定订购内感兴趣的主题，以及其中该发布/订购代理器的匹配引擎对在接收发布中指定的主题与订购器指定的、该发布/订购代理器所拥有的订购主题进行比较，

其中该代理器响应包括订购器指定主题的新订购的接收，传递当前由该代理器保持的、适合于该订购器指定主题的任一发布到相应的订购器。

7.根据权利要求2所述的方法，包括检验该添加数据的步骤是否将超过最大消息大小的步骤，以及如果该添加数据的步骤将超过该最大消息大小，则拒绝该添加指令。

8.根据权利要求7所述的方法，其中该发布/订购代理器响应所述拒绝，以与以前的保持发布相关联地保持该新发布。

9.一种用于发布/订购通信网络的发布/订购代理器，该代理器包括：

从发布器接收发布的装置；

比较接收发布与存储订购来标识匹配的发布的订购匹配部件，从而标识该匹配发布应该被转发到的订购器；

转发匹配发布到所标识的订购器的装置；以及

保持管理器，其中该保持管理器响应发布器指定的、该发布是否应该与以前的保持发布相关联地保持的标记，来与该以前的保持发布相关联地保持该新发布。

10.一种向通信网络内的发布/订购代理器发布消息的消息客户机，该发布/订购消息客户机包括：

调用向该发布/订购代理器发送消息的操作的装置；以及

在该消息内指定应该由该代理器与以前的保持消息相关联地保持该消息的装置。

Images