Базовые технологии, использованные для реализации Microsoft Windows Azure

Цель лекции: Ознакомление с принципами и технологией (.NET), используемой для реализации Microsoft Windows Azure.

Презентацию к данной лекции Вы можете скачать здесь.

4.1. Введение

Данная лекция знакомит с платформой .NET – базой для реализации Windows Azure. Рассмотрены Web-сервисы .NET, на которых базируется архитектура и реализация Azure.

Реализация платформы Windows Azure базируется на платформе .NET – платформе надежного и безопасного многоязыкового программирования.

В текстах и презентациях данной и последующих лекций использованы материалы презентаций [1] коллег из Института прикладных наук Верхней Австрии, за что автор выражает им глубокую благодарность.

4.2. Обзор архитектуры .NET

Windows Azure реализована на базе .NET.

.NET – платформа надежного и безопасного многоязыкового программирования.

Основана на единой для всех языков инфраструктуре (CLI), общей системе типов (CTS), общей системе поддержки выполнения (CLR).

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

Исполнение программы в CLR реализовано как последовательность вызовов методов и just-in-time (динамическая) компиляция каждого метода в native-код при первом вызове, с последующими вызовами native-кода.

Метаданные могут быть аннотированы атрибутами, как встроенными, так и пользовательскими.

На использовании метаданных основан динамический контроль типов и безопасности, выполняемый CLR.

4.3. Основные идеи и принципы .NET

Основные идеи и принципы .NET следующие. Это компиляция с любого языка в промежуточный двоичный код MSIL (CIL) – постфиксную форму представления программ; генерация компилятором так называемых метаданных – информации о типах,

определяемых и используемых в программном модуле для .NET. Промежуточный код, метаданные, плюс так называемый манифест (список содержимого двоичного кода)

составляют сборку (assembly) – логическую единицу представления двоичного кода в .NET. Во время выполнения программы, при первом вызове каждого метода, его промежуточный код компилируется специальным компилятором (just-in-time, или JIT, компилятором) в платформно-зависимый (native) код аппаратной платформы (машины), на которой исполняется программа. Де-факто стандартом для представления конфигурационной информации и передачи данных серез сеть в .NET является XML.

4.4. Преимущества подхода .NET

Преимуществом подхода .NET является независимость двоичного кода (CIL) от конкретной апппаратной платформы. Также .NET выполняет код в особом режиме – managed execution, в котором гарантируется полный контроль типов и безопасности, что обеспечивает надежность и безопасность программ, в отличие от использования более старых языков и платформ, например, Си.

Многоязыковое программирование – еще один важнейший принцип .NET: программист может разрабатывать модули своей программы на любых удобных ему языках, а .NET обеспечивает совместимость (interoperability) этих модулей в рамках одной программы.

Повышенные требования к безопасности – еще одна характерная черта .NET. Наконец, .NET имеет очень удобные и современные механизмы поддержки Web-программирования.

4.5. Архитектура .NET Framework

На рис. 4.1 приведена архитектура базовой библиотеки классов (BCL) .NET. Их использование ясно из их названий. Весьма важно, что все эти классы могут быть использованы при программировании на любом языке .NET – C#, Visual Basic, Managed C++ и др.

Наиболее важны для данного курса пространства имен System.Web – поддержка Web-сервисов – и System.Security – поддержка установки, проверки и конфигурирования полномочий безопасности сборок.

4.6. Общая система типов .NET

