OData на практике

Создание полнофункциональных интернет-приложений с применением Open Data Protocol

Шейн Бургес

На конференции PDC09 группа Microsoft WCF Data Services (ранее называлась ADO.NET Data Services) впервые сообщила о протоколе OData — Open Data Protocol. Объявление о его выпуске прозвучало в программном докладе на второй день конференции, но жизнь OData началась не в тот момент. Люди, знакомые с ADO.NET Data Services, уже использовали OData как протокол передачи данных для приложений на основе ресурсов, поскольку ADO.NET Data Services появилась еще в Microsoft .NET Framework 3.5 SP1. В этой статье я объясню, как разработчики полнофункциональных интернет-приложений (Rich Internet Applications, RIA) могут применять OData, и покажу преимущества этого.

Я начну с ответа на вопрос номер один, который мне задают с момента объявления OData в ноябре прошлого года: «Что это такое?». Говоря очень простыми словами, OData — это веб-протокол на основе ресурсов для запроса и обновления данных. OData определяет операции с ресурсами, используя HTTP-команды (PUT, POST, UPDATE и DELETE), и идентифицирует эти ресурсы по стандартному синтаксису URI. Данные передаются поверх HTTP с применением стандартов AtomPub или JSON. В случае AtomPub протокол OData определяет некоторые соглашения в стандарте для поддержки обмена информацией о запросах и схемах. Подробности о протоколе OData см. на сайте odata.org.

Экосистема OData

В этой статье я ознакомлю вас с несколькими продуктами, инфраструктурами и веб-сервисами, которые используют или создают каналы OData. Этот протокол определяет ресурсы, методы и операции (GET, PUT, POST, MERGE и DELETE, соответствующие операциям чтения, создания, замены, слияния и удаления), которые можно выполнять применительно к этим ресурсам с помощью методов.

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

Если, например, вы работаете с Silverlight и изучили библиотеку OData для этой платформы, то можете программировать, используя любой канал OData. Помимо библиотеки OData для Silverlight, вы найдете аналогичные библиотеки для клиента Microsoft .NET Framework, AJAX, Java, PHP, Objective-C и др. Кроме того, Microsoft PowerPivot for Excel поддерживает канал OData (OData feed) как один из вариантов импорта данных в свое ядро анализа информации в памяти.

Так же, как клиенты, способные использовать протокол OData, могут работать с любым источником данных, к сервису или приложению, созданному с применением OData, могут обращаться любые клиенты с поддержкой OData. Создав веб-сервис, предоставляющий реляционные данные как конечную точку OData (или предоставляющий данные на сайте SharePoint, таблицах в Windows Azure и т. д.), вы можете легко сконструировать полнофункциональный настольный клиент в .NET Framework или веб-сайт на основе AJAX с богатой функциональностью, способный использовать эти данные.

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

Что нового в WCF Data Services?

WCF Data Services — компонент .NET Framework — инфраструктура, предлагающая решение «под ключ» для создания веб-сервисов OData и включающая клиентскую библиотеку, с помощью которой можно создавать клиенты, использующие каналы OData. Группа WCF Data Services недавно выпустила обновление для .NET Framework 3.5 SP1, в котором появился целый набор новых средств, уже имеющихся в .NET Framework 4. Это вторая версия инфраструктуры Data Services. Полное описание и ссылку на скачивание вы найдете здесь: blogs.msdn.com/astoriateam/archive/2010/01/27/data-services-update-for-net-3-5-sp1-available-for-download.aspx.

Инфраструктура WCF Data Services — не просто протокол для RIA-приложений. Он был спроектирован для разработчиков крупномасштабных сервисов и имеет много привлекательных для них возможностей, в том числе поддержку лимитов на серверной стороне, HTTP-кеширования, сервисов без состояний, потоковой передачи данных и модели подключаемых провайдеров. Давайте рассмотрим новые средства, которые в целом представляют наибольший интерес для разработчиков RIA-приложений.

