Microsoftの戦略的クラウド「Azure（アジュール）」を見る【第三回】

　.NET Servicesは、Azureで提供されているサービス群だ。オンプレミスのサーバーやサードパーティが提供しているサービスとAzureなどのクラウドサービスを接続して連携して動かすための「サービスバス」、各サービスに対してのアクセス権を設定する「アクセスコントロールサービス」、Azure上のサービスやサードパーティ、オンプレミスのサーバー上で提供されているサービスを連携させる「ワークフローサービス」などで構成されている。今回は、この.NET Servicesを説明する。

■ サービスバス

サービスバスは、オンプレミスやほかのクラウドのサービスを接続する時に利用する

　Azureは、クラウド上に構築されたサービスだけでなく、オンプレミス（社内）のサーバー上で構築されているサービスと連携して動作することができる。とはいえ、オンプレミスのサービスとAzureが接続するには、オンプレミスのサーバーのIPアドレスなど、接続先の情報が必要になってくる。また、オンプレミスのサーバーは、NATやファイアウォールなどのより強固なセキュリティに守られていることもある。このため、Azure側から簡単にアクセスすることはできない。

　そこで、サービスバスでは、Azureが特定のサービスに関する固定的な情報をスタティックに保持するのではなく、オンプレミスのサーバーがAzureに接続してきたとき、毎回サービスを公開する情報をAzureに登録するようなダイナミックなシステムを採用している。

　まず、オンプレミスのサーバーがAzureに接続しない限り、サービスは登録されない。このため、ファイアウォールで問題になるインバウンドポートの公開を行わなくてもいい。つまり、オンプレミスのサーバーからアウトバウンドでAzureに接続して、そのセッションを使って通信を行うようになっている。また、NATなどでIPアドレスがプライベートアドレスになっているサーバーにも、アウトバウンドの通信でセッションを使うため、グローバルIPアドレスが個々に付与されていなくてもAzureとの通信が行える。

サービスバスは、ネーミング、サービスレジストリ、メッセージングの3つの機能で構成されている

　サービスバスでは、オンプレミスのサービスの接続先名などを設定する「ネーミング」、Azureに公開するサービスを登録する「サービスレジストリ」、実際にクライアントとオンプレミスのサービスにメッセージを転送するための「メッセージング」の3つの機能が提供されている。

　特に、メッセージングはWindows VistaやWindows Server 2008から正式に搭載されたWindows Communication Foundation（WCF）が利用されている。WCFを利用するには、.NET ServicesのSDKを利用するのが簡単だが、JavaやRuby用のSDKも公開されている。

　サービスバスでは、Azureを経由した接続形態だけでなく、クライアントとサービス側でサポートしているなら、Azureを経由せず、直接クライアントとサービスを接続して、動作する仕組みも用意されている。


ネーミングにより、オンプレミスのサービスを接続させる	サービスレジストリを使って外部のサービスが、Azure上に登録される	メッセージングの内容。プログラミングとしては、WCFが使われる

■ アクセスコントロールサービス

アクセスコントロールサービスの仕組み

Azureは、クレームベースの認証を採用している

　クラウドでサービスを提供する場合、最も重要になるのがアクセス権限の管理だろう。Azureでは、Live IDやActive Directoryなどのアクセス権限管理のシステムが利用できる。サービスごとにアクセス権限の管理を行っているテクノロジーとして、クレームベースのIDフェデレーションが採用されている。これが、アクセスコントロールサービスだ。

　アクセスコントロールサービス自体では、アクセス権限の発行は行わない。このため、Live IDやActive Directoryなど、さまざまなID認証システムと連携するようにできている。つまり、一度ID認証システムでアクセス権限が確認されれば、各サービスにアクセスするときにクレームを使うことで、各サービスでいちいち認証確認を取らなくても、アクセスできるような信頼関係に基づいたシステムになっている。

　例えば、セキュリティがかかっているサービスにクライアントがアクセスする場合、まずサービス（Relying Parties：RP）側から、自分が必要とするセキュリティトークンの内容をクライアントに要求する。具体的には、利用できるユーザーIDの種類、ユーザー名、会社名など、さまざまな情報がある。

　RPからのリクエストを受信したクライアントは、クレームをアクセスコントロールサービスアカウントに送信する。クレームには、ユーザーに関する情報が入っている。例えば、ユーザーID、会社情報、役職、所属といったものが入っている場合もある。もちろん、これらの中の一部だけでもOKだ。さらに、Windows VistaやWindows Server 2008に搭載されているID管理システムのカードスペースをクレームとして利用することもできる。

　クライアントからのクレームを受信したアクセスコントロールでは、自分が持っているルールにしたがって、セキュリティトークンを作成し、クライアントに返信する。その後、クライアントは、アクセスしたいサービスにセキュリティトークン付きのメッセージを送信して、無事アクセス可能となる。

　このような仕組みにより、公開されている個々のサービスには、アクセス権限の管理の仕組みは必要ない。サービスは、どのアカウントコントロールと信頼しているかだけが明示されていれば、実際のユーザー管理は、Live IDやActive Directoryなどのユーザー管理システムに任せられる。このような仕組みは、Active Directoryの信頼関係と少し似ている。


アクセスコントロールサービスのアーキテクチャ	アクセスコントロールの手順	クレームベースのアクセスコントロールにより、さまざまなサービスと連携することができる

Genevaの概要

　もともと、こういったクレームベースの認証システムは、Windowsサーバー上で開発されていたGeneva（開発コード名）というユーザー認証システムをクラウドにまで拡張したものだ。このため、Geneva Serverは、Windows Server 2008 R2に搭載される次期Active Directoryフェデレーションサービス（AD FS）に採用されている。また、Windows 7やWindows Server 2008 R2には、GenevaバージョンのカードスペースやGenevaを扱うためのフレームワークなども搭載されている。これにより、クライアントとサーバーを含めて、クレームベースのIDモデルを構築している。

　また、Genevaを利用することで、Azureでは、Live IDやActive Directory以外にも、Open IDなど、さまざまなID認証システムを使用することができる。さらに、オンプレミスにあるActive DirectoryサーバーにMicrosoft Service Connectorをインストールすることで、オンプレミスのActive DirectoryをAzureの認証システムとして使用することができる。


Geneva上では、複数のIDシステムと連携して動作することができる	GenevaとMicrosoft Federation Gatewayを利用すれば、社内のActive DirectoryとLive IDを連携させることもできる	Genevaを利用しなくても、社内のActive DirectoryにMicrosoft Services Connectorをインストールすれば、Microsoft Federation Gatewayを経由してLive IDと連携することができる

■ ワークフローサービス

ワークフローサービスの概要

ワークフローサービスの開発から展開まで

　ワークフローサービスは、クラウド上で個々のサービスを連携（オーケストレーション）して動かすための仕組みだ。つまり、MicrosoftがAzure上で提供しているサービス、サードパーティがAzure上で提供しているサービス、自社開発でオンプレミスに構築されているサービスなどをつなげて、クライアントに提供するアプリケーションを構築するときに、どのように個々のサービスを接続して、どういった条件の時に分岐していくかなどのワークフローを動かすためのインフラだ。

　ワークフローサービスは、Windows VistaやWindows Server 2008で採用されたWorkFlow Foundationがベースとなっている。

　開発者は、Visual StudioのWFデザイナーを使って、フローチャートを作成し、そのデータをルールXAMLとして出力する。Azureでは、ルールXAMLを受け取って、Azure上のサービスをワークフローにしたがって動作させる。

　ちなみに、Azureでは、Windows 7やWindows Server 2008 R2で採用されるWorkflow Foundation 4.0（Windows VistaやWindows Server 2008はWorkflow Foundation 3.5）を使用している。Workflow Foundation 3.5は、逐次処理をステートマシンで実装していたため、ネスト関連などに制限があった。しかし、Workflow Foundation 4.0では、フローチャートで実装がされているために、制限が取り払われている。これ以外にも、実行ロジックの高速化など、いろいろな部分でWorkflow Foundation 3.5の問題点が解消されている。

　Microsoftでは、Workflow FoundationやWCFの実行を管理するためのサーバーシステムのDublin（ダブリン：開発コード名）を開発している。Dublinは、実体としては、IIS/WASをベースにしたアプリケーションサーバーだ（リリース時期は、Visual Studio 2010リリース直後）。

　また、ワークフローベースのサービス構築が容易にできるように、モデル駆動型の開発ソリューションとなるOslo（オスロ：開発コード名）の開発も進めている。Osloは、新しいモデリング言語「M」を使うことで、今までのプログラミング言語とはまったく違う開発ソリューションを提供する。


ワークフローの実行・管理システムのDublin	Dublinの構成図	Dublinのサービスアプリケーションの実行・管理

（山本雅史）
2009/03/25 08:56

Enterprise Watch ホームページ