Доступ к данным

Квалифицированные пользователи смогут сами создавать свои OData-каналы

Джули Лерман

 

В этой статье рассматривается продукт Microsoft Codename «Data Explorer». Любая изложенная здесь информация может быть изменена.

У меня есть заказчик, для которого я разрабатываю множество внутренних бизнес-приложений. В этой компании также есть местный энтузиаст — молодой человек, использующий свои знания в области Web 2.0 для создания некоторых внутренних решений. Я пишу для них код с применением средств Microsoft .NET Framework, который работает с базой данных SQL Server 2008. А этот энтузиаст разрабатывает PHP-приложения, использующие онлайновую базу данных MySQL. Несколько лет назад он показал мне, над чем он работает, и я заметила раскрывающиеся списки, содержащие данные, которые дублировали данные, создаваемые моими приложениями и используемые в SQL Server. В то время WCF Data Services все еще пребывала на ранних этапах разработки (под кодовым названием «Astoria»), но я увидела в этой технологии возможность навести мосты между нашими проектами.

Я предложила создать для данных SQL Server сервис только для чтения, который он мог бы задействовать в своих приложениях, тем самым избавившись от необходимости поддерживать дублирующиеся данные в базе данных MySQL. Идея ему понравилась. А через несколько дней Microsoft выпустила свой первый инструментальный набор PHP для использования каналов Astoria. Этот программист стал одним из первых пользователей этого набора, и мы смогли очень быстро создать наше совместное решение.

Теперь промотаем время вперед… Astoria — это теперь WCF Data Services с выходными данными в формате, соответствующем спецификации OData (odata.org), и, кроме того, выпущен OData SDK for PHP (bit.ly/xW8sJf). Мой сервис существенно расширился после многочисленных просьб предоставлять больше данных из базы данных SQL Server для его приложений. Но есть одна проблема. Каждый раз, когда моему клиенту требовалось что-то новое в сервисе, мне приходилось создавать соответствующее представление в базе данных, открывать Visual Studio, модифицировать модель данных для включения сущности, сопоставленной с этим представлением, затем компилировать и заново развертывать новую версию сервиса через VPN на его веб-сервере. Этот процесс отнимает довольно много времени и может оказаться весьма некстати, особенно когда приближается срок сдачи материалов в мою рубрику!

 

SQL Azure Labs Codename «Data Explorer» спешит на помощь

На SQLPass Summit в октябре 2011 года Microsoft объявила о новом разрабатываемом инструменте, который в настоящее время называется Microsoft Codename «Data Explorer». Здесь я буду называть его просто «Data Explorer».

Data Explorer дает возможность пользователям обращаться к самым разнообразным источникам данных (SQL Azure, SQL Server, HTML с веб-страниц, OData-каналам, текстовым файлам, файлам Excel и многим другим) и формировать из них представления, используя сравнительно простой интерфейс. Этот UI позволяет формировать продольные и поперечные срезы данных, фильтровать, переименовывать и комбинировать данные. Вы можете смешать данные из файлов разных типов, чтобы создать, например, представление, которое объединяет ваши данные SQL Server со статистикой на веб-странице, а затем представить результаты в виде OData-канала, файла Excel или в любом другом формате.

Вы можете найти массу демонстраций и видеороликов по функциям Data Explorer в блоге группе его разработчиков (blogs.msdn.com/dataexplorer) или в SQL Azure Labs (sqlazurelabs.com). Data Explorer предлагается в виде веб-клиента (облачного сервиса) и настольного клиента. Облачный сервис в настоящее время размещен в SQL Azure Labs и для доступа к нему нужна регистрация (на bit.ly/pI8Oug). Текущую версию настольного приложения можно скачать по ссылке bit.ly/shltWn. На момент написания этой статьи данные инструменты все еще находились на ранних этапах разработки, и я предвижу появление множества усовершенствований.

