Azure Service Platform

Автор Дэвид Чеппел

Перевод Николая Курносова

Обзор платформы

Использование компьютеров в облаке часто может быть очень неплохой идеей. Вместо того, чтобы покупать и обслуживать свое собственное железо, почему бы не использовать «тонны» серверов, доступных и предлагаемых сегодня через интернет? Для некоторых приложений и код, и данные – и то, и другое может жить в облаке, где кто-то другой поддерживает и обслуживает используемые ими системы. В других случаях приложения, которые работают внутри организации - локальные (on-premises) приложения, могут хранить свои данные в облаке или использовать другую инфраструктуру из облака. Приложения, которые работаю на десктопах или мобильных устройствах могут использовать сервисы в облаке для синхронизации данных между разными системами или в каких-то других целях.

В любом случае, работает ли приложение само в облаке или использует сервисы, предоставленные облаком, либо оба варианта, нужно что-то типа платформы для таких приложений. Смотря шире, под платформой для приложений можно понимать все, что предоставляет разработчику службы для создания приложений. Для примера, в локальном мире Windows это включает такие технологии как .NET  Framework, SQL  Server и т.д. Чтобы приложения могли использовать облако должна существовать облачная платформа для приложений. И поскольку есть много разных применений облака для приложений, разные виды облачных платформ полезны в разных ситуациях.

Microsoft  Azure  Services  Platform - это группа облачных технологий, каждая из которых предоставляет определенный набор сервисов для разработчиков. На рис.1, Azure  Services  Platform может использоваться как приложениями, работающими в облаке, так и работающими на локальной системе.

Рис.1. Azure  Services  Platform поддерживает приложения, работающие как в облаке, так и на локальной системе.

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

●     Windows  Azure: Предоставляет основанную на Windows среду для выполнения приложений и хранения данных на серверах в дата центрах Microsoft;

●     Windows  .NET  Services: Предоставляют распределенные инфраструктурные сервисы для облачных и локальных приложений.

●     Microsoft  SQL  Services: Предоставляет сервисы для работы с данными, основанные на SQL Server.

●     Live  Services: Через Live  Framework предоставляет доступ к данным из приложений на Microsoft  Live. Live  Framework также позволяет синхронизировать эти данные между десктопами и устройствами, искать и загружать приложения и другое.

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

Windows Azure

На высоком уровне понять Windows  Azure очень просто: это платформа для запуска Windows приложений и хранения данных приложения в облаке. На рис.2 – основные ее компоненты.

Рис.2. Windows  Azure предоставляет сервисы для выполнения и
хранения данных облачным приложениям.

Как видно из рисунка, Windows  Azure работает на большом количестве машин, расположенных в дата центрах Microsoft и доступных через интернет. Фабрика Windows  Azure связывает весь этот избыток вычислительной мощи в единое целое. Сервисы хранения данных и выполнения Windows  Azure построены поверх этой фабрики.

Сервисы выполнения Windows  Azure основаны, конечно, на Windows. Для первоначальной доступной версии (CTP стал доступен публике осенью 2008), Microsoft разрешила Windows  Azure запускать только приложения, основанные на .NET  Framework. Компания анонсировала планы по поддержке также и неуправляемого кода, то есть приложений, не построенных на .NET  Framework, в Windows  Azure в 2009.

В CTP версии Windows  Azure, разработчики могут создавать основанные на .NET приложения, такие как ASP.NET приложения и WCF-сервисы. Для этого они могут использовать C# или другие .NET-языки вместе с традиционными средствами разработки типа Visual  Studio  2008. И хотя большинство разработчиков, скорее всего, будет использовать первоначальный версию Windows  Azure для создания web-приложений, платформа так же поддерживает и фоновые процессы, которые работаю независимо от web-части – это не только платформа для web-приложений.

И приложения Windows  Azure, и локальные приложения, могут использовать сервисы хранения данных Windows  Azure, в обоих вариантах одним и тем же способом – с использованием механизма типа REST. Однако, используемое хранилище данных – это не SQL Server. В частности, это даже не реляционная система и ее язык запросов – не SQL. Поскольку система хранения спроектирована для поддержки приложений на Windows  Azure, она предоставляет более простые, более масштабируемые виды хранилищ. Соответственно, оно позволяет хранить большие бинарные объекты (блобы), предоставляет очереди для взаимодействия между компонентами приложений Windows  Azure, и даже представляет что-то типа таблиц с обычным языком запросов.

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

Но получение этих выгод требует правильного управления. В Windows  Azure, у каждого приложений есть конфигурационный файл – рис. 2. Изменяя информацию в этом файле, руками или программно, владелец приложения может контролировать различные аспекты его поведения, такие как количество работающих экземпляров Windows  Azure. Фабрика Windows  Azure мониторит приложение, чтобы поддерживать заданное состояние.

Чтобы позволить клиентам создавать, конфигурировать и мониторить приложения, Windows  Azure предоставляет доступный через браузер портал. Клиент предоставляет свой Windows  Live  ID, затем выбирает, создать ли хостинг аккаунт для выполнения приложений или аккаунт хранилища для хранения данных, либо оба. Приложение свободно в выборе способа взимания платы со своих клиентов – подписка, плата за каждое использование или что-то еще.

Windows  Azure это общая платформа, которая может использоваться в различных сценариев. Вот несколько примеров, основанных на том, что позволяет CTP:

●     Стартап, создающий новый сайт, например новый ВКонтакте (в оригинале – Facebook*:) , может построить свое приложение на Windows  Azure. Поскольку платформа поддерживает и Web-facing сервисы и фоновые процессы, приложение может предоставить как интерактивный пользовательские интерфейс, так и асинхронное выполнение работ для пользователей. Вместо того, чтобы тратить время и деньги, беспокоясь о инфраструктуре, стартаперы могут сфокусироваться исключительно на создании кода, который значим для их пользователей и инвесторов. Приложение также может стартовать в небольшом размере, требующем небольшие затраты пока у него немного пользователей. Если приложение «пойдет» и его использование возрастет, Windows  Azure смасштабирует приложение как потребуется.

●     ISV создающий SaaS версию существующего локального .NET приложения может построить его на Windows  Azure. Поскольку Windows  Azure в основном предоставляет стандартное .NET окружение, перенос приложения бизнес-логики приложения на облачную платформу не породит множество проблем. И опять же, разработка на существующей платформе, позволит ISV сфокусироваться на бизнес-логике – именно том, что приносит ему деньги – вместо того, чтобы тратить время на инфраструктуру.

●     Корпорация, создающая приложение для своих клиентов может выбрать Windows  Azure. Поскольку Windows  Azure основана на .NET, то и найти подходящих разработчиков будет не сложно, и стоить они будут не «зверски» дорого. Выполнение приложений на площадках Microsoft освобождает корпорацию от ответственности и затрат поддержки своих собственных северов, превращая капитальные затраты в оперативные. Особенно если у приложения есть пики использования – например, если это онлайн магазин цветов, который обязан выдерживать 8-мартовский наплыв (в оригинале – Mother’s  Day) – позволить Microsoft обслуживать большую серверную базу для этого может иметь экономический смысл.

Выполнение приложений в облаке это один из самых важных аспектов облачных вычислений. С Windows  Azure, Microsoft предоставляет платформу для этого, вместе со способом хранения данных приложения.

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

.NET Services

Выполнение приложений в облаке это важная часть облачных вычислений, но это далеко не все, что скрывается под этим термином. Так же можно предоставлять сервисы, основанные на облаке, которые могут использоваться или локальными, или другими облачными приложениями. Решение этой задачи – цель .NET  Services.

