Silverlight Queues: Design

time to read 4 min | 619 words

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?