Платформа веб-сервисов по сравнению с пользовательским протоколом XML через HTTP?

Question

Я ищу конкретные рекомендации о том, когда следует использовать платформы веб-служб, в отличие от хорошо документированного пользовательского протокола, который взаимодействует с использованием XML по HTTP.

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

Пожалуйста, перечислите специфических функций , которые веб-службы приносят на стол.

Answer 1

Преимущество WS, как правило, вытекает из поддержки инструментов для создания клиентов, заглушек и дескрипторов сервера и преимуществ конвейера, таких как безопасность, шифрование и другие возможности расширения. Без инструментов бремя обработки и обработки запросов WS велико, а ценность для вашего результата относительно низка.

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

Answer 2

Я был на стороне клиента до веб-службы, которая была просто XML отправлена ​​по HTTP. Мне было довольно просто работать с ним. Я использовал JiBX для создания своих запросов XML от объекта Java и распаковал ответ XML на объект Java, используя также JiBX.

Answer 3

Мы интенсивно используем внутренние веб-сервисы между нашими производственными системами, и все они представляют собой ванильный XML-over-HTTP, без SOAP. Мы обнаружили, что громоздкая природа стеков WS, даже таких лучших, как XFire, просто не стоила этого.

Answer 4

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

Answer 5

Это классический вопрос сборки против покупки. Даже если инфраструктура бесплатна, есть инвестиции в изучение и настройку. Масштабируемая экономия для приобретенной структуры возрастает, поскольку она будет улучшена от объекта, который ее поддерживает, но вы не управляете этим процессом. Он может добавлять функции, которые вы хотите, или функции, которые нарушают ваш код, вы не можете сказать заранее. Создание себя означает время запуска и последующее обслуживание. В зависимости от вашей рабочей силы, эксперты могут двигаться дальше, и, по мере того, как код становится устаревшим, будут развиваться и знания для его поддержки. В этом вопросе есть множество плюсов и минусов, которые вы должны рассмотреть, прежде чем выбирать направление.

Answer 6

Почему вы решили заново изобрести колесо, если у вас нет проблем с производительностью или других сомнений в том, что WS не справится с работой?

Для клиента это (в большинстве случаев) будет самый простой способ использовать ваш сервис.

Файлы дескриптора должны в любом случае (по крайней мере, в мире .NET) обрабатываться с сервера.

Answer 7

RESTful веб-сервисы очень мало церемоний. Если что-то вроде Atom Publishing Protocol работает для вас, я бы выбрал этот путь.