Browse Prior Art Database

Message Broker Use of Identifiers to Distinguish Neighbours

IP.com Disclosure Number: IPCOM000013391D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Related People

Simon Holdsworth: AUTHOR [+2]

Abstract

Within a multi-broker network, it is necessary for a broker to know the source of messages it receives in order to avoid loops by sending a message back to its source. This could be solved by having a broker insert its identity into each message which it sends to a neighbouring broker, however this has the disadvantage that it may result in the entire message being rewritten (inefficient for large messages) and requires the broker to have special case code when delivering messages to other brokers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Message Broker Use of Identifiers to Distinguish Neighbours

Within a multi-broker network, it is necessary for a broker to know the source
of messages it receives in order to avoid loops by sending a message back to
its source. This could be solved by having a broker insert its identity into
each message which it sends to a neighbouring broker, however this has the
disadvantage that it may result in the entire message being rewritten
(inefficient for large messages) and requires the broker to have special case
code when delivering messages to other brokers.

     Within a publish/subscribe system, it is often
possible for a subscriber to specify an identifier which
the broker must place in any messages sent to the client,
in order for the client to distinguish messages sent to it
from messages sent on the same transport link, but
intended for other subscribers. The normal mode is thus
for the subscriber to register with its own identity,
which the broker then places in messages sent to that
subscriber. For example, IBM's MQSeries has a correlation
identifier in all message headers. This can be modified
by the broker without having to rewrite the message
content.

     The system described uses this mechanism, but with
the key point that a broker assigns identifiers to its
neighbours, so that each neighbour has a different
identifier (two different brokers may represent the same,
third broker using different identifiers), and registers
with each neighbour using the neighbours identifier,
rather than its own. When the neighbour sends messages to
the broker, it naturally places the identifier supplied by
the broker into the message.

     In this way the subscribing broker receives messages
from each neighbour with that neighbour's identifier,
without the neighbour being aware that it is sending the
message to a broker, and without the neighbour needing to
know the value of its identifier for the broker. The
disclosure allows a multi-broker design where brokers do
not need to have special case code for forwarding messages
to other brokers. It also means that messages destined
for...