AppFabric での構成プロセス

  • [アーティクル]

IIS マネージャー用の AppFabric 拡張機能および AppFabric 用の Windows PowerShell コマンドレットを使用することで、アプリケーションの所有者や IT の担当者は、WCF サービスまたは WF サービスを基にして構築されたアプリケーションを簡単に構成できます。このトピックでは、IIS マネージャーの拡張機能または AppFabric の構成コマンドレットを使用してサービスまたはアプリケーションを構成するときに Web.config ファイルに対して行われる処理について説明します。最初にサービスの構成で使用される Web.config ファイルについて説明した後、サービスを直接構成する方法について説明し、最後にサービスが継承する既定値の構成について説明します。

ASP.NET での Web.config ファイルの使用に関する詳細については、「ASP.NET Configuration」を参照してください。

Web.config ファイルの階層

IIS の構成階層内の各項目は独自の Web.config ファイルを持つことができ、サービスは属しているサーバー、サイト、アプリケーション、およびサブディレクトリに関連付けられている Web.config ファイルから既定の構成設定を継承できます。結果として、サービスの構成は Web.config ファイルの階層によって定義されます。ここでは、階層内のどの Web.config ファイルがサービスの構成を定義するのかを決定する規則、およびこれらのファイル内で優先される要素について説明します。

AppFabric がサーバーにインストールされる際、Machine.config ファイルと同じディレクトリ (<drive>:\Windows\Microsoft.NET\Framework\v4.0.xxxxx\Config) に、サーバーの Web.config ファイルが作成されます (まだ存在しない場合)。このサーバーの Web.config ファイルを構成することにより、サービスの追跡、ワークフローの永続化、およびワークフローのインスタンスの管理が可能になります。Web サイト用の Web.config ファイル (Web サイトのディレクトリ <drive>:\inetpub\wwwroot にあります)、アプリケーション用の Web.config ファイル (アプリケーションのルート ディレクトリ)、およびアプリケーションのサブディレクトリ用の Web.config ファイルを作成することもできます。サイト、アプリケーション、およびサブディレクトリの Web.config ファイルは、AppFabric のセットアップではインストールされません。IIS マネージャー用の AppFabric 拡張機能を使用してあるスコープの構成を変更しようとして、そのスコープの Web.config ファイルが存在しないときは常に、Web.config ファイルが自動的に作成されます。

いずれのレベルの Web.config ファイルにもサービスに直接適用する構成設定を格納できますが、IIS マネージャーの UI でサービスを直接定義する場合は、アプリケーションの Web.config ファイルのサービス定義を操作することになります。これらの設定に加えて、サーバー、サイト、アプリケーション、およびサブディレクトリの各レベルの Web.config ファイルにも、サービスで継承できる既定の構成設定を格納できます。IIS マネージャー UI 用の AppFabric 拡張機能および構成コマンドレットによって設定されるアプリケーションの構成は、Web.config ファイルに対してのみ反映され、machine.config または環境の構成を定義する他のファイルには反映されません。ただし、この規則の例外として、自動開始はサーバー レベルの applicationHost.config ファイルでアプリケーションに対して定義されます。

Web.config ファイルの内容は、構成設定を指定する XML タグおよびサブタグとその属性の入れ子になった階層です。WCF ベースおよび WF ベースのサービスに対する一部の構成設定は、サービス ビヘイビアーの中で定義されます。AppFabric では、構成ツールの全部ではありませんがほとんどで、ビヘイビアーが編集されます。ただし、一部の構成設定は、サービス ビヘイビアーの範囲外で定義されています。たとえば、サービスに対する監視、エンドポイント アドレス、バインド トランスポート クォータなどは Web.config ファイルで構成されていますが、ビヘイビアーの外部です。イベント コレクターおよびシステム診断の構成は、どちらもアプリケーション レベル以上のスコープであり、ビヘイビアーでは定義されていません。

ヒント

AppFabric では、Microsoft Web Administration (MWA) を使用して構成を管理します。MWA ではすべての構成要素がスキーマ化されている必要があります。カスタム ビヘイビアー用のスキーマを作成する方法の詳細については、「Extending IIS 7.0 Schema and Accessing the Custom Sections Using MWA」を参照してください。

サービスの直接的な構成

