http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Sven, It can serve as a replacement for Rhino Queues, but it is also going to serve as a notification server for applications. I am probably going to write an article or two on that. http://ayende.com/4687/raven-mq-principles#comment36http://ayende.com/4687/raven-mq-principles#comment36Mon, 15 Nov 2010 08:27:31 GMTAyende, I learned a lot from reading your recent articles in msdn magazine. How does RavenMQ fit into the ideas you presented in the articles ? Is it "just" a replacement for Rhino Queues that is better suited to the scenarios you talked about in the articles ? Does anything else change ? Is there going to be a sequel (series) ? :-) http://ayende.com/4687/raven-mq-principles#comment35http://ayende.com/4687/raven-mq-principles#comment35Sun, 14 Nov 2010 22:29:10 GMTHa ok sorry about that :) It will be really nice if you do :) you are going to use async networking either way right?,because you plan to handle a lot of clients(in this case clients can be web browser and not just a app like in normal queuing systems). http://ayende.com/4687/raven-mq-principles#comment34http://ayende.com/4687/raven-mq-principles#comment34Thu, 11 Nov 2010 14:05:52 GMTUriel, I didn't say that I am not supporting them, I said that I don't know if I will http://ayende.com/4687/raven-mq-principles#comment33http://ayende.com/4687/raven-mq-principles#comment33Thu, 11 Nov 2010 14:02:53 GMT why you are not supporting long-polling? ,it is pretty much the only cross-browser way of doing real time updates,and it is very easy to implement using async networking. http://ayende.com/4687/raven-mq-principles#comment32http://ayende.com/4687/raven-mq-principles#comment32Thu, 11 Nov 2010 13:54:05 GMTUriel, That is pretty much it, yes. It will support Mono, and it has HTTP API http://ayende.com/4687/raven-mq-principles#comment31http://ayende.com/4687/raven-mq-principles#comment31Thu, 11 Nov 2010 13:48:51 GMTJesus, I might, it depends on too many factors. Long polling doesn't really work that well in the scenarios that I have in mind (multi level subscriptions) http://ayende.com/4687/raven-mq-principles#comment30http://ayende.com/4687/raven-mq-principles#comment30Thu, 11 Nov 2010 13:48:13 GMTThis is basically to support real-time web apps(ala COMET) right? A message bus with history and WebSockets support. looks nice will it support Mono? and will it have a HTTP API? http://ayende.com/4687/raven-mq-principles#comment29http://ayende.com/4687/raven-mq-principles#comment29Thu, 11 Nov 2010 13:46:26 GMTAyende, And are you considering to fall back to long polling when WebSockets is not available at the client side? http://ayende.com/4687/raven-mq-principles#comment28http://ayende.com/4687/raven-mq-principles#comment28Thu, 11 Nov 2010 10:54:20 GMTLuke, I really like use naming conventions, and it works pretty well in this regard. It just happens to fall nicely into the REST pattern too. http://ayende.com/4687/raven-mq-principles#comment27http://ayende.com/4687/raven-mq-principles#comment27Thu, 11 Nov 2010 10:24:30 GMTJesus, I plan to use WebSockets, not long polling, but essentially, yes. http://ayende.com/4687/raven-mq-principles#comment26http://ayende.com/4687/raven-mq-principles#comment26Thu, 11 Nov 2010 10:23:14 GMTAyende, Would I be somewhere near correct in assuming the usage (or one usage pattern) would be similar to: Publish: Post to Stream /stream/service/identifier Subscribe: Get (instant or long-poll) from /stream/service/identifier So, the short question, is it modelled on Rest, or is that just the format you decided on for naming streams. http://ayende.com/4687/raven-mq-principles#comment25http://ayende.com/4687/raven-mq-principles#comment25Thu, 11 Nov 2010 02:00:52 GMT@Jesus - It seems very likely that this is the case, as I certainly get that feeling from this short post. Even if, in the off chance, that it isn't exposed as such (which really, I'm pretty sure is half the point), a light wrapper would serve to expose a stream ala comet server. http://ayende.com/4687/raven-mq-principles#comment24http://ayende.com/4687/raven-mq-principles#comment24Wed, 10 Nov 2010 23:45:38 GMTAyende, Can it be used as a kind of Comet server where javascript clients (browsers) long poll queues for events (or messages)? http://ayende.com/4687/raven-mq-principles#comment23http://ayende.com/4687/raven-mq-principles#comment23Wed, 10 Nov 2010 18:14:43 GMTI can not wait to see this product in action. To me it seems like the answer to using messaging with Smart Clients especially when you need to publish events to smart clients not located on the same subnet. Could this be used with Windows Phone 7? http://ayende.com/4687/raven-mq-principles#comment22http://ayende.com/4687/raven-mq-principles#comment22Wed, 10 Nov 2010 15:57:44 GMTGreat! Exactly what I wanted to hear. Eager to see it in live. http://ayende.com/4687/raven-mq-principles#comment21http://ayende.com/4687/raven-mq-principles#comment21Wed, 10 Nov 2010 15:20:04 GMTIgor, Of course. In fact, the way it works, the client keeps track of its last seen ID. That is how you ensure that you aren't getting the same message twice. http://ayende.com/4687/raven-mq-principles#comment20http://ayende.com/4687/raven-mq-principles#comment20Wed, 10 Nov 2010 14:54:04 GMTAyende, and will it be possible to query not only full historical set of messages, but also a subset starting from particular time or particular message ID ? http://ayende.com/4687/raven-mq-principles#comment19http://ayende.com/4687/raven-mq-principles#comment19Wed, 10 Nov 2010 14:49:06 GMTPeriop, Probably, and I would like to keep options open on that. I'll say that I have passing tests right now :-) http://ayende.com/4687/raven-mq-principles#comment18http://ayende.com/4687/raven-mq-principles#comment18Wed, 10 Nov 2010 14:01:24 GMTDo you think this is something that could be integrated into NServiceBus? When to you plan to have a working version of this Raven MQ? http://ayende.com/4687/raven-mq-principles#comment17http://ayende.com/4687/raven-mq-principles#comment17Wed, 10 Nov 2010 13:54:20 GMTGenerally speaking, you can avoid deletion by ID, Then you will need only a truncate operation (or kind of archiving). Actually, the source of my association is how database for SMS processing works - no updates and deletes... Again, never mind. http://ayende.com/4687/raven-mq-principles#comment16http://ayende.com/4687/raven-mq-principles#comment16Wed, 10 Nov 2010 11:28:41 GMTIgor, I suppose so. Take note that messages are deleted eventually. And we will probably have to do replication and point to point at some point, so it is a bit more complex than that. http://ayende.com/4687/raven-mq-principles#comment15http://ayende.com/4687/raven-mq-principles#comment15Wed, 10 Nov 2010 10:49:51 GMTLet me explain. Your stream concept actually means that you keep all the messages in your centralized storage (i.e., you don't delete them). Messages are not being updated as well - a new message is placed instead. And finally, your storage is centralized. So, it looks like an event triggered DB without update and delete operations. Anyway, it's just another point of view, never mind. Now I am interested in something like you described. I tried Laharsub mentioned above, and another promising project - nvents.org. But your idea looks more complete http://ayende.com/4687/raven-mq-principles#comment14http://ayende.com/4687/raven-mq-principles#comment14Wed, 10 Nov 2010 10:46:36 GMTIgor, I think that I need more information to understand what you mean. And there will be a .NET Client API http://ayende.com/4687/raven-mq-principles#comment13http://ayende.com/4687/raven-mq-principles#comment13Wed, 10 Nov 2010 10:23:44 GMTAyende, it looks more like a new type of database engine with select an insert but without update and delete (which should be fast), extended with publisher-subscriber mechanism. Isn't it? And what about non-web .NET client? http://ayende.com/4687/raven-mq-principles#comment12http://ayende.com/4687/raven-mq-principles#comment12Wed, 10 Nov 2010 10:19:39 GMTDarius, With MSMQ, RabbitMQ, etc - it is expensive to create a queue. You wouldn't create thousands of them or create/destroy queues on the fly. http://ayende.com/4687/raven-mq-principles#comment11http://ayende.com/4687/raven-mq-principles#comment11Wed, 10 Nov 2010 09:58:08 GMT>>> Unlike in most queuing systems, queues are cheap. By " most queuing systems", what do you mean? Sound like in most of the products queues are expensive from your point of saying. (Which in my experience is not true) http://ayende.com/4687/raven-mq-principles#comment10http://ayende.com/4687/raven-mq-principles#comment10Wed, 10 Nov 2010 09:53:29 GMTReshef - CQRS is irrespective of messaging, let alone a particular messaging implementation (which this is). Instead, try thinking about Raven MQ in a way that directly supports a CQRS implementation (as I think Ayene may have been alluding to) http://ayende.com/4687/raven-mq-principles#comment9http://ayende.com/4687/raven-mq-principles#comment9Wed, 10 Nov 2010 03:15:56 GMTReminds me of XMPP. Effectively a message bus but with a more instant-messaging-inspired architecture for clients across the web. http://ayende.com/4687/raven-mq-principles#comment8http://ayende.com/4687/raven-mq-principles#comment8Tue, 09 Nov 2010 23:49:39 GMTDoesn't cqrs already solves this problem? And, cqrs consolidates the state of the changes to the state instead of letting each client do it for itself. http://ayende.com/4687/raven-mq-principles#comment7http://ayende.com/4687/raven-mq-principles#comment7Tue, 09 Nov 2010 16:08:09 GMT