次の方法で共有

実用 OData

  • [アーティクル]

Open Data Protocol を使用してリッチ インターネット アプリケーションを構築する

Shayne Burgess

マイクロソフトの WCF Data Services チーム (旧称 "ADO.NET Data Services チーム") は、PDC09 で初めて OData (Open Data Protocol) を公表しました。発表はカンファレンスの 2 日目の基調講演で行われましたが、OData はここから始まったわけではありません。ADO.NET Data Services に詳しいユーザーは、Microsoft .NET Framework 3.5 SP1 で ADO.NET Data Services を使用できるようになったときから、リソース ベースのアプリケーションで OData をデータ転送プロトコルとして使用していました。この記事では、リッチ インターネット アプリケーション (RIA: Rich Internet Application) の開発者が OData をどのように使用することができるかについて説明します。また、RIA の開発で OData を使用する利点も紹介します。

まずは、11 月 に OData が公表されて以来、私が最も聞かれることの多かった「OData とは何か」という質問にお答えしましょう。非常に簡単に言うと、OData とは、データの照会と更新を行うための、リソース ベースの Web プロトコルです。OData では、HTTP 動詞 (PUT、POST、UPDATE、および DELETE) を使用してリソースに対する操作が定義され、標準的な URI 構文を使用してこうしたリソースが特定されます。データは、AtomPub 標準または JSON 標準を使用して HTTP 経由で転送されます。AtomPub 標準に関しては、OData プロトコルでは、クエリとスキーマ情報の交換をサポートするためのいくつかの規則が定義されています。OData の詳細については、odata.org (英語) を参照してください。

OData のエコシステム

この記事では、OData フィードを使用または生成するいくつかの製品、フレームワーク、および Web サービスを紹介します。OData プロトコルでは、操作できるリソースとメソッド、およびこうしたリソースに対して実行できる操作 (GET、PUT、POST、MERGE、および DELETE。それぞれ、読み取り、作成、置換、マージ、および削除に対応します) が定義されています。

実際には、これは、OData プロトコルを使用できるクライアントはすべて、どのようなプロデューサーが生成したデータでも使用できることを意味します。サービスのプログラミング モデルを学習しなくても、そのサービスを使用してプログラミングを行うことは可能です。必要なのは、プログラミングに使用する言語を選択することだけです。

たとえば、Silverlight 用の OData ライブラリについて学習した Silverlight 開発者は、任意の OData フィードを使用してプログラミングを行うことができます。Silverlight 用の OData ライブラリの他に、Microsoft .NET Framework クライアント用、AJAX 用、Java 用、PHP 用、Objective-C 用などのライブラリもあります。また、Microsoft PowerPivot for Excel では、メモリ内分析エンジンにデータをインポートする際のオプションの 1 つとして OData フィードがサポートされています。

OData プロトコルを使用できるクライアントが、どのようなプロデューサーが生成したデータでも使用できるのと同様に、OData 対応のクライアントであればどのようなクライアントも、OData を使用して作成されたサービスやアプリケーションを使用することができます。リレーショナル データを OData エンドポイントとして公開する (または、データを SharePoint サイト、Windows Azure のテーブルなどで公開する) Web サービスを作成したら、.NET Framework でリッチ デスクトップ クライアントを簡単に構築したり、同じデータを使用する AJAX ベースのリッチ Web サイトを簡単に構築したりすることができます。

OData の長期的な目標は、すべてのクライアント アプリケーションが OData フィードの資源を利用できるように、すべての主要なテクノロジ、プログラミング言語、およびプラットフォーム用の OData クライアント ライブラリを用意することです。OData のプロデューサーとコンシューマーが組み合わさって、OData "エコシステム" が作り出されます。

WCF Data Services の新機能

.NET Framework のコンポーネントである WCF Data Services は、OData Web サービスを作成するためのターンキー ソリューションを提供するフレームワークです。WCF Data Services には、OData フィードを使用するクライアントの構築に使用できるクライアント ライブラリが含まれています。WCF Data Services チームは最近、.NET Framework 3.5 SP1 の更新プログラムをリリースしました。この更新プログラムでは、.NET Framework 4 にも含まれる多くの新機能が導入されています。これは、Data Services フレームワークの 2 番目のバージョンです。説明とダウンロード リンクが掲載された 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 開発者にとって最も興味深い新機能を見てみましょう。