Web.config ファイルで名前付きサービス ビヘイビアーを使用することにより、サービスを構成できます。そのためには、サービス ビヘイビアー タグを指している behaviorConfiguration 属性を持つ <service> タグを Web.config ファイルに入力します。名前付きビヘイビアーは、アプリケーション レベルまたはそれより高いレベルで、Web.config ファイルの中でサービスに対して定義できます。次に示すのは、TestGetMetaData という名前の名前付きサービス ビヘイビアーで構成が定義されている TestService という名前のサービスの例です。

<system.serviceModel>
   <services>
      <service name="TestService" behaviorConfiguration="TestGetMetaData" >
         <endpoint address="/TestService" binding="wsHttpBinding" contract="ITestService"/>
         <endpoint address="mex"  binding="mexHttpBinding"  contract="IMetadataExchange"/>
      </service>
   </services>

   <behaviors>
      <serviceBehaviors>
         <behavior name="TestGetMetaData"> <serviceMetadata httpGetEnabled="true" httpGetUrl=""/> </behavior>
      </serviceBehaviors>
   </behaviors>
</system.serviceModel>

.NET Framework 3.5 では、サービスの多くの面を構成するための最も簡単な方法は、サービスのアプリケーション (またはサブディレクトリ) の Web.config ファイルで名前付きサービス ビヘイビアーを使用するものでした。.NET Framework 4.0 では、新しい テンプレートによって名前なしビヘイビアーの使用が進み、サービスは既定の構成を継承します。詳細については、後の「サービスが継承する既定値の構成」を参照してください。

AppFabric の構成ツールは、次のサービス ビヘイビアーを変更します。

  • sqlWorkflowInstanceStore (永続化)

  • etwTracking (監視)

  • serviceThrottling (パフォーマンス)

  • serviceCredentials/serviceCertificate (セキュリティ)

  • workflowIdle

  • workflowUnhandledException

  • workflowInstanceManagement

サービスが継承する既定値の構成

アプリケーションの Web.config ファイルで名前付きサービス ビヘイビアーを使用する以外にも、サービスを構成する方法があります。サービスは、属しているサーバー、サイト、アプリケーション、およびサブディレクトリに対する Web.config ファイルから既定の構成設定を継承することもできます。WCF ベースおよび WF ベースのサービスに対する一部の既定の構成設定は、名前なしのサービス ビヘイビアーの中で定義されます。

名前なしビヘイビアーの使用

名前付きサービス ビヘイビアーが存在し、サービスの behaviorConfiguration 属性がそれを指している場合、サービスは名前付きビヘイビアーの設定を使用します。また、上位のレベルにある同じ名前の他の名前付きビヘイビアーからも設定を継承します。サービスに対して適用されるサブディレクトリ、アプリケーション、サイト、およびサーバーの Web.config ファイルで定義されている既定のサービス ビヘイビアーの設定は使用しません。ただし、アプリケーションの Web.config ファイルで <service> タグを変更することにより、サービスに既定値を継承させることができます。そのためには、1 つ以上のレベルの Web.config ファイルで名前なしのサービス ビヘイビアーを定義し、サービスがその名前なしビヘイビアーを使用することを指定します。次のコードに示すように、サービス要素の behaviorConfiguration 属性の名前が空の文字列に設定されている場合、サービスは名前なしビヘイビアーを使用します。

<services>
   <service name=”TutorialService” behaviorConfiguration=””
      <endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
   </service>
</services>

次のコードに示すように behaviorConfiguration 属性を削除しても、同じ結果になります。前の例では名前なしビヘイビアーを明示的に使用するのに対し、次の例では名前なしビヘイビアーが暗黙で使用されます。

<services>
   <service name=”TutorialService”
      <endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
   </service>
</services>

名前なしの behaviorConfiguration 要素を使用すると、サービスは serviceBehavior 要素で定義されている 1 つ以上の名前なしビヘイビアーから構成を継承します。次に示すのは、サーバー レベルにおいて既定で定義されている名前なしの serviceBehavior 要素です。(AppFabric のセットアップで作成される) サーバーに対するこの既定の構成により、サービスの追跡、ワークフローの永続化、およびワークフローのインスタンスの管理が可能になります。

