SYSK 179: MSMQ Roadmap
When I found that searching on the Internet for “MSMQ Roadmap” resulted with zero matches, I knew I had to create this post.
Quick recap – since 1997 application developers have been using Microsoft Message Queue (MSMQ) in applications that needed reliable queuing support for asynchronous, message based transactions in offline (temporarily disconnected) environments. So, with Windows Communication Foundation (a.k.a. Indigo) as the new unified communication model coming out later on this year, what’s going to happen to MSMQ?
Rest assured, MSMQ functionality is not going anywhere… As a matter of fact, MSMQ is the engine for WCF Queued Channels. MSMQ, as other communication technologies such as DCOM, .NET remoting, and web services will be integrated with WCF, and developers will be able to use System.Messaging namespace to build asynchronous, durable, reliable, secure, transacted queuing applications.
Moreover, Microsoft continues innovations in the MSMQ space by adding new features in MSQM 4.0 that will ship as part of WCF in Longhorn Server and Vista, e.g.:
- Adding infrastructure for “poison message” handling, including message abort counts and message rejection
- Per application dead-letter queue, resulting in better isolation between applications
- Support for transactional remote read, i.e. transactional receive from a remote queue
- Subqueues (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msmq/html/f33640e3-b946-460e-b611-5d86c152ba12.asp)
- Improved administration and diagnostics, e.g. more detailed operational events, tracing, and queue connection diagnostics
Finally, applications using MSMQ today will seamlessly integrate with Integrate WCF Queued applications without changing existing MSMQ apps.
Comments
- Anonymous
August 16, 2006
It will be really nice to see MSMQ support wide range of Programming Languages (Java, Ruby, Python). It can be done today but using some thirdparty tools. The biggest advantage of MQ Series is that it supports C, C++, Java, C# but the issue is that it is so expensive. If only MSMQ could provide bindings for other languages, it would be be the ubiquitous messaging bus in an enterprise.