Изначально известные как BizTalk  Services, .NET  Services решают основные инфраструктурные проблемы при создании распределенных приложений. На рис.3 – компоненты.

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

Компоненты .NET  Services:

●     Access  Control (контроль доступа): Все более частый способ идентификации – когда каждый пользователь приложению токен, содержащий набор утверждений (claims) . Приложение теперь может решить, что разрешено этому пользователю, основываясь на предоставленных утверждениях.

●     Service  Bus (сервисная шина): Открытие доступа снаружи к сервисам приложения сложнее чем думает большинство. Цель сервисной шины в том, чтобы сделать это проще за счет открытия конечных точек веб-сервисов, которые будут доступными другим локальным или облачным приложениям. Каждой открытой наружу точке доступа назначается URI, который клиенты могут использовать для нахождения и доступа к сервису. Сервисная шина также решает проблемы работы с NAT (Network  Address  Translation) и прохождение через файрволлы без открытия нового порта для каждого открытого наружу приложения.

●     Workflow: Создание композитных приложений, таких как приложения для интеграции enterprise-приложений, требует логики, координирующей взаимодействие между различными частями системы. Такая логика часто лучше всего реализуется за счет workflow, способного поддерживать продолжительные процессы. Построенный поверх Windows  Workflow  Foundation, сервис Workflow позволяет использовать логику такого типа в облаке.

Вот несколько примеров того, как могут использоваться .NET  Services:

●     ISV, который предоставляет приложение, используемое клиентами в различных организациях может использовать Access  Control для упрощения разработки и работы приложения. Для примера, этот компонент .NET  Services может преобразовывать разнообразные утверждения (claims), используемые в различных организациях клиентов, каждая из которых использует у себя разные технологии идентификации, в единообразный набор, который будет использовать разрабатываемое приложение. Также это позволяет перенести работу identity  federation на сервис Access  Control в облаке, что освобождает ISV от необходимости запускать свое локальное federation  software.

●     Представьте корпорацию, желающие дать приложениями своих торговых партнеров доступ к одному из своих приложений. Она может открыть функции приложения через SOAP или REST веб-сервисы, затем зарегистрировать их конечные точки в Service  Bus. Торговые партнеры теперь могут использовать Service  Bus для того, чтобы найти эти открытые сервисы и получить доступ к ним. Поскольку это не требует разрешение новых портов в файрволле организации, то это снижает риск от открытия приложения. Организация также может использовать Access  Control, который разработан для работы с Service  Bus, для приведения к общему виду идентификационных данных, которые клиенты посылают приложению.

●     Вполне вероятно, что рассмотренный выше бизнес-процесс, включающий ее торговых партнеров, обязан выполняться целостно. Для этого можно использовать сервисы Workflow для реализации WF - приложения, которое будет управлять процессом. Приложение может взаимодействовать с партнерами через Service  Bus и положиться на Access  Control в приведении идентификационных данных к общему виду.

Как и при работе с Windows  Azure, есть доступный через браузер портал, который позволяет клиентам подписаться на .NET  Services используя Windows  Live  ID. Цель Microsoft с их .NET  Services проста и понятна: предоставить полезную облачную инфраструктуру для распределенных приложений.

SQL Services

Один из самых привлекательных способов использования доступных в Интернете серверов – это работа с данными. Конечно, обычно это означит предоставление движка баз данных, но не всегда дело ограничивается только этим. Цель SQL  Services – предоставить набор облачных сервисов для хранения и работы с большим количеством разнообразных видов данных, от реляционных до неструктурированных.

Microsoft говорит, что SQL  Services будут включать разные сервисы, связанные с данными, такие как отчеты, анализ данных и т.д. Однако, самый первый компонент - это SQL  Data  Services.

Идея – на рис. 4.

Рис. 4. SQL  Services предоставляет сервисы для работы с данными в облаке.

SQL  Data  Services, ранее известные как SQL  Server  Data  Services, предоставляют базы данных в облаке. Как видно из рисунка, эта технология позволяет локальным и облачным приложениям хранить и получать доступ к данным на серверах Microsoft в дата центрах Microsoft. Как и с другими облачными технологиями, организация платит только за то, что она использует. Использование (и цена) увеличивается и уменьшается в соответствии с потребностями организации. Использование баз данных в облаке так же позволяет преобразовать то, что было бы капитальными затратами типа инвестиций в жесткие диски или системы управления базами данных, в оперативные затраты.

Основная цель SQL  Services – быть максимально доступными. Для этого она делает доступными интерфейсы как через SOAP, так и через REST, что позволяет подучить доступ к данным самыми разными способами. И поскольку данные доступны через стандартные протоколы, SQL  Data  Services могут использоваться на самых разных системах – это не только Windows технология.

В отличии от сервисов хранения Windows  Azure, SQL  Data  Services построены на Microsoft  SQL  Server. Не смотря на это, сервис не доступен через обычный реляционный интерфейс. Вместо этого, SQL  Data  Services предоставляют иерархическую модель данных, которая не требует предопределенной схемы данных. Каждый элемент данных в этом сервисе хранится как свойство со своим именем, типом и значением. Для запроса этих данных можно использовать запросы в стиле REST или LINQ.

Сразу встает очевидный вопрос, почему бы просто не предложить SQL  Server в облаке? Зачем вместо этого предоставлять облачный сервис баз данных, который использует совсем другие методы, чем те к которым мы все привыкли? Один из ответов состоит в том, что предоставление немного отличный от привычного набор сервисов дает некоторые преимущества. SQL  Data  Services могут предоставить большую масштабируемость, доступность и надежность, чем дал бы простой запуск СУБД в облаке. Тот способ, которым новые сервисы организуют и получают данные, делают репликацию и балансировку нагрузки гораздо более легкой и быстрой, нежели с обычными реляционным способом. Другое преимущество состоит в том, что SQL  Data  Services не требуют от клиентов, чтобы те поддерживали свои собственные СУБД. Вместо того, чтобы заботиться о технических деталях, типа мониторинга использования жестких дисков, обслуживания логов, определения необходимого количества экземпляров и т.д., пользователи SQL  Data  Services могут сфокусироваться на главном – на данных. В конце концов, Microsoft анонсировала планы о добавлении новых реляционных фич в SQL  Data  Service, так что ожидайте роста их функциональности.

SQL  Data  Services могут использоваться самыми разными способами, вот несколько примеров:

●     Приложение может хранить старые архивные данные в SQL  Data  Service. Для примера, представьте приложение, которое предоставляет часто обновляемую RSS ленту. Информация старее, допустим, 30 дней вряд ли будет запрашиваться часто, но она все равно должна быть доступна. Перенос таких данных в SQL  Data  Service может быть дешевой и надежной альтернативой их локальному хранению.

●     Представьте производителя, который хочет сделать информацию о своих продуктах доступной как его сети дилеров, так и клиентам напрямую. Хранения таких данных в SQL  Data  Services позволит обеспечить доступ к данным как приложениям, которые работают у дилеров, так и web-приложению для клиентов, которое работает у самого производителя. Поскольку данные доступны и через REST, и через SOAP, то приложения, которые используют эти данные, могут быть написаны на разных технологиях и для разных систем.

Как и с другими компонентами Azure  Service  Platform, начать использовать SQL  Data  Services просто – нужно идти на портал и заполнить там нужную информацию. Для дешевого архивного хранения, предоставления доступа к данным приложениям, расположенных в разных местах, или с другими целями, облачные базы данных могут быть очень привлекательным решением. С появлением новых технологий под эгидой SQL  Services, компании смогут использовать облако для все большего количества задач, связанных с данными.

