При спонсорской поддержке корпорации майкрософт



Скачать 207.48 Kb.
Pdf просмотр
Дата16.12.2016
Размер207.48 Kb.
Просмотров265
Скачиваний0








ПРЕДСТАВЛЕНИЕ ПЛАТФОРМЫ
WINDOWS AZURE
ПРЕДВАРИТЕЛЬНЫЙ ОБЗОР WINDOWS AZURE,
SQL AZURE И .NET SERVICES
ДЭВИД ЧЭППЕЛ (DAVID CHAPPELL),
АВГУСТ 2009 Г.
ПРИ СПОНСОРСКОЙ ПОДДЕРЖКЕ КОРПОРАЦИИ МАЙКРОСОФТ

СОДЕРЖАНИЕ

ОБЗОР ПЛАТФОРМЫ WINDOWS AZURE............................................................................................... 3
WINDOWS AZURE ................................................................................................................................... 4
SQL AZURE .............................................................................................................................................. 6
.NET SERVICES ....................................................................................................................................... 8
БОЛЕЕ ПОДРОБНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ...................................................................................... 9
WINDOWS AZURE ................................................................................................................................... 9
Выполнение приложений .................................................................................................................... 9
Доступ к данным ...............................................................................................................................11
SQL AZURE ............................................................................................................................................ 13
SQL Azure Database ........................................................................................................................... 13
Huron ................................................................................................................................................... 16
.NET SERVICES ..................................................................................................................................... 17
Служба управления доступом ......................................................................................................... 17
Шина служб......................................................................................................................................... 19
ЗАКЛЮЧЕНИЕ .......................................................................................................................................... 21
ОБ АВТОРЕ............................................................................................................................................... 21



2

ОБЗОР ПЛАТФОРМЫ WINDOWS AZURE
Использование вычислительных мощностей, размещенных в Интернете (или «облаке», если говорить профессиональным языком), — более чем здравая идея. Вместо того чтобы покупать и обслуживать собственные компьютеры, почему бы не использовать огромное количество предлагаемых на сегод- няшний день серверов, доступных через Интернет? Код и данные некоторых приложений могут находиться в «облаке», где кто-то другой, а не вы, управляет системами, которые они используют, и обеспечивает их поддержку. С другой стороны, данные приложений, которые выполняются внутри организации, — локальных приложений — могут храниться в «облаке» или использовать другие инфраструктурные службы глобальной сети. Приложения, которые выполняются на настольных компьютерах и мобильных устройствах, могут использовать службы в «облаке» для синхронизации информации в нескольких системах или какими-либо другими способами. Как бы все это ни происходило, использование возможностей Интернета позволяет сделать мир лучше.
Однако выполняется ли приложение в «облаке», использует ли имеющиеся в «облаке» службы или прибегает к обеим этим возможностям, необходима какая-то платформа приложений. В широком понимании платформой приложений можно назвать любую структуру, предоставляющую службы для создания приложений, доступные разработчикам. В более узком смысле, например в контексте
Windows, сюда входят технологии, такие как .NET Framework, SQL Server и некоторые другие. Для того чтобы дать возможность приложениям использовать «облако», должны также существовать платформы приложений. И поскольку имеются разные способы использования «облачных» служб приложениями, в разных ситуациях целесообразно применять различные «облачные» платформы.
Платформа корпорации Майкрософт Windows Azure (первоначально известная под названием
Azure Services Platform) — это группа «облачных» технологий, каждая из которых предоставляет определенный набор служб для разработчиков приложений. На рис. 1 показано, что платформа
Windows Azure может быть использована как приложениями, выполняющимися в «облаке», так приложениями, работающими на локальных компьютерах.

Рисунок 1. Платформа Windows Azure поддерживает приложения, данные и инфраструктуру,
находящиеся в «облаке».
3

Платформа Windows Azure состоит из следующих компонентов.
Windows Azure. Обеспечивает среду на базе Windows для выполнения приложений и хранения данных на серверах в центрах обработки данных корпорации Майкрософт.
SQL Azure. Обеспечивает службы данных в «облаке» на базе SQL Server.
.NET Services. Обеспечивают распределенную инфраструктуру для «облачных» приложений и локальных приложений.
Каждый компонент платформы Windows Azure играет собственную роль. В этом обзоре рассматри- ваются все три компонента сначала в общих чертах, а затем — немного подробнее. Несмотря на то что ни один из компонентов не является законченным (его отдельные характеристики и многое другое могут измениться до первоначального выпуска), представляется, что попытка проанализировать этот новый набор платформенных технологий не будет чересчур поспешной.
WINDOWS AZURE
На высоком уровне понять Windows Azure очень легко. Это платформа для выполнения приложений
Windows и хранения их данных в Интернете («облаке»). На рисунке 2 показаны ее основные компоненты.
Рисунок 2. Windows Azure предоставляет «облачные» приложениям службы для вычисления
и хранения на базе Windows
Как показано на рисунке, Windows Azure выполняется на большом количестве компьютеров, распо- ложенных в центрах обработки данных корпорации Майкрософт, и доступна через Интернет. Общая структура подключения Fabric Windows Azure соединяет множество вычислительных мощностей в единое целое. Службы Windows Azure для вычисления и хранения построены на основе этой структуры.
4

