Построение гибридных приложений в облаке на платформе Windows Azure patterns & practices



Pdf просмотр
страница4/33
Дата28.11.2016
Размер8.44 Mb.
Просмотров6338
Скачиваний0
1   2   3   4   5   6   7   8   9   ...   33
Глава

Проблема

Технологии

Глава 2
«Развертывание данных и приложения Orders в облаке»

Развертывание функциональных возможностей и данных в облаке.
Синхронизация данных.
SQL Azure
Служба SQL Azure Data Sync
Служба SQL Azure Reporting
Windows Azure Marketplace (Рынок данных)
Служба Service Bus Relay
Глава 3
«Аутентификация пользователей в приложении
Orders»

Аутентификация пользователей и авторизация запросов в облаке.
Служба Windows Azure Access Control
Платформа Windows Identity Framework
Функциональный блок для обработки неустойчивых неисправностей в библиотеке
Enterprise Library
Глава 4
«Реализация надежного обмена сообщениями и информацией в облаке»

Коммуникации и доступ к сервисам без границ.
Служба Windows Azure Connect
Очереди шины интеграции
Топик и правила шины интеграции
Глава 5
«Обработка заказов в решении Trey Research»

Бизнес-логика и маршрутизация сообщений.
Очереди шины интеграции
Топик и правила шины интеграции
Глава 6
«Максимизация масштабируемости, доступности и эффективности приложения Orders»

Масштабируемость, производительность и доступность.
Служба Windows Azure Caching
Диспетчер трафика Windows Azure
Функциональный блок для автоматического масштабирования в библиотеке Enterprise
Library
Глава 7
«Мониторинг и управление приложением
Orders»

Мониторинг и управление.
Служба диагностики Windows Azure
Интерфейсы Windows Azure Management
REST API
Командлеты Windows Azure Management
Примечание
Некоторые из перечисленных функций и служб (например, роль виртуальной машины
Windows Azure, служба Windows Azure Connect и диспетчер трафика Windows Azure) на момент подготовки руководства были доступны только в виде предварительной или бета- версии. Актуальная информация представлена на домашней странице Microsoft Windows
Azure http://www.microsoft.com/windowsazure/
. Кроме того, в данное руководство не была включена подробная информация о ACS. Подробнее ACS обсуждается в «Руководстве
по идентификации на основе утверждений и управлению доступом»
(см. http://claimsid.codeplex.com/
), которое входит в серию руководств по Windows Azure.

38
Резюме
В этой главе вы познакомились с гибридными приложениями, использующими преимущества, которые предоставляет размещение в облаке. Облачные сервисы предоставляют широкий спектр возможностей для развертывания приложений в соответствии с моделями «платформа как услуга» (Platform as a Service, PaaS) и «инфраструктура как услуга» (Infrastructure as a Service, IaaS), а также целый ряд встроенных функций, позволяющих решить проблемы, которые могут возникнуть в процессе развертывания существующих приложений в облаке или разработки новых гибридных приложений, работающих частично локально и частично в облаке.
В этой главе также представлено онлайн-приложение Orders, которое Trey Research использует для обработки заказов, и приведен рассказ о том, как специалисты компании преобразовывали полностью локальное приложение в гибридное решение, некоторые компоненты которого работают в облаке, в то время как остальные по-прежнему развернуты в локальном центре обработки данных. Наконец, в этой главе содержится описание итоговой архитектуры приложения Orders, поэтому вы знакомы с результатом.
В последующих главах этого руководства приложение будет рассматриваться более подробно.
Мы предоставим гораздо больше информации о выборе подходящих технологий и о том, как специалисты
Trey Research решали различные задачи, и как эти решения могут быть расширены или адаптированы к другим ситуациям.
Вы увидите, как Trey Research модифицировала свое приложение с целью обеспечения его безупречной работы в рамках локальной и облачной сред, а также с целью интеграции с внешними компаниями- партнерами (чьи приложения также могут выполняться локально или в облаке), при помощи служб, предоставляемых платформой Windows Azure и СУБД SQL Azure.
Более подробная информация

На сайте данной серии руководств (
http://wag.codeplex.com/
) представлены ссылки на онлайновые ресурсы, примеры кода, практические занятия, обратная связь и многое другое.

Портал с информацией о Microsoft Windows Azure: http://www.microsoft.com/windowsazure/
Он содержит ссылки на официальные документы, инструменты и другие ресурсы. Вы также можете зарегистрироваться и получить здесь учетную запись Windows Azure.

Ответы на свои вопросы вы можете найти на форуме Windows Azure: http://social.msdn.microsoft.com/Forums/en-US/category/windowsazureplatform

Юджинио Пейс (Eugenio Pace), главный менеджер программ группы Microsoft Patterns &
Practices, отвечает за создание серии руководств по Windows Azure, к которой принадлежит этот документ. Более подробная информация о серии руководств представлена в блоге: http://blogs.msdn.com/eugeniop

Масаши Нарумото (Masashi Narumoto) является менеджером программ группы Microsoft
Patterns & Practices, работающей над руководствами по Windows Azure. Его блог: http://blogs.msdn.com/masashi_narumoto

Скотт Денсмор (Scott Densmore), ведущий разработчик группы Microsoft Patterns & Practices, пишет в своем блоге о разработке приложений для Windows Azure: http://scottdensmore.typepad.com/

Блог Стива Маркса (Steve Marx) http://blog.smarx.com/
— отличный источник информации и новостей о Windows Azure.

39

Программный код и документация, созданные в процессе работы над серией руководств по
Windows Azure, представлены на веб-сайте Codeplex Windows Azure Guidance: http://wag.codeplex.com/

Подробные рекомендации и примеры, иллюстрирующие возможности службы Windows Azure
Service Control Access, представлены в подготовленной группой Microsoft Patterns & Practices книге «Руководство по идентификации на основе утверждений и управлению доступом»
(
http://claimsid.codeplex.com/
).


