Easily Balance Messaging Workload with IBM® MessageSight™ v1.1
Andrew Schofield 120000NJ3J firstname.lastname@example.org | | Tags:  jms_client application_server messagesight internet_of_things messaging_workload messaging_exchange shared_subscriptions ibm
0 Comments | 1,308 Visits
One of the most useful features in IBM® MessageSight™ v1.1 is shared subscriptions. This is an extension to publish/subscribe messaging which enables balancing of messaging workload across many consumers.
Styles of messaging
There are two basic models for exchanging messages. Point-to-point messaging exchanges messages using queues, and while there may be many senders and receivers, each message sent is received by just one receiver. Publish/subscribe messaging is more loosely coupled. The messages are published using some kind of classification, such as a topic name, without knowing anything about the receivers. Messages are received using subscriptions which indicate which messages should be received. Each message sent might be received by any number of subscribers or even none at all.
Publish/subscribe is a nice model for messaging. It’s very flexible because it allows you to vary the message distribution pattern easily. The publishers and subscribers are typically not aware of the location or number of each other. If you think up additional uses for your messages, you just add more subscribers. The publishers and subscribers need to agree on the message format and the topic strings, but that’s it.
MessageSight supports topic-based publish/subscribe which means that every message published specifies a topic name and each subscription uses a topic filter to specify the messages it wants to receive. There’s also content-based publish/subscribe where the subscriptions use the message content to specify which messages to receive, but there’s very limited support for that in JMS (just message selectors on message properties).
So what is a shared subscription?
There’s usually a one-to-one relationship between a subscription and a message consumer, so each consumer gets a copy of every message matching its topic filter. That’s normally what you want, but if a consumer cannot keep up with the message rate, it’s no good at all.
This is where shared subscriptions come in. Each subscription still gets a copy of every message matching its topic filter, but you can connect more than one consumer to a shared subscription and share the messages among them. This, of course, lets you balance the workload across a set of consumers.
Each shared subscription has a name so that the consumers can connect up to it and start consuming the messages, and you also need specific authorization to use shared subscriptions, much as you do with a queue.
How do I use shared subscriptions?
You can use shared subscriptions from JMS clients or from an application server using the new resource adapter. In either case, you need to specify the name of the subscription and to say that it’s a shared subscription. If you forget this last bit, you’ll get an unshared subscription.
There are a couple of ways you might use them.
First, you could just run several consumers inside a single server so that you’re not limited by the performance of a single thread. Using WebSphere Application Server, you could achieve this using an MDB running on one server with the maximum number of concurrent consumers set to more than 1.
Second, you could consume the messages using more than one server. Again, using WebSphere Application Server, you could achieve this using an MDB in a cluster. MessageSight will distribute the messages among the servers with each server getting a proportion of the messages based on how fast it is consuming them.
So, that’s basically all you need to know about shared subscriptions.
IBM MessageSight v1.1 is available today. Why not download IBM MessageSight for Developers v1.1 for free and give it a try.