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 ...