Windows Server AppFabricの紹介。 ホスティングサービス、WCFおよびWFサービスのホスティングとスケーリング

サービスを介してデータをアプリケーションに取り込むことは、ますます一般的になっています。 Windowsでは、これはほとんどの場合、Windows Communication Foundation（WCF）に基づいてそのようなサービスを実装することを意味します。 また、このようなサービスのロジックは多くの場合ワークフローとして表すことができるという事実により、Windows Workflow Foundation（WF）を使用してWCFサービスを実装することが可能です。



しかし、問題は、これらすべてのサービスをどこで起動する必要があるかということです。 WCFもWFも特定のホストプロセスを必要としないため、開発者は適切なホストプロセスを使用できます。 ただし、効率的で管理されたホストを作成することは、それほど簡単な作業ではありません。 Windows Serverがこれらのサービスをホストおよび管理するためのより多くのサポートを提供すると、はるかに簡単になります。



そして、これはまさにAppFabric Hosting Servicesが提供するものです。 Windows Server AppFabricのこの部分をよりよく理解するには、最初にWCFとWFの基本テクノロジーをすばやく確認しておくと便利です。

技術の基本

WCFは、サービスを作成および使用する一般的な方法を提供します。 WFは、ワークフローの形でビジネスロジックを作成するためのサポートを提供します。 WFワークフローは通常、サービスを使用して外の世界とやり取りするため、WCFから始めてこれら2つのテクノロジーを説明します。

サービスの作成：Windows Communication Foundation

WCFを使用すると、開発者は、共通のプログラミングモデルを通じて、SOAP、RESTfulなどのさまざまなタイプのサービスを作成して使用できます。 図1に基本を示します。





図1 WCFサービススキーム



開発者は、Visual Studio（または別のツール）を使用して、あらゆる機能を提供できるサービスを実装できます。 このようなサービスは、1つ以上のエンドポイントを介して顧客が利用できるようになり、各エンドポイントは特定のインターフェイス（契約とも呼ばれます）を提供します。



通常、サービスはその機能をいくつかの操作に分割します。各操作は、ビジネスロジックの1つまたは別の側面を担当します。 たとえば、eコマースアプリケーションを実装するサービスには、バスケットの作成、バスケットへのアイテムの追加、アイテムの削除、購入代金の支払いなどの操作があります。 このサービスのクライアントは、必要に応じて各操作を呼び出します。

ワークフローの作成：Windows Workflow Foundation

開発者はどのようにサービスを実装する必要がありますか？ 場合によっては、たとえば、異なるタイプのデータセットへのアクセスを提供するサービスのように、サービス操作が互いに独立している場合があります。 それ以外の場合、サービス操作はプロセスの形式で互いに追従することができます。つまり、一定期間にわたって特定の順序で呼び出される必要があります。



たとえば、開発者が、バスケットの作成、商品の追加、削除、支払いなど、必要なすべての操作でWebストアバスケットサービスを実装する方法を考えてください。 クライアントが行う最初の呼び出し-バスケットの作成-以前に商品で何かを行うことは完全に受け入れられません。 さらに、クライアントは通常、製品をバスケットに追加する操作を呼び出します（空のバスケットでdeleteを呼び出すことは意味がありません）。その後、必要に応じて削除関数を呼び出すこともできます。 支払関数が呼び出されると、商品の追加または削除の操作を呼び出すことはすでに受け入れられません。



潜在的に、これにはすべて時間がかかります。 たとえば、ユーザーがバスケットを作成し、1組の製品を追加してから、しばらくの間サービスの作業を中断したとします。 彼は数時間または数日で戻ってくるかもしれず、彼のバスケットと商品がまだ彼を待っていると期待するでしょう。



この種のロジックはどのように実装する必要がありますか？ これは実際には、これらの手順を実行する順序を決定するルールを含む一連の手順です。 また、実装では、プロセス全体を通じて状態（バスケット）を維持する必要があり、これには数時間、数日、またはそれ以上かかる場合があります。 特に、スケーラブルなアプリケーションを構築することが目標である場合、WFに基づいて構築されたワークフローの形式でこのようなロジックを実装することが最も望ましいでしょう。 WFワークフローは、プロセスの作成を簡素化するように設計されており、特定の種類のサービスを開発する場合に適しています。



WFは、ビジネスロジックのブロックを構築するためのデザイナーと、ワークフローに基づいてロジックを実装するためのランタイムという単純な基本部分で構成されています。 図2は、WFの動作を示しています。





図2。 WF-プロセス指向のビジネスロジックを作成するための基礎