<behaviors>
   <serviceBehaviors>
      <behavior name=””>
         <workflowIdle timeToUnload="00:01:00" timeToPersist="infinite" />
         <workflowInstanceManagement authorizedWindowsGroup=”AS_Administrators" />
         <etwTracking profileName="HealthMonitoring Tracking Profile" />
      </behavior>
   </serviceBehaviors>
</behaviors>

名前なしビヘイビアーは、階層の任意のレベルの Web.config ファイルで定義できます。名前なしビヘイビアーがサービスを含む複数のレベルで定義されている場合、サービスの構成は、階層内で定義されている各名前なしビヘイビアーを結合した設定で構成されます。サービスの階層内の複数の名前なしビヘイビアーに競合する設定が含まれる場合は、低い方のレベルまたは最下位のレベルの設定が使用されます。複数の名前なしビヘイビアーからサービスの構成設定を集約するこの処理は、ビヘイビアーの結合と呼ばれます。

Web.config ファイルのビヘイビアー セクションでは、削除タグおよびクリア タグも使用できます。削除タグは、それを含む名前なしビヘイビアーの設定を削除します。クリア タグは、サービスのすべてのビヘイビアーを削除します。

behaviorConfiguration が空の文字列に設定されているサービスはすべて、階層内で定義されている名前なしビヘイビアーから既定の構成値を継承します。特定のレベルの Web.config ファイルで指定できる名前なしビヘイビアーは 1 つだけです。

暗黙的なサービス (「タグなし」サービスとも呼ばれます) の場合は、(behaviorConfiguration 属性がないと) 名前なしビヘイビアーが暗黙で使用されます。タグなしサービスとは、Web.config ファイルで宣言されていないサービスです。タグなしサービスには、Web.config ファイル内に関連付けられたサービス ノードがありません。既定では、Visual Studio 10 の新しいプロジェクトの種類ではタグなしサービスが作成されます。ランタイムは、タグなしサービスを検出すると、該当する名前なしビヘイビアーから結合された既定値を、そのサービスに自動的に適用します。IIS マネージャーの拡張機能ではタグなしサービスのエンドポイントを変更できないことに注意してください。変更するには、名前付きサービス要素を Web.config ファイルに追加する必要があります。

WCF ベースおよび WF ベースのサービスに対する一部の既定の構成設定は名前なしのサービス ビヘイビアーの中で定義されていますが、それ以外は名前なしのサービス ビヘイビアーの外部で定義されています。たとえば、接続文字列またはコレクションについては、サービスは階層内のすべての構成ファイルから構成値を継承します。

IIS マネージャーでの既定値の構成

IIS マネージャーの UI 用の AppFabric 拡張機能で、アプリケーションを直接構成できます。これを行うと、AppFabric は該当する Web.config ファイル (通常はアプリケーション レベル) に名前付きサービス ビヘイビアーを設定します。IIS マネージャーを使用して、サービスを直接構成するのではなく、サブディレクトリ、アプリケーション、サイト、およびサーバーのレベルの既定値を使用するようにサービスの構成を変更することもできます。その場合、Web.config ファイルの名前なしビヘイビアーは変更されます。AppFabric は、ビヘイビアーの結合を実行してアプリケーション構成パラメーターの完全なセットを作成します。

同じ構成プロパティに対して複数の Web.config ファイルで異なる値が設定されている場合、AppFabric は低い方のレベルまたは最も低いレベルの値を使用します。サービス用の [サービスの構成] ダイアログ ボックスのフィールドには、適用される Web.config ファイル内の名前なしビヘイビアーの値が表示されます。これらの値はサービス レベルの構成 UI で変更でき、変更すると適切なアプリケーションの名前なしビヘイビアーが変更されます。または、サブディレクトリ、サイト、およびサーバーのレベルで既定値を変更できます。アプリケーションの名前なしビヘイビアーを作成した後、より高いレベルの名前なしビヘイビアーで既定の設定を変更した場合は、下位レベルで上書きされていない限り、上位レベルの名前なしビヘイビアーに対する変更がサービス レベルに伝達されます。

