JMS Topic vs Selector

Question

JMS Topic and JMS Selector are quite different concept, yet they both can be used by a consumer to get only a subset of the messages.

in a PubSub scenario, what are the pro’s and con`s of filtering messages using:

Option 1) Publishing everything in a single Topic and consumers uses JMS Selector

Option 2) Subscriber subscribe to one or multiple Topic.

Exemple:
I am Publishing Client Data Message and Subscriber might want to get only a particular type of client. A client types is defined in different attribute like ‘ClientGroup’ ‘ClientSource’ ‘ClientOrgUnit’ ‘ClientSize’ etc

What should I do:
1) Create a different Topic for each client type
OR
2) On topic and Have each type in a JMS Property and let Subscriber use Selectors?

Thank you

Answer 1

In general, selection based on topic string should be faster. A side effect of selection on topic in a WebSphere MQ cluster is that messages are not distributed to network nodes that will not consume them. In WMQ V6 message selectors are implemented at the client so the application still gets every message but only sees the ones that match the selection criteria. In WMQ V7 the QMgr will perform the selection but the message must get to the QMgr for that to happen. So if every client is subscribed to the same topic then messages will flow to every QMgr where a client is connected. But if the clients subscribe at granular points in the topic tree, messages will only go to nodes where something has subscribed to them.

Apart from distribution, the question of topic or property selection is greatly influenced by taxonomy. The design of the topic tree should provide granularity according to the logical data hierarchy but, unlike a file system, there are no "soft links" possible to overlay alternate structures within the tree. It is a simple hierarchy.

In many cases there are data elements which if used in the topic tree would break the taxonomy and yet these are needed for selection. These are candidates for properties.

Topic elements tend to be more categorical in nature. Items such as region, cost center, department number, branch number tend to fall into topic trees because they serve to partition data according to categorical business requirements.

So as a general rule, use topics for those things by which you might summarize transactions. These generally follow the existing and natural taxonomies you already use to define your business. For example, department or cost center are two common elements. If you can easily imagine a report broken down by that value, it may be a topic element. "Show me all transactions from branch 01234" is an example. Use properties for things that are attributes of specific transactions rather than categories. Examples here would include color or price. Chances are "show me all transactions for blue items" sounds wrong because blue is not a categorical element and therefore is probably not a good candidate for the topic tree. (Unless you are in the paint business!)