各WFワークフローは、アクティビティに基づいて作成されます。各アクティビティは、プロセスのビジネスロジックの一部を実装します。 WFは、ifやWhileなどの基本的な機能を実装する一連のアクティビティを備えた標準のベースアクティビティライブラリ（BAL）を提供します。 開発者は、ビジネスロジックのニーズを満たすために、独自のアクティビティを自由に作成できます。 開発者は、ワークフローを作成するために、Visual Studioの一部であるWFワークフローデザイナーを使用してアクティビティを配布できます。 使用されるアクティビティに関係なく、それらはすべてWFランタイムランタイムを使用して実行されます。



ワークフローは、プロセスを実装する開発者に一連の有用なものを提供します。 たとえば、カートアイテムを追加または削除する要求など、ワークフローが入力を待機している場合、WFランタイムはワークフローの状態を自動的に保存し、メモリからアンロードできます。 新しいリクエストを受信すると、環境は状態をリロードし、ワーカースレッドを開始してリクエストを処理します。 これにより、ワーカースレッドが実行されていないときにメモリ、システムスレッド、またはその他のリソースを消費しないため、スケーラブルなアプリケーションの開発が簡素化されます。 ランタイムは、トラッキングと呼ばれるワークフローの各実行の記録を保存できます。これにより、開発者は、ワークフローで各アクティビティがオンまたはオフになったときなど、さまざまな便利な情報を確認できます。

ワークフローに基づいてサービスを作成する

WFワークフローを使用して、非常に多数の異なる種類のビジネスプロセスを実装できます。サービスの作成だけに限定されません。 それにもかかわらず、WFに基づいてロジックが作成されたWCFサービスは、ワークフローに基づいたサービスという独自の名前に値します。 図3は、このアプローチを示しています。





図3 ワークフローベースのサービス



ワークフローに基づいたサービスまたはWFを使用しない単純なWCFサービスを作成する開発者を想像してください。 WCFもWFも、サービスを開始するプロセスのホストを明示的に決定しません。 これの良い点は、開発者が使用するプロセスを自由に選択できることです。WCFとWFはこれに限定しません。 これは、主な目標がビジネスロジックの作成であり、サービスのホストプロセスの構築が不要な作業である産業開発にとって特に重要です。 結局のところ、このプロセスはインフラストラクチャの一部であり、インフラストラクチャの問題はWindows Serverの責任です。 インフラストラクチャ内のホスティングサービスに対するすべてのリクエストに対するソリューションは、AppFabricホスティングサービスに役立ちます。

AppFabricホスティングサービスの概要

AppFabric Hosting Services（コードネーム「Dublin」）は、まったく新しいインフラストラクチャを作成することを意図したものではありません。 それどころか、IISサーバーとWindowsプロセスアクティブ化サービス（WAS）エンジンによって既に提供されているものの上に構築されています。 この基盤に基づいて、AppFabric Hosting Servicesは、ワークフローベースのサービスを含むWCFサービスを起動および管理するための新しい機能を追加します。 図4はこれを示しています。





図4 AppFabric Hosting Servicesは、サービスの起動と管理を簡素化します



図に示すように、WCFサービスとワークフローベースのサービスはIISが提供するワークフローで起動されます。つまり、AppFabricホスティングサービスは独自のプロセスを作成しません。 このテクノロジーはWASの機能も使用します。これにより、HTTPまたは別のプロトコルを介してメッセージを受信したときにサービスを開始できます。 AppFabric Hosting Servicesは既存のインフラストラクチャ上に構築され、メッセージを待たずに、展開後すぐに特定のサービスを実行する機能を追加します。 これにより、サービスの開始を待つ必要がないため、最初に連絡した顧客に対してサービスの応答性が向上します。



図4に示すように、AppFabricホスティングサービスは、IISマネージャーを新しいサービス管理ツールで拡張します。 管理者はこれらの拡張機能を使用して、WCF構成の管理、サービスの開始または停止、サービスエンドポイントの調査、ワークフローに基づいて特定のサービスインスタンスの一時停止、再開、または停止を行うことができます。 同時に、AppFabric Hosting Servicesは、サービスを管理するためのPowerShellコマンドレットのセットを提供し、管理者が独自のスクリプトを作成できるようにします。



開発者の生活を簡素化するために、Visual StudioはWCFサービスとWFサービスの両方を作成するための組み込みプロジェクトテンプレートを提供します。 これらのテンプレートに基づいて作成されたサービスは、AppFabricホスティングサービスですぐにホストできます。開発者は、特別なことをする必要はありません。 また、サービスが展開された後、さまざまな方法で利用できるようになります。 シナリオでそれらを考慮してください。

