Введение в облачные решения Microsoft

Как видно, данные успешно добавлены.

Но нас интересует отображение списка контактов в рамках нашего приложения.

Для этого добавим на веб - форму элемент управления GridView с ID = contactGV , который мы будем использовать для отображения текущих данных таблицы.

Рис. 17.6.

asp - код для GridView:

<asp:GridView ID="contactGV" runat="server" CellPadding="4" ForeColor="#333333"

GridLines="None" onrowdeleting="contactGV_RowDeleting"

onselectedindexchanged="contactGV_SelectedIndexChanged">

<AlternatingRowStyle BackColor="White" />

<Columns>

<asp:CommandField ButtonType="Button" SelectText="Изменить"

ShowSelectButton="True" />

<asp:CommandField ButtonType="Button" ShowDeleteButton="True" />

</Columns>

<EditRowStyle BackColor="#2461BF" />

<FooterStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<HeaderStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<PagerStyle BackColor="#2461BF" ForeColor="White" HorizontalAlign="Center" />

<RowStyle BackColor="#EFF3FB" />

<SelectedRowStyle BackColor="#D1DDF1" Font-Bold="True" ForeColor="#333333" />

<SortedAscendingCellStyle BackColor="#F5F7FB" />

<SortedAscendingHeaderStyle BackColor="#6D95E1" />

<SortedDescendingCellStyle BackColor="#E9EBEF" />

<SortedDescendingHeaderStyle BackColor="#4870BE" />

</asp:GridView>

Определим переменные учетной записи и контекста, до метода Page_Load:

private CloudStorageAccount account = null;

private ContactContext context = null;

В метод Page_Load нашей страницы добавим следующий код, для привязки GridView к источнику данных:

account= CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

context = new ContactContext(account.TableEndpoint, account.Credentials);

contactGV.DataSource = context.ContactData;

contactGV.DataBind();

Листинг 17.2.

Также в методе btn_add_Click добавим следующую строку:

contactGV.DataBind();

Запустив приложение, получим следующее:

Рис. 17.7.

Как видно, при загрузке страницы мы сразу получаем и текущий список контактов. Если добавить новый контакт, то (см. 5.2) списокдополнится еще одной записью.

Рис. 17.8.

Редактирование и удаление сущностей

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

Поскольку нашей целью является демонстрация работы с Windows Azure Table, мы пойдем по самому простому пути.

Для начала добавим на форму кнопку btn_change, невидимую при загрузке страницы.

Данные между методами формы будем передавать при помощи сессий.

Первая и главная задача сводится к тому, чтобы определить ключи строки и секции редактируемой сущности. Учитывая, что структура таблицы и названия параметров могут быть произвольны, за одним исключением - как раз параметров Partition Key и Row Key , добавим в метод Page_Load следующее:

int i = 0;

foreach (TableCell cell in contactGV.HeaderRow.Cells)

{

if (cell.Text == "PartitionKey") { Session["pkindex"] = i; }

if (cell.Text == "RowKey") { Session["rkindex"] = i; }

i++;

}

Теперь, вне зависимости от структуры таблицы, сессии pkindex и rkindex будут содержать номера столбцов contactGV , в которых находятся параметры ключей секции и строки.

Полностью метод Page_Load для данного задания должен быть следующим:

protected void Page_Load(object sender, EventArgs e)

{

btn_change.Visible = false;

account = CloudStorageAccount.FromConfigurationSetting ("DataConnectionString");

context = new ContactContext(account.TableEndpoint, account.Credentials);

contactGV.DataSource = context.ContactData;

contactGV.DataBind();

int i = 0;

foreach (TableCell cell in contactGV.HeaderRow.Cells)

{

if (cell.Text == "PartitionKey") { Session["pkindex"] = i; }

if (cell.Text == "RowKey") { Session["rkindex"] = i; }

i++;

}

}

Также добавим в класс ContactContext методы для обновления и удаления сущностей - Update и Delete соответственно:

public void Delete(Contact cnt)

{

this.DeleteObject(cnt);

this.SaveChanges();

}

public void Update(Contact cnt)

{

this.UpdateObject(cnt);

this.SaveChanges();

}

Удаление строки

Добавим метод, обрабатывающий нажатие кнопки "Удалить" элемента contactGV.

protected void contactGV_RowDeleting(object sender, GridViewDeleteEventArgs e)

{

GridView g = (GridView)sender;

try

{

Contact c = (from contact in context.CreateQuery<Contact>("Contacts")

where contact.PartitionKey == g.Rows[e.RowIndex].

Cells[Convert.ToInt32(Session["pkindex"].ToString())].Text

&& contact.RowKey == g.Rows[e.RowIndex].Cells[Convert.ToInt32

(Session["rkindex"].ToString())].Text

select contact).FirstOrDefault();

context.Delete(c);

}

catch(DataServiceRequestException ex)

{

lb_status.Text = ex.Message;

}

g.DataBind();

}

Обратим ваше внимание на то, что сущность для удаления мы получаем при помощи linq - запроса, указывая значения параметровPartitionKey и RowKey . Значения же параметров мы получаем из contactGV , указывая значения соответствующих ячеек.

Реализация удаления сущности на этом закончена.

Редактирование сущности

