IBM WMQ WCF Transport channel tips and tricks
Working with this transport channel now for a while, and discovered some interesting things which I’d like to share. With the transport channel I mean the “IBM.XMS.WCF.SoapJmsIbmTransportChannel” which you can find in the IBM.XMS.WCF assembly after installing WMQ 7 server or client. I’m currently using the 7.0.1.0 version.
#1 Skip SOAP/JMS over WMQ in a oneway service provider
The transport channel seemed to be tied to SOAP/JMS over WMQ. Although I discovered that you can skip this when you build a service provider.
You can set the WCF service AddressFilterMode to any: [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]. If you do this then the service can just read plain text encoded SOAP envelopes without JMS and MQHRF2 stuff. But when doing request-reply then the replies that are send back by the service will again be in the SOAP/JMS format.
#2 Oneway calls over WMQ can still block
This one is interesting: WMQ is an asynchronous transport but WCF oneway calls can still block in the scenario described here. Although I hoped that IBM did this right I was already afraid that they didn’t since the WCF channel model is a bit quirky in this area. I blogged about this before for standard WCF bindings. The difference here is that even the operation call is blocking, not the proxy.Close().
WMQ is an asynchronous transport but IBM does support request-reply in their WCF implementation by using the correlation identifier pattern: http://www.eaipatterns.com/ramblings/09_correlation.html
Microsoft doesn’t do this in their WCF MSMQ implementation. It only supports oneway, no request reply.
WCF makes a difference between servicecontracts with oneway only operations and contracts that have oneway and request-reply operations mixed.
“Oneway only”
“Mixed”
So here is where it gets interesting: in WCF the choice of channel is just made once:
“The proxy is a model of the service contract. The choice of channel type is made once against the service contract rather than on a per-operation contract basis. The channel shape with highest preference that supports all of the operations is selected.” (Nicholas Allen, Microsoft WCF Team)
So here is where it goes wrong: The IBM WMQ WCF transport channel returns an IRequestChannel (request-reply) in the case of a mixed contract .This is fine for the request-reply operations but not for the oneway operations. This results in that the service consumer call on the oneway operation (like SayHello in the sample) blocks until the service side responded. This can take a while when the service is busy, so this can cause timeouts on the service consumer side:
“WCFCH0310E: The timeout '00:01:00' was exceeeded while attempting to receive data from endpoint. The operation did not complete in the time allowed. Review the system status and configuration and increase the timeout if required.”
One of the reasons why I would pick the WMQ transport is that you have a disconnected service consumer and provider. But due to the implementation of the WCF transport and depending on how you contract look you might get different results. Microsoft doesn’t suffer from the problem with MSMQ and WCF since mixed contracts aren’t supported.
The only work around that I’m aware of if to change the mixed contract to oneway only contracts.
#3 Assured delivery does not support multiple endpoints
You can only use the assured delivery mechanism when you only have a WMQ endpoint on your service. The behaviour will crash when you also for example add an HTTP endpoint. A HTTP endpoint for just WSDL publishing is no problem. Makes sense though because for the WMQ endpoint with assured delivery you could make some promises that you don’t loose messages. You can’t make these promises for an HTTP endpoint.
#4 Sharing conversations
The “sharing conversations” setting from the WMQ connection channel trough which you connect may not be 0. In this case with channel I mean the thing on the WMQ server side to connect, has nothing to do with WCF channels. Otherwise you’ll hit some errors like “The specified value 'IBM.XMS.Client.WMQ' is not allowed for 'Expected ConnectionType = '.” or 2058 or 2059 reason codes.