40
Глава 2. Развертывание данных
и приложения Orders в облаке
Первый этап перемещения частей системы Orders в облако в качестве элементов гибридного приложения потребовал от проектировщиков компании Trey Research рассмотрения способов развертывания этих частей на технологической платформе Windows Azure. Для платформы
Windows Azure предлагается несколько вариантов развертывания функциональности приложения и широкий спектр связанных с этим служб, которые могут быть использованы решениями Trey Research при проектировании и построении гибридных приложений.
В этой главе вы узнаете, как компания Trey Research преодолела проблемы, связанные с развертыванием основных элементов приложения Orders в облаке, и как проектировщики связали это приложение со службами, предоставляемыми Windows Azure и технологической платформой SQL Azure.
Сценарий и контекст
В изначальной реализации приложения Orders компоненты и службы, которые оно использует, работают локально и обращаются к данным, хранящимся в локальных базах данных SQL Server в центре данных Trey
Research. Вы познакомились с архитектурой и описанием изначальной локальной реализации системы в главе 1
«
Сценарий Trey Research»
. Специалистам компании Trey Research необходимо было решить, как разделить функциональность, какие типы ролей Windows Azure использовать и как предложенная архитектура повлияет на безопасность, производительность и надежность приложения.
Помимо этого, проектировщики должны были решить, где и как будут размещены используемые приложением данные, когда некоторые части приложения будут размещены удаленно и взаимодействие с ними будет осуществляться через Интернет, и как обеспечить возможность формирования бизнес-отчетов по этим данным.
Когда они анализировали существующее приложение Orders с точки зрения переноса определенных частей в Windows Azure, стало очевидно, что модули приложения для управления и формирования отчетов, которым не требуется такое же масштабирование, как общедоступным сайтам, должны оставаться локальными. Это позволило компании Trey Research осуществлять более строгий контроль над теми функциями приложения, которые требуют повышенной безопасности, и теми, которые должны, по мнению специалистов компании, находиться в собственном центре данных исходя из соображений логистики. Однако компания Trey Research хотела, чтобы некоторые открытые части отчетных данных были доступны доверенным партнерам для использования в их системах.
Эта общедоступная часть приложения могла бы легко размещаться в облаке, как это и было выполнено в виде отдельного приложения, и эта часть приложения потребует наибольшего масштабирования в процессе использования для удовлетворения требований к расширению. Это позволило компании Trey
Research использовать все преимущества облака с точки зрения надежности, доступности, безопасности,

41 меньших эксплуатационных затрат, сниженных требований к локальной инфраструктуре и возможности быстрого масштабирования в обоих направлениях, чтобы выдержать требуемую пиковую нагрузку.
Есть и другие преимущества размещения в Windows Azure, которые являлись серьезными причинами для переноса общедоступных частей приложения Orders в облако. Среди них: возможность развертывания в нескольких центрах данных, находящихся в различных местах, чтобы обеспечить меньшее время ответа и максимизировать доступность для клиентов. Благодаря диспетчеру трафика
Windows Azure запросы к приложению автоматически направляются к тому экземпляру, который обеспечит более эффективную обработку с точки зрения пользователя. Диспетчер трафика также обрабатывает ошибки определенных экземпляров, перенаправляя запросы другим экземплярам.
Кроме того, компания Trey Research смогла воспользоваться преимуществами встроенной функции кэширования распределенных данных для временных данных, используемых веб-сайтами общего доступа, службы аутентификации на основе утверждений для простоты реализации федеративной аутентификации. Компания также воспользовалась функцией подключения для безопасной связи и доступа к службам через границы между локальной сетью и облаком, возможностями синхронизации данных, мощной облачной системой формирования отчетов и доступностью платформ и компонентов сторонних производителей для упрощения разработки.
Мнение Маркуса
Преимущества имеющихся компонентов, служб, платформ и функций, разработанных и оптимизированных для работы в облаке, упрощают разработку облачных приложений.

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

43
Развертывание данных и приложения Orders в облаке
Приложение Orders — это веб-сайт, поэтому проектировщики компании Trey Research понимали, что его можно легко развернуть в Windows Azure в виде веб-роли. Развертывание нескольких экземпляров веб- роли позволяет масштабировать веб-сайт в соответствии с требованиями и гарантирует необходимые компании Trey Research доступность и надежность. Задачи фоновой обработки, которые выполняются после того, как пользователь разместил заказ, передаются рабочей роли. Trey Research может развернуть несколько экземпляров рабочей роли, чтобы справиться с изменяющейся нагрузкой, когда клиенты размещают заказы на веб-сайте.
Мнение Маркуса
Вы разрабатываете новое веб-приложение или адаптируете существующее веб-приложение для Windows Azure практически так же, как разрабатываете элементы для локального размещения в собственном центре данных. Однако есть некоторые аспекты, которые отличаются, например управление состоянием сессии, хранение данных и конфигурация.
Веб-сайт Orders в процессе работы требует доступа к нескольким элементам данных. Эти данные включают список продуктов, которые может заказать покупатель, список клиентов, чтобы приложение могло аутентифицировать посетителя и получить доступ к информации о нем, заказах, которые покупатель размещает на веб-сайте, а также к информации о проведении аудита и записях журнала в реальном времени. Проектировщики из Trey Research должны были решить, где и как разместить все эти элементы и также выбрать подходящий механизм хранения этих данных.
Выбор размещения данных
Все элементы гибридного приложения, размещены ли они локально, в облаке или у партнеров, потребуют доступа к данным. Важной частью разработки гибридного приложения является размещение этих данных в соответствующих местах, чтобы максимизировать эффективность и производительность, при этом сохраняя безопасность и выполняя все требования к репликации и синхронизации. Как правило, данные должны быть расположены как можно ближе к приложениям и компонентам, которые их используют. Однако это не всегда рекомендуемо или возможно в зависимости от конкретных условий.
Основное решение — будут ли данные размещены локально или удаленно (например, в облаке или у партнеров). Приложение Orders использует четыре типа данных:

Информация о клиентах, включая такую важную информацию, как лимиты кредита и информация о платежах. В нее входит информация личного порядка (Personally Identifiable
Information, PII), которая должна быть защищена в максимальной степени.

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

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

Информация журнала аудита, такая как события и исключения, посланные приложением, и подробности о заказах общей суммой более 10 000 долл. США. Эти данные могут содержать важную информацию и должны быть полностью защищены от доступа сотрудников, не имеющих отношения к администрации.

44
Проектировщики компании Trey Research рассматривали три варианта размещения данных, используемых приложением Orders. Они могли развернуть все данные в облаке, оставить все данные локально или перенести некоторые данные в облако, а остальные сохранять локально.
Развертывание всех данных в облаке
Размещение всех данных в облаке, чтобы они были ближе к приложению Orders, поможет максимально повысить производительность и свести к минимуму время ответа, а также устранит необходимость синхронизации данных между облаком и локальным размещением. Это также позволит компании Trey
Research пользоваться преимуществами масштабируемости и производительности как служб хранения
Windows Azure Storage, так и SQL Azure, при этом и то, и другое хранилище данных обеспечивает надежный, быстрый и эффективный доступ к данным для приложения и при необходимости позволяет легко расширить доступность хранилища.
Однако развертывание всех данных в облаке будет означать, что приложения головного офиса будут вынуждены обращаться к данным через Интернет. Облачное размещение в этом случае приводит к тому, что сотрудники головного офиса сталкиваются с задержками и отказами связи в связи с работой в сети Интернет, а также с проблемами с производительностью. Кроме того, будут требоваться дополнительные расходы на доступ к данным из локальных приложений. К тому же, стоимость хранилища при размещении больших объемов данных или нескольких баз данных может стать слишком высокой, и вероятно потребуется синхронизация данных между этими размещениями, если приложение размещено в более чем одном центре данных.
Локальное хранение всех данных
Локальное хранение всех данных означает, что администраторам и операторам компании Trey Research будет проще управлять и гарантировать безопасность данных, особенно если большая часть операций обновления данных выполняется локально сотрудниками и другими приложениями организации. Этот подход позволяет компании Trey Research гарантировать соответствие законодательным и нормативным требованиям к размещению и безопасности важной информации. Кроме того, нет необходимости в переносе или развертывании данных удаленно, а другие операции, такие как резервное копирование данных, выполняются намного проще.
Однако хранение всех данных локально означает, что удаленные приложения и службы в облаке или у партнеров должны получать доступ к данным через Интернет, хотя с этой проблемой можно в некоторой степени побороться разумным применением кэширования. Проектировщики компании Trey Research также рассматривали вопрос, будет ли возможно реализовать требуемую бизнес-логику так, чтобы она работала надежно и безопасно, когда удаленные приложения и службы выполняют обновления нескольких баз данных через Интернет.
Мнение Джаны
Доступ к хранящимися локально данным из приложений, размещенных в облаке, как правило, не является лучшим подходом в связи с внутренней задержкой сети и ненадежностью Интернета. Если вы решили выбрать этот подход, то должны использовать надежный механизм кэширования, например кэширование Windows Azure, чтобы минимизировать влияние проблем сети.

