Message selectors vs Topics for message filtering on Tibco EMS

0
votes

I'm working on a client server application using Tibco EMS Topics for Pub/Sub communication.

In one of our use cases we need to send several millions of messages per minutes split over >200k "subjects".

Each client is interested in a small subset of subjects, which he needs to subscribe to.

The question is, which of these implementations is more reasonable:

  1. Send all messages over a single topic, and use message selectors to filter by relevant subjects.

  2. Create a non static topic for each subject, and have the client subscribe to the relevant subjects' topic.

1
jmstibco-emsjms-topicems
Does Tibco EMS implement message selectors on the server side, or the client ? I would avoid selectors if they are client side only. – Nicholas

1 Answers

2
votes

Message Selector are rumored to slightly impact performances... which make sense. So essentially, you have to figure out the trade-off parameters: On one side, how much to you profit of message selectors, and on the other, can you tolerate their cost in performance.

In summary, activities such as Messaging architecture (your question) and capacity/performance testing will ultimately give you the answer.

Regarding Messaging Architecture, there are a lot of questions to ask:

  • How many different subjects do you have ?
  • How dynamic is that list (does it change often)
    • Sub-question : How do the clients know that the list as changed ?
  • Is there a hierarchy involved ?

YOUR QUESTION HIGHLY DEPEND ON THE TYPE AND NUMBER OF SUBJECTS, AND THEIR NATURE.

Message selectors can be super useful when the subjects are related, and some subscribers are only interested in a subset.

Example 1 : One Topic REPORTS, with a JMS header "ReportType" present. In that case, some client migth prefer to scrubscribe to all messages, and others might subscribe with "ReportType=Sales or ReportType=Weekly". This example can get very sketchy if the list of subjects varies all the time... what program is interested in getting all the reports, event the one it does not know about (they would have to be self-described to be useful)

Example 2 : If subjects are related in a hierarchy... subscription in EMS and MQ can be to one specific branch. Imagine 3 Topics : REPORTS, REPORTS.WEEKLY and REPORTS.SALES A client can sunscribe to REPORTS.* in EMS... this is done without Message Selectors.

Example 3 : Non Static Topics. In that example, you create Topics as you go... but have to worry about many things: Testing the scaling, Getting the list of subjects to the clients, managing deprecation of subjects, making the clients listening to many subjects (very difficult... multiples connections ???), etc.

Good luck with your design,

Side note : As for the performance you are aiming for... don't hesitate to look at FTL (another TIBCO product) or products like RabbitMQ if your capacity/perf tests are not satisfactory with EMS and don'T mind losing the JMS feature. EMS is super powerful and can take quite a lot, but other products can be lighter and more performance oriented.