Одним из наиболее частых пожеланий, высказывавшихся заказчиками после первого выпуска, было введение возможности запрашивать количество сущностей в наборе. И новый механизм «счетчика» как раз для этого и включен. Он состоит из двух частей. Во-первых, он позволяет запрашивать только счетчик, т. е. количество значений, которое должен вернуть запрос. Во-вторых, добавлен параметр запроса, который сообщает сервису включать счетчик общего количества сущностей в набор, когда результатом запроса является частичный набор, например при включенной поддержке разбиения набора на страницы на серверной стороне (server paging).

Чтобы упростить связывание с данными от OData-сервиса, в клиентскую библиотеку WCF Data Services добавлен новый тип — DataServiceCollection. Он реализует отслеживание изменений содержащихся в нем элементов (через интерфейсы INotifyPropertyChanged и INotifyCollectionChanged). Если его привязать к какому-либо элементу управления (например, DataGrid в Silverlight), он будет отслеживать изменения, внесенные в объекты и в сам набор. Этот новый набор значительно облегчает процесс создания OData-клиентов.

Также заказчики часто просили добавить возможность проецировать подмножество свойств сущности, возвращаемой в результате запроса. Для этого ввели LINQ-поддержку на основе LINQ-выражения Select. Это дает два преимущества: сокращается размер HTTP-ответов на запросы и уменьшается объем памяти, занимаемый объектами на клиентской стороне. Это может оказаться особенно полезным при разработке клиентского приложения, использующего некий сервис, который вам не принадлежит и в котором у каждой сущности есть много свойств, не нужных вашему клиенту. Далее в этой статье я продемонстрирую работу с крупномасштабным, общедоступным сервисом с большим количеством сущностей, имеющих множество свойств. Проекции будут весьма полезны в этом примере, так как благодаря им можно будет включать лишь некоторые, действительно необходимые свойства сущности.

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

Реляционные данные

Основной источник данных для приложения Home Finder компании Contoso.com — база данных SQL Server, которая содержит информацию обо всей недвижимости, управляемой компанией, и все лоты (текущие и ранее проданные), опубликованные по этой недвижимости.

Благодаря выпуску WCF Data Services и ADO.NET Entity Framework в .NET Framework 3.5 SP1 к реляционной базе данных можно легко обращаться как к каналу OData. Нужно лишь создать модель данных Entity Framework поверх этих реляционных данных. Канал OData базируется на HTTP, поэтому вы должны разместить сервис на веб-сайте или в веб-сервисе.

Чтобы создать канал OData поверх реляционных данных, начните с создания веб-приложения ASP.NET в Visual Studio 2010, которое будет хостом OData-сервиса. В Visual Studio выберите File | New | Project | ASP.NET Web Application. Это приведет к генерации скелетного кода веб-сервиса, который можно будет использовать для хостинга канала OData.

После создания и настройки веб-сервиса мы создадим модель данных Entity Framework, которую будет предоставлять канал OData. Visual Studio упрощает эту задачу с помощью мастера Add New Item, позволяющего автоматически генерировать такую модель на основе существующей базы данных. На рис. 1 показана простая модель данных, созданная с применением мастера Add New Item поверх данных SQL Server, в которых содержатся сведения о недвижимости и лотах, управляемых Contoso.

Рис. 1. Модель данных Entity Framework для реляционных данных

Теперь создадим WCF-сервис данных, открывающий доступ к этой модели как к каналу OData. Visual Studio позволяет упростить и эту задачу выбором варианта WCF Data Service в мастере Add New Item. В этом случае Visual Studio предоставляет файл кода (в данном примере этот файл называется Listings.svc.cs), используемый для конфигурирования сервиса данных.

Код на рис. 2 демонстрирует, как определить WCF-сервис данных. Listings — это класс сервиса, предоставляющий сервис данных; он реализует обобщенный DataService<T>. Для определения DataService<T> на рис. 2 использован тип ListingsEntities, это контекст Entity Framework, созданный на рис. 1. Поскольку этот класс будет принимать контекст Entity Framework, это простой и быстрый способ получить WCF-сервис данных, предоставляющий реляционные данные. Однако класс DataService не ограничен работой только через контексты Entity Framework; он будет принимать любые наборы CLR-объектов, реализующих интерфейс IQueryable. В .NET Framework 4 была введена новая модель собственных провайдеров для WCF Data Services, которая позволяет создавать сервис поверх практически любого источника данных.

