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

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

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

посредников между конечными точками.

Request Response. Механизм двунаправленного обмена сообщениями, при

котором клиент ожидает ответа на каждое отправленное сообщение

Непротиворечивость

данных

Atomic Transactions (Атомарные транзакции). Транзакции, область

действия которых ограничена одной операцией сервиса.

Cross-service Transactions (Межсервисные транзакции). Транзакции,

которые могут охватывать множество сервисов.

Long-running transactions (Длительные транзакции). Транзакции,

являющиеся частью бизнес-процесса.

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

Command Message. Структура сообщения, используемая для поддержки

команд.

Document Message. Структура, используемая для передачи документов

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

Event Message. Структура, обеспечивающая надежное асинхронное

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

Request-Reply. Запрос и отклик передаются по разным каналам.

Конечная точка

сообщения

Competing Consumer. Задает несколько потребителей для одной очереди

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

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

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

Durable Subscriber. Чтобы обеспечить гарантированную доставку в

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

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

сообщений.

Idempotent Receiver. Гарантирует, что сервис обрабатывает сообщение

только один раз.

Message Dispatcher. Компонент, рассылающий сообщения множеству

потребителей.

Messaging Gateway. Инкапсулирует вызовы, осуществляемые посредством

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

кода приложения.

Messaging Mapper. Преобразует запросы в бизнес-объекты для входящих

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

объектов в ответные сообщения.

Polling Consumer. Потребитель сервиса, который проверяет канал на

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

Service Activator. Сервис, принимающий асинхронные запросы для вызова

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

Selective Consumer. Потребитель сервиса, использующий фильтры для

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

Transactional Client. Клиент, который может реализовать транзакции при

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

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

Data Confidentiality. Использует шифрование на уровне сообщений для

защиты конфиденциальных данных в сообщении.

Data Integrity. Гарантированно обеспечивает защиту сообщений от

повреждения или подделки при передаче.

Data Origin Authentication. Проводит проверку источника сообщения как

расширенный метод обеспечения целостности данных.

Exception Shielding. При возникновении исключения предотвращает

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

Federation. Интегрированное представление данных, распределенных по

многим сервисам и потребителям.

Replay Protection. Обеспечивает идемпотентность сообщения,

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

злоумышленниками.

Validation. Проверяет содержимое и значения сообщений для обеспечения

защиты сервиса от неправильно сформированного или злонамеренного

содержимого.

Преобразование

сообщений

Canonical Data Mapper. Использует общий формат данных для

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

форматами данных.

Claim Check. Извлекает данные из постоянного хранилища по

необходимости.

Content Enricher. Дополняет сообщения недостающими данными,

полученными из внешнего источника данных.

Content Filter. Удаляет конфиденциальные данные из сообщения и

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

из сообщения.

Envelope Wrapper. Оболочка сообщений, включающая данные заголовка,

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

сообщения

Normalizer. Преобразует или трансформирует данные в общий формат

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

REST

Behavior. Применяется к ресурсам, выполняющим операции. Обычно такие

ресурсы не содержат состояния и поддерживают только операцию POST.

Container. Создает шаблон сущности, обеспечивая средства для

динамического добавления и/или обновления вложенных ресурсов.

Entity. Ресурсы, чтение которых может быть осуществлено операцией GET,

но изменение возможно только с помощью операций PUT и DELETE.

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

помощью операции PUT.

Transaction. Ресурсы, поддерживающие транзакционные операции.

Интерфейс сервиса

Façade. Реализует унифицированный интерфейс для набора операций,

чтобы обеспечить упрощенный интерфейс и уменьшить связанность

систем.

Remote Façade. Создает обобщенный унифицированный интерфейс для

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

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

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

Service Interface. Программный интерфейс, который может использоваться

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

SOAP

Data Contract. Схема, определяющая структуры данных, передаваемые с

запросом к сервису.

Fault Contract. Схема, определяющая ошибки или сбои, которые могут

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

Service Contract. Схема, определяющая операции, которые может

осуществлять сервис.

Более подробно шаблоны Duplex и Request Response рассматриваются в статье «Designing