45
Развертывание некоторых данных в облаке
Развертывание некоторых данных в облаке и хранение остальных локально имеет несколько преимуществ.
Например, данные для приложений и служб, которые требуют быстрого и надежного доступа, могут размещаться в облаке, ближе к приложению или службе, которые их используют, а данные, которыми пользуются в основном приложения головного офиса, могут оставаться локальными для обеспечения быстрого и надежного доступа для этих приложений. Помимо этого, данные, которые имеют законодательные или нормативные ограничения с точки зрения места их хранения или которые требуют реализации особого механизма обеспечения безопасности, могут оставаться локальными. И наконец, данные, которым не требуется масштабирование, могут оставаться локальными, уменьшая стоимость их размещения, а данные с необходимостью масштабирования могут быть размещены в хранилище Windows
Azure или SQL Azure, чтобы воспользоваться преимуществами этих служб в области масштабирования.
Однако развертывание некоторых данных в облаке означает, что в случае использования как облачными, так и локальными приложениями, доступ к ним должен быть реализован и через Интернет. Будет необходим достаточно надежный и безопасный механизм подключения, а также решение для репликации и синхронизации, чтобы обеспечить согласованность данных для всех размещений.
Как компания Trey Research выбирала место для развертывания данных
После рассмотрения различных вариантов развертывания данных компания Trey Research приняла следующее решение по размещению информации, используемой приложением Orders.
Данные клиентов
Информация о клиентах обрабатывается собственными операторами компании Trey Research при помощи локальной системы бухгалтерского учета, которую компания использует в пределах всей организации.
Компания Trey Research требует от клиентов регистрации через головной офис, и операторы добавляют клиентов в локальную базу данных. Планируется, что с использованием приложения Orders клиенты смогут изменять некоторую свою информацию (эта функциональность еще не реализована), но приложение не позволит им изменять критические данные удостоверений и прочие защищенные данные. Данные клиентов, скорее всего, будут относительно статичными и не будут сильно изменяться со временем.
Компания Trey Research решила сохранять главную базу данных клиентов локально для обеспечения максимальной безопасности и обеспечения возможностей эффективной работы с этими данными для всех локальных приложений. Однако данные о клиентах также необходимы веб-сайту Orders для аутентификации посетителей и для принятия от них заказов. Поэтому для максимизации производительности и надежности компания Trey Research решила разместить реплику данных о клиентах в облаке, ближе к веб-сайту Orders.
Это означает, что необходим двунаправленный механизм синхронизации для того, чтобы изменения данных клиента, внесенные локальными операторами, реплицировались во все центры данных, где размещается приложение Orders, а изменения некоторых данных клиентами с помощью приложения Orders реплицировались в главную локальную копию данных и в базы данных SQL Azure других центров данных.
Данные о продукции
Информация о продукции также обрабатывается операторами компании Trey Research. Эти данные могут обновляться только локально в связи с существующим локальным процессом производства и каталогами деталей, которые компания Trey Research использует во всей организации. Поскольку нет информации о запасах на складе (вся продукция изготовляется под заказ), данные о продукции относительно статичны.

46
Компания Trey Research решила сохранять основные данные о продукции локально для поддержки существующих возможностей эффективной работы с этими данными для всех локальных приложений.
Однако для максимизации производительности и надежности, компанией Trey Research было принято решение разместить реплику некоторых полей данных о продукции (только данные, необходимые для перечисления продукции, предоставления детальной информации о продукции и принятия заказа) в облаке, ближе к приложению Orders. Это означает необходимость реализации однонаправленного механизма синхронизации для обеспечения репликации обновления данных о продукции, произведенных локальными операторами, во все центры данных, где размещено приложение Orders.
Данные о заказах
Информация о заказах генерируется приложением Orders, которое запущено в облаке, и не может редактироваться ни в каком другом месте. Приложение Orders также обращается к данным о заказах для предоставления пользователям списка текущих заказов и информации о доставке. В отличие от данных о клиентах и продукции, которые являются относительно статичными, данные о заказах отличаются высокой динамичностью, поскольку они изменяются при размещении клиентом заказа и при доставке партнерами по транспорту.
В компании Trey Research решили, что не требуется размещать данные о заказах локально. Вместо этого данные о заказах размещаются только в облаке, ближе к приложению Orders. Однако, если приложение
Orders развернуто более чем в одном центре данных, необходима двунаправленная синхронизация данных о заказах между центрами данных, чтобы клиенты видели свою информацию о заказах, если они по причине отказа приложения перенаправлены в другой центр данных (или в случае, если пользователь меняет географическое расположение). Единственной проблемой этого решения является то, что компания Trey
Research не сможет более использовать службы формирования отчетов SQL Server для создания аналитических бизнес-отчетов непосредственно по данным. Далее в этой главе, в разделе «Выбор решения для формирования отчетов», вы узнаете, как в компании Trey Research решили эту проблему.
Данные журнала аудита
Информация журнала аудита генерируется приложением Orders в ответ на события и исключения, сгенерированные приложением, а также для заказов на общую сумму более 10 000 долл. США. Она также формируется другими локальными приложениями в компании Trey Research. Таким образом база данных
Audit Log для журнала аудита — это полное хранилище для всех служб управления приложением и контроля.
Компания Trey Research пришла к выводу, что поскольку наиболее интенсивный доступ к этим данными осуществляется из инструментов для контроля и приложений для административного управления, эти данные должны оставаться локальными. Кроме того, правительственные нормативы по продаже некоторых высокотехнологичных продуктов, которые выпускает компания Trey Research, подразумевают, что в Trey
Research должны иметь полную и точную информацию о таких продажах, а также сохранять ее локально.
Локальное хранение данных журнала аудита, который может содержать важную информацию о приложении, также позволяет обеспечить их полную безопасность от неавторизированного доступа в домене Trey Research.
Выбор механизма хранения данных
Определившись, что некоторые данные, используемые приложением Orders, будут размещены в Windows Azure, проектировщики компании Trey Research должны были определить подходящий механизм для хранения данных в облаке. Наиболее распространенные варианты — это хранилище
Windows Azure, SQL Azure, другая система баз данных или собственный репозиторий.