Рис. 2. Определение WCF-сервиса данных

// The ListingsEntities is the Entity Framework Context that the Service exposes
public class Listings : DataService< ListingsEntities >
{
  public static void InitializeService(DataServiceConfiguration config)
  {
    // These lines set the access rights to "Read Only" for both entity sets
    config.SetEntitySetAccessRule("Listings", EntitySetRights.AllRead);
    config.SetEntitySetAccessRule("Properties", EntitySetRights.AllRead);

    // There are currently no service operations in the service
    config.SetServiceOperationAccessRule("MyServiceOperation",
      ServiceOperationRights.All);

    config.DataServiceBehavior.MaxProtocolVersion = 
      DataServiceProtocolVersion.V2;
  }
}

Давайте подробнее рассмотрим, что еще делает метод InitalizeService на рис. 2. Он вызывает SetEntitySetAccessRule для обоих наборов сущностей, которые будет предоставлять сервис и задает права доступа как AllRead. Это указывает сервису сделать оба набора сущностей полностью доступными для чтения, но запретить любые попытки вставок, обновлений или удалений. И это отличный способ управлять доступом к сервису. WCF Data Services также поддерживает методы, называемые перехватчиками запросов (Query Interceptors); они позволяют автору сервиса более тонко разграничивать права доступа для сервиса индивидуально для каждого набора сущностей. Установите файл Listings.svc как стартовую страницу проекта и запустите проект. Откроется окно браузера, и вы увидите документ сервиса (рис. 3).

Рис. 3. Документ сервиса для сайта SharePoint

Соглашения в OData по URI

В документе сервиса перечисляются наборы сущностей, предоставляемые этим сервисом. Помните: вы можете обращаться к ресурсам в этом сервисе, используя мощный синтаксис URI, определенный как необязательная часть протокола OData. Давайте кратко рассмотрим синтаксис URI для этого сервиса. Чтобы получить доступ к каналу для каждого набора сущностей, вы дописываете имя этого набора к базовому URI сервиса, например http://myhost/Listings.svc/Properties будет указывать на набор сущностей Properties.

Кроме того, можно адресоваться индивидуально к конкретной сущности, используя ее значение ключа; URI http://myhost/Listings.svc/Properties(0) указывал бы на сущность Property с идентификатором, равным 0. Вы можете использовать связи между сущностями или наборами сущностей, добавляя в конец URI имя отношения, и http://myhost/Listings.svc/Properties(0)/Listings позволял бы обращаться к набору лотов, связанных с сущностью Property с нулевым идентификатором. Благодаря такому синтаксису становится возможной навигация по множеству уровней связей (отношений).

Синтаксис URI также определяет количество параметров запроса, которые можно добавлять в конец URI для модификации базового запроса, а каждый параметр запроса определяется как пара «имя-значение». Например, добавив параметр запроса $top=10, вы ограничите результат запроса только первыми десятью элементами. На рис. 1 перечислены все параметры запросов, доступные в этом синтаксисе URI.

Рис. 1. Параметры OData-запроса

$top=n	Ограничивает запрос первыми n сущностями
$skip=n	Пропускает первые n сущностей в наборе
$inlinecount=allpages	Включает счетчик всех сущностей из набора в результат
$filter=<выражение>	Выражение позволяет ограничивать результаты, возвращаемые запросом (пример: $filter=Status eq 'Available' ограничивает результаты сущностями, у которых свойство Status имеет значение "Available").
$orderby=<выражение>	Упорядочивает результаты по набору свойств сущности
$select=<выражение>	Указывает возвращаемое подмножество свойств сущности
$format	Указывает формат возвращаемого канала (ATOM или JSON). Этот параметр не поддерживается в WCF Data Services

Предоставление данных из SharePoint

В предыдущем разделе я показал, как обеспечить доступ к данным, хранящимся в моей реляционной базе данных с информацией о недвижимости и лотах для веб-сайта риэлтерской компании. Допустим, у меня есть также информация об агентах по продажам недвижимости, но эти сведения хранятся на сайте SharePoint. Microsoft SharePoint 2010 позволяет предоставлять все списки и документы внутри этих списков как канал OData. Это просто замечательно для сайта риэлтерской компании, так как информация об агентах, введенная сотрудниками компании, доступна по каналу OData, который может быть включен в создаваемое мной приложение для обработки лотов (Listings application). Компаниям, у которых есть процессы ввода и обновления таких данных через интерфейс SharePoint, не придется что-либо менять в своих рабочих процессах для подстройки под мое приложение. Данные, введенные на сайт SharePoint компании, доступны в реальном времени для создаваемого приложения Listings.

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

