Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

связанные с обменом сообщениями. Основное, на что требуется обратить внимание: сервисы

взаимодействуют посредством обмена сообщениями, как правило, по сети, что по сути своей

медленнее, чем прямое взаимодействие внутри процесса, и обычно сервисы взаимодействуют

с потребителями асинхронно. Кроме того, сообщения, передаваемые между сервисом и

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

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

гарантированной доставки. Все эти аспекты требуют создания дизайна, в котором будет учтено

такое недетерминированное поведение процесса обмена сообщениями. При проектировании

слоя сервисов руководствуйтесь следующими рекомендациями:

 Проектируйте сервисы, областью действия которых является приложение, а не

компонент. Операции сервисов должны охватывать большие фрагменты

функциональности и сосредотачиваться на операциях приложения.

Проектирование слишком узконаправленных операций может иметь негативное

влияние на производительность и масштабируемость. Тем не менее, необходимо

обеспечить, чтобы сервис не возвращал неограниченно большие объемы данных.

Например, для сервиса, который может возвращать большие объемы

демографических данных, необходимо создать операцию, которая будет

возвращать не все данные за один вызов, а подмножества данных определенного

размера. Размер подмножества данных должен соответствовать возможностям

сервиса и требованиям его потребителей.

 Проектируйте расширяемые сервисы и контракты данных, не делая допущений о

предполагаемом клиенте. Иначе говоря, контракты данных должны быть

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

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

поддержки изменений, не обладающих обратной совместимостью, возможно,

придется создавать новые версии интерфейса сервиса, которые будут

функционировать параллельно с существующими версиями. Нельзя делать

предположения о клиентах или о том, как они планируют использовать

предоставляемый сервис.

 Проектируйте только соответственно контракту сервиса. Слой сервисов должен

реализовывать и обеспечивать только функциональность, оговоренную контрактом

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

внешним потребителям. Также если возникает необходимость изменить контракт

сервиса для включения новой функциональности, реализованной сервисом, и

новые операции и типы не являются обратно совместимыми с существующими

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

новые операции, предоставляемые сервисом в новой версии контракта сервиса, и

новые типы передаваемых сообщений в новой версии контракта данных.

Проектирование контрактов сообщений рассматривается в главе 18,

«Взаимодействие и обмен сообщениями».

 Отделяйте функциональность слоя сервиса от функциональности

инфраструктуры. В слое сервисов реализация сквозной функциональность не

должен сочетаться с кодом логики сервиса, поскольку это может усложнить

расширение и обслуживание реализаций. Обычно сквозная функциональности

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

 Создавайте сущности из стандартных элементов. По возможности компонуйте

сложные типы и объекты передачи данных, используемые сервисом, из

стандартных элементов.

 При проектировании учитывайте возможность поступления некорректных

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

сервис сообщения будут корректными. Реализуйте логику валидации всех входных

данных на основании значений, диапазонов и типов данных, и отклоняйте

недопустимые данные. Более подробно валидация рассматривается в главе 17,

«Сквозная функциональность».

 Обеспечьте в сервисе функциональность для выявления и обработки

повторяющихся сообщений (идемпотентность). Реализация широко известных

шаблонов, таких как Receiver и Replay Protection, при проектировании сервиса

обеспечит, что дублирующие сообщения не будут обрабатываться, или что

повторная обработка не будет влиять на результат.

 Проектируйте сервис, чтобы он мог обрабатывать сообщения, поступающие в

произвольном порядке (коммутативность). Если существует вероятность

поступления сообщений в порядке, отличном от того, в котором они отправлялись,

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

правильном порядке.

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

Существует ряд общих вопросов, на которые следует обратить внимание при проектировании

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

следующих разделах представлены рекомендации по проектированию аспектов, в которых

чаще всего возникают ошибки:

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

 Авторизация

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

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

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

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

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

 Безопасность сообщений

 Маршрутизация сообщений

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

 Интерфейс сервиса

 Валидация

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

производительность и доступные технологии рассматриваются в главе 18, «Взаимодействие и

обмен сообщениями».

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

Аутентификация используется для установления подлинности потребителя сервиса.

