CN101222449A - 发布/订阅系统和方法 - Google Patents

Abstract

一种操作发布/订阅系统的方法，包括：从发布者接收消息，将该消息传输到一个或者多个订阅者，将该消息识别为保持消息，执行关于该消息的算法，以及根据该算法的输出，或者存储该消息，或者删除一条或者多条消息，或者为一条或者多条消息指定未来删除时间。

Description

发布/订阅系统和方法

技术领域

本发明涉及发布/订阅系统以及用于操作发布/订阅系统的方法，并提供了用于在发布/订阅系统中使用的计算机程序产品。更具体地，本发明提供了用于发布/订阅代理器(broker)的灵活的消息保持(retention)机制。

背景技术

常规的发布/订阅模型使用固定的、预先命名的主题(topic)来支持发布者和订阅者去耦合(例如，主题可以指定为“股票/IBM”)。在这些发布/订阅模型中，发布者和订阅者并不需要互相识别，并且每一个都能够连接到中间代理器或者代理器网络。发布者在他们的发布中包含主题信息，订阅者在订阅发布/订阅代理器时指定他们感兴趣的主题。代理器将发布与订阅进行匹配，然后将发布转发到匹配的订阅者集合。

通常，在已经将发布的副本递送到所有当前匹配的订阅者之后将该发布删除。但是，在某些情况下，即使已经将消息递送到了当前匹配的订阅者集合，保持消息副本的代理器仍然保持发布。保持的发布允许后续订阅者异步地请求所保持的关于主题或者感兴趣的发布。保持的发布通常是发布/订阅代理器所接收关于主题的最后一次发布。

保持的消息可能变得过时或者不正确。例如，涉及事件将要发生的时间的消息不再有用，事实上，对于任何订阅者而言，一旦事件已经发生了，该涉及事件将要发生的时间的消息还会造成混淆。这样，需要一种机制以用于移除这种保持的发布。

用于移除所保持发布的一种已知机制包括：在消息中指定到期时间，该到期时间告诉代理器在特定的时间或者某几分钟之后该发布到期。但是，由于必须在发送消息时预先设置到期时间，这种机制并不灵活。另一种已知机制包括：一旦知道消息已经过时，便手动地删除该消息。但是，固有延迟以及需要付出的劳动都使手动删除成为没有吸引力的选择。

如上所指出，保持的发布可以是关于某主题发布的最后一条消息，并且由代理器来保持该发布，使得该主题的后续订阅者能在他们连接时得到该消息。对于提供信息而言，这种机制非常方便。但是，一旦保持了消息，该消息便会不确定地停留，这实际上变得与内存泄露类似。设置到期时间的已知方案不够灵活，并且某些发布可能保持比期望时间更长的时间，而其他的发布可能很快删除。

发明内容

根据本发明第一方面，提供了操作发布/订阅系统的方法，包括：从发布者接收消息；将所接收的消息传输到一个或者多个订阅者；将所接收的消息识别为潜在保持消息；以及响应于所述识别步骤，评估至少一个与所接收的消息相关的保持标准，并根据该评估步骤的结果来确定用于所接收的消息的保持特征。

确定步骤优选地包括从以下操作中选择一个：存储该消息；删除一条或者多条消息；或者为一条或者多条消息指定未来删除时间。另外，可以为消息指定元数据，并且定义新的保持标准，以在将来保持评估中使用。

根据本发明第二方面，提供了发布/订阅系统，包括消息代理器，其被配置为：从发布者接收消息；将所接收的消息传送到一个或者多个订阅者；以及将所接收的消息识别为潜在保持消息；以及保持组件，其被配置为响应于所述识别步骤，评估至少一个与所接收的消息相关的保持标准，并根据该评估步骤的结果来确定用于所接收的消息的保持特征。

根据本发明第三方面，提供了一种包括记录在计算机可读介质上的程序代码的计算机程序产品以用于操作发布/订阅系统，该程序代码包括用于进行以下步骤的指令：从发布者接收消息；将所接收的消息传送到一个或者多个订阅者；将所接收的消息识别为潜在保持消息；以及响应于所述识别步骤，评估至少一个与所接收的消息相关的保持标准，并根据该评估步骤的结果来确定用于所接收的消息的保持特征。

