Один большой веб-сервис или много маленьких?

Question

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

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

Если это влияет на ответы, которые я использую .Net 3.5, C# и не могу использовать WCF на данный момент.

Answer 1

Один большой
Плюсы:

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

Минусы:

• Если вы когда-либо обновления 1 подпись, клиенты должны добавить, что огромный ссылку и перечитать WSDL (?).
• Сложнее делегировать работу, если присутствует множество клиентов.

Lotsa маленькие
Pros:

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

• Легче использовать разные хосты.

Минусы:

• Может легко перерасти в беспорядок.

Мой совет - посмотреть на логические пакеты ваших услуг. Клиенты могут использовать часть ваших услуг или все из них? Существуют ли случаи, когда им нужно будет использовать половину службы №1 и половину службы №2? Попытайтесь выяснить, каковы общие сценарии, и спроектируйте свои службы, чтобы им нужно было создать только один прокси-сервер для его работы.

Answer 2

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

Рэнди

Answer 3

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

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

Вы можете сделать аргументы для обоих случаев. Два самых больших вопроса, которые у меня были бы: 1) Связаны ли эти услуги? Имеет ли смысл группировать их вместе или просто группировать их для удобства? Если они связаны друг с другом, может иметь смысл держать их вместе.

2) Какую нагрузку вы ожидаете? Можете ли вы реально ожидать, что один сервер будет обрабатывать нагрузку на все услуги в течение следующих нескольких лет? Если нет, возможно, лучше разбить их сейчас.

Answer 4

Некоторая пища для размышлений: гранулы хороши для большего контроля, но у этого есть связанная с этим штрафная сила. Если вы идете также , вы можете получить API, который потребует нескольких сетевых поездок, чтобы сделать что-то нетривиальным. Поэтому при проектировании службы я буду поддерживать связь в сети и задержка. Если служба должна быть потенциально расположена через глобальную сеть, я бы воздержался от создания «чатного» интерфейса и перешел на методы, которые возвращают больше данных.

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