Azure Queue Services

Windows Azure Queue предоставляет надежный механизм доставки сообщений. Она предлагает простой алгоритм диспетчеризации асинхронных заданий, который обеспечивает возможность подключения к разным компонентам приложения в облаке. Очереди Windows Azure Queue характеризуются высокой надежностью, постоянством и производительностью. Текущая реализация гарантирует, по крайней мере, однократную обработку сообщения. Более того, Windows Azure Queue имеет REST-интерфейс, таким образом, приложения могут создаваться на любом языке программирования и выполнять доступ к очереди через веб в любое время из любой точки Интернета.

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

Рис. 7.4. Построение приложений для облака с использованием Azure Queue

Приведенный выше рисунок иллюстрирует простой и распространенный сценарий для приложений в облаке. Имеется ряд веб ролей, на которых размещается интерфейсная логика обработки веб-запросов. Также существует ряд рабочих ролей, реализующих бизнес-логику приложения. Веб роли обмениваются информацией с рабочими ролями посредством наборов запросов. Устойчивое состояние приложения может сохраняться в хранилищах Windows Azure Blob и Windows Azure Table.

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

Такое приложение может использовать описанную ранее архитектуру. Веб-роли реализуют уровень представления и обрабатывают веб-запросы пользователей. Пользователи могут загружать видео через веб-интерфейсы. Видео-файлы могут храниться как большие двоичные объекты в хранилище Azure Blob. Приложение может также обслуживать ряд таблиц для учета имеющихся видеофайлов и хранения индексов, используемых для поиска. Рабочие роли выполняют преобразование входящих видеофайлов в разные форматы и сохранение их в хранилище Azure Blob. Рабочие роли также отвечают за обновление таблиц этого приложения в Azure Table. При получении запроса пользователя (например, запроса на загрузку видео) веб-роли создают рабочий элемент и помещают его в очередь запросов. Рабочие роли извлекают эти рабочие элементы из очереди и обрабатывают соответствующим образом. В случае успешной обработки рабочая роль должна удалить рабочий элемент из очереди во избежание повторной его обработки другой рабочей ролью.

Благодаря применению Windows Azure Queue такая архитектура обладает рядом преимуществ:

1. Масштабируемость – Приложение может легче масштабироваться соответственно нуждам трафика. Вот преимущества, связанные с масштабированием: Во-первых, длина очереди напрямую отражает насколько хорошо рабочие роли справляются с общей рабочей нагрузкой. Увеличение очереди свидетельствует о том, что рабочие роли не могут обрабатывать данные с необходимой скоростью. В этом случае приложению может потребоваться увеличить количество рабочих ролей, чтобы обеспечить более быструю обработку. Если длина очереди неизменно остается близкой к нулю, это означает, что серверная часть приложения обладает большими вычислительными мощностями, чем требуется. В этом случае приложение может сократить количество рабочих ролей для обеспечения рационального расходования ресурсов. Отслеживая размеры очереди и настраивая количество внутренних узлов, приложения могут эффективно масштабироваться соответственно объемам трафика. Во-вторых, применение очередей позволяет разделить части приложения и выполнять их масштабирование независимо друг от друга, что намного упрощает эту задачу. В данном примере веб-роли и рабочие роли отделены друг от друга и обмениваются информацией через очереди. Это позволяет настраивать количество веб-ролей и рабочих ролей независимо друг от друга без влияния на логику приложения. Таким образом, приложение может свободно масштабировать критически важные компоненты, добавляя для них больше ресурсов/компьютеров. В-третьих, применение очередей обеспечивает гибкость для эффективного использования ресурсов в приложении, что повышает эффективность масштабирования. То есть для рабочих элементов с разными приоритетами и/или разных размеров могут использоваться разные очереди, которые будут обрабатываться разными пулами рабочих ролей. В этом случае приложение может распределять соответствующие ресурсы (например, с точки зрения количества серверов) для каждого пула, таким образом, обеспечивая эффективное использование доступных ресурсов при разных характеристиках трафика. Например, рабочие элементы, имеющие критически важное значение для всей задачи, могут быть помещены в отдельную очередь. Это обеспечит их обработку независимо от всех остальных задач. Кроме того, отдельная очередь может использоваться для рабочих элементов, обработка которых требует привлечения большого количества ресурсов (например, преобразование видео). Для каждой из этих очередей могут использоваться разные пулы рабочих ролей. Приложение может настраивать размер каждого из пулов независимо, соответственно поступающему трафику.

