Веб-сервисы, которые принимают и возвращают XML-документы - почему?

Question

Есть ли преимущества написания интерфейса веб-службы, все методы которого принимают и возвращают документы XML, а не более привычные списки параметров собственных типов и классов?

У нас есть несколько существующих веб-сервисов, которые сконструированы следующим образом. Документы XML, которые передаются их методам, обычно имеют большой размер (так как они содержат, возможно, 100 фрагментов данных, которые имеют отношение к вызовам методов). У нас есть XSD-файлы, которые мы используем для проверки XML-документов, но общее впечатление от разработчика клиента низкое и медленное. Конечно, было бы предпочтительнее иметь строго типизированный интерфейс?

Веб-службы написаны на C #, а клиенты - на C #, а также на Java (некоторые наши деловые партнеры используют Java).

Answer 1

Если вы абсолютно точно знаете, какова ваша технология конечного пользователя / клиента (например, чисто .NET и Java, где набор функций, вероятно, самый богатый), тогда непременно воспользуйтесь преимуществами строго типизированных интерфейсов, где они доступны. , Но если ваша клиентская база представляет собой смешанный пакет Perl, PHP, ASP, Python и т. Д., То я бы сделал жизнь простой и доступной для этих людей.

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

Answer 2

Другой причиной могут быть очень сложные XML-документы, которые могут быть представлены в виде классов, но это будет неудобно. Глубоко вложенные документы со многими повторяющимися элементами, например: doc.a[3].b.c[4].d[52].e, например, очень быстро утомляют.

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

Answer 3

Я когда-то слышал, чтобы сравнивать метод службы с "string xml" в / из, это сравнимо с написанием функции C # следующим образом:

public object DoSomething(object o){

}

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

Я даже видел организации, определяющие стандарты веб-услуг для страховых компаний, которые разрабатывают подобные услуги. [Вздох]

Answer 4

Несколько причин и некоторые связанные с этим мысли:

• Interoperability. Конечно, он может ускоряться с некоторыми грубыми углами, но если вы придерживаетесь простых классов, у вас не должно быть проблем. Существует также возможность сначала заключить контракт, но с другой стороны, вы должны понимать ограничения, в некоторых случаях генератор классов работает не так хорошо :(. Но даже тогда вы можете загрузить этот фрагмент как XML, вместо этого делать это для всего этого.
• Вы хотите использовать его для обработки сообщений различного типа. Эти сообщения могут быть даже агрегированы. Это не единственное решение, так как, немного поработав над определением, вы можете использовать эти сценарии в типизированных сообщениях.
• Не нужно понимать все задействованные биты, просто отправьте соответствующие кусочки в соответствующие системы. Это неотразимо, но даже тогда я не думаю, что это оправдывает не рассмотрение того, как объединить xsd для разных систем и объединить их для определения вашего веб-сервиса. Это, вероятно, должно быть сделано в любом случае.

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