Be careful what you ask for.

I among a vocal crowed who has been asking the Indigo team for a MSMQ and/or MQSeries transport for WSE 2.0. During the last round of complaining, I was asked - along with Martin Pichardo - if I'd be willing to take this on and create the MQSeries transport for WSE 2.0.  Of course, it wouldn't look good if we were supporting IBM's technology before our own, so this also means creating an MSMQ transport as well.  In addition, we'll also be crafting a whitepaper for MSDN that details these transports and hopefully conveys how to create your own.

Ingo Rammer blogged about this back in June, and he was kind enough to send me his MSMQ sample.  While it works, I find that reading someone else's code doesn't carry the same learning experience as doing it yourself, so I set out to create my own MSMQ transport from scratch.  My goal in doing it from scratch is to understand what is and isn't required when implementing your own transport and set the stage for documenting my experience.

After spending a few hours last week, I have a working MSMQ transport - and the MQSeries transport is not far behind.  Currently, the MSMQ transport works very well for one-way messaging.  Unfortunately, it's challenged at the moment in that it's not respecting the <wsa:ReplyTo> element for WS-Addressing and the SOAP response ends up being dropped onto the same queue that was used to send the request.

I'll be blogging about the various WSE APIs necessary for implementing your own custom transport as a precursor to writing the article, so stay tuned for more.