2. Разделение ролей - Использование очередей позволяет разделить разные части приложения, что обеспечивает существенную гибкость и расширяемость с точки зрения построения приложения. Сообщения в очереди могут быть в стандартном или расширяемом формате, таком как XML, что обеспечивает независимость компонентов на обоих концах очереди друг от друга, поскольку они могут понимать сообщения в очереди. Разные части системы могут быть реализованы с использованием разных технологий и языков программирования. Например, компонент на стороне очереди может быть написан на.NET Framework, а другой компонент – на Python. Более того, изменения, происходящие внутри компонента, не имеют никакого влияния на остальную систему. Например, компонент может быть изменен с применением совершенно другой технологии или языка программирования, при этом система будет продолжать работать точно так же, и для этого не придется изменять другие компоненты, поскольку использование очередей обеспечивает разделение компонентов. Кроме того, и спользование очередей делает возможным сосуществование в системе разных реализаций одного и того же компонента, т.е. приложение может свободно переходить к новым технологиям. В рассматриваемом выше примере можно постепенно уходить от компонентов, созданных с применением устаревших технологий, и заменять их новыми реализациями. Старая и новая реализации могут выполняться одновременно на разных серверах и обрабатывать рабочие элементы одной очереди. При этом другие компоненты приложения никак не будут затронуты.

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

Итак, благодаря модели очереди приложения застрахованы от потери данных и снижения надежности даже в условиях систематических сбоев компонентов приложения. Для обеспечения корректной работы этой модели разработчик приложения должен обеспечить идемпотентность обработки рабочих элементов очереди рабочими ролями. Благодаря этому, прежде чем рабочий элемент будет полностью обработан и удален из очереди, допускаются его многократные частичные обработки, прерывающиеся в результате сбоев.

Windows Azure Queue имеет следующую модель данных.

• Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища.
• Это самый высокий уровень пространства имен для доступа к очередям и их сообщениям. Для использования Windows Azure Storage пользователь должен создать учетную запись хранилища. Выполняется это через веб-интерфейс портала Windows Azure Portal. При создании учетной записи пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса.

Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации через проверку достоверности подписи HMAC.

• Учетная запись может иметь множество очередей.
• Очередь – Очередь содержит множество сообщений. Область действия имени очереди ограничена учетной записью.

1. Количество сообщений в очереди не ограничено
2. Сообщение хранится максимум неделю. Система удаляет сообщения, поступившие более недели назад, в процессе сборки мусора.
3. С очередями могут быть ассоциированы метаданные. Метаданные представляются в форме пар <имя, значение>, их размер может составлять максимум 8KБ на очередь.
• Сообщения – Сообщения хранятся в очередях. Каждое сообщение может быть размером не более 8КБ. Для хранения данных большего размера используются хранилища Azure Blob или Azure Table, а в сообщении указывается имя большого двоичного объекта/сущности. Обратите внимание, что когда сообщение помещается в хранилище, его данные могут быть двоичными. Но при извлечении сообщений из хранилища ответ формируется в формате XML, и данные сообщения возвращаются base64-кодированными. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз. Рассмотрим некоторые параметры, используемые Azure Queue Service:
1. MessageID: Значение GUID, которое идентифицирует сообщение в очереди.
2. VisibilityTimeout: Целое значение, определяющее время ожидания видимости сообщения в секундах. Максимальное значение – 2 часа. Значение по умолчанию – 30 секунд.
3. PopReceipt: Строка, возвращаемая для каждого извлеченного сообщения. Эта строка, вместе с MessageID, необходима для удаления сообщения из очереди (Queue). Данный параметр следует рассматривать как непрозрачный, поскольку в будущем его формат и содержимое могут быть изменены.
4. MessageTTL: Определяет срок жизни (time-to-live, TTL) сообщения в секундах. Максимально допустимый срок жизни – 7 дней. Если этот параметр опущен, срок жизни по умолчанию – 7 дней. Если в течение срока жизни сообщение не будет удалено из очереди, оно будет удалено системой хранения в процессе сборки мусора.

URI конкретной очереди структурировано следующим образом:

http://<учетнаязапись>.queue.core.windows.net/<ИмяОчереди>

Первая часть имени хоста образована именем учетной записи хранилища, за которым следует ключевое слово "queue". Это обеспечивает направление запроса в часть Windows Azure Storage, которая обрабатывает запросы очереди. За именем хоста идет имя очереди. Существуют ограничения именования учетных записей и очередей (подробнее об этом рассказывается в документе Windows Azure SDK). Например, имя очереди не может включать символ "/".

Любой доступ к Windows Azure Queue выполняется через HTTP-интерфейс REST. Поддерживаются как HTTP, так и HTTPS протоколы.

К командам HTTP/REST на уровне учетной записи относятся:

• List Queues – Представить список всех очередей данной учетной записи.

К командам HTTP/REST на уровне очереди относятся:

• Create Queue – Создать очередь под данной учетной записью.
• Delete Queue – Удалить указанную очередь и ее содержимое без возможности восстановления.
• Set Queue Metadata – Задать/обновить определяемые пользователем метаданные очереди. Метаданные ассоциированы с очередью в виде пар имя/значение. Эта команда обеспечит перезапись всех существующих метаданных новыми.
• Get Queue Metadata – Извлечь определяемые пользователем метаданные очереди, а также примерное число сообщений в заданной очереди.

Операции уровня очереди могут выполняться с использованием следующего URL:

http://<учетнаязапись>.queue.core.windows.net/<ИмяОчереди>

К командам HTTP/REST, поддерживаемым для реализации операций на уровне сообщения, относятся:

