Когда не следует использовать веб-сервис?

Question

Использование веб-службы часто является отличным архитектурным подходом. И с появлением WCF в .Net ситуация становится еще лучше.

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

Я имею в виду небольшие интранет-приложения с несколькими десятками пользователей. Веб-приложение и его веб-служба развернуты на одном веб-сервере, а не на веб-ферме. В будущем не будет другого веб-приложения, которое могло бы использовать этот конкретный веб-сервис. Мне кажется, что стоимость вызова веб-службы излишне увеличивает нагрузку на веб-сервер. Производительность снижается при обработке вызовов. Поддержка и отладка кода для веб-приложения и веб-службы более сложна. Так же как и развертывание. Я просто не вижу преимуществ использования веб-сервиса здесь.

Можно проверить это, создав две версии веб-приложения, с веб-службой и без нее, и провести стресс-тестирование, но я этого не сделал.

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

Answer 1

Веб-сервисы - абсолютно ужасный выбор для доступа к данным. Это тонна накладных расходов и сложности для почти нулевой выгоды.

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

В некоторых случаях я бы порекомендовал веб-сервисы (и я предполагаю, что вы имеете в виду SOAP), но это в основном для совместимости.

Здесь также обсуждается гранулярность услуг. Сервис в смысле SOA будет инкапсулировать операцию или бизнес-процесс. Методы доступа к данным являются лишь частью этого процесса.

Другими словами:

  - someService.SaveOrder(order);  // <-- bad
    // some other code for shipping, charging, emailing, etc

  - someService.FulfillOrder(order);  //<-- better
    //the service encapsulates the entire process

Веб-сервисы ради веб-сервисов - это безответственное программирование.

Answer 2

Ник Харрисон, блестящий разработчик в Шарлотте, предложил следующие сценарии, в которых использование веб-службы имеет смысл:

• В веб-ферме, где есть несколько веб-серверов, на которых размещены веб-сайты, все они указывают на веб-службы, работающие на другом веб-сервере. Это позволяет распределить нагрузку по нескольким серверам.
• Клиент / сервер, где приложения Windows Form могут вызывать веб-службу.
• Кроссплатформенный
• Проходя через брандмауэр

Answer 3

Тот факт, что инструмент генерирует кучу заглушек, не означает, что он полезен. WS- * превосходен в тех случаях, когда вы предоставляете услуги внешним сторонам. Это означает, что каждая операция должна быть на гранулярности бизнес-процесса, а не на доступ к данным.

Множество стандартов могут быть использованы для подробного описания различных аспектов вашего контракта, а (гипотетический) полностью совместимый стек WS может отнять у сторонних разработчиков много боли и даже разрешить объединение «точки и щелчки». a'la Yahoo Pipes. С помощью эффективного управления вы можете развивать свой публичный интерфейс и управлять обратной совместимостью по мере необходимости.

Все это почти невозможно создать автоматически. Генератор заглушек C # знает только физический интерфейс вашего класса, но не имеет представления о задействованной семантике. См. этот документ для более подробного обсуждения.

Если вы создаете веб-сайт, то создайте веб-сайт. Если вы хотите использовать асинхронный обмен сообщениями внутри приложения, используйте MSMQ . Если вы хотите предоставить данные внутренним клиентам, используйте POX . Если вам нужен эффективный двоичный формат сообщения, проверьте Google Protocol Buffers или если вам нужна RPC-проверка Hessian для C # или DCOM.

Веб-сервисы - это грубое интеграционное решение. Они жесткие, они медленнее, чем альтернативы, они требуют слишком много усилий, чтобы преуспеть (а если не сделали хорошо, то почти бессмысленны).

Подводя итог: "Когда следует использовать веб-сервис , а не ?" - в любое время вы можете уйти без него

Answer 4

Если вы просто кодируете крошечное (менее 50 пользователей) веб-приложение для своей интрасети, веб-служба кажется излишней. Особенно, если его основная функция (предоставление единой точки доступа ко многим службам) не будет использоваться.

Answer 5

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

Однако не использует веб-службы в следующих сценариях:

• Когда вы должны использовать Http в качестве транспорта и сериализации XML ваших данных, и вам нужно много разных бит данных, синхронно и часто. Будь то REST, SOAP или WS- * у вас будут проблемы с производительностью. Чем больше звонков вы сделаете, тем медленнее будет ваша система. Если вы хотите, чтобы куски данных среднего размера использовались реже, асинхронно, и вы можете использовать прямой TcpIp (например, Wcf netTcpBinding), вам лучше.
• Когда вам нужно запрашивать данные из вашего веб-сервиса и объединять их с другими источниками данных, лучше мотивируйте хранилище данных, которое может быть заполнено должным образом консолидированными и рационализированными данными со всего предприятия

Это мой опыт, надеюсь, он поможет.

Answer 6

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

Answer 7

Для небольшого веб-приложения (хотя вы должны задать вопрос: «Всегда ли оно останется мелким?») Использование веб-сервисов, отдельных бизнес-уровней, слоев данных и т. Д. И т. Д. Может быть излишним.

Прежде чем кто-нибудь застрелит меня, я согласен с тем, что разделение логики между слоями наряду с юнит-тестами, непрерывной интеграцией и т. Д. Чертовски блестяще. В моей нынешней роли я был бы совершенно потерян и раскачивался в углу без них. Однако для очень небольшого веб-приложения, используемого, например, для отслеживания контактных номеров и адресов для компании из 36 сотрудников, анализ затрат / выгод показал бы, что все перечисленные выше «тонкости» были бы излишними.

Однако ... Не забудьте задать вопрос "Всегда ли он останется мелким?" : -)