C# Queue or ServiceBus with no dependencies?

问题:

Is there a product (ideally open source, but not necessary), that would enable a zero dependency deployment? every service bus or queue library I've been able to find has a dependency on one of the queue apps (like msmq), or a database. I would like a very lightweight solution that I can just add a reference to my application, build it, and deploy it with as little configuration as possible.

In an ideal world, the queue/service bus would run on IIS, and allow web and rich clients to talk to it.

Such a tool would be ideal for fast prototyping of large distributed systems on a local development machine.

回答1:

Rhino Queues from Ayende is exactly what you are looking for, this is the blog post introducing it:

http://ayende.com/Blog/archive/2008/08/01/Rhino-Queues.aspx

I think that all of the limitations mentioned in this post have been fixed since then.

From the blog post, what rhino queues is:

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

回答2:

In a similar vein to ShuggyCoUk's suggestion, you could rig up a queue (or queues) using the Windows built-in ESENT database (comes already installed with Windows). There is a managed code access library (open source): http://www.codeplex.com/ManagedEsent. If you stick with writing / reading CLOBs or BLOBs, it should work just fine. If you want to be really clever, you can use NServiceBus and write (contribute?) ESENT-flavored subscription storage and transports. There are some forays into using ESENT on Ayende's blog as well (you'll have to poke around his SVN repository for the juicy bits).

回答3:

If you're happy to be:

1. Windows specific
2. Limited to the local domain
3. Seriously limited in the message size supported
4. Wrap the underlying win32 calls in P/Invoke
5. Deal with the polling yourself
6. Deal with the hacks needed to allow back and forth communication
7. Deal with the shared config needed to keep the names in sync

Then a quick wrapper around the windows MailSlot API might be sufficient.

This simple example is a reasonable basis to start.

This article has some further information but assumes the use case is via a control (rather than a Component as it should be) as well as some poor WinForms integration so should be considered for incidental reading rather than a basis for any library.

This article is C++ but is of a higher standard (and a commenter has extended it to support the batching of larger messages into several smaller ones).

You get 424 bytes (so with .Net 212 chars) you may want to drop to ASCII to double your useful message length if you are talking text.

Note that despite its simplicity, limitations and lack of features it does provide multicast delivery, something often complex to layer on a point to point protocol yourself.

回答4:

This ayende post provides and interesting comparison of three service buses. We use NServiceBus and think if it's not clear that Udi Dahan would respond to how you'd plug in non-dependent queue.

We work using MSMQ happily but there are other options and in theory it should be open to practically anything, given that you may lose some reliability and durability depending on your choice.

回答5:

Why not Amazon's message service Simple Queue Service?

回答6:

We moved our projects from MSMQ to ActiveMQ. its really better :)
ActiveMQ is open source queue ,based on Apache web server.
We used him in production on high frequently data workflow, where msmq have a lot of problem (we work with msmq a year)
The csharp implementation is nms

回答7:

I'm currently working on an open source WCF based service bus. You can find it here: http://rockbus.codeplex.com/. It supports dynamic (@run-time) subscriptions, subcription repository (database), pluggable transports, XPath based content-based routing, transactional delivery over wcf protocols, roundrobin delivery, pluggable subscription evaluation, and more. Have a look!

回答8:

Have you thought about using a service like IronMQ by http://Iron.io?

You wouldn't have any dependencies, could quickly prototype apps without setting up any queue infrastructure, and it's highly available and fast.

There is not currently a locally installable version but it's based on the upcoming OpenStack protocol so there will be.

Btw I work for Iron.

回答9:

Try https://github.com/mcintyre321/PieQ - this is my attempt to write a threadsafe, persistent, zero-config, embedded work queue. It probably needs a little love, but I think it might be the kind of tool you are looking for.

回答10:

I have developed an InMemory JMS library which can be used to in testing JMS applications without really connecting to JMS providers/server (Think of hsqldb). You don't have to deal with connection or protocol or anything, all you need to do is to send and receive messages.

https://github.com/Dhana-Krishnasamy/InMemoryJMS