Proxy WCF généré à partir de WSDL, la méthode proxy renvoie la valeur null

Question

J'ai généré un proxy WCF à partir d'un fichier WSDL, mais maintenant, lorsque j'appelle les méthodes proxy, elles renvoient null. J'ai activé la journalisation des messages et je peux voir que les messages du serveur sont correctement renvoyés.

J'ai vérifié la réponse de this question, mais dans mon cas au moins le nom de l'objet retourné était le même dans le message et dans le WSDL. Je crois toujours que le problème a à voir avec le fichier WSDL, car il n'est pas récupéré de la manière habituelle à travers l'URL "? Wsdl" (c'est un service web tiers), mais a été donné séparément.

Le type de retour de la méthode est juste une chaîne.

Est-ce que quelqu'un d'autre a eu des problèmes similaires, et quelle était la solution correspondante, le cas échéant? Quelle est la source la plus probable du problème?

Re-edit:

Il est un service Web RPC/encodée. Comme je l'ai écrit, je peux voir la réponse SOAP à travers la journalisation des messages, mais la WCF ne semble pas être capable d'analyser l'information.

La partie du message de la réponse du service se présente comme suit:

<ns1:ServiceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace"> 
    <ns1:ReturnValue xsi:type="xsd:string"> 

Cependant, lors de l'inspection du message sortant de mon client, il est différent:

<ns1:ServiceRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace"> 
    <RequestValue xsi:type="xsd:string" xmlns=""> 

Alors peut-être le proxy attend la réponse à avoir la même structure d'espace de noms, et échoue donc à l'analyser.

J'ai essayé de changer l'attribut type à element dans les définitions de message wsdl, et en ajoutant de nouveaux éléments dans la types partie de la définition de wsdl, mais le svcutil selfs lors de la génération du proxy, se plaignant qu'il ya un conflit entre le document de style inféré et le style spécifié rpc.

De l'WSDL specification, l'article 3.5:

Si l'utilisation est encodées, chaque partie du message fait référence à un type abstrait en utilisant l'attribut de type.

Mais alors je suis un peu confus, car il ne semble pas avoir été un problème dans ce question. Qu'est-ce qui serait nécessaire pour effectuer un changement similaire, avec la restriction qu'il s'agit d'un service RPC/codé?

Answer 1

Nous avons eu quelque chose de similaire lors de l'utilisation d'un client WCF par rapport à un WSDL d'un service Web Java.

Notre problème était que nous ne pouvions pas voir les données qui revenaient du service, il semblait que les données manquaient. Cependant, lorsque nous avons regardé ce qui se passait sur le fil, les données étaient là.

Le problème était que le WSDL avait de nombreux types hérités d'autres types. Par défaut, nous ne verrons que les informations dans le type de base.

La solution était de lancer l'objet au type que nous attendions, puis tous les champs sont apparus.

Answer 2

Vous devrez donner des détails sur le service Java afin de résoudre ce problème. Cependant, je soupçonne que le service Java utilise des parties de message définies avec l'attribut type. Ceux-ci ne sont pas conformes au profil de base WS-I 1 car il existe une ambiguïté quant à l'espace de noms à utiliser pour les éléments du message. Certains services utiliseront l'espace de noms du type, tandis que d'autres utiliseront (correctement) l'espace de noms du service Web lui-même. L'utilisation de l'attribut element supprime l'ambiguïté et est donc préférable.

Veuillez publier un extrait du fichier WSDL contenant l'un des messages que vous rencontrez. Lorsque vous comparez ensuite la définition du message avec ce que vous voyez sur le réseau, puis comparez cela aux détails de la classe proxy qui est censée consommer le message, je crois que vous verrez ce que je veux dire. La classe proxy attend un espace de nom, mais sur le réseau, un espace de noms différent est utilisé.