Вычислительная служба Windows Azure, естественно, работает на базе Windows. Для обеспече- ния первоначальной доступности этой службы осенью 2008 г. была открыта для широкой публики
CTP-версия. Корпорация Майкрософт разрешила выполнять на Windows Azure только приложения, разработанные на платформе .NET Framework. Сегодня, однако, Windows Azure также поддерживает неуправляемый код, позволяя разработчикам выполнять приложения, которые разработаны не на базе .NET Framework. В любом случае такие приложения написаны на обычных языках Windows — C#,
Visual Basic, C++ и других — с помощью Visual Studio 2008 или других средств разработки. Разработчики могут создавать веб-приложения с помощью таких технологий, как
ASP.NET
и Windows Communication
Foundation (WCF), приложения, которые выполняются как независимые фоновые процессы, или приложения, сочетающие и то и другое.
Как приложения Windows Azure, так и локальные приложения могут получать доступ к службе хранилища
Windows Azure, делая это одним и тем же способом: с помощью подхода RESTful. Однако Microsoft
SQL Server не является базовым хранилищем данных. Фактически хранилище Windows Azure не от- носится к реляционным системам, и язык его запросов не SQL. Поскольку оно изначально предназначено для поддержки приложений на базе Windows Azure, то обеспечивает более простые и масштабируемые способы хранения. Следовательно, оно позволяет хранить большие двоичные объекты (binary large object — blob), обеспечивает создание очередей для взаимодействия между компонентами прило- жений и даже что-то вроде таблиц с простым языком запросов. (А для тех приложений Windows Azure, которым требуется обычное реляционное хранилище, платформа Windows Azure предоставляет базу данных SQL Azure, описанную далее.)
Выполнение приложений и хранение их данных в Интернете имеет очевидные преимущества. Например, вместо того чтобы покупать, устанавливать и эксплуатировать собственные компьютеры, организация может доверить все это поставщику услуг Интернета. При этом заказчики платят только за вычисли- тельные мощности и хранилище, которое они используют, и не связаны с обслуживанием большого количества серверов, предназначенных только для пиковых нагрузок. Если приложения правильно написаны, их можно легко масштабировать, воспользовавшись преимуществами огромных центров обработки данных, которые могут предложить поставщики.
И все же для получения этих преимуществ требуется эффективное управление. В Windows Azure каждое приложение имеет файл конфигурации, как показано на рис. 2. Изменяя информацию в этом файле вручную или с помощью программы, владелец приложения может контролировать различные аспекты его поведения, такие как настройка количества экземпляров, которые должны выполняться на платформе Windows Azure. Структура Fabric платформы Windows Azure наблюдает за тем, чтобы приложение поддерживалось в требуемом состоянии.
Чтобы позволить своим заказчикам создавать, настраивать приложения и наблюдать за ними,
Windows Azure предоставляет портал, доступный с помощью браузера. Заказчик предоставляет
Windows Live ID, а затем решает, создавать ему учетную запись размещения для выполнения приложений, учетную запись хранения для хранения данных или и ту и другую. Оплата исполь- зования приложения заказчиками может производиться любым удобным способом: с помощью подписки, повременно или как-нибудь иначе.
Windows Azure — это общая платформа, которую можно использовать в различных сценариях.
Приведем несколько примеров, все они описываются с учетом возможностей CTP-версии.
При создании нового веб-сайта, скажем, такого как Facebook, можно разрабатывать приложения на платформе Windows Azure. Благодаря тому что данная платформа поддерживает как веб-службы, так и фоновые процессы, приложение может предоставлять интерактивный интерфейс пользо- вателя и асинхронно выполнять работу для пользователей. Вместо того чтобы тратить время и деньги, думая об инфраструктуре, пусковая группа может полностью сосредоточить свое внимание на разработке кода, который будет приносить пользу пользователям и инвесторам. Компания может также запустить небольшой веб-сайт, требующий незначительных затрат, если у ее при- ложения очень мало пользователей. Если приложение приобретает популярность и количество пользователей растет, Windows Azure при необходимости позволяет масштабировать его.
5

Независимые поставщики программного обеспечения, создающие версию программы как службы имеющегося локального приложения Windows, могут разработать его на базе Windows Azure.
Благодаря тому что Windows Azure главным образом обеспечивает стандартную среду Windows, перемещение бизнес-логики приложения на эту «облачную» платформу не должно создавать особых проблем. Еще раз подчеркнем: разработка на базе имеющейся платформы позволяет независимым поставщикам ПО сосредоточить внимание на бизнес-логике, то есть на том, что позволяет им делать деньги, а не тратить время на инфраструктуру.
Компания, создающая приложение для своих заказчиков, может выбрать для его разработки платформу Windows Azure. В силу того что Windows Azure поддерживает .NET, не представляет труда найти разработчиков с соответствующими навыками, к тому же за разумную плату. Выполнение приложения в центрах обработки данных Майкрософт освобождает предприятия от ответствен- ности и расходов на поддержку собственных серверов, превращая капитальные затраты в экс- плуатационные расходы. В особенности если у приложения имеются периоды пиковой нагрузки
(если это, например, сетевой магазин цветов, которые необходимо вручить во время всеобщего ажиотажа 8 марта), предоставление корпорации Майкрософт функции поддержки большой серверной базы, необходимой для этого, может оказаться экономически выгодным.
Выполнение приложений в «облаке» — один из самых важных аспектов «облачных» вычислений.
С помощью Windows Azure корпорация Майкрософт обеспечивает как платформу для выполнения приложений, так и способ хранения данных. По мере того как растет интерес к «облачным» вычислениям, ожидается создание еще большего количества приложений Windows для этой новой области.
SQL AZURE
Один из наиболее привлекательных способов использования серверов, доступных через Интернет, — это обработка данных. Цель SQL Azure — решить эту проблему, предлагая набор веб-служб для хранения самой разной информации и работы с ней. В то время как представители Майкрософт заявляют, что постепенно SQL Azure будет содержать целый ряд возможностей, ориентированных на данные, включая создание отчетов, анализ данных и многое другое, первыми компонентами SQL
Azure станут база данных SQL Azure Database и средство синхронизации данных Huron. Это наглядно продемонстрировано на рисунке 3.
Рисунок 3. SQL Azure обеспечивает средства в Интернете, ориентированные
на работу с данными.
6