• PutMessage (QueueName, Message, MessageTTL) – Добавить новое сообщение в конец очереди. MessageTTL определяет строк жизни данного сообщения. Сообщение может храниться в текстовом или двоичном формате, но возвращается base64-кодированным.
• GetMessages (QueueName, NumOfMessages N, VisibilityTimeout T) – Извлечь N сообщений из начала очереди и сделать их невидимыми в течение заданного VisibilityTimeout промежутка времени T. Эта операция возвратит ID сообщения, возвращенного вместе с PopReceipt. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз.
• DeleteMessage (QueueName, MessageID, PopReceipt) – Удалить сообщение, ассоциированное с данным PopReceipt, возвращенным ранее вызовом GetMessage. Обратите внимание, что если сообщение не будет удалено, оно повторно появится в очереди по истечении VisibilityTimeout.
• PeekMessage (QueueName, NumOfMessages N) – Извлечь N сообщений из начала очереди, не делая сообщения невидимыми. Эта операция возвратит ID сообщения для каждого возвращенного сообщения.
• ClearQueue – Удалить все сообщения из заданной очереди. Заметьте, что вызывающая сторона должна повторять эту операцию до тех пор, пока получает сообщения об успешном ее выполнении, это обеспечит удаление всех сообщений очереди.

Операции уровня сообщения могут быть выполнены с использованием следующего URL:

http://<учетнаязапись>.queue.core.windows.net/<ИмяОчереди>/messages

Полное описание API REST можно найти в документе Windows Azure SDK.

Пример

На следующем рисунке представлен пример, иллюстрирующий семантику Windows Azure Queue.

Рис. 7.5. Пример использования очереди

В этом примере поставщики (P1 и P2) и потребители (C1 и C2) обмениваются информацией через представленную выше очередь. Поставщики формируют рабочие элементы и помещают их в виде сообщений в очередь. Потребители изымают сообщения/рабочие элементы из очереди и обрабатывают их. Может существовать множество поставщиков и множество потребителей. Рассмотрим последовательность действий:

1. C1 извлекает сообщение из очереди. Эта операция возвращает сообщение 1 и делает его невидимым в очереди на 30 секунд (принимаем в данном примере, что используется VisibilityTimeout по умолчанию, что составляет 30 секунд).
2. Затем появляется C2 и извлекает из очереди другое сообщение. Поскольку сообщение 1 по-прежнему невидимое, эта операция не увидит сообщения 1 и возвратит C2 сообщение 2.
3. По завершении обработки сообщения 2 C2 вызывает Delete, чтобы удалить сообщение 2 из очереди.
4. Теперь представим, что C1 дает сбой в ходе обработки сообщения 1, таким образом, C1 не удаляет это сообщение из очереди.
5. По истечении времени VisibilityTimeout для сообщения 1, оно опять появляется в очереди.
6. После того, как сообщение 1 повторно появилось в очереди, оно может быть извлечено последующим вызовом от C2. Тогда C2 полностью обработает сообщение 1 и удалит его из очереди.

Как показано в этом примере, семантика API очереди гарантирует каждому сообщению в очереди шанс быть обработанным полностью, по крайней мере, один раз. То есть, если возникает сбой потребителя в период после извлечения им сообщения из очереди и до его удаления, сообщение опять появится в очереди по истечении времени VisibilityTimeout. Это обеспечивает возможность этому сообщению быть обработанным полностью другим потребителем.

Рассмотрим REST-запросы, используемые Windows Azure Queue.

Ниже показан пример REST-запроса для операции постановки в очередь. Заметьте, что используется HTTP-команда PUT. Задается необязательная опция "messagettl", определяющая срок жизни сообщения в секундах. Максимальный срок жизни – 7 дней. Если этот параметр опущен, значение по умолчанию – 7 дней. По истечении срока жизни сообщение будет удалено системой в процессе сборки мусора. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности. В данном случае, Content-MD5 – это контрольная сумма MD5 данных сообщения в запросе. Параметр Content-Length (Длина содержимого) определяет размер содержимого сообщения. Также в заголовке HTTP-запроса имеется заголовок авторизации. Обратите внимание, что данные сообщения располагаются в теле HTTP-запроса. Сообщение может храниться в текстовом или двоичном формате, но при извлечении оно возвращается base64-кодированным.

PUT http://sally.queue.core.windows.net/myqueue/messages

? messagettl=3600

HTTP/1.1 Content-Length: 3900

Content-MD5: HUXZLQLMuI/KZ5KDcJPcOA==

Authorization: SharedKey sally: F5a+dUDvef+PfMb4T8Rc2jHcwfK58KecSZY+l2naIao=

x-ms-date: Mon, 27 Oct 2008 17:00:25 GMT

Message Data Contents ………