Рис. 5. Сайт SharePoint для хранения информации об агентах

После установки ADO.NET Data Services Update для .NET Framework 3.5 SP1 в системе с SharePoint для каждого сайта, предоставляющего данные списков как канал OData, становится доступным новая конечная точка HTTP. Благодаря этому канал OData можно просматривать просто браузером Internet Explorer. На рис. 6 показан канал для списка агентов в SharePoint.

Рис. 6. Канал агентов для SharePoint Agent Service

Использование справочных данных от OGDI

По умолчанию канал OData будет возвращать ATOM-представление, поэтому при обращении из браузера результат будет показываться как канал ATOM. Если в запросе изменить заголовок приема (accept header) на «application/json», те же данные будут возвращаться как канал JSON.

Канал на рис. 5 начинается с элемента <feed>, представляющего набор сущностей. Внутри каждого канала содержится набор элементов <entry>, каждый из которых представляет одну сущность в канале (первые три элемента <entry> свернуты, чтобы на экране было видно содержимое всего канала).

В этом примере для сущности определен маркер параллельной обработки (concurrency token); в итоге у каждой сущности в этом канале есть свойство etag. Это свойство — маркер, используемый сервисом данных для принудительной проверки на параллельную обработку, когда в запрошенную сущность вносится какое-либо изменение. Каждая сущность, отформатированная с применением тега <entry>, состоит из набора ссылок, который содержит как ссылку для использования при редактировании сущности, так и отношения с другими сущностями. Каждая ссылка отношения (relationship link) указывает либо на другую сущность, либо на набор сущностей (такие свойства называют соответственно ссылочными и навигационными). Каждый элемент <entry> также включает элемент <m:properties>, содержащий свойства сущности элементарного и комплексного типов; значения свойств состоят из имени свойства сущности и значения самого свойства.

Open Government Data Initiative (OGDI) — сервис, встроенный в платформу Microsoft Windows Azure и упрощающий правительственным агентствам публикацию самых разнообразных общедоступных данных. Проект OGDI предоставляет стартовый набор, который правительственные агентства могут использовать для доступа к своим данным. Например, в Эдмонтоне используют стартовый набор для доступа к информации от муниципалитета, а сервис на ogdisdk.cloudapp.net имеет набор данных с разнообразной информацией о Вашингтоне, округ Колумбия. Другой пример — проект Microsoft по кодовым названием «Dallas», нацеленный на то, чтобы упростить любому лицу или организации, обладающей какой-либо общественно интересной информацией, предоставление своих данных в виде сервиса в Интернете. Этот проект также создан на платформе Windows Azure и обеспечивает доступ к данным через OData. Все это примеры крупномасштабных сервисов, открывающих доступ к большим наборам справочных данных, которые могут использоваться веб-приложениями. Как я покажу далее, если эти сервисы предоставляют свои данные через OData, их очень легко использовать в самых разных приложениях.

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

Другие провайдеры данных OData

До сих я показывал примеры использования данных от SQL Server, SharePoint и универсального OData-сервиса в Интернете, но существуют и другие варианты. Облачная платформа Windows Azure имеет сервис таблиц, которые предоставляет доступ к данным, хранящимся в таблицах Windows Azure, и соответствующий API построен на использовании OData. Как упоминалось, проект Microsoft Dallas является централизованной площадкой для поиска и запроса данных, предоставляемых сервисом Dallas, и этот сервис обеспечивает доступ к своим данным по протоколу OData. Кроме того, провайдеры данных OData не ограничены только продуктами Microsoft; в частности, IBM недавно объявила, что ее продукт WebSphere eXtreme Scale 7.0 теперь поддерживает протокол OData.

Клиент Silverlight

