I’m going to start with the samples written by Björn Rochel, which are on github, so first I need a git client. Because I’ve used TortoiseSvn, I’ll use TortoiseGit to retain some degree of familiarity.
Having installed TortoiseGit and cloned the samples repository (and having read this mini-tutorial to learn a bit about git), I have a Lib folder, a Source folder and a ReadMe.txt file which says “A set of examples demonstrating important parts of the Rhino.ServiceBus API”, setting the trend for zero documentation because the code is so self-explanatory (we hope).
The Lib folder contains the Rhino Service Bus guts (Rhino.ServiceBus.Host.exe and Rhino.ServiceBus.dll) and other supporting dlls (e.g. for dependency injection and logging).
The Source folder holds ten sub-folders containing the samples. Lets start with number 1, “Hello world using MSMQ”.
The solution contains four assemblies: Client, Backend (interestingly not called Server), Messages and Utils.
Before digging into the code any further, let’s compile and run, and see what happens.
Running Backend brings up a console showing that it is waiting to receive messages:
We can also see that a new queue has been created on which messages are received for Backend (right-click on Computer in Windows Explorer and select “Manage”):
Private queues do not have the Active Directory integration of public queues, which adds a bunch of features such as name lookup. We’ll be skipping all that for now. A private queue can still receive information from remote clients – the clients just need to know where it is.
The queue has two sub-queues: the main one on which the messages are received, and a journal queue, to which processed messages can be copied so that you can see what has been going on. These are created automatically, even though journaling is not enabled in this demo (you can enable it manually after Backend has started and created its queue).
Now for the client. Start it up and it created its own queue and waits for you to press Enter to send a hard-coded message. This is sent to Backend, which replies with an acknowledgement (the original message tells it which queue to reply to).
If you turned on journaling above, you can now look at the message in the Backend journal queue and see its properties and contents.
In theory, you should be able to start Client without Backend running and send the message, then start Backend and see it display the message and send back the response. This requires that the Backend queue exists. In practice it doesn’t work because both Client and Backend purge their queues when starting up. If you remove this code and recompile, it works a treat.
So it all works locally, using MSMQ to talk between processes, but what about between machines? Should just work, right?
I copied the Backend program and supporting dlls to another machine and started it listening. I changed the target queue path in the client config file:
<?xml version="1.0" encoding="utf-8" ?>
<section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor"/>
Running the client generates no errors but nothing appears at the Backend. Worse, there are no messages hanging around in any of the queues – the message has been lost! I thought this was exactly the kind of thing that queues were supposed to prevent.
So this post ends on a cliffhanger. It seems I need to dig into MSMQ a bit more before proceeding.