2010-11-03 7 views
1

J'ai le scénario de pontage de protocole WCF suivant: un client WCF utilisant la liaison basicHttp parlant à un service de routage qui transmet la demande au service en utilisant netTcp.WCF 4 Routing Service - problème de pontage de protocole

client < ->basicHttpBinding (SOAP 1.1) < ->Service Router < ->netTcpBinding (SOAP 1.2) < ->service

La fonctionnalité de routage fonctionne parfaitement jusqu'à ce que nous exposons le service à notre client C++ qui utilise la bibliothèque gSOAP pour transmettre des messages au service. Si le client C++ communique directement avec le service, l'appel réussit; Cependant, dès qu'il essaie de communiquer via le service de routage, il échoue.

Le service reçoit le message routé mais lance une exception dès qu'il tente de désérialiser le message. Le message d'erreur renvoyé par le service est un System.ServiceModel.Dispatcher.NetDispatcherFaultException indiquant le "The formatter threw an exception while trying to deserialize the message…"

Le problème semble provoqué par le pontage de protocole. Si je n'utilise pas de pontage de protocole, c'est-à-dire que j'utilise basicHttp tout au long de la chaîne d'appel, le client C++ (et le routage des messages) fonctionne comme prévu.

Je n'arrive pas à résoudre ce problème. Je comprends que le service de routage est conçu pour être un intermédiaire WCF-WCF, mais le problème semble être isolé uniquement pour les appels provenant du client gSOAP C++. J'ai essayé d'utiliser certains outils de test de service Web (soapUI, soapSonar) pour voir si je peux répliquer le problème, mais ils semblent fonctionner correctement. Toute aide ou conseil serait apprécié.

Cordialement, Steve

+0

Quel est le message d'exception/trace de la pile? Toute exception interne? –

+0

Il n'y avait pas d'exception interne. Nous avons partiellement identifié le problème, mais je ne sais toujours pas pourquoi cela se produit, à part le fait que gSOAP ne joue évidemment pas bien avec netTCPBinding.Nous avons résolu ce problème en utilisant basicHttpBinding tout au long de la chaîne d'appel. Pas idéal du point de vue de la performance, mais nous avons au moins une fonctionnalité cohérente pour tous les clients du service. – stephenl

Répondre

2

Après avoir contacté Microsoft et avec l'aide de Yaron Naveh, il se trouve que c'est un bug non confirmé dans le service d'acheminement WCF. Pour plus de détails sur les raisons de ce problème, Yaron a publié un blog qui décrit le problème en détail.

http://webservices20.blogspot.com/2011/01/gsoap-and-wcf-routing-services-are-not.html

Merci à tous ceux qui ont aidé à clarifier cette question!

Cordialement,

Steve

UPDATE (04/03/2011): Microsoft ont publié un correctif pour ce problème. http://connect.microsoft.com/VisualStudio/feedback/details/640260/wcf-routing-services-creates-wrong-message-when-protocol-bridging-is-used

0

Ce problème se produit également lors de l'utilisation de n'importe quel message SOAP codé RPC avec différentes liaisons entrantes et sortantes. La référence d'espace de noms associée à la définition de type est perdue dans la traduction. Nous avons créé une extension de comportement de service qui a ajouté manuellement la référence d'espace de noms. Ce n'était pas idéal mais nous n'avons pas pu changer les fixations. Nous avons signalé le problème de manière informelle à Microsoft.

Bonne chance

+2

Vous pourriez être intéressé de savoir que Microsoft a publié un correctif pour ce problème ici: [http://connect.microsoft.com/VisualStudio/feedback/details/640260/wcf-routing-services-creates-wrong-message-when -protocol-bridge-is-used] (http://connect.microsoft.com/VisualStudio/feedback/details/640260/wcf-routing-services-creates-wrong-message-when-protocol-bridging-is-) . – stephenl