Одна из функций Data Explorer, позволившая мне упростить добавление дополнительных данных к сервису данных, который я поддерживаю для своего заказчика, — возможность публиковать результаты анализа продольных и поперечных срезов данных (slicing and dicing) в формате OData-канала. Сегодня (по состоянию на начало января 2012 года, когда я писала эту статью) публикация поддерживается облачным сервисом, а настольный клиент такой поддержки пока не обеспечивает. Хотя моя цель в конечном счете выполнять всю эту работу во внутренней сети своего заказчика, используя его базу данных SQL Server и веб-сервис, я изучила возможность применения облачного сервиса и базы данных SQL Azure. Этим я и поделюсь с вами. Я не стану расписывать все по шагам, поскольку это уже сделано в ресурсах, на которые я ссылалась ранее.

Ваше рабочее пространство (workspace) может содержать несколько приложений, использующих данные из разных источников (mashups), а каждое из них — ряд ресурсов. На рис. 1 показаны четыре ресурса, созданные мной в приложении с именем Mashup1. Три ресурса открывают доступ к представлению Customers, списку данных Beer и списку Breweries, тогда как конечный ресурс (Beer List Merged with Breweries) предоставляет объединенный список пивоварен вместе с марками пива, которые они производят. Мне пришлось создать ресурсы Beer List и Breweries, чтобы объединить их в еще один ресурс. Состояние значка «галочка» справа сообщает, что будет предоставляться в публикуемых данных и чего там не будет. Блеклые галочки рядом с Breweries и Beer List указывают, что эти данные будут недоступны. Как видно на рис. 1, я намереваюсь опубликовать Customers и Beer List Merged with Breweries, но не исходные строительные блоки, из которых я создавала этот объединенный набор.

Рис. 1. Четыре набора данных, созданных в Mashup1

Если вы посмотрите на общую схему моего приложения в My Workspace, показанную на рис. 2, то заметите, что Mashup1 имеет два вывода, представляющие два ресурса, которые я решила сделать доступными.

Рис. 2. Общая схема Mashup1 в My Workspace

Когда я опубликую Mashup1 с помощью средств Data Explorer, а затем перейду в полученный OData-канал, вы увидите, что сервис действительно предоставляет доступ к этим двум ресурсам и ни к чему другому (рис. 3).

Рис. 3. Два ресурса, предоставляемые как наборы в моем опубликованном приложении

<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://www.w3.org/2007/app"
  xmlns:atom="http://www.w3.org/2005/Atom"
  xml:base="https://ws39047873.dataexplorer.sqlazurelabs.com/
  Published/CustomersAndBeerData/Feed/">
  <workspace>
    <atom:title type="text">Default</atom:title>
    <collection href="Beer List Merged with Breweries">
      <atom:title type="text">Beer List Merged with Breweries
      </atom:title>
    </collection>
    <collection href="Customers">
      <atom:title type="text">Customers</atom:title>
    </collection>
  </workspace>
</service>

Data Explorer UI позволяет визуально создавать сложные запросы, но, поскольку я буду формировать канал данных, мне проще создать представление в базе данных. Поэтому мой план таков: всякий раз, когда квалифицированный пользователь хочет получить доступ к большему объему данных в моем сервисе, я буду создавать соответствующее представление базы данных, добавлять его в качестве ресурса в свое приложение, работающее с разными источниками данных (mashup), и заново публиковать канал.

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

Однако Data Explorer предлагает и другой подход, позволяющий мне защищать свой API/канал от любых изменений в схеме. Я просто должна обновлять приложение для учета изменений в схеме, в то же время сохраняя неизменной форматы выходных данных. 

Уровни безопасности

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

На рис. 4 показаны все типы данных, которые можно использовать для создания ресурсов в приложении, работающем со множеством источников данных. Под общим названием SQL Databases может скрываться либо база данных SQL Server, либо база данных SQL Azure.

Рис. 4. Варианты добавления данных

В число возможных источников данных входят OData Feed и существующее приложение (mashup). Это позволяет квалифицированному пользователю создать свое приложение на основе моего опубликованного канала.

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