База данных SQL Azure Database (ранее известная под названием SQL Data Services) обеспечивает систему управления базами данных (СУБД) в Интернете. Эта технология позволяет локальным и веб-приложениям хранить реляционные и другие типы данных на серверах Майкрософт в центрах обработки данных Майкрософт. Так же как при работе с другими веб-технологиями, компания платит только за то, что использует, увеличивая и уменьшая объем использования (и затраты) по мере возникновения необходимости в изменениях. Использование базы данных в «облаке» также меняет характер капитальных затрат: на место инвестиций в жесткие диски и ПО для СУБД приходят эксплуатационные затраты.
В отличие от службы хранилища Windows Azure база данных SQL Azure разработана на основе Microsoft
SQL Server. Тем не менее в первоначальной CTP-версии 2008 г. база данных SQL Azure Database не предоставляла традиционный реляционный подход к данным. Учитывая отзывы заказчиков, корпо- рация Майкрософт решила внести соответствующие изменения. В дальнейшем база данных SQL
Azure Database будет поддерживать реляционные данные, обеспечивая среду SQL Server в «облаке» с индексами, представлениями, хранимыми процедурами, триггерами и многим другим. Доступ к этим данным можно получить с помощью
ADO.NET
и других интерфейсов доступа к данным Windows.
Фактически приложения, которые сегодня получают доступ к SQL Server локально, будут работать почти точно так же с данными в SQL Azure Database. Для работы с этой информацией в «облаке» заказчики могут также использовать локальное ПО, такое как службы отчетов SQL Server.
В то время как приложения могут использовать базу данных SQL Azure Database в значительной степени так же, как локальную СУБД, требования к управлению существенно сокращены. Вместо того чтобы беспокоиться о технике, например обеспечивать мониторинг использования диска и обслуживание файлов журнала, заказчик SQL Azure Database может сосредоточить внимание на том, что действительно важно: на данных. А корпорация Майкрософт будет отвечать за вопросы эксплуатации. Кроме того, так же как в случае с другими компонентами платформы Windows Azure, использование SQL Azure Database не составляет труда. Нужно просто зайти на веб-портал и пре- доставить необходимую информацию.
Второй компонент SQL Azure был заявлен под названием Huron Data Sync. Эта технология, разра- ботанная на основе Microsoft Sync Framework и SQL Azure Database, позволяет синхронизировать реляционные данные в разных локальных СУБД. Владельцы данных могут определять, что именно должно синхронизироваться, как должны разрешаться конфликты и многое другое.
Приложения могут использовать SQL Azure самыми разными способами. Приведем несколько примеров.
Приложение Windows Azure может хранить данные в SQL Azure Database. Несмотря на то что
Windows Azure обеспечивает собственное хранилище, реляционные таблицы не входят в число предлагаемых вариантов. Учитывая то, что многие имеющиеся приложения используют реляционное хранилище, а многие разработчики знают, как с ним работать, значительное количество прило- жений Windows Azure, скорее всего, будет работать с данными привычным способом, то есть с опорой на SQL Azure Database. Для повышения производительности заказчики могут указать, что определенное приложение Windows Azure должно выполняться в том же центре обработки данных, где SQL Azure Database хранит информацию этого приложения.
В небольшой компании или подразделении большой организации приложение может использовать
SQL Azure Database. Вместо того чтобы хранить данные в базе данных SQL Server или Access, работающей на компьютере под чьим-то столом, приложение может использовать преимущества надежного и отказоустойчивого «облачного» хранилища.
Предположим, производитель хочет сделать информацию о продукте доступной для своей дилерской сети и непосредственно для заказчиков. Размещение данных в SQL Azure Database позволит сделать их доступными для приложений, выполняемых на стороне дилеров, и для ориентированных на заказчиков веб-приложений, которые выполняются на стороне производителя.
Компания с клиентской базой данных, реплицированной в географически удаленных местах, должна использовать компонент Huron для синхронизации этих реплик. Возможно, в каждой из геогра- фических точек требуется собственная копия данных для повышения производительности, обеспечения доступности или по каким-то иным причинам. Автоматическая синхронизация может сделать такое обязательное распределение менее проблематичным.
7

Идет ли речь о приложении Windows Azure, обеспечении большей доступности данных, синхронизации этих данных или о чем-то еще, службы данных в Интернете могут оказаться очень полезными. По мере появления новых технологий в рамках SQL Azure организации будут получать возможность использова- ния Интернета для выполнения все большего количества задач, ориентированных на работу с данными.
.NET SERVICES
Выполнение приложений и хранение данных в Интернете относятся к важным аспектам вычислительной сетевой среды. Однако они далеко не исчерпывают ее возможности. Другая возможность заключается в обеспечении инфраструктуры служб на базе «облака», которые могут использоваться локальными приложениями или веб-приложениями. Заполнить этот пробел и призваны службы .NET Services.
Первоначально известные как BizTalk Services, службы .NET Services предлагают функции для решения общих проблем инфраструктуры при создании распределенных приложений. На рисунке 4 показаны их основные компоненты.
Рисунок 4. Службы .NET Services обеспечивают инфраструктуру в «облаке», которая может
быть использована для веб-приложений и локальных приложений.
Службы .NET Services состоят из следующих компонентов.
Управление доступом. Получающий все большее распространение подход к удостоверениям заключается в том, что каждый пользователь должен предоставить приложению маркер, содержащий некоторый набор утверждений. На основании этих утверждений приложение решает, что раз- решено делать пользователю. Эффективное осуществление этой процедуры в масштабах компании требует федерации удостоверений, которая позволяет принимать утверждения, сделанные в одной области удостоверений, в другой области. Может также потребоваться преобразование
утверждений, изменяющее их при передаче из одной области удостоверений в другую. Служба управления доступом обеспечивает реализацию обеих функций на основе «облака».
Шина служб. Предоставление служб приложений в Интернете гораздо труднее, чем может пока- заться. Задача шины служб — упростить эту процедуру, позволяя приложениям предоставлять конечные точки веб-служб, доступ к которым может быть получен другими приложениями — локальными или работающими в «облаке». Каждой предоставленной конечной точке присваивается
URI, который клиенты могут использовать для поиска службы и получения доступа к ней. Шина служб также решает проблему преобразования сетевых адресов и прохождения через межсетевые экраны без открытия новых портов для предоставленных приложений.
8

Приведем несколько примеров использования службы .NET Services.
Независимый поставщик ПО, который поставляет приложение, необходимое заказчикам из разных организаций, может использовать службу управления доступом для упрощения разработки и эксплуатации приложения. Например, этот компонент .NET Services может преобразовывать различные утверждения, применяемые в разных организациях с различными технологиями иден- тификации, в согласованный набор, подходящий для приложения независимого поставщика ПО.
Такое преобразование позволяет также разгрузить механизм федерации удостоверений за счет службы управления доступом, освобождая независимых поставщиков ПО от необходимости выполнения собственной локальной программы федерации.
Предположим, предприятие хочет открыть доступ к одному из своих приложений торговым парт- нерам. Оно может распределить функции приложения с помощью веб-служб SOAP или RESTful и зарегистрировать их конечные точки с помощью шины служб. Затем торговые партнеры могут использовать шину для поиска конечных точек и доступа к службам. Это позволяет снизить риски, связанные с предоставлением приложения, поскольку не требует открытия новых портов в межсетевом экране компании. Организация может также использовать службу управления доступом, предназначенную для работы с шиной служб, для рационализации сведений о проверке подлинности, отправленной приложению ее партнерами.
Так же как в случае Windows Azure, предоставляется портал, доступный с помощью браузера, чтобы дать заказчикам возможность подписаться на службы .NET Services с помощью Windows Live ID. Цель корпорации Майкрософт, достигаемая с помощью .NET Services, совершенно очевидна: обеспечить полезную «облачную» инфраструктуру для распределенных приложений.
БОЛЕЕ ПОДРОБНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ

Важен первый шаг — получение широкого представления о платформе Windows Azure. Тем не менее более глубокое понимание каждой из технологий тоже очень полезно. В этом разделе мы немного подробнее рассмотрим каждого из членов семейства.
WINDOWS AZURE
Windows Azure решает две основные задачи: выполняет приложения и хранит их данные.
Соответственно этот раздел разделен на две части, посвященные каждой из областей применения.
Не менее важно и то, как управляются эти две области, поэтому в описании также будет уделено внимание данной стороне вопроса.
Выполнение приложений
В Windows Azure у приложения обычно несколько экземпляров, каждый из которых использует копию всего или части кода приложения. Каждый из экземпляров выполняется на собственной виртуальной машине (ВМ). Эти ВМ работают на 64-разрядной ОС Windows Server 2008 и пре- доставляются гипервизором, специально предназначенным для использования в Интернете.
Разработчику не нужно ни предоставлять Windows Azure собственный образ ВМ, ни беспокоиться о поддержке копии ОС Windows. CTP-версия позволяет разработчику создавать приложения с помощью экземпляров веб-роли или роли сотрудника. На рис. 5 показано, как это выглядит.
9

Рисунок 5. В CTP-версии приложения Windows Azure могут состоять из экземпляров веб-роли
и роли сотрудника, каждый из которых выполняется на собственной виртуальной машине
Как можно предположить из названия, каждый экземпляр веб-роли принимает входящие запросы HTTP
(или HTTPS) через службы Internet Information Services (IIS) 7. Веб-роль может быть развернута с помощью
ASP.NET
, WCF или другой технологии, которая работает с IIS. Как показано на рисунке 5,
Windows Azure обеспечивает встроенную балансировку нагрузки для распределения запросов по экземплярам веб-роли, являющимся частями одного и того же приложения.
Экземпляр роли сотрудника, наоборот, не может получить доступ к запросам напрямую из внешнего мира, ему запрещены любые входящие сетевые подключения, и на его ВМ не выполняются службы
IIS. Вместо этого он обычно получает данные из очереди в хранилище Windows Azure. Сообщения в этой очереди могут поступать с экземпляра веб-роли, из локального приложения или из другого источника. Откуда бы ни поступали входящие данные, экземпляр роли сотрудника может отправить данные в другую очередь или во внешний мир: исходящие сетевые подключения разрешены. В отличие от экземпляра веб-роли, который создан для обработки входящих HTTP-запросов, экземпляр роли сотрудника — это пакетное задание. Если говорить в целом, то роль сотрудника может быть реализована с помощью любой технологии Windows с методом main().
Каждая ВМ, выполняет ли она экземпляр веб-роли или роли сотрудника, содержит также агент
Windows Azure, позволяющий приложению взаимодействовать со структурой Fabric Windows Azure, как показано на рис. 5. Агент предоставляет прикладной программный интерфейс, определенный
Windows Azure, который позволяет экземпляру делать записи в поддерживаемом Windows Azure журнале, отправлять предупреждения его владельцу через Windows Azure Fabric и многое другое.
И хотя со временем все может измениться, первоначальная CTP-версия Windows Azure поддерживает отношения типа «один к одному» между ВМ и ядром физического процессора. Именно поэтому может быть гарантирована производительность каждого приложения — каждый экземпляр веб-роли и роли сотрудника имеет собственное выделенное ядро процессора. Для повышения производительности приложения его владелец может увеличить количество выполняемых экземпляров, указанных в файле конфигурации приложения. Структура Fabric Windows Azure впоследствии запускает новые
ВМ, назначает их ядрам и начинает выполнять больше экземпляров данного приложения. Структура
Fabric также определяет момент сбоя экземпляра веб-роли или роли сотрудника и запускает новый экземпляр.
10

