Publish & Subscribe Messaging System "Shared Subscription" Explanation (TIBCO EMS)

Question

Im reading the pdf tib_ems_user_guide.pdf to prepare for an upcoming project (a project on TIBCO ESB). I got no further than the intro when I ran into what I perceived as a contradiction. I realized i am not grasping this concept. (I read a little further into it and could not find answers)

Starting on Ch1 (pg4) under the Publish and Subscribe section, I talks about "Shared Subscriptions":

Shared subscriptions are created with a specific name, and optionally a client ID. Consumers sharing the subscription specify this name when subscribing to the topic.

For example, the topic foo might have the following subscriptions:

• not shared, non-durable subscription.

• not shared, durable subscription

• shared, non-durable subscription called mySharedSub with three shared consumers

• shared, durable subscription called myDurableSharedSub with two shared consumers

If a message is received on foo, each of the above four subscriptions receive that same message. For the shared subscriptions mySharedSub and myDurableSharedSub, the message is delivered to only one if its respective shared consumers.

If the shared consumers of the shared durable subscription myDurableSharedSub are closed, then the shared durable subscription continues to exist and accumulate messages until it is deleted, or until the application creates a new durable shared consumer named myDurableSharedSub to resume this subscription. If the shared consumers of mySharedSub are all closed, the subscription is removed from topic foo.

My Questions are...

1. What is the point of the "speceific name" for a subscription. Dont you need each subscription in a topic to have some sort of specific name so that you can reference it when subscribing to it? Or is it more you subscribe to a topic and it will systematically figure out which subscription to subscribe you to unless you specify.
2. What would a client ID do?
3. Why would a subscription called "shared" only deliver its messages to one of its consumers? That seems backwards to me.

Thanks for your help,

Mingman

Answer 1

Note that the concepts apply to JMS in general, not just TIBCO EMS. Let me start with the last question.

Suppose you have a system broadcasting messages about new orders coming in on a topic. You then have say two other systems, each running on a single machine as a single process, that need to receive this message: Billing and Fulfilment. Each system would subscribe with a non-shared subscription (durable since you don't want to loose orders).

Now consider what happens when you have to scale out say the Billing system horizontally. It is now running on two servers, one process on each, that we'll call Billing1 and Billing2. If Fulfilment, Billing1, and Billing2 would subscribe each with a non-shared subscription, both Billing1 and Billing2 would receive each order. That's however not what you want, since now each order would be basically just billed twice. Rather you would want the orders to be sent in an alternating (or otherwise load-balanced) manner to Billing1 and Billing2. This is what you can use a shared subscription for. You would now a non-shared subscription for Fulfilment and shared subscription (let's call it "BillingSubscription") for Billing1 and Billing2. The first order message now would go to Fulfilment and Billing1, the second order message would go to Fulfilment and Billing2, etc.

As a side note, before shared subscriptions, you could achieve a similar effect by briding the Topic to a Queue and having the billing systems subscribe to this bridged queue.

To the first point, you need the specific name of a subscription to know which systems belong to a shared subscription. Billing1 and Billing2 share the subscription by using the same subscription name when they create the subscription to the topic. Let's say you now connect an Inventory systems running as three processes Inv1, Inv2, Inv3 also to you topic. You'd use a different subsciption name (e.g., "InventorySubscription") for these.

The clientID is used to see if a client has already received a message or not (for the case that the client is offline while the message is sent, but other clients could be online). Note that the clientID is set on the connection (and a connection can manage many subscriptions to topics and queues). If you use only shared subscriptions, it is not that useful as far as I understand. But say you have a connection that contains a durable shared subscription to Topic1 and a durable non-shared subscription to Topic2, then the clientID would be used to ensure that you receive messages on Topic2 even if you go offline for a while.