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

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. Это обеспечивает возможность этому сообщению быть обработанным полностью другим потребителем.

105

Рассмотрим 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>

106

<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/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZ

S5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwg

UHVibGljS2VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1

ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JYVpcHQCAAAA

FjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQ

DAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl

9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPL SAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA=</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/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZ

S5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwg

UHVibGljS2VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1

ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JYVpcHQCAAAA

FjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQ

DAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl

9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAuX4syrxsEFGviaDUUpO8KNfNapL7xPL SAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</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%2f%2f%2f%2fAQAAAAAAAAAMAgAAAFxOZXBob3Mu UXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1c mU9bmV1dHJhbCwgUHVibGljSV5VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2Vyd mljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5 hZ2VyKJlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX 19CYWNraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3%2f%2f%2f8LU3lzdGVtLkd1aWQL AAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoE mDP8w9Bvd3cKe423ipfNapL7xPSAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

107

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%3d&timeou t=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 Blob – абстракция данных, которая обеспечивает хранилище больших элементов данных.

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

Литература:

1.ВикторШатохин www.way2cloud.com

2.http://microsoft.com/faculty

108

Лекция 8. 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, где можно зарегистрироваться для получения кода приглашения.

109

Рисунок 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

110

Чтобы зарегистрироваться на получения учетной записи 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.

111

Рисунок 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.

112

Рисунок 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»

113