Live Services

Если идея облачной платформы относительно нова, то интернет совсем нет. Сотни миллионов людей по всему свету используют его каждый день. Чтобы помочь им в этом, Microsoft предоставляет постоянно расширяющийся набор веб-приложений, включая семейство приложений Windows  Live и другие. Эти приложения предоставляют пользователям возможность слать мгновенные сообщения, хранить контактную данные, получать маршруты и делать другие полезные вещи.

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

Для того, чтобы это стало возможным, Microsoft собрала весь этот разнообразный набор ресурсов в одну группу – Live  Services. Существующие приложения Microsoft, типа семейства Windows  Live, использую Live  Services для хранения и управления своими данными. Чтобы дать возможность новым приложениям использовать эти данные, Microsoft предоставляет Live  Framework. Основные аспекты – на рис. 5.

Рис.5. Live Framework предоставляет приложениям доступ к данным Live Services,
при необходимости синхронизируя эти данные между десктопами и мобильными устройствами.

ФундаментLive  Framework – это Live  Operating  Environment. Как видно из рисунка, этот компонент выполняется в облаке и приложения получают через него доступ к данным Live  Services. Доступ к данным происходит через HTTP, то есть любые приложения на .NET, Java, javaSAFEscript или других языках могут получить доступ к данным Live Services. Также информация из Live Services может быть получена через Atom или RSS, что позволяет приложениям узнавать об изменениях этих данных. Для настройки и управления функциями Live Services, которые нужны конкретному приложению, разработчик может использовать веб-портал Live  Services  Developer  Portal.

На рис. 5 показан так же другой аспект Live  Framework – Live  Operating  Environment, который так же может выполняться и на системах с Windows  Vista, Windows  XP, Mac  OS  X и Windows  Mobile устройствах. Чтобы использовать эту фичу, пользователь группирует все систему в одну штуку, известную как меш (mesh). Для примера, можно создать меш, который содержит ваш десктоп, ноутбук и сотовый. На каждом из устройств будет выполняться экземпляр Live  Operating  Environment.

Самая главная характеристика меша – это то, что Live  Operating  Environment синхронизирует данные между всеми системами, входящими в него. Пользователи и приложения могут указать, какие данные должны быть синхронизированными, и Live  Operating  Environment автоматически обновит все десктопы, ноуты и мобильные устройства, входящие в меш, данными, которые были изменены на одном из устройств. И поскольку облако это тоже часть любого пользовательского меша – оно представляется там как специальное устройство – то синхронизация работает и для данных Live  Services. Для примера, если пользователь хранит свои контакты в Windows  Live  Hotmail, Windows  Live  Messenger или Windows  Live Contacts, то они будут синхронизированы между всеми устройствами меша. (Правда в ноябрьском CTP  Live  Framework эта возможность еще не работает). Через Live  Operating  Environment также можно давать доступ к каким-то своим данным другим пользователям, что позволяет выборочно делиться какой-либо информацией.

Как показывает рис. 5., приложение может обращаться к данным меша через локальный или облачный экземпляр Live  Operating  Environment. В обоих случаях доступ производится одним и тем же способом – через HTTP-запросы. Такое единообразие доступа дает приложению одинаково работать не зависимо от наличия соединения с облаком, в любом случае данные достуны и обращаться к ним можно тем же способом.

Любое приложение, работает ли оно на Windows или другой операционной системе, может обращаться к данным Live  Services в облаке через Live  Operating  Environment. Если приложение работает на устройстве, которое является частью меша, она может использовать Live  Operating  Environment для обращения к локальным копиям данных Live  Services. Есть и третья возможность – разработчик может сделать штуку, которая называется Mesh-Enabled  Web  Application. Такие приложения создаются с помощью кроссплатформенных технологий типа Silverlight и они обращаются к данным через Live  Operating  Environment. Благодаря таким ограничениям, Mesh-Enabled  Web  Application может потенциально запускаться на любой машине пользовательского меша – Windows машине, Маке, коммуникаторе с Windows  Mobile и она всегда будет иметь доступ к одним и тем же синхронизированным данным. Для поиска таких приложений, среда Live  Framework предоставляет облачное приложение – каталог mesh-enabled web-приложений. Пользователь может посмотреть каталог, выбрать приложение и установить его. И чтобы дать создателям приложений возможность построить бизнес на таких приложениях, Microsoft планирует предоставить встроенную поддержку показа рекламы в их приложениях.

Вот примеры разнообразных способов применения Live  Framework:

●     Java приложение, работающее на Linux, может использовать Live  Framework для работы с контактами пользователя. Приложение не завязывается на какой-то технологии, через которую открыт доступ к этим данным; все, с чем оно работает - это постоянный HTTP интерфейс к пользовательским данным.

●     Приложение на .NET может требовать от пользователя создания меша, а затем использовать Live Framework для кэширования и синхронизации данных. Когда у машины, на которой работает приложение, есть связь с интернетом, приложения работает с копией данных в облаке. Когда связи нет – например при работе на ноутбуке в самолете – приложение использует локальную копию тех же данных. Live Operating  Environmentреплицирует изменения локальных данных в облако.

●     ISV может сделать Mesh-Enabled  Web  Application , которое позволяет пользователям узнавать, чем занимаются их друзья. Это приложение может работать без изменений на всех устройствах пользователя, использовать разные части Live  Framework для социальных приложений. Поскольку Live  Framework поддерживает открытие доступа к пользовательским данным в меше через RSS, то приложение, может, например, подписаться и следить за обновлениями от любого из друзей пользователя. Поскольку Live  Framework предоставляет механизм доставки для mesh-enabled web-приложений, то возможно «вирусное» распространения приложения, когда пользователи приглашают своих друзей пользоваться этим приложением. И поскольку в меше уже есть данные о контактах пользователя из Live  Services, то пользователя может приглашать друзей через само приложение просто по имени, а заботиться о том, чтобы доставить приглашение друзьям, будет уже само приложение.

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

Детальный взгляд на технологии

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

Windows Azure

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

Выполнение приложений

В Windows  Azure приложение обычно имеет несколько экземпляров, каждая из которых выполняет часть или весь код приложения. Каждый из экземпляров работает на своей виртуальной машине. Все виртуалки работают под Windows  Server  2008 и они предоставлены гипервизором, специально разработанным для использования в облаке.

В то же время, приложение на Windows  Azure не видит виртуальную машину, на которой она работает. Разработчик не может предоставить свой образ виртуальной машины, чтобы Windows  Azure работала на нем, но ему и не нужно заботиться о поддержке этой копии Windows. Вместо этого, CTP версия дает разработчикам создавать .NET 3.5 приложения с двумя типа экземпляров – одна выполняет Web  Role другая Worker  Role. На рис.5 – как это все работает.

Рис. 6. В CTP версии приложение Windows  Azure состоит из экземпляров Web  Role и Worker  Role,
каждая из которых работает на своей виртуальной машине.

Как видно из названия, экземпляр Web  Role принимает входящие HTTP (или HTTPS) запросы через InterNET  Information  Services  (IIS) 7. Web  role может быть реализована с помощью ASP.NET, WCF или другой .NET технологии, которая работает с IIS. Как показано на рис. 6, Windows  Azure предоставляет встроенный балансировщик нагрузки, который распределяет запросы между разными экземплярами Web  Role, которые являются частями одного приложения.