通过本发明，可能提供一种操作灵活的保持消息系统的发布/订阅系统，当收到消息时，该保持消息系统确定是否存储该消息。本发明提供了比已知的保持消息机制更灵活的模型，这样，可以根据代理器接收消息之后对保持标准的评估(诸如，对订阅者的分析)，来保持或者删除该消息。

可以用常规方式来发布消息，该消息设置有“保持”标志(如本领域所公知的)。但是，尽管已知解决方案将“保持”标志当作总是要遵循的指示看待，但是根据本实施方式的发布/订阅代理器将此标志解释为指示保持组件应该用于管理该消息的保持。存在于代理器的匹配引擎中的保持组件监视具有前述标志设置的进入消息。被标志的消息由保持组件处理。

统计组件收集代理器中的活动的信息，例如每个主题的消息吞吐率、订阅者数量、每个主题自最后一次订阅以来的时间长度等。消息的到达周期性地触发保持组件来检查每个消息，以便根据存放在代理器中的策略来确定该消息是否应到期。

策略根据统计组件收集的统计数据来描述到期标准。一种简单策略可以是：如果在特定时间段内已经没有针对保持的发布的订阅者，或者如果关于该主题的消息频率是这样的(例如，每两秒一条新消息)，以致于由于该消息的频繁更新，不值得保持该消息，则令该保持的发布到期。

除了考虑为发布/订阅网络中的系统所收集统计信息外，更复杂的策略可能内部检查消息中的数据以确定到期。例如，在班机到达系统中，策略可以是：在两小时内清除出现字样“到达(LANDED)”的相关班机的消息。策略可以在代理器上管理性地设置，或者利用发布中的消息(例如，关于某个系统主题)内的策略进行动态设置。

新订阅者订阅消息发布所针对的主题，并且如果如上所述该消息并未到期的话，则按照保持的发布来递送该消息给新订阅者。

系统通过保持组件，提供了更灵活的机制来管理发布的保持。这可能涉及应用程序进行权衡的元素。不过，在对主题的订阅可能是突发的或者适合于在某一离散时间段内的情况下(例如，关于特定航班到达的信息)，系统可以工作得很好。在这种情况下，一旦航班已经到达，就不太可能存在许多进一步的订阅者订阅特定于此航班的主题，因为该信息现在已经过时。订阅者应用程序从保持发布中受益，并且比使用固定到期时间更为灵活。在此示例中，如果用户(基于某些原因)保持订阅该主题，则仍可以保持该消息(即，可以将策略创建为“如果在两个小时后没有订阅者，则该消息到期”)。

从代理器负载管理的角度来看，本发明的系统提供了相对于之前的保持机制而言资源更有效的可选择方式，以及为应用程序开发者提供了更灵活的模型。

附图说明

参照附图，下面仅通过示例的方式更详细地说明本发明的实施方式，在附图中：

图1是发布/订阅系统的示意图；

图2是图1系统的进一步示意图；以及

图3是操作该发布/订阅系统的方法流程图。

具体实施方式

图1示出了包括消息代理器12的发布/订阅系统10。消息代理器12的角色是发布者14和订阅者16之间的媒介。系统10还包括主题数据库18，该主题数据库18维护主题的细节和已经订阅每个特定主题的订阅者的细节。在图1的示例中，主题“主题1(TOPIC1)”具有订阅该主题的订阅者S1和S2。系统10定义了简单命令接口，订阅者16可以通过该接口对主题数据库18中维护的每个主题进行订阅和取消订阅，并且系统10支持创建和删除主题本身。

当消息代理器12从发布者14接收到消息20时，消息代理器12将消息20传输到由主题数据库18指定为订阅该主题的订阅者的所有订阅者16中的每一个。作为此处理的一部分，消息20的主题必须由消息代理器12进行确定。可以在消息代理器12接收的发布消息20中明确声明其主题，或者可以在消息20中暗示主题，消息代理器12必须通过消息20的内容确定主题。在简单的形式中，消息20可以采用“主题1：数据(TOPIC1:DATA)”的形式，消息代理器12将消息20的“数据(DATA)”部分传送给每个如主题数据库18所定义的针对主题“主题1(TOPIC1)”的订阅者。