47
Хранилище Windows Azure
Хранилище Windows Azure позволяет хранить BLOB-объекты, таблицы и очереди. Очереди, как правило, используются для передачи информации между ролями и службами и не предназначены для использования в качестве механизма постоянного хранения. Однако компания Trey Research могла бы использовать хранилище таблиц или BLOB-объектов. И то, и другое является экономически эффективным способом хранения данных.
Хранилище BLOB-объектов идеально для хранения неструктурированной информации, такой как изображения, файлы и другие ресурсы. Хранилище таблиц идеально подходит для структурированной информации. Хранилище таблиц очень гибкое и может быть очень эффективным, особенно если структура таблицы разработана для обеспечения максимальной скорости обработки запросов.
Оно также поддерживает репликацию между различными географическими расположениями, чтобы обеспечить быстрый и эффективный доступ для различных месторасположений клиентов. Хранилище таблиц значительно дешевле использования базы данных SQL Azure.
Однако хранилище таблиц не поддерживает знакомую технологию SQL для чтения и записи данных, а также некоторые стандартные типы реляционных баз данных. Данные хранятся как коллекции объектов, которые подобны строкам, но каждая из них имеет первичный ключ и набор свойств. Эти свойства состоят из имени и набора типизированных пар значений. Проектировщики компании Trey Research понимали, что перенос существующего приложения, которое использует базу данных SQL, в облако и использование хранилища таблиц Windows Azure потребует переработки модели данных и переписывания некоторых частей кода, относящегося к доступу к данным. А это повлечет дополнительные финансовые и временные затраты на процесс переноса.
Кроме того, хранилище таблиц Windows Azure не поддерживает концепцию транзакций базы данных, хотя и обеспечивает доступ в виде транзакций к одной таблице. И наконец, данные не могут быть напрямую импортированы из системы реляционной базы данных, как например SQL Server, в хранилище таблиц.
Компании Trey Research было бы необходимо создать или заказать инструменты для преобразования и загрузки данных.
Примечание
Для получения дополнительных сведений об использовании хранилища таблиц Windows
Azure см. раздел «Хранение данных о бизнес-расходах в хранилище таблиц Windows Azure» главы 5 руководства «Перенос приложений в облако» на сайте http://msdn.microsoft.com/ en-us/library/ff803365.aspx#sec6
SQL Azure
SQL Azure — это служба базы данных с высокой производительностью, которая полностью поддерживает операции на основе SQL и может быть использована для создания в облаке реляционной базы данных.
Она реализуется экземплярами SQL Server, установленными в центрах данных корпорации Microsoft.
SQL Azure предлагает большую часть основной функциональности локального SQL Server и предоставляет данные приложению, используя знакомый протокол SQL Server – поток табличных данных (Tabular Data
Stream, TDS). Такая архитектура позволяет вам использовать тех же поставщиков данных .NET Framework
(таких как System.Data.SqlClient) для подключения к базе данных и T-SQL для доступа и работы с данными.
SQL Azure также совместим с существующими программными интерфейсами службы подключения, такими как Entity Framework (EF), ADO.NET и Open Database Connectivity (ODBC). Данные могут обновляться при помощи транзакций базы данных для обеспечения согласованности.

48
Эти преимущества позволяют разработчикам компании Trey Research избежать существенных изменений в коде приложений, а администраторам быстро и легко развернуть данные в SQL Azure без необходимости изменять схему таблиц. Администраторы и операторы компании Trey Research могут управлять базами данных SQL Azure при помощи портала управления Windows Azure и использования знакомых инструментов, таких как SQL Server Management Studio и инструменты баз данных Visual Studio. Также имеется ряд других инструментов для таких операций, как перенос и миграция данных, и инструменты командной строки для развертывания и администрирования.
Кроме того, синхронизация данных между локальными и размещенными в облаке базами данных реализуется легко с помощью службы Windows Azure Data Sync и программного интерфейса Data Sync API.
Формирование аналитических бизнес-отчетов SQL Azure поддерживает с помощью службы SQL Azure
Reporting.
Однако проектировщики компании Trey Research также должны были принять во внимание, что хотя
SQL Azure и очень похож на SQL Server, однако некоторые концепции, такие как элементы управления серверного уровня или управление физическими файлами неприменимы к таким автоматически управляемым средам как SQL Azure. К тому же цена подписки на SQL Azure выше, чем на хранилище
Windows Azure.
Альтернативные системы баз данных или собственный репозиторий
Если вы используете реляционную систему баз данных или собственный репозиторий для хранения данных, вы легко осуществите миграцию данных в SQL Azure, в зависимости от существующего формата данных. Если же вы используете систему баз данных отличную от SQL Server (например, Mongo DB, см. http://www.mongodb.org/
), вы сможете запустить эту систему управления базами данных в облаке с использованием рабочей роли Windows Azure или роли виртуальной машины.
Использование существующей системы управления базами данных или собственного репозитория, которые предоставляют доступ к данным для вашего приложения, означает, что вы, скорее всего, сможете использовать тот же код для доступа к данным, что и в локальной системе. Если разработчики знакомы с выбранным вами механизмом, это является преимуществом и поможет сократить время перехода и затраты на изучение новой системы.
Однако использование альтернативной системы управления базами данных или собственного репозитория означает, что вы должны самостоятельно обслуживать эту базу данных или репозиторий.
Например, вы должны будете устанавливать обновления программного обеспечения управления базами данных и отлаживать свой собственный код. Вы также можете столкнуться с трудностями при импорте и переносе данных в другие механизмы хранения данных в будущем.
Как компания Trey Research выбрала механизм хранения данных
Компания Trey Research использует SQL Server для хранения данных в локальных приложениях, включая приложение Orders. Форматы и типы данных, а также код доступа к данным предназначены для работы с SQL Server. Поэтому для компании Trey Research имело смысл использовать SQL Azure в качестве механизма хранения данных для гибридной версии приложения Orders. Дополнительные расходы в сравнении с использованием хранилища таблиц Windows Azure частично покрываются экономией на перепроектировании схемы и разработке кода.
Кроме того, в компании Trey Research хотели использовать транзакции базы данных и выполнять сложные запросы при работе с данными. Реализация кода для получения эквивалентной функциональности с использованием хранилища таблиц Windows Azure потребовало бы дополнительного времени на разработку и привело к дополнительным затратам. Администраторы компании Trey Research знакомы с SQL Server, включая инструменты для управления данными, и легко используют системы, основанные на SQL Server, поэтому работа с SQL Azure не требует изучения ими новых парадигм.

