I have the following WCF protocol bridging scenario: a WCF Client using basicHttp binding talking to a Routing Service which forwards the request to the Service using netTcp.
Client <-> basicHttpBinding (SOAP 1.1)
<–> Router Service <–> netTcpBinding (SOAP 1.2)
<–> Service
The routing functionality works perfectly until we expose the service to our C++ client that uses gSOAP library to pass messages to the service. If the C++ client communicates with the Service directly, the call succeeds; however, as soon as it tries to communicate via the Routing Service it fails.
The Service receives the routed message but throws an exception as soon as it tries to deserialize the message. The error message that is returned from the service is a System.ServiceModel.Dispatcher.NetDispatcherFaultException
saying the "The formatter threw an exception while trying to deserialize the message…"
The issue appears to be caused by the protocol bridging. If I do not use protocol bridging, i.e. I use basicHttp throughout the entire call chain, the C++ client (and the message routing) works as expected.
I cannot figure out how to resolve this issue. I understand the Routing Service is designed to be a WCF-to-WCF intermediary, but the issue appears to be isolated only to calls originating from the C++ gSOAP client. I've attemped to use some web service testing tools (soapUI, soapSonar) to see if I can replicate the issue, but they seem to work fine. Any assistance, or guidance would be appreciated.
Regards, Steve
After contacting Microsoft and with the help from Yaron Naveh, it turns out that this is a unconfirmed bug in the WCF Routing Service. For details on why the issue happens Yaron has a nice blog post which describes the issue in detail.
http://webservices20.blogspot.com/2011/01/gsoap-and-wcf-routing-services-are-not.html
Thanks to everyone who helped clarify this issue!
Regards,
Steve
UPDATE (04/03/2011): Microsoft have issued a fix for this issue. http://connect.microsoft.com/VisualStudio/feedback/details/640260/wcf-routing-services-creates-wrong-message-when-protocol-bridging-is-used
This issue also occurs when using any RPC encoded SOAP messages with different incoming and outgoing bindings. The namespace reference associated with the type definition is lost in translation. We created a service behavior extension that added the namespace reference back in manually. This was not ideal but we could not change the bindings. We have reported the problem informally to Microsoft.
Good luck