Сервис, предоставляемый по внутренней сети. Этот сценарий описывает сервис,

используемый по внутренней сети рядом (обычно ограниченным) внутренних или корпоративных клиентов. Система электронного документооборота уровня предприятия – один из примеров такого сценария. Решения по аутентификации и авторизации должны приниматься, исходя из границ доверия во внутренней сети и типов учетных данных. Например, аутентификация Windows с применением Active Directory для хранения пользовательских данных является более вероятным для интранет-сценария, чем для Интернет-сценария.

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

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

Общие принципы проектирования

При проектировании сервисных приложений необходимо следовать общим рекомендациям, применимым ко всем сервисам. Такими рекомендациями являются проектирование слабо детализированных операций, следование контракту сервиса и готовность к возможному поступлению недействительных запросов или запросов в неверном порядке. Кроме общих рекомендаций, есть специальные рекомендации, которых следует придерживаться при проектировании разных типов сервисов. Например, для Сервисно-ориентированной архитектуры (SOA) необходимо обеспечить стабильность контракта приложения и автономность сервиса. Либо может создаваться приложение, предоставляющее сервисы рабочего процесса, или хранилище операционных данных, обеспечивающее основанный на сервисе интерфейс. При проектировании сервисных приложений руководствуйтесь следующими рекомендациями:

Используйте многослойный подход и избегайте тесного связывания слоев. По возможности распределяйте бизнес-правила и функции доступа к данным по разным компонентам. Обеспечивайте интерфейс бизнес-слоя через абстракцию, которая может быть реализована путем использования открытых интерфейсов объектов, общих описаний интерфейсов, абстрактных базовых классов или через обмен сообщениями. Более подробно абстракция в многослойной архитектуре рассматривается в главе 5, «Рекомендации по проектированию многослойных приложений».

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

шаблона Façade позволит объединять несколько небольших детализированных операций в одну слабо детализированную операцию. Например, для статистических данных необходимо обеспечить операцию, которая будет возвращать все данные за один вызов, чтобы не приходилось делать множество вызовов, каждый из которых будет возвращать лишь подмножество данных.

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

При проектировании строго придерживайтесь контракта сервиса. Слой сервисов должен реализовывать и обеспечивать только ту функциональность, которая оговорена контрактом сервиса, внутренняя реализация и детали сервиса никогда не должны предоставляться потребителям. Также если необходимо изменить контракт сервиса для включения в него новой функциональности, реализованной сервисом, и новые операции и типы не являются обратно совместимыми с существующими контрактами, создавайте новые версии контрактов. Описывайте новые операции, предоставляемые сервисом, в новой версии контракта сервиса и новые типы схем – в новой версии контракта данных. Проектирование контрактов сообщений рассматривается в главе 18, «Взаимодействие и обмен сообщениями».

Проектируйте автономные сервисы. Сервисы не должны предъявлять никаких требований к их потребителям и не должны делать никаких предположений о потребителе или о том, как он планирует использовать предоставляемый сервис.

При проектировании должна быть учтена возможность поступления недействительных запросов. Никогда не делайте предположения о том, что все поступающие на сервис сообщения будут действительными. Реализуйте логику валидации для проверки всех сообщений на соответствие схемам; и отвергайте или очищайте все недействительные сообщения. Более подробно валидация рассматривается в главе 17, «Сквозная функциональность». Обеспечьте сервису возможность выявлять и правильно обрабатывать повторные сообщения (идемпотентность) путем реализации широко известных шаблонов или через использование сервисов инфраструктуры. Кроме того, сервис должен уметь обрабатывать сообщения, поступающие в произвольном порядке (коммутативность). Это можно сделать, реализуя дизайн, позволяющий сохранять сообщения и затем обрабатывать их в правильном порядке.

Сервисы должны управляться на основе политик и иметь явные границы.

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

обеспечить потребителям возможность проверять политику и требования для взаимодействия.

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

Размещайте основные компоненты слоя сервисов в отдельных сборках. Например,

интерфейс, реализация, контракты данных, контракты сервисов, контракты сбоев и трансляторы – каждый из них должен размещаться в собственной сборке.

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

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

Специальные вопросы проектирования

В следующих разделах предлагаются рекомендации, которые помогут разрешить общие проблемы, возникающие при разработке архитектуры сервисов:

Аутентификация

Авторизация

Бизнес-слой

Сетевое взаимодействие

Слой доступа к данным

Управление исключениями

Структура сообщения

Конечная точка сообщения

Защита сообщений

Преобразование сообщений

Шаблоны обмена сообщениями

Передача репрезентативного состояния

Слой сервисов

SOAP

Валидация

Аутентификация

Стратегия аутентификации сервиса зависит от используемого типа хоста для сервиса. Например, если сервис размещен в Internet Information Services (IIS), можно использовать поддержку аутентификации, предоставляемую IIS. Если сервис размещается с применением Windows Service, должна использоваться аутентификация на основе сообщений или транспорта. При проектировании стратегии аутентификации руководствуйтесь следующими рекомендациями:

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

Учтите последствия применения разных параметров доверия для выполнения кода сервиса.

С обычной аутентификацией или при передаче учетных данных в виде простого текста должны использоваться безопасные протоколы, такие как Secure Sockets Layer (SSL). С SOAP-сообщениями применяйте такие механизмы обеспечения безопасности,

как Web Services Security1 (WS-Security).

Авторизация

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

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

Для защиты URL и файловых ресурсов используйте авторизацию на базе Унифицированного указателя ресурса (Uniform Resource Locator, URL) и/или авторизацию доступа к файлам.

1 Безопасность Веб-сервисов (прим. переводчика).