Ниже показан пример REST-запроса для операции извлечения из очереди. Заметьте, что используется HTTP-команда GET. Заданы два необязательных параметра. "numofmessages" определяет, сколько сообщений должно быть изъято из очереди; максимальное число – 32. По умолчанию извлекается одно сообщение. В примере ниже будет извлекаться по 2 сообщения. Параметр "visibilitytimeout" определяет время ожидания видимости; сообщение будет оставаться невидимым в очереди, в течение этого промежутка времени, в секундах, и вновь появится в очереди, если не будет удалено до завершения периода ожидания видимости. Максимальное значение этого времени ожидания – 2 часа, и значение по умолчанию – 30 секунд. В примере ниже время ожидания видимости задано равным 60 секундам. Также в заголовке HTTP-запроса имеется элемент авторизации. Обратите внимание, что ответ поступает в XML-формате, и данные сообщения в ответе будут base64-кодированными (в примере ниже располагаются между тегами <MessageText> </MessageText>).

GET http://sally.queue.core.windows.net/myqueue/messages

?numofmessages=2 &visibilitytimeout=60

HTTP/1.1

Authorization: SharedKey sally: QrmowAF72IsFEs0GaNCtRU143JpkflIgRTcOdKZaYxw=

x-ms-date: Thu, 13 Nov 2008 21:37:56 GMT

Ответ на этот вызов будет аналогичен получаемому в следующем примере:

HTTP/1.1 200 OK

Transfer-Encoding: chunked

Content-Type: application/xml

Server: Queue Service Version 1.0 Microsoft-HTTPAPI/2.0

x-ms-request-id: 22fd6f9b-d638-4c30-b686-519af9c3d33d

Date: Thu, 13 Nov 2008 21:37:56 GMT

<?xml version="1.0" encoding="utf-8"?>

<QueueMessagesList>

<QueueMessage>

<MessageId>6012a834-f3cf-410f-bddd-dc29ee36de2a</MessageId>

<InsertionTime>Thu, 13 Nov 2008 21:38:26 GMT</InsertionTime>

<ExpirationTime>Thu, 20 Nov 2008 21:36:40 GMT</ExpirationTime>

<PopReceipt>AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZ

XIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2VG9rZW49bnVsbAUBAAAAVU1p

Y3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVld

WVNYW5hZ2VyK1JYVpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNr

aW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mA

l9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPLSAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</PopReceipt>

<TimeNextVisible>Thu, 13 Nov 2008 21:38:26 GMT</TimeNextVisible>

<MessageText>......</MessageText>

</QueueMessage>

<QueueMessage>

<MessageId>2ab3f8e5-b0f1-4641-be26-83514a4ef0a3</MessageId>

<InsertionTime>Thu, 13 Nov 2008 21:38:26 GMT</InsertionTime>

<ExpirationTime>Thu, 20 Nov 2008 21:36:40 GMT</ExpirationTime>

<PopReceipt>AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFn

ZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2VG9rZW49bnVsbAUBAAAAVU1

pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVl

dWVNYW5hZ2VyK1JYVpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWN

raW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9m

Al9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAuX4syrxsEFGviaDUUpO8KNfNapL7xPLSAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</PopReceipt>

<TimeNextVisible>Thu, 13 Nov 2008 21:38:26 GMT</TimeNextVisible>

<MessageText>.....</MessageText>

</QueueMessage>

</QueueMessagesList>

Ниже представлен пример REST-запроса для операции удаления сообщения. В этом случае используется HTTP-команда DELETE. Параметр "popreceipt" определяет сообщение, которое должно быть удалено. "popreceipt" получается в результате предыдущей операции извлечения из очереди, как показано в примере ранее.

DELETE /sally/myqueue/messages/6012a834-f3cf-410f-bddd-dc29ee36de2a?popreceipt=AAEAAAD%2f%2

f%2f%2f%2fAQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9

uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljSV5VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU

2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyKJlY2V

pcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQDAAtT

eXN0ZW0uR3VpZA0CAAAABP3%2f%2f%2f8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9

pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPSAsAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%3d&timeout=30

HTTP/1.1

Content-Type: binary/octet-stream

x-ms-date: Thu, 13 Nov 2008 21:37:56 GMT

Authorization: SharedKey sally:M/N65zg/5hjEuUS1YGCbVDHfGnI7aCAudkuTHpCDvZY=

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

• В данной лекции мы ознакомились с двумя абстракциями данных Windows Azure: Windows Azure Blob – абстракция данных, которая обеспечивает хранилище больших элементов данных.
• Windows Azure Queue – абстракция данных, которая обеспечивает диспетчеризацию асинхронных заданий.

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

Windows Azure Blob – абстракция данных, которая обеспечивает хранилище больших элементов данных.

Windows Azure Queue – абстракция данных, которая обеспечивает диспетчеризацию асинхронных заданий для реализации обмена данными между сервисами

7. Лекция: Microsoft®.NET Services

Платформа Azure™ Services Platform представляет комплексную стратегию, разработанную Microsoft для облегчения разработчикам задач по реализации возможностей обработки данных в облаке. В ходе данной лекции нам предстоит ознакомиться с технологиями Microsoft.NET Services. Так же в лекции производится обзор NET Services SDK

Содержание

