Файл: Основы_обл_техн_лекции.pdf

Как приложения 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 при необходимости позволяет масштабировать его.

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

58

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

Компания, создающая приложение для своих заказчиков, может выбрать для его разработки платформу Windows Azure. В силу того что Windows Azure поддерживает .NET, не представляет труда найти разработчиков с соответствующими навыками к тому же за разумную плату. Выполнение приложения в центрах обработки данных Microsoft освобождает предприятия от ответственности и расходов на поддержку собственных серверов, превращая капитальные затраты в эксплуатационные расходы. В особенности если у приложения имеются периоды пиковой нагрузки (если это, например, сетевой магазин цветов, которые необходимо вручить во время всеобщего ажиотажа 8 марта), предоставление корпорации Microsoft функции поддержки большой серверной базы, необходимой для этого, может оказаться экономически выгодным.

Выполнение приложений в «облаке» — один из самых важных аспектов «облачных» вычислений. С помощью Windows Azure корпорация Microsoft обеспечивает как платформу для выполнения приложений, так и способ хранения данных. По мере того, как растет интерес к «облачным» вычислениям, ожидается создание еще большего количества приложений Windows для этой новой области.

Один из наиболее привлекательных способов использования серверов, доступных через Интернет, — это обработка данных. Цель SQL Azure — решить эту проблему, предлагая набор веб-служб для хранения самой разной информации и работы с ней. В то время, как представители Microsoft заявляют, что постепенно SQL Azure будет содержать целый ряд возможностей, ориентированных на данные, включая создание отчетов, анализ данных и многое другое, первыми компонентами SQL Azure станут база данных SQL Azure Database и средство синхронизации данных Huron. Это наглядно продемонстрировано на рисунке 4.4.

Рисунок 4.4. SQL Azure обеспечивает средства в Интернете, ориентированные на работу с данными.

59

База данных SQL Azure Database (ранее известная под названием SQL Data Services) обеспечивает систему управления базами данных (СУБД) в Интернете. Эта технология позволяет локальным и веб-приложениям хранить реляционные и другие типы данных на серверах Microsoft в центрах обработки данных Microsoft. Так же как при работе с другими веб-технологиями, компания платит только за то, что использует, увеличивая и уменьшая объем использования (и затраты) по мере возникновения необходимости в изменениях. Использование базы данных в «облаке» также меняет характер капитальных затрат: на место инвестиций в жесткие диски и ПО для СУБД приходят эксплуатационные затраты.

Вотличие от службы хранилища Windows Azure база данных SQL Azure разработана на основе Microsoft SQL Server. Тем неменее в первоначальной CTP-версии 2008 г. база данных SQL Azure Database не предоставляла традиционный реляционный подход к данным. Учитывая отзывы заказчиков, корпорация Microsoft решила внести соответствующие изменения. В дальнейшем база данных SQL Azure Database будет поддерживать реляционные данные, обеспечивая среду SQL Server в «облаке» с индексами, представлениями, хранимыми процедурами, триггерами и многим другим. Доступ к этим данным можно получить с помощью ADO.NET и других интерфейсов доступа к данным Windows. Фактически приложения, которые сегодня получают доступ к SQL Server локально, будут работать почти точно так же с данными в SQL Azure Database. Для работы с этой информацией в «облаке» заказчики могут также использовать локальное ПО, такое как службы отчетов SQL Server.

Вто время, как приложения могут использовать базу данных SQL Azure Database в значительной степени также, как локальную СУБД, требования к управлению существенно сокращены. Вместо того, чтобы беспокоиться о технике, например, обеспечивать мониторинг использования диска и обслуживание файлов журнала, заказчик SQL Azure Database может сосредоточить внимание на том, что действительно важно, на данных. Корпорация Microsoft будет отвечать за вопросы эксплуатации. Кроме того, так же как в случае с другими компонентами платформы 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, работающей на компьютере под чьим-то столом, приложение может использовать преимущества надежного и отказоустойчивого «облачного» хранилища.

60

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

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

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

