Example 2: Publisher to a variable topic
A Websphere MQ program to illustrate publishing to a programmatically defined topic.
char topicNameDefault = "STOCKS";
- The default topic name
STOCKSdefines part of the topic string. You 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 = "IBM/PRICE";
IBM/PRICEis the default topic string. You 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
"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
IBMSTOCKPRICEtopic 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
MQOPENby the publisher. WebSphere 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/b"(Figure 3). If the publisher program refers to topic object
Aand provides topic string
"b", resolving the topic to the topic string
"a/b", then the publication inherits its properties from topic object
Bbecause the topic matches the topic string
argvis 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.
strncpy(td.ObjectName, topicName, MQ_OBJECT_NAME_LENGTH);
- For the default case, the optional
topicNameneeds to be created beforehand, using WebSphere MQ Explorer or this MQSC command:
DEFINE TOPIC(STOCKS) TOPICSTR(NYSE) REPLACE;
td.ObjectString.VSPtr = topicString;
- The topic string is a
MQCHARVfield 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 WebSphere MQ implements publish/subscribe using its underlying queuing system; the benefits of guaranteed delivery, transactionality and loose coupling associated with messaging and queueing are inherited by publish/subscribe applications.
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 queueing or not. Study the subscriber
example applications next. They are designed to be used with the publisher
examples, typically publishing and subscribing to