Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Rule-based mapping of publish/subscribe messages to different delivery protocols

IP.com Disclosure Number: IPCOM000031303D
Original Publication Date: 2004-Sep-21
Included in the Prior Art Database: 2004-Sep-21
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

The key point of the disclosure is the linking of a topic space to a communication transport in a publish/subscribe messaging environment. This enables the topic to be modified using a rule-based system in the broker, which in turn leads to the message being routed to different transports by the pub/sub matching engine, based purely on the topic hierarchy.

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

Page 1 of 2

Rule-based mapping of publish/subscribe messages to different delivery protocols

Some publish/subscribe message broker products (e.g. IBM's* WebSphere** Business Integrator Message Broker) allow subscribers to connect to the broker over a variety of different protocols, each suited to a particular role. Examples include multicast delivery, protocols optimised for low bandwidth utilisation, HTTP-wrapped protocols for easy connectivity through firewalls, etc.

    When a subscribing application connects to a broker using one of these supported protocols, and issues a subscription message to the broker, the broker will deliver any messages which match that subscribers interests over that protocol.

    There are times when it is desirable to send data out over a particular protocol, for various operational reasons, and it would be helpful to be able to route a pub/sub message to a particular protocol for delivery, using rules configured in the broker, i.e. centrally.

    An example of this might be a retail store, which during the day makes use of a high-bandwidth leased line during trading hours, but in the evening can make use of a satellite distribution mechanism during off-peak hours. Or it might be that messages that are less urgent can be sent over a connection/protocol which only connects once an hour and queues messages in between times, but more urgent messages go out immediately. Or messages above some critical size may get trickled out over a different communications path than smaller messages which can get through without clogging up any systems.

    Disclosed is a way to administratively impose such rules on messages at the central broker, which is a lot more desirable than having to hard-code such operational-level rules into every publishing application.

    The key point of the disclosure is the linking of a topic space to a communication transport.

This enables the topic to be modified using a rule-based system in the broker, which in turn leads to the message being routed to different transports by the pub/sub matching engine, based purely on the topic hierarchy.

    The mechanism proposed here (as a preferred embodiment) is that the protocol name is pre-pended to the topic name by a transformation rule that is executed by the broker.

    So for example, suppose the rule is that before 6pm messages on topic "x/y/z" should go out over protocol A, and after 6pm over protocol B. When a publication comes into the broker from a publisher on topic x/y/z, a transformation rule in the broker is used to modify the topic, based on the current time, so if it's before 6pm the topic is changed to "protocolA/x/y/z", and if it's after 6pm it is changed to "protocolB/x/y/z".

    A subscriber that wishes to receive messages on topic x/y/z, over either protocol A or protocol B, connects to the broker over protocol A and subscribes to "protocolA/x/y/z", and also connects to the broker over protocol B and subscribes to "protocolB/x/y/z".

    Now, during the day (i.e. befor...