最初のリリースの後でユーザーから最も多く要望が寄せられた機能の 1 つは、セット内のエンティティの数を要求する機能でした。新たに導入された "カウント" 機能では、2 段階でこの要望に対処します。第 1 に、この機能を使用すると、カウント (クエリが返す値の数) のみを要求することができます。第 2 に、この機能では、クエリ結果がセットの一部である場合 (サーバーのページングが有効になっている場合など) にセット内のエンティティの総数のカウントを含めるようにサービスに指示するクエリ オプションが追加されています。

OData サービスのデータをバインドしやすいように、WCF Data Services クライアント ライブラリに DataServiceCollection という新しい型が追加されました。DataServiceCollection には、格納されている項目の変更の追跡が実装されています (追跡は、INotifyPropertyChanged インターフェイスと INotifyCollectionChanged インターフェイスを使用して行われます)。コントロール (Silverlight の DataGrid など) にバインドされた場合、DataServiceCollection では、オブジェクトに加えられた変更とコレクション自体に加えられた変更を追跡します。この新しいコレクションにより、インターフェイス コンポーネントを使用して OData クライアントを作成するプロセスが大幅に簡略化されます。

この他にリクエストの多かった機能は、エンティティのプロパティの中で、クエリ結果で返すものを選択する機能です。これを実現するため、LINQ の Select ステートメントを通じて LINQ のサポートが追加されました。これには 2 つの利点があります。クエリへの HTTP 応答のサイズが縮小されること、およびクライアント側オブジェクトのメモリ占有領域が縮小されることです。これは、自分の所有物ではないサービスを使用してクライアント アプリケーションを開発しており、そのサービスの各エンティティがクライアントにとって重要でないプロパティを多数持つ可能性がある場合に、特に役立ちます。多くのエンティティを持ち、各エンティティが多数のプロパティを持つ、一般公開されている大規模なサービスを使用する例を後で紹介します。プロジェクションを使用すると、1 つのエンティティのプロパティのうち、いくつかの必要なプロパティだけをクエリ結果に含めることができるので、この例ではプロジェクションが役立ちます。

OData エコシステムの価値をご理解いただけるように、Web アプリケーションを作成します。このアプリケーションを使用すると、ユーザーは架空の不動産会社 Contoso Ltd. のサイトを閲覧して、Contoso が管理する物件のリスティングを確認することができます。

リレーショナル データ

Contoso.com Home Finder アプリケーションの主要なデータ ソースは SQL Server データベースで、このデータベースには、Contoso が管理している物件すべてに関する情報、および Contoso がこうした物件用に発行した (現在販売中の物件と以前に販売されていた物件の) リスティングすべてに関する情報が格納されています。

.NET Framework 3.5 SP1 で WCF Data Services と ADO.NET Entity Framework がリリースされてから、リレーショナル データベースを OData フィードとして公開するのは簡単になりました。必要なものは、リレーショナル データから作成された Entity Framework モデルだけです。OData フィードは HTTP ベースなので、サービスをホストする Web サイトまたは Web サービスが必要です。

リレーショナル データから OData フィードを作成するには、まず、OData サービスをホストする ASP.NET Web アプリケーションを Visual Studio 2010 で作成します。Visual Studio で、[ファイル] をクリックし、[新規作成] をポイントし、[プロジェクト] をクリックします。次に、[ASP.NET Web アプリケーション] をクリックします。OData フィードをホストするために使用できる Web サービスのスケルトンが作成されます。

Web サービスの作成と構成が済んだら、OData フィードによって公開される Entity Framework データ モデルを作成します。Visual Studio では、[新しい項目の追加] ウィザードを使用して簡単にこれを行うことができます。このウィザードでは、既存のデータベースからモデルを自動生成することができます。図 1 は、[新しい項目の追加] ウィザードを使用して、Contoso が管理している物件とリスティングで構成された SQL Server データから作成された単純なデータ モデルを示しています。

image: The Entity Framework Data Model for the Relational Data図 1 リレーショナル データの Entity Framework データ モデル

では、このデータ モデルを OData フィードとして公開する WCF Data Service を作成しましょう。Visual Studio では、[新しい項目の追加] ウィザードの [WCF Data Service] オプションを使用することで、これも簡単に行うことができます。このオプションを選択すると、Data Service の構成に使用されるコード ファイルが作成されます (この例では、ファイルの名前は Listings.svc.cs です)。

