Last week I posted the first in a series on Mass Transit, an open source enterprise messaging system.  This series is my public exploration into messaging for our eCommerce application.  In this post I'm going to dig in to see an actual working example.  I like to see something work, then dig in to figure out how it's all put together.  We'll take a look at a simple publish subscribe example to see the messaging in action.  In later posts we'll dig in deeper into the guts of MassTransit.  That said, let's see some MassTransit in action!

Getting Started

I've downloaded the MassTransit source from the Google Code repository and am going to run one of the samples provided with the source.  We'll look at their "PublishSubscribe" sample.

Project Structure

Opening the solution reveals nine projects, a few more than what I would consider a simple sample, however don't let the solution scare you away.  It turns out that you can for the most part ignore five of the projects, the mass transit infrastructure projects.

There are four parts to this solution that are relevant and we'll focus on those:

• Client - The client represents the application that wishes to leverage messaging.  It plays the role of publisher in this example.  It is worth noting however that in this example, as we'll see, this project is also a subscriber.
• Security Messages - This is a pretty simple project as it should be.  This project encapsulates the strongly typed messages that will be passed throughout the system.  By having the messages in their own light-weight assembly we can keep our messages separate for their consumers.
• Server - This project acts as the subscriber.  In a normal scenario this server may be sending out emails or logging particularly interesting things as messages come through or whatever else you may have a need for.  Like the client project, we'll see that this project also plays dual roles, the subscriber as mentioned and also a publisher.
• SubMgr - The subscription manager, is quite a mystery to me.  It may not be obvious, but the subscription manager is needed to get everything to work.  As Dru explains it to me, it is the glue.  In my first go around with MassTransit, I created a client and server and was frustrated when nothing was working.  Talking with Dru, he quickly pointed out my error, I had no Subscription manager.  In the following posts I hope to clear up some of the mystery for myself around the subscription manager.  My understanding at this point of the subscription manager, which may be a bit simplistic, is that it pushes the messages to each of the queues which are interested in the message.  A publisher publishes a message, the subscription manager is the one that ensures that it ends up in the appropriate queue(s) for consumption by various subscribers.

Getting Setup

In order to get this sample going you first have to create the MSMQ queues that this sample expects:

• mt_client
• mt_pubsub
• mt_server

You can create these queues in the Message Queuing area of the Services and Applications snap-in in the computer management area on your computer.

Seeing Is Believing

Now that we've got the project set up let's fire it up and see what we get.  Since we need all three applications running at once, the client, server, and subscription manager we can take advantage of a cool feature in Visual Studio, multi-project startup.

With multi-project startup you start any number of projects in your solution.  From the properties dialog for the solution we can choose which projects we want to kick off.  (It is worth noting the order in which I have these projects launching.)

What's Going On

When you run this example, the client application will ask you to enter a new password.  When you type in a new password  you will get a nearly instantaneous response letting you know the password was updated.

The thing to bear in mind here is that at the point you hit the <enter> key submitting your new password, the client publishes a message and then it is done.  It appears instantaneous but you'll want to keep in mind that it is asynchronous.

The Flow Of It All

The diagram to the right illustrates what is going on once you hit the <enter> key.

1. The client publishes a RequestPasswordUpdate message (see the Security Messages project in the solution for this message object).
2. The server in this case consumes the RequestPasswordUpdate message.  When it is notified of the message, it logs the new password, then...
3. The Server publishes a new PasswordUpdateComplete message.
4. The client consumes the PasswordUpdateComplete message and in so doing writes to the console that the password update is complete.

It is worth noting here that the client knows nothing of the server and the server knows nothing of the client.  Our example could easily expand to have multiple clients (think for example a windows app or multiple web servers in a farm).  Likewise there could be multiple server instance, each consuming different messages.  In other words, we are very loosely coupled, which is a good thing.

Conclusion

I hope this introduction to the MassTransit was beneficial.  Now that we've seen the example working, in the next post I'll revisit the idea of durability.  We'll augment this example and simulate a breakdown in infrastructure and see what durability really means, which is really at the heart of this fantastic open source library.