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

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

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

граница между Веб-сервером и сервером базы данных, граница между приложением и

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

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

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

сервера базы данных или вызове Веб-сервиса. Обозначьте точки входа на границах доверия и

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

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

Шаг 2 – Определение ключевых сценариев

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

ключевыми сценариями, в которых требуется валидация данных. Все вводимые

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

злонамеренные. Например, в слое представления Веб-приложения подлежат проверке поля

форм, строки запросов и скрытые поля; параметры запросов GET и POST; загруженные данные

(злонамеренные пользователи могут перехватывать HTTP-запросы и изменять содержимое); и

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

В бизнес-слое ограничения на данные налагают бизнес-правила. Любое нарушение этих

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

исключение для представления этого нарушения. При использовании подсистемы управления

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

правила на основании данных, требуемых этим правилом, и выводов, полученных в

результате проверки предыдущих правил.

Шаг 3 – Выбор места валидации

На этом этапе определяемся с местом проведения валидации: на клиенте или и на сервере, и

на клиенте. Никогда не полагайтесь только на валидацию на стороне клиента. Используйте ее

для обеспечения более интерактивного UI, но всегда реализуйте также и валидацию на

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

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

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

должен поддерживать DHTML и JavaScript, в идеальном варианте реализованный в отдельном

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

Самый простой подход в Веб-приложении – применение элементов управления валидацией

ASP.NET. Это набор серверных элементов управления, которые могут проводить валидацию

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

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

реализована с использованием элементов управления валидации ASP.NET. Также, как

альтернативный вариант для Веб- и других типов приложений, используйте Validation

Application Block (Блок валидации) от группы patterns & practices. Validation Application Block

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

Validation Application Block может применяться в приложениях Windows Forms, ASP.NET и WPF.

Подробно Validation Application Block рассматривается в приложении F, «Enterprise Library от

patterns & practices».

Шаг 4 – Выработка стратегий валидации

