Complex Type Messaging with ActiveMQ and .NET
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.
- Download ActiveMQ (as of this post the current release was 5.5.0)
It’ll come as a ZIP file. I just unzipped mine to my root drive, so C:\ActiveMQ
- Download Spring.NET
I placed mine again, in my system root, at C:\SpringNet
- In the ActiveMQ\conf you’ll find the file activemq.xml, and in that file you’ll need to make sure you set the file as displayed in the screenshot below. This is explained in the comments of Mark’s post in more detail, but for now, just trust me.
- Go to a dos prompt, cd into the ActiveMQ\bin directory, and type “activemq” (without the quotes). You’ll see a window like that below open and you’ll need to find a line similar in nature to the one highlighted. Again, there’s some detail in Mark’s post on this we won’t delve into at this point.
- That’s it! We’re ready to code! Most of the code is again, inspired – okay, mimics – Mark’s examples. Our point here is to pass complex message types via ActiveMQ, so we’ll do a few things slightly differently. I’ll also take a few naïve steps and use generic implementations for publishing and subscribing to messages.
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 SampleRequesttype 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.Urlproperty.
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.Messageproperty and will set the SampleRequest.ClientMachineproperty 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.