One of the things that often come up in the NServiceBus mailing list is the request for an xcopy, zero administration, queuing service. This is especially the case when you have smart clients or want to have queues over the Internet.

I decided to try to build such a thing, because it didn't seem such a hard problem. I turned out to be wrong, but it was an interesting experiment. Actually, the problem isn't that it is hard to do this, the problem was that I wanted durable queuing, and that led me to a lot of technologies that weren't suitable for my needs.

You can get the bits here: https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/branches/rhino-queues-1.0

What it is:

• XCopyable, Zero Administration, Embedded, Async queuing service
• Robust in the face of networking outages
• System.Transactions support
• Fast
• Works over HTTP

What it isn't:

• Durable queuing service
• Wetted by production use

Broadly, using Rhino Queues you get async queues over HTTP. But, it keeps all the data in memory, so if you restart the application, it will lose all waiting messages. It also tries its best (but does not guarantee) to ensure message ordering and ensure delivery.

Let us take a look at the code, and then discuss the implementation details from there.

Server usage:

using(var factory = new Configuration("server")
	.Map("server").To("http://localhost:9999/server/")
	.Map("client").To("http://localhost:9999/client/")
	.RegisterQueue("echo")
	.BuildQueueFactory())
{

	factory.Start();
        using (var queue = factory.OpenQueue("echo"))
	{
		var message = queue.Recieve();
		var str = (string)message.Value;
		var rev = new string(str.Reverse().ToArray());
		using(var remoteQueue = factory.OpenQueue(message.Source))
		{	
			Console.WriteLine("Handled message");
			remoteQueue.Send(rev);
		}
	}
}

And the client usage:

using(var factory = new Configuration("client")
	.Map("server").To("http://localhost:9999/server/")
	.Map("client").To("http://localhost:9999/client/")
	.RegisterQueue("echo-reply")
	.BuildQueueFactory())
{

	factory.Start();

	using (var tx = new TransactionScope())
	using (var serverQueue = factory.OpenQueue("echo@server"))
	{
		Console.WriteLine("Sending 'hello there'");
		serverQueue.Send("Hello there").Source = new Destination("echo-reply@client");
		tx.Complete();
	}
	
	using (var clientQueue = factory.OpenQueue("echo-reply"))
	{
		var msgText = clientQueue.Recieve();
		Console.WriteLine(msgText.Value);
	}
}

As you can see, we map a nice name to an endpoint, so we can send message to [queue]@[endpoint nice name], sending a message to just [queue] send it to the local machine. It is expected that the nice name for an endpoint would be the machine name, which alleviate the need of syncing names across all endpoints.

You can also see the usage of System.Transaction and without System.Transactions.

One thing that would probably raise questions is why Rhino Queues doesn't have a durable mode, after all, I just spent some time building a durable queue infrastructure. The reason for that is very simple, I spent too much time on that, and I can't spend more time on this at the moment. So I am putting both Rhino Queues and Rhino Queues Storage Disk out there, and I'll let the community bring them together.

A word of warning, Rhino Queues is a cool project, but it is not a replacement for such things as MSMQ. If you can, you probably want to make use of MSMQ, specifically because there is a lot more production time using it.