Mark Bloodworth wrote a few blogs on the art of using ActiveMQ within .NET. Those posts are the origination for my ability to produce this post, so thanks, Mark. I’d highly advise going to read Mark’s introductory post on the topic first. I’ll paraphrase a good deal of Mark’s post in this one so look to him for the details and deeper explanation, he’s the man.
Mark’s post shows at a high level how to pass simple string messages via ActiveMQ. This post will answer the question of passing more complicated types via ActiveMQ so that you can use strongly-typed instances as your messages.
It sounds a bit scary, especially if you’re not akin to using non-MSMQ messaging engines. Don’t freak out, ActiveMQ actually quite easy. I’m a Java troglodyte, so if I can do this, you can do this.
Both sides of the conversation will need to have context. I’ll also throw in a strings class to mitigate fat-fingering [and potentially configuration of some sort later on]. The message class and utility class are below.
With ActiveMQ running we’re now ready to subscribe to a queue in which messages of the SampleRequest type will be sent. As mentioned earlier the first thing needed is a listener. The main difference in this example and in Mark’s post is that this code expects for the messages to be Object Messages and not Simple messages, as Mark’s example was for primarily passing string messages. Below is the generic listener, which basically expects the body of a particular message to be of the type specified in the generic argument.
Next is the program that creates an instance of the listener (and the queue if it doesn’t already exist in the ActiveMQ installation). The listener is created and bound to a ActiveMQ connection. Again, more detail in other places, for now the idea is, we’re going to listen for messages. The program code below begins watching the ActiveMQ specified in the Strings.Destination property at the URL specified in the Strings.Url property.
With the subscriber listening for messages within ActiveMQ the next application will need to send messages into the queue. As with the subscription side the publication side will rely on a generic approach to publishing messages into ActiveMQ queues.
The program code will take input from the user. Then it will use that input as the value of the SampleRequest.Message property and will set the SampleRequest.ClientMachine property to the client computer’s machine name.
When both the projects included in the accompanying download are executed the results are instantaneous.
To prove the durability of the ActiveMQ layer during debug mode, stop the subscription application and use the publication client to send a few more messages.
Then, stop the publication client. Once the subscription client is re-started, the messages sent into the ActiveMQ while the subscription application was shut down are collected and processed. The screenshot below shows how the later messages sent when the subscription app wasn’t running are processed as soon as it is re-started. Then, the publication app sends in two more messages and the new instance of the subscription app continues processing them as they arrive.