Следует помнить, что это подразумевает: чтобы быть масштабируемыми, веб-роли Windows Azure должны работать без учета состояния. Любые клиентские данные должны записываться в хранилище
Windows Azure, отправляться в базу данных SQL Azure или возвращаться клиенту в файле cookie.
Неизменное состояние у веб-роли также является требованием встроенного балансировщика нагрузки
Windows Azure. Благодаря тому что он не позволяет создавать сходство с конкретным экземпляром веб-роли, невозможно гарантировать, что многочисленные запросы от одного и того же пользователя будут отправлены на один и тот же экземпляр.
Веб-роли и роли сотрудников внедряются с помощью стандартных технологий Windows. Однако для перемещения имеющихся приложений на платформу Windows Azure могут потребоваться некоторые изменения. Во-первых, для доступа к хранилищу Windows Azure используются службы данных
ADO.NET
, относительно новая технология, которая еще не столь распространена для локальных приложений.
(Однако приложение Windows Azure может также использовать стандарт
ADO.NET
для доступа к реляционному хранилищу, предоставляемому базой данных SQL Azure Database, что упрощает перемещение имеющегося приложения на эту «облачную» платформу.) Кроме того, экземпляры роли сотрудника обычно используют для ввода очереди в хранилище Windows Azure, абстракцию, которая недоступна в локальных средах Windows. Однако в основном среда, в которой выполняются приложения на платформе Windows Azure, очень напоминает то, с чем они сталкиваются в любой другой системе Windows Server 2008.
Что касается разработчиков, то разработка приложения Windows Azure в CTP-версии выглядит так же, как и обычного приложения Windows. Корпорация Майкрософт предоставляет шаблоны проекта
Visual Studio 2008 для создания веб-ролей Windows Azure, ролей сотрудника и сочетаний этих двух ролей. Разработчики могут использовать любой язык программирования Windows (хотя нужно сказать, что корпорация Майкрософт первоначально ориентировалась на язык C# для Windows Azure). Кроме того, пакет средств разработки Windows Azure включает версию среды Windows Azure, которая выпол- няется на компьютере разработчика. Известная под названием Windows Azure Development Fabric, она включает хранилище Windows Azure, агент Windows Azure и все остальное, с чем сталкивается приложение, выполняемое в «облаке». Разработчик может создать и отладить свое приложение с помощью локального симулятора, а затем, когда оно будет готово, выполнить его развертывание на платформе Windows Azure в «облаке». И все же некоторые вещи в «облаке» выглядят совершенно иначе. Например, к веб-приложениям невозможно прикрепить отладчик, поэтому их отладка осущест- вляется в основном с помощью записей в поддерживаемом Windows Azure журнале, которые делаются через агент Windows Azure.
Windows Azure предоставляет разработчикам и другие службы. Например, приложение Windows Azure может отправить предупреждение с помощью агента Windows Azure, а Windows Azure перенаправит его указанному получателю по электронной почте, через службу мгновенного обмена сообщениями или другим способом. При желании структура Fabric Windows Azure самостоятельно может обнаруживать сбой приложения и отправлять предупреждение. Платформа Windows Azure также предоставляет подробную информацию о потреблении ресурсов приложением, включая загрузку процессора, входящий и исходящий трафик и загрузку памяти.
Доступ к данным
Приложения работают с данными самыми разными способами. Иногда единственное, что им нужно, это большие бинарные объекты (blob), тогда как в других ситуациях требуется более структурированный способ хранения информации. А в некоторых случаях нужен только способ обмена данными между разными частями приложения. Хранилище Windows Azure удовлетворяет всем этим требованиям, как показано на рисунке 6.
11

Рисунок 6. Windows Azure позволяет хранить данные в объектах blob, таблицах и очередях,
доступ к которым осуществляется с помощью подхода RESTful по протоколу HTTP или HTTPS
Самый простой способ хранения данных в хранилище Windows Azure — это использование больших бинарных объектов (blob). Как показано на рис. 6, иерархия весьма проста. Учетная запись хранения может иметь один или несколько контейнеров, каждый из которых содержит один или несколько объектов blob. Объекты blob могут быть очень большими (до 50 ГБ каждый), а для того чтобы повысить эффективность передачи таких объектов blob, каждый из них может быть разделен на два блока.
Если происходит сбой, повторная отправка может возобновиться с последнего по времени блока, вместо того чтобы отправлять весь объект blob целиком. С объектами blob могут быть соотнесены метаданные, такие как информация о том, где была сделана фотография в формате JPEG, или кто сочинил музыку, записанную в MP3-файле.
Объекты blob вполне подходят для некоторых типов данных, но во многих ситуациях они оказываются слишком неструктурированными. Для того чтобы позволить приложениям более детально работать с данными, хранилище Windows Azure предоставляет таблицы. И пусть их название не вводит вас в заблуждение. Это не реляционные таблицы. В самом деле, несмотря на то что они называются таблицами, содержащиеся в них данные хранятся в наборе объектов со свойствами. У таблицы нет определенной схемы, в то же время свойства могут быть разных типов, таких как int, string, Bool или
DateTime. А вместо использования SQL, приложение может получить доступ к данным таблицы с помощью служб данных
ADO.NET
или LINQ. Отдельная таблица может быть довольно большой, с миллиардами объектов, содержащих терабайты данных, и если требуется повысить производи- тельность, хранилище Windows Azure может разбивать ее на несколько серверов.
Объекты blob и таблицы ориентированы на хранение данных. Третий способ хранения данных в хранилище Windows Azure, которым являются очереди, имеет совершенно другое предназначение.
Основная роль очередей — обеспечивать способ взаимодействия экземпляров веб-роли с экземплярами роли сотрудника. Например, пользователь может отправить запрос на выполнение какой-то требую- щей интенсивной обработки задачи через веб-страницу, развернутую веб-ролью Windows Azure.
Экземпляр веб-роли, который получил этот запрос, может написать сообщение в очередь с описанием работы, которая должна быть выполнена. Экземпляр роли сотрудника, который ожидает в этой очереди, может затем прочитать сообщение и выполнить задачу, указанную в нем. Полученные результаты могут быть возвращены с помощью другой очереди или обработаны каким-то другим способом.
12

Вне зависимости от способа хранения — в объектах blob, таблицах или очередях — все данные, имеющиеся в хранилище Windows Azure, реплицируются трижды. Эта репликация повышает отка- зоустойчивость, поскольку потеря копии не так страшна. Кроме того, система гарантирует согласо- ванность данных, поэтому приложение, считывающее данные, которые оно только что записало, получит именно то, чего ожидает.
Доступ к хранилищу Windows Azure можно получить с помощью приложения Windows Azure или приложения, работающего в какой-либо другой среде. В обоих случаях все три способа хранения
Windows Azure используют соглашения REST для выявления и предоставления данных. Все данные именуются с помощью URI, а доступ к ним возможен с помощью стандартных операций протокола HTTP.
Клиент .NET может также использовать службы данных
ADO.NET
и LINQ, но доступ к хранилищу
Windows Azure, скажем, из приложения Java возможен только с помощью стандарта REST. Например, объект blob может быть прочитан с помощью HTTP GET относительно универсального идентификатора
URI, форматированного следующим образом: http://<StorageAccount>. blob. core, windows. r\et//
— это идентификатор, назначенный при создании новой учетной записи хранения, он уникальным образом определяет объекты blob, таблицы и очереди, созданные с помощью этой учетной записи. и — это всего лишь имена контейнера и объекта blob, доступ к которым осуществляется по данному запросу.
Точно так же запрос в отношении конкретной таблицы выражается как HTTP GET в отношении идентификатора URI, форматированного следующим образом: http://<StorageAccount>. table, core, windows. net/?$filter=
Здесь обозначает запрашиваемую таблицу, а содержит запрос, который должен быть выполнен в отношении этой таблицы.
Даже доступ к очередям может быть осуществлен приложениями Windows Azure и внешними приложениями с помощью метода HTTP GET в отношении идентификатора URI, форматированного следующим образом: http://<StorageAccount>. queue, core, windows. r\et/
Платформа Windows Azure по отдельности загружает вычислительные ресурсы и ресурсы хранилища.
Это означает, что локальное приложение может использовать только хранилище Windows Azure, получая доступ к своим данным с помощью только что описанного метода RESTful. Благодаря тому что доступ к данным возможен непосредственно из приложений, отличных от Windows Azure, они остаются доступными, даже если использующее их приложение Windows Azure не работает.
Задача платформы приложений, идет ли речь о локальных или веб-приложениях, заключается в поддержке приложений и их данных. Windows Azure обеспечивает место и для того и для другого.
Далее мы надеемся увидеть, что было бы при использовании локальных приложений Windows вместо этой новой «облачной» платформы.
SQL AZURE
SQL Azure — общее название группы «облачных» технологий для работы с реляционными и другими типами данных. Первыми из членов этого семейства будут выпущены база данных SQL Azure Database и Huron Data Sync. В этом разделе мы более подробно остановимся на каждом из них.
SQL Azure Database
СУДБ в «облаке» выглядит привлекательно по многим причинам. Для некоторых компаний имеет смысл предоставлять поставщику специализированных услуг гарантированную надежность, обеспечивать резервное копирование и выполнение других функций управления. Доступ к данным в «облаке» можно также получить с помощью приложений, работающих в любом месте, даже на мобильных устройствах. При условии эффекта масштаба, достигаемого поставщиком услуг, использование базы данных в «облаке» может быть дешевле, чем создание собственной. Цель базы данных SQL
Azure Database заключается в обеспечении этих преимуществ. На рис. 7 показано простое схематичное представление этой технологии.
13

Рисунок 7. Приложения получают доступ к данным в SQL Azure Database по протоколу TDS
корпорации Майкрософт, позволяющему им использовать
ADO.NET
и другие общие
интерфейсы данных
Приложение, использующее SQL Azure Database, может выполняться на базе Windows Azure, в центре обработки данных корпорации, на мобильном устройстве или где-то еще. Где бы оно ни выполнялось, приложение получает доступ к данным по протоколу под названием Tabular Data Stream (TDS). Это тот же протокол, который используется для доступа к локальной базе данных SQL Server, поэтому приложение SQL Azure Database может использовать любую имеющуюся клиентскую библиотеку
SQL Server. Важнее всех из них, наверное, службы
ADO.NET
, но могут быть также использованы
ODBC и другие.
В большинстве случаев приложение, использующее SQL Azure Database, имеет дело со знакомой средой SQL Server. Однако здесь отсутствуют некоторые вещи, такие как SQL Common Language
Runtime (CLR) и поддержка пространственных данных. Кроме того, поскольку администрирование выполняется корпорацией Майкрософт, служба не предоставляет физических административных функций. (Например, заказчик не может завершить работу системы.) И, как можно ожидать от общей среды, запрос будет выполняться только ограниченное время: ни один запрос не может использовать больше предварительно заданного количества ресурсов.
И все же, несмотря на то что среда выглядит стандартно, услуги, которые получает приложение, гораздо надежнее, чем те, которые может обеспечить отдельный экземпляр SQL Server. Так же как в хранилище Windows Azure, все данные, находящиеся в базе данных SQL Azure Database, репли- цируются трижды. Кроме того, подобно хранилищу Windows Azure, служба обеспечивает большую согласованность данных. Когда запись возвращается, все копии уже записаны. Цель заключается в обеспечении надежного хранения данных даже в случае сбоя системы или сети.
14

Максимальный размер отдельной базы данных в SQL Azure Database составляет 10 ГБ. Приложение, данные которого находятся в этих пределах, может использовать одну базу данных, а приложению с большим количеством данных нужно будет создавать несколько баз данных. На рисунке 8 это наглядно показано.

Рисунок 8. Приложение может использовать одну или несколько баз данных
При использовании одной базы данных приложение видит один набор данных, поэтому запросы SQL могут использоваться для всех этих данных как обычно. Однако при использовании нескольких баз данных приложение должно разделить свои данные между ними. Так, например, информация о за- казчиках, чьи имена начинаются на букву «А», могут быть в одной базе денных, а о тех, чьи имена начинаются на букву «Б», — в другой и т. д. Несмотря на то что база данных предоставляет обычный реляционный интерфейс, приложение больше не может создавать один запрос SQL, который получает доступ ко всем данным во всех базах данных. Вместо этого приложения, которые работают с несколь- кими базами данных, должны будут знать, как эти данные разделены.
В некоторых случаях даже приложения с меньшим количеством данных могут выбрать вариант использования нескольких баз данных. Такой подход позволяет выполнять, например, параллельные запросы, поэтому в некоторых ситуациях он обеспечивает большую производительность. Аналогичным образом приложение, которое предоставляет услуги различным организациям, может использовать несколько баз данных, скажем, назначая одну базу данных каждой из организаций.
Нуждается ли приложение в нескольких базах данных или в одной, SQL Azure Database позволяет разработчикам использовать широкий спектр сценариев. Вне зависимости от решаемой проблемы основная задача технологии остается одной и той же: предоставить знакомую, надежную и недорогую базу данных для всех типов приложений.
15

Huron
В идеале данные должны храниться в одном месте. Однако на практике это часто оказывается невозможным. Многие организации имеют копии одних и тех же данных, распределенные между разными базами данных, часто находящимися в географически удаленных местах. Поддержка синхронизации этих данных трудна, но необходима.
Средство Huron позволяет решить эту проблему. Построенное на основе Microsoft Sync Framework и SQL Azure Database, оно позволяет синхронизировать реляционные данные в нескольких базах данных. На рис. 9 показаны основы этой технологии.


Рисунок 9. Huron использует Microsoft Sync Framework для синхронизации данных между
SQL Azure Database и локальными базами данных
Huron будет изначально поддерживать SQL Server и SQL Server Compact Edition. Эта технология также включает SDK, что позволяет добавлять поддержку дополнительных СУБД. Вне зависимости от используемых технологий баз данных Huron работает совершенно одинаково: изменения данных синхронизируются сначала для SQL Azure Database, а затем для других синхронизируемых СУБД.
Технология обеспечивает графический интерфейс, который дает пользователям возможность определять, какие данные и в каких базах данных должны синхронизироваться.
Синхронизация выполняется с несколькими хозяевами, то есть изменения могут быть сделаны в любой из копий. Пользователь, который настраивает синхронизацию, может также определить, как должны решаться конфликты. Можно выбрать приоритетность последней записи, требование, чтобы изменения вносились сначала в какую-то определенную базу данных, и многое другое.
16

Средство Huron, работающее вместе с SQL Azure Database, позволяет решить важные проблемы, существующие во многих организациях. По мере расширения семейства SQL Azure мы ожидаем увидеть еще больше «облачных» решений для распространенных задач, связанных с данными.
.NET SERVICES
Хранение данных в «облаке» полезно, но не меньшее значение имеет предоставление инфраструктур- ных служб на базе «облака». Эти службы могут быть использованы локальными или веб-приложениями, а также могут устранять проблемы, которые не удается решить другими способами. В этом разделе мы более подробно остановимся на предложениях корпорации Майкрософт в этой области: службе управления доступом .NET и шине служб .NET, известных под общим названием .NET Services.
Служба управления доступом
Работа с удостоверениями — основная часть большинства распределенных приложений. На основе информации об удостоверениях пользователя приложение принимает решение о том, что ему раз- решено делать. Для передачи этой информации приложение может использовать маркеры, заданные с помощью языка SAML. Маркер SAML содержит утверждения, каждое из которых несет часть инфор- мации о пользователе. Одно утверждение может содержать его имя, другое — роль, например менеджер, а третье — электронный адрес. Маркеры создаются приложением под названием служба
маркеров безопасности (STS), которое снабжает каждый из маркеров цифровой подписью для проверки его источника.
Если клиент (например, веб-браузер) имеет маркер для своего пользователя, он может представить этот маркер приложению. Затем приложение использует утверждения маркера, для того чтобы решить, что можно делать пользователю. Тем не менее существует несколько потенциальных проблем.
Что если маркер не содержит утверждений, которые нужны данному приложению? При проверке подлинности на основе утверждений каждое приложение может самостоятельно определять набор утверждений, которые должен представить пользователь. Однако служба STS, которая создала маркер, могла не поместить в него именно то, что требуется приложению.
Что если приложение не доверяет службе маркеров безопасности, которая выпустила данный маркер? Приложение не может принимать маркеры, выпущенные любой службой STS. Вместо этого приложение, как правило, получает доступ к списку сертификатов доверенных служб STS, позволяющему проверить подписи на созданных ими маркерах. Только маркеры от доверенных служб STS будут приниматься приложением.
Вставка еще одной службы маркеров безопасности может решить обе проблемы. Для того чтобы удостовериться, что маркеры содержат правильные утверждения, эта дополнительная служба STS выполняет преобразование утверждений. Служба маркеров безопасности может содержать правила, определяющие, как должны соотноситься входящие и исходящие утверждения, а затем использовать эти правила для создания нового маркера, содержащего именно те утверждения, которые требуются приложению. Решение второй проблемы, которое носит название «федерация удостоверений», требует, чтобы приложение доверяло новой службе STS. Также требуется установление отношений доверия между новой службой маркеров безопасности и той, которая создала полученный первой маркер.
Добавление еще одной службы STS позволяет выполнять две очень полезные операции — преоб- разование утверждений и федерацию удостоверений. Но где должна выполняться эта служба STS?
Можно использовать службу маркеров безопасности, выполняемую внутри организации. Такая воз- можность предоставляется на сегодняшний день несколькими поставщиками. Но почему бы не выпол- нять службу маркеров безопасности в «облаке»? Это сделает ее доступной для пользователей и приложений в любой организации. Это также позволит возложить обязанности по выполнению и поддержке службы STS на поставщика услуг.
17

Именно такие возможности предлагает служба управления доступом Access Control Service. Ведь она представляет собой службу маркеров безопасности в «облаке». Чтобы увидеть, как можно ис- пользовать такую службу STS, предположим, что независимый поставщик ПО предоставляет прило- жение, доступное через Интернет, которое может быть использовано сотрудниками различных орга- низаций. Несмотря на то что все эти организации могут снабдить своих пользователей маркерами
SAML, эти маркеры вряд ли содержат именно тот набор утверждений, который нужен приложению.
На рисунке 10 показано, как служба управления доступом может решить эти проблемы.


Рисунок 10. Служба управления доступом обеспечивает преобразование утверждений
и федерацию удостоверения на основе правил
Сначала приложение пользователя (в данном примере это веб-браузер, но может быть также клиент
WCF или что-то еще) отправляет маркер SAML пользователя в службу управления доступом (шаг 1).
Эта служба проверяет подпись маркера, чтобы удостовериться, что он был создан службой STS, которой она доверяет. Затем служба создает и подписывает новый маркер SAML, содержащий именно те утверждения, которые нужны приложению (шаг 2).
Для этого служба STS службы управления доступом использует правила, определенные владельцем приложения, к которому пытается получить доступ пользователь. Предположим, например, что при- ложение предоставляет особые права доступа любому пользователю, который является менеджером данной компании. Несмотря на то что каждая компания может включить в свой маркер утверждение, указывающее, что пользователь является менеджером, скорее всего такие утверждения будут разными.
Одна компания может использовать строку Manager (менеджер), другая — строку Supervisor (супер- вайзер), а третья — целочисленный код. Для того чтобы помочь приложению обработать эти различия, его владелец может задать в службе управления доступом правило, которое преобразует все эти утверждения в общую строку Decision Maker (принимающий решения). Теперь задача приложения значительно упрощается, поскольку для него выполнена работа по преобразованию утверждений.
Как только новый маркер будет создан, служба STS службы управления доступом возвращает его клиенту (шаг 3), который затем передает его в приложение (шаг 4). Приложение проверяет подпись маркера и убеждается, что он был действительно выпущен STS службы управления доступом. Следует помнить, что в то время как STS службы управления доступом должна поддерживать отношения доверия со службой STS каждой организации-заказчика, само приложение должно доверять только
STS службы управления доступом. Если приложение уверено в происхождении данного маркера, оно может использовать содержащиеся в нем удостоверения для принятия решения о том, что разре- шено делать данному пользователю (шаг 5).
18

Другой способ использования службы управления доступом определяется ее названием. Приложение может эффективно возлагать на эту службу принятие решений о том, на какой тип доступа имеет право каждый конкретный пользователь. Предположим, например, что для доступа к определенной функции приложения пользователь должен представить конкретное утверждение. Правила службы управления доступом для приложения могут быть определены таким образом, чтобы давать такое утверждение только тем пользователям, которые представят другие обязательные утверждения, такие как утверждения менеджера, описанные выше. Когда приложение получает маркер пользователя, оно предоставляет или запрещает доступ на основе наличия этого утверждения. Таким образом, решение было эффективно принято службой управления доступом. Это позволяет администратору задавать правила управления доступом в одном общем месте, он может также обеспечить совместное использование правил управления доступом несколькими приложениями.
Все взаимодействия со службой управления доступом основаны на стандартных протоколах, таких как WS-Trust и WS-Federation. Это делает службу доступной из приложения любого типа на любой платформе. А для того чтобы задать правила, служба предоставляет графический интерфейс поль- зователя на основе браузера и клиентский прикладной программный интерфейс для программного доступа.
Удостоверения на основе утверждений постепенно становятся стандартным подходом для распре- деленных сред. Благодаря предоставлению службы STS в «облаке», обладающей возможностью преобразования утверждений на основе правил, служба управления доступом делает этот совре- менный подход к проверке подлинности более привлекательным.
Шина служб
Предположим, у вас есть приложение, работающее внутри организации, которое вы хотели бы предоставить для доступа ПО другой организации через Интернет. На первый взгляд, задача кажется довольно простой. Если приложение предоставляет свои функции в качестве веб-служб
(на основе подхода RESTful или SOAP), вы можете просто сделать эти веб-службы видимыми извне.
Но когда вы пытаетесь сделать это на практике, возникают некоторые проблемы.
Во-первых, как приложения в других организациях (или даже других частях вашей собственной организации) найдут конечные точки, к которым они могут подключить для доступа к вашим службам?
Неплохо было бы иметь что-то вроде реестра, в котором другие пользователи могли бы найти ваше приложение. А если они найдут его, то как запросы из ПО их организации смогут попасть в ваше при- ложение? Преобразование сетевых адресов (NAT) очень широко распространено, поэтому приложение часто не имеет фиксированного IP-адреса для предоставления его во внешней среде. Но даже если сетевое преобразование адресов NAT не использовалось, как смогут запросы проникнуть через ваш межсетевой экран? Можно открыть порты брандмауэра, чтобы разрешить доступ к вашему приложению, но большинство сетевых администраторов отнесутся к этому с неодобрением.
19

Шина служб позволяет решить все эти проблемы. На рис. 11 показано, как она это делает.

Рисунок 11. Шина служб позволяет приложению регистрировать конечные точки, а затем
заставлять другие приложения обнаруживать и использовать эти конечные точки для
доступа к его службам
Сначала ваше приложение регистрирует одну или несколько конечных точек с помощью шины служб
(шаг 1), которая предоставляет их от вашего имени. Шина служб присваивает вашей организации пространство имен URI root, в котором вы можете создать любую иерархию именования по своему усмотрению. Это позволяет присвоить вашим конечным точкам специальные легко находимые идентификаторы URI. Ваше приложение должно также открыть подключение с шиной служб для каждой конечной точки, которую она предоставляет. Шина служб держит это подключение открытым, что позволяет решить две проблемы. Во-первых, преобразование сетевых имен больше не создает трудностей, поскольку трафик в открытом подключении с шиной служб всегда будет направляться на ваше приложение. Во-вторых, поскольку приложение было инициировано из-за брандмауэра, отсутствует проблема передачи информации назад в приложение через это подключение, так как брандмауэр не будет блокировать этот трафик.
Когда приложение в какой-то другой организации (или даже в другой части вашей организации) хочет получить доступ к вашему приложению, оно контактирует с реестром шины служб (шаг 2). Для этого запроса используется протокол Atom Publishing Protocol, который возвращает сервисный документ
AtomPub со ссылками на конечные точки вашего приложения. Как только приложение получает ссылки, оно может вызвать службы, предлагаемые в этих конечных точках (шаг 3). Каждый запрос, получаемый шиной служб, затем передается в ваше приложение с ответами, проделывающими обратный путь.
И хотя это не показано на рисунке, шина служб по мере возможности устанавливает непосредственное подключение между приложением и его клиентом, делая их взаимодействие более эффективным.
Шина служб также позволяет осуществлять взаимодействие через очереди. Благодаря этому клиентское приложение может отправлять сообщения, когда слушающее приложение недоступно.
Шина служб может поставить эти сообщения в очередь на срок до недели, ожидая, пока прослушиватель не получит их. Клиент может также отправлять сообщения в очередь шины приложений, чтобы затем эти сообщения получили несколько прослушивателей.
20

Шина служб может не только упростить взаимодействие, но и повысить безопасность. Благодаря тому что клиенты теперь видят только IP-адрес, предоставляемый шиной приложений, нет необходимости предоставлять какие-либо IP-адреса вашей организации. Это позволяет вашему приложению оставаться анонимным, поскольку извне нельзя увидеть его IP-адрес. Шина служб действует как внешняя демилитаризированная зона, обеспечивая слой без косвенных связей, позволяющий сдерживать злоумышленников. И наконец, шина служб предназначена для использования со службой управления доступом, позволяющей преобразовывать утверждения на основе правил. Фактически шина служб принимает только маркеры, выпущенные STS службы управления доступом.
Приложение, службы которого желательно предоставлять через шину служб, обычно внедряется с помощью WCF. Клиенты могут быть разработаны с помощью WCF или других технологий, таких как
Java, и они могут делать запросы по протоколу SOAP или HTTP. Приложения и их клиенты также могут использовать собственные механизмы безопасности, такие как шифрование, для защиты своих взаимодействий от злоумышленников и от самой шины служб.
Предоставление приложений для доступа извне не такая простая задача, как может показаться.
Назначение шины служб — по возможности облегчить реализацию этого полезного сценария.
ЗАКЛЮЧЕНИЕ

Совершенно очевидно, что «облачные» вычисления уже стали реальностью. Для разработчиков использование преимуществ «облачных» технологий означает различные способы применения
«облачных» платформ. Выпуская платформу Windows Azure, корпорация Майкрософт представляет широкий диапазон платформенных методов удовлетворения различных потребностей:
Windows
Azure предоставляет вычислительную среду на основе Windows и среду хранения в «облаке».
SQL
Azure предоставляет СУБД в «облаке» с базой данных SQL Azure Database и возможностью синхронизации данных с помощью Huron Data Sync. Запланирован также целый ряд других веб-служб для работы с данными.
Службы .NET Services обеспечивают инфраструктуру на основе «облака» для локальных и веб-приложений.
Все эти подходы удовлетворяют самые разные потребности, и не каждый разработчик будет исполь- зовать их все. Однако вне зависимости от того, работаете ли вы для независимого поставщика ПО или корпорации, некоторые службы этой «облачной» платформы, скорее всего, окажутся полезными для приложений, которые создает ваша организация. Зарождается новая реальность, будьте готовы стать ее частью.
ОБ АВТОРЕ

Дэвид Чэппел — глава компании Chappell & Associates (
www.davidchappell.com
), расположенной в Сан–Франциско (Калифорния). Выступая с лекциями, статьями и консультациями, он помогает людям из разных стран мира больше узнать о новых технологиях, лучше использовать их и принимать более взвешенные решения об их использовании.
21

Document Outline

  • ОБЗОР ПЛАТФОРМЫ WINDOWS AZURE
    • WINDOWS AZURE
    • SQL AZURE
    • .NET SERVICES
  • БОЛЕЕ ПОДРОБНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ
    • WINDOWS AZURE
      • Выполнение приложений
      • Доступ к данным
    • SQL AZURE
      • SQL Azure Database
      • Huron
    • .NET SERVICES
      • Служба управления доступом
      • Шина служб
  • ЗАКЛЮЧЕНИЕ
  • ОБ АВТОРЕ



Поделитесь с Вашими друзьями:


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

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


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