49
Шифрование данных в хранилище и базах данных Windows Azure
Проектировщики компании Trey Research осознали, что при перемещении данных в облако они должны будут рассмотреть необходимый уровень защиты данных независимо от выбранного механизма их хранения. Важные данные, такие как пароль и номер кредитной карты клиента, а также информация личного порядка, такая как адрес и номер телефона, как правило, требует более высокой степени защиты, чем такая информация, как список продукции.
На момент написания этой книги ни хранилище Windows Azure, ни SQL Azure не поддерживали встроенного механизма шифрования данных. Это означает, что за шифрование и дешифрование важных данных, которые требуют дополнительного уровня защиты, отвечает приложение. В компании Trey
Research этого достигли с использованием стандартных алгоритмов шифрования, предусмотренных на платформе .NET Framework, а также других библиотек кода.
Примечание
Сведения о шифровании данных в Windows Azure см. в статьях «Crypto Services and Data Security in Windows Azure» (Службы шифрования и безопасность данных в Windows Azure) на сайте MSDN
Magazine http://msdn.microsoft.com/Ben-us/magazine/ee291586.aspx и «Encrypting Data in
Windows Azure Storage» («Шифрование данных в хранилище Windows Azure») на сайте http://cm-bloggers.blogspot.com/2011/07/encrypting-data-in-windows-azure.html
. Для получения более подробной информации о функциях безопасности SQL Azure см. раздел «Security
Guidelines and Limitations (SQL Azure Database)» («Рекомендации и ограничения по безопасности
(база данных SQL Azure)») по адресу http://msdn.microsoft.com/en-gb/library/ff394108.aspx
Синхронизация данных между облачными и локальными
размещениями
Архитектура, которую компания Trey Research выбрала для приложения Orders, предполагает размещение некоторых данных в облаке в SQL Azure, а остальных — локально. Это значит, что разработчики компании Trey Research должны решить, как синхронизировать данные между этими размещениями для обеспечения их согласованности.
Выбор решения для синхронизации данных
Выбор решения для синхронизации данных зависит как от типа хранилища данных, где они находятся, так и от требований к согласованности данных. Например, если данные всегда должны быть синхронизированы между различными размещениями, это решение должно отследить и реплицировать изменения, как только они происходят. Если приложение может нормально работать, когда данные в конечном итоге согласовываются, но могут быть устаревшими на протяжении некоторого времени, тогда процесса запланированной синхронизации может быть достаточно. В следующем разделе этой главы представлены варианты, которые рассматривались в компании Trey Research для синхронизации данных приложения
Orders.
Синхронизация данных SQL Azure
Если данные развертываются в SQL Azure, естественным решением для синхронизации данных является использование службы SQL Azure Data Sync. Эта служба может синхронизировать данные между локальными базами данных SQL Server и одной или несколькими базами данных SQL Azure, размещенными в облаке.
Синхронизация данных SQL Azure предлагает множество вариантов однонаправленной и двунаправленной синхронизации.

50
Использование службы SQL Azure Data Sync подразумевает, что разработчикам компании Trey Research не понадобится писать собственный код, поскольку синхронизация настраивается и управляется при помощи веб-портала Windows Azure. Это позволяет снизить расходы и время, которые требуются на внедрение решения в сравнении с созданием собственного решения.
Однако служба SQL Azure Data Sync работает только с базами данных SQL Server и SQL Azure; она не может быть использована в случае, если данные находятся в хранилище Windows Azure или в другой системе баз данных. Кроме того, служба SQL Azure Data Sync накладывает некоторые ограничения на типы данных столбцов и на допустимость пустых значений, поэтому может потребоваться внесение изменений в существующие схемы базы данных. Служба SQL Azure Data Sync обрабатывает конфликтующие изменения, сделанные в различных базах данных с использованием одной из немногих предварительно определенных политик. Настраивать эти политики невозможно, и служба SQL Azure
Data Sync не предоставляет событий синхронизации для реализации вашего механизма.
Проектировщики компании Trey Research также осознали, что при некоторых сценариях синхронизации необходимо для завершения выполнить два прохода; эти данные сначала переносятся в центральную базу данных (которой может быть одна из существующих операционных бах данных), а затем в клиентские базы данных. Это означает, что в случае синхронизации нескольких баз данных с центральной некоторые экземпляры данных будут устаревшими до выполнения второго прохода синхронизации. Однако при простой синхронизации локальной базы данных с центральной базой данных SQL Azure все изменения выполняются за один проход.
Примечание
См.
«
Приложение A. Репликация, распространение и синхронизация данных»
, где представлена дополнительная информация об использовании службы SQL Azure Data Sync.
Платформа Microsoft Sync Framework
Для синхронизации данных служба SQL Azure Data Sync использует компоненты платформы Microsoft
Sync Framework. Мощная платформа синхронизации Sync Framework поддерживает любые типы данных, любые хранилища данных, любые протоколы передачи и любую топологию сети. Она не ограничена использованием только с базами данных SQL Server и SQL Azure.
Если бы разработчикам компании Trey Research нужен был больший контроль над процессом синхронизации, они могли бы использовать компоненты Sync Framework SDK непосредственно в коде.
Преимуществом такого подхода является то, что приложение может реагировать на события, такие как изменение данных, и инициировать синхронизацию. Это приложение могло бы также обрабатывать события, происходящие в процессе синхронизации для управления конфликтами и ошибками или для лучшего обеспечения отслеживания. Конечно, это также будет означать, что разработчики должны будут написать дополнительный код для управления процессом синхронизации, что повлечет дополнительные расходы и время в сравнении с использованием службы SQL Azure Data Syn.
Примечание
Дополнительная информация о Sync Framework SDK представлена в центре для разработчиков Microsoft Sync Framework (Microsoft Sync Framework Developer Center) по адресу http://msdn.microsoft.com/en-us/sync/bb736753

51
Собственное решение для синхронизации или использование решения стороннего разработчика
Если бы компания Trey Research решила не использовать службу SQL Azure Data Sync или платформу
Microsoft Sync Framework, проектировщики могли бы рассмотреть возможность разработки собственного решения или использования решения стороннего разработчика для синхронизации данных. В случае, если есть особые требования к синхронизации или репликации данных, собственный механизм может стать лучшим решением, чем готовое решение. Например, если компании Trey Research было бы необходимо выполнять особые виды синхронизации, которые не поддерживаются существующими решениями или службами от сторонних разработчиков, хорошим решением был бы собственный механизм, который передает сообщения между локальными службами и всеми центрами данных с использованием службы обмена сообщений через посредника шины интеграции Windows Azure.
Решение на основе службы обмена сообщениями является гибким и может быть использовано для различных типов репозиториев данных, поскольку служба, получающая сообщения об обновлении, может произвести операции обновления в репозитории с использованием соответствующих методов. Решения для репликации и синхронизации на основе системы обмена сообщениями особенно подходят для выполнения обновлений в реальном времени, однако это не является требованием для приложения Orders.
Помимо этого, решения для обмена сообщениями могут предоставлять дополнительную информацию о процессе синхронизации в ходе работы, например позволяя разработчикам отслеживать все модификации данных и обрабатывать конфликтные ситуации и ошибки соответствующим образом. Также возможно реализовать решение, которое следует принципам разделения очереди команд (Command Query
Responsibility Segregation, CQRS), отделяя запросы, извлекающие данные, от команд, которые изменяют данные в репозитории.
Однако, если вы не сможете найти готовое решение стороннего разработчика, которое предоставляет необходимые функции и может работать с используемыми вами хранилищами данных, и вы примите решение разработать собственное приложение, то это потребует дополнительного времени на разработку и повлечет расходы на внедрение, тестирование и отладку.
Примечание
См. «Приложение A. Репликация, распространение и синхронизация данных
»
для получения дополнительной информации о создании собственного решения для синхронизации данных на основе службы обмена сообщениями.
Как компания Trey Research выбрала решение для синхронизации
данных
Проектировщики компании Trey Research решили использовать службу SQL Azure Data Sync в качестве решения для репликации и синхронизации для приложения Orders. Все данные хранятся либо локально в базе данных SQL Server, либо в SQL Azure в облаке, поэтому служба SQL Azure Data Sync сможет получить доступ и синхронизировать все требуемые данные. Экономия средств и времени на разработку в сравнении с собственным решением компенсируется в некоторой степени использованием службы SQL Azure Data Sync.

