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

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

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

возможности взаимодействия:

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

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

такие как HTTP и XML. Не забывайте, что выбор протокола может оказывать

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

защищена межсетевыми экранами, блокирующими некоторые протоколы.

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

Необходимость в изменении сервисов может возникнуть из-за изменения бизнес-

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

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

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

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

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

эти вопросы рассматриваются в статье «Service Versioning» (Контроль версий

сервисов) по адресу http://msdn.microsoft.com/en-us/library/ms731060.aspx.

 Выбор формата данных может влиять на возможность взаимодействия. Например,

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

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

 Принимаемые решения по шифрованию и дешифрованию могут влиять на

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

шифрования/дешифрования доступны не во всех системах.

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

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

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

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

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

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

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

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

 По возможности, не передавайте лишние данные в удаленные методы и

максимально сократите объем передаваемых по сети данных. Это обеспечит

сокращение задержки сети и издержек на сериализацию. Кроме того, для

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

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

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

единицы работы. Применяйте шаблон Façade, он обеспечит слабо

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

 Используйте DTO-объекты для передачи данных единым элементом, вместо того

чтобы передавать отдельные типы данных по одному.

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

специальные классы с бинарной сериализацией.

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

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

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

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

протяжении множества запросов. Принимая решение о реализации управления состоянием,

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

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

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

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

развертывания.

 При использовании в компоненте или сервисе модели программирования с

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

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

 При проектировании ASMX-сервиса для хранения состояния используйте класс

ApplicationContext (Контекст приложения), потому что он обеспечивает доступ к

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

 При проектировании WCF-сервиса используйте расширяемые объекты,

предоставляемые платформой для управления состоянием. Эти расширяемые

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

определения, таких как хост сервиса, контекст экземпляра сервиса и контекст

операции. Обратите внимание, что все эти состояния удерживаются в памяти и не

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

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

Framework 3.5, или реализовать собственное решение.

Контрактно-ориентированное проектирование

Традиционно разработчики создавали сервисы, применяя подход сначала код (code first), при

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

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

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

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

номенклатурой клиентов.

Контрактно-ориентированное проектирование – это процесс проектирования контракта

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

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

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

операции. Это позволяет в самом начале процесса сосредоточиться на формате сообщений и

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

и совместимости.

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

