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

Я пишу клиент 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.

Вы используете «Добавить веб-ссылку» (.NET 2.0) или «Добавить ссылку на службу» (.NET 3.0)?

Mark Cidade 15.09.2008 21:19
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
10
1
24 430
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Ответ принят как подходящий

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

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

В этом случае вы должны предоставить дополнительные объявления пространств имен в атрибутах C#.

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

Ваше понимание правильное. Это работало до тех пор, пока я не добавил метод, возвращающий MyResponse []. Я обновил ссылку и прокси перестроили.

David Chappelle 16.09.2008 00:30

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

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. Вы должны повторять это всякий раз, когда обновляете ссылку, но, по крайней мере, это работает.

Спасибо, что разместили свое решение, оно вернуло море воспоминаний!

Xian 25.09.2008 01:22

Другие вопросы по теме