StockService samples and the MSMQ transport provider

  • Article

I had some traveling time this week and was able to get back into the MSMQ transport for WSE 2.0.  After making sure the transport provider continued to work as expected with the latest build and my shim of a test harness, I tackled the modification of the TcpAsyncStockService sample from WSE 2.0 to use the MSMQ provider.

Presently, the provider only supports friendly names for queues, MachineName\QueueName and its variants.  I need to do some work to also support the format name to enable an offline model.  Its grunge work to parse and validate the incoming endpoint reference that I’d rather not do, but in the interest of being complete and providing a broadly usable transport, I feel it’s important and will be tackling that shortly.

Another outstanding item that I need to address is the support of transactional queues.  Currently, the provider doesn’t worry about transactions at all, though my plan is to have this done as well within the next week or so.

The great thing about the transport model in WSE 2.0 is that the higher-level service code really doesn’t care about the underlying transport, resulting in a whopping addition of one line of code to each of the StockService and StockServiceClient files, and a simple modification of the EndpointReferences being used. All that’s required to register the transport for use is:

Microsoft.Web.Services.Configuration.WebServicesConfiguration.MessagingConfiguration.AddTransport(
            SoapMsmqTransport.UriScheme, new SoapMsmqTransport());

With that in place, it becomes pretty easy to wire up a URI for the SoapReceiver to listen on:

Uri uri = new Uri("soap.msmq://" + System.Net.Dns.GetHostName() + "/private$/StockService");
SoapReceivers.Add(uri, typeof(StockServiceRequestReceiver));

If you’ve looked at the Tech Preview samples, the above two lines of code should look familiar, with the change being the URI is soap.msmq://hostname/private$/StockService as opposed to soap.tcp://hostname/StockService.

Done right, the above can also be eliminated with configuration files making the registration and use of the transport quite transparent.

When a build of WSE with the current changes becomes broadly available, I’ll be looking for a few folks interested in pounding on the provider a bit and providing feedback.  Holler if you’re interested in playing around a bit.

Lastly, if you’re interested in what the underlying transport model looks like in the current iterations of WSE 2.0, take a look at Hervey’s entry on Channels.