Worker  Role, напротив, не принимает запросов напрямую из внешнего мира – она не может иметь внешних входящих сетевых соединений и на ее виртуальных машинах нет IIS. Вместо этого, она получает исходные данные от Web  Role, обычно через очередь в хранилище Windows  Azure. Результат работы экземпляров Worker  Role может писаться в хранилище Windows  Azure или посылаться во внешний мир – исходящие сетевые соединения разрешены. В отличии от экземпляров Web  Role, которые создаются для обработки HTTP-запросов и выключаются после обработки запроса, Worker  Role может работать бесконечно – это фоновое задание. За счет этого отсутствия специализированности, Worker  Role может быть реализована с помощью любой .NET-технологии, поддерживающей метод main() (есть некоторые ограничения, связанные с доверием Windows  Azure, которые будут описаны ниже).

Каждая виртуальная машина, хостящая экземпляр Web  Role или Worker  Role, содержит агента Windows  Azure, через который приложения взаимодействуют с фабрикой Windows  Azure, как на рис.6. Агент доступен через определенный в Windows  Azure  API, через который приложения могут писать в лог, управляемый Windows  Azure, посылать предупреждения своему владельцу через фабрику Windows  Azure и т.д.

Хотя в будущем текущее положение дел может измениться, в CTP каждой виртуальной машине соответствует свое физическое ядро процессора. Благодаря этому производительность каждого приложения может быть гарантирована – каждый экземпляр Web  Role и Worker  Role имеет свое собственное выделенное ядро. Для увеличения производительности всего приложения, его владелец может увеличить количество работающих экземпляров указанное в конфигурационном файле. Фабрика Windows  Azure затем «разгонит» новые виртуальные машины, назначит им ядра, и запустит больше экземпляров приложения. Фабрика также определяет, когда экземпляр Web или Worker  Role падает, и запускает новый.

Обратите внимание на следствие из этого: чтобы обеспечит масштабируемость, экземпляры Web  Role не должны хранить свое состояние. Любое информация о специфичном для клиента состоянии должна писаться в хранилище Windows  Azure или отправляться клиенту с куками. Отсутствие состояния у Web  role необходимо для встроенного в Windows  Azure балансировщика нагрузки. Поскольку нельзя привязываться к определенному экземпляру Web  Role, то нельзя и гарантировать, что разные запросы от одного пользователя будет обрабатывать один и тот же экземпляр.

И Web  Role и Worker  Role реализуются с помощью стандартных .NET технологий. Но перенести существующие приложения на Windows  Azure без изменений скорее всего не получится. С одной стороны, отличается способ доступа к данным. Доступ к хранилищу Windows  Azure реализуется через ADO.NET  Web  Services, относительно новую технологию, которая еще не применяется повсеместно в локальных приложениях. Аналогично, Worker  Role обычно использует очередь хранилища Windows  Azure для получения входных данных, то есть абстракцию, аналогов которой для локальных приложений не существует. Другое ограничение – это то, что приложения Windows  Azure не работают в полностью доверенной среде. Наоборот, они ограничены тем, что Microsoft называет Windows  Azure  trust, что соответствует средней степени доверия, которую используют большинство ASP.NET хостеров.

