Pierre Greborio.NET

4. Indigo

I work with the MSMQ team, and unfortunately I can't talk about their future plans right now. I will say that I think MSMQ is a fine, mature product that you should feel free to use if it meets your needs. I'd also be curious to know what you think the future *should* be, and why?

SQL Service broker is an abomination. We can only hope and pray it will be aborted before it sees the light of day (although I realize that's too much to ask). Microsoft continues to damn MSMQ with faint praise while continuously coming up with "replacements" that are either less capable or horribly complex (or like Service Broker both at the same time). What I would like to see is MSMQ extended to include an interoperable wire format and a way to tie a message contract to a queue (probably via a custom formatter/XML schema pair).

Bruce,
MSMQ is a really good product. The only think I really don't like is the message size limitation (for what I know it's 4MB).

In the future (probably Indigo as Erv says) I hope to have a better support for MQ components in .NET (the implementation of IPersistStream isn't so simple).

In any cases, MSMQ today is my primary choice, with WS duplex message patterns too.

MSMQ is a strong product, and it meets a wide variety of messaging needs today. I hope and expect that you'll be pleased to see the directions we are taking the product - I'm looking forward to the day, hopefully in the near future, when I can talk about it. Even without any visions of the future, however, there is plenty of juicy messaging goodness already shipping with MSMQ and System.Messaging.

I'd be interested in learning more about your ask relating to "MQ components" - you mean System.Messaging, right? How are you using IPersistStream with it?

Bruce, I agree, MSMQ is a strong product. The limitation of 4MB Message size could be a problem when using MSMQ with MQ components, but today I never reached that limit.

MQ Component I mean Enterprose Services queued components. And yes, I'm using IPersistStream with the Michael's wrapper (http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3537c3ce-8e80-46af-baf7-7d919e320607)

I hope to find something integrated in EnterpriseServices namespace in the near future as well as a good article ;-).

MSMQ, definitely... MSMQ is powerful, lightweight and simple to use. I would use MSMQ for everything except SQL replications (where I would consider Service Broker) or communication with Biztalk (when I would use MSMQ/T).
One thing I would really like to see in the long run, though, is "componentized MSMQ" - an MSMQ version that would let me hook up my own storage or my own transport (instead of TCP). Such version can be based on MSMQ/T.

(I am biased, of course, after working in the MSMQ team till this August :-))