Приложение Contoso для поиска недвижимости теперь имеет, во-первых, веб-сервис ASP.NET, который предоставляет реляционные данные из SQL Server с информацией о лотах и недвижимости, управляемой компанией, во-вторых, сайт SharePoint, применяемый для управления сведениями об агентах по продаже недвижимости, и, в-третьих, государственный веб-сервис, предоставляющий информацию о местности вокруг рекламируемой компанией недвижимости. Я хочу соединить все эти источники в одно приложение Silverlight, которое сможет осмысленно работать с этими данными.

В Silverlight 3 клиентская библиотека WCF Data Services включается в Silverlight SDK, который упрощает взаимодействие приложений Silverlight с сервисом, поддерживающим OData. Для этого в Visual Studio из проекта Silverlight щелкните правой кнопкой мыши проект и выберите Add Service Reference. В итоге это позволит добавить ссылку на сервис. Главное, что вы должны ввести, — URI сервиса, на который есть ссылка из приложения Silverlight. На рис. 7 показан пример добавления ссылки на сервис-пример OGDI.

Рис. 7. Добавление ссылки на сервис-пример OGDI

Мастер добавления ссылки на сервис создает контекст на клиентской стороне, используемый для взаимодействия с сервисом данных. Клиентский контекст абстрагирует детали работы с HTTP и URI в модели программирования на клиентской стороне и позволяет разработчику клиента сосредоточиться исключительно на C#-классах и XAML. Клиентский контекст также включает реализацию LINQ-провайдера, что обеспечивает поддержку LINQ-запросов к прокси. Кроме того, мастер Add Service Reference генерирует набор классов клиентских прокси, отражающих типы, которые предоставляются сервисом. Создав ссылку на сервис OGDI, я также добавляю ссылки на уже готовые сервисы SharePoint и Listings. Следующий код показывает, как создавать контексты, применяемые для взаимодействия с этими тремя сервисами OData:

// OGDI service context
OGDIService.dcDataService OGDIService = 
  new dcDataService(new Uri(OGDIServiceURI));

// SharePoint service context
AgentsReference.AgentsDataContext agentsService = 
  new AgentsReference.AgentsDataContext(new Uri(sharepointServiceURI));

// Listings Service context
ListingReference.ListingsEntities listingsService =
  new ListingReference.ListingsEntities(new Uri(listingsServiceURI));

На рис. 8 приведен внешний вид приложения Home Finder на Silverlight. Оно будет размещено в SharePoint, чтобы к нему могли легко обращаться мои существующие пользователи, привыкшие работать в среде SharePoint.

Рис. 8. Contoso Home Finder

На рис. 9 представлен код для запроса сервиса Listings и связывания результата с элементом управления «сетка» в верхней части окна приложения Home Finder.

Рис. 9. Создание контекстов клиентских прокси

private void getListings()
{
  DataServiceCollection<Listing> listings = new 
    DataServiceCollection<Listing>();

  listingsGrid.ItemsSource = listings;
  
  var query = from listing in
              listingsService.Listings.Expand("Property")
              select listing;
  listings.LoadAsync(query);
}

Код на рис. 9 создает DataServiceCollection — отслеживаемый набор — и привязывает его к свойству ItemsSource основной сетки лотов. Поскольку этот набор реализует отслеживание изменений, любое изменение, внесенное в элементы сетки, будет автоматически отражаться на сущностях в наборе лотов. Изменения, внесенные в сетке, можно сохранять в сервисе вызовом метода BeginSaveChanges контекста для сервиса Listings.

В Silverlight все сетевые вызовы осуществляются асинхронно, поэтому выполнение любых операций с сервисом с применением клиентской библиотеки WCF Data Services требует начального вызова операции и написания отдельного метода обратного вызова, передаваемого для последующей обработки результата асинхронного вызова. Чтобы упростить работу с асинхронными вызовами, в класс DataServiceCollection был добавлен метод LoadAsync, который берет на себя выполнение всей работы с функцией обратного вызова и загрузки результатов в набор.

В коде на рис. 8 набор связывается с сеткой до вызова LoadAsync, и значения не загружаются в набор, пока не завершится асинхронный вызов. Набор будет генерировать события изменения набора при возврате результатов сервисом; сетка будет захватывать эти события и отображать результаты по завершении асинхронного вызова.

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

