WSE 2.0 and Alternate Transports
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.