図 2 は、WCF Data Service を定義する方法を示しています。Listings クラスは Data Service を公開するサービス クラスで、ジェネリック DataService<T> を実装します。図 2 で DataService<T> の定義に使用されている型は ListingsEntities 型です。これは、図 1 で作成された Entity Framework コンテキストです。このクラスは Entity Framework コンテキストを受け取るので、この方法を使用すると、リレーショナル データを公開する WCF Data Service をすばやく簡単に機能させることができます。ただし、DataService クラスは、Entity Framework コンテキストしか操作できないわけではありません。
DataService クラスは、IQueryable インターフェイスが実装されている限り、CLR オブジェクトのどのようなコレクションでも受け取ることができます。.NET Framework 4 では、WCF Data Services 用の新しいカスタム プロバイダー モデルが追加されました。このモデルを使用すると、ほぼどのようなデータ ソースからでもサービスを作成することができます。

図 2 WCF Data Service を定義

// 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;
  }
}

図 2 の InitializeService メソッドが他にどのような処理を行っているのかをもう少し詳しく見てみましょう。このメソッドでは、サービスが公開するエンティティ セットの両方に関して SetEntitySetAccessRule を呼び出して、アクセス権を AllRead に設定しています。これにより、両方のエンティティ セットを完全に読み取り可能にし、なおかつ挿入、更新、削除は許可しないように、サービスに指示することができます。これは、サービスへのアクセスを制御する優れた方法です。WCF Data Services は、クエリ インターセプターと呼ばれる手法もサポートしています。この手法を使用すると、サービス作成者は、エンティティ セットごとにサービスへのよりきめ細かいアクセス制御を構成することができます。Listings.svc ファイルをプロジェクトのスタート ページに設定し、プロジェクトを実行します。ブラウザー ウィンドウが開き、サービス ドキュメントが表示されます (図 3 参照)。

image: Service Document for the SharePoint Site図 3 SharePoint サイト用のサービス ドキュメント

OData の URI 規則

サービス ドキュメントでは、サービスによって公開されるエンティティ セットが一覧表示されます。必要に応じて OData プロトコルの一部として定義される強力な URI 構文を使用して、このサービスのリソースにアクセスできることを思い出してください。このサービスの URI 構文を簡単に見てみましょう。各エンティティ セットのフィードにアクセスするには、サービスのベース URI の末尾にそのエンティティ セットの名前を追加します。たとえば、http://myhost/Listings.svc/Properties を指定すると、Properties エンティティ セットの一連のエンティティにアクセスすることができます。

キー値を使用して特定のエンティティに個々にアクセスすることも可能です。http://myhost/ Listings.svc/Properties(0) という URI を指定すると、ID が 0 の物件にアクセスすることができます。URI の末尾にリレーションシップの名前を追加すると、このエンティティから別のエンティティまたはエンティティ セットへのリレーションシップを指定することができます。したがって、http://myhost/ Listings.svc/Properties(0)/Listings を指定すると、ID が 0 の物件エンティティに関連付けられたリスティングのセットにアクセスすることができます。この構文を使用すると、さまざまなレベルのリレーションシップ間を移動することができます。

URI 構文では、ベース クエリになんらかの変更を加えるために URI の末尾に追加することができるいくつかのクエリ オプションも定義されています。各クエリ オプションは名前と値のペアとして定義されます。たとえば、$top=10 というクエリ オプションを追加すると、クエリが結果内の最初の 10 項目のみに制限されます。図 4は、URI 構文で使用できるすべてのクエリ オプションを示しています。

図 4 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 のデータを公開する

前のセクションでは、リレーショナル データベースに格納されたデータ (不動産 Web サイト用の物件とリスティングの情報) を公開する方法について説明しました。物件を販売している不動産仲介業者に関する情報もありますが、このデータは SharePoint サイトに格納されているとします。Microsoft SharePoint 2010 では、すべてのリスト、およびこのようなリストに含まれるすべてのドキュメントを OData フィードとして公開することができます。これは不動産サイトにとってすばらしいことです。会社の従業員が登録した仲介業者情報を、構築中のリスティング アプリケーションに含めることができる OData フィードとして利用できるということだからです。このデータの登録や更新のプロセスで SharePoint インターフェイスを使用するユーザーは、このアプリケーションに合わせてワークフローを変更する必要はありません。会社の SharePoint サイトに登録されたデータは、作成中のリスティング アプリケーションにリアルタイムで提供されます。