Service Contracts» по адресу http://msdn.microsoft.com/en-us/library/ms733070.aspx.

Более подробно шаблон Request-Reply рассматривается в статье «Request-Reply» по адресу

http://www.eaipatterns.com/RequestReply.html.

Более подробно шаблоны Atomic и Cross-service Transaction рассматриваются в статье «WS-*

Specifications» по адресу http://www.ws-standards.com/ws-atomictransaction.asp.

Более подробно шаблоны Command, Document Message, Event Message, Durable Subscriber,

Idempotent Receiver, Polling Consumer и Transactional Client рассматриваются в материале

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

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

Более подробно шаблоны Data Confidentiality и Data Origin Authentication рассматриваются в

материале «Chapter 2: Message Protection Patterns» по адресу http://msdn.microsoft.com/en-

us/library/aa480573.aspx.

Более подробно шаблоны Replay Detection, Exception Shielding и Validation рассматриваются в

материале «Chapter 5: Service Boundary Protection Patterns» по адресу

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

Более подробно шаблоны Claim Check, Content Enricher, Content Filter и Envelope Wrapper

рассматриваются в материале «Messaging Patterns in Service Oriented Architecture, Part 2»

(Шаблоны обмена сообщениями в сервисно-ориентированной архитектуре, Часть 2) по адресу

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

Более подробно шаблон Remote Façade рассматривается в статье «P of EAA: Remote Façade» по

адресу http://martinfowler.com/eaaCatalog/remoteFacade.html.

Более подробно шаблоны REST, такие как Behavior, Container и Entity, рассматриваются в

статье «REST Patterns» (Шаблоны REST) по адресу

http://wiki.developer.mindtouch.com/REST/REST_Patterns.

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

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

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

 Более подробно распределенные системы рассматриваются в статье «Enterprise

Solution Patterns Using Microsoft .NET - Distributed Systems Patterns» (Шаблоны

корпоративных решений для Microsoft .NET – шаблоны распределенных систем) по

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

 Сценариям Enterprise Service Bus посвящена статья «Microsoft BizTalk ESB Toolkit» по

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

 Более подробно шаблоны интеграции обсуждаются в статье «Prescriptive Architecture

Integration Patterns» (Нормативные шаблоны интеграции архитектуры) по адресу

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

 Более подробно шаблоны сервисов рассматриваются в статье «Enterprise Solution

Patterns Using Microsoft .NET - Services Patterns» (Шаблоны корпоративных решений

для Microsoft .NET – шаблоны сервисов) по адресу http://msdn.microsoft.com/en-

us/library/ms998508.aspx.

 Более подробно шаблоны безопасности для Веб-сервисов рассматриваются в статье

«Web Service Security» по адресу http://msdn.microsoft.com/en-

us/library/aa480545.aspx.

Проектирование

размещаемых сервисов и

сервисов в облаке

Обзор

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

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

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

облаком (cloud), отсюда широко используемый термин обработка данных в облаке (cloud

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

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

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

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

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

привлекает и независимых поставщиков ПО (independent software vendors, ISV), и корпорации

как способ сокращения затрат, повышения эффективности и расширения возможностей.

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

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

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

использовании этого типа приложений.

Обработка данных в облаке

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

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

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

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

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

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

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

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

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

Многие организации смогли ощутить суммарные преимущества применения масштабируемых

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

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

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

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

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

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

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

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

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

доступности.

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

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

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

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

Разные провайдеры размещения в облаке предъявляют разные требования к модели

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

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

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

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

(как описывается позже в данной главе), а также для вычислений и взаимодействия. Тогда как

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

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

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

(Enterprise Resource Planning, ERP) или Управление отношениями с клиентами (Customer

Relationship Management, CRM). Каждый из упомянутых подходов обладает определенными

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

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

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

реализованный специально для этого UI. Некоторые из этих приложений поддерживают

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

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

REST или SOAP), т.е. могут быть интегрированы в другие приложения, которые, в свою очередь,

могут размещаться либо локально, либо удаленно. Некоторые размещаемые удаленно

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

