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

Бизнес-слой

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

Компоненты бизнес-слоя не должны знать о слое сервисов. Бизнес-слой и любой код бизнес-логики не должен иметь зависимостей с кодом слоя сервисов и никогда не должен выполнять код слоя сервисов.

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

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

Реализуйте все бизнес-сущности в отдельной сборке. Эта сборка представляет разделяемый компонент, который может использоваться и бизнес-слоем, и слоем доступа к данным. Однако обратите внимание, что бизнес-сущности не должны предоставляться через границы сервиса; для передачи данных между сервисами используйте объекты передачи данных (data transfer objects, DTO).

Вопросам реализации бизнес-слоя посвящена глава 7, «Рекомендации по проектированию бизнес-слоя». Более подробно бизнес-сущности рассматриваются в главе 13, «Проектирование бизнес-сущностей».

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

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

Если сервис будет развертываться в закрытой сети, можно использовать более эффективный протокол связи Transmission Control Protocol (TCP). Если сервис будет развертываться в публичной сети, следует выбирать протокол Hypertext Transfer Protocol (HTTP).

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

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

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

Более подробно протоколы и техники связи рассматриваются в главе 18, «Взаимодействие и обмен сообщениями».

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

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

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

Всегда используйте абстракцию при реализации интерфейса слоя доступа к данным. Как правило, это обеспечивается применением шаблонов Data Access или Table Data Gateway, в которых типы входных и выходных данных определены.

Для каждой таблицы или представления базы данных создайте класс для реализации простых операций Create, Read, Update и Delete (CRUD). Это обеспечивает шаблон Table Module, в котором каждой таблице поставлен в соответствие класс с операциями, взаимодействующими с этой таблицей. Спланируйте обработку транзакций.

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

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

Более подробно реализация слоя доступа к данным обсуждается в главе 8, «Рекомендации по проектированию слоя доступа к данным».

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

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

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

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

Используйте SOAP-элементы Fault или специальные расширения для возвращения данных исключения вызывающей стороне.

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

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

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

Выбирайте соответствующие шаблоны для структуры сообщения (такие как Command, Document, Event и Request-Response).

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

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

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

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

Выбирайте соответствующие шаблоны конечных точек сообщений (такие как

Gateway, Mapper (Преобразователь), Competing Consumer и Message Dispatcher).

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

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

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

Обеспечьте коммутативность. Коммутативность – это ситуация, когда сообщения могут поступать в произвольном порядке. Иначе говоря, коммутативная конечная точка гарантирует, что поступающие в произвольном порядке сообщения будут сохранены и впоследствии обработаны в правильном порядке.

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

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

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