在图1的示例中，消息20涉及主题“主题1(TOPIC1)”，然后被传送到两个订阅者S1和S2，因为这些订阅者是在数据库18中定义为已经订阅了该主题的订阅者。无论消息代理器12何时接收到消息20，也不管哪个发布者14已经发送了消息20，只要消息20涉及“主题1(TOPIC1)”，代理器12就会将该消息发送到如在主题数据库18中定义的关于“主题1(TOPIC1)”的当前订阅者集合。

发布/订阅系统10还包括保持消息数据库22。通常，一旦消息代理器12已经从发布者14接收到消息20并将消息20传送到相关订阅者16，消息20随后就会被丢弃，这是因为对接收的消息20进行存储会非常迅速地造成巨大的存储需求(其原因是，常规系统10可以维护非常多的不同的主题，并且每一秒钟都会有关于每个主题的消息到达)。但是，所接收的消息20的子集可以存储在保持消息数据库22中。

数据库22可能有几种不同的配置。例如，可以保持关于每个主题的最后一次接收的消息。当主题的新订阅者第一次订阅新主题时，这样会使他们能够接收到关于该特定主题的最后一次发布消息。通过在来自发布者14的消息20中设置标志来指定哪些消息应该存储也是有可能的。这样可以允许发布者指定特定消息是重要的并且应该被保持，此外也是出于将保持的消息提供给新订阅者16的目的。保持消息数据库22可以被配置为使得为每个主题存储的消息都不多于一个，这样对于每个主题，每个将要存储的新消息都会引起关于该主题的任何已保持的消息被删除。

图2更详细地示出了图1的发布/订阅系统10。除了被配置以从发布者接收消息并将该消息传送给一个或者多个订阅者的消息代理器12之外，系统10包括保持组件24和统计组件26。这两个组件24和26与消息代理器12进行通信，并且保持组件连接至保持消息数据库22。

一旦消息已经被识别为潜在保持消息(例如，识别消息中的“保持”标志，或者识别消息中这样的主题：对于该主题，代理器具有“保持最新发布”的策略)，则保持组件24被配置以执行与该消息有关的算法，以及根据该算法的输出，或者存储该消息，或者删除一条或多条消息，或者为一条或多条消息指定未来删除时间。这点在以下参照图3中，进行更详细地解释。实际上，保持组件24在数据库22中管理保持的消息的存储。每当消息别识别为看起来像是要求保持的消息时，保持组件24就会进行操作。在接收到消息后，保持组件24就会进行操作(即，在此实施方式中，保持组件并未作为后台任务运行)。

统计组件26被配置以收集关于发布/订阅系统10操作的数据，该数据包括对保持组件24周期性执行的算法的输入。再次参照图3在下面对其进行更具体的描述。统计组件26收集涉及诸如订阅者信息(例如，关于主题最后一次有效订阅的时间)和/或所接收消息的数量(在每个主题的基础上)的数据。组件26可以存储所收集的数据，如果且当该保持组件24需要该数据的时候，将该数据提供给保持组件24。

当保持组件24和统计组件26正在操作时，在不需要进行任何调整的情况下，消息代理器12也可以起作用。在两个组件24和26不进行干预的情况下，消息代理器12可以正常处理进来的消息，接收并传输该消息。保持组件24管理保持消息的存储，统计组件26监控并记录涉及系统10的性能的统计数据。

图3概括了操作发布/订阅系统10的方法。第一步骤(S1)是从发布者14接收消息20的常规步骤，在该步骤之后，由消息代理器12在每个主题的基础上执行步骤(S2)，即，将消息20传送到一个或者多个订阅者16。