図 5 は、不動産仲介業者が連絡先情報の登録や更新に使用する単純な SharePoint ポータルを示しています。

image: SharePoint Site for Agent Information図 5 仲介業者情報用の SharePoint サイト

.NET Framework 3.5 SP1 用の ADO.NET Data Services 更新プログラムを SharePoint システムにインストールすると、リスト データを OData フィードとして公開する各サイトで新しい HTTP エンドポイントを利用できるようになります。OData フィードは、HTTP を使用してアクセスされるので、Internet Explorer を使用して調査することができます。図 6 は、SharePoint の仲介業者リストのフィードを示しています。

image: Agents Feed from the SharePoint Agent Service図 6 SharePoint の仲介業者サービスの仲介業者フィード

OGDI の参照データを使用する

既定では、OData フィードはフィードの ATOM 表現を返し、Web ブラウザーからアクセスすると、結果は ATOM フィードとなります。要求の accept ヘッダーを "application/json" に変更すると、結果は同じデータが JSON フィードとして表現されたものとなります。

図 6 のフィードは、エンティティのセットを表す <feed> 要素で始まっています。各 feed の中には、一連の <entry> 要素があります。各 <entry> 要素はフィード内の 1 つのエンティティを表します (フィード全体が 1 つの画面内に収まるように、最初の 3 つの entry 要素は折りたたまれています)。

この例では、エンティティには同時実行トークンが定義されているため、フィード内の各エンティティには etag プロパティがあります。etag は、要求されたエンティティに変更が加えられた場合に同時実行制御チェックを実施するために、データ サービスによって使用されるトークンです。<entry> タグを使用して形式設定された各エンティティは、エンティティを編集する際に使用されるリンクとエンティティのリレーションシップの両方を含む一連のリンクで構成されています。各リレーションシップ リンクは、別のエンティティまたはエンティティのセットを示しています (これらはそれぞれ、参照プロパティ、ナビゲーション プロパティと呼ばれます)。各 <entry> 要素の中には <m:properties> 要素もあり、<m:properties> 要素の中にはエンティティのプリミティブ型および複合型のプロパティがあります。プロパティ値は、エンティティのプロパティの名前とそのプロパティの値で構成されています。

Open Government Data Initiative (OGDI) は Microsoft Windows Azure Platform を基盤として構築されたサービスで、これを使用すると、政府機関はさまざまな公的データをより簡単に公開することができます。OGDI プロジェクトでは、政府機関がデータの公開に使用できるスタート キットが提供されています。たとえば、エドモントン市は行政データを公開するためにスタート キットを導入しました。また、ogdisdk.cloudapp.net (英語) のサービスでは、ワシントン D.C. エリアに関するさまざまなデータのデータ セットが提供されています。もう 1 つの例は、データ セットを使用すればだれでも簡単にデータをサービスとして Web に公開できるようにすることを目標とする Microsoft コードネーム "Dallas" プロジェクトです。このプロジェクトも Windows Azure Platform を基盤として構築されており、OData を使用してデータが公開されます。これらは、Web アプリケーションでさらに使用できる大規模な参照データ セットを公開する大規模なサービスの例です。後で示すように、こうしたサービスで OData を使用してデータを公開すると、さまざまなアプリケーションからそのデータを簡単に使用することができます。

前述のとおり、OGDI Web サイトでは、ワシントン D.C. エリアに関するデータが一般公開されて提供されています。Contoso の不動産アプリケーションはこのエリアのリスティングを閲覧するのに使用されるので、特定の物件を確認する際、その物件の周辺エリアに関してこの参照データの一部が提供されると、ユーザーの役に立つでしょう。サンプル アプリケーションのクライアントの作成について説明するところで、OGDI Web サイトの OData フィードをこのアプリケーションのデータ ソースの 1 つとして含める方法を紹介します。

他の OData プロデューサー