На рис. 9 показано, как запросить у сервиса SharePoint сущность агента, передав ему имя агента. Похожий код используется для запроса от OGDI статистических данных по криминогенной обстановке в близлежащей местности на диаграмме внизу страницы Home Finder. Код вплоть до этого момента демонстрирует только возможности запросов клиента Silverlight, но такой клиент не ограничен одними запросами; он располагает богатыми средствами для обратной записи изменений в сервис.

Рис. 10. Выполнение асинхронного запроса

private void GetAgentData(string agentName)
{
    var query = agentsService.Agents.Where(a => a.FullName == agentName) as 
        DataServiceQuery;

    query.BeginExecute(
        AgentQueryCallBack, query);
}

private void AgentQueryCallBack(IAsyncResult result)
{
    Dispatcher.BeginInvoke(() =>
    {
        var queryResult = result.AsyncState as DataServiceQuery<AgentsItem>;
        if (queryResult != null)
        {
            var agents = queryResult.EndExecute(result);
            this.grdAgent.DataContext = agents.First();
        }
    });
}

OData в PowerPivot

PowerPivot — новый инструмент бизнес-анализа информации в памяти, поставляемый как надстройка для Microsoft Excel 2010; за более подробными сведениями обращайтесь на сайт powerpivot.com. Этот инструмент поддерживает импорт больших наборов данных из источника данных, выполнение комплексного анализа информации и генерацию отчетов. PowerPivot может импортировать данные из разнообразных источников, в том числе прямо из каналов OData. Выбор From Data Feeds в PowerPivot (рис. 11) включает поддержку конечной точки OData-сервиса как адрес канала для импорта.

Рис. 11. PowerPivot импортирует данные из канала OData

На рис. 12 показана сводная диаграмма по статистике криминогенной обстановки в Вашингтоне, округ Колумбия, полученной от OGDI.

Рис. 12. Диаграмма PowerPivot на основе информации из канала OData

Диаграмма на рис. 12, использующая тот же набор данных, что и риэлтерское приложение в предыдущем примере, показывает сводные данные по каждому округу. Рекомендую скачать PowerPivot for Excel 2010 и импортировать данные с сайта OGDI по ссылке ogdi.cloudapp.net/v1/dc, а потом самостоятельно убедиться, насколько быстро этот инструмент выполняет анализ этих данных.

Open Data Protocol Visualizer

OGDI-сервис данных, по сути, является «черным ящиком» для стороннего разработчика, который создает приложение, использующее данные от этого сервиса. К счастью, OGDI-сервис предоставляет свои данные по протоколу OData, поэтому знать детали внутреннего устройства сервиса для взаимодействия с ним не требуется. Модель программирования этого сервиса — протокол OData. Конечная точка сервиса описывает форму данных и, как я показывал в предыдущем разделе, это все, что вам нужно знать для взаимодействия с сервисом. Однако зачастую полезно видеть форму данных в сервисе и лучше понимать взаимосвязи между частями сервиса. Именно с этой целью и был создан Open Data Protocol Visualizer. Он доступен из меню Tools | Extension Manager в Visual Studio 2010. На рис. 13 даны два представления, с помощью которых этот визуализатор отображает структуру данного OGDI-сервиса.

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

Рис. 13. Представления сервиса-примера OGDI в Open Data Protocol Visualizer

Где узнать больше

Эта статья — не более чем введение в Open Data Protocol и экосистему, построенную вокруг него, включая инфраструктуру WCF Data Services. Дополнительные сведения можно получить на веб-сайте Open Data Protocol по адресу odata.org. Дополнительные сведения по WCF Data Services можно получить по адресу msdn.microsoft.com/data/bb931106 или в блоге по WCF Data Services по адресу blogs.msdn.com/astoriateam.

Шейн Бургес (Shayne Burgess) — менеджер программ в группе Microsoft Data and Modeling, занимается WCF Data Services и Open Data Protocol. Регулярно публикует статьи в блоге группы WCF Data Services blogs.msdn.com/b/astoriateam.

Выражаю благодарность за рецензирование статьи эксперту: Элизе Фласко (Elisa Flasko) и Майку Фласко (Mike Flasko)