Общая система типов .NET (CTS) – весьма удачная унификация систем типов данных современных языков программирования. Подчеркнем, что такая унификация просто необходима в .NET для поддержки многоязыкового программирования (CLR должна "понимать" типы каждого языка одинаково.

Различаются следующие разновидности типов в CTS.

Типы-значения и типы-ссылки – две основных разновидности типов, воплощающие два различных подхода к представлению значений и объектов – контейнерный и ссылочный.

Простые типы (int, double, unsigned int, native int и др.), разумеется, относятся к типам-значениям.

Структуры, что весьма полезно, также относятся к типам-значениям, а не к объектам. Это позволяет описать в них собственные методы. Единственное, чего нет в структурах, по сравнению с классами, - это наследования. Структуры размещаются в стеке. Объекты (принадлежащие некоторым классам) – в куче.

Указатели (managed pointers) - это разновидность указателей, на которой базируются проверки типов и безопасности. Управляемый указатель в .NET содержит ссылку на тип объекта (на метаданные), благодаря чему тип и атрибуты любого объекта можно проверить во время выполнения.

Классы имеют обычный смысл, как в других системах ООП.

Интерфейсы – также стандартная концепция для современных яззыков ООП – Java, C#, VB и др. Интерфейс – совокупность заголовков методов, реализуемых некоторым классом.

Делегаты и события– типы данных для обработки событий. Тип делегата описывает типовую структуру заголовка обработчика события, представленного в виде callback-метода. При описании события указывается конкретный тип делегата.

4.7. Язык C#: Определение классов

Язык C# разработан специально для платформы .NET, хотя не является обязательным и единственным для этой платформы (в отличие от Java). Классы в C# определяются традиционным для ООП образом – как набор полей и методов. В дополнение к другим языкам, определение класса может также содержать свойства (обобщенные поля с операциями get и set); индексаторы; события; делегаты. Пример класса:

public class Person :IPersonAge
{
   private int YOB;
   public Person() 
   {
   }
   public int YearOfBirth
   {
      get { return YOB; }; 
      set { YOB = value; };
   } 
   public int GetAgeToday()
   { 
      return Today()-
             YearOfBirth 
   }; 
}

4.8. Web-сервисы в .NET

Концепция Web-сервиса в .NET поддерживает сервисы в виде классов, интерфейс которых доступен через Web, соблюдающие ряд стандартов (WSDL, SOAP, XML), основанные на библиотеке классов .NET Framework.

На рис. 4.2 приведена структура распределенного Web-приложения.

Приложение состоит из клиентской и серверной частей. Web-сервис должен удовлетворять определенному контракту (реализовывать определенный интерфейс).

Инфраструктура Web-сервисов представлена на рис. 4.3.

Web-сервис может обрабатывать несколько видов запросов Web-клиентов. При обнаружении (открытии) сервиса клиент передает запрос вида vsdisco, в ответ на который сервисы открытия (UDDI) сообщают о месте расположения Web-сервиса. В ответ на другой запрос – WSDL – сервис сообщает клиенту структуру своего интерфейса в формате XML с соблюдением стандарта WSDL (Web Service Description Language). В ответ на запрос asmx Web-сервис посылает свой файл реализации в формате XML.

На рис. 4.4 приведен простой пример кода Web-сервиса, выполняющего вычитание двух чисел и выдающего результат, на рис. 4.5 представлена структура WSDL-спецификации Web-сервисов, состоящей из сервисов, портов и сообщений.

Пример WSDL-описания Web-сервиса:

<definitions name="serviceName">
 <import namespace="http://namespacePath"
         location="http://path/fileName.wsdl">
 <portType name="serviceNamePortType">
   <operation name="opName">
      <input message="msgNameInput" />
      <output message="msgNameOutput" />
   </operation>
 </portType>
 <binding name="serviceNameSoapBinding">
    <soap:operation soapAction="http://..." />
 </binding>
 <service name="serviceName">
   <port name="serviceNamePort" binding="bindingName">
      <soap:address location="http://..." />
   </port>
 </service>
</definitions>

Использование Web-сервисов основано на следующих принципах. Полностью разделена логика размещения и вызова: сервис представлен в виде пары файлов: .aspx и .aspx.cs (или .aspx.vb). Файлы .aspx предназначены для дизайнеров, файлы .aspx.cs - для программистов. Таким образом достигается легкость сопровождения приложения.

Фрагмент кода сервиса:

<%@ Import Namespace="MathServiceSpace" %>
            <script language="C#" runat="server">
           public void Submit_Click(Object S, EventArgs E) {
          service.Add(operand1, operand2);
            ...
           </script>
                 ...
       <input OnServerClick="Submit_Click" runat="server" ...>

4.9. Архитектура Windows Azure и реализация облачных Web-сервисов

Перейдем теперь собственно к предмету рассмотрения – архитектуре Azure и реализации облачных Web-сервисов средствами .NET.

Архитектура Azure представлена на рис. 4.5.

Fabric - это сеть взаимосвязанных узлов: Commodity –серверы, высокоскоростные роутеры, переключатели, волоконно-оптические коннекторы.

Azure Fabric Controller – сервис, который осуществляет мониторинг и предоставляет виртуальные машины для исполнения облачных приложений.

Главные сервисы Windows Azure следующие:

- Compute: Хостинг масштабируемых сервисов на платформе Windows Server 2008.

- Storage: управление данными (не реляционными).

- Network: Ресурсы для взаимодействия со внешними приложениями (Service Bus).

Функции Fabric Controller:

- Fault Domains: Единица обработки ошибок в ЦОД (например, кластер машин).

- Update Domains: модификация областей при апгрейдах (ОС, сервисы).

Владельцы приложений описывают требуемые ресурсы в виде дескрипторов ресурсов (моделей сервисов).

Fabric Controller автоматически предоставляет требуемые ресурсы.

Fabric Controller обеспечивает устойчивость ресурсов к ошибкам и быстрый доступ к ним, раннее обнаружение ошибок в приложениях, создание дополнительных экземпляров по требованию. Экземпляры размещаются поверх fault и update domains.

В Azure различаются роли Web и Worker (см. рис. 4.6). По существу, каждая роль в Azure – это определенная разновидность приложения.

Web-роль – это интерактивное .NET – приложение, обслуживаемое IIS, - Web Application или Web Service Windows Communication Foundation (WCF).

Worker-роль – это независимый изолированный фоновый процесс. Предоставляются способы доступа к нему со стороны внешних приложений.

Fabric Agent сохраняет метрики ресурсов, такие, как использования и ошибки.

Модель сервисов: Определение сервисов. Файл ServiceDefiniton.csdef определяет общую структуру сервиса:

Файл определения сервиса обрабатывается во время развертывания приложения.

Структура файла определения сервисов изображена на рис. 4.7.

Модель сервисов: Конфигурация сервисов. Файл ServiceConfiguration.csdef задает конфигурацию сервисов. В нем указывается число экземпляров каждой роли и определяются значения для установок конфигурации.

Содержимое файла ServiceConfiguration может быть изменено во время выполнения.

Структура файла конфигурации сервисов изображена на рис. 4.8.

Диаграмма классов Windows Azure Role API изображена на рис. 4.9.

Класс BasicEntryPoint (с потомками MyWebRole и MyWorkerRole) содержит методы жизненного цикла - onStart(), onStop(), run().

Класс RoleEnvironment имеет потомков Role и RoleInstance.

Реализация ролей изображена на рис. 4.10.

В реализации роли определяется класс-потомок RoleEntryPoint и перегружаются методы жизненного цикла. Обычно перегружается метод OnStart(). Регистрируется обработчик, который прослушивает изменения в конфигурации учетной записи облачной памяти. Когда обнаруживается изменение, роль повторно стартуется (переиспользуется).

Реализация ролей Web и Worker изображена на рис. 4.11.

При реализации Web Role нет никаких отличий от стандартов ASP.NET Web Forms, ASP.NET MVC или WCF-приложений.

При реализации Worker Role переопределяется метод Run() класса RoleEntryPoint. Этот метод служит в качестве главного потока исполнения для этой роли.

Альтернатива: можно прослушивать внешние HTTP(S) - или TCP- коммуникационные точки для входящих сообщений.

Взаимодействие между ролями изображено на рис. 4.12.

Экземпляры ролей могут взаимодействовать асинхронно с помощью очередей.

Это предпочтительный метод для надежного обмена сообщениями.

Экземпляры ролей могут также взаимодействовать непосредственно с помощью TCP- или HTTP(S) - соединений.

Взаимодействие между ролями на основе WCF/TCP изображено на рисунках 4.13, 4.14, 4.15.

В примере реализуется сервис xxx. С помощью атрибутов определяется контракт сервиса. Для конфигурирования worker-роли добавляются внешние или внутренние коммуникационные точки. Реализуется хостинг WCF-сервиса. При реализации клиента, при использовании внутренних коммуникационных точек отправитель должен выполнять балансировку загрузки вручную. Необходимо использовать RoleEnvironment.Roles["TargetRole"] для поиска этих коммуникационных точек.

4.10. Резюме

Сервисы .NET - надежная и безопасная основа для реализации Azure. Дополнительные детали по поводу реализации компонент Fabric, Storage, Compute приведены далее в соответствующих лекциях, посвященных этим компонентам Azure.

Ключевые термины

Azure Fabric Controller – сервис, который осуществляет мониторинг и предоставляет виртуальные машины для исполнения облачных приложений

Web-роль – интерактивное .NET – приложение, обслуживаемое IIS, - Web Application или Web-сервис, основанный на Windows Communication Foundation (WCF).

Worker-роль – независимый изолированный фоновый процесс. Предоставляются способы доступа к нему со стороны внешних приложений.

Краткие итоги

Реализация платформы Windows Azure базируется на платформе .NET – платформе надежного и безопасного многоязыкового программирования. .NET обеспечивает управляемое выполнение приложений. Основана на общей системе типов и общей системе поддержки выполнения. Web-сервисы .NET базируются на стандарте WSDL.

В архитектуре Azure основной компонентой является Fabric. Она управляет приложениями через Fabric Controller. Главные сервисы Azure – это Compute, Storage и Network.

Среди исполняемых программных компонент Azure различаются Web-роль и Worker-роль. Web-роль – это интерактивное облачное Web-приложение, Worker-роль – это независимый процесс, исполняемый в облаке.

Модель (структура) сервиса и конфигурация сервиса задаются конфигурационными файлами формата XML.

Экземпляры ролей могут взаимодействовать либо асинхронно с помощью очереди сообщений, либо непосредственно через TCP- или HTTPS-соединения.

Набор для практики

Вопросы

Упражнения

Темы для курсовых работ, рефератов, эссе