приложения, и вообще не предоставляют UI.

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

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

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

 Бизнес-сервисы – это такие сервисы, как биржевые сводки и котировки акций, системы

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

информации.

 Сервисы розничной/оптовой торговли – это такие сервисы, как каталоги, системы

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

порталы.

 Сервисы хранения/обработки – это такие сервисы, как системы хранения и обработки

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

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

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

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

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

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

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

(Software plus Services, S+S). Под S+S понимается такой подход к разработке приложений,

который объединяет размещаемые сервисы и локально выполняемое ПО. Сочетание

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

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

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

Сервисно-ориентированную архитектуру (Service Oriented Architecture, SOA), ПО как сервис

(Software as a Service, SaaS), Платформа как сервис (Platform as a Service, PaaS) и сообщество-

ориентированные архитектурные подходы Web 2.0.

Обработка данных в облаке – новая область. В данной главе представлены некоторые

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

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

приложений и сервисов. В ближайшем будущем инфраструктуры, инструменты и среды

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

этих проблем.

Терминология размещаемых сервисов и сервисов в облаке

Рассмотрим некоторые термины, часто встречающиеся в данной главе, а также в сценариях с

использованием сервисов в облаке и размещаемых сервисов:

 Стандартный блок сервиса. Сервис, созданный для использования или интеграции с

другими приложениями или сервисами. Примером является сервис хранилища или

размещаемый Сервис маркеров доступа (Security Token Service, STS), такой как Сервис

управления доступом (Access Control Service) и Сервисная платформа Azure (Azure

Services Platform).

 Среда размещения в облаке. Среда, обеспечивающая основную среду выполнения для

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

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

учета, оплаты услуг и управления.

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

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

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

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

 Размещенное приложение. Приложение (коробочное или собственное), размещенное

как сервис. Оно может размещаться внутренне в вашей системе или внешне у партнера

или поставщика услуг размещения.

 Коробочное приложение. Приложение, созданное сторонним производителем или

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

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

 Платформа как сервис (Platform as a Service, PaaS). Базовая операционная система и

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

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

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

 ПО как сервис (Software as a Service, SaaS). Приложения, осуществляющие

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

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

приложения, кроме композиции и UI.

Преимущества приложений в облаке

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

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

обеспечивают преимущества большим корпорациям, как правило, являющимся

потребителями размещаемых решений и решений в облаке.

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

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

и предлагающих решения в облаке, являются:

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

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

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

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

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

пользователей, разрабатывающих сервисы.

 Насыщенное взаимодействие с пользователем. ISV и поставщики сервисов могут

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

счет применения существующих специализированных сервисов (таких как Virtual

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

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

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

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

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

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

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

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

пропускания.

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

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

Приведем некоторые примеры:

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

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

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

защитить дорогостоящую лицензию.

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

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

эластичность (способность расширяться по необходимости без больших исходных

инвестиций).

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

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

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

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

понадобится больших инвестиций в ИТ-оборудование и организацию сети.

Преимущества корпоративных потребителей сервисов

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

 Гибкость архитектуры. Собственные разработчики могут создавать законченные

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

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

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

 Экономия денежных средств и времени. Отделы ИТ могут выбирать наиболее

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

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

затраты на разработку. Кроме того, сокращение требований к собственной ИТ-

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

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

 Эффективность, обусловленная ростом масштабов использования. Компании могут

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

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

основной деятельности. Положительный эффект масштаба, обеспечиваемый

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

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

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

необходимо найти сбалансированное соотношение между выгодами от роста

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

полностью удаленным приложениям.

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

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

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

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

(настольного компьютера, мобильных клиентов и пр.) с минимальными

перенастройками сети.

Вопросы проектирования

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

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

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

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

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

 Безопасность данных

 Хранение и расширяемость данных

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

 Многотенантная архитектура

 Локально или удаленно, создавать или покупать

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

 Композиция сервисов

 Интеграция сервисов

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

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

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

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

 Отдельные базы данных. Каждый пользователь имеет собственную базу данных с

собственными схемами данных. Этот сценарий имеет преимущество простоты

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

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

стоимости обслуживания инфраструктуры. Такой вариант является наиболее

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

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

платы.