Web Service Software Factory: Modeling Edition (http://msdn.microsoft.com/servicefactory/)

группы patterns & practices. Или можно создать дизайн интерфейса, используя XML, XSD и

схемы, а затем с помощью такого инструмента, как WSDL.exe, с ключом /server сгенерировать

описание интерфейса. Технологии с применением шины сообщений, такие как Microsoft

BizTalk Server, способствуют использованию принципов контрактно-ориентированного

проектирования.

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

принципы:

 Работа с XML-схемами и типами данных означает, что вы не оперируете и не можете

оперировать категориями типов данных, характерных для той или иной платформы.

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

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

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

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

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

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

форматам.

 Применяйте специальные инструменты для проектирования контрактов сервиса. Это

может существенно упростить и ускорить процесс.

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

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

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

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

Более подробно контрактно-ориентированное проектирование рассматривается в статье

«Contract-First Service Development» (Контрактно-ориентированная разработка сервисов) по

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

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

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

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

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

обеспечения безопасности при взаимодействии: безопасность на транспортном уровне и

безопасность на уровне сообщения. Максимальную защиту обеспечит сочетание этих двух

методик.

Безопасность на транспортном уровне

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

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

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

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

уровне являются применение шифрования по протоколам Secure Sockets Layer (SSL) и Internet

Protocol Security (IPSec). Принимая решение об использовании безопасности на транспортном

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

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

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

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

на более низких уровнях, иногда даже на уровне сетевого оборудования. Однако в

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

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

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

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

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

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

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

угрозу безопасности.

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

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

такой как интранет.

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

Безопасность на уровне сообщения может использоваться с любым транспортным

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

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

важного содержимого. Общими подходами к обеспечению безопасности на уровне

сообщения являются шифрование и цифровые подписи. Принимая решение об использовании

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

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

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

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

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

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

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

шифрование и подпись сообщений.

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

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

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

разрывают подключение SSL или IPSec и затем создают новое подключение SSL или

IPSec для передачи этого сообщения следующему серверу. Поэтому, если

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

сервере.

Технологии

Платформа Microsoft предлагает две технологии обмена сообщениями: Windows

Communication Foundation (WCF) и ASP.NET Web Services (ASMX). В следующих разделах будут

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

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

Технология WCF

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

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

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

 Используйте WCF в следующих ситуациях:

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

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

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

◦ Для взаимодействия с Веб-сервисами, использующими не SOAP-сообщения,

например, приложениями, работающими с такими форматами, как Really

Simple Syndication (RSS).

◦ Для взаимодействия посредством SOAP-сообщений и двоичного

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

WCF.

◦ Для создания сервисов REST Singleton и Collection Services, ATOM Feed и

Publishing Protocol Services, а также HTTP Plain XML Services.

 Используйте WS-MetadataExchange в SOAP-запросах для получения подробных

сведений о сервисе, таких как описание на языке описания Веб-сервисов (Web

Services Description Language, WSDL) и политики.

 Используйте WS-Security для реализации аутентификации, целостности данных,

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

 Используйте WS-Reliable Messaging для реализации надежной сквозной связи даже

при наличии одного или более промежуточных Веб-сервисов.

 Используйте WS-Coordination для координирования двухфазного подтверждения

транзакции в контексте взаимодействий Веб-сервисов.

WCF поддерживает несколько разных протоколов связи:

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

протокол HTTP.

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

протокол TCP.

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

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

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

Технология ASMX

ASMX обеспечивает более простое решение для создания Веб-сервисов на базе ASP.NET и их

предоставления через Веб-сервер IIS. ASMX имеет следующие характеристики:

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

протокола HTTP. По умолчанию использует порт 80, но изменить это не составляет

никакого труда.

 Не поддерживает транзакций координатора распределенных транзакций

(Distributed Transaction Coordinator, DTC). Для программирования длительных

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

 Поддерживает аутентификацию IIS, роли, хранящиеся как группы Windows для

авторизации, олицетворение IIS и ASP.NET и безопасность на транспортном уровне с

использованием протокола SSL.

 Поддерживает технологию конечных точек, реализованную в IIS.

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

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

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

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

 «Data Transfer and Serialization» (Передача и сериализация данных) по адресу

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

 «Endpoints: Addresses, Bindings, and Contracts» (Конечные точки: адреса, привязки и

контракты) по адресу http://msdn.microsoft.com/en-us/library/ms733107.aspx.

 «Messaging Patterns in Service-Oriented Architecture» по адресу

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

 «Principles of Service Design: Service Versioning» (Принципы проектирования

сервисов: контроль версий) по адресу http://msdn.microsoft.com/en-

us/library/ms954726.aspx.

 «Web Service Messaging with Web Services Enhancements 2.0» (Web Service Messaging

с расширениями Web Services Enhancements 2.0) по адресу

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

 «Web Services Protocols Interoperability Guide» (Руководство по возможности

взаимодействия протоколов Веб-сервисов) по адресу http://msdn.microsoft.com/en-

us/library/ms734776.aspx.

 «Windows Communication Foundation Security» (Безопасность Windows

Communication Foundation) по адресу http://msdn.microsoft.com/en-

us/library/ms732362.aspx.

 «XML Web Services Using ASP.NET» (Веб-сервисы XML с использованием ASP.NET) по

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

Физические уровни и

развертывание

Обзор

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

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

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

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

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

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

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

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

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

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

иных требований дизайна из-за технических ограничений инфраструктуры.

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

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

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

Выявление ограничений развертывания на ранних этапах проектирования поможет избежать

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

инфраструктуры. При выборе стратегии развертывания:

 Изучите целевую физическую инфраструктуру развертывания.

 Исходя из инфраструктуры развертывания, выявите ограничения архитектуры и

дизайна.

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

системы будет оказывать инфраструктура развертывания.

Распределенное и нераспределенное развертывание

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

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

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

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

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

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

Нераспределенное развертывание

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

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

Рис. 14

Нераспределенное развертывание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Распределенное развертывание

При распределенном развертывании все слои приложения располагаются на разных

физических уровнях. При многоуровневом развертывании инфраструктура системы

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

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

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

слои приложения по разным физическим уровням, как показано в примере на рис. 2.

Рис. 15

Распределенное развертывание

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

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

слоя. Тем не менее, поскольку основным фактором оптимизации развертывания компонентов

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

сервером, прямое проецирование слоев в уровни часто не является наилучшей стратегией

развертывания.

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

Каждая инфраструктура оптимизируется под определенный набор эксплуатационных

требований и требований по использованию системных ресурсов. После этого компоненты

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

ресурсам, что обеспечит наилучшие производительность и поведение. Чем больше уровней,

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

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

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

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

увеличению необходимого объема работ по развертыванию и затрат.

Другое основание для добавления уровней – применение особых политик безопасности.

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

приложений, например, через введение межсетевого экрана между Веб-сервером и

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

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

средах

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

за издержек на удаленные вызовы через физические границы. Однако распределение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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