Проектирование эффективной стратегии аутентификации для слоя сервисов имеет большое

значение с точки зрения обеспечения безопасности и надежности приложения, в противном

случае, оно будет уязвимым для атак с подделкой пакетов, атак перебором по словарю,

перехватом сеансов и других типов атак. При проектировании стратегии аутентификации

руководствуйтесь следующими рекомендациями

 Найдите походящий механизм безопасно идентифицировать пользователей, по

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

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

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

кода сервиса.

 Для обычной аутентификации или при передаче учетных данных в открытом виде

используйте такие безопасные протоколы, как Secure Sockets Layer (SSL). Для SOAP-

сообщений применяйте механизмы безопасности уровня сообщения,

поддерживаемые стандартами WS* (Web Services Security, Web Services Trust и Web

Services Secure Conversation).

Авторизация

Авторизация позволяет определить, какие ресурсы или действия доступны тому или иному

аутентифицированному потребителю сервиса. Проектирование эффективной стратегии

авторизации для слоя сервисов имеет большое значение с точки зрения обеспечения

безопасности и надежности приложения, в противном случае, оно будет уязвимым для

разглашения сведений, повреждения или подделки данных и несанкционированного

получения прав. Как правило, стратегия авторизации работает с обобщенными действиями

или операциями, а не ресурсами, которые их выполняют. При проектировании стратегии

авторизации руководствуйтесь следующими рекомендациями:

 Задайте соответствующие права доступа к ресурсам для пользователей, групп и

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

набором разрешений.

 По возможности избегайте слишком подробного деления прав при авторизации,

чтобы обеспечить эффективность и удобство обслуживания применяемой стратеги

авторизации.

 Для аутентификации Windows используйте авторизацию URL и/или авторизацию

доступа к файлам.

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

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

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

При проектировании стратегии сетевого взаимодействия для сервиса выбор протокола

должен основываться на сценарии развертывания, который должен поддерживать ваш

сервис. При проектировании стратегии связи руководствуйтесь следующими рекомендациями

 На основании требований, предъявляемых к механизмам сетевого взаимодействия,

определите используемый механизм: запрос-ответ или двусторонняя связь, и то,

должен ли обмен сообщениями быть однонаправленным или двунаправленным.

Также выясните необходимость в асинхронных вызовах.

 Примите решение о том, как будет обрабатываться ненадежная или неустойчивая

связь, возможно, путем реализации агента сервиса или использования надежной

системы очереди сообщений, такой как Message Queuing.

 Если сервис предполагается развертывать в закрытой сети, используйте протокол

Transmission Control Protocol (TCP)

, что обеспечит максимальную эффективность

сетевого взаимодействия. Если сервис будет развертываться в Интернете,

используйте протокол Hypertext Transfer Protocol (HTTP)

 Для обеспечения максимальной гибкости используйте динамические URL для

конфигурации конечных точек. Например, вместо указания URL конечных точек в

коде, по возможности используйте конфигурацию или сервис каталогов, такой как

Universal Discovery Description and Integration (UDDI)

 Проверяйте адреса конечных точек и обеспечьте защиту конфиденциальных

данных в сообщениях.

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

Проектирование эффективной стратегии управления исключениями для слоя сервисов имеет

большое значение с точки зрения обеспечения безопасности и надежности приложения, в

противном случае, оно будет уязвимым для атак Отказа в обслуживании (Denial of Service, DoS)

и может допустить разглашение конфиденциальных или наиболее важных данных о

приложении. Формирование и обработка исключений является ресурсоемкой операцией,

поэтому важно, чтобы проектирование стратегии управления исключениями велось с учетом

влияния на производительность. Хорошей практикой является проектирование

Протокол управления передачей (прим. переводчика).

Протокол передачи гипертекста (прим. переводчика).

Универсальный поиск, описание и взаимодействие (прим. переводчика).

централизованного механизма управления исключениями и протоколирования. Также

предусмотрите механизмы управления, поддерживающие инструментирование и

централизованный мониторинг, чтобы облегчить работу системным администраторам. При

проектировании стратегии управления исключениями руководствуйтесь следующими

рекомендациями:

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

как обеспечить целостность сообщения при возникновении исключения.