Рассмотрим общие стратегии валидации данных:

 Прием заведомо допустимого (Список разрешенного ввода или позитивная

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

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

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

 Отклонение заведомо недопустимого (Список запрещенного ввода или негативная

проверка). Принимаются данные, не отвечающие заданному критерию (например,

не содержащие известный набор символов). Применяйте эту стратегию с

осторожностью и только как вторую линию защиты, поскольку очень сложно

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

вводов.

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

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

запрещенного ввода (негативная проверка), применяйте эту стратегию с

осторожностью и только как вторую линию защиты, поскольку очень сложно

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

вводов.

Шаблоны проектирования

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

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

этих шаблонов при принятии проектных решений для каждой из категорий.

Категория

Шаблоны

Кэширование

Cache Dependency (Кэш с зависимостью). Использует внешние

данные для определения состояния данных, хранящихся в кэше.

Page Cache (Кэш страниц). Улучшает время ответа динамических

Веб-страниц, доступ к которым осуществляется довольно часто, но

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

системы для воссоздания.

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

Intercepting Filter (Перехватывающий фильтр). Цепочка пригодных

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

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

запросе Веб-страницы.

Pipes and Filters (Каналы и фильтры). Выполняет маршрутизацию

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

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

Service Interface (Интерфейс сервиса). Программный интерфейс,

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

взаимодействия с сервисом.

Более подробно шаблоны Page Cache, Intercepting Filter и Service Interface рассматриваются в

статье «Enterprise Solution Patterns Using Microsoft .NET» по адресу

http://msdn.microsoft.com/en-us/library/ms998469.aspx.

Более подробно шаблон Pipes and Filters рассматривается в статье «Integration Patterns» по

адресу http://msdn.microsoft.com/en-us/library/ms978729.aspx.

Предложения группы patterns & practices

Узнать о дополнительных предложениях группы Microsoft patterns & practices можно из

следующих источников:

 Enterprise Library включает наборы блоков приложений, использование которых

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

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

данными, а также средства для реализации таких шаблонов, как Inversion of Control

(Инверсия управления) и Dependency Injection. Подробнее рассматривается в статье

«Microsoft Enterprise Library» по адресу http://msdn2.microsoft.com/en-

us/library/cc467894.aspx.

 Unity Application Block легковесный расширяемый контейнер внесения

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

приложений. Более подробно рассматривается в статье «Unity Application Block» по

адресу http://msdn.microsoft.com/en-us/library/cc468366.aspx.

Дополнительные источники

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

http://www.microsoft.com/architectureguide.

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

 «Authorization» по адресу http://msdn.microsoft.com/en-us/library/cc949059.aspx.

 «Authorization In WCF-Based Services» (Авторизация в WCF-сервисах) по адресу

http://msdn.microsoft.com/en-us/magazine/cc948343.aspx.

 «Designing Application-Managed Authorization» (Проектирование управляемой

приложением авторизации) по адресу http://msdn.microsoft.com/en-

us/library/ms954586.aspx.

 «Enterprise Authorization Strategy» (Корпоративная стратегия авторизации) по

адресу http://msdn.microsoft.com/en-us/library/bb417064.aspx.

 «Federated Identity: Scenarios, Architecture, and Implementation» (Интегрированная

идентификация: сценарии, архитектура и реализация) по адресу

http://msdn.microsoft.com/en-us/library/aa479079.aspx.

 «Guidance on Patterns & Practices: Security» (Руководство Patterns & Practices:

безопасность) по адресу http://msdn.microsoft.com/en-us/library/ms954624.aspx.

 «Trusted Subsystem Design» (Проектирование доверенных подсистем) по адресу

http://msdn.microsoft.com/en-us/library/aa905320.aspx.

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

можно найти в следующих статьях:

 «Caching Architecture Guide for .NET Framework Applications» (Руководство по

архитектуре кэширования для приложений .NET Framework) по адресу

http://msdn.microsoft.com/en-us/library/ms978498.aspx.

 «Cohesion and Coupling» (Связность и связанность) по адресу

http://msdn.microsoft.com/en-us/magazine/cc947917.aspx.

 Duffy, Joe. Concurrent Programming on Windows

. Addison-Wesley 2009.

 «Enterprise Solution Patterns Using Microsoft .NET» по адресу

http://msdn.microsoft.com/en-us/library/ms998469.aspx.

 «Exception Management Architecture Guide» (Руководство по архитектуре управления

исключениями) по адресу http://msdn.microsoft.com/en-us/library/ms954599.aspx.

 «Integration Patterns» по адресу http://msdn.microsoft.com/en-

us/library/ms978729.aspx.

 «Microsoft Project Code Named Velocity» по адресу http://msdn.microsoft.com/en-

us/data/cc655792.aspx.

Сведения о некоторых популярных библиотеках и инфраструктурах сторонник

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

можно найти в следующих источниках:

 Castle Project по адресу http://www.castleproject.org/index.html.

 Ninject по адресу http://ninject.org/.

 PostSharp по адресу http://www.postsharp.org/.

 StructureMap по адресу http://structuremap.sourceforge.net/Default.htm.

 memcached по адресу http://www.danga.com/memcached/.

 NLog по адресу http://www.nlog-project.org/.

 log4net по адресу http://logging.apache.org/log4net/.

Джо Даффи, «Параллельное программирование в Windows»

Взаимодействие и обмен

сообщениями

Обзор

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

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

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

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

доступа к данным. Когда компоненты физически располагаются на одном уровне, между ними

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

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

сценариев, необходимо продумать, как обеспечить эффективное и надежное взаимодействие

компонентов этих уровней.

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

методов между компонентами) и связью посредством обмена сообщениями. В связи

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

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

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

развертывания в будущем. Однако в связи с обменом сообщениями возникают такие

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

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

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

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

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

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

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

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

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

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

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

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

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

и уменьшению объемов данных, передаваемых по сети. Разрабатывая стратегию связи,

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

 Продумайте стратегии связи при пересечении границ. Продумайте все границы и

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

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

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

приложения или внешних сервисов и приложений.

 Используйте связь посредством обмена сообщениями при пересечении границ

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

Windows Communication Foundation (WCF) и TCP или протокол именованных

каналов.

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

физических границ. Используйте WCF для организации связи через физические

границы с удаленными компьютерами. Используйте Microsoft Message Queuing для

обеспечения надежной одноразовой доставки сообщений.

 Обеспечьте максимальную производительность и скорость ответа при доступе к

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

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

сокращения требуемого объема информационного обмена, а также по

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

блокировки UI или перехода его в состояние «не отвечает».

 Для форматов данных, передаваемых через границы, учтите возможности

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

другими системами, используйте сериализацию XML. Не забывайте, что

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

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

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

результате сериализованных данных меньше, чем у их XML-эквивалента.

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

взаимодействии. Используйте шифрование, цифровые сертификаты и средства

