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

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

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

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

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

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

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

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

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

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

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

Управление удостоверениями. Операции по добавлению, обновлению и удалению пользователей должны быть перенесены на удаленные сервисы. Если внешний сервис

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

Данные. Требования операций с данными, таких как Extract, Transform, Load (ETL) и интеграция данных, должны быть проанализированы на предмет совместимости с возможностями сервисов. Размещаемые сервисы могут не поддерживать шаблоны хранения составных данных, что повлияет на дизайн сущностей данных и архитектуру приложения. Кроме того, возможно, понадобится предпринять дополнительные меры защиты данных, чтобы скомпенсировать недостаток физической безопасности, которая обеспечивалась при локальном размещении. Однако приложения могут хранить конфиденциальные или личные данные локально и использовать сервисы в облаке только для неконфиденциальных данных. Также необходимо спланировать процесс передачи данных провайдеру сервиса и то, как они будут передаваться другому провайдеру в случае возникновения такой необходимости.

Операции. Локальные сервисы интеграции и клиентские приложения могут быть несовместимыми с сервисами, предоставляемыми поставщиком сервисов, даже при использовании стандартных протоколов. Необходимо обеспечить поставщику сервисов возможность формировать соответствующие сведения отчетности и выработать стратегию интеграции этих данных с собственными системами управления и составления отчетов. Возможно, потребуется пересмотреть соглашения об условиях обслуживания (Service Level Agreements, SLA), чтобы обеспечить их выполнение в условиях все возрастающей зависимости от поставщика сервисов. Предприятия также должны быть готовы реализовать службу поддержки, которая будет выступать в роли первой инстанции для пользователей, и определить процедуры решения проблем с поставщиком сервисов.

Безопасность. Политики конфиденциальности предприятия должны быть совместимыми с политиками поставщика сервисов. Также должны быть обеспечены правила для действий, которые могут выполняться пользователями, такие как ограничения по размеру транзакции и другие бизнес-правила, даже если они не относятся к возможностям удаленного сервиса. Это может усложнить инфраструктуру интеграции сервисов. Также потребуются процедуры и политики для обеспечения безопасности и целостности данных в случае сбоя сервиса или подключения. Для аутентификации, шифрования и использования цифровых подписей необходимо будет приобрести сертификаты у сертифицированных поставщиков и, возможно, реализовать Инфраструктуру открытых ключей (Public Key Infrastructure, PKI). Кроме того, интеграция может потребовать внесения изменений в правила межсетевых экранов, а для

обеспечения фильтрации данных приложений и валидации XML-схемы понадобится обновление их оборудования и ПО.

Возможность подключения. Некоторым типам приложений в облаке, таким как сервисы оперативной обработки транзакций и сервисы реального времени (Передача голоса по IP (voice over IP, VoIP) и Microsoft Office Communications Server), для эффективной работы необходимо наличие широкополосного Интернет-подключения хорошего качества. В некоторых регионах и странах такое подключение может быть недоступным. Кроме того, сервисы, требующие больших объемов передачи данных, такие как сервисы архивации и доставки файлов, как правило, через сетевое соединение будут выполняться медленнее, чем при локальной реализации, чтоб может представлять проблему. Однако обмен сообщениями и другие подобные сервисы не так зависят от полосы пропускания и не так сильно страдают от периодической потери подключения.

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

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

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

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

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

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

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

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

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

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

	Категория			Шаблоны

Доступность данных	Polling (Опрос). Один источник, как правило, через равные промежутки
	времени опрашивает остальные о наличии изменений.
	Push (Выталкивание). Источник, данные в котором были изменены,
	передает изменения в приемник данных при каждом изменении данных или
	через равные промежутки времени.
	Publish/Subscribe. Смешанный подход, сочетающий в себе черты опроса и
	выталкивания. При внесении изменений в источник данных он публикует
	событие-уведомление об изменении, на которое может подписаться
	приемник данных.
Передача данных	Asynchronous Data Transfer (Асинхронная передача данных).
	Основанный на сообщениях метод, при котором отправитель и получатель
	обмениваются данными, не ожидая ответа.
	Synchronous Data Transfer (Синхронная передача данных).
	Интерфейсный метод, при котором отправитель и получатель обмениваются
	данными в режиме реального времени.
Преобразование	Shared Database (Совместно используемая база данных). Все
данных	интегрируемые приложения выполняют чтение данных напрямую из одной и
	той же базы данных.
	Maintain Data Copies (Хранение копий данных). Сохраняет копии базы
	данных приложения, чтобы другие приложения могли читать данные (и,
	возможно, обновлять их).
	File Transfer (Передача файлов). Доступность данных обеспечивается
	через передачу файла, являющегося фрагментом базы данных приложения,
	для того чтобы другие приложения могли загружать данные из файлов.
Интеграция и	Broker (Посредник). Скрывает детали реализации вызова удаленного
композиция	сервиса путем их инкапсуляции в другой слой, отдельный от бизнес-
	компонента.
	Composition (Композиция). Объединяет множество сервисов, приложений
	или документов в интегрированный интерфейс, обеспечивая при этом
	безопасность, валидацию, преобразование и связанные задачи для каждого
	источника данных.
	Portal Integration (Интеграция в портал). Создает приложение портала,
	которое отображает в унифицированном UI данные, извлекаемые из
	множества приложений. Пользователь может осуществлять необходимые
	задачи на основании данных, отображаемых в портале.
Производительность	Server Clustering. Организовывает инфраструктуру приложения таким
и надежность	образом, что используемые серверы представляются пользователям и
	приложениям как виртуальные унифицированные вычислительные ресурсы,
	что позволяет улучшить доступность и масштабируемость либо и то, и
	другое.
	Load-Balanced Cluster. Устанавливает сервис или приложение на множество
	серверов, конфигурированных для разделения рабочей нагрузки. Хосты с
	балансировкой нагрузки параллельно отвечают на запросы разных клиентов,
	даже на множество запросов одного клиента.
	Failover Cluster. Устанавливает приложение или сервис на множество
	серверов, конфигурированных так, чтобы замещать друг друга в случае
	отказа. Каждому серверу в кластере поставлен в соответствие, по крайней
	мере, один сервер этого кластера, который является резервным для него.