Обеспечьте корректную обработку необрабатываемых исключений и не

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

 При работе с SOAP используйте элементы Fault (Сбой) или специальные

расширения для доставки данных исключения вызывающей стороне.

 Обеспечьте протоколирование исключений, обеспечивающее неразглашение

конфиденциальных данных в сообщениях об ошибках или файлах журнала.

Более подробно методики управления исключениями рассматриваются в главе 17, «Сквозная

функциональность».

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

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

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

сервиса, такой как Windows Communication Foundation (WCF). Необходимо понимать, какие

шаблоны поддерживает выбранная инфраструктура, и определить подходящий канал для

взаимодействия с потребителями сервиса. При проектировании каналов обмена сообщениями

руководствуйтесь следующими рекомендациями:

 Из имеющихся шаблонов каналов обмена сообщениями, таких как Channel Adapter,

Messaging Bus и Messaging Bridge, выберите наиболее подходящие для вашего

сценария. Убедитесь также в правильности выбора инфраструктуры сервисов и ее

соответствии всем требованиям.

 Продумайте, как будете перехватывать и проверять данные между конечными

точками, если в этом появится необходимость.

 Опишите условия возникновения исключений в канале и способы их обработки.

 Продумайте, как будете обеспечивать доступ к клиентам, не поддерживающим

обмен сообщениями.

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

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

сообщение. Формат этого сообщения определяется типами поддерживаемых операций.

Например, может происходить обмен документами, выполнение команд или формирование

событий. При проектировании структуры сообщения руководствуйтесь следующими

рекомендациями:

 Из имеющихся шаблонов структуры сообщения, таких как Command, Document,

Event и Request-Reply, выберите наиболее подходящие для вашего сценария.

 Разделяйте очень большие объемы данных на меньшие блоки и отправляйте их

последовательно.

 При использовании медленных каналов доставки сообщений включайте в

сообщения данные о сроке действия. Сервис должен игнорировать сообщения,

срок действия которых истек.

Конечная точка для передачи сообщения

Конечная точка для передачи сообщения представляет подключение, которое приложения

используют для взаимодействия с сервисом. Реализация интерфейса сервиса представляет

конечную точку для передачи сообщений. При проектировании реализации сервиса

необходимо учесть возможность поступления дублирующихся или недействительных

сообщений. При проектировании конечных точек для передачи сообщений руководствуйтесь

следующими рекомендациями:

 Из доступных шаблонов конечных точек для передачи сообщений, таких как

Gateway, Mapper, Competing Consumers и Message Dispatcher, выберите наиболее

подходящие вашему сценарию.

 Определитесь с тем, должны ли приниматься все сообщения или необходимо

реализовать фильтр для обработки лишь определенных сообщений.

 Обеспечьте идемпотентность интерфейса для передачи сообщений.

Идемпотентность – это ситуация, когда при поступлении от одного потребителя

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

идемпотентная конечная точка гарантирует, что будет обработано только одно

сообщение и все дублирующиеся сообщения будут проигнорированы.

 Обеспечьте коммутативность интерфейса для передачи сообщений.

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

понадобиться сохранять входящие сообщения, чтобы обеспечить их обработку в

правильном порядке.

 Проектируйте с учетом сценариев без постоянного подключения. Например,

реализуйте поддержку гарантированной доставки или сохранения сообщений для

отложенной доставки. Обеспечьте, чтобы при отсутствии подключения не

выполнялись попытки соединения с конечными точками.

Безопасность сообщений

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

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

(IPSec или SSL) или защиту на уровне сообщения (шифрование и цифровые подписи). При

проектировании безопасности сообщений руководствуйтесь следующими рекомендациями:

 В большинстве случаев необходимо предусмотреть возможности защиты

содержимого сообщений методами обеспечения безопасности на уровне

сообщения. Безопасность на уровне сообщения помогает защищать

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

предоставления цифровой подписи, которая защитит от повреждений или

подделки сообщений, а также позволит выявить отправителя сообщения. Однако

нельзя забывать, что каждый уровень защиты негативно сказывается на

производительности.

 Если взаимодействие между сервисом и потребителем осуществляется без

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