обеспечения безопасности канала.

 Реализуйте механизмы, обеспечивающие идемпотентность и коммутативность.

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

поступающие более одного раза (идемпотентность), и множество сообщений,

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

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

сообщениями

Связь посредством обмена сообщениями позволяет предоставлять сервис вызывающим

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

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

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

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

всего подходит для следующих сценариев:

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

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

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

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

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

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

надежность.

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

использующих его сервисов. Применение интерфейсов сервисов на основе

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

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

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

 Работа с реальными бизнес-процессами, использующими асинхронную модель.

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

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

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

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

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

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

Для сохранения состояния взаимодействия бизнес-логика может протоколировать

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

получен.

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

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

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

TCP для связи по внутренним сетям. Реализуйте собственный механизм связи

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

и формата не отвечает заданным требованиям.

 Если время ответа на сообщения является критичным для взаимодействия,

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

ожидают ответа на каждое сообщение. Или, если клиенты могут продолжать

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

При проектировании стратегии связи посредством обмена сообщениями также необходимо

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

повторного использования, производительность и общий успех дизайна. Более подробно эти

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

 Сравнение асинхронного и синхронного взаимодействия

 Связывание и связность

 Форматы данных

 Возможность взаимодействия с другими системами

 Производительность

 Управление состоянием

Сравнение асинхронного и синхронного взаимодействия

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

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

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

требуется ожидать ответа на вызов. Асинхронное взаимодействие применяется в сценариях, в

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

точки назначения. Выбирая между синхронным и асинхронным взаимодействием,

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

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

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

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

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

синхронное взаимодействие с клиентом.

 Если необходимо обеспечить гарантированный порядок выполнения операций, или

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

операций, используйте синхронную модель.

 Для асинхронных вызовов внутри процесса используйте средства платформы (такие

как версии Begin и End методов и обратные вызовы) для реализации асинхронных

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

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

запросы сервисов.

Если вы выбрали асинхронное взаимодействие и не можете гарантировать возможность

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

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

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

случай недоступности системы или сети в локальных кэшах. В качестве альтернативы можно

применить Message Queuing. Этот механизм в случае недоступности или сбоя системы или сети

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

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

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

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

используйте BizTalk Server. Он обеспечит надежный механизм доставки.

Связывание и связность

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

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

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

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

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

 Для обеспечения слабой связанности используйте основанную на сообщениях

технологию, такую как ASP.NET Web services (ASMX) или WCF, и данные с

самоописанием и общепринятые протоколы, такие как HTTP, REST и SOAP.

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

их назначения и функциональной области.

Форматы данных

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

объекты DataSets и собственные объекты. В следующей таблице представлены ключевые

факторы, оказывающие влияние на выбор типа данных.

Тип

Факторы

Скалярные

значения

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

Позволяют обрабатывать возможные изменения схемы. Скалярные значения

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

таким образом, оказывая влияние на вызывающий код.

XML

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

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

метаданные для бизнес-сущности.

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

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

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

DataSet

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

Необходимо обрабатывать наборы и сложные отношения.

Необходимо отслеживать изменения данных DataSet.

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

Собственные

объекты

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

Взаимодействие осуществляется с компонентами, которым известен тип объекта.

Желательна поддержка бинарной сериализации для обеспечения лучшей

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

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

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

 Если приложение работает, главным образом, с данными экземпляра,

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

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

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

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

 Применение XML может потребовать дополнительного предварительного описания

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

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

если понадобится дополнительно предоставить интерфейс новым

поддерживающим XML вызывающим сторонам).

 Объекты DataSet прекрасно подойдут для составных типов данных, особенно если

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

объекты DataSet также включают сведения о схеме и состоянии, которые

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

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

объекты DataSet, если приложение, главным образом, работает с множествами

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

данных.

 Собственные объекты применяются в случаях, когда ни один из других вариантов

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

ожидают использования собственного объекта. Такие объекты обусловливают

меньшие издержки, чем объекты DataSet, и поддерживают и бинарную, и XML-

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

каналам связи, являются объектами передачи данных (data transfer objects, DTO), в

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

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

Точность воспроизведения типа обеспечивает бинарная сериализация. Ее

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

Однако такой подход означает необходимость реализации более строгой системы

контроля версий для интерфейсов. Стандартная сериализация XML обеспечивает

сериализацию только открытых свойств и полей и не сохраняет типы.

Возможность взаимодействия с другими системами

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

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