Выполнение приложений и хранение данных в Интернете относятся к важным аспектам вычислительной сетевой среды. Однако они далеко не исчерпывают ее возможности. Другая возможность заключается в обеспечении инфраструктуры служб на базе «облака», которые могут использоваться локальными приложениями или вебприложениями. Заполнить этот пробел и призваны службы .NET Services.

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

Рисунок 4.5 Службы .NET Services обеспечивают инфраструктуру в «облаке», которая может быть использована для веб-приложений и локальных приложений.

Службы .NET Services состоят из следующих компонентов.

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

61

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

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

экраны без открытия новых портов для предоставленных приложений. Приведем несколько примеров использования службы .NET Services.

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

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

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

.NET Services, совершенно очевидна: обеспечить полезную «облачную» инфраструктуру для распределенных приложений.

Программное обеспечение как Сервис (SaaS)

Программное обеспечение как сервис (Software as a service, SaaS) или программное обеспечение по требованию (Software on Demand, SoD) — бизнес-модель продажи программного обеспечения, при которой поставщик разрабатывает вебприложение и самостоятельно управляет им, предоставляя заказчикам доступ к

62

программному обеспечению через Интернет. Основное преимущество модели SaaS для потребителя состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и работающего на нём программного обеспечения. Программное обеспечение как сервис является моделью распространения программного обеспечения, в которой приложения размещены у вендора SaaS или поставщика услуг и доступны для клиентов по сети, как правило, Интернет. Модель SaaS доставки приложений становится все более и более распространенной технологией, которая поддерживает веб-службы и сервис-ориентированную архитектуру (SOA). SaaS также часто ассоциирована с моделью лицензирования, когда оплата происходит по мере получения услуг. Тем временем, услуги широкополосных сетей стали все более и более доступными, для поддержки доступа пользователей из большего количества мест по всему миру.

Огромные успехи, достигнутые поставщиками услуг интернет (ISP), чтобы увеличить полосу пропускания и сохранить возможность использования более мощных микропроцессоров вместе с недорогими устройствами хранения данных. Это обеспечивает огромную платформу для того, чтобы проектировать, разворачивать и использовать программное обеспечение через все области бизнес- и частных вычислений. Приложения SaaS также должны быть в состоянии взаимодейстововать с другими данными и другими приложениями среди большого разнообразия окружающих сред и платформ. Компания IDC описывает две немного отличающихся модели поставки SaaS.

SaaS чаще всего предназначен для обеспечения бизнес функциональности программного обеспечения для корпоративных клиентов по низкой цене, что позволяет избавиться от установки, управления, поддержки, лицензирования и высоких затрат в компании. Большинству клиентов неинтересно знать, как или почему программное обеспечение реализовано, развернуто и т.д., но все они, в тоже время, имеют потребность в использовании программное обеспечение в их работе. Многие типы программного обеспечения хорошо удовлетворяют модели SaaS (например, бухгалтерский учет, работа с клиентами, электронная почта, учет трудовых ресурсов, ИТ безопасность, управление ИТ, видеоконференцсвязь, веб-аналитика, управление веб-контентом). Различие между SaaS и более ранними способами доставки приложений через Интернет в том, что решения SaaS были разработаны специально, чтобы работать с веб браузерами. Архитектура приложений на основе SaaS специально предназначена для поддержки обработки запросов от большого количества пользователей. В этом и заключается большая разница между традиционным клиент-серверным приложением решением, расположенным у поставщиков услуг. С другой стороны, поставщики услуг SaaS увеличивают экономию масштабирования при развертывании, управлении, поддержке и обслуживании их предложений.

Много типов компонентов программного обеспечения и Фреймворков могут быть использованы при разработке приложений SaaS. Используя новые технологии в этих современных компонентах и средах разработки приложений, можно значительно уменьшить время разработки и стоимости преобразования традиционного продукта в решение SaaS. Согласно Microsoft, SaaS архитектура может быть классифицирована в один из четырех уровней, с ключевыми признаками: простота конфигурации, эффективность при многопользовательском доступе и масштабируемость. Каждый уровень отличается от предыдущего добавлением одного из этих признаков. Рассмотрим уровни, описанные Microsoft:

Архитектурный Уровень 1 — Специальный/Настраиваемый.

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

63