The Generic Programming Model

Every Pub/Sub messaging application follows a generic programming template to connect to a topic, publish or subscribe to messages from the topic, and to close the topic connections.

The basic Pub/Sub messaging client program development is as follows:

• Get (or create) a topic connection factory object.

• Get (or create) a topic.

• Use the topic connection factory object to create the Connection object.

• Use the topic connection object to create the Topic Session object.

• Decide whether to create a topic publisher or a topic subscriber object. Use the Topic Session and Topic objects to create the message producers (publishers) and message consumers (subscribers).

• Start the connection.

• Publish or subscribe to messages.

• Close the topic session and connection.

The figure below, details the steps that we just described:

A glance at the figure above will show you how amazingly similar the PTP and the Pub/Sub programming models are. If you were to substitute all the occurrences of queue, sender, and receiver in the PTP API with topic, publisher, and subscriber respectively, you would get the equivalent Pub/Sub API.

Publish/Subscribe via Multicast

A message server is required in order to provide the full set of Pub/Sub functionality defined in the JMS specification. The ability to deliver messages after the publisher is no longer available, and the ability to support transactions and durable subscribers all imply that there must be some process other than that of the publisher and subscribers that stores the messages temporarily. A subset of the JMS Pub/Sub functionality, though, can be supported without a server through the use of IP multicast. The advantages to be gained in return for the sacrifice of functionality are performance, efficiency, and simplified administration.

Consider what happens when publishing stock prices to 100 subscribers over a single LAN segment via a unicast protocol such as TCP/IP. The Network Interface Card (NIC) of the computer of each subscriber "sees" the same message 100 times, but ignores 99 of them because they are addressed to other hosts. In contrast, multicast provides basic Pub/Sub semantics at the network level.

By definition, multicast packets are sent to a multicast address. Unlike unicast addresses, multicast addresses are not associated with a particular host. Any host can subscribe to a multicast address, and as such a multicast address corresponds to a JMS topic. When using multicast-based Pub/Sub, messages travel directly from publisher to subscriber and they must only be transmitted on the network once, no matter how many subscribers there are. This can make a tremendous difference in performance and scalability.

Raw IP multicast is not a reliable protocol, and in contrast to the unicast world, there is no ubiquitous reliable protocol like TCP that is already embedded in every network operating system. There are, however, commercial MOM products, such as Softwired's iBus//MessageBus and FioranoMQ Info Bus, that provide reliable, in-order message delivery over IP multicast via a subset of the JMS API.

The current generation of network routers support routing protocols for multicast packets. This means that, in theory, multicast network traffic could be routed over wide-area networks. In reality this raises concerns in the areas of security and efficiency. Multicast packets contain a time-to-live (not related to the time-to-live of a JMS message) value that is actually an integer that determines how may routers it is permitted to pass through on its way from publisher to subscriber. A large value for the time-to-live implies that publishers and subscribers that are intended to interact are spread over a wide area.

When using multicast over such a wide area, it is difficult to guarantee that publishers and subscribers find each other in an efficient manner. It is also more difficult to ensure that only intended parties have access to the messages being sent; remember that anyone can subscribe to a multicast address through a normal socket interface; it does not even require low-level network access. For these reasons, multicast-based messaging is usually only practical in local area networks and with low time-to-live values.

It is possible, and fairly common, to link together several local multicast LAN's via a unicast bridge. This requires a gateway in each LAN that is a JMS publisher and subscriber. It relays messages to the corresponding gateway of the remote LAN via a unicast connection, where the remote gateway re-publishes them to the same topics in the remote multicast provider.

When is it desirable to use a serverless, multicast-based JMS provider over a server-based one? In cases where it is supported on the underlying network infrastructure and when performance is more important than robustness to failure. The stock price example could be implemented using a multicast-based provider, and this would probably be a better choice for many trading environments. Timely price updates are often critical to traders, whereas if a critical machine fails, or is otherwise not available, the chance to be the first to react to new price information is probably lost anyway.

In contrast, a back-office system keeps the official records of the institution, and absolute reliability is more important that performance, so this type of system would tend to be designed around a transactional server-based provider if it uses JMS.

In general, it is probably advantageous to use multicast JMS when possible: in other words, when it is supported by the network and satisfies the system's design requirements. If a Pub/Sub-based system needs to support the following features, then a server-based JMS is required:

• Wide Area Network communications

• Communication through firewalls

• Secure communication via SSL

• Transactions

• Durable subscribers