Первая часть перевода
Получить общее представление о Azure Service Platform это важный первый шаг, однако, более глубокее понимание каждой из технологий тоже необходимо. В этом разделе каждый из членов семьи 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, форматированному примерно так:
это идентификатор, который назначается каждой созданной учетной записи хранилища, и он уникально идентифицирует блобы, таблицы и очереди, созданные в этом аккаунте. и это просто имена контейнера и блоба, к которым идет обращение в запросе.
Аналогично, запрос к определенной таблице выражается через HTTP GET запрос к URI вида:
Здесь указывает запрашиваемую таблицу, а запрос для выполнения к этой таблице.
Даже очереди доступны приложениям Windows Azure и внешним приложениям через HTTP GET к URI:
Плата за вычисления ресурсы и хранилища на платформе Windows Azure взымается независимо. Это значит, что локальное приложение может использовать только хранилище Windows Azure, обращаясь к его данным через REST как было описано. Но все же справедливо будет ометить, что основная цель хранилищ Windows Azure – это работа с данными приложений Azure. И поскольку данные доступны не Azure приложениям напрямую, то они остаются доступны даже тогда, когда использующее их приложение Azure не выполняется.
Основная цель платформ для приложений, облачных ли или локальных, это поддержка приложений и данных. Windows Azure предоставляет среду и для того, и для другого. Смотря в будущее, можно ожидать, что приложения которые должны были бы быть локальными Windows приложениями, будут построены на этой новой облачной платформе.
Выполнения приложений в облаке уже само по себе полезно, но не менее полезны и предоставляемые в облаке инфраструктурные сервисы. Эти сервисы могут использовать как локальные, так и облачные приложения, и они решают задачи, которые другим способом решить было бы значительно труднее. Этот раздел рассматривает предложения Microsoft в этой сфере: .Net Access Control Service, .Net Service Bus и .Net Workflow Service, которые все вместе и известны как .Net Services.
Работа с идентификационными данными это фундаментальная часть большинства распределенных приложений. Основываясь на идентификационных данных пользователя, приложение решает, что разрешено этому пользователю. Для передачи этих данных приложение может использовать токены, определенные с помощью Security Assertion Markup Language (SAML). Токен SAML содержит утверждения (claims), каждое из которых представляет определенную информацию о пользователе. Одно утверждение может содержать имя пользователя, другое указывать на его роль, типа «менеджер» или «генеральный директор», третье – содержать его электронную почту. Токены создаются приложениями, известными как security token service (STS), которые подписывают цифровыми подписями каждый токен для подтверждения его источника.
Как только клиент (например, Web-браузер) получает токен пользователя, он может предоставить его приложению. Приложение теперь может использовать утверждения из токена для определения, что разрещено этому пользователю. В тоже время, сразу появляется пара проблем:
Добавление нового 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 делает этот новый механизм идентификации все более привлекательным.
Предположим, что у вас есть приложение, которое работает внутри компании, и доступ к которому вы хотите дать другим компания через интернет. На первый взгляд, это кажется очень простой проблемой. Допустим, что функционал вашего приложение доступен через веб-сервисы (REST или SOAP), тогда вы можете просто сделать эти Веб-сервисы доступными внешнему миру. Когда вы в действительности попытаетесь делать это, сразу возникнут некоторые проблемы.
Во-первых, как приложениям в других компаний (или даже частям вашего приложения) найти точки доступа через которые они могут связаться с вашими сервисами? Было бы здорово иметь что-то типа реестра, через который можно найти ваше приложение. После того, как ваше приложение было найдено, как запросы от приложений других компаний доберутся до вашего приложения? Network Address Translation (NAT) – обычное дело, так что приложение часто не имеет фиксированного внешнего IP-адреса. И даже если NAT не используется, как этим запросом пройти через файрволл? Конечно можно открыть определенные порты для приложения, но большинство сетевых администраторов смотрят на это очень неодобрительно.
Service Bus решает эти проблемы – рис.9.
Рис. 9 Service Bus дает приложениям регистрировать свои точки доступа, затем другие приложения могут их обнаруживать и использовать для доступа к сервисам приложения.
Для начала, ваше приложение регистрирует одну или несколько точек доступа в Service Bus (шаг 1), которая уже сама открывает доступ к ним в ваших интересах. Service Bus назначает вашей организации корневой URI, внутри которого вы можете создавать любую иерархию имен, какую пожелаете. Это позволяет вашим точкам доступа иметь назначенные им определенные, обнаруживаемые URI. Ваше приложение должно открыть cоединение с сервисной шиной для каждой точки доступа, которую она создает. 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 – сделать реализацию этого полезнего поведения макимально простым и очевидным.
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 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 Servies именуются через URI, очень похоже на Windows Azure storage service. Общий формат, для URI, идентифицирующей определенную сущность выглядит примерно так:
Не лишним будет еще раз подчеркнуть, что 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, которые будут включать новые облачные сервисы по работе с данными, можно ожидать, что все они будут опираться на этого первого представителся семейства.
Детальный взгляд на технологии.
Получить общее представление о 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, форматированному примерно так:
http://<StorageAcount>.blob.core.windows.net/<Container>/<BlobName>
это идентификатор, который назначается каждой созданной учетной записи хранилища, и он уникально идентифицирует блобы, таблицы и очереди, созданные в этом аккаунте. и это просто имена контейнера и блоба, к которым идет обращение в запросе.
Аналогично, запрос к определенной таблице выражается через HTTP GET запрос к URI вида:
http://<StorageAcount>.table.core.windows.net/<TableName>?$filter=<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. Ваше приложение должно открыть cоединение с сервисной шиной для каждой точки доступа, которую она создает. 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 Servies именуются через URI, очень похоже на Windows Azure storage service. Общий формат, для URI, идентифицирующей определенную сущность выглядит примерно так:
http://<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, которые будут включать новые облачные сервисы по работе с данными, можно ожидать, что все они будут опираться на этого первого представителся семейства.