IIS マネージャーでアプリケーション、サブディレクトリ、サイト、またはサーバー レベルの既定の設定を定義するには、[接続] ウィンドウでレベルを選択した後、[アクション] ウィンドウで [WCF サービスと WF サービスの管理] の [構成] をクリックします。[接続] ウィンドウでレベルを右クリックし、[WCF サービスと WF サービスの管理] をポイントして、[構成] をクリックしてもかまいません。そのレベルの [構成] ダイアログ ボックスが表示されます。UI であるレベルの既定の設定を変更するときに、そのレベルの Web.config ファイルがない場合は、AppFabric によって作成されます。

IIS マネージャー用の AppFabric 拡張機能では、サービスを構成するときに、使用される名前付きビヘイビアーの構成を選択しません。サービスの [サービスの構成] ダイアログ ボックスで値の入力または選択を行うと、AppFabric によって Web.config ファイルが編集されます。AppFabric 用の Windows PowerShell コマンドレットを使用して、ビヘイビアー構成の多くを設定することもできます。

location タグの使用

AppFabric は、Web.config ファイルの location タグでの読み取り操作をサポートします。サービスの構成を定義するには、名前付きサービス ビヘイビアーを使用したり、名前なしサービス ビヘイビアーまたはタグなしサービスを使用して既定のビヘイビアーを定義したりする方法の他に、location タグを使用する方法があります。location タグは、Web.config ファイルに要素を埋め込み、タグで具体的に指定した対象に構成設定を適用します。location タグには 1 つ以上の構成設定が含まれます。また、構成プロパティを適用する対象を指定するパスも含まれます。該当するアプリケーションの Web.config ファイルの <services> ノード内に存在する必要がある名前付きサービス ビヘイビアーとは異なり、location タグは任意の Web.config ファイルに入力できます。名前なしビヘイビアーとは異なり、location タグでは、アプリケーションの Web.config ファイルの <service> ノードで名前なしの behaviorConfiguration 要素を使用して適用されることを示す必要はありません。

次に示すのは、アプリケーション app1 のサービス s1 に構成設定を適用する、サイトの Web.config ファイル内の location タグの例です。

<location path=”app1/s1.svc” overrideMode=”Allow”>
   <defaultDocument enabled=”true”>
      <files>
         <add value=”Developer.htm” />
      </files>
   </defaultDocument>
</location>

パスを宣言しないと、location タグが定義されているレベルからすべての子パスまでがパスになります (ドット (.) を指定するのと同じです)。applicationHost.config でこのように指定すると、グローバル レベルの構成を指定することになります。location タグの overrideMode 要素を "Allow" に設定した場合は、階層の下位レベルで location タグの構成設定を編集して上書きできます。overrideMode 要素が設定されておらず、同じサービスの同じ構成設定に対して異なる値を指定する複数の location タグが存在する場合は、優先順位付け規則が適用されて、使用される設定が決まります。

location タグからサービスに適用される構成設定は、IIS マネージャー UI 用の AppFabric 拡張機能または AppFabric 構成コマンドレットでは変更できません。location タグの内容は UI またはコマンドレットに対しては読み取り専用です。IIS マネージャーまたはコマンドレットを使用して location タグを変更しようとすると、アクションがエラーになります。location タグで適用される設定を変更するには、Web.config ファイル内の location タグを手動で変更する必要があります。

リサイクル

IIS マネージャーで Web.config ファイルを変更して [サービスの構成] ダイアログ ボックスの [適用] または [OK] をクリックするときは常に、システムは関連付けられているアプリケーション ドメインをリサイクルします。[適用] または [OK] をクリックしてサブディレクトリ、アプリケーション、サイト、またはサーバーのレベルで既定の設定を指定して、対応する Web.config ファイルを変更するときは常に、そのスコープより下にあるすべてのサービスのアプリケーション ドメインがリサイクルされます。リサイクルの負荷を抑えるため、特に高レベルでは、再構成処理の回数を最小限にすることをお勧めします。既定値を構成するときは、次のように処理する必要があります。サーバーの既定値とサイトの既定値を (任意の順序で) 構成した後、アプリケーションをインポートし、含まれるアプリケーションとサービスを構成します。このような順序にする理由は、既定値を構成するとすべてのツリーがリサイクルされる可能性があるためです。可能な場合は、アプリケーションをリサイクルする負荷を避けるため、構成手順を実行してからアプリケーションを実際に実行してください。

  2012-03-05