下一步骤(S3)是将消息20识别为看起来需要保持的消息的步骤。消息代理器12会将消息20识别为需要为该消息涉及的主题进行存储的消息。消息20本身可以携带请求保持的标志，或者消息代理器12可以进行它自己的决策处理，诸如针对某些主题的“存储最后一次消息”策略。一旦消息20识别为保持消息，则调用保持组件24以进行处理发布/订阅系统10的保持策略。保持组件24可以使用多种策略，并且这些策略包含在组件24运行的算法中。

在步骤S4，保持组件24执行与刚刚接收的消息20相关的算法，并且根据该算法的输出，或者存储消息(步骤S6)，或者删除一条或者多条消息(步骤S7)，或者为一条或者多条消息指定未来删除时间(步骤S8)。响应于接收到保持的消息，保持组件24执行算法，并且算法的输出确定将要采取的动作，这是存储管理的一种形式。保持组件24可以访问一个或者多个定义了如何处理保持消息的策略。这些可以是管理员所管理的用户。一种非常简单的策略是：如果所接收的消息大于某个尺寸，则删除该接收的消息(而不是像通常发生在保持消息上的存储该消息)。

统计组件26收集(步骤S5)关于系统10操作的数据，并且在根据各种策略执行算法时，保持组件24可以使用这些数据。例如，统计组件26可以被配置以监控关于特定主题(或者事实上关于所有主题)的新订阅者16。此信息可以提供给保持组件24，该保持组件24可以操作规定了在最近两小时内没有任何订阅消息的主题的新订阅者16，则删除保持的消息的策略。在这种情况下，该算法将输出：删除特定消息20而不是保持。

诸如每个主题的消息吞吐率以及订阅者数量的其他因素可以由统计组件26进行监控，并且保持组件24在执行决定存储消息还是删除消息的算法时，可以考虑这些因素。例如，如果主题具有相对高的消息吞吐率，诸如每两秒一条消息，则保持组件24可以决定不为该主题存储任何保持消息，因为这些消息很快就会被替代。

保持组件24还可以决定保持消息，但是同时为该消息指定未来删除时间。例如，主题可以是这样的：接收消息，该消息由于重要而应该保持，但是在一段时间周期后将不再有用。在这种情况下，保持的消息将存储在数据库22中，该消息上具有附加的时间t。当时间t过去后，保持组件24将管理该消息的删除。

算法的输出可以是：删除除了实际接收的消息以外的消息，或者为其指定未来删除时间。可以是这样的，只有特定数量的消息或者特定总大小的消息可以存储，并且可以建立保持消息的层次使得当接收到新的保持消息时，删除一条或者多条之前存储的消息。这样可以智能地管理系统10可用的存储器资源。

对算法的输入可以包括所接收消息的至少一部分。例如，保持组件24可以在发布消息中查找特定单词或者短语，该单词或者短语指示主题状态的改变。例如，如果主题涉及航班，则关于该主题的消息中的单词“到达(LANDED)”的出现可以用来设置指示一旦两个小时过去，就不再为该主题存储消息的标志，这是基于在此时间过去之后，不太可能还会有人对这个主题感兴趣。

保持组件24可以实现为发布/订阅匹配引擎的补充(addendum)(例如，以Microbroker中的Java实现)。另外，统计收集组件26可以相当容易地添加到内部组件中(发布/订阅引擎、通信组件)以便衍生出关于主题、连接等的元数据。

统计组件26的简单实施方式可以是包含关于数据的公知关键字的哈希表(hash-table)，同时可以更新针对几乎每个关键字的统计值，并且保持组件24能够在应用策略时拍摄快照(take a snapshot)。策略描述容器(descriptor)的简单示例可以利用由保持组件24所使用的XML文档来示出：

<retention-policy topic＝″arriVals/#″>

     <action type＝″purge″>

        <constraint>

             <time-inactive>2</time-inactive>

             <payload-match>LANDED</payload-match>

          </constraint>

       </action>

</retention-policy>

更多复杂算法也是可能的，诸如主题和/或资源的组合使用Bayesian网络来影响消息的保持的算法。这可以通过使用XML信念网络(XBN)标准来与上述类似地实现——将发布/订阅保持消息作为从其他如使用率、普及度、重要程度等一类的节点或者源进入的节点(node)和线(line)，其中对于每条线具有不同的权重。这可以编程入保持组件24中。

