+972 52-548-6969
Silverlight Queues: Design
I got a question about the feasibility of porting Rhino Queues to Silverlight, but that isn’t really something that can fit in that scenario. So I set down to write the design for a Silverlight queuing system. Just to be clear, I have no intention currently to actually build this at this time (well, not unless someone is willing to pay for it or I get a project that requires it). This is merely a way to get the design problem off my head.
Why can’t we just port Rhino Queues to Silverlight?
There are two reasons, one is technical, the second relates to the different way that Silverlight applications are used. The first problem is that Rhino Queues requires a way to listen to incoming messages, but Silverlight offers no way of doing such (reasonably so, FWIW, since that would turn the Silverlight app to a server, and there are probably security issues with that).
The second problem is simply that the way most Silverlight solutions are structured, there is going to be a WAN between the Silverlight app and the server, and WAN between each client. Direct connections between the Server & Silverlight client is likely to be possible only when using HTTP, and there isn’t going to be any direct communication between different clients.
This usually looks something like this:
Rhino Queues is built on the notion of independent agents, each of them containing a full queuing stack. That model will not work for Silverlight. In Silverlight, we need to support all the usual queuing features, but each agent (Silverlight application) is no longer independent.
The Silverlight Queues model will be slightly different. We introduce a Queues server component which will hold the queues & messages internally.
On the client side, the process of sending messages is:
- Queues.Send(“server”, “Orders”, new Buy{ … });
- Message is saved to isolated storage
- A background thread send the messages from isolated storage to the Queues server.
The process of receiving messages is:
- A background thread periodically pools (an alternative is a Comet using something like WebSync) the server for new messages.
- Messages are written to isolated storage
- The Silverlight acknowledge the receipt of the messages.
There are some twists here, though.
In a Silverlight application, there are going to be several possible use cases:
- Each Silverlight application has its own “queue” in the Queues server. That allows a one-way messaging platform with point to point notification. That is likely to be common in Silverlight applications that handle business transactions.
- Topics, in addition to a queue per client, we might also want to allow subscription to topics, for example, I may be interested in getting notifications when the system settings have changed. That is something that is shared among all (or a lot) of clients. The Queues server should support this as well.
An interesting approach to make the Queues server even more stateless is to remove the process of acknowledgement and change it to “give me all messages after…”
Yes, I know that this is a very high level design, but there really isn’t much here that I can call very complex.
How much interest is there in Queuing system in Silverlight?
Comments
Could WebSockets offer an alternative mechanism for broadcast / polling?
"How much interest is there in Queuing system in Silverlight?"
Isn't the question: "what problem would this solve?", and the answers to that should be analyzed and if the best answer involves queueing, then one should look at a queueing system but IMHO it now looks like you're looking for a problem which fits a solution which was written without knowing the problem.
Howard,
Probably, that is highly dependant on the requirements that you have for ttl for messages, I think.
Frans,
The problem that this solves is the same problem outlined here:
msdn.microsoft.com/en-us/magazine/ff796225.aspx
The need exists, witness only by the fact that people asked me about it.
Just looked through Alexandria. Interesting! I am just wondering - what protocol does rhino.bus use? can it be hosted in IIS much like a WCF service?
Just questioning myself whether message request/response + batching could be put on top/into WCF...
Websync looks quite elegant, as opposed to ye old' polling. The other day, a colleague of mine explored a Comet approach based on this article: www.codeproject.com/KB/aspnet/CometGrid.aspx
First things first ;) Do we have an open implementation of Comet for the .NET stack?
Silverlight Polling Duplex might make things a bit easier.
Alexandria uses Rhino Queues, which can't be hosted in IIS, but you can use MSMQ (or any other queuing tech) as well
I agree polling duplex is the right way to go here for silverlight. I do think there's a need. It would be very nice for those trying to achieve a CQRS solution in Silverlight. Could also be something that sets RSB apart from other solutions if there is an easy bridge between the two.
Off-topic
in what program do you make those nice diagrams and where do you find such nice pictures of server, computer, firewall ... ?
www.gliffy.com/gliffy/#templateId=blank&signup=1
We are currently developing a Silverlight app that communicates with a webserver that is using rhino servicebus to orchestrate messaging with different services. Currently we are using httppollingduplexbinding to forward incoming messages server side over wcf to caliburn.reactive where messages are pushed to the relevant components client side.
What we think would be nice is simply to retain the rsb api client side. Unfortunately we have had no time to investigate in how to do that ourselves. Offline availability is not a requirement for us, so we don't really have a need for having persistent messages client side.
I would love to see some framework/toolkit for that!!
Now i'm thinking on using rhino bus or some other bus framework, and polling duplex services for Silverlight. Then, on silverlight side, another messaging pub/sub system (mvvmlight) for internal SL needs. Unified system would make this much easier.
I think this solves more than just Silverlight, such as MSMQ isn't that great if the client's end point keeps changing, such as if you have a laptop out in the field connected using 3G. The client won't have a constant connection (perfect reason for using queues), but also won't have a consistent IP or DNS name.
I'd name the server side per-client holding area mailboxes, since they work similar to say POP3 email (or using Comet, IMAP with push).
The main points I saw is the mailboxes need to be cheap, as you'll probably need to create a large number of them as you'll need one per client, which might translate to one per session. From what I've seen a queue per client for MSMQ wouldn't be pretty, not sure about Rhino.Queues or ActiveMQ. RabbitMQ seems to eat memory when it has a large number of queues from what I've read.
I was thinking something as simple as serialize each message to the file system server side, perfect if the message order doesn't matter as you can use the message's guid as the file name. If the serialized format matches the wire format then it's ready to go, which can also work well with systems like AtomPub.
Spending some time reading up on WebSockets I think that could give some interesting options over PollingDuplex.
Comment preview