A WebSphere MQ program to illustrate publishing to a programmatically defined topic.
Note: The compact coding style is intended for readability not production use.
There are a few points to note about this example.
char topicNameDefault[] = "STOCKS";
The default topic name STOCKS defines part of the topic string. We can override this topic name by providing it as the first argument to the program, or eliminate the use of the topic name by supplying / as the first parameter.
char topicString[101] = "IBM/PRICE";
IBM/PRICE is the default topic string. We can override this topic string by providing it as the second argument to the program.
The queue manager combines the topic string provided by the STOCKS topic object, NYSE, with the topic string provided by the program IBM/PRICE and inserts a / between the two topic strings. The result is the resolved topic string NYSE/IBM/PRICE. The resulting topic string is the same as the one defined in the IBMSTOCKPRICE topic object, and has precisely the same effect.
The administrative topic object associated with the resolved topic string is not necessarily the same topic object as passed to MQOPEN by the publisher. IBM MQ uses the tree implicit in the resolved topic string to work out which administrative topic object defines the attributes associated with the publication.
Suppose there are two topic objects A and B, and A defines topic a, and B defines topic a/b ( Figure 3 ). If the publisher program refers to topic object A and provides topic string b, resolving the topic to the topic string a/b, then the publication inherits its properties from topic object B because the topic matches the topic string a/b defined for B.
if (strcmp(argv[1],"/"))
argv[1] is the optionally provided topicName. / is invalid as a topic name; here it signifies that there is no topic name, and the topic string is provided entirely by the program. The output in Figure 2 shows the whole topic string being supplied dynamically by the program.
For the default case, the optional topicName needs to be created beforehand, using IBM MQ Explorer or this MQSC command:
DEFINE TOPIC(STOCKS) TOPICSTR(NYSE) REPLACE;
td.ObjectString.VSPtr = topicString;
The topic string is a MQCHARV field in the topic descriptor
What does the second example demonstrate? Although the code is very similar to the first example - effectively there are only two lines difference - the result is a significantly different program to the first. The programmer controls the destinations to which publications are sent. In conjunction with minimal administrator input used to design subscriber applications, no topics or queues need to be predefined to route publications from publishers to subscribers.
In the point-to-point messaging paradigm, queues have to be defined before messages are able to flow. For publish/subscribe, they do not, although IBM MQ implements publish/subscribe using its underlying queuing system; the benefits of guaranteed delivery, transactionality and loose coupling associated with messaging and queuing are inherited by publish/subscribe applications.
A designer has to decide whether publisher, and subscriber, programs are to be aware of the underlying topic tree or not, and also whether subscriber programs are aware of queuing or not. Study the subscriber example applications next. They are designed to be used with the publisher examples, typically publishing and subscribing to NYSE/IBM/PRICE.