StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>If you have Azure in mind, perhaps you should start straight on Azure as the APIs and semnatics are significantly different between Azure queues and any of MSMQ or SSB.</p> <p>A quick 3048 meters comparison of MSMQ vs. SSB (I'll leave a custom table-as-queue out of comparison as it really depends how you implement it...)</p> <ul> <li><strong>Deployment</strong>: MSMQ is a Windows component, SSB is a SQL compoenent. SSB requires a SQL instance to store any message, so disconencted clients need access to an instance (can be Express). MSMQ requires deployment of MSMQ on the client (part of OS, but optional install).</li> <li><strong>Programmability</strong>: MSMQ offers a fully fledged, supported, WCF channel. SSB offers only an experimental WCF channel at <a href="http://ssbwcf.codeplex.com" rel="noreferrer">http://ssbwcf.codeplex.com</a></li> <li><strong>Performance</strong>: SSB will be significantly faster than MSMQ in transacted mode. MSMQ will be faster if let operate in untransacted mode (best effort, unordered, delivery)</li> <li><strong>Queriability</strong>: SSB queues can be SELECTE-ed uppon (view any message, full SQL JOIN/WHERE/ORDER/GROUP power), MSMQ queues can be peeked (only next message)</li> <li><strong>Recoverability</strong>: SSB queues are integrated in the database so they are backed up and restored with the database, keeping a consitent state with the application state. MSMQ queues are backed up in the NT file backup subsytem, so to keep the backup in sync (coherent) the queue <em>and</em> database have to be suspended.</li> <li><strong>Transactions</strong> (since every enqueue/dequeue is <em>always</em> accompanied by a database update): SSB is fully integrated in SQL so dequeueing and enqueueing are local transaction operations. MSMQ is a separate TM (Transaction Manager) so queue/dequeue has to be a Distributed Transaction operation to enroll both SQL and MSMQ in the transaction.</li> <li><strong>Management and Monitoring</strong>: both equaly bad. No tools whatsoever.</li> <li><strong>Correlated Messages</strong> processing: SSB can block processing of correlated message by concurent threads via built-in <a href="http://msdn.microsoft.com/en-us/library/ms171615.aspx" rel="noreferrer">Conversation Group Locking</a>.</li> <li><strong>Event Driven</strong>: SSB has <a href="http://msdn.microsoft.com/en-us/library/ms171617.aspx" rel="noreferrer">Activation</a> to launch stored procedures, MSMQ uses <a href="http://msdn.microsoft.com/en-us/library/ms752246.aspx?wt.slv=ColumnA" rel="noreferrer">Windows Activation</a> service. Similar. SSB though has self load balancing capalities due to the way WAITFOR(RECEIVE) and MAX_QUEUE_READERS interact.</li> <li><strong>Availability</strong>: SSB piggybacks on the SQL Server High Availability story, it can work either in a clustered or in database miroring environment. MSMQ rides the Windows clustering story only. Database Mirroring is much cheaper than clustering as a HA solution.</li> </ul> <p>In addition I'd add that SSB and MSMQ differ significantly at the level ofthe primitive they offer: SSB primitive is a <em>conversation</em>, while MSMQ primitive is a <em>message</em>. Think TCP vs. UDP semantics.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload