Прокси WCF, сгенерированный из WSDL, метод прокси возвращает ноль

Question

Я сгенерировал прокси WCF из файла WSDL, но теперь, когда я вызываю прокси-методы, они возвращают ноль. Я включил ведение журнала сообщений и вижу, что сообщения с сервера возвращаются правильно.

Я проверил ответ на этот вопрос, но в моем случае, по крайней мере, имя возвращаемого объекта было одинаковым в сообщении и в WSDL. Я по-прежнему считаю, что проблема связана с файлом WSDL, поскольку он не извлекается обычным способом через URL-адрес «? Wsdl» (это сторонний веб-сервис), а предоставляется отдельно.

Тип возвращаемого значения метода - просто строка.

У кого-нибудь еще были подобные проблемы, и какое было соответствующее решение, если таковое было? Каков наиболее вероятный источник проблемы?

Re-редактирование:

Это RPC / закодированный веб-сервис. Как написано, я вижу ответ SOAP через ведение журнала сообщений, но WCF, похоже, не в состоянии проанализировать информацию.

Часть сообщения ответа службы выглядит следующим образом:

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

Однако, при проверке исходящего сообщения от моего клиента, все по-другому:

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

Так что, возможно, прокси-сервер ожидает, что ответ будет иметь такую ​​же структуру пространства имен, и, следовательно, не сможет его проанализировать.

Я попытался изменить атрибут type на element в определениях сообщений wsdl и добавить некоторые новые элементы в часть types определения wsdl, но затем svcutil задыхается при генерации прокси, с жалобой на конфликт между предполагаемым стилем документа и указанным стилем rpc.

Из спецификации WSDL , раздел 3.5:

Если используется кодировка , то каждая часть сообщения ссылается на абстрактный тип с использованием атрибута type .

Но тогда я немного сбит с толку, поскольку в этом вопросе это, похоже, не было проблемой. Что потребуется для внесения аналогичного изменения с ограничением, что это RPC / кодированный сервис?

Answer 1

Чтобы решить эту проблему, вам нужно будет указать особенности службы Java. Однако я подозреваю, что служба Java использует части сообщения, определенные с атрибутом type. Они не соответствуют Основному профилю 1 WS-I, поскольку существует неоднозначность того, какое пространство имен следует использовать для элементов сообщения. Некоторые службы будут использовать пространство имен этого типа, в то время как другие будут (правильно) использовать пространство имен самого веб-сервиса.

Использование атрибута element устраняет неоднозначность и поэтому является предпочтительным.

Пожалуйста, опубликуйте фрагмент WSDL, содержащий одно из сообщений, с которыми у вас возникли проблемы. Затем, когда вы сравните определение сообщения с тем, что видите на проводе, а затем сравните его с подробностями прокси-класса, который предназначен для использования сообщения, я полагаю, вы поймете, что я имею в виду. Прокси-класс ожидает одно пространство имен, но в сети используется другое пространство имен.

Answer 2

У нас было нечто подобное при использовании клиента WCF против WSDL из веб-службы Java.

Наша проблема заключалась в том, что мы не могли видеть данные, которые возвращались из службы, казалось, что данные отсутствовали.

Однако, когда мы смотрели на то, что происходит по проводам, данные были там.

Проблема заключалась в том, что WSDL имел много типов, унаследованных от других типов. По умолчанию мы видим информацию только в базовом типе.

Решением было привести объект к ожидаемому типу, после чего появились все поля.