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

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

 Постзагрузка и автоматический запуск, в этом случае специальный пакет компании

загружается как часть операционной системы.

 Загрузка с сайта, вручную с использованием SD-карты.

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

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

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

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

беспроводному соединению.

 При использовании распределения для множества устройств с помощью CAB-файла

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

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

остальных исполняемых файлов.

 Если приложение широко использует возможности компьютера, применяйте для его

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

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

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

приложения сразу после запуска операционной системы Windows Mobile.

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

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

карты памяти SD.

Более подробно шаблоны и сценарии развертывания рассматриваются в главе 19,

«Физические уровни и развертывание».

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

Основные шаблоны проектирования организованы по категориям, таким как Кэширование,

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

таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных

решений для каждой из категорий.

Категория

Шаблоны

Кэширование

Lazy Acquisition (Отложенное получение). Максимально долго откладывает

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

Сетевое

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

Active Object (Активный объект). Поддерживает асинхронную обработку путем

инкапсуляции запроса сервиса и ответа по завершении выполнения сервиса.

Communicator (Коммуникатор). Инкапсулирует внутренние детали взаимодействия

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

каналам.

Entity Translator. Объект, преобразующий типы данных сообщения в бизнес-типы

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

Reliable Sessions. Надежная передача сообщений из конца в конец между

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

между конечными точками

Доступ к

данным

Active Record. Включает объект доступа к данным в сущность предметной области.

Data Transfer Object (DTO). Объект, в котором сохраняются данные, передаваемые

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

методов.

Domain Model. Набор бизнес-объектов, представляющих сущности предметной

области и отношения между ними.

Transaction Script. Организует бизнес-логику каждой транзакции в одну процедуру,

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

Синхронизация

Synchronization (Синхронизация). Компонент, установленный на устройство,

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

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

Application Controller. Объект, включающий всю логику выполнения и

используемый другими Контроллерами, которые работают с Моделью и отображают

соответствующее Представление.

Model-View-Controller. Разделяет данные предметной области, представление и

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

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

отвечает на запросы о состоянии (обычно поступающие от Представления) и

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

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

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

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

Model-View-Presenter. Разделяет обработку запросов на три роли, где

Представление отвечает за обработку пользовательского ввода, Модель – за

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

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

Pagination (Разбиение на страницы). Разделяет большие объемы содержимого на

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

занимаемого содержимым на экране.

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

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

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

 Более подробно варианты используемых технологий для Windows Embedded

рассматриваются в Windows Embedded Developer Center

 Больше сведений о фабриках ПО для мобильных устройств можно найти в статье

patterns & practices Mobile Client Software Factory

 Microsoft Sync Framework обсуждается в статье Microsoft Sync Framework Developer

Center

 OpenNETCF.Diagnostics.EventLog в Smart Device Framework рассматривается в

материале Instrumentation for .NET Compact Framework Applications

(Инструментирование для приложений .NET Compact Framework)

 Подробнее об ASP.NET Mobile рассказывает материал Roadmap for ASP.NET Mobile

Development (Дорожная карта для разработки с ASP.NET for Mobile)

 Более подробно о введении поддержки исходного кода ASP.NET Mobile в Visual Studio

2008 рассказывает статья Tip/Trick: ASP.NET Mobile Development with Visual Studio 2008

(Советы и рекомендации: разработка на ASP.NET Mobile с использованием Visual Studio

2008)

 Более подробно о разрешениях модели безопасности в Windows Mobile 6.x

рассказывается в статье Security Model for Windows Mobile 5.0 and Windows Mobile 6

(Модель безопасности Windows Mobile 5.0 и Windows Mobile 6)

 Более подробную информацию о сервисах протоколирования Apache «log4Net»

можно найти по адресу http://logging.apache.org/log4net/index.html.

 Более подробную информацию о продукте Ярослава Ковальского «NLog» можно найти

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

 Больше сведений о сообществе OpenNetCF можно найти по адресу

http://community.opennetcf.com/.

Проектирование сервисных

приложений

Обзор

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

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

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

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

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

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

Сервис – это открытый интерфейс, обеспечивающий доступ к единице функциональности.

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

потребляющей этот сервис. Сервисы слабо связаны и для обеспечения более сложной

функциональности могут комбинироваться с клиентом или в рамках других сервисов. Сервисы

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

компьютера, так и с компьютера, на котором они выполняются. Сервисы ориентированы на

сообщения, т.е. интерфейсы сервисов описываются с помощью Web Services Description

Language (WSDL), и операции вызываются с использованием схем сообщений на базе

Extensible Markup Language (XML), передаваемых по транспортному каналу. Сервисы

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

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

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

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

сервисного приложения.

Рис. 42

Типовая архитектура сервисного приложения

Типовое сервисное приложение состоит из трех слоев: слой сервисов, бизнес-слой и слой

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

сообщений и типов данных; бизнес-слой – компоненты бизнес-логики, бизнес-процесса и