• Краткие итоги:
• Ключевые термины:
• Лабораторная работа 3. Создание первого Windows Azure приложения
• Создание проекта в Visual Studio
• Создание модели данных для элементов в Table Storage
• Создание Веб роли для отображения гостевой книги
• Организация очереди рабочих элементов для обработки в фоне
• Проверка
• Лабораторная работа 4. Развертывание приложения Windows Azure
• Создание Storage Account
• Развертывание приложения на портале Windows Azure Platform
• Лабораторная работа 5. Работа с Blob
• Получение Blob данных из хранилища
• Загрузка Blob данных в хранилище
• Извлечение метаданных для Blob в хранилище
• Удаление Blob из хранилища
• Копирование Blob
• Получение снимков Blob
• Лабораторная работа 6. Работа с Tables
• Настройка Storage Account Settings
• . Создание классов для модели Model the Table Schema
• Создание пользовательского интерфейса Chat
• Проверка:

Цель данной лекции – ознакомиться с технологиями Microsoft.NET Services.

.NET Services предоставляет основные стандартные блоки, которые понадобятся при построении приложений в облаке и работающих с облаком для Azure™ Services Platform.

Сервисы, собранные под именем.NET Services, обеспечивают инфраструктуру облака, которая, в конечном счете, упрощает построение работающих в облаке приложений.

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

• Microsoft®.NET Service Bus: предоставляет сетевую инфраструктуру для соединения приложений через Интернет с использованием разнообразных шаблонов обмена сообщениями способом, обеспечивающим возможность прохождения межсетевых экранов и NAT-устройств без нарушения безопасности, предоставляемой этими устройствами.
• Microsoft®.NET Access Control Service: обеспечивает управление доступом в облаке на основании утверждений. Он включает механизм преобразования утверждений, который объединяется с поставщиками удостоверений, такими как Active Directory и Windows Live ID (WLID). В будущих версиях будет реализована интеграция с любыми поставщиками удостоверений.
• Microsoft®.NET Workflow Services: предоставляет инфраструктуру для размещения и управления рабочими процессами (WF), уделяя основной внимание взаимодействию через сообщения посредством.NET Service Bus. Поставляется с новыми действиями WF и инструментами для размещения и управления экземплярами рабочего процесса.

Данные новые сервисы можно рассматривать как.NET-инфраструктуру сервисов для облака. Все они доступны через открытые протоколы и стандарты, включая REST, SOAP, Atom/AtomPub и WS. Это означает, что разработчики на любой платформе могут интегрироваться с этими сервисами.

Однако, в попытке сделать все максимально привычным для.NET-разработчиков, Microsoft также предоставляет.NET Services SDK, который обеспечивает первоклассные условия для.NET-разработчика и скрывает многие сложные моменты работы с сервисами.

.NET Services SDK позволяет разработчикам использовать имеющийся опыт.NET-разработки, в частности в областях WCF и WF, через применение новых расширений инфраструктуры SDK (например, новых привязок, каналов и действия). SDK также включает поддержку инструментов Visual Studio для интеграции с порталом Azure™ Services Portal. Кроме.NET Services SDK, сегодня партнеры Microsoft предлагают Java и Ruby SDK (ссылки можно найти в разделе " Дополнительные ресурсы ").

Чтобы начать работу с.NET Services, перейдите на портал Azure™ Services Platform по адресу http://azure.com и щелкните ссылку "Try It Now" (Попробуйте сейчас). Вы перейдете на страницу " Register for Azure Services " (Регистрация для сервисов Azure), представленную на рисунке 8.1. На этой странице даются важные ссылки для скачивания различных SDK, доступа к дополнительным ресурсам и перехода на сайт Microsoft Connect, где можно зарегистрироваться для получения кода приглашения.

Рис. 8.1. Портал Azure™ Services Platform

Далее потребуется загрузить.NET Services SDK. Обратите внимание, что имеется несколько SDK: один – специально предназначенный для разработки Windows® Azure™; другой – для разработки.NET Services; и остальные – для SQL Data Services и Live Framework. Для воспроизведения примеров, предлагаемых в данной серии документов, понадобится скачать и установить.NET Services SDK.

Скачав.NET Services SDK, просто запустите программу установки, как показано на рисунке 8.2. Тем самым вам будут доступны новые.NET-сборки, которые вместе с некоторыми надстройками Visual Studio помогут начать использование различных функций.NET Services. Приступая к работе с.NET Services, обязательно ознакомьтесь с остальными ресурсами, доступными с этой страницы (демонстрации, видео, практические лабораторные и т.д.), цель которых – сделать процесс обучения более насыщенным и разнообразным. Скачать SDK можно, не создавая учетной записи, но, чтобы использовать сервисы, необходимо зарегистрироваться.

Рис. 8.2. Запуск установки NET Services SDK

Чтобы зарегистрироваться на получения учетной записи Azure Services, щелкните показанную выше ссылку " Register for Services " (Регистрация для сервисов). Вам будет предложено зарегистрироваться, используя Windows Live ID (WLID). После этого вы перейдете на сайт Microsoft Connect, где потребуется заполнить регистрационную форму Azure Services CTP. После успешной регистрации на Azure Services CTP, на экране появится страница, представленная на рисунке 8.3.

Рис. 8.3. Регистрация для Azure Services Platform на сайте Microsoft Connect

Теперь можно вернуться на страницу входа.NET Services Эту страницу можно увидеть на рисунке 8.4.

Рис. 8.4. Страница входа.NET Services

Теперь, щелкнув " Sign Up " (Войти), вы получаете возможность создавать решение. NET Services. Примечание: в CTP-версии, вышедшей в марте 2009, для создания решения. NET Services больше не требуется код приглашения.

Для создания решения необходимо просто ввести уникальное имя решения, принять условия использования и нажать " Create Solution " (Создать решение). После этого новое решение будет подготовлено и ассоциировано с вашим WLID. Теперь, в любой момент, зарегистрировавшись на портале Azure™ Services Platform, вы имеете возможность управлять решениями, ассоциированными с вашим WLID.

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

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

Рис. 8.5. Завершение процесса подготовки решения

После успешного создания решения можно приступать к работе с ним на портале Azure™ Services Platform. Зарегистрировавшись под собственным WLID, на странице портала справа вы увидите меню " My Solutions " (Мои решения) (рисунок 8.6). Для работы с конкретным решением необходимо просто выбрать его в меню " My Solutions ", после чего вам будет представлена страница, показанная на рисунке 8.7.

По сути, решение – это контейнер верхнего уровня для организации различных ресурсов.NET Services.Например, в нем размещаются конечные точки.NET Service Bus, типы и экземпляры рабочих процессов.NET Workflow Service, а также ваши удостоверения.NET Access Control Service и правила преобразования утверждений. Но одним из самых важных аспектов, которым вы захотите управлять после создания собственного решения, являются учетные данные решения.

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

Рис. 8.6. Управление своими решениями посредством меню "My Solutions"

Рис. 8.7. Управление отдельным решением

Пароль решения, предоставленный в процессе подготовки, можно изменить на странице " Credential Management " (Управление учетными данными) (просто щелкните ссылку " Solution Credentials " (Учетные данные решения), которую можно видеть на рис. 8.8). С этой страницы можно также конфигурировать информационные карточки Windows CardSpace, ассоциированные с данным решением, и также любые сертификаты, которые необходимо ассоциировать с решением (рисунок 8.8)

Рис. 8.8. Управление учетными данными своего решения

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

Самым распространенным требованием в распределенных приложениях с высоким уровнем масштабируемости является возможность подключения приложений. Обычно интеграция приложений – одна из самых дорогостоящих и хлопотных областей ИТ. Сегодня для этих задач многие организации используют решение Enterprise Service Bus. Enterprise Service Bus (сервисная шина предприятия, ESB) — подход к построению распределённых корпоративных информационных систем. Обычно включает в себя промежуточное ПО, которое обеспечивает взаимосвязь между различными приложениями по различным протоколам взаимодействия.

Архитектура ESB заключается в взаимодействии всех приложений через единую точку, которая, при необходимости, обеспечивает транзакции, преобразование данных, сохранность обращений. Данный подход обеспечивает большую гибкость, простоту масштабирования и переноса: при замене одного приложения подключенного к шине нет необходимости перенастраивать остальные.

Одним из стандартов взаимодействия являются веб-сервисы. В популярных реализациях ESB добавляются шлюзы для обмена данными с корпоративным ПО. С использованием ESB может быть реализована сервисно-ориентированная архитектура. Существует некоторое разногласие, что именно считать ESB — архитектуру или программное обеспечение. Обе точки зрения имеют право на существование.

NET Service Bus является основной частью предложения.NET Services. Ее основная задача – сделать шаблон ESB реальностью в Интернете в рамках платформы Azure™ Services Platform. Предоставляемые.NET Service Bus архитектурные характеристики во многом аналогичны предлагаемым типовыми решениями ESB, включая идентификацию и управление доступом, присваивание имен, реестр сервиса и общую среду обмена сообщениями. Основное отличие в области применения. В случае с.NET Service Bus компоненты должны разрабатываться для работы в облаке, в глобальной области Интернета, с обеспечением высокого уровня масштабируемости и интегрируемости. Именно поэтому в прошлом этот предлагаемый сервис назывался Microsoft Internet Service Bus (рисунок 8.9).

Internet Service Bus позволила бы интегрировать ваш локальный ESB-продукт с вашими собственными выполняющимися в облаке сервисами, с различными сторонними сервисами, предоставляемыми Microsoft или другими производителями (такими как предлагаются в рамках платформы Azure™ Service Platform) и с различными настольными, RIA3 и веб-приложениями, которые могут выполняться на вспомогательных площадках вне межсетевого экрана корпорации.

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

1. Сервисная шина предприятия.
2. Эта терминология применялась в документации BizTalk Services, но более не является официальным наименованием, используемым Microsoft.
3. RIA = Rich Internet Application (Насыщенное Интернет-приложение).

Рис. 8.9. Сервисная шина Интернет

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

Часто компании решают эти проблемы связи, открывая входящие порты межсетевых экранов (что доставляет немало хлопот системным администраторам) или используя различных обходные приемы, такие как динамическая DNS, сопоставление портов NAT или технологию UpnP. Все эти методы неустойчивы, трудно управляемы и восприимчивы к угрозам безопасности. Число приложений, для которых требуется такой тип двусторонней связи, постоянно растет..NET Service Bus призвана удовлетворить эту потребность.

Network address translation – Преобразование сетевых адресов.

Domain Name System – Служба доменных имен.

Universal Plug and Play – Универсальная автоматическая настройка сетевых устройств.

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

Microsoft®.NET Access Control Service – это сервис в облаке, выполняющий именно эту функцию. Вместо того чтобы создавать собственную базу данных пользовательских учетных записей и ролей, можно предоставить возможность.NET Access Control Service управлять аутентификацией и авторизацией ваших пользователей..NET Access Control Service использует существующие хранилища учетных записей пользователей, такие как Windows Live ID и Active Directory, а также любые другие хранилища, поддерживающие стандартные протоколы интегрирования. Таким образом, использование единой регистрации для доступа ко всем приложениям становится вполне естественным. Также это обеспечивает централизацию логики аутентификации и управления доступом, что упрощает ваши приложения.

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

Рис. 8.10. Использование идентификации на базе утверждений для веб-сервисов

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

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

• Аутентификация пользователей
• Хранение учетных записей пользователей и паролей
• Обращение к каталогам предприятия в поисках данных удостоверения пользователя
• Интеграция с системами удостоверений других платформ или компаний

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

.NET Access Control Service реализовывает идентификацию на базе утверждений в рамках платформы Azure™ Services Platform. Система администрирования является важной частью.NET Access Control Service.

Рис. 8.11. Портал ACS

.NET Access Control Service предоставляет портал администрирования (рисунок 8.11) в рамках портала Azure™ Services Portal. Здесь вы выполняете настройку правил, которые определяют схему выпуска утверждений для различных пользователей.

Портал Access Control Service – замечательное средство для исследования, изучения и начала работы с ACS. И для относительно простых приложений он может быть единственным необходимым инструментом. Но для нетривиальных систем с сотнями или тысячами пользователей и, возможно, таким же количеством правил, использование портала становится громоздким. В таких случаях программный интерфейс – более предпочтительный вариант, поэтому ACS также предоставляет интерфейс AtomPub для программного администрирования. AtomPub – это протокол RESTful, который стандартизует базовые операции CRUD (Create, Retrieve, Update и Delete) для управления удаленными ресурсами. Это открывает совершенно новые возможности.

Сервис.NET Access Control Service также включает конечные точки SOAP и REST для программного администрирования, а также ряд.NET-классов, которые упрощают вызов этих конечных точек. Итак, если вам не нравится портал, предоставляемый ACS, или вы желаете реализовать настройки, характерные для определенной предметной области, можно создать собственную консоль администрирования.

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

.NET Workflow Service является частью Azure™ Services Platform и интегрируется с сервисами.NET Service Bus и.NET Access Control Service для безопасного координирования взаимодействия посредством сообщений..NET Workflow Service также обеспечивает инструменты управления для создания и управления типами и экземплярами рабочих потоков и API веб-сервисов для ситуаций, когда требуется создать собственные инструменты.

Поскольку управляющая среда построена на платформе Windows® Azure™, она может масштабироваться по требованию и в значительной степени, при этом организации или разработчику не приходится беспокоиться о планировании большего количества оборудования или программного обеспечения. Благодаря использованию среды выполнения WF экземпляры рабочего потока могут выполняться в пуле серверов и перемещаться с одного сервера на другой в каждом эпизоде выполнения. Управляющая среда включает сервис хранения, который использует безопасные тиражированные сервисы Microsoft SQL Service для сохранения состояния выполняющихся рабочих процессов и для обеспечения возможности восстановления.

На период перехода к обработке данных в облаке.NET Workflow Services предоставляет упрощенный подход для управления сложными взаимодействиями.NET Service Bus в создаваемых вами составных решениях "в облаке".

Построение хоста для рабочих процессов WF означает принятие решений о том, какие возможности будет поддерживать среда и как лучше сделать ее безопасной, масштабируемой и стабильной. Сегодня.NET Workflow Service построен на.NET Framework 3.5 и действиях и компонентах WF, входящих в данную версию инфраструктуры. Однако для обеспечения наилучших условий Microsoft были добавлены несколько специальных действий и сервисов, которые наложили некоторые ограничения на рабочие процессы, выполняющиеся в облаке.

В облаке не используется сервис хранения SqlWorkflowPersistenceProvider, получивший наибольшую популярность среди разработчиков, применяющих WF. Чтобы использовать операционную среду Azure и обеспечить наилучшие возможности масштабирования и стабильности, в инфраструктуре облака имеется специальный провайдер услуг хранения, который реализует сохранение состояния выполняющихся рабочих процессов посредством возможностей хранения Microsoft SQL Services. Кроме всего прочего, для Интернет-сервиса необходима Интернет-технология хранения и извлечения данных. Но поскольку механизм WF един – как в облаке, так и в ваших локальных решениях, – применение специального провайдера услуг хранения прозрачно для разработчиков рабочих процессов. Все делается так же, как в любой другое среде WF.

