Написание С#-клиента для использования веб-службы Java, которая возвращает массив объектов

Я пишу клиент С#, который вызывает веб-сервис, написанный на Java (другим человеком). Я добавил веб-ссылку на мой клиент, и я могу вызвать методы в веб-сервисе в порядке.

Служба была изменена, чтобы возвращать массив объектов, и клиент неправильно обрабатывает возвращенное сообщение SOAP.

MyResponse[] MyFunc(string p)

class MyResponse
{
    long id;
    string reason;
}

Когда мой сгенерированный прокси С# вызывает веб-службу (используя SoapHttpClientProtocol.Invoke), я ожидаю массив MyResponse [] с длиной 1, т.е. один элемент. То, что я получаю после вызова Invoke, - это элемент с id = 0 и reason = null, независимо от того, что фактически возвращает служба. Используя сниффер пакетов, я вижу, что служба возвращает то, что кажется законным мыльным сообщением с идентификатором и причиной, установленной для ненулевых значений.

Есть ли какой-то трюк, чтобы заставить клиент С# вызывать веб-службу Java, которая возвращает someobject []? Я буду работать над получением дезинфицированной демонстрации, если это необходимо.

Изменить. Это веб-ссылка через "Добавить веб-ссылку...". VS 2005,.NET 3.0.

Ответ 1

Прошло некоторое время, но я, похоже, помню, что у меня были проблемы с небольшими различиями в том, как пространство имен было обработано между веб-службами .NET и Java.

Дважды проверьте сгенерированный класс прокси-сервера С# и любые пространства имен, объявленные внутри (особенно по умолчанию xmlns = ""), против ожидаемого Java-сервиса. Вероятно, будут очень тонкие различия, которые вам придется воссоздать.

Если это так, вы должны предоставить больше объявлений пространства имен в атрибутах С#.

Ответ 2

Благодаря Xian, у меня есть решение.

В wsdl для службы была включена строка

<import namespace="http://mynamespace.company.com"/>

Мыло, отправленное клиенту на сервер, имело следующий атрибут для всех элементов данных:

xmlns="http://mynamespace.company.com"

Но полезная нагрузка xml ответа (от службы обратно клиенту) не включала это пространство имен. Погрузившись с ответом HTTP (который я получил с помощью WireShark), я заметил, что класс .NET proxy правильно взял значения MyResponse, если я принудительно присвоил атрибут xmlns для каждого возвращаемого элемента данных.

За исключением изменения службы, которую я не контролирую, обходным путем является изменение созданного VS-прокси-класса (например, Reference.cs) и поиск таких строк:

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://mynamespace.company.com")]
public partial class MyResponse {

и закомментируйте строку атрибута XmlType. Это укажет CLR на поиск элементов ответа в пространстве имен по умолчанию, а не на том, что указано в wsdl. Вы должны повторить это, когда будете обновлять ссылку, но, по крайней мере, она работает.

Ответ 3

Из вашего вопроса, похоже, что у вас был клиент, работающий в один момент, а затем служба была изменена, чтобы вернуть массив. Убедитесь, что вы повторно создаете прокси-сервер, чтобы возвращаемое SOAP-сообщение было десериализовано на клиенте. Не ясно, что вы это сделали - просто убедитесь.