Breakout Session: WCF Integrated COM+ and MSMQ

This breakout session dealt with how you can stage the migration of your existing applications using COM+ and MSMQ to WCF.  I won’t get into great detail with this one, thought it was a very good session.

Andy Milligan from Microsoft presented along with another man I didn’t catch the name for.

He presented a scenario where a company had legacy VB6 components hosted in COM+ and a Windows Service that was taking messages off the queue and processing them. His first scenario included the ability to call the existing COM+ components via a WCF application. He did this by using the ComSvcConfig utility to draw information out of the COM+ metabase to create the same service description that any WCF service would provide. The tool created not only the .svc file to host in a vdir, but also the accompanying config file, virtual directory and metadata. He could then use these files just as if he had created a real WCF service and connect up his new WCF client to it. NOTE: He never touched the existing COM+ component.

The second scenario was sending messages to an existing service that was processing messages off an MSMQ. For this he used the MSMQ Integration Channel when setting up the WCF client bindings. This sits between the WCF client and the Queue Manager on the box. It translates the WCF message into a classic MSMQ message and sends the object across the wire. The service on the other side has no reason to treat the message any differently because it is exactly in the format it expects already.

If you have a WCF service that is consuming messages off an MSMQ (or the reverse of the scenario above) it works the same way except the MSMQ Integration Channel binding takes the classic MSMQ message and translates it into a message useful to the WCF service application.

If you have two WCF applications that need to communicate over a queue then use the MSMQ Transport Channel. This uses the new WCF addressing schemes and also wraps the SOAP contents into a MSMQ message for transport across the wire.

They never turned off the original MSMQ service that was written in “legacy” code and just started sending messages to it from their new WCF client and it worked great.

A few things of note:

• They repeated several times that MSMQ was the “premier” queuing system for Windows and will be in the future as well.
• The current Peek functionality is not exposed in the WCF MSMQ implementation.
• You can’t send COM objects over the wire as an MSMQ message, but you can serialize the object to rehydrate on the other side.
• In future Vista queues, each application can have its own error queue rather than a single dead-letter queue.

I did find it interesting that the room was jammed with people and they had to open some rooms for overflow and pipe in the recorded feed. But as soon as the topic switched off the COM+ stuff to MSMQ a good number of people left.