База данных останется защищенной, но как насчет канала данных, который я создаю? В Data Explorer уже встроен ряд средств защиты, и Microsoft работает над дальнейшим совершенствованием и расширением этих средств. Один из безопасных путей — выдавать разрешения пользователю с существующей учетной записью Data Explorer для доступа в ваше рабочее пространство в качестве Owner (владелец), Author (автор) или Consumer (потребитель). Если бы я выдала своему квалифицированному пользователю разрешения Author, то в своем рабочем пространстве он смог бы создавать и публиковать собственные приложения, основанные на моем канале.

Я также могла бы предоставить такому пользователю ключ канала (Feed Key). В каждом рабочем пространстве есть единственный Feed Key, который позволяет кому угодно обращаться к любому каналу, опубликованному из этого рабочего пространства. Когда пользователь обращается к моему OData-каналу для построения собственного приложения, ему потребуется предоставить удостоверения, указанные мной. На рис. 5 показано, как при попытке пользователя добавить к себе мой канал CustomersAndBeerData выводится запрос удостоверений.

Рис. 5. Добавление OData-канала в приложение

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

Ожидание того стоит

В итоге, когда квалифицированному пользователю требуется дополнительный OData для своего приложения, мое участие сводится к минимуму. Я по-прежнему должна добавлять соответствующее представление в базу данных, затем вводить новый ресурс в свой канал и публиковать его заново. Но этот рабочий процесс, проиллюстрированный на рис. 6, гораздо привлекательнее для меня, чем необходимость открывать проект в Visual Studio, изменять модель данных, заново компилировать проект, входить в VPN и, наконец, передавать новую сборку на сервер своего заказчика.

Рис. 6. Рабочий процесс от базы данных до приложения

Database	База данных
READ	Чтение
Developer Workspace	Рабочее пространство разработчика
PUBLISH	Публикация
OData for Power User	OData для квалифицированного пользователя
Power User Workspace	Рабочее пространство квалифицированного пользователя
OData for App	OData для приложения

Data Explorer пока не выпущен в виде продукта, и его развитие продолжается. Но, проработав данный сценарий с использованием доступной в настоящее время предварительной версии, я с нетерпением жду перехода на это решение, когда Data Explorer будет выпущен официально. Следите за новостями в блоге blogs.msdn.com/dataexplorer.

Data Explorer

Мигель Лопис и Фейсал Мохамуд

Microsoft Codename «Data Explorer» — новый инструмент для самообслуживания ETP-операций (Extract, Transform and Publish). Data Explorer упрощает создание неоднородного контента (data mashups) комбинацией различных источников данных, таких как Excel, Access, SQL Server, Web (HTML, Web API, OData) и др. Основная цель Data Explorer — облегчить получение, преобразование и композицию данных, чтобы публиковать данные в продуктах для конечных пользователей, например в Excel/PowerPivot или в собственных приложениях.

В настоящее время Data Explorer доступен как лабораторная версия в SQL Azure Labs и поддерживает как локальные, так и облачные источники данных. Чтобы узнать больше и опробовать на практике этот инновационный сервис Microsoft Azure, зайдите на сайт dataexplorer.sqlazurelabs.com.

---

Джули Лерман (Julie Lerman) — Microsoft MVP, преподаватель и консультант по .NET, живет в Вермонте. Часто выступает на конференциях по всему миру и в группах пользователей по тематике, связанной с доступом к данным и другими технологиями Microsoft .NET. Ведет блог thedatafarm.com/blog и является автором книг «Programming Entity Framework» (O’Reilly Media, 2010) и «Programming Entity Framework: Code First» (O’Reilly Media, 2011). Вы также можете читать ее заметки в twitter.com/julielerman.

Выражаю благодарность за рецензирование статьи экспертам Мигелю Лопису (Miguel Llopis) и Фейсалу Мохамуду (Faisal Mohamood).