52
Как компания Trey Research использует службу SQL Azure Data Sync
В компании Trey Research хранят информацию о продукции, клиентах и размещенных этими клиентами заказах. Компания Trey Research использует комбинацию локальной базы данных SQL Server и базы SQL
Azure, размещенной в каждом из центров данных для управления данными, необходимыми для приложения Orders. Поэтому компания Trey Research решила реализовать репликацию и синхронизацию данных в приложении Orders.
Этот раздел приведен только в информационных целях. Для простоты пример решения развернут в одном центре данных, поэтому не настроен на репликацию и синхронизацию между различными центрами данных.
Для различных типов информации, синхронизируемой в Trey Research, используются различные методы управления и хранения, а именно:

Данные о заказах размещаются только в облаке приложением Orders с использованием SQL
Azure и синхронизируются между центрами данных. Эта информации не направляется обратно в локальную базу данных.

Информация о продукции находится только в локальной базе данных SQL Server, но данные, необходимые для размещения заказа, регулярно копируются в каждую базу данных SQL Azure каждого центра данных.

Новые клиенты регистрируются локально, и их данные добавляются в базу данных SQL Server, которая находится в головном офисе. Эти данные реплицируются в базу данных SQL Azure в каждом центре данных, что позволяет клиентам входить и работать с приложением Orders без помощи системы головного офиса. В будущем, после того как учетная запись создана, в приложении Orders может быть разрешено клиентам изменять некоторые свои данные без необходимости вмешательства со стороны головного офиса, и эти изменения будут выполняться в базе данных SQL
Azure, размещенной в том центре обработки данных, к которому подключен клиент
(эта функциональность на данный момент не реализована, но в компании Trey Research хотели развернуть данные о клиентах с такими возможностями в будущем). Затем эти изменения будут передаваться назад в головной офис, а также реплицироваться во все остальные центры данных.
На рисунке 2 показано выбранное компанией Trey Research решение.

53
Рисунок 2
Репликация данных в приложении Orders компании Trey Research
В этом решении данные о продукции синхронизируются в одном направлении, от локального размещения в облако. Данные о заказах реплицируются двунаправленно между центрами данных. Данные о клиентах также реплицируются в обе стороны, но при этом задействованы как локальные базы данных, так и размещенные в центрах данных.

54
На рисунке 3 показана физическая реализация этих подходов на основе службы SQL Azure Data Sync.
Эта реализация использует четыре группы синхронизации. Каждая группа определяет набор данных для синхронизации и политику разрешения конфликтов для каждого типа данных (как описано выше, есть две перекрывающиеся группы синхронизации для репликации данных о клиентах). Базы данных SQL Azure расположены в центре данных на севере США и работают также в качестве центральной базы данных для синхронизации. Это ближайший центр данных к головному офису (головной офис компании Trey Research находится в Иллинойсе), поэтому выбор этого размещения позволяет снизить сетевую задержку при синхронизации с локальными базами данных.
Рисунок 3
Физическая реализация синхронизации данных для компании Trey Research

55
Следующая таблица подытоживает реализованную компанией Trey Research конфигурацию каждой группы синхронизации.
Имя и описание

Размещение
центральной
базы данных

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

Набор данных

Политика
разрешения
конфликта

Группа синхронизации
«Продукты»
Односторонняя синхронизация информации о продукции из локального размещения в облако
Центр данных на севере США
Головной офис
Синхронизация с центральной базой данных
Таблица Product
(для размещения заказа необходимы все столбцы)
Приоритет у центральной базы данных
Центр данных на юге
США
Синхронизация из центральной базы данных
Группа синхронизации
«Заказы»
Синхронизация данных о заказах между центрами данных в облаке в двух направлениях
Центр данных на севере США
Центр данных на юге
США
Двунаправленная
Таблицы с данными о заказах Order,
OrderDetail и OrderStatus
(все столбцы всех таблиц)
Приоритет у центральной базы данных
Группа синхронизации
«Клиенты»
Двунаправленная синхронизация информации о клиентах между локальным размещением и облаком
Центр данных на севере США
Головной офис
Двунаправленная
Таблицы с данными о клиентах
Customer и ACSIdentity
(все столбцы всех таблиц)
Приоритет у центральной базы данных
Центр данных на юге США
Двунаправленная
Примечание
Информация о каждом клиенте находится в двух таблицах: таблице Customer с общедоступной информацией о клиенте и таблице ACSIdentit с маркерами ACS, которые идентифицируют каждого клиента. Это необходимо, если сформировано несколько экземпляров ACS для аутентификации клиента; некоторые поставщики удостоверений возвратят различные идентификаторы пользователя ACS для каждого экземпляра. Поэтому база данных должна быть ассоциирована с более чем одним идентификатором ACS с каждой записью клиента.
Однако в примере решения, приведенного в данном руководстве, реализуется только один идентификатор ACS для каждого пользователя, который хранится в столбце UserName таблицы Customer базы данных Trey Research. Пример решения не содержит таблицу
ACSIdentity, поскольку идентификаторы ACS хранятся в столбце UserName таблицы Customer.

