Какие good practice почитать по написанию WSDL на C#?

Question

[QuAzI]

Есть веб-сервис, который активно ломается/меняется/развивается, соответственно танцуем по граблям, набиваем шишки, хочется как-то развития. Все почитайки про WSDL описывают довольно общие вещи, хочется больше конкретики, что, зачем и как стоит делать, чтобы веб-сервис был нормально жил с разными версиями API, на больших нагрузках

Answer 1

[Сергей Протько]

good practice почитать по написанию WSDL на C#

вот вам good practice - не пишите WSDL руками.

Comments

[QuAzI]

Носом пока не получается :( ну или дайте больше конкретики - чем писать

[Сергей Протько]

QuAzI: конкретика, в контексте c# его вам генерят из атрибутов

[pi314]

Вот вам best practice - если возможно, вообще откажитесь от него в пользу REST. По хорошему, вебсервисы на SOAP существуют до сих пор только потому, что стандарт настолько монстрозный, что нет такой большой помойки, на которую его можно было бы выкинуть :)
Если такой возможности нет, то, конечно, генерируйте, но все равно не удивляйтесь, когда полезут грабли несовместимости MS и Java стеков. Ну и, разумеется, www.soapui.org Вам в помощь :)

[QuAzI]

pi314: да, SoapUI классный, если не считать UI =) по поводу остального хотелось бы пруфов, т.е. более чёткого обоснования. Потенциально, конечно, хотелось бы стек без проблем с переносимостью, но пока упор именно на WSDL.
Но опять же, ни одного совета более конкретного или ссылки на литературу. Например слышал что обязательно все параметры передавать как класс, мол если добавится параметр, то не будет смертельно для старых клиентов, мол для новых атрибутов просто выставится значение по умолчанию. Вот такого плана хотелось бы советов, а тут вода одна в комментариях

[pi314]

QuAzI: Приведенный в качестве примера совет, к сожалению, далеко не универсален. Такое расширение списка параметров может прокатить в какой-то конкретной имплементации, но для большинства (мне известных) изменение сигнатуры метода повлечет за собой как минимум генерирование и компиляцию новых классов на клиенте. Для "старых" клиентов придется поддерживать "старую" версию интерфейса, и таких версий наплодится со временем немало.
И так - со всем. Именно поэтому практически невозможно дать какие-то конкретные советы - все "тонкости" слишком сильно завязаны на конкретную имплементацию. Все грабли совместимости - соответственно, на пару имплементаций. Если у Вас есть конкретные сомнения или проблемы - спрашивайте. А иначе тут пришлось бы написать средней толщины учебник, который все равно останется неполным :)

[pi314]

QuAzI: А аргументация, почему SOAP и WSDL на сегодня скорее зло, чем добро, достаточно прозрачна. Эта технология подразумевает принудительную статическую зависимость между соединяемыми системами, и делает это ценой очень большой сложности. Это было вершиной технической мысли в 90х, но с тех пор отрасль сильно шагнула вперед, обзавелась языками с динамической типизацией, более компактными (по сравнению с ХМL) форматами сериализации, и т.д... и технология морально устарела.