2

I'm currently trying to find the best message queue solution for an appharbor application. Most of the ones of looked at assume you have a windows environment with MSMQ and DTC installed, which I don't believe the appharbor environment provides.

I would like something that works well with ravendb, as that is the database we are using. Something who's only dependence is on raven would be ideal, especially if it integrates with our existing unit of work. Ie, when save changes is called in our controller action the messages are saved in the same transaction.

It would also need a host that works in a console application for background processing.

Ideally I would like something that "just works" in a development environment also. With raven, for example, we use the embedded mode while developing and I would like something that doesn't require installation.

I've looked at nServicebus, which seems to fail these conditions because it needs a transport (msmq, sql, etc) and much of the documentation is out of date.

I also looked at rhino service bus but there is a distinct lack of documentation and community. I'm also not sure if it can depend entirely on ravendb.

The others I looked at all seemed quite heavyweight and required installation and configuration to run in a development environment.

Edit: the other option, is to implement our own.

flukus
  • 996
  • 8
  • 18
  • Since you are evaluating various options you could take a look at my FOSS service bus project: https://shuttle.codeplex.com/ --- there isn't an `IQueue` / `IQueueFactory` implementation for ravendb but there is one for sql server that could serve as a template. Your implementation could be merged into shuttle for others to use if you would be willing. Just a thought :) I guess you could also implement a ravendb transport for NServiceBus. – Eben Roux Apr 25 '13 at 04:01

1 Answers1

2

First of all, congratulations on being the 1000th NServiceBus question on StackOverflow!

Second, if you were to use SQL for persisting your business data, then you could run NServiceBus on top of that same SQL where all the messages go through tables (instead of queues) and then you wouldn't need the DTC.

Third, if you did want to go with RavenDB as your transport for NServiceBus, you would have to implement the ISendMessages and IReceiveMessages interfaces on top of it, but I believe that somebody in the community has already started working on that, so possibly you could join forces with them.

Finally, I wouldn't recommend writing your own ESB these days - not when there are so many good choices already out there. You mentioned the issues of community and documentation - those tend to be handled the worst when writing your own infrastructure.

Udi Dahan
  • 11,932
  • 1
  • 27
  • 35
  • Thanks, if I knew it was going to be number 1000 I would have com up with something better though :) I looked further into creating a raven transport, bit it was a bit "down the rabbit hole" with creating custom units of work etc. The core issue I seem to be having with ESB's is that they are "systems to be used" rather than "libraries to integrate with", if that makes sense. The needs for this particular system are rather modest (one way message queue) so I'm going to take a stab at implementing my own. – flukus Apr 27 '13 at 06:02
  • NServiceBus already has a unit of work implementation for RavenDB - just plug that one in. In any case, you probably will need some unit of work infrastructure for your own implementation. – Udi Dahan Apr 30 '13 at 08:22