April 2009
Volume 24 Number 04
クラウド コンピューティング - .NET Services で分散アプリケーションを構築する
Aaron Skonnard | April 2009
この記事は、.NET Services のプレリリース版に基づいて書かれています。ここに記載されているすべての情報は、変更される場合があります。
この記事では、次の内容について説明します。
|
この記事では、次のテクノロジを使用しています。 Azure Services Platform、.NET Services |
目次
.NET Services
.NET Services の内容
.NET Services ソリューションを作成する
.NET Services SDK をインストールする
.NET Access Control Service
サービスを構成する
.NET Service Bus
.NET Service Bus を使用して通信する
.NET Workflow Service
クラウド ワークフローを構築する
2008 年の Professional Developers Conference (PDC) はロサンゼルスで行われ、そこではその後の数年間に発表される野心的な新しいクラウド コンピューティング戦略が発表されました。Microsoft のクラウド プラットフォーム (正式な名前は Azure Services Platform) は、.NET 開発者が既に使い慣れているのと同じツールと API を使用して、アプリケーション (またはアプリケーションの一部) をクラウドに簡単に移行できるようにするものです。
Windows Azure は、Microsoft クラウド プラットフォームの基盤を提供します。Windows Azure は Windows ベースのクラウド オペレーティング システムと考えることができます。世界中での .NET アプリケーションの実行と Microsoft データ センターへのデータの格納のための、優れた拡張性を備えた実行環境を提供します。Windows Azure でアプリケーションを構築することにより、ユーザーはアプリケーションの中でもコストがかかり問題の発生しやすいインフラストラクチャに関する多くの側面に対処する必要がなくなり、開発と業務に集中できます。
Microsoft からは、.NET Services、SQL Services、Live Services、SharePoint Services など、Windows Azure の基盤に組み込まれた複数のサービス製品が提供されています。これらのサービス製品と Windows Azure の基盤を組み合わせることで、完全な Azure Services Platform が構成されます (図 1 を参照)。各サービス製品に含まれる複数の個別サービスから、アプリケーションで利用するサービスを選択できます。Microsoft では、Windows Live、Microsoft Office Live、Microsoft Exchange Online、Microsoft SharePoint Online など、さまざまなコンシューマ向けアプリケーションにおいて、Azure Services Platform への対応を積極的に進めています。同じように、ユーザーは Azure サービスがもたらす価値を活用できます。
図 1 Azure Services Platform
この記事では、2008 年 11 月/12 月の CTP リリースを基にして、Azure Services Platform で提供される .NET Services について詳しく説明します。図 1 からわかるように、.NET Services は広範なクラウド プラットフォームの 1 つの小さな要素にすぎませんが、クラウドに移行しようとしている .NET 開発者には特に興味のある部分の 1 つです。
.NET Services
Windows Communication Foundation (WCF)、Windows Workflow Foundation (WF)、BizTalk Server などのテクノロジを使用する Microsoft 接続システムの開発者は、.NET Services に特に注意を払う必要があります。.NET Services には、Azure Services Platform の中で注目する必要があるテクノロジのほとんどが含まれています (興味深いことに、開発プロジェクトでのもともとの名前は "BizTalk Services" であり、正式な名前 .NET Services は Windows Azure と共に PDC において発表されました)。
Windows Azure を "クラウド用の Windows" と考えるなら、.NET Services は "クラウド用の Microsoft .NET Framework" と考えることができます。今日、.NET 開発者は、Windows プラットフォーム向けアプリケーションの開発において .NET Framework に大きく依存しています。.NET Framework は多くのアプリケーションで必要な共通の構成要素を提供し、アプリケーションを短時間で開発して稼働させることが簡単にできるようにしています。.NET Services は、クラウド ベースのアプリケーションを簡単に作成できるようにする共通の構成要素を提供することで、Azure Services Platform において同じような役割を果たしています。
.NET Framework と .NET Services の間には、類似点もありますが大きな相違点もあります。.NET Framework は構成要素を .NET アセンブリの形式で提供しますが、.NET Services は Microsoft データ センターの中で動作するホストされたサービスという形式で構成要素を提供します。.NET Services を使用するとき、オンプレミス ロジックとクラウド内で動作する .NET Services の間には明確な境界があります。これらのサービスをビジネス ソリューションに組み込むのはユーザーの作業です。Microsoft は、アプリケーションが依存するホストされたサービスのホスト、管理、保守を行います。
.NET Services のプログラミングは、.NET Services が提供する個別のサービスと統合することで行います。名前は ".NET" Services ですが、実際に .NET を使用する必要はありません。.NET Services との統合は、.NET Services が公開する標準の SOAP および REST インターフェイスを使用して行うことができます。Microsoft からは .NET 開発者の環境を最適化する .NET Services SDK が提供されており、コミュニティからは Java や Ruby の SDK を入手することさえできます。
.NET Services の内容
アプリケーションをクラウド プラットフォームに移行する方法を考えるとき、ほとんどの場合に必要になる一般的な要件がいくつかあります。1 つ目の要件として、ビジネス プロセスつまりワークフローをクラウドで実行および管理できるように記述してパッケージ化するための手段が必要です。2 つ目の要件として、クラウド ベースのワークフローとオンプレミス アプリケーションの間で、途中にあるファイアウォールやネットワーク アドレス変換 (NAT) デバイスを通して通信するための方法が必要です。3 つ目の要件として、通信を保護し、さまざまなクラウド ベース リソースへのアクセスを制御するための手段が必要です。
ほとんどのクラウド アプリケーションでは、これらの要件の少なくとも 1 つに対処する必要があります。この種のインフラストラクチャを自分で構築する必要があるとすると、全体的な価値提案は大きく変わることでしょう。このような部分こそ、2008 年 11 月/12 月の CTP バージョンで .NET Services が対象としている領域です。
具体的には、.NET Services は、クラウド インフラストラクチャに関するこれらのニーズを、3 つの異なる構成要素サービスによって実現します。つまり、.NET Workflow Service、.NET Service Bus、および .NET Access Control Service です (詳細については図 2 を参照)。
| 図 2 .NET Services のコンポーネント |
| サービス | 説明 |
| .NET Workflow Service | このコンポーネントは、Azure Services Platform の中の WF ワークフローをホストおよび管理するためのインフラストラクチャを提供します。また、実行中ワークフローのインスタンスを展開、管理、追跡するクラウド中心のアクティビティとツールも提供します。 |
| .NET Service Bus | このコンポーネントは、組織の境界を越えてクラウド内の接続を確立できるようにするリレー サービスを提供します。この重要なインフラストラクチャにより、クラウド ベースのワークフローは、ファイアウォールや NAT デバイスを通過してオンプレミス アプリケーションと通信できます。 |
| .NET Access Control Service | このコンポーネントは、クラウド内で、WS-Security 機能で構成される要求ベースのアクセス制御メカニズムを提供します。また、Active Directory や Windows Live ID などの ID プロバイダとの相互運用性など、ほとんどのクラウド シナリオに固有のフェデレーション要件も満たします。 |
.NET Service Bus は、.NET Access Control Service を利用して、送信者とリスナの両方によるリレー サービスへのアクセスを制御します。つまり、すべての送信者とリスナは、先に .NET Access Control Service からトークンを取得してからでないと、.NET Service Bus を使用できません。.NET Workflow Service は .NET Service Bus と統合することで、リレー サービスを通してメッセージを送信できるようにし、クラウド ベースのワークフロー内でのさまざまな興味深い通信シナリオを可能にします。これらのサービスが連携して、クラウドのアプリケーションを構築するための強力な開発構造を提供します。
.NET Services ソリューションを作成する
.NET Services の利用を開始する前に、Azure Services Platform ポータルにアクセスしてソリューションを作成する必要があります。この記事は 2008 年 11 月/12 月の CTP リリースに基づいており、.NET Services ソリューションを作成するには招待トークンが必要です。招待トークンは Azure Services Platform ポータルの [Try it now] のリンクに従って入手できます。Windows Azure と .NET Services では異なる招待トークンが必要なので、.NET Services のトークンも忘れずに要求してください。承認が済むと、電子メールで .NET Services の招待トークンが送付されます。
招待トークンを受け取ったら、ポータル内の .NET Services エリアにアクセスして新しいソリューションを作成できます。有効な招待コードを入力してソリューション名を指定する必要があり、それが済むと新しい .NET Services ソリューションが準備されて、ソリューションのパスワードが提供されます (ソリューション名が認証用のユーザー名として使用されます)。
準備プロセスでは、新しいソリューションとユーザーのアカウントを関連付けることができるように、Windows Live ID (WLID) を使用してサインインするように求められます。複数のソリューションを 1 つの WLID と関連付けることができますが、ソリューションごとに固有の招待コードが必要です。WLID を使用してポータルにログインするたびに、ページの右側の [マイ ソリューション] にすべてのソリューションが一覧表示されます。特定のソリューションを選択すると、そのソリューション内の .NET Services のさまざまな部分を管理するためのページに移動します (図 3 を参照)。
図 3 ソリューションの管理
ソリューションは基本的に、.NET Services のさまざまな面を管理するための最上位のコンテナです。たとえば、.NET Service Bus のエンドポイント、.NET Workflow Service のタイプとインスタンス、.NET Access Control Service の ID と要求の変換ルールなどのコンテナです。
.NET Services SDK をインストールする
.NET Services SDK をダウンロードしてインストールする必要もあります。これも Azure Services Platform ポータルから入手できます。SDK をインストールすると、いくつかの .NET アセンブリ、および .NET Services とのプログラムでの統合を容易にする Visual Studio アドインがマシンに追加されます。
新しいアセンブリはインストール ディレクトリにあります。インストール ディレクトリの既定の場所は \Program Files\Microsoft .NET Services SDK です。重要なアセンブリは、Microsoft.ServiceBus.dll、Microsoft.Workflow.Activities.dll、および Microsoft.AccessControl.Management.dll です。インストール ディレクトリには、各サービスの使用方法および各サービスが提供する重要な機能を紹介するサンプルも含まれます。作業を始める前に、さまざまなサンプルを確認してください。
Visual Studio を起動すると、CloudSequentialWorkflow という名前の新しいプロジェクト テンプレートが追加されていることもわかります (CloudWorkflow プロジェクト タイプの下)。.NET Workflow Service でホストする WF ワークフローを作成するには、このプロジェクト テンプレートを使用します。SDK をインストールすると、.NET Workflow Service へのワークフローの展開を容易にする Visual Studio アドインもインストールされます。
興味深いことに、.NET Services の実装は、実際には .NET Framework 3.5 の WCF と WF から派生します。.NET Services SDK は、この WCF と WF の相乗効果を基盤として、WCF と WF のプログラミング モデルに既に慣れているコンシューマ開発者の環境を可能な限りわかりやすくします。そのような開発者は、.NET Services のプログラミングの構造を非常に自然なものに感じるはずです。最終的に主な問題となるのは、いくつかの新しい WCF バインド (.NET Service Bus に対するもの) を覚え、これらのバインドを構成し、新しいアクティビティ (.NET Workflow Service に対するもの) をいくつか理解することです。
以降では、各サービスについて簡単に説明し、それぞれの使用例を見ていきます。読み終えるまでには、抵抗なくサービスを使い始めることができるようになっているでしょう。
.NET Access Control Service
最初に .NET Access Control Service について説明します。過去数年間、Microsoft は要求ベースの ID モデルに移行してきました。このモデルを使用すると、認証と承認の決定をアプリケーションから取り除いて、セキュリティの専門家による集中管理が可能な外部サービスに移すことができます。このモデルでは、セキュリティの専門家がユーザーの認証プロセスを管理し、ユーザーについての要求を発行します。アプリケーションでは、サービスによって提示される要求を単純に信頼し、要求に基づいて (認証することなく) 決定を下すことができます。
要求ベースの ID モデルを使用するときは、ユーザーは自分の ID を一連の要求としてアプリケーションに示します。要求はユーザーについてのアサーションでしかありません。名前、電子メール アドレス、フィードバック評価など、どのようなものでもかまいません。要求は、ユーザーの認証方法と属性を (おそらくはエンタープライズ ディレクトリから) 知っている ID プロバイダによって提供されます。クライアント アプリケーションは、これらの要求を取得してアプリケーションに提示するための発行機関を意識しないで動作します。
Microsoft .NET Access Control Service はクラウド ベースの集中型サービスであり、このモデルを Azure Services Platform の中で簡単に実現できるようにします。現在、.NET Access Control Service は、プロビジョニング プロセスの間に割り当てられたソリューション資格情報を使用してユーザーを認証することにより ID プロバイダとして機能できますが、これはこのサービスに本来意図されている機能ではありません。このサービスは本来、WLID や "Geneva" Server セキュリティ トークン サービスなどの既存の ID プロバイダ、または標準フェデレーション プロトコルをサポートする任意の ID プロバイダを利用するように設計されたものです。そのためシングル サインオンは当然の結果です。
.NET Access Control Services の主な機能は、アプリケーションに役立つ一連の要求を提供することです。これは通常、WLID や "Geneva" Server などの ID プロバイダからの入力要求を、アプリケーションにとって意味のある一連の出力要求に変換することを意味します。このサービスは、クラウド内の構成可能な要求変換エンジンと考えることができます。
サービスを構成する
.NET Access Control Service の構成は、特定のソリューションの中で提供される管理ポータルを使用して行います (図 4 を参照)。管理ポータルでは、サービスに登録されているユーザーの要求を発行する方法や、他のプロバイダからの要求を変換した結果として要求を発行する方法を決定するルールを構成します。
図 4 .NET Access Control Service 管理ポータル
自分でサンプルのサービスを構成する代わりに、.NET Access Control Service が .NET Service Bus 用にどのように構成されるのかを見ていくことにします。管理ポータルで [Advanced] (詳細設定) ボタンをクリックすると、さまざまなスコープの所有者を表すソリューション名のドロップダウンが表示されます。スコープは要求変換ルールのコレクションです。自分のアカウントの Service Bus ソリューションを選択すると、次のスコープが表示されます。
http://servicebus.windows.net/services/pluralsight/
.NET Service Bus を使用するときは、この Service Bus スコープを使用するエンドポイントをベース URI として構成します (当然ながら、URI は各自のアカウント用にカスタマイズします)。すべてのソリューションには、.NET Service Bus と .NET Workflow Service の両方に対する一連のアクセス制御ルールが事前に構成されています。
[Manage] (管理) をクリックすると、特定のスコープに対して構成されているルールの一覧を確認できます (図 5 を参照)。この例には、pluralsight という値を含む着信ユーザー名要求を検索する 2 つのルールがあります。1 つのルールは Send の出力要求を生成し、もう 1 つは Listen の出力要求を生成します。.NET Service Bus は、このような要求を検索してエンドポイント名前空間へのアクセスを制御するために開発されました。Send 要求を提示するユーザーはスコープの URI にメッセージを送信することを許可され、Listen 要求を提示するユーザーはスコープの URI でリッスンを作成することを許可されます。Send トークンを生成するルールを削除すると、pluralsight アカウントは、このスコープ内の .NET Service Bus を通してメッセージを送信できなくなり、リッスンのみが可能になります。
図 5 スコープのルールの構成
独自のサービスにも同様のサポートを簡単に追加できます。管理ポータルで新しいスコープ URI を定義した後、サービスが期待する要求を生成するために必要なルールを定義するだけです。サービスのロジックでは、着信した要求を検査し、存在する要求とその内容に基づいて承認の決定を行うコードを記述する必要があります。WCF と新しい "Geneva" Framework はどちらも、要求ベースのプログラミング モデルを使用してこれを可能にします。詳細な例については、SDK の .NET Access Control Service Getting Started サンプルを参照してください。
.NET Service Bus
.NET Service Bus の主な目的は、インターネット スコープで双方向の接続を提供することです。これは、今では非常に一般的になっている、ほとんどの環境において入力方向のトラフィックを制限するファイアウォールと NAT デバイスが原因で、実現が困難な場合があります。.NET Service Bus は、必要なネットワーク移動ロジックを備えた集中的なリレー サービスをクラウドに提供することで、これを実現します (図 6 を参照)。
図 6 .NET Service Bus リレー
リレーは、送信側と受信側がランデブー アドレスを通して通信できるようにします。受信側は、送信ポートを通してリレーに接続し、リッスンするランデブー アドレスを指定する双方向ソケットを通信用に作成します。送信側は、送信先として同じランデブー アドレスを指定して、リレーにメッセージを送信できます。リレーは、メッセージを受信すると、同じランデブー アドレスを共有する対応する 1 つのリスナ (マルチキャストの場合は複数のリスナ) にメッセージを中継します。リレーは、既に作成されている双方向ソケットを通して、受信側にメッセージを送信します。つまり、受信側に受信用のポートは必要ありません。これが、このメカニズムが (一般的なチャット アプリケーションのように) ファイアウォールおよび NAT デバイスを通して動作するしくみの説明です。
.NET Service Bus は、一方向、要求/応答、さらにはパブリッシュ/サブスクライブなど、さまざまなメッセージング スタイルをサポートします。また、相互運用性またはパフォーマンスの必要性に応じて、HTTP と TCP のどちらの通信もサポートします。さらに、リレーは、ポート予測アルゴリズムに基づいて、2 つのピア ノード間の直接 TCP 接続をネゴシエートするためのモードも提供します。大きいメッセージを送信するときは、リレーをバイパスすることでスループットを高めることができます。全体として、.NET Service Bus は今日の最も一般的な各種通信シナリオに、非常に柔軟に適応できます。
.NET Service Bus エンドポイントの URI の構成方法を理解することが重要です。TCP ベースのエンドポイントを公開するときは、次のようにアドレスを構成する必要があります。
sb://servicebus.windows.net/services/{solution}/{name}/{name}/...
HTTP ベースのアドレスを公開するときは、プロトコル方式の sb を http に置き換えるだけです。.NET Service Bus 全体で自分のエンドポイントと他のソリューションによって使用されるエンドポイントを区別するため、アドレスの一部としてソリューション名を指定することに注意してください。これは、.NET Access Control Service 構成でスコープ URI として使用される URI と同じアドレスです。ソリューション名の後には、エンドポイントに使用する URI 名階層がどのようなものであっても自由に指定できます。
特定のアドレスで送信またはリッスンするには、送信側と受信側が .NET Service Bus に Send 要求または Listen 要求 (.NET Access Control Service から取得したもの) を提示する必要があります。.NET Service Bus は .NET Access Control Service との間に信頼関係を持っているので、発行されたセキュリティ トークンを読み取って、これらの要求を処理できます。これらの要求がないとリレーを使用できません。ただし、特定のエンドポイントが匿名の送信を許可するように構成されている可能性があり、その場合は例外です。
.NET Service Bus リレーと統合する最も簡単な方法は、SDK に含まれる新しい WCF リレー バインドを使用することです。組み込まれている WCF HTTP/TCP バインドのほとんどに、同等のリレー バインドがあります (図 7 を参照)。NetOneWayRelayBinding (アグレッシブな一方向トラバーサル用) や NetEventRelayBinding (一方向のマルチキャスト シナリオ用、通常はパブリッシュ/サブスクライブに使用されます) のように、明確に対応するバインドがない新しいリレー バインドも少数ですがあります。標準バインドの代わりにリレー バインドを使用すると、基になっている WCF チャネル コンポーネントが .NET Access Control Service との通信および背後で行われるリレーを処理するので、ユーザーのコードを変更する必要がない場合さえあります。
| 図 7 WCF リレー バインド |
| 標準の WCF バインド | 同等のリレー バインド |
| BasicHttpBinding | BasicHttpRelayBinding |
| WebHttpBinding | WebHttpRelayBinding |
| WSHttpBinding | WSHttpRelayBinding |
| WS2007HttpBinding | WS2007HttpRelayBinding |
| WSHttpContextBinding | WSHttpRelayContextBinding |
| WS2007HttpFederationBinding | WS2007HttpRelayFederationBinding |
| NetTcpBinding | NetTcpRelayBinding |
| NetTcpContextBinding | NetTcpRelayContextBinding |
| N/A | NetOnewayRelayBinding |
| N/A | NetEventRelayBinding |
.NET Service Bus では、Atom フィードの形式でサービス レジストリも提供されます。このフィードは、標準の HTTP GET 要求を使用して、ソリューションのベース アドレスで使用できます。このフィードには、特定のソリューション内にあるすべてのアクティブなリスナ エンドポイントについての情報が自動的に含まれます。
.NET Service Bus を使用して通信する
次に、パブリッシュ/サブスクライブ モデルを使用した .NET Service Bus 経由の通信の例を詳細に見ていきます。最初に、次のサービス コントラクトがあるとします。
[ServiceContract(Namespace = "")] public interface ITweetNotifier { [OperationContract(IsOneWay = true, Action = "urn:DisplayTweet")] void DisplayTweet(string status); }
また、受信したステータス テキストをコンソール ウィンドウに単純に表示するサービス (名前は TweetNotifierApp) をホストするアプリケーションがあるとします。これに関しては特別なことは何もありません。
いずれかのリレー バインドを使用してエンドポイントを定義することで、.NET Service Bus を通してリッスンするようにホスト アプリケーションを構成できます。パブリッシュ/サブスクライブを実装するために (リスナが複数の可能性があります)、図 8 に示すような NetEventRelayBinding を使用します。
図 8 NetEventRelayBinding
<configuration> <system.serviceModel> <behaviors> <endpointBehaviors> <behavior name="Default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="pluralsight" password="{password}"/> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> <services> <service name="TweetServiceLibrary.TweetService"> <endpoint address="sb://servicebus.windows.net/services/pluralsight/tweet" behaviorConfiguration="Default" binding="netEventRelayBinding" bindingConfiguration="" contract="TweetServiceLibrary.ITweetNotifier" /> </service> </services> </system.serviceModel> </configuration>
特別な動作を使用して、.NET Access Control Service に送信する資格情報を WCF に指示していることにも注意してください。これは、認証を受けて必要な .NET Service Bus 要求を取得するためですこの例を実行してみる場合は、ユーザー名とパスワードを自分の資格情報に置き換えてください。
ホスト アプリケーションを実行すると、WCF のホスト インフラストラクチャは、自動的に、.NET Access Control Service で認証を行い、要求を取得した後、.NET Service Bus に対する送信ポートを開いて、指定されているアドレスでリスナを登録します。この時点で、ローカルにホストされているサービスは、指定されたアドレスで .NET Service Bus を通してリレーされるメッセージを受信できる状態になります。また、ソリューションのベース アドレスを参照してサービス レジストリ フィードにアクセスでき、フィードではアクティブなリスナ エンドポイントが表示されます。
次に、同じランデブー アドレスで .NET Service Bus を通してメッセージを送信するクライアント アプリケーションを作成できます。クライアント プログラムは次のようになります。
static void Main(string[] args) { ChannelFactory<ITweetNotifier> cf = new ChannelFactory<ITweetNotifier>("tweetService"); ITweetNotifier tweetNotifier = cf.CreateChannel(); Console.WriteLine("Enter a status update: "); string status = Console.ReadLine(); while (!status.Equals("")) { tweetNotifier.DisplayTweet(status); status = Console.ReadLine(); } }
クライアント構成ファイルはホスト構成ファイルと同様の内容にする必要があります。<client> セクションではエンドポイントの定義のみを指定する必要があります。それ以外は、クライアントのエンドポイントで構成される <transportClientEndpointBehavior> も含めてほぼ同じになります。
このようにすると、ホスト アプリケーションの複数のインスタンスを実行した後、クライアント アプリケーションの単一のインスタンスを実行して、マルチキャスト方式でリレーされるすべてのメッセージを確認できるようになります (図 9 を参照)。ホスト アプリケーションがファイアウォールまたは NAT デバイスの背後にあっても、リレーは動作します。
図 9 .NET Service Bus のデモの実行
これは、.NET Service Bus がサポートする多くの可能な通信シナリオの 1 つの例にすぎません。他の例については、.NET Services SDK で提供されている .NET Service Bus のさまざまなサンプルを参照してください。
.NET Workflow Service
クラウド コンピューティングへの移行において、ワークフローは、構築する複合クラウド ソリューションでの複雑なサービス対話を調整するための簡単な方法を提供します。
.NET Workflow Service は、クラウド内の WF ワークフローを実行して管理するための拡張可能なホスティング環境を提供します。ホスティング環境は必要に応じて拡張できる Window Azure を基に構築され、また WF ランタイムが使用されているため、ワークフローのインスタンスは特定のサーバーには固定されません。実行のエピソードごとに (Windows Azure の中の) サーバー間を自由に移動できます。.NET Workflow Service は WF 永続化サービスに依存します。このサービスは、Microsoft SQL Services を利用して実行中のワークフローの状態を保存し、復旧機能が提供されるようにします。
クラウドのワークフローは、Visual Studio およびいつも使用しているものと同じワークフロー デザイナを使用して作成します。最終的には、XAML のワークフローとルール ファイルを作成します。その後、これらの XML ファイルを .NET Workflow Service に展開し、それを使用してワークフローのインスタンスを作成できます。
.NET Services SDK には、標準の SequentialWorkflow テンプレートの特殊なバージョンである SequentialCloudWorkflow を作成するためのプロジェクト テンプレートが含まれています。クラウドで実行するワークフローを定義するときは、ワークフローで使用できるアクティビティについても制限があります。使用できるのは、WF の基本アクティビティ ライブラリに含まれるアクティビティのサブセットと、.NET Services SDK の一部として提供される一連の新しいカスタム クラウド アクティビティだけです (図 10 を参照)。これらのクラウド アクティビティによりメッセージを送信、受信、および処理できるようになりますが、今のところはそれくらいです。今後のバージョンではさらにアクティビティが追加されて、クラウド ベースのワークフローの機能が拡張される予定です。
| 図 10 クラウド ワークフローのアクティビティ |
| タスク | 説明 |
| CloudHttpReceive | ワークフロー インスタンスの特定の URL にポストされた HTTP 要求を受信します。 |
| CloudHttpSend | 指定された URL で HTTP GET または POST 操作を呼び出し、応答を取得します。 |
| CloudServiceBusSend | .NET Service Bus 上の特定のエンドポイントにメッセージを送信します。 |
| CloudXPathRead | 入力 XML ドキュメントから指定されたデータを読み取ります。 |
| CloudXPathUpdate | 入力 XML ドキュメントに指定されたデータを設定します。 |
| CloudDelay | 指定された時間だけ待機します。 |
他のサービスと同様に、.NET Workflow Service にもワークフローの種類とインスタンスを管理するための管理ポータルがあります。.NET Services SDK にも、同じことをプログラムで実行できるクライアント管理 API が含まれます。
図 11 完成したワークフローのデザイン
クラウド ワークフローを構築する
.NET Workflow Service がどのように動作するのかを見るため、パブリック Twitter フィードを受け取り、購読しているすべての TweetNotifierApp インスタンスに .NET Service Bus を使用して最新のエントリを送信するワークフローを作成してみましょう。
最初に、Visual Studio 2008 で新しい CloudSequentialWorkflow プロジェクトを作成する必要があります。MonitorTwitterFeed という名前にします。この時点では、従来の WF デザイナのように見えるでしょう。アクティビティ ツールボックスを展開すると、使用できる制限されたアクティビティのセットが表示されます。
While アクティビティを使用して、60 秒ごとにパブリック Twitter フィードをポーリングし続ける必要があります。そこで、最初に While アクティビティをワークフロー デザイン画面にドラッグし、条件を宣言型ルール条件として指定します。この例の目的から、条件が常に "true" を返すようにします。次に、Sequence アクティビティを While アクティビティの内部にドラッグし、繰り返す手順のシーケンスを定義します。
60 秒間待つ必要があるので、CloudDelay アクティビティをシーケンスにドラッグし、Timeout の値に 00:01:00 を指定します。HTTP GET 要求を使用してパブリック Twitter フィードを取得する必要があるので、CloudHttpSend アクティビティを CloudDelay アクティビティのすぐ下に配置し、適切に構成します (Method を GET に設定し、URL を http://twitter.com/statuses/public\_timeline.xml に設定します)。
次に、フィードの先頭から最新のステータス エントリを読み取る必要があります。これは、CloudXPathRead アクティビティで行うことができます。これをシーケンスに配置した後、InXml プロパティを前のアクティビティの Response プロパティにバインドします。また、InXPathExpression を /statuses/status/text に設定して XPath 式を指定します。
次に、.NET Service Bus を使用して TweetNotifierApp に送信する適当な XML メッセージを作成する必要があります。これは CloudXPathUpdate アクティビティで行うことができます。ターゲット サービスは次のようなメッセージを予期しています。
<DisplayTweet><text>ここにステータスを設定する</text></DisplayTweet>
そこで、CloudXPathUpdate アクティビティをシーケンスに配置した後、XML を InXml プロパティに入力し、"/DisplayTweet/text" を InXPathExpression に入力します。また、InNewValue を前のアクティビティの OutReadValue プロパティにバインドする必要があります。これにより、入力値 (最新のステータス) を XML テンプレートに挿入することで新しい XML ドキュメントを作成する基本的な方法をアクティビティに指示します。
最後に、.NET Service Bus を使用してメッセージを送信するようワークフローに指示する必要があります。そのためには CloudServiceBusSend アクティビティを使用します。このアクティビティをシーケンスの最後に配置した後、Action を urn:DisplayTweet に、ConnectionMode を Multicast に、アドレスを sb://servicebus.windows.net/services/pluralsight/tweet にそれぞれ設定します。また、Body プロパティを前のアクティビティの OutXml プロパティにバインドします。それが済んだらワークフローは完成です。完成したワークフロー デザインの表示は、図 11 を参照してください。
ワークフローを配置してテストするには、ワークフロー デザイン画面で右クリックし、[ワークフローの配置] をクリックするだけです。ソリューションの資格情報を入力して [配置] と [実行] をクリックします。アドインが XAML 定義を .NET Workflow Service にアップロードし、そのインスタンスを開始します。管理ポータルのフォームを使用して、手動で XAML 定義をアップロードすることもできます。
ワークフローを配置した後は、管理ポータルを表示してワークフローの種類と実行中のインスタンスを確認できます。TweetNotifierApp の実行中のインスタンスがある場合、Twitter のメッセージが 60 秒ごとに表示されます。
Aaron Skonnard は、インストラクタ主導とオンデマンドの両方の Microsoft 開発者向けコースを提供するトレーニング プロバイダである Pluralsight の共同設立者です。最近は、クラウド コンピューティング、Windows Azure、WCF、および REST を対象とする Pluralsight On-Demand! コースの録画にほとんどの時間を費やしています。Aaron はこれまで何年もの間、執筆と、講演と、世界中のプロ開発者の指導に従事してきました。彼のブログのアドレスは pluralsight.com/aaron です。