Для разработчиков, создание Windows  Azure приложений на CTP версии очень схоже с разработкой традиционных .NET приложений. Microsoft предоставляет шаблоны проектов VS2008 для создания Windows  Azure  Web  Role, Worker  Role, и комбинации обеих ролей. Разработчики могут использовать на выбор любой .NET язык (хотя будет справедливым отметить, что фокус Microsoft при разработке Azure был на C#). Также, Windows  Azure  SDK включает версию среды Windows  Azure, запускаемую на компьютере разработчика. Она содержит хранилище, агента Windows  Azure и все остальное, что доступно приложению, запускаемому в облаке. Разработчик может создавать и отлаживать свое приложение в своем локальном подобии облака, а затем распространить его в настоящее облако, когда оно будет готово. В то же время, некоторые вещи в облаке совсем другие. Невозможно подключиться отладчиком к приложению в облаке, для примера, так что отладка облачных приложений производится в основном за счет управляемого Windows  Azure лога через агента.

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

Доступ к данным

Приложения работают с данными самыми разными способами. Иногда, все что нужно – это простые блобы, другие ситуации требуют более структурированного способа хранения информации. В некоторых случаях, все что надо – это механизм обмена данными между различными частями приложения. Хранилища Windows  Azure покрывают все эти требования как показано на рис. 7.

Рис. 7. Windows  Azure позволяет хранить данные в блобах, таблицах и очередях,
 доступ к которым предоставляется через REST поверх HTTP.

Самый простой способ хранения данных в Windows  Azure – используя блобы. Как на рис. 7, есть простая иерархия: аккаунт хранилища может иметь один или несколько контейнеров, каждый из которых хранить один или несколько блобов. Блобы могут быть большими – влоть до 50 Гб каждый – а чтобы сделать передачу блобов проще, каждый из них может быть разделен на подблобы. При ошибке передачи, повторная передача может начаться с самого последнего передаваемого подблоба. Блобы могут иметь метаданные, типа информации о том, где была сделана JPEG фотографии, или данные о композиторе песни для MP3 файла.

Для некоторых видов данных блобы – самое то, но во многих ситуациях они оказываются недостаточно структурированными. Чтобы приложения могли работать с данными на уровне мелких структурных единиц, хранилища Windows  Azure предоставляют таблицы. Не смотря на схожесть имен, их не надо путать с реляционными таблицами. В действительности, хотя они и называются таблицами, данные в них хранятся в виде простой иерархии сущностей со свойствами. У таблицы нет определенной схемы данных, вместо этого, свойства могут иметь различные типы, такие как Int, String, Bool или DateTime. И вместо того, чтобы использовать SQL для работы с данными, приложение обращается к данным через язык запросов с синтаксисом LINQ. Одиночная таблица может быть весьма большой, с миллионами сущностей, хранящими терабайты данных, и Windows Azure может разбить таблицу между многими серверами, если это необходимо для обеспечения производительности.

И блобы, и таблицы предназначены для хранения данных. Третий метод хранения данных в хранилище Windows  Azure – очереди – создан немного с другой целью. Основная роль очередей – обеспечить взаимодействие экземпляров Web  Role и Worker  Role. Для примера, пользователь посылает запрос на выполнение какой-то ресурсоемкой задачи через веб-страницу, реализованную в Web  Role. Экземпляр Web  Role, который получает этот запрос, пишет сообщение, описывающее требуемую работу, в очередь. Экземпляр Worker  Role, который ожидает сообщения в очереди, считывает новое сообщение и выполняет требуемую работу. Результаты работы он может вернуть через другую очередь или каким-то другим способом.

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

Данные в хранилище Windows  Azure доступны как приложениям Windows  Azure, так и приложениям, выполняющимся в каком-то другом месте. В обоих случаях, для всех трех способов хранения данных доступны они одинаково, используя соглашения REST для идентификации и предоставления доступа к данным. Все именуется URI и доступно через обычные HTTP операции. Клиент на .NET может использовать ADO.NET  Services или LINQ, а из, например, Java-приложения доступ к данным Windows  Azure осуществляется через стандартный REST. Для примера, блоб может быть считан через HTTP  GET к URI, форматированному примерно так:

https://<StorageAcount>.blob.core.windows.NET/<Container>/<BlobName>

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

Аналогично, запрос к определенной таблице выражается через HTTP GET запрос к URI вида:

http://<StorageAcount>.table.core.windows.NET/<TableName>?$filter=<Query>

Здесь <TableName> указывает запрашиваемую таблицу, а <Query>   запрос для выполнения к этой таблице.

Даже очереди доступны приложениям Windows Azure и внешним приложениям через HTTP GET к URI:

http://<StorageAcount>.queue.core.windows.NET/<QueueName>

Плата за вычисления ресурсы и хранилища на платформе Windows  Azure взымается независимо. Это значит, что локальное приложение может использовать только хранилище Windows  Azure, обращаясь к его данным через REST, как было описано. Но всё же, справедливо будет отметить, что основная цель хранилищ Windows  Azure – это работа с данными приложений Azure. И поскольку данные доступны не Azure приложениям напрямую, то они остаются доступны даже тогда, когда использующее их приложение Azure не выполняется.

Основная цель платформ для приложений, облачных ли или локальных, это поддержка приложений и данных. Windows  Azure предоставляет среду и для того, и для другого. Смотря в будущее, можно ожидать, что приложения, которые должны были бы быть локальными Windows приложениями, будут построены на этой новой облачной платформе.

.NET Services

Выполнения приложений в облаке уже само по себе полезно, но не менее полезны и предоставляемые в облаке инфраструктурные сервисы. Эти сервисы могут использовать как локальные, так и облачные приложения, и они решают задачи, которые другим способом решить было бы значительно труднее. Этот раздел рассматривает предложения Microsoft в этой сфере: .NET  Access  Control  Service, .NET  Service  Bus и .NET  Workflow  Service, которые все вместе и известны как .NET  Services.

Access Control Service

Работа с идентификационными данными это фундаментальная часть большинства распределенных приложений. Основываясь на идентификационных данных пользователя, приложение решает, что разрешено этому пользователю. Для передачи этих данных приложение может использовать токены, определенные с помощью Security  Assertion Markup  Language  (SAML). Токен SAML содержит утверждения (claims), каждое из которых представляет определенную информацию о пользователе. Одно утверждение может содержать имя пользователя, другое указывать на его роль, типа «менеджер» или «генеральный директор», третье – содержать его электронную почту. Токены создаются приложениями, известными как security  token  service (STS), которые подписывают цифровыми подписями каждый токен для подтверждения его источника.

Как только клиент (например, Web-браузер) получает токен пользователя, он может предоставить его приложению. Приложение теперь может использовать утверждения из токена для определения, что разрешено этому пользователю. В тоже время, сразу появляется пара проблем:

●     Что если токен не содержит утверждений, которые нужны приложению? С идентификацией, основанной на утверждениях, каждое приложение может определить набор утверждений, которые должны предоставлять пользователи. В то же время, не факт, что STS, создавший токен, добавил в него именно то, что нужно приложению.

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

Добавление нового STS в этот процесс может решить обе проблемы. Чтобы быть уверенным, что токен содержит нужные утверждения, этот дополнительный STS производит преобразование утверждений. STS может иметь правила, определяющую связь исходных и итоговых утверждений, и использовать эти правила для создания токена, содержащего именно те утверждения, которые нужны приложению. Решение второй проблемы, обычно называемое identity  federation, требует, чтобы приложения доверяло этому новому STS. Так же требуется установить доверенные отношения между этим STS и STS, выдавшем исходный токен.

Добавление дополнительного STS дает возможности преобразования утверждений и identity  federation, и то и другое очень полезно. Но где должен выполняться этот STS? Можно использовать STS, который работает внутри организации – это услуга, которую предоставляют некоторые вендоры. А почему бы не выполнять STS в облаке? Это сделает его доступным пользователям и приложениям любых организаций. Это также перекладывает заботу об управлении и поддержке STS на провайдера услуги.

Это и есть именно то, что предлагает Access  Control  Service: это STS в облаке. Чтобы представить, как такой STS может использоваться, предположим ISV, который предоставляет приложение, доступное через интернет, с которым могут работать пользователи из разных компаний. Даже если все компании смогут предоставить SAML токены для своих пользователей, маловероятно, что они будут содержать именно тот набор утверждений, который нужен приложению. На рис.8 – то как Access  Control Service решает эту проблему.

Рис. 8. Access  Control  Service предоставляет основанное на правилах преобразование утверждений и identity  federation.

Вначале, пользовательское приложение (в этом примере это браузер, но это может быть и WCF клиент или что-то еще) посылает токен пользователя Access  Control  Service (шаг 1). Сервис проверяет подпись токена, проверяет, что токен выдан доверенным STS. После этого сервис создает и подписывает новый SAML токен, который содержит требуемые приложению утверждения.

Чтобы сделать такое преобразование, STS в Access  Control  Service использует правила, определенные владельцем приложения. Для примера, представим приложение, которое дает определенные права любому пользователю, который работает менеджером в своей компании. Хотя каждая компания может включить утверждение в свой токен, которое показывает что пользователь – это менеджер, утверждения разных компаний вполне могут оказаться разными. Одна компания может использовать строку «Manager», другая «Supervisor», а третья вообще специальный код, выраженный целым числом. Чтобы помочь приложениям работать со всем этим многообразием, владелец приложения может определить правило, которое преобразует все три приведенных утверждения в одно, содержащее строку «Decision  Maker». Жизнь приложения после этого становится гораздо проще, поскольку работа с преобразованием утверждений для него уже сделана.

После создания нового токена, Access  Control  Service возвращает новый токен клиенту (шаг 3), который затем предает его приложению (шаг 4). Приложение проверяет подпись токена, чтобы быть уверенным, что она выдано именно STS в Access  Control  Service. Нужно отметить, что хотя STS в Access  Control  Service должен устанавливать доверительные отношения с STS всех компаний пользователей, само приложение должно доверять только STS в Access  Control  Service. Когда доверие к токену подтверждено, приложение использует содержащиеся в нем утверждения для определения прав пользователя.

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

Все взаимодействие с Access  Control  Service производится через стандартные протоколы WS-Trust и WS-Federation. Это делает сервис доступным любым приложениям на любых платформах. Для определения правил, сервис предоставляет как GUI через браузер, так и API для доступа из программ.

Идентификация, основанная на утверждениях, прокладывает свой путь к тому, чтобы стать стандартным механизмом в распределенных приложениях. За счет предоставления STS в облаке, дополненного возможностью преобразования утверждений, Access  Control  Service делает этот новый механизм идентификации все более привлекательным.

Service  Bus

Предположим, что у вас есть приложение, которое работает внутри компании, и доступ к которому вы хотите дать другим компания через интернет. На первый взгляд, это кажется очень простой проблемой. Допустим, что функционал вашего приложение доступен через веб-сервисы (REST или SOAP), тогда вы можете просто сделать эти Веб-сервисы доступными внешнему миру. Когда вы в действительности попытаетесь делать это, сразу возникнут некоторые проблемы.

Во-первых, как приложениям в других компаний (или даже частям вашего приложения) найти точки доступа. через которые они могут связаться с вашими сервисами? Было бы здорово иметь что-то типа реестра, через который можно найти ваше приложение. После того, как ваше приложение было найдено, как запросы от приложений других компаний доберутся до вашего приложения? NETwork  Address  Translation (NAT) – обычное дело, так что приложение часто не имеет фиксированного внешнего IP-адреса. И даже если NAT не используется, как этим запросом пройти через файрволл? Конечно, можно открыть определенные порты для приложения, но большинство сетевых администраторов смотрят на это очень неодобрительно.

Service  Bus решает эти проблемы – рис.9.

Рис. 9. Service  Bus дает приложениям регистрировать свои точки доступа,
затем другие приложения могут их обнаруживать и использовать для доступа к сервисам приложения.

Для начала, ваше приложение регистрирует одну или несколько точек доступа в Service  Bus (шаг 1), которая уже сама открывает доступ к ним в ваших интересах. Service Bus назначает вашей организации корневой URI, внутри которого вы можете создавать любую иерархию имен, какую пожелаете. Это позволяет вашим точкам доступа иметь назначенные им определенные, обнаруживаемые URI. Ваше приложение должно открыть соединение с сервисной шиной для каждой точки доступа, которую она создает. Service  Bus держит это соединения установленным, что решает две проблемы. Во-первых, NAT больше не доставляет неприятностей, поскольку трафик от Service  Bus всегда дойдет до приложения через открытое им соединение. Во-вторых, поскольку соединения было инициировано изнутри сети компании, то не будет и проблем с прохождением информации обратно к приложению - файрволл не будет блокировать этот трафик.

Когда приложению другой компании (или даже другой части вашего приложения) нужно обратиться к вашему приложению, оно обращается к реестру Service Bus (шаг 2). Для запросы используется Atom  Publishing  Protocol, ответ возвращается в виде AtomPub документа с ссылками на точки доступа вашего приложения. Когда эти данные получены, приложение может обратиться к сервисам доступным через эти точки доступа (шаг 3). Каждый запрос получает Service Bus, затем передает его вашему приложению, ответ приложение идет по обратному пути. И хотя на рисунке это и не показано, если возможно, что Service Bus устанавливает прямое соединение между приложением и его клиентом, что делает коммуникацию более эффективной.

Вместе с упрощением коммуникации, Service  Bus может так же повысить безопасность. Поскольку клиенты видят только IP, принадлежащий Service  Bus, нет необходимости открывать IP адреса вашей организации. Это эффективно делает ваше приложение анонимным, поскольку внешний мир не видит его IP. Service  Bus работает как внешний DMZ, предоставляя «слой преобразования адресов» помогающий защищаться от атакующих. Наконец, Service  Bus была разработана для использования вместе с Access  Control  Service. В частности, Service  Bus принимает токены только от STS  Access  Control  Service.

Приложение, которое открывает доступ своим сервисам через Service  Bus, обычно реализуется с помощью WCF. Клиенты могут быть написаны с помощью WCF или других технологий, типа Java, и они могут посылать запросы через SOAP или HTTP. Приложения и их клиенты могут использовать свои собственные механизмы безопасности для защиты своей коммуникации от атакующих и самой Service  Bus.

Открытие доступа к приложениям из внешнего мира не так просто, как может показаться. Цель Service  Bus – сделать реализацию этого полезного поведения максимально простым и очевидным.

Workflow  Service

Windows  Workflow  Foundation это основная технология для создания workflow приложений. Один из классических сценариев для применения Workflow – это контроль протяженного по времени процесса, как это часто происходит при интеграции enterprise-приложений. В более общем случае, WF-приложения могут быть хорошим выбором для координирования многих видов работ. Особенно когда координируемая работа происходит между несколькими компаниями, выполнение контролирующей логики в облаке может быть очень хорошим решением.

Workflow  Service собственно и предоставляет такую возможность. Предоставляя хост-процесс для приложений, основанных на WF 3.5, он дает разработчиком возможность создавать workflows, которые выполняются в облаке. Как это выглядит – на рис. 10

Рис. 10. Workflow  Service позволяет создавать WF-приложения,
которые могут взаимодействовать через HTTP или Service  Bus.

Каждый WF  workflow реализуется, используя некоторое количество activities, на рисунке они выделены красным цветом. Каждая activity выполняет определенное действие, такие как отправка или получение сообщения, реализация условного выражения, или управление циклом. WF предоставляет стандартный набор activities, известных как Base  Activity  Library  (BAL), и Workflow  Service дает приложениям использовать подмножество BAL. Сервис также предоставляет некоторый набор своих собственных activities. Для примера, приложение, которое выполняется на сервисе, может взаимодействовать с другими приложениями через HTTP или Service  Bus, как на рис. 10, то есть Workflow  Service содержит встроенные activities для реализации и того, и другого. Workflow  Service так же предоставляет activities для работы с XML сообщениями - частое требованияе при организации интеграции приложений.

Однако выполнение в облаке привносит и некоторые ограничения. Основанные на WF приложения, выполняющиеся на Workflow  Service, могут использовать только последовательную модель workflow, для примера. Также и выполнение произвольного кода не разрешено, так что ни Code  Activity из BAL, ни пользовательские activity не могут использоваться.

Для создания приложений для Workflow  Service, разработчики могут использовать стандартный workflow дизайнер из Visual  Studio. После того, как приложение написано, оно может быть опубликовано в облако через портал, доступный через браузер, или программно через предоставляемое API. Выполнение приложений так же может управляться через портал или через приведенное API. И как и в случае с Service Bus, приложение, которое взаимодействует с Workflow Service, обязано вначале получить токен от Access  Control  Service - это единственный доверенный STS.

WF-приложения это не метод для решения любых задач. Однако, когда требуется решение задачи подходящего вида, использование workflow может сделать жизнь разработчика гораздо проще. За счет предоставления управляемого, масштабируемого способа хостить WF-приложений в облаке, Workflow Service делает эту полезную технологию доступнее.

SQL Services

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

Базы данных в облаке привлекательны по многим причинам. Для некоторых организаций переложить на провайдера сервиса заботы об обеспечении надёжности, резервного копирования и других функций поддержки может быть очень удобно. Данные в облаке так же легко сделать доступными для приложений, которые выполняются где угодно, в том числе и на мобильных устройствах. И поскольку масштабирование в облаке реализуется на радость  провайдеру гораздо экономичнее, то в итоге и для организаций хранение данных в облаке получается дешевле. Цель SQL Data  Services - предоставить все эти выгоды.

В то же время, реализация надежной, высокопроизводительной базы данных с InterNET-масштабируемостью это совсем не простое дело; нужные какие-то компромиссы. Как было описано выше, для примера, SQL  Data  Services не предоставляют стандартную реляционную базу данных, не дает работать через обычные SQL запросы. Вместо этого, данные организуются, используя структуру как на рис.11.

Рис.11. SQL  Data  Services дата центры разделены на authorities,
каждая из которых содержит контейнеры, которые в свою очередь содержат сущности содержащие свойства.

Информация в SQL  Data  Services хранится во многих разных дата центрах. Каждый из центров содержит определенное количество authorities, как на рис.11. Разделение на authority идет по географическому расположению, каждый из них хранится в определенном дата центре Microsoft и имеет уникальное DNS имя. Authority содержит контейнеры, каждый из которых реплицируется внутри своего дата центра. Контейнеры используются для балансировки нагрузки и доступности данных: при ошибке, SQL Data Services автоматически начнет использовать другую реплику контейнера. Каждый запрос выполняется к одному определенному контейнеру - запросы к данным из всего authority не допустимы. Каждый контейнер хранит некоторое количество сущностей, которые в свою очередь содержат свойства. У каждого свойства есть имя, тип, и значение этого типа. Типыподдерживаемые SQL  Data  Services влючают String, DateTime, Base64Binary, Boolean и Decimal. Приложения так же могут хранить блобы с MIME типами.

Для обращения к этим данным, у приложений есть несколько вариантов. Один из них - это использование языка запросов, близкого по синтаксису к LINQ в C#, которые отправляются через SOAP или REST. Другой вариант - использовать ADO.NET  Data  Services, альтернативный способ доступа к данным типа REST. В обоих случаях, приложение делает запросы к контейнерам используя операторы типа ==, !=, >, <, AND, OR или NOT. Запросы так же могут некоторые похожие на SQL операторы, такие как ORDER  BY и JOIN.

Однако для запросов объектами получения или обновления являются сущности, а не их свойства. Запрос возвращает некоторое количество сущностей, для примера, включая все свойства, которые они содержат. Аналогично, нельзя и изменить только одно свойство сущности - нужно заменять всю сущность. И поскольку сущности не имеют предопределенной схемы данных, то свойства в одной сущности могут иметь разные типы. Сущности в одном контейнере так же могут отличаться друг от друга, каждая из них содержать разный набор свойств.

Данные в SQL  Data  Services именуются через URI, очень похоже на Windows  Azure  Storage  Service. Общий формат, для URI, идентифицирующей определенную сущность выглядит примерно так:

https://<Authority>.data.database.windows.NET/v1/<Container>/<Entity>

Не лишним будет еще раз подчеркнуть, что SQL Data Services не требует .NET на клиенте. Данные, которые там содержатся, доступны через REST - то есть обычный HTTP - или через SOAP любому приложению на любой платформе. Вне зависимости от платформы, на которой они выполняются, приложения для обращения к данным должны идентифицировать своих пользователей с определенным SQL  Data  Services именем пользователя и пароля или токеном, созданным Access  Control  Service  STS.

Microsoft анонсировала планы по развитию SQL  Data  Services в более реляционную технологию. Если вспомнить, что в отличие от Windows  Azure  Storage, SQL  Data  Service  Storage реализованы поверх SQL  Server, то такая эволюция становится естественной. В не зависимости от предоставляемой модели, цель технологии остается одна и та же - предоставление масштабируемой, надежной и недорогой облачной базы данных для любых типов приложений. С расширением SQL  Data  Services, которые будут включать новые облачные сервисы по работе с данными, можно ожидать, что все они будут опираться на этого первого представителя семейства.

Live Services

Что является движущей силой создания новой платформы для приложений? Ответ - это изменения, изменения в железе, в софте и изменения в способах того, как мы используем приложения и данные. Мобильные телефоны трансформировались в компьютеры, для примера, и сервера в облаке стали большой частью нашей жизни. Приложения стали более личными, как и данные, которые мы храним в этих приложениях. Собрав эти изменения вместе, получаем основу для создания новой платформы приложений.

Live  Services и Live  Framework дают хороший пример этого. Приложения могут использовать Live Framework для доступа к данным Live  Services, так же они могут положиться на Live  Framework при синхронизации этих данных между десктопами, лаптопами и мобильными устройствами. Рис. 12 показывает как Live  Services и Live  Framework работают вместе.

Рис.12. Live  Framework дает приложениям доступ к данным Live Services и т.п.

Live Services разбиты на несколько категорий, как показано на рисунке. Каждый сервис предоставляет доступ к определенному набору ресурсов, которые могут принадлежать конкретному пользователю или быть общими. Для примера, список контактов пользователей доступен через сервис Directory, а его профиль - это ресурс, предоставляемый сервисом Storage. Оба эти сервисы работают с данными, специфичными для конкретного пользователя, поскольку они открывают доступ к данным, связанным с определенным пользователем. А Geospatial сервис предоставляет ресурсы, содержащие разделяемые данные, типа карт и другой географической информации, так же и как и Search сервис.

Данные в Live  Services используются существующими приложениями Microsoft самыми разными способами, как показано на рисунке. Основная цель Live Framework - упростить создание приложений, которые используют эти же данные. Live  Mesh самого Microsoft - это один из примеров такого приложения, и ISV и конечные пользователя могут без проблем создавать новые другие приложения. Все эти приложения получают доступ к данным через основной компонент Live  Framework - Live  Operating  Environment. Как это выглядит описано ниже.

Доступ к данным

Самый простой способ обратиться к данным Live  Services - сделать это напрямую через Live  Operating  Environment. Рис. 13 показывает, как это выглядит.

Рис. 13. Поскольку Live  Framework открывает доступ к данным Live  Services через HTTP,
то приложения, написанные на самых разных технологиях, могут использовать эти данные.

Все ресурсы, предоставляемые Live  Services, как специфичные для определенного пользователя, так и разделяемые, именуются с помощью URI. Для обращения к этой информации, приложения могут делать REST запросы через HTTP. Так же ресурсы доступны через AtomPub или другими основанными на HTTP способами. Информация передается в XML или JSON, подписка реализуется через RSS или Atom.

Для реализации согласованного способа описания и именования данных Live  Services, Live  Framework определяет модель ресурсов. Эта модель определяет типы и допустимые отношения между экземплярами этих типов, а также и схему именования через URI. Приложения так же могут создавать свои собственные типы для хранения своих видов информации. Цель всего этого - предоставить общую единую схему для обнаружения и навигации по данным Live  Services, равно как и предоставить приложениям нужную им гибкость для хранения самой разной информации. И поскольку каждый пользователь может детально контролировать, какой из его ресурсов доступен какому приложению и в течение какого срока, то ничьи персональные данные не общедоступны.

Надо отметить, что данные, используемые Live приложениями Microsoft доступны уже сейчас через существующее Live  Services  API (иногда это еще называет Windows  Live  Platform). Однако эти API значительно различаются для разных приложений. За счет предоставления общего, основанного на HTTP доступа ко всей этой информации, Live  Framework заменит этот старый способ на более простой и согласованный интерфейс.

Для написания приложений, использующих данные Live  Framework, разработчик может писать код с использованием напрямую HTTP интерфейса. Однако чтобы упростить это, Live  Framework так же включает Live  Framework  Toolkites. Эти библиотеки предоставляют более простой и естественный способ для разработчиков для создания приложений, обращающихся к данным Live  Services через Live  Framework. Microsoft предоставляет тулкиты для .NET  Framework, Silverlight и javaSAFEscript, скорее всего в дальнейшем программистское сообщество создаст тулкиты и для других платформ. Подчеркнем еще раз, ничто в способе доступа к данным в Live  Framework не привязано к технологиям Microsoft, Live F ramework  Toolkits могут быть созданы для любой платформы.

Использование Mesh

До тех пор, пока у него есть правильные разрешения, любое приложение свободно использовать данные Live  Services через Live  Framework. Дополнительно, приложение может работать на системе, которая была сделана частью мэша. Если это так, то у приложения есть некоторые дополнительные возможности.

Как было описано ранее, каждый пользователь может иметь свой собственный мэш, содержащий системы, которые он использует. Для примера, у пользователя может быть рабочий десктоп на Windows  XP, Мак дома, ноутбук на Windows  Vista и телефон, работающий на Windows  Mobile. Все эти системы могут быть собраны в меш, как на рис. 14.

Рис. 14. При добавлении системы в меш на эту систему устанавливается Live  Operating  Environment.

Для создания меша, пользователь может залогиниться со своим Live  ID, а затем работать со своим рабочим столом Live  Desktop через браузер. Это облачное приложение используется для добавления приложений в меш пользователя. Чтобы реализовать это, Live  Desktop в облаке загружает и устанавливает Live  Operating Environment на эту машину (шаг 2).

Как было показано выше, Live  Operating  Environment позволяет приложениям обращаться к данным Live Services через HTTP. Однако, когда это происходит в меше, этот компонент делает больше: он синхронизирует пользовательские данные Live  Services между облаком и всеми системами в меше. Рис.15 иллюстрирует эту идею.

Рис.15. Live  Operating  Environment поддерживает синхронизированность данных между десктопами, устройствами и облаком.

Пользователи и приложения могут указать, какие данные нужно включить в меш, и Live  Operating  Environment возьмет на себя заботу о поддержке этих данных синхронизированными. Для примера, приложение Microsoft  Live  Mesh позволяет пользователю указать определенную папку как часть меша. После того, как это сделано, Live  Operating  Environment будет незаметно распространять изменения, сделанные в этой папке, между всеми системами меша. Аналогично, пользовательские данные Live  Services, типа контактов или профиля, могут поддерживаться синхронизированными внутри всего меша.

Синхронизация в меше сделана так, что пользователь может менять данные на любой системе, нет одной главной, на которой должны производиться все изменения (multi-master). Для этого используется технология FeedSync, это определенный Microsoft, публично доступный протокол, который работает на HTTP. Если возможно, то данные синхронизируются напрямую между связанными системами - peer-to-peer. Однако, поскольку это не всегда возможно, то система может так же синхронизироваться с Live  Operating  Environment в облаке. Этот облачный экземпляр может соединиться напрямую с любой системой в меше - это peer для всех систем, так что он может синхронизироваться со всеми.

Как обычно, приложение, работающее на системе в меше, может обращаться к данным через HTTP-запросы к Live  Operating  Environment в облаке. Так же у приложения есть доступ к локальной копии всех данных Live Services, которые были добавлены в меш. Вместо того, чтобы взаимодействовать с удаленным экземпляром Live  Operating  Environment, приложение может слать те же HTTP-запросы к экземпляру, работающему локально, как на рис. 15. Кроме базовой части URI, эти запросы будут идентичны как для локального, так и для облачного экземпляра Live  Operating  Environment.

Эта симметрия позволяет приложению работать единым способом с локальными и облачными данными. Если приложение работает на десктопе или устройстве, которое в данный момент не соединено с интернетом, для примера, то приложение может обращаться к локальной копии, которая работает как кэш для последнего известного состояния облачных данных. Когда устройство снова соединиться, приложение может обращаться к облачным данным напрямую - все что нужно поменять это URI - или подождать, пока обновится локальная копия за счет синхронизации Live  Operating  Environment.

Системы, на которых не работает Live  Operating  Environment, могут так же участвовать в меше, хотя и более ограниченно. Поскольку Live  Desktop доступен через любой браузер, пользователь, работающий, например, на Linux, может создать меш только с одним облачным компонентом, то есть меш без десктопов и устройств. Приложения, работающие на Linux, могут хранить и обращаться к данным в этом простом меше так же, как и с обычными данными в Live Services - через HTTP. В частности, приложение может даже реализовать поддержку протокола FeedSync для синхронизации данных в облаке с локальной копией. Системы, на которых работает Live  Operating  Environment имеют больше возможностей, но для тех, на которых эта среда не работает, этот аспект Live  Framework может быть полезен.

Mesh-Enabled  Web  Application

Каждое приложение, как основанное на Windows, так и на другой системе, может обратиться к данным Live  Services, - оно не обязательно должно быть частью меша. Если же разработчик создает приложение, которое будет всегда работать на системах из меша, то у него есть дополнительные возможности. Он может создать Mesh-Enabled Web  Application, которое может распространяться и управляться самим Live  Framework. Рис. 16 показывает основы того, как это работает:

Рис. 16. Пользователь может найти Mesh-Enabled Web Application и затем установить его в свой меш.

Как видно из рисунка, Mesh-Enabled Web  Application можно сделать доступным через предоставляемый Microsoft каталог приложений в облаке. Пользователь может обращаться к этому каталогу для обнаружения доступных Mesh-Enabled Web  Application (шаг 1). После того, как пользователь выбрал приложение, он может установить его (шаг 2). Первоначально, при этом только копируется приложение в облачное хранилище пользователя в Live  Services. Потом приложение будет синхронизировано на все десктопы и устройства пользователя, как и другие обычные данные меша (шаг 3). Приложение теперь можно запускать из локального хранилища на любом устройстве меша пользователя (шаг 4). Вообще, это не совсем точно рассматривать Mesh-Enabled  Web  Application как устанавливаемое только на одну систему. Вместо этого, оно ставится на все системы - на весь меш.

Mesh-Enabled  Web  Application должно быть реализовано, используя кросс платформенную технологию типа Microsoft  Silverlight, DHTML или Adobe  Flash. Эти технологии поддерживаются на всех платформах, на которых может работать Live  Framework: Windows  Vista/XP, Mac  OS  X и Windows  Mobile  6. Соответственно, любое Mesh-Enabled Web Application может выполняться на любой системе в меше (хотя все эти возможности еще не реализованы в ноябрьском CTP).

Поскольку Live  Operating  Environment поддерживает синхронизированность всех данных меша, то Mesh-Enabled  Web  Application будет видеть те же данные, в не зависимости от того, где оно выполняется. Это дает новое интересное значение понятию «написал один раз - выполняй где угодно» (write  once, run anywhere): Mesh-Enabled  Web  Application может без изменений работать на любой системе в меше, при этом оно может рассчитывать, что ему всегда доступны одни и те же данные, в не зависимости от того, где оно выполняется.

Как и в других случаях организации доступа к данным Live  Framwork, Mesh-Enabled  Web  Application имеет доступ только к тем данным, для которых пользователь явно указал, что приложение может с ними работать. И как и другие Silverlight, DHTML и Flash приложения, Mesh-Enabled  Web  Application выполняется в своей безопасной песочнице. Кроме случаев, когда пользователь явно разрешил, такие приложения не могут напрямую обращаться к локальному диску или данным других Mesh-Enabled  Web  Application. Однако пользователь может сам разделять Mesh-Enabled  Web  Application с мешем другого пользователя. Для примера, пользователь может сказать Mesh-Enabled  Web  Application, чтобы то пригласило любого из его адресной книге использовать себя. Поскольку контактные данные доступны приложению напрямую - они являются частью меша - то необходимость приложению уметь это делать вполне очевидно.

Чтобы помочь разработчикам создавать Mesh-Enabled  Web  Application, Microsoft предоставляет шаблоны проектов для Visual  Studio  2008. Чтобы упростить обновления приложений, разработчик может загрузить новую версию в каталог приложений, предоставив Live  Framework, заботится об обновлении приложении в меше каждого пользователя, который установил это приложение. И чтобы помочь разработчикам зарабатывать на своих приложениях, Microsoft планирует включение своего собственного центра контекстной рекламы (adCenter) или сервисов других компаний, чтобы Mesh-Enabled  Web  Application могли показывать рекламу.

Live  Framework в значительной степени представляет собой полностью новый вид платформы для приложений. Многие аспекты среды, такие как доступ к данным Live  Services и фокус на десктопах и мобильных устройствах, делают очевидным то, что основная цель этой технологии - это поддержка клиентоориентированных, социальных приложений. В самом прямом смысле, Live  Framework расположен на пересечении новой технологии и новых способах человеческого взаимодействия.

Выводы

Истина очевидна - облачные вычисления уже здесь. Для разработчиков, использование возможностей облака влечет за собой использование каким-либо образом облачной платформы. С Azure  Services  Platform, Microsoft представляет набор платформ для разных потребностей:

●     Windows  Azure предоставляет основанную на Windows среду для вычисления и хранения данных в облаке.

●     .NET  Services предлагают облачную инфраструктуру для облачных и локальных приложений.

●     SQL  Services предоставляют базу данных в облаке через SQL  Data  Services, в дальнейшем планируется появление новых облачных сервисов для работы с данным.

●     Live  Services предоставляют Live  Framework, который позволяет приложениям использовать данные Live  Services, синхронизировать данные между системами, объединенными в меш и другое.

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