Developing publish/subscribe applications

The following information shows you how publications and subscriptions flow through the network and tells you about different subscribers and publishers.

How publications and subscriptions flow through the network

The transport mechanism that you choose determines how publications and subscriptions flow through a network. The transports that are available are described in End-user application support

MQ Subscribers and Publishers

When a client registers a subscription, the broker registers a matching subscription with its neighbors. This is called a 'proxy subscription'. If an identical subscription has already been registered, the broker does not register again; only one proxy subscription is in effect at any one time. Similarly, when a client deregisters a subscription from a broker, the broker deregisters the proxy subscription from its neighbors, if the client is the only client for which the broker is holding the proxy.

Content-based filters are not included in proxy subscriptions. A super-set of messages might be received by the broker to which a subscriber that specified a content filter is registered, but a message is not passed on to that subscriber by its local broker unless there is a content match.

All proxy subscriptions are made with the PersistenceAsPublisher option. This results in messages being delivered to neighboring brokers with the persistence specified by the publisher. Client subscription persistence options only take effect at the local broker; that is, at the broker with which the clients have registered.

A subscriber that requests persistent delivery always receives a persistent message for matching publications. However, the message might be delivered through the broker network as a nonpersistent message if this was specified by the publisher. If a problem occurs during the transmission of a message between publisher and subscriber, the subscriber might never get the message despite specifying persistent delivery as an option on subscription registration.

Real-time Transport Subscribers and Publishers

When two neighboring brokers contain a message flow that has either a Real-timeInput node or a Real-timeOptimizedFlow node, a connection is made between the two brokers using the broker host and broker port parameters that are configured as part of the broker.

Subscriptions and 'proxy subscriptions' are not forwarded to neighboring brokers for clients that subscribe using Real-time Transport.

Real-time Transport publication messages are forwarded to all neighboring brokers, even if there are no Real-time Transport subscriptions there to match.

Multicast publish/subscribe can be used to improve network utilization.

Related tasks
Publishing
Subscribing