Разделение сервисов SOA

Question

Я хочу написать несколько веб-сервисов.

Что определяет одну единицу «обслуживания». Отмечу, что помимо одного проекта вы можете иметь несколько служебных файлов .svc.

Как вы обычно сегментируете свои услуги? Например, банковское приложение:

Хотели бы вы иметь одну услугу (.svc) для?

• Клиент
  • AddClient (Клиент newClient)
  • DeleteClient (клиент-клиент)
• Счет
  • SetName (имя строки)
  • SetType (тип AccountType)
• Передача
  • SendMoney (клиент-клиент и т. Д.)
  • ReceiveMoney (клиент-клиент и т. Д.)
• HomeLoan
  • AddNewHomeLoan (); * * тысяча тридцать шесть
  • RemoveHomeLoan

Есть ли способ группировки объектов? Например, вместо того, чтобы пользоваться услугой перевода, вы можете поместить отправку и получение денег в службу учета, поскольку вы получаете и отправляете со счетов.

Это также приводит к другому вопросу в отношении методов и параметров. Если бы я хотел добавить клиент редактирования, можно ли добавить метод, подобный EditClient (клиент-клиент, клиент newClient), и заменить весь клиент другим клиентским объектом? Или вы бы добавили отдельные методы для редактирования клиента, например: EditName (Client client, string name) в разделе Client service?

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

Answer 1

Есть несколько грубых правил, которым я хотел бы следовать при разработке веб-сервисов, особенно для незащищенных (где сервисы могут использоваться приложениями / пользователями вне определенной группы).

1. Максимальное количество рабочих единиц: веб-сервисы (на самом деле любой сервис RPC) - это еще одна часть программного обеспечения, работающая на отдельной (обычно) машине, и вам придется платить за нее (в отличие от вызова локальной функции), даже если она включена. та же машина. Имейте это в виду и создавайте функции, которые могли бы принимать как можно больше данных. Не полагайтесь на обходы между серверами для связи и выполнения бизнес-операций. Например, не иметь процесса «создать учетную запись», который требует вызова «добавить пользователя», «создать учетную запись», «связать пользователя с учетной записью», «обновить данные пользователя», «активировать учетную запись» только для завершения процесса. Вместо этого используйте функцию «createUserWithAccount», которая делает это за одну поездку.
2. Минимальное время ожидания. Помните, что эти службы называются встроенными, и если ваш процесс занимает слишком много времени, возможно, процесс может быть остановлен либо нетерпеливым пользователем, либо промежуточной службой, либо сторожевым процессом, предполагая, что произошла ошибка , Вы можете предпочесть услуги, которые возвращают «билеты», которые вызывающий абонент может проверить позже. В большинстве случаев это не является строго необходимым, но для процессов, выполнение которых может занять более минуты, может потребоваться такой подход
3. Четко определенные интерфейсы: убедитесь, что ваши сервисы имеют четко определенные и предпочтительно независимые от типа определения. Определяемый здесь тип agnostic означает, что вы используете обычные типы, которые легко связываются и имеют небольшой шанс непреднамеренных побочных эффектов для реализаторов клиента. Многие люди предпочитают использовать XML в качестве основы для передачи сообщений и скрывают все свои детали в этом.
4. План изменений: Сервисы существуют в течение длительного времени (проектно) и одновременно доступны внешним исполнителям. Это означает, что им потребуется измениться, но требования клиентов могут помешать вам сделать это легко. При создании ваших интерфейсов рассмотрите возможность создания версий или использования транспортных кодировок (таких как XML), которые позволяют изменять передаваемые данные без изменения вызывающего интерфейса. Посмотрите, как API (например, Windows API) справляются с этим, чтобы получить представление о том, как это может быть проблематично.
5. Безопасность как первоклассная цель проектирования: сервисные интерфейсы могут вызывать любой . Вы должны ожидать, что они будут вызываться всеми видами пользователей, которые могут или не могли аутентифицироваться, и могут быть или не быть вредоносными по своей природе. Планируйте безопасность в соответствующих местах и ​​не полагайтесь только на один механизм для проверки того, что все безопасно. Есть несколько способов приблизиться к безопасности, и если ваша служба используется для внутренних целей, вы можете ослабить некоторые вещи, но для общественных служб вам нужно будет подумать, как вы хотите, чтобы безопасность работала, и убедиться, что она остается согласованной во всех ваших службах.

Надеюсь, это поможет.

• Это общие стратегии, взятые у Фаулера и других. Просто мой взгляд на то, как к нему следует подходить.

Answer 2

В дополнение к отличному ответу GrayWizardx я бы добавил еще один момент.

Постарайтесь сохранить все ваши определения услуг на функциональном / бизнес-уровне. Имена сервисов должны иметь хорошие имена высокого уровня «ChangeDeliveryAddress», «QueryOrderStatus», а сами определения интерфейса должны содержать только бизнес-объекты и минимальное количество «технических» полей. полное разделение интерфейса от реализации.

Если вы обнаружите, что пользуетесь такими услугами, как «NextOrderLineWithinPage», то, вероятно, что-то пошло не так с вашим дизайном.

Answer 3

Я предпочитаю разделять свои услуги по функциям, а не по структуре. Эту технику подробно обсуждает Эрик Эванс в Domain Driven Design Одним из факторов, стоящих за этим, является скорость изменения. Функциональные области имеют тенденцию изменяться с одинаковой скоростью.

Структурный (плохой):

• Клиент
• Счет
• Loan

Функционально (хорошо):

• Billing
• Provisioning
• LoanApproval

Answer 4

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