When a publishing or subscribing application is remote from its
destination, remote publication points are used to manage the flow of messages
between the messaging engine where the destination is located, and the messaging
engine to which the application is attached.
The following diagram illustrates the use of remote publication points
in publish/subscribe messaging. Messages are published to a publication point
on ME1, and are routed to publication points on ME2 and ME3 via remote publication
points on ME1. The messages are consumed from subscriptions on ME2 and ME3.
Figure 1. Publish/subscribe messaging using remote publication points.
The sequence of steps involved in remote publish/subscribe messaging is
as follows:
- The administrator creates a topic space destination on the bus; this creates
a publication point on each messaging engine in the bus.
- The subscribing applications register subscriptions for a topic on the
topic space on their local messaging engines. ME1 is informed that ME2 and
ME3 are interested in the topic.
- The publishing application, on ME1, publishes a message for that topic
and topic space to the bus, for distribution to the publication points on
each messaging engine.
- The remote publication points on ME1 queue the message for transmission
to their respective publication points on ME2 and ME3.
- The message is sent to the publication points on ME2 and ME3 as soon as
possible. ME1 remembers the existence of the message until both ME2 and ME3
confirm that they have received the message.
- The subscribing applications consume the message via their subscriptions
on ME2 and ME3.
In the above example the subscribing applications are attached to the same
messaging engines that their subscriptions were created on. If a subscribing
application has a durable subscription, it is possible for the application
to be attached to a different messaging engine than the messaging engine that
the subscription was created on. In this case the subscribing application
accesses its subscription via a
remote subscription on the messaging
engine to which the application is attached. In the example below, messages
are published to ME1, and are routed to the durable subscription which resides
on ME2. The messages are consumed from ME2 via a remote subscription on ME3.
Figure 2. Publish/subscribe messaging using a remote
subscription
In this situation,
Subscribing Application B consumes messages from its subscription in the same
way as an application consumes remotely from a queue point, as detailed in
Point-to-point messaging example using remote queue points.