シナリオ：ワークフローベースのサービスをホストする

AppFabricホスティングサービスは、任意のWCFサービスと連携するために使用できますが、ワークフローベースのサービスの実行と管理の追加サポートを提供します。 図5は、これらの機能のうち最も重要なものの一部を示しています。





図5 AppFabric Hosting Servicesには追加のツールが含まれています



前述のように、WFランタイムは、データの入力を待機しているワークフローの状態を自動的に保存し、データの到着時に復元します。 しかし、条件はどこで維持されますか？ WFを別のメカニズムとして使用する場合、開発者はデータベースを個別に作成および構成して、状態を保存する必要があります。 ただし、図5に示すように、AppFabricホスティングサービスは事前構成された状態ストアを提供します。 WFでは、ワークフローの実行を追跡することもでき、開発者は実行に関する詳細な情報を自動的に受け取ることができます。 また、WFだけでは、追跡情報を保存する場所を正確に決定しません。 図5に示すように、AppFabricホスティングサービスは、監視用の組み込みデータベースを提供します。 状態ストアと監視データベースは、ワークフローで使用できるアプリケーションデータベースとは別個であることを明確にする必要があります。



他のWCFサービスと同様に、ワークフローの監視および制御メカニズムがあります。 前述のサービス制御要素に加えて、AppFabricはIISマネージャーを、ワークフローベースのサービスにのみ適用される追加機能で拡張します。 例として、図6に示すAppFabricダッシュボードと呼ばれる拡張機能の1つを見てください。





図6 AppFabricダッシュボードコントロールパネル



図に示すように、AppFabricダッシュボードにはAppFabricホスティングサービスコントロールパネルがあります。 上部には、現在のWFサービスのステータスが表示され、さまざまな状態のサービスの数が表示されます。 ウィンドウの少し下には、最近の呼び出し、例外などの履歴が表示されます。 Microsoftは、System Center Operations Managerのオプションの管理パックも提供しています。これにより、標準のWindows管理ツールを使用してAppFabricホスティングサービスイベントを監視できます。 これらのツールの目的は、現在のサービスホスティング環境で何が起こっているかについて明確な情報を提供することです。

シナリオ：ワークフローサービスのスケーラブル化

ワークフローの状態を自動的に保存および復元するWFの機能により、開発者はスケーラブルなビジネスロジックを作成できます。 AppFabricホスティングサービスにより、開発者はさらにスケーラブルなワークフローベースのサービスを作成できます。 図7はこれを示しています。





図7 スケーラブルなワークフローベースのサービスアーキテクチャ



このシナリオでは、3つのWebサーバーが同じ負荷分散ASP.NETアプリケーションのコピーを実行します。 ASP.NETは、ユーザーインターフェイスの生成にのみ使用されます。 アプリケーションのビジネスロジック（ショッピングカートなど）は、ワークフローに基づくサービスとして実装されます（したがって、混乱はありません。これは図には示されていませんが、原則として、ワークフローに基づく各サービスはIISワークフローとして起動されます） 。



最初のユーザーリクエストは上位Webサーバーに送信されました（ステップ1）。 この要求を受け取ったASP.NETページは、ワークフローに基づいてサービスの最初の操作（たとえば、バスケットの作成）を呼び出します。 この要求は、別のサーバーで実行されているサービスインスタンスに送信されます（手順2）。 操作が完了して結果が返されるとすぐに、WFランタイムはAppFabricホスティングサービスによって提供されるストレージにサービスのステータスを自動的に記録します（ステップ3）。



次のユーザーリクエストは、ロードバランサーによって別のWebサーバーに送信されました（ステップ4）。 今回は、たとえばカートにアイテムを追加するなど、リクエストを処理するASP.NETページが、最初のサーバー以外のサーバーで実行されているサービスにリクエストを送信します（ステップ5）。 この2番目の要求は別のサーバー上のサービスによって実行されるという事実にもかかわらず、WFランタイムでは、ワークフローインスタンスの状態をリポジトリから読み込み、要求を処理できます（図6）。



例に示すように、AppFabric Hosting Servicesを使用すると、ワークフローに基づいた同じサービスを異なる物理サーバーで異なる時間に実行できます。 これにより、多くの中間サーバーをホストして任意の数の要求を処理できるようになるため、サービスのスケーラビリティが向上します。 Webサーバーを追加するだけでASP.NETアプリケーションを拡張できるように、追加のサーバーを使用してワークフローとして実装されたビジネスロジックを拡張できます。



このアドレスの冒頭を参照してください、続き、最後が続きます。