Веб-служба против общей библиотеки

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Преимущества службы:

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

Ответ 3

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

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

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

Услуги

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

Ответ 4

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

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

Ответ 5

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

1. обслуживание

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

2. Библиотека

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

3. Сначала предоставьте библиотеку. Затем сервис, если возникнет необходимость.

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

4. Библиотека, которая запускает локальный сервис.

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

5. ни

   • Вы не можете серьезно оправдать даже дело библиотеки
   • ценность бизнеса сомнительна