ここまでのところで、SQL Server、SharePoint、および Web 上で一般公開されている OData サービスのデータを使用する例を紹介しましたが、選択肢は他にもあります。クラウド ベースの Windows Azure Platform には、Windows Azure テーブルに格納されているデータを公開するテーブル サービスがあり、そのための API は OData を使用して構築されています。前述のとおり、Microsoft Dallas プロジェクトは、Dallas サービスによって公開されるデータの検索と照会を行うためのデータ マーケットプレースであり、このサービスでは、OData プロトコルを使用してデータが公開されます。また、OData プロデューサーはマイクロソフト製品だけに限定されません。IBM は、WebSphere eXtreme Scale 7.0 製品が OData プロトコルをサポートするようになったことを最近発表しました。

Silverlight クライアント

Contoso の不動産検索アプリケーションでは、Contoso が管理している不動産リスティングと物件に関する SQL Server のリレーショナル データを公開する ASP.NET Web サービス、仲介業者に関するデータの管理に使用されている SharePoint サイト、および Contoso が宣伝している物件の周辺の地域に関するデータを公開する政府の Web サービスを使用できるようになりました。これらのソースすべてを、有意義な方法でこのデータを処理できる 1 つの Silverlight アプリケーションにまとめたいと思っています。

Silverlight 3 では、Silverlight SDK に WCF Data Services クライアント ライブラリが含まれているため、Silverlight アプリケーションで OData 対応のサービスと通信するのは簡単です。これを行うには、Visual Studio で、Silverlight プロジェクトを右クリックし、[サービス参照の追加] をクリックします。表示される指示に従うと、サービス参照を作成することができます。サービス参照を作成するために必要な主な情報は、Silverlight アプリケーションから参照されているサービスの URI です。図 7 は、OGDI サンプル サービスへのサービス参照を追加する例を示しています。

image: Add Service Reference for the OGDI Sample Service図 7 OGDI サンプル サービスへのサービス参照を追加

サービス参照ウィザードを実行すると、データ サービスとのやり取りに使用されるクライアント側コンテキスト クラスが作成されます。クライアント コンテキストによって、HTTP や URI の使い方の詳細はクライアント プログラミング モデルから分離され、クライアント開発者は C# クラスと XAML のことだけ考えることができるようになります。クライアント コンテキストには LINQ プロバイダーの実装も含まれるため、プロキシに対する LINQ クエリがサポートされます。[サービス参照の追加] ウィザードを実行すると、参照されているサービスによって公開される型を反映した一連のクライアント プロキシ クラスも生成されます。OGDI サービス参照を作成したら、作成した SharePoint サービスとリスティング サービスの両方へのサービス参照も作成します。次のコードは、3 つの 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 でこのアプリケーションをホストします。

image: The Contoso Home Finder
図 8 Contoso Home Finder

図 9 は、リスティング サービスに照会し、結果を Home Finder Silverlight アプリケーションの上部にあるグリッドにバインドするためのコードを示しています。

図 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 メソッドを呼び出すことによって、グリッド内の変更をサービスに保存することができます。

Silverlight では、すべてのネットワーク呼び出しは非同期で実行されるので、WCF Data Services クライアント ライブラリを使用してサービスに対する操作を実行するには、最初に操作を呼び出してから、非同期呼び出しの結果を処理するためにメソッドに渡される別個のコールバック メソッドを記述する必要があります。この非同期処理をより簡単にするために、DataServiceCollection クラスに LoadAsync というメソッドが追加されました。非同期コールバック関数を処理して結果をコレクションに読み込むという処理すべてがこのメソッドで行われます。

図 9 のコードでは、LoadAsync が呼び出される前にコレクションがグリッドにバインドされており、非同期呼び出しが完了するまで値はコレクションに読み込まれません。サービスから結果が返されるとコレクションはコレクション変更イベントを発生させ、非同期呼び出しが完了するとグリッドはこうしたイベントをキャッチして結果を表示します。

データ グリッドからリスティングが選択されたら、そのリスティングを管理している仲介業者に関する情報を取得するために SharePoint サイトに照会する必要があります。このアプリケーション アーキテクチャでは、第 2 のクエリが必要です。リスティング用のデータ ソースと仲介業者用のデータ ソースが異なり、2 つの間には明確な関係がないからです (モデルの観点から説明すると、この例では 2 つの完全に別個のモデルが使用され、2 つのモデル間の関係はクライアントによって作成および強制される人為的なものです)。

図 10 は、仲介業者の名前に基づいて、仲介業者エンティティを取得するために SharePoint サービスに照会する方法を示しています。Home Finder ページの下部にあるグラフで示されている近隣の統計データを取得するために OGDI データに照会する際にも、同様のコード シーケンスが使用されます。今のところ、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();
        }
    });
}