бизнес-сущностей; и слой доступ к данным включает компоненты доступа к данным и агентов

сервисов. Многослойному дизайну посвящена глава 5, «Рекомендации по проектированию

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

глава 10, «Рекомендации по проектированию компонентов».

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

сценариях и комбинациях. Рассмотрим типовые сценарии:

 Сервис, предоставляемый через Интернет. Этот сценарий описывает сервис,

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

«бизнес-бизнес», так и ориентированные на потребителя сервисы. Биржевой Веб-

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

акций – один из примеров такого сценария. Решения по аутентификации и

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

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

применение сертификатов более вероятна в Интернет-сценарии, чем в интранет-

сценарии.

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

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

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

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

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

типов учетных данных. Например, аутентификация Windows с применением Active

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

интранет-сценария, чем для Интернет-сценария.

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

сервис, потребляемый приложением на локальном компьютере. Решения по защите

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

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

 Смешанный сценарий. Этот сценарий описывает сервис, используемый множеством

приложений по Интернету, внутренней сети и/или на локальном компьютере.

Сервисное бизнес-приложение (LOB), потребляемое локально насыщенным

клиентским приложением и Веб-приложением по Инернету – пример такого

сценария.

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

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

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

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

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

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

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

архитектуры (SOA) необходимо обеспечить стабильность контракта приложения и

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

рабочего процесса, или хранилище операционных данных, обеспечивающее основанный на

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

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

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

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

компонентам. Обеспечивайте интерфейс бизнес-слоя через абстракцию, которая

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

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

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

рассматривается в главе 5, «Рекомендации по проектированию многослойных

приложений».

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

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

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

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

шаблона Façade позволит объединять несколько небольших детализированных

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

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

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

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

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

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

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

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

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

слоем. Обычно это обеспечивается путем создания для бизнес-сущностей отдельной

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

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

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

оговорена контрактом сервиса, внутренняя реализация и детали сервиса никогда не

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

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

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

контрактами, создавайте новые версии контрактов. Описывайте новые операции,

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

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

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

 Проектируйте автономные сервисы. Сервисы не должны предъявлять никаких

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

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

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

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

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

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

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

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

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

(идемпотентность) путем реализации широко известных шаблонов или через

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

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

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

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

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

Сервисное приложение должно быть самодостаточным и иметь четкие границы.

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

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

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

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

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

 Разделяйте функциональность сервиса и операции инфраструктуры. Логика

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

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

обслуживании.

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

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

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

 Избегайте использования сервисов данных для предоставления отдельных таблиц

базы данных. Это приведет к слишком детализированным вызовам сервиса и

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

зависимостей для потребителей сервиса. Кроме того, старайтесь избегать реализации

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

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

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

 Обеспечьте при проектировании, чтобы сервисы рабочего процесса использовали

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

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

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

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

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

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

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

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

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

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

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

 Бизнес-слой

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

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

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

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

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

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

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

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

 Передача репрезентативного состояния

 Слой сервисов

 SOAP

 Валидация

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

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

Например, если сервис размещен в Internet Information Services (IIS), можно использовать

поддержку аутентификации, предоставляемую IIS. Если сервис размещается с применением

Windows Service, должна использоваться аутентификация на основе сообщений или

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

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

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

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

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

регистрации.

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

сервиса.

 С обычной аутентификацией или при передаче учетных данных в виде простого

текста должны использоваться безопасные протоколы, такие как Secure Sockets Layer

(SSL). С SOAP-сообщениями применяйте такие механизмы обеспечения безопасности,

как Web Services Security

(WS-Security).

Авторизация

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

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

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

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

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

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

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

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

правами доступа.

 Для защиты URL и файловых ресурсов используйте авторизацию на базе

Унифицированного указателя ресурса (Uniform Resource Locator, URL) и/или

авторизацию доступа к файлам.

Безопасность Веб-сервисов (прим. переводчика).

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

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

Бизнес-слой

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

бизнес-операции. Основная цель при проектировании интерфейса сервиса – использовать

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

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

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

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

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

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

должен выполнять код слоя сервисов.

 При поддержке сервисов используйте фасад для бизнес-слоя. Фасад представляет

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

операций и их разложение на множество бизнес-операций. Однако если сервис будет

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

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

операции, если это необходимо для клиента.

 Проектируйте бизнес-слой без сохранения состояния. Операции сервиса должны

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

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

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

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

объема ресурсов. Это привело бы к ограничению числа запросов, которые может

обрабатывать сервис в любой момент времени.

 Реализуйте все бизнес-сущности в отдельной сборке. Эта сборка представляет

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

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

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

используйте объекты передачи данных (data transfer objects, DTO).

Вопросам реализации бизнес-слоя посвящена глава 7, «Рекомендации по проектированию

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

бизнес-сущностей».

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

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

на основании сценария развертывания сервиса. При проектировании стратегии связи

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