Для аутентификации Windows используйте авторизацию URL и/или авторизацию доступа к файлам.
Где это возможно, ограничьте доступ к открытым Веб-методам путем использования декларативных методов проверки прав.
Сетевое взаимодействие
При проектировании стратегии сетевого взаимодействия для сервиса выбор протокола должен основываться на сценарии развертывания, который должен поддерживать ваш сервис. При проектировании стратегии связи руководствуйтесь следующими рекомендациями
На основании требований, предъявляемых к механизмам сетевого взаимодействия, определите используемый механизм: запрос-ответ или двусторонняя связь, и то, должен ли обмен сообщениями быть однонаправленным или двунаправленным. Также выясните необходимость в асинхронных вызовах.
Примите решение о том, как будет обрабатываться ненадежная или неустойчивая связь, возможно, путем реализации агента сервиса или использования надежной системы очереди сообщений, такой как Message Queuing.
Если сервис предполагается развертывать в закрытой сети, используйте протокол Transmission Control Protocol (TCP)1, что обеспечит максимальную эффективность сетевого взаимодействия. Если сервис будет развертываться в Интернете,
используйте протокол Hypertext Transfer Protocol (HTTP)2.
Для обеспечения максимальной гибкости используйте динамические URL для конфигурации конечных точек. Например, вместо указания URL конечных точек в коде, по возможности используйте конфигурацию или сервис каталогов, такой как
Universal Discovery Description and Integration (UDDI)3.
Проверяйте адреса конечных точек и обеспечьте защиту конфиденциальных данных в сообщениях.
Управление исключениями
Проектирование эффективной стратегии управления исключениями для слоя сервисов имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для атак Отказа в обслуживании (Denial of Service, DoS) и может допустить разглашение конфиденциальных или наиболее важных данных о приложении. Формирование и обработка исключений является ресурсоемкой операцией, поэтому важно, чтобы проектирование стратегии управления исключениями велось с учетом влияния на производительность. Хорошей практикой является проектирование
1Протокол управления передачей (прим. переводчика).
2Протокол передачи гипертекста (прим. переводчика).
3Универсальный поиск, описание и взаимодействие (прим. переводчика).
централизованного механизма управления исключениями и протоколирования. Также предусмотрите механизмы управления, поддерживающие инструментирование и централизованный мониторинг, чтобы облегчить работу системным администраторам. При проектировании стратегии управления исключениями руководствуйтесь следующими рекомендациями:
Перехватывайте только те исключения, которые можете обработать, и продумайте, как обеспечить целостность сообщения при возникновении исключения. Обеспечьте корректную обработку необрабатываемых исключений и не используйте исключения для управления бизнес-логикой.
При работе с 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, ContentBased Router, Dynamic Router и Message Filter, выберите наиболее подходящие для вашего сценария.
При поступлении от потребителя последовательных сообщений маршрутизатор должен гарантировать их доставку в одну конечную точку в заданном порядке (коммутативность).
Маршрутизатор сообщений может просматривать данные сообщения, чтобы понять, как выполнять его маршрутизацию. Таким образом, необходимо гарантировать возможность доступа маршрутизатора к этим данным. Возможно, сведения маршрутизации придется вынести в заголовок. При шифровании сообщения необходимо гарантированно обеспечить, что в нешифрованном заголовке имеются данные, необходимые для маршрутизации сообщения.