PowerPivot での OData の使用

PowerPivot は、Microsoft Excel 2010 用のアドインとして提供される、新しいメモリ内ビジネス インテリジェンス ツールです。詳細については、powerpivot.com (英語) を参照してください。このツールを使用すると、データ ソースから大規模なデータ セットをインポートしたり、複雑なデータ分析やレポートを実行したりすることができます。PowerPivot では、さまざまなデータ ソースからデータをインポートすることができます。OData フィードから直接インポートすることも可能です。PowerPivot の [外部データをデータ フィードから取得] オプション (図 11 参照) では、インポートするフィードの場所として OData サービス エンドポイントを指定する必要があります。

image: PowerPivot Imports from an OData Feed図 11 PowerPivot での OData フィードからのインポート

図 12 は、OGDI のワシントン D.C. データ フィードの犯罪統計の概要を基にして作成されたグラフを示しています。

image: PowerPivot Chart from OData Feed図 12 OData フィードを基にして作成された PowerPivot グラフ

前の例の不動産アプリケーションと同じデータ セットを使用して作成された図 12 のグラフは、全データの集計を地区ごとに示しています。PowerPivot for Excel 2010 をダウンロードして OGDI サイト (ogdi.cloudapp.net/v1/dc、英語) からデータをインポートし、このデータに対する充実したデータ分析をどれほど簡単に行うことができるか自分で確かめてみることをお勧めします。

Open Data Protocol Visualizer

OGDI データ サービスによって公開されるデータを使用するアプリケーションを作成する外部の開発者にとって、OGDI データ サービスは基本的に "ブラック ボックス" です。さいわい、OGDI サービスのデータは OData プロトコルを使用して公開されるので、OGDI サービスの内部の詳細について知らなくても、OGDI サービスとやり取りすることは可能です。OGDI サービスのプログラミング モデルは OData プロトコルです。サービス エンドポイントはデータの構造を表現します。前のセクションで説明したように、サービスとやり取りするために必要なのはそれだけです。ただし、サービスのデータの構造を確認し、サービスの構成要素間の関係をより深く理解すると、役に立つことがよくあります。Open Data Protocol Visualizer は、まさにこのために作成されました。Open Data Protocol Visualizer は、Visual Studio 2010 の [ツール] メニューの [拡張機能マネージャー] から入手することができます。図 13 は、OGDI サービスの構造を表す、ビジュアライザーの 2 つの図を示しています。

図 13 の上部の図は、サービス全体を示しています。下部の図は、上部の図に含まれるボックスのうち 4 つだけを拡大して示したものです。ビジュアライザーでは、エンティティ セットはボックスとして表現され、エンティティ間のリレーションシップはボックスを結ぶ線として表現されます。図 13 の上部の図を見ると、OGDI サービスが完全にフラットで、リレーションシップをまったく含まないことは明らかです (ボックスを結ぶ線がまったくないため)。これは単に OGDI サービスの特性にすぎず、ほとんどの OData サービスにはこのような特性はありません。下部の図は、OGDI サービスのエンティティ セットのうち 4 つを拡大したものです。この図を確認すると、このサービスでは消防署、小学校の出席、透析クリニック、および政府機関の場所に関するデータが公開され、これらの種類それぞれについてプロパティとキーも公開されることがわかります。

image: Open Data Visualizer Views of the OGDI Sample Service図 13 Open Data Protocol Visualizer による、OGDI サンプル サービスの図

詳細

この記事では、Open Data Protocol 、およびその周りに構築されたエコシステム (WCF Data Services Framework など) を紹介しました。詳細については、Open Data Protocol の Web サイト (odata.org、英語) を参照してください。WCF Data Services の詳細については、msdn.microsoft.com/data/bb931106 または WCF Data Services ブログ (blogs.msdn.com/astoriateam、英語) を参照してください。

Shayne Burgess はマイクロソフトのデータおよびモデリング グループでプログラム マネージャーを務めており、特に WCF Data Services と Open Data Protocol を担当しています。Burgess は、WCF Data Services チームのブログ (blogs.msdn.com/b/astoriateam、英語) でたびたび記事を書いています。

この記事のレビューに協力してくれた技術スタッフの Elisa Flasko と Mike Flasko に心より感謝いたします。