算法可能实现的策略的范围可能非常广。可以使用的策略类型为：如果在长时间内没有针对此主题的发布者；暂时没有人已订阅；在发布的消息体中引用的显著事件已发生等。

系统19可以这样配置，使得如果某人订阅了主题并且仍然连接，则保持组件24可以推迟保持缓冲区的到期时间，因为如果网络暂时将订阅者踢出，当他们重新连接时，他们会感激对保持消息的刷新。

Claims (20)

1.一种操作发布/订阅系统的方法，包括：

从发布者接收消息；

将所接收的消息传输到一个或者多个订阅者；

将所接收的消息识别为潜在保持消息；以及

响应于所述识别步骤，评估至少一个与所接收的消息相关的保持标准，并根据所述评估步骤的结果来确定用于所述接收的消息的保持特征。

2.根据权利要求1的方法，其中所述确定步骤包括从操作集合中选择操作，该集合包括：

存储所述接收的消息；

删除一条或者多条消息；以及

为一条或者多条消息指定未来删除时间。

3.根据权利要求1或2的方法，其中所述删除一条或者多条消息的步骤包括删除所接收的消息。

4.根据上述任一权利要求的方法，其中所述为一条或者多条消息指定未来删除时间的步骤包括为所述接收的消息指定未来删除时间。

5.根据上述任一权利要求的方法，其中对所述评估步骤的输入包括所述消息的至少一部分。

6.根据上述任一权利要求的方法，其中所述将所述接收的消息识别为潜在保持消息的步骤包括识别所述消息中的“保持”标志。

7.根据权利要求1到5中任一权利要求的方法，其中所述将所述接收的消息识别为潜在保持消息的步骤包括识别所述接收消息中的主题标识符，其中所述主题标识符与所述发布/订阅系统执行保持策略所针对的主题相匹配。

8.根据上述任一权利要求的方法，进一步包括收集关于所述发布/订阅系统操作的数据，所述数据包括对所述评估步骤的输入。

9.根据权利要求8的方法，其中所述收集的数据包括订阅者信息。

10.根据权利要求8或9的方法，其中所述收集的数据包括所述接收的消息的数量。

11.一种发布/订阅系统，包括消息代理器(broker)，其被配置为：从发布者接收消息；将所述接收的消息传输到一个或者多个订阅者；以及将所述接收的消息识别为潜在保持消息；以及保持组件，其被配置以响应于所述识别步骤来评估关于所接收的消息的至少一个保持标准，并且根据所述评估步骤的结果来确定用于所述接收的消息的保持特征。

12.根据权利要求11的发布/订阅系统，其中所述保持组件被配置以从操作集合中选择操作，所述集合包括：

存储所述接收的消息；

删除一条或者多条消息；以及

为一条或者多条消息指定未来删除时间。

13.根据权利要求12的系统，其中该保持组件被配置以在删除一条或者多条消息时删除所述接收的消息。

14.根据权利要求12的系统，其中该保持组件被配置以在为一条或者多条消息指定未来删除时间时，为所述接收的消息指定未来删除时间。

15.根据权利要求11到14中任一权利要求的系统，其中所述消息代理器被配置以识别所述消息中的“保持”标志，以将所述接收的消息识别为潜在保持消息。

16.根据权利要求11到14中任一权利要求的系统，其中所述消息代理器被配置以通过在所述接收的消息中识别主题标识符，以将所述接收的消息识别为潜在保持消息，其中所述主题标识符与所述发布/订阅系统执行保持策略所针对的主题相匹配。

17.根据权利要求11到16中任一权利要求的系统，其中对所述保持组件执行的所述评估的输入包括所述消息的至少一部分。

18.根据权利要求11到17中任一权利要求的系统，进一步包括数据收集组件，其被配置以收集关于所述发布/订阅系统操作的数据，所述数据包括对所述保持组件执行的所述评估的输入。

19.根据权利要求17的系统，其中所述收集的数据包括订阅者信息。

20.根据权利要求18或19的系统，其中所述收集的数据包括所接收的消息的数量。

Images