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

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

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

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

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

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

Ответ 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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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