Refactoring MSMQSoapProvider for Generic Async Support


I had an epiphany the other day in which I realized there’s no need for both the MSMQ
and MQSeries channels to have their own, dedicated SoapTransport.  Instead,
the transport itself is really quite generic.  It’s
the transport-specific channel that we really care about.  Thus,
SoapAsyncTransport was born to service the needs of both queuing technologies.

SoapAsyncTransport’s constructor takes a System.Type of a SoapChannel-derived class
and a string representing the scheme for the transport (i.e., soap.msmq or soap.mqseries.)  It
dynamically creates transport-specific channels as needed.

I bet the SMTP model could be brought into this model …

Comments (2)

  1. Hey, I hope you guys are sure that we are eagerly waiting for your code! 😉
    Seems you did a great job. This kind of stuff will enable a lot of new views on Web services, finally we can go away from this "Web services are over HTTP and are simple synchronous point-to-point integration and interaction" picture – cool!

Skip to main content