Ссылка на службу C # Java -> C#

#c# #java #service #wsdl

#c# #java #Обслуживание #wsdl

Вопрос:

Сначала позвольте мне сказать, что это не идеальная ситуация. У меня нет копии оригинального WSDL, чтобы определить, что изменилось; Я также работаю с разработчиками через стену, которые не могут помочь. Мое приложение разработано в Visual Studio 2010, использующее конечную точку службы, написанную на Java.

У меня есть приложение на C #, у которого есть ссылка на службу, я буду называть его произвольным виджетом. Виджет имеет метод DoWork, который принимает четыре аргумента: argument01, argument02, argument03 и argument04.

Сигнатура метода моего сгенерированного кода на C # такова

 public DoWorkResponse DoWork(string argument01, int argument02, bool argument03, int argument04)

Недавно был добавлен новый метод, и мне сказали обновить мою ссылку. Когда я это сделал, моя подпись изменилась с приведенной выше на:

 public DoWorkResponse DoWork(DoWork DoWork1)

где DoWork

 partial class DoWork
{
    string argument01;

    int argument02;

    bool argument03;

    int argument04;

}

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

Итак, в основном я ищу некоторое представление о том, что могло измениться на стороне Java, чтобы заставить Visual Studio генерировать иначе, чем раньше.

Заранее спасибо!

1. Похоже DoWork , что метод был переработан одновременно с добавлением нового метода.

2.Это была и моя мысль, но разработчик, который изначально написал конечную точку, больше не работает в штате, а назначенный ему боится вникать в это, опасаясь взлома черного ящика. Я почти уверен, что это часть wsdl, которая вызывает проблемы. <xs:element name="DoWork"> <xs:complexType> <xs:sequence>

3. @clichekiller Вы говорите, что могло измениться на стороне Java, чтобы заставить Visual Studio генерировать иначе, чем раньше . В этом нет «might»; в какой-то момент сигнатура метода, предоставленного службой, была изменена, и служба была перекомпилирована / перераспределена. Это изменение могло произойти до добавления нового метода, но оно не было развернуто на сервере до недавних изменений.

Ответ №1:

Возможно parameterStyle , элемент аннотации SOAPBinding был изменен, сделав стиль параметра пустым, а не обернутым. Они могли бы попробовать добавить это в свое определение службы:

 @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)

Возможно, их версия SOAP также изменилась. Я не эксперт в веб-службах Java, но это обсуждение является информативным как для веб-служб SOAP, так и для Java.

Если они не могут или не хотят вносить эти изменения со своей стороны, вы можете иметь некоторый контроль над привязками на стороне клиента. См. Раздел Поддержка форматов SOAP в .NET Framework. В принципе, вы можете создавать свои классы из WSDL, используя дополнительные параметры командной строки с wsdl.exe .

С другой стороны, разве у них нет управления версиями в их исходном коде? Конечно, их история будет отражать, какие изменения они внесли в свою службу или параметры.

1. Я был бы удивлен, если бы на их стороне не было контроля версий, вероятно, subversion, но у меня нет к нему доступа, и они, к сожалению, не появятся. Это просто расстраивает, потому что это не первый раз, когда у меня менялись контракты. Я всегда думал о wsdl как о контрактах, их можно было расширять, но их нельзя было изменять; здесь не так много, но вы знаете, как это происходит. Спасибо за понимание.