Написание клиента C # для использования веб-службы Java, которая возвращает массив объектов - PullRequest
10 голосов
/ 15 сентября 2008

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

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

MyResponse[] MyFunc(string p)

class MyResponse
{
    long id;
    string reason;
}

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

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

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

Ответы [ 3 ]

8 голосов
/ 16 сентября 2008

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

В wsdl для услуги включена строка

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

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

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

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

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

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

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

3 голосов
/ 15 сентября 2008

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

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

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

0 голосов
/ 15 сентября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...