Для начала напишем обработчик события изменения индекса выбранной строки contactGV , инициируемое нажатием кнопки"Изменить" . При нажатии этой кнопки должен становиться видимым элемент управления btn_change, а соответствующие текстовые поля заполняться значениями параметров редактируемой строки.

protected void contactGV_SelectedIndexChanged(object sender, EventArgs e)

{

GridView g = (GridView)sender;

int index = g.SelectedIndex;

Contact c = (from contact in context.CreateQuery<Contact>("Contacts")

where contact.PartitionKey == g.Rows[index].

Cells[Convert.ToInt32(Session["pkindex"].ToString())].Text

&& contact.RowKey == g.Rows[index].

Cells[Convert.ToInt32(Session["rkindex"].ToString())].Text

select contact).FirstOrDefault();

tb_firstname.Text = c.FirstName;

tb_lastname.Text = c.LastName;

tb_email.Text = c.Email;

tb_telnum.Text = c.TelNumber;

Session["index"] = index;

btn_change.Visible = true;

}

Здесь стоит обратить внимание разве что на формирование еще одной сессии, в которой мы будем хранить номер редактируемой строки в contactGV.

Вот, что должно получиться при нажатии кнопки "Изменить" напротив второй строки списка контактов:

Рис. 17.9.

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

Осталось только написать метод обрабатывающий событие нажатия кнопки btn_change.

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

protected void btn_change_Click(object sender, EventArgs e)

{

int index = Convert.ToInt32(Session["index"].ToString());

try

{

Contact c = (from contact in context.CreateQuery<Contact>("Contacts")

where contact.PartitionKey == contactGV.Rows[index].

Cells[Convert.ToInt32(Session["pkindex"].ToString())].Text

&& contact.RowKey == contactGV.Rows[index].

Cells[Convert.ToInt32(Session["rkindex"].ToString())].Text

select contact).FirstOrDefault();

c.FirstName = tb_firstname.Text;

c.LastName = tb_lastname.Text;

c.Email = tb_email.Text;

c.TelNumber = tb_telnum.Text;

context.Update(c);

}

catch (DataServiceRequestException a)

{

lb_status.Text = a.Message;

}

contactGV.DataBind();

}

Номер изменяемой строки мы получаем из сессии "index" , остальное уже не должно вызывать вопросов.

Запустите приложение еще раз и измените произвольным образом любой из параметров, либо насколько из них какой - либо строки. Мы изменили Email на tableentitychange@mail.test . Нажмите кнопку "Change".

Мы получили следующее:



Рис. 17.10.

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

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

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="AzureTable.aspx.cs" Inherits="WebRole1.AzureTable" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title></title>

<style type="text/css">

.style1

{

}

.style2

{

width: 149px;

}

</style>

</head>

<body>

<form id="form1" runat="server">

<div>

<asp:Label ID="NameOfExample" runat="server" Font-Bold="True"

Font-Italic="False" Font-Size="Larger" Font-Strikeout="False"

Font-Underline="False" Text="My Contact List - Windows Azure Table Example"></asp:Label>

<br />

<br />

<asp:Label ID="ContactLabel" runat="server" Text="Contact:"></asp:Label>

<br />

<table style="width:100%;">

<tr>

<td class="style2">

</td>

<td>

</td>

</tr>

<tr>

<td class="style2">

<asp:Label ID="lb_firstname" runat="server" Text="First Name"></asp:Label>

</td>

<td>

<asp:TextBox ID="tb_firstname" runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td class="style2">

<asp:Label ID="lb_lastname" runat="server" Text="Last Name"></asp:Label>

</td>

<td>

<asp:TextBox ID="tb_lastname" runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td class="style2">

<asp:Label ID="lb_telnum" runat="server" Text="Telephone Number"></asp:Label>

</td>

<td>

<asp:TextBox ID="tb_telnum" runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td class="style2">

<asp:Label ID="lb_email" runat="server" Text="E-mail"></asp:Label>

</td>

<td>

<asp:TextBox ID="tb_email" runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td class="style2">

</td>

<td>

</td>

</tr>

<tr>

<td class="style2">

<asp:Button ID="btn_change" runat="server" onclick="btn_change_Click"

Text="Change" Width="105px" />

</td>

<td>

<asp:Button ID="btn_add" runat="server" Height="20px" onclick="btn_add_Click"

Text="Add Contact" />

</td>

</tr>

<tr>

<td class="style2">

<asp:Label ID="lb_status" runat="server"></asp:Label>

</td>

<td>

</td>

</tr>

<tr>

<td class="style2">

</td>

<td>

</td>

</tr>

<tr>

<td class="style1" colspan="2">

<asp:GridView ID="contactGV" runat="server" CellPadding="4" ForeColor="#333333"

GridLines="None" onrowdeleting="contactGV_RowDeleting"

onselectedindexchanged="contactGV_SelectedIndexChanged">

<AlternatingRowStyle BackColor="White" />

<Columns>

<asp:CommandField ButtonType="Button" SelectText="Изменить"

ShowSelectButton="True" />

<asp:CommandField ButtonType="Button" ShowDeleteButton="True" />

</Columns>

<EditRowStyle BackColor="#2461BF" />

<FooterStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<HeaderStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<PagerStyle BackColor="#2461BF" ForeColor="White" HorizontalAlign="Center" />

