Веб-сервис против общей библиотеки - PullRequest
13 голосов
/ 21 августа 2009

Этот вопрос был задан несколько раз на SO из того, что я нашел:

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

Ответы помогли, но они оба немного указывали на конкретный сценарий. Я хотел получить более общую мысль об этом.

Когда следует рассматривать веб-службу поверх общей библиотеки (DLL) и наоборот?

Ответы [ 5 ]

12 голосов
/ 21 августа 2009

Моя мысль об этом:

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

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

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

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

А как насчет общей библиотеки?

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

Примеры того, когда использовать:

В вашем контроле много приложений, размещенных на одном или двух серверах, которые будут использовать библиотеку.

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

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

Вы пишете что-то, что используется только ограниченным набором приложений, возможно, некоторыми вспомогательными функциями. Библиотека.

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

Если бы все были равны, было бы легче начать с общей библиотеки и превратить ее в веб-сервис, но не так сильно наоборот.

Есть еще много, но это некоторые из моих мыслей об этом ...

7 голосов
/ 13 февраля 2013

Преимущества библиотеки:

Преимущества обслуживания:

  • Каждый получает обновления немедленно и прозрачно (если не предлагается версионный API)
  • Потребители не могут декомпилировать код
  • Может масштабировать сервисное оборудование отдельно
  • Технология агностика. При использовании совместно используемой библиотеки потребители должны использовать совместимую технологию.
  • Более безопасный. Уровень пользовательского интерфейса может вызывать службу, которая находится за брандмауэром, вместо прямого доступа к БД.
4 голосов
/ 11 мая 2011

На основе нескольких источников ...

Общая общая библиотека

  1. Должен предоставлять набор хорошо известных операций, выполняющих общие задачи (например, анализ строки, числовые манипуляции, компоновщики)
  2. Должен инкапсулировать общий код многократного использования
  3. иметь минимальные зависимости от других библиотек
  4. Обеспечение стабильных интерфейсов

Услуга

  1. Должен предоставить многократно используемые компоненты приложения
  2. Предоставление общих бизнес-услуг (например, расчет нормы прибыли, отчеты о производительности или услуги по истории транзакций)
  3. Может использоваться для подключения существующего программного обеспечения из разрозненных систем или обмена данными между приложениями
1 голос
/ 17 мая 2019

Вот 5 вариантов и причины их использования.

  1. Услуга

    • имеет постоянное состояние
    • вам нужно часто выпускать обновления
    • решает главную бизнес-проблему и владеет данными, связанными с ней
    • нужна безопасность: пользователь не может видеть ваш код, пользователь не может получить доступ к вашему хранилищу
    • нужен независимый интерфейс, такой как REST (вы можете автоматически создавать мелкие клиенты REST для клиентских языков)
    • нужно масштабировать отдельно
  2. Библиотека

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

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

    • многим приложениям на хосте необходимо подключиться к нему и отправить на него некоторые данные
  5. Ни

    • Вы не можете серьезно оправдать даже дело библиотеки
    • ценность для бизнеса сомнительна
0 голосов
/ 19 июля 2018

В идеале, если мне нужны оба преимущества, мне понадобится портативная библиотека с автоматическим клеем интерфейса, автоматически обновляемая, с запутанной (трудно декомпилируемой) или защищенной внутренней средой.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...