защиту на транспортном уровне, например, с помощью протоколов IPSec или SSL.

Но если сообщение передается через одного или более посредников, должна

использоваться только безопасность на уровне сообщения, поскольку при первом

варианте защиты сообщение дешифруется и затем повторно шифруется на каждом

посреднике, что представляет угрозу безопасности.

 Применение обоих типов защиты, и на транспортном уровне, и на уровне

сообщений, обеспечит максимальную безопасность. Безопасность на транспортном

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

при использовании безопасности на уровне сообщений.

Маршрутизация сообщений

Маршрутизатор сообщений обеспечивает отделение потребителя сервиса от реализации

сервиса. Существует три основных типа марштутизаторов: простые, составные и шаблонные. В

простых маршрутизаторах конечная точка назначения сообщения определяется с помощью

единственного маршрутизатора. Составные маршрутизаторы объединяют в себе множество

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

шаблоны используются для описания разных стилей маршрутизации на основе простых

маршрутизаторов сообщений. При проектировании маршрутизации сообщений

руководствуйтесь следующими рекомендациями:

 Из доступных шаблонов маршрутизации сообщений, таких как Aggregator, Content-

Based Router, Dynamic Router и Message Filter, выберите наиболее подходящие для

вашего сценария.

 При поступлении от потребителя последовательных сообщений маршрутизатор

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

(коммутативность).

 Маршрутизатор сообщений может просматривать данные сообщения, чтобы

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

гарантировать возможность доступа маршрутизатора к этим данным. Возможно,

сведения маршрутизации придется вынести в заголовок. При шифровании

сообщения необходимо гарантированно обеспечить, что в нешифрованном

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

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

Часто при передаче сообщений между сервисом и потребителем приходится преобразовывать

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

клиентов, не поддерживающих обмен сообщениями, можно с помощью адаптеров; а для

преобразования данных сообщений в формат, понятный всем потребителям, используются

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

рекомендациями:

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

производительности при преобразовании и постарайтесь максимально сократить

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

 Выберите соответствующие шаблоны для преобразования сообщений, такие как

Canonical Data Mapper, Envelope Wrapper и Normalizer. Однако применяйте модель

Canonical Data Mapper только по необходимости.

 Определяйте формат сообщения с помощью метаданных.

 Рассмотрите возможность использования внешнего хранилища для хранения

метаданных.

Интерфейс сервиса

Интерфейс сервиса представляет контракт, предоставляемый сервисом. Контракт определяет

операции, поддерживаемые сервисом, и связанные с ними параметры и объекты передачи

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

и тип потребителей, которые будут осуществлять доступ к сервису. Например, операции

сервиса должны быть операциями уровня приложения и слабо детализированными. Одна из

самых больших ошибок при проектировании интерфейса сервиса – интерпретация сервиса как

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

требующего большого количества вызовов через физические границы или границы процесса,

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

проектировании интерфейса сервиса руководствуйтесь следующими рекомендациями:

 Используйте слабо детализированный интерфейс для обеспечения пакетирования

запросов и максимального сокращения количества вызовов по сети.

 Проектируйте интерфейсы сервисов таким образом, чтобы изменения бизнес-

логики не оказывали на них влияния. Однако при изменении бизнес-требований,

вероятно, это будет просто неизбежно.

 Не реализуйте бизнес-правила в интерфейсе сервиса.

 Для обеспечения максимальной совместимости с разными типами клиентов

используйте параметры стандартных форматов. При проектировании интерфейса

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

 Не используйте наследование объектов для реализации контроля версий

интерфейса сервиса.

 Включайте трассировку и компиляцию в режиме отладки для всех сервисов только

на время разработки и тестирования.

Валидация

Для обеспечения защиты слоя сервисов необходимо проверять все получаемые им запросы, в

противном случае приложение будет уязвимым и к злонамеренным атакам, и к ошибкам,

обусловленным некорректными входными данными. Точного и исчерпывающего

определения действительного или злонамеренного ввода не существует, кроме того, риск

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

При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:

 Используйте централизованный подход к проверке, чтобы максимально повысить