56
См. главу 3
«
Аутентификация пользователей в приложении Orders»
для получения дополнительной информации о том, как в компании Trey Research используют ACS для аутентификации пользователей.
Внедрение решения для формирования отчетов по данным,
размещенным в облаке
В некоторых случаях перенос функциональности в облако сделает невозможным использование существующих служб. Например, в исходной локальной версии приложения Orders компания Trey
Research для хранения всех корпоративных данных использовала SQL Server, а аналитические бизнес- отчеты формировались с помощью служб отчетов SQL Server. Однако, когда в компании Trey Research переместили исходные данные (базы данных заказов) в SQL Azure, проектировщики должны были понять, возможно ли использование локальной системы формирования отчетов. Теоретически возможно запускать систему формирования отчетов локально и подключаться к базе данных SQL
Azure через Интернет, однако этот подход, скорее всего, вызовет большую нагрузку на пропускную способность и приведет к снижению производительности.
Выбор решения для формирования отчетов
Проектировщики в компании Trey Research пришли к выводу, что следует найти лучшее решение для формирования аналитических бизнес-отчетов на основе размещенной в облаке базы данных заказов.
Следующие разделы этой главы посвящены рассмотренным компанией Trey Research вариантам решения для формирования аналитических бизнес-отчетов.
Службы отчетов SQL Server
Служба отчетов SQL Server — это функция SQL Server, которая позволяет получить комплексные аналитические бизнес-отчеты на основе данных, хранящихся в таблицах базы данных, а также в других источниках данных. Если вы используете SQL Server для хранения корпоративной информации, то службы отчетов SQL Server обеспечивают простое в использовании решение для создания отчетов.
Службы отчетов SQL Server могут считывать данные из реляционной, многомерной, основанной на XML и пользовательской баз данных и формировать отчеты в различных форматах, включая веб- ориентированный, предназначенный для печати и форматы компьютерных приложений. Они также поддерживают непосредственную публикацию отчетов в различные системы, такие как сервер отчетов, службы SharePoint, файловые службы общего пользования, внутренние архивные хранилища, а также приложения Office.
Службы отчетов SQL Server должны подключиться к источнику данных для анализа данных. Если источник данных удален по отношению к приложению, использующему отчет, процесс формирования отчета может генерировать значительный сетевой трафик, кроме того, может потребоваться служба, которая предоставит доступ к данным для использования службами отчетов SQL Server. Это может повлиять на безопасность источника данных, если он расположен удаленно от приложения, которое использует отчет.
Служба отчетов SQL Azure
Служба отчетов SQL Azure — это предоставляемая Windows Azure служба, которая позволяет генерировать различные аналитические бизнес-отчеты в общих веб-форматах и форматах для использования с Microsoft
Office. Если используется SQL Azure для хранения корпоративной информации, служба отчетов SQL Azure обеспечивают простое в использовании решение для создания отчетов.

57
Служба отчетов SQL Azure работает в том же центре обработки данных, что и база данных SQL Azure, поэтому сетевой трафик между службой отчетов SQL Azure и отображающим отчет приложением является минимальным. Это означает, что формирование отчетов будет происходить, скорее всего, намного быстрее и что будет обеспечиваться более высокая производительность по сравнению с подключением локального приложения для формирования отчетов к базе данных SQL Azure.
Хотя служба отчетов SQL Azure — это платная служба, требующая определенных расходов на покупку подписки, но их можно в определенной мере компенсировать за счет уменьшения расходов на трафик данных в локальную базу данных. Это решение также позволяет избежать изначальных расходов на разработку локальной системы формирования отчетов для организаций, которые не имеют такой системы. Также стоит принять к сведению, что служба отчетов SQL Azure менее интерактивна и обладает меньшими возможностями в сравнении со службами отчетов SQL Server и с другими решениями для формирования отчетов высокого класса, однако предлагаемый в ней набор форматов, как правило, достаточен для большей части возможных требований.
Мнение По
Широкий охват и актуальность информации являются жизненно необходимыми для всех компаний при управлении инвестициями, планировании использования ресурсов и контроле производительности бизнеса. Служба отчетов SQL Azure распространяет эти возможности на размещенные в SQL Azure данные.
Собственное решение для синхронизации или использование решения стороннего
разработчика
Также можно использовать любой существующий пакет или разработать собственное решение для анализа данных и формирования отчетов для гибридных приложений исходя из того, что выбранное решение может получить доступ к данным, хранящимся в базе данных приложения или репозитории.
Некоторым организациям может потребоваться собственное решение, которое интегрируется с другими приложениями или службами, или использовать существующее собственное решение или решение стороннего поставщика для создания аналитических бизнес-отчетов.
Собственное решение или решение стороннего поставщика можно точно настроить в соответствии с требованиями организации к отчетам, и такая сосредоточенность на конкретных областях интересов может обеспечить ускоренное формирование отчетов и эффективную общую производительность по сравнению с более общим решением. Разработанные под заказ решения сторонних поставщиков могут лучше подходить для специальных типов приложений и могут стоить меньше, чем более общее решение.
Использование существующего решения для формирования отчетов может снизить расходы на перенос приложения в облако. Однако в решении для формирования отчетов должна быть предусмотрена возможность подключения к облачному источнику данных без ущерба безопасности данных; это может потребовать от разработчиков создания дополнительных служб для предоставления данных. Кроме того, когда источник данных удален от приложения, которое использует отчет, процесс взаимодействия между ними может приводить к существенному сетевому трафику. И наконец, существующее решение или решение стороннего поставщика может не предоставлять всех необходимых форматов или такой же функциональности по сравнению со службами отчетов SQL Server и SQL Azure.

58
Как компания Trey Research выбрала решение для формирования отчетов
Когда компания Trey Research переместила приложение Orders в облако, проектировщики решили разместить данные, генерируемые приложением при размещении заказа, в SQL Azure. До этого перемещения в компании Trey Research использовались службы отчетов SQL Server для получения бизнес-информации из базы данных заказов.
Проектировщики в Trey Research решили, что возможным решением при удаленном размещении исходных данных может быть загрузка всех данных о заказах в локальные базы данных и использование служб отчетов
SQL Server для их анализа. Однако, если синхронизация данных не производится на регулярной основе, что требуют дополнительных расходов, операция передачи данных приведет к большему времени задержки при формировании отчетов. Этот подход может вызвать значительный сетевой трафик в Интернете, поскольку данные будут многократно запрашиваться при построении отчетов.
Вместо этого после переноса данных в SQL Azure, имеет смысл использовать возможности бизнес- аналитики службы формирования отчетов SQL Azure. Этот подход позволяет минимизировать сетевой трафик в Интернете, обеспечивает отображение в отчете последних данных без дополнительных задержек и позволяет предоставлять информацию отчетов в различных форматах.
Как в Trey Research используют службу отчетов SQL Azure
Локальная служба формирования отчетов использует службу отчетов SQL Azure для формирования отчетов, которые используются локальными приложениями управления. Компания Trey Research повысила полезность отчетов, комбинируя первичные данные из службы отчетов SQL Azure с потоками данных, которые предоставляет Windows Azure Marketplace.
На рисунке 4 показана реализованная компанией Trey Research архитектура.

59
Рисунок 4
Создание аналитических бизнес-отчетов с помощью службы отчетов SQL Azure
Примечание
Для простоты установки пример приложения в этом руководстве не включает реализацию службы отчетов SQL Azure. Для получения более подробной информации о службе отчетов SQL
Azure см. статью «Бизнес-аналитика» на сайте http://www.windowsazure.com/en- us/home/tour/business-analytics/.
Для получения более подробной информации об использовании внешних данных в отчетах см. статью «Как получить данные и приложения премиум-класса в одном месте» по адресу http://datamarket.azure.com/

