Enterprise Watch
バックナンバー

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

サービスバスを実現する.NET Services

.NET Servicesは、サービスバス、アクセスコントロールサービス、ワークフローサービスの3つで構成されている。将来的には、サービスが増えることもある
 .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のサービスアプリケーションの実行・管理

関連記事
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第一回】(2009/03/23)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第二回】(2009/03/24)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第四回】(2009/03/26)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【最終回】(2009/03/27)


( 山本 雅史 )
2009/03/25 08:56

Enterprise Watch ホームページ
Copyright (c) 2009 Impress Watch Corporation, an Impress Group company. All rights reserved.