тестируемость и пригодность для повторного использования.

 Ограничивайте, отклоняйте и очищайте все содержимое сообщений, включая

параметры. Проводите проверку длины, диапазона, формата и типа.

 Используйте схемы проверки сообщений. Валидация с применением схем

рассматривается в статье «Message Validation» (Валидация сообщений) по адресу

http://msdn.microsoft.com/en-us/library/cc949065.aspx и в статье «Input/Data

Validation» (Валидация ввода/данных) по адресу http://msdn.microsoft.com/en-

us/library/cc949061.aspx.

REST и SOAP

Representational State Transfer (REST)

и SOAP представляют два разных стиля реализации

сервисов. Фактически, REST – это архитектурный шаблон, создаваемый с использованием

простых команд и хорошо ложащийся на протокол HTTP. Хотя архитектурные принципы REST

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

сочетании с HTTP. SOAP – это основанный на XML протокол обмена сообщениями, который

может использоваться с любым протоколом связи, в том числе и с HTTP.

Основное различие между этими двумя подходами в способе сохранения состояния сервиса.

Состояние сервиса не должно рассматриваться как состояние приложения или сеанса; это

разные состояния, которые приложение проходит в течение его жизненного цикла. При

использовании SOAP переход из состояния в состояние может быть реализован через

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

предоставлять доступ ко многим операциям и типам сообщений.

При использовании REST набор операций ограничен, и эти операции применяются к ресурсам,

которые предоставляются и доступны через URI (HTTP-адреса). В сообщениях фиксируется

текущее или необходимое состояние ресурса. REST хорошо работает с Веб-приложениями, что

позволяет обеспечивать преимущество поддержки HTTP не-XML MIME-типам или потоковую

передачу содержимого. Потребители сервиса при перемещении по REST-ресурсам

Передача репрезентативного состояния (прим. переводчика).

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

Веб-страницами.

С большинством реализаций сервисов могут использоваться и REST, и SOAP, часто подход с

применением REST лучше подходит для публичных сервисов или в случаях, когда доступ к

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

для реализации широкого диапазона процедурных взаимодействий, таких как интерфейс

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

Стандарты WS-*, которые могут использоваться в SOAP, предоставляют стандартный и,

следовательно, обеспечивающий возможность взаимодействия метод решения общих

проблем обмена сообщениями, таких как безопасность, транзакции, адресация и надежность.

REST тоже может обеспечивать такую же функциональность, но в настоящее время эта область

практически не стандартизована, поэтому часто приходится создавать собственные

механизмы.

В общем, при проектировании взаимодействий на базе SOAP можно использовать те же

принципы, чтобы и для REST-взаимодействий без сохранения состояния. В обоих подходах для

описания обмена данными (полезной нагрузкой) используются обычные глаголы. В случае с

SOAP набор глаголов не является окончательным и определяется конечной точкой сервиса.

Для REST набор глаголов ограничен предопределенными словами, отражающими протокол

HTTP. При выборе между REST и SOAP руководствуйтесь следующими рекомендациями:

 SOAP – протокол, обеспечивающий базовую инфраструктуру обмена сообщениями,

на которой могут строиться абстрактные слои. Он обычно применяется как RPC-

инфраструктура

, передающая запросы и ответы по сети с помощью XML-

форматированных сообщений.

 SOAP обеспечивает учет таких аспектов, как безопасность и адресация, через

внутреннюю реализацию протокола, но требует, чтобы был доступен стек SOAP.

 REST – методика, которая может использовать другие протоколы, такие как

JavaScript Object Notation (JSON)

, протокол публикации Atom и собственные

форматы Plain Old XML (POX)

 REST предоставляет приложение и данные как конечный автомат, а не просто

конечную точку сервиса. Он позволяет использовать для выполнения запросов и

изменения состояния системы стандартные HTTP-методы вызова, такие как GET и

PUT. REST по своей природе не сохраняет состояния, поэтому каждый отдельный

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

данные для его интерпретации, поскольку сервер не сохраняет данных о состоянии

сеанса.

Механизм удаленного вызова процедур (прим. научного редактора).

Объектная нотация JavaScript (прим. переводчика).

Обычный старый XML (прим. переводчика).