60
Как компания Trey Research предоставляет данные отчетов внешним
партнерам
В компании Trey Research также решили предоставить данные отчетов конкретным пользователям, которые имеют доступ к локальной службе отчетов по Интернету с помощью службы Service Bus Relay.
Компания Trey Research решила разработать пробную версию этой функциональности, пока будет изучаться вопрос, какие типы информации можно предоставить внешним партнерам без угрозы коммерческой конфиденциальности бизнеса. Поэтому в этой первой версии компания Trey Research просто отобразила общую стоимость проданной продукции, разбитую по отчетным кварталам и регионам, как это определено в сервисном контракте в файле IOrdersStatistics.cs, который находится в папке Services проекта HeadOffice:
C#
[ServiceContract] public interface IOrdersStatistics
{
[OperationContract] double SalesByQuarter(int quarter);
[OperationContract] double SalesByRegion(string region);
}
Последующие версии этой службы могут предоставлять более детальную разбивку данных по продажам.
Приложение HeadOffice, которое работает локально в решении Trey Research, размещает службу WCF, которая называется OrderStatistics и реализует операции SalesByQuarter и SalesByRegion. Эти операции позволяют просто извлечь необходимые данные из основной базы данных и передать их назад в качестве возвращаемого значения. Реализация этой службы приведена в файле OrdersStatistics.cs в папке Services проекта HeadOffice.
Вызывающий эту службу код находится в методе OpenServiceHost в файле Global.asax.cs также в проекте
HeadOffice.
Примечание
Технология, применяемая в примере приложения для запуска службы OrderStatistics, может не подходить для всех веб-приложений и работает только в примере приложения, поскольку пользователь должен явно запустить веб-приложение, в котором содержится служба. В других случаях может быть предпочтительней использовать функцию автозапуска Auto-Start Windows
Server AppFabric для запуска службы. Для получения дополнительной информации см. статью
«Функция автозапуска» по адресу http://msdn.microsoft.com/en-us/library/ee677260.aspx
Эта служба доступна для внешних партнеров и пользователей через службу Windows Azure Service Bus Relay с использованием пути службы Services/RelayedOrdersStatistics, и приложение публикует службу через конечную точку TCP с использованием привязки netTcpRelayBinding. Подключение к шине интеграции безопасно благодаря ACS с использованием маркера аутентификации. В главе 3 «Аутентификация пользователей в приложении Orders» приводится более подробная информация о настройке ACS, а в разделе «Рекомендации по безопасности службы Windows Azure Service Bus Relay» в «Приложении
В. Реализация подхода ʺкоммуникации без границʺ» приводится руководство по аутентификации и авторизации партнеров при подключении к службе Service Bus Relay. Дополнительная информация о пространстве имен шины интеграции, пути службы, учетной записи для безопасного доступа и настройке службы хранится в файле web.config проекта. Обратите внимание, что веб-приложение подключается к шине

61 интеграции с помощью удостоверения с именем headoffice; это удостоверение предоставляет права, ассоциированные с утверждением Listen, что позволяет приложению получать входные запросы, но не разрешает выполнять другие операции, например отправку запросов.
XML











"SharedSecretBehavior" binding="netTcpRelayBinding" contract=
"HeadOffice.Services.IOrdersStatistics" name="RelayEndpoint"/>










"RelayedOrdersStatistics_Service"/>






62
Компания Trey Research также разработала простое приложение, работающее из командной строки, для проверки подключения к службе OrderStatistics через службу Windows Azure Service Bus Relay и проверки ожидаемой работоспособности операций SalesByQuarter и SalesByRegion. Это приложение находится в проекте ExternalDataAnalyzer. Это клиент WCF, который обеспечивает подключение к службе при помощи программного интерфейса шины интеграции Windows Azure SDK совместно с программным интерфейсом
Service Model WCF. Безопасность подключения к шине интеграции обеспечивается соответствующим маркером аутентификации. Определение конечной точки для подключения к службе и удостоверения для безопасного доступа находятся в файле app.config. Как и веб-приложение, проект ExternalDataAnalyzer подключается к шине интеграции с использованием особого идентификатора, externaldataanalyzer, которому предоставляются права, ассоциированные с утверждением Send, позволяя ему отсылать запросы в службу, но не позволяя производить другие действия, например получать запросы от других клиентов.
XML








"externaldataanalyzer" issuerSecret="" />







На рисунке 5 приведена общая структура и детали реализации службы OrderStatistics и клиентского приложения ExternalDataAnalyzer.

63
Рисунок 5
Структура службы OrderStatistics и клиентского приложения ExternalDataAnalyzer
Резюме
Эта глава посвящена развертыванию сценариев, относящихся к построению приложений, некоторые части которых работают локально, другие — в облаке, а какие-то части разработаны для внешних партнеров или самими партнерами. Эта глава посвящена трудностям развертывания, с которыми столкнулись в компании
Trey Research, например размещение данных локально или в облаке, синхронизация данных между различными размещениями, которые входят в гибридное решение, и формирование аналитических бизнес- отчетов.
Поскольку в компании Trey Research использовался SQL Server в первоначальной версии приложения
Orders, развертывание данных в SQL Azure и использование службы SQL Azure Data Sync для поддержания соответствия и репликации основных данных — это простой и естественный процесс переноса приложения в облако.
И наконец, при выборе SQL Azure для хранения данных в облаке, служба отчетов SQL Azure — это очевидный выбор для реализации решений бизнес-аналитики и формирования отчетов для Trey
Research, а служба Service Bus Relay обеспечивает идеальный механизм для публикации данных отчетов для компаний-партнеров.

64
Дополнительная информация

Обзор возможностей Windows Azure на сайте http://www.windowsazure.com/en-us/home/tour/overview/

Центр разработчика Windows Azure «Windows Azure Developer Center» по адресу http://www.windowsazure.com/en-us/develop/overview/

Обзор синхронизации данных SQL Azure «SQL Azure Data Sync Overview» на сайте http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-data-sync-overview.aspx

Часто задаваемы вопросы по синхронизации данных SQL Azure «SQL Azure Data Sync FAQ» по адресу http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-data-sync-faq.aspx

Служба SQL Azure Data Sync — синхронизация данных между локальным размещением и облаком
«SQL Azure Data Sync — Synchronize Data across On-Premise and Cloud (E2C)» по адресу http://channel9.msdn.com/Series/SQL-Azure-Data-Sync/SQL-Azure-Data-Sync-Synchronize-Data-across-
On-Premise-and-Cloud-E2C

Синхронизация SQL Server с SQL Azure при помощи Sync Framework 2.1 «SQL Server to SQL Azure
Synchronization using Sync Framework 2.1» по адресу http://blogs.msdn.com/b/sync/archive/2010/08/31/sql-server-to-sql-azure-synchronization-using-sync- framework-2-1.aspx

Бизнес-аналитика для формирования отчетов в SQL Azure «Business Analytics» по адресу http://www.windowsazure.com/en-us/home/tour/business-analytics/

Как получить данные и приложения премиум-класса в одном месте «One-Stop Shop for Premium
Data and Applications» на сайте http://datamarket.azure.com/

Начальные сведения о службе Service Bus Relay «Windows Azure AppFabric: An Introduction to Service
Bus Relay» по адресу http://www.microsoft.com/en-us/showcase/details.aspx?uuid=395930db-6622-
4a9f-8152-e0cb1fc5149c

1   2   3   4   5   6   7   8   9   ...   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал