Browse Prior Art Database

A mechanism for avoiding unnecessary publications in a publish/subscribe environment

IP.com Disclosure Number: IPCOM000020707D
Original Publication Date: 2003-Dec-10
Included in the Prior Art Database: 2003-Dec-10
Document File: 5 page(s) / 65K

Publishing Venue

IBM

Abstract

In the traditional ("pure") publish/subscribe messaging model, publishers and subscribers are unaware of each other's existence, and each only has a connection to a central broker. Consequently, a publisher will continue to produce (publish) messages, even if there are no subscribers to receive the messages. When this happens, the broker simply discards the messages, as no subscribers have expressed an interest in receiving them. This is a waste of effort on the part of the publisher, and more importantly, consumes bandwidth on the network link between the publisher and the broker, which may be limited or expensive, or both. In these circumstances, it would be useful if the publisher could find out when the topics they are publishing on are being subscribed-to, or not, so they can decide whether or not it is worth publishing subsequent messages. This invention proposes a mechanism to enable this, and can be implemented at an application level (using an unmodified publish/subscribe message broker infrastructure), or can more elegantly and efficiently be incorporated into the function of a broker.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 5

A mechanism for avoiding unnecessary publications in a publish/subscribe environment

In the traditional ("pure") publish/subscribe messaging model, publishers and subscribers are unaware of each other's existence, and each only has a connection to a central broker. Consequently, a publisher will continue to produce (publish) messages, even if there are no subscribers to receive the messages. When this happens, the broker simply discards the messages, as no subscribers have expressed an interest in receiving them.

    This is a waste of effort on the part of the publisher, and more importantly, consumes bandwidth on the network link between the publisher and the broker, which may be limited or expensive, or both.

    In these circumstances, it would be useful if the publisher could find out when the topics they are publishing on are being subscribed-to, or not, so they can decide whether or not it is worth publishing subsequent messages.

    This invention proposes a mechanism to enable this, and can be implemented at an application level (using an unmodified publish/subscribe message broker infrastructure), or can more elegantly and efficiently be incorporated into the function of a broker.

    The invention involves tracking subscription and de-subscription requests from subscribing clients.

    Usage counters on the topics are maintained by either an external application (called the Flow Controller), or the broker itself.

    When the counter for a topic (e.g. "x") goes from 0 to 1 (i.e. the first subscriber joins the topic), or from 1 to 0 (when the last subscriber leaves the topic), a message is published (by either the Flow Controller application or by the broker, depending on where the mechanism is implemented) to a special topic (e.g. "subscriptions/topics/x") saying "start" or "stop", respectively.

    A publisher that wishes to know if it is worthwhile publishing to topic x subscribes to "subscriptions/topics/x", and monitors the "start" and "stop" notifications being published on that topic, and can suspend or resume sending messages accordingly.

    This mechanism brings the advantage that messages are not sent needlessly to the broker, simply to be thrown away, when there is a cost associated with sending that message from the publisher (e.g. over an expensive and/or slow network link).

    We first describe the implementation of this mechanism inside a publish/subscribe broker. This is the more elegant and efficient of the two implementations, but requires modification to the pub/sub broker, and places a pre-requisite on a particular model of implementation for the "matching engine" of the broker. Hence it is less general than the application-based implementation described later.

Broker-based implementation

    A pub/sub broker has a topic hierarchy into which publishers can publish messages, and subscribers can subscribe to explicit topics and sub-trees.

    It is assumed that the "matching engine" of the broker maintains a tree structure to hold subscription...