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

Publishing Venue

IBM

Related People

Authors:
Simon Holdsworth Steve Bolam

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. 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 other brokers do not have to be modified, other than a header field change. Both of these result in a more efficient broker.