При построении рабочих процессов для облака разработчики используют привычные инструменты Visual Studio, включая тот же дизайнер рабочего процесса для создания XAML-файлов рабочих процессов и файлов правил. Затем эти XML-файлы загружаются на сервер в облаке, где они могут использоваться для создания экземпляров рабочего процесса..NET Services SDK включает шаблон проекта для создания SequentialCloudWorkflow (Последовательный рабочий процесс в облаке), который является специальной версией стандартного шаблона SequentialWorkflow (Последовательный рабочий процесс). Одним из ограничений текущей инфраструктуры является то, что при определении рабочих процессов, которые будут выполняться в облаке, можно использовать только подмножество действий базовой библиотеки действий, а также комплект специальных действий, предоставляемый как часть.NET Services SDK.

Набор действий требует, чтобы рабочие процессы были полностью декларативными и ограничивающими. Это предотвращает введение пользовательского кода, т.е. позволяет гарантировать стабильность среды. При построении управляющей среды для рабочих процессов, написанных любым количеством разработчиков, разбросанных по всему миру, такой уровень контроля является обязательным. Поскольку сегодня для выполнения WF необходимо полное доверие, мы не можем обеспечить ограниченный набор функциональности, просто выделив пользовательский код в безопасную изолированную программную среду на серверах. Следует отметить, что со временем доступный сегодня ограниченный набор действий будет расширен для увеличения возможностей рабочего процесса в облаке. По мере выхода новых версий.NET Framework и.NET Workflow Service также будет поддерживать их. Кроме того, если понадобятся специальные этапы, возможности локальных рабочих процессов могут комбинироваться с рабочими процессами в облаке с помощью.NET Service Bus.

.NET Services SDK содержит новый шаблон проекта для построения рабочих процессов в облаке, набором новых действий в облаке и клиентским API для удаленного развертывания и управления рабочими процессами, размещаемыми в облаке.

При написании рабочих процессов в облаке необходимо быть аккуратным с используемыми действиями (дизайнер предложит только допустимые действия). Разрешенными являются некоторые основные действия потока управления WF, включая IfElse (Если…то), While (Пока), Sequence (Последовательность), Suspend (Приостановить), Terminate (Завершить) и FaultHandler (Обработчик сбоев). Кроме базовых действий потока управления, в рабочих процесса в облаке могут также использоваться CancellationHandlerActivity и FaultHandlersActivity для моделирования обработки исключений и логики отмены. Обратите внимание, что эти действия обычно не добавляются в модель напрямую; для этого используется дизайнер составных действий, который вводит их автоматически, когда представление переходит к этому действию.

Ни одно другое действие WF или пользовательские действия не могут использоваться. Разрешены к применению только новые специальные действия в облаке, включенные в.NET Services SDK. Ниже описаны новые специальные действия в облаке, которые поставляются с.NET Services SDK.

Поскольку основной задачей.NET Workflow Service является упрощение взаимодействия сообщений, эти действия, главным образом, касаются отправки, получения и обработки сообщений. Отправлять/принимать сообщения можно посредством традиционных HTTP-запросов или через.NET Service Bus. Эти действия можно будет найти на панели инструментов Visual Studio при использовании шаблона проекта последовательного рабочего процесса в облаке.

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

Платформа Azure™ Services Platform представляет комплексную стратегию, разработанную Microsoft для облегчения разработчикам задач по реализации возможностей обработки данных в облаке. Microsoft®.NET Services – ключевая составляющая этой платформы, созданная специально, чтобы помочь.NET-разработчикам сделать первый шаг..NET Services предлагает ориентированные на работу в облаке стандартные блоки и инфраструктуру для обеспечения возможности подключения приложений, управления доступом, размещения и управления рабочим процессом. Эти стандартные блоки станут основными средствами организации работы "с облаком" для.NET-разработчиков на годы вперед. Больше информации о.NET Service Bus,.NET Access Control Service и.NET Workflow Service можно найти в документах данной серии, посвященных каждой из этих тем в отдельности.

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

Microsoft®.NET Service Bus – блок сервисов, который предоставляет сетевую инфраструктуру для соединения приложений через Интернет с использованием разнообразных шаблонов обмена сообщениями способом, обеспечивающим возможность прохождения межсетевых экранов и NAT-устройств без нарушения безопасности, предоставляемой этими устройствами.

Microsoft®.NET Access Control Service – блок сервисов, который обеспечивает управление доступом в облаке на основании утверждений. Он включает механизм преобразования утверждений, который объединяется с поставщиками удостоверений, такими как Active Directory и Windows Live ID (WLID). В будущих версиях будет реализована интеграция с любыми поставщиками удостоверений.

Microsoft®.NET Workflow Services – блок сервисов, который предоставляет инфраструктуру для размещения и управления рабочими процессами WF, уделяя основной внимание взаимодействию через сообщения посредством