<RowStyle BackColor="#EFF3FB" />

<SelectedRowStyle BackColor="#D1DDF1" Font-Bold="True" ForeColor="#333333" />

<SortedAscendingCellStyle BackColor="#F5F7FB" />

<SortedAscendingHeaderStyle BackColor="#6D95E1" />

<SortedDescendingCellStyle BackColor="#E9EBEF" />

<SortedDescendingHeaderStyle BackColor="#4870BE" />

</asp:GridView></td>

</tr>

</table>

</div>

</form>

</body>

</html>

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

namespace WebRole1

{

class Contact : Microsoft.WindowsAzure.StorageClient.TableServiceEntity

{

public String FirstName { get; set; }

public String LastName { get; set; }

public String TelNumber { get; set; }

public String Email { get; set; }

}

}

Приложение В. Класс ContactContext.cs

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.WindowsAzure;

using Microsoft.WindowsAzure.StorageClient;

using System.Data.Services.Client;

namespace WebRole1

{

class ContactContext : TableServiceContext

{

public IQueryable<Contact> ContactData

{

get

{

return this.CreateQuery<Contact>("Contacts");

public ContactContext(Uri baseAddress, StorageCredentials credentials) : base(baseAddress.AbsoluteUri, credentials) { }

public void Add(Contact cnt)

{

this.AddObject("Contacts", cnt);

this.SaveChanges();

}

public void Delete(Contact cnt)

{

this.DeleteObject(cnt);

this.SaveChanges();

}

public void Update(Contact cnt)

{

this.UpdateObject(cnt);

this.SaveChanges();

}

}

}

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.Web.Security;

using System.Web.SessionState;

using Microsoft.WindowsAzure;

using Microsoft.WindowsAzure.StorageClient;

using System.Data.Services.Client;

using Microsoft.WindowsAzure.ServiceRuntime;

namespace WebRole1

{

public class Global : System.Web.HttpApplication

{

void Application_Start(object sender, EventArgs e)

{

CloudStorageAccount.SetConfigurationSettingPublisher(

(configName, configSettingPublisher) =>

{

var connectionString =

RoleEnvironment.GetConfigurationSettingValue(configName);

configSettingPublisher(connectionString);

}

);

var account = CloudStorageAccount.FromConfigurationSetting ("DataConnectionString");

CloudTableClient _tc = null;

_tc = account.CreateCloudTableClient();

_tc.CreateTableIfNotExist("Contacts");

}

void Application_End(object sender, EventArgs e)

void Application_Error(object sender, EventArgs e)

void Session_Start(object sender, EventArgs e)

void Session_End(object sender, EventArgs e)

14. Windows Azure Blob: введение, модель данных, REST - интерфейс

Общие сведения

Аббревиатура BLOB расшифровывается как Binary Large Object, т.е. большой бинарный объект - массив двоичных данных. В СУБД BLOB -специальный тип данных, предназначенный, в первую очередь, для хранения медиа- информации и компилированного программного кода.

Blob - хранилище в Azure может быть представлено в виде специального табличного хранилища в "облаке". Windows Azure Blobрасширяет табличное хранилище и рассчитано на хранение больших объемов информации. Разница между Table и Blob хранилищами заключается в следующем:

Табличное хранилище для управления таблицами использует ключи секций и строк. Бинарное хранилище для управления использует контейнер хранения ( storage container ) и идентификатор ( blob ID ).

Табличное хранилище может работать со всеми основными форматами данных, как то символы, строки, целые и действительные числа, XML и т.д. Бинарное хранилище рассчитано только на, очевидно из названия, бинарный тип данных, при этом данных хранятся в виде блоков (data chunks).

Доступ к Blob - хранилищу осуществляется через пользовательскую учетную запись. Одна учетная запись может создать несколькоBlob - контейнеров. В свою очередь, Blob - контейнер может включать в себя несколько Blob - объектов. (см. рис 18.1).

Рассмотрим модель данных Windows Azure Blob более детально. Выделим основные термины:

Учетная запись. Любой доступ к Windows Azure Storage и его сервисам, осуществляется посредством учетной записи. Как уже отмечалось, одна учетная запись может иметь несколько Blob - контейнеров.

Рис. 18.1.



Модель данных

Blob - контейнер. Контейнер группирует Blob - объекты. При этом политики использования данных задаются на уровне контейнера.

Blob (blob - объект). Хранится в контейнере. Каждый объект может быть размером до 50 Гб и имеет уникальное строковое имя в рамках контейнера. С бинарными объектами могут быть ассоциированы метаданные (рис 18.1), задающиеся в виде пары "имя - значение" размером до 8Кб.

На рис 18.2 приведена структура данных Windows Azure Blob, полученная средствами MS SQL Server 2008. Отметим ряд особенностей работы с бинарными объектами и контейнерами:

контейнеры хранятся распределено;

область действия одного контейнера ограничена учетной записью пользователя;

при удалении контейнера, возможно возникновение задержек при повторном его создании, особенно при наличии большого количества объектов, т.е. до тех пор пока система не очистит blob - объекты попытки создать контейнер с тем же именем, что и удаляемый, будут вызывать ошибку;

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



Рис. 18.2.

REST - интерфейс Blob - объектов

Любой доступ к Windows Azure Blob осуществляется через стандартные HTTP - команды PUT, Get и DELETE интерфейса REST.

Приведем перечень поддерживаемых HTTP/REST команд операций с Blob - объектами и контейнерами:

Более полный перечень команд можно найти по ссылке в списке материалов для самостоятельного изучения.

Windows Azure Blob, как список блоков. Примеры REST - запросов

Блоки и страницы

Кроме уже рассмотренных нами основ blob - объектов и хранилищ, необходимо так же пояснить термины "блок" и "страница".

"Блок" и "страница" - способы организации хранения бинарных объектов.

Blob -блок

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

Блоки оптимизированы для потоковой передачи информации. Запись блоков осуществляется в два этапа: сначала загружаются отдельные блоки информации, являющиеся частью одного бинарного объекта, затем необходимо подтвердить добавление блоков. В течении процесса подтверждения можно добавлять, удалять и изменять блоки бинарного объекта. При создании блока нет необходимости задавать его размер, блоки просто добавляются бинарному объекту. Также необязательно создавать блоки в строго определенной последовательности, упорядочить и редактировать блоки можно позднее.

Структура и атрибуты блока указаны на рис. 19.1 (среда MS SQL Server 2008)

Рис. 19.1.

Подытоживая вышесказанное. Блок бинарных объектов состоит из частей (блоки блока), каждый из которых идентифицируется по идентификатору (ID). Создать или изменить blob-блок можно после загрузки его частей. Максимальный размер каждой части блока 4Мб, сам блок бинарного объекта ограничен размером в 200Гб, или до 50000 частей.

Blob - страница

Как blob-блоки состоят из блоков, так и blob-страницы представляют собой коллекцию страниц.

При создании страницы необходимо указать ее предельный размер. Добавление или обновление blob-страницы осуществляется при помощи Put Page операции.

Чтение и запись данных в страницу можно начать с любого произвольного набора данных.

Blob - страница ограничена размером 1Тб.

Структура и атрибуты страницы указаны на рис. 19.2 (среда MS SQL Server 2008)

Рис. 19.2.

Windows Azure Blob, как набор блоков

При загрузке blob - объекта размером в десятки гигабайт реализовывается следующий сценарий (рис. 19.3):

загружаемый объект разбивается на блоки, максимальный размер которых 4Мб;

каждому блоку присваивается уникальный идентификатор в пределах бинарного объекта;

блоки загружаются в "облако";

после загрузки всех составных блоков бинарного объекта, определяются список блоков, которые должны использоваться blob - объекте.



Рис. 19.3.

Доступ к blob - объектам, осуществляется при помощи операций PUT и GET.

Таким образом, Blob-блок может быть создан:

при размере меньше 64Мб, он может быть загружен при помощи Put Blob операции;

при размере более 64Мб, blob разбивается на части размером 4Мб или меньше, которые после загрузки собираются в определенном порядке.

Примеры REST запросов

Приведем примеры запросов для размещения блока PUT Block и чтения blob - объекта Get Blob. Примеры других REST-запросов можно найти по ссылкам в списке материалов для самостоятельного изучения.

В данных примерах имя учетной записи обозначено как <account>, работа производится с объектом "BVideo.mp4" в контейнере "video".

Также отметим, что для всех решений Windows Azure Storage введен новый HTTP-заголовок "x-ms-version". Все изменения в APIхранилища регистрируются как версии с помощью этого заголовка.

Заголовок x-ms-version должен быть задан для всех запросов к Windows Azure Storage.

PUT Block

Ниже представлен пример REST-запроса для размещения блока размером 4МБ посредством операции PUT block. Параметр запроса "?comp=block" указывает на то, что это операция PUT block. Затем задается BlockID. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности. В данном случае, Content-MD5 - это контрольная сумма MD5 данных блока в запросе. Контрольная сумма проверяется на сервере, в случае несовпадения возвращается ошибка. Параметр Content-Length(Длина содержимого) определяет размер содержимого блока. Также в заголовке HTTP-запроса имеется заголовок авторизации, как показано ниже.

PUT <ref src="http://<account>.blob.core.windows.net/video/

BVideo.mp4?comp=block &blockid=BlockId1 &timeout=60 HTTP/1.1

Content-Length: 4194304Content-MD5" type="url">:

HUXZLQLMuI/KZ5KDcJPcOA==Authorization: SharedKey <account>:

<key>= x-ms-date: Mon, 6 Apr 2009 17:00:25 GMTx-ms-version: 2009-04-14

<block data>

GET Blob

Нижеследующий запрос обеспечит извлечение всего содержимого заданного blob. Если для контейнера, которому принадлежит blob (в данном примере "video"), задана политика совместного использования "Private", для получения blob необходимо пройти аутентификацию. Если задана политика совместного использования "Public-Read", аутентификация не требуется, и заголовок аутентификации в заголовке запроса не нужен.

GET <ref src="http://<account>.blob.core.windows.net/video/

BVideo.mp4HTTP/1.1Authorization" type="url"/>: SharedKey

<account>:<key>х-ms-date: Mon, 6 Apr 2009 17:00:25

GMTx-ms-version: 2009-04-14

Интерфейс перечисления объектов blob - контейнера

Windows Azure Blob поддерживает перечисление объектов контейнера бинарных объектов. Интерфейс ListBlobs поддерживает параметры префикса ( prefix ) и разделителя( delimeter ), что делает возможным формирование иерархического перечня объектов. К примеру, имеется Blob-контейнер "Photos" бинарных объектов с именами:

Work|MyFirstDay.jpeg

Work|Boss.jpeg

Work|NewProjectStart.jpeg

Friends|Party_May.jpeg

Friends|NewYear2011.jpeg

Friends|WeekendApril.jpeg

При этом "|" используется как разделитель, для обозначения тематики фотографий, т.е. для создания иерархии имен. Запрос на получение всех имен "каталогов" будет выглядеть следующим образом:

GET <ref src="http://<account>.blob.windows.net/Photos

?comp=list&delimeter=|" type="url"/>

Ответ на запрос:

<BlobPrefix>Work</BlobPrefix>

<BlobPrefix>Friends</BlobPrefix>

Тег < BlobPrefix > указывает на то, что выведенное значение является префиксом имени бинарного объекта, а не именем целиком. Повторяющиеся префиксы возвращаются только один раз. Список бинарных объектов, содержащихся в одном "каталоге", можно получить сочетанием параметров "prefix" и "delimiter", следующим запросом:

GET http://<account>.blob.windows.net/Photos?comp=list

&prefix=Work/&delimeter=|

Ответ на запрос:

<Blob> Work|MyFirstDay.jpeg</Blob>

<Blob> Work|Boss.jheg </Blob>

<Blob> Work|NewProjectStart.jpeg </Blob>

Тег < Blob > указывает на то, что возвращенное имя является полным именем бинарного объекта.

Также интерфейс ListBlobs поддерживает возможность возвращения определенного количества записей, при помощи параметра"maxresult".

Возвращаясь к нашему примеру, следующий запрос вернет первую набор данных, при установленном параметре maxresult=2:

GET <ref src="http://<account>.blob.windows.net/Photos

?comp=list&prefix=Work&maxresult=2" type="url"/>

Ответ на запрос:

<Blob> Work|MyFirstDay.jpeg</Blob>

<Blob> Work|Boss.jheg </Blob>

<NextMarker> Marker1 </NextMarker>

В теге <NextMarker> возвращается непрозрачный маркер, который может быть использован для возвращения следующих результатов:

GET <ref src="http://<account>.blob.windows.net/Photos

?comp=list&prefix=Work&maxresult=2&marker= "

type="url"/>

Marker1

Ответ на запрос:

<Blob> Work|NewProjectStart.jpeg </Blob>

<NextMarker> </NextMarker>

Если тег <NextMarker> пуст, то получены все результаты.

Список материалов для самостоятельного изучения

Блоки и списки

http://msdn.microsoft.com/en-us/library/ee691964.aspx

Windows Azure Blob. Операции с Blob - объектами.

http://msdn.microsoft.com/en-us/library/dd573356.aspx

http://msdn.microsoft.com/ru-ru/library/ee872420.aspx

http://docwiki.embarcadero.com/RADStudio/en/Windows_Azure_Blob_API

Самостоятельная работа 6:

Работа с Windows Azure Blob

В качестве примера рассмотрим работу простого веб - приложения для загрузки изображений в хранилище Windows Azure Blob:

подготовка приложения;

загрузка и отображение изображений;

удаление сущностей;

копирование сущностей.

В свойствах веб - роли определим строку подключения к эмулятору хранилища Azure.

Рис. 20.1.

Также нам понадобится строковый параметр ContainerName, определяющий имя Blob - контейнера для изображений.

Рис. 20.2.

15. Windows Azure Queue. Введение. Модель данных. REST - интерфейс

Общее представлениe

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

Сервисно - ориентированное приложение, построенное с использованием Azure Queue будет обладать рядом преимуществ:

Возможность оценки масштабируемости на основе анализа длины очереди. Длина очереди отражает, по сути, время задержки обработки. Если размер очереди мал, это означает что арендуется больше ресурсов, чем, возможно, необходимо в данном случае. Напротив, большой размер очереди свидетельствует о явной нехватке вычислительных ресурсов и наличии издержек, связанных с задержками в обработке данных.

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

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

На рис 21.1 приведена структура данных Windows Azure Queue, полученная средствами MS SQL Server 2008.

Рис. 21.1.



Рассмотрим модель данных Windows Azure Queue более детально. Выделим основные термины:

Учетная запись. Любой доступ к Windows Azure Storage и его сервисам, осуществляется посредством учетной записи. При этом одна учетная запись может иметь несколько очередей.

Очередь. Очередь содержит множество сообщений, при этом:

количество сообщений не ограничено

сообщение хранится не дольше одной недели и удаляется по истечении этого срока в процессе "сборка мусора"

с очередями могут быть ассоциированы метаданные вида " имя - значение" размером до 8Кб

Сообщения. Хранятся в очередях. Размер каждого сообщения ограничен 8Кб. При необходимости хранения большего объема данных, сами данные размещаются в табличных или бинарных хранилищах, а сообщение хранит имя бинарного объекта, или сущности.

Рис. 21.2. Архитектура Queue сервиса Windows Azure

Параметры AzureQueue Services:

MessageID - идентификатор сообщения в очереди

VisibilityTimeout - значение времени ожидания видимости сообщения, т.е. через какой промежуток времени созданное сообщение " увидят". До 2 часов, значение по умолчанию - 30 секунд

PopReceipt -возвращаемая строка для каждого сообщения, наряду с MessageID необходима для удаления строки из очереди

MessageTTL - срок жизни сообщения в сеундах.

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

К операциям HTTP\REST на уровне очередей и сообщений относятся:

Операции с очередями осуществляются при помощи следующего URL: http://<account>. queue .core.windows.net/<QueueName>

Операции с сообщениями осуществляются при помощи следующего URL: http://<account>. queue.core.windows.net/<QueueName>/messages

где <account> - имя учетной записи, а <QueueName> - имя очереди.

16. Windows Azure Queue: примеры использования, REST - запросы

Примеры использования

Рассмотрим условный пример, демонстрирующий логику использования Azure Queue в приложении (рис. 22.1):

Рис. 22.1.



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

Клиент 1 забирает из очереди сообщение. Ему возвращается Сообщение 1, при этом оно становится невидимым в очереди на величину времени равную значению VisibilityTimeout.

Клиент 2 забирает сообщение из очереди, при этом Сообщение 1 все еще невидимо. Таким образов Клиенту вернется Сообщение 2.

По завершении обработки сообщения Клиент 2 удаляет его из очередь.

Отметим, что в случае, если Клиент 2 удалит Сообщение 2, а Клиент 1 не сможет удалить Сообщение 1, то последующие запросы сообщений из очереди вернут Сообщение 1. Таким образом, любое сообщение в очереди будет гарантировано обработано хотя бы единожды.

Примеры REST - запросов

Рассмотрим некоторые примеры использования REST - запросов Windows Azure Queue. Учетная запись пользователя будет обозначена, как <account>, имя очереди - <AzureQueue>, само сообщение - <message>

Постановка в очередь

Следующий пример REST - запроса добавит сообщение в очередь, при помощи HTTP - метода PUT. Поясним некоторые моменты:параметр "messagettl" является необязательным и задает время жизни сообщения в секундах до семи дней, что является также сроком жизни по - умолчанию. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности.Параметр Content-Length (Длина содержимого) определяет размер содержимого сообщения.

PUT <ref src="http://<account>.queue.core.windows.net/

<AzureQueue>/messages? messagettl=3600HTTP/1.1"

type="url"/> Content-Length: 3900Content-MD5:

HUXZLQLMuI/KZ5KDcJPcOA== Authorization: SharedKey <account>:<key>

x-ms-date: Thu, 10 May 14:05:56 GMT <mesage>

Извлечение сообщения

Следующий пример REST - запроса извлечет сообщение из очереди, при помощи HTTP - метода GET. Поясним некоторые моменты:"numofmessages" - число сообщение, которое должно быть извлечено (до 32х, по умолчанию только 1); " visibilitytimeout" - определяет время в секундах, которое сообщение будет оставаться невидимым, после его извлечения (от 30секунд до 2 часов, по умолчанию - 30 секунд).

GET http://<account>.queue.core.windows.net/<AzureQueue>

/messages?numofmessages=1 &visibilitytimeout=100HTTP/1.1Authorization:

SharedKey <account>:<key>x-ms-date: Thu, 10 May 14:05: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: 2<requestID>

Date: Thu, 10 May 14:05:56 GMT

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

<QueueMessagesList>

<QueueMessage>

<MessageId>MessageID</MessageId>

<InsertionTime>...</InsertionTime>

<ExpirationTime>...</ExpirationTime>

<PopReceipt> PRValue</PopReceipt>

<TimeNextVisible>...</TimeNextVisible>

<MessageText>MessageText</MessageText>

</QueueMessage>

</QueueMessagesList>

Следует пояснить тег <PopReceipt> его значение идентифицирует полученное сообщение, в частности это значение может быть использовано для удаления сообщения.

Удаление сообщения

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

DELETE /<account>/<AzureQueue>/messages/MessageID?popreceipt=PRValue&timeout=30HTTP/1.1

Content-Type: binary/octet-streamx-ms-date: Thu, 10 May 15:02:04 GMT Authorization: SharedKey <account>:<key>

Особенности обмена сообщениями Windows Azure Queuе

Подведем краткий итог и обратим внимание на основные особенности очередей и процесса обмена сообщениями Azure Queue.

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

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

Важно проектировать систему таким образом, чтобы одно сообщение из очереди могло быть обработано несколько раз без рассогласования состояния приложения, даже в случае, если сообщение обрабатывается разными рабочими ролями.

17. Microsoft .Net Access Services. Идентификация на основе утверждений

Как уже упоминалось в предыдущих лекция, .Net Access Control Services обеспечивает управление доступом к приложениям и сервисам и интеграцию с имеющимися у заказчика средствами авторизации. Поддерживаются стандартные механизмы аутентификации (к примеруWindows Live ID, Active Directory ). Основой сервиса Access Control является Windows Identity Foundation.

С .Net Access Control Services "облачные" и локальные приложения могут объединяться (в т.н. федерации) и позволяет использовать сервисы через firewall. Azure - приложение использует ту же систему безопасности каталогов, что и Active Directory, т.е. приложениебудет считать, что учетная запись пользователя управляется локально.

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

Основной целью данной лекции является знакомство с идентификацией на основе утверждений.

Идентификация на основе утверждения

Особенностью идентификации на основе утверждений является централизованная реализация сервисов аутентификации и авторизации вне локальной инфраструктуры, вне организации. Собственно, именно эти сервисы и предоставляет .Net Access Control.

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

Для обеспечения заявленного, приложения используют SAML (Security Assertion Markup Language). Утверждения передаются SAML - маркерами, каждый маркер несет часть информации о пользователе. Маркеры генерируются STS - программой.

STS (security token service), или сервис маркеров доступа - создает, подписывает и выдает маркеры доступа. STS принимает запросы на получение маркера (RST - request for token) и возвращает ответ (RSTR).

По сути, STS является элементом службы сертификации.

Однако, не все так просто, как кажется на первый взгляд. SAML маркер может не содержать утверждений, ожидаемых приложением и сервис, генерирующий маркером может не быть доверенным, с точки зрения приложения. Для решения этой проблемы в процесс идентификации вовлекается еще один STS - сервис, гарантирующий, что SAML - маркеры будут содержать всю требуемую информацию. При этом, .Net Access Control Services, использую федеративные механизмы, устанавливает доверенную связь между новым STS и сервисом, генерирующим маркеры.

Рис. 24.1 показывает, как .Net Access Control Services обеспечивает преобразование утверждений и федеративную идентификацию.

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

Генерируется запрос на получения SAML - маркера к STS службам, формирующим маркеры на основе ряда правил.

Маркер передается клиенту. Маркер предается приложению. Приложение принимает только маркеры подписанные службой сертификации, все иные маркеры отклоняются.

Рис. 24.1.

На рисунке 24.1 на стороне пользователя подразумевается наличие Smart - клиента, генерирующего запросы к STS и взаимодействующие с приложением. В случае использования пользователем браузера, при обращении к веб - приложению, использующим идентификацию на основе утверждений, шаги процесса идентификации будут следующими:

Пользователь посылает HTTP - запрос веб - приложению.

Приложение, поскольку пользователь не зарегистрирован, перенаправляет его на веб - страницу, предоставляемую доверенной службой сертификации.

Служба сертификации управляет процессом аутентификации пользователя.

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

SAML - маркер включается в состав ответа с java - сценарием.

Сценарий, вернувшись браузеру пользователя, передает маркер веб - приложению через POST - запрос.

Используемые стандарты

Возможность взаимодействия всех этих элементов обеспечивается несколькими WS -стандартами (см п.№8 списка материалов для самостоятельного изучения).

WSDL извлекается с помощью WS-MetadataExchange или простого HTTP-запроса GET, и политика в WSDL структурирована соответственно спецификации WS-Policy.

STS службы сертификации предоставляют конечную точку, реализующую спецификацию WS-Trust, которая описывает процессы запроса и получения маркеров доступа.

SAML - словарь XML, который может использоваться для представления утверждений в форме, обеспечивающей возможность

Основной задачей .Net Service Bus является обеспечение коммуникаций между приложениями. Использование данных служб решает проблемы:

передачи запросов через брандмауэр;

определения конечных точек (endpoints) сервисов.

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

Вторым способом решения данных проблем является Windows Communication Foundation (WCF), использующий основанные веб-протоколы передачи данных, в т.ч. SOAP.

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

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

Рассмотрим более подробно .Net Service Bus, чтобы понять, как данный сервис справляется с обеспечением эффективного обмена сообщениями.

Концепция .Net Service Bus

Первоначально для того, чтобы воспользоваться возможностями .Net Service Bus, приложения должны зарегистрироваться в соответствующем реестре. Когда приложение обращается к службе, находящейся за брандмауэром, с помощью ,Net Service Busопределяется конечная точка службы и с ней устанавливается связь., т.е. непосредственно сам сервис выполняется за брандмауэром, а соединение с ним обеспечивает Service Bus. Клиенты видят только IP адрес, предоставляемый Service Bus, а не IP, предоставляемый компанией. Данный подход использует возможности .Net Access Control для обеспечения безопасности доступа.

Фактически, приложение использующее .Net Service Bus, реализует WCF функционал, но это не является обязательным. Приложение, обращающееся к сервисам за брандмауэром также может сформировать SOAP или REST - запрос.

Шаблон Enterprise Service Bus (ESB)

Enterprise Service Bus, или сервисная шина предприятия -- подход к построению распределённых корпоративных информационных систем. Обычно включает в себя промежуточное ПО, которое обеспечивает взаимосвязь между различными приложениями по различным протоколам взаимодействия.

Рис. 25.1. (Источник -книга " Introducing Windows Azure" Henry Li)

Шаблон ESB требует:

интегрированных механизмов идентификации и управления доступом

механизма присваивания имен сервисам

общей среды обмена сообщениями

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

К продуктам и технологиям реализации ESB можно отнести:

Active Directory

UDDI

BizTalk Server

MSMQ

WCF

Сервисная шина Интернета (Internet Service Bus - ISB)

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

ISB сделала бы возможным интегрировать вашу локальную ESB с вашими сервисами, выполняющимися в "облаке", с различными сервисами сторонних производителей, RIA и веб - приложениями.

Проблемы реализации двусторонней Интернет связи:

нехватка IPv4-адресов;

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

Тем не менее на сегодняшний день можно говорить о наличии двунаправленных приложений, таких как:

сервисы мгновенного обмена сообщениями (ICQ, MSN)

сетевые игры

приложения совместного использования файлов (torrent - клиенты)

Обмен сообщениями

Центральной частью .Net Services Bus является сервис ретрансляции, обеспечивающий возможность обмена сообщениями.

Сервис ретрансляции поддерживает:

однонаправленный обмен сообщениями;

синхронный обмен сообщениями;

обмен сообщениями между равноправными участниками сети.

В этом случае вашим сервисам больше нет необходимости создавать локальных слушателей транспортного уровня; они полностью полагаются на сервис ретрансляции в вопросах обработки указанных транспортных аспектов связи. Сервис ретрансляции просто пересылает входящие сообщения на ваш локальный сервис.

18. Отладка и развертывание проекта

Развертывание "облачной" службы

"Облачную" службу можно развернуть непосредственно из среды разработки. В нашем случае, щелкнув правой кнопкой мыши на проекте "облачной" службы, и выбрав пункт "Опубликовать."

Рис. 26.1.

В появившемся окне "Развертывание проекта Windows Azure " модно выбрать один из следующих вариантов:

Только создать пакет службы. Можно указать Visual Studio только создать пакет службы. Когда пакет создан, Visual Studioоткрывает окно проводника, показывая расположение файла созданного пакета. Теперь вы можете перейти на портал разработчика и развернуть пакет и файл конфигурации в нужный слот развертывания.

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

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

Подписка на Windows Azure. При регистрации в Windows Azure подписка связывается с вашим Live ID. Идентификатор подписки можно найти, перейдя на страницу Account портала разработки. Идентификатор подписки отображается в разделе Support Information в нижней части страницы.

Размещенная служба Windows Azure. До развертывания "облачной" службы необходимо создать размещенную службу для этого развертывания. Размещенная служба предоставляет два слота развертывания, в которые может быть развернута "облачная" служба: Промежуточный и Производственный.

Учетная запись хранилища Windows Azure. При развертывании "облачной" службы из Visual Studio пакет службы сначала отправляются в хранилище больших двоичных объектов через заданную учетную запись хранилища, а затем разворачиваются в среде Windows Azure из службы больших двоичных объектов.

При первом развертывании "облачной" службы из Visual Studio необходимо связать ее с размещенной службой, созданной вами на портале разработчика; также необходимо предоставить учетные данные, которые Visual Studio сможет использовать для взаимодействия с вашей подпиской Windows Azure.



Рис. 26.2.

Также в окне "Развертывание облачной службы" можно включить IntelliTrace.

Просмотр состояния развертывания

Состояние развертывания также можно просматривать средствами среды разработки в обозревателе серверов, где можно добавить развертывания для отслеживания. При просмотре состояния развертывания работу в Visual Studio прерывать не требуется.

Рис. 26.3.

Обозреватель вычислений Windows Azure позволяет просматривать и отслеживать только ваши собственные развертывания; из обозревателя вычислений Windows Azure нельзя запускать и останавливать экземпляры ролей.

Просматривать службу в обозревателе вычислений Windows Azure можно только после того, как она развернута в слот развертывания.

Чтобы добавить развертывание в обозреватель вычислений Windows Azure:

Откройте обозреватель серверов.

Щелкните правой кнопкой мыши в обозревателе вычислений Windows Azure и выберите "Добавление среды развертывания", для отображения окна "Добавление среды развертывания".

Чтобы добавить слот развертывания для отслеживания щелкните правой кнопкой мыши узел "Учетные данные Windows Azure " и выберите "Создать".

Рис. 26.4.

облачный мультитенантный программирование интерфейс

Эти учетные данные используются Visual Studio для взаимодействия с Windows Azure для управления вашими размещенными службами.

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

Отладка с помощью IntelliTrace

Отладка с помощью IntelliTrace доступная в Microsoft Visual Studio 2010 Ultimate, и позволяет получить более подробное представление о приложении. С помощью IntelliTrace можно увидеть события, произошедшие в прошлом, а также контекст, в котором они происходили.

Отладку с помощью IntelliTrace можно включить только для "облачной" службы, развертывание которой выполняется из Visual Studio. Необходимо настроить отладку с помощью IntelliTrace для "облачной" службы перед ее развертыванием в среду Windows Azure. Еслиотладка для службы не настроена, и вы решили сделать это, необходимо заново выполнить развертывание службы через Visual Studio.

Когда все готово к развертыванию "облачной" службы, убедитесь, что для целевых объектов построения задано значение Отладка. Затем щелкните правой кнопкой мыши по проекту "облачной" службы в обозревателе решений и выберите "Опубликовать". Для включения IntelliTrace установите флажок "Включить IntelliTrace для ролей .NET 4" в диалоговом окне "Развертывание проектаWindows Azure ".

Журнал IntelliTrace представляет собой кольцевой файл журнала, максимальный размер которого указывается в настройках IntelliTrace(размер по умолчанию 250 МБ). Журналы IntelliTrace записываются в файл в файловой системе виртуальной машины. В момент, когда вы запрашиваете журнал, делается снимок, который загружается на ваш локальный компьютер.

Загрузить журналы IntelliTrace для экземпляра роли можно с помощью обозревателя вычислений Windows Azure.

Размещено на Allbest.ru