次の方法で共有


ServiceHostFactory を使用したホスティングの拡張

Windows Communication Foundation (WCF) でサービスをホストするための標準の ServiceHost API は、WCF アーキテクチャの拡張ポイントです。 ユーザーは、ServiceHostから独自のホスト クラスを派生させることができます。通常、サービスを開く前に、OnOpening()を使用して既定のエンドポイントを強制的に追加したり、動作を変更したりするために、ServiceDescriptionをオーバーライドできます。

セルフホスト環境では、ホストをインスタンス化するコードを記述し、インスタンス化した後でServiceHostを呼び出すので、カスタム Open()を作成する必要はありません。 これら 2 つの手順の間で、任意の操作を実行できます。 たとえば、新しい IServiceBehaviorを追加できます。

public static void Main()  
{  
   ServiceHost host = new ServiceHost( typeof( MyService ) );  
   host.Description.Add( new MyServiceBehavior() );  
   host.Open();  
  
   ...  
}  

この方法は再利用できません。 説明を操作するコードはホスト プログラム (この場合は Main() 関数) にコード化されるため、そのロジックを他のコンテキストで再利用することは困難です。 命令型コードを必要としない IServiceBehavior を追加する他の方法もあります。 ServiceBehaviorAttributeから属性を派生させ、それをサービス実装の種類に配置することも、カスタム動作を構成可能にして構成を使用して動的に構成することもできます。

ただし、この問題の解決には、この例のわずかなバリエーションを使用することもできます。 1 つの方法は、ServiceBehavior を追加するコードをMain()外に移動し、OnOpeningのカスタム派生メソッドのServiceHostメソッドに移動することです。

public class DerivedHost : ServiceHost  
{  
   public DerivedHost( Type t, params Uri baseAddresses ) :  
      base( t, baseAddresses ) {}  
  
   public override void OnOpening()  
   {  
  this.Description.Add( new MyServiceBehavior() );  
   }  
}  

その後、 Main() 内で次の情報を使用できます。

public static void Main()  
{  
   ServiceHost host = new DerivedHost( typeof( MyService ) );  
   host.Open();  
  
   ...  
}  

これで、カスタム ロジックをクリーンな抽象化にカプセル化し、さまざまなホスト実行可能ファイルで簡単に再利用できるようになりました。

インターネット インフォメーション サービス (IIS) または Windows プロセス アクティブ化サービス (WAS) 内からこのカスタム ServiceHost を使用する方法はすぐには明らかではありません。 ホスト環境はアプリケーションに代わって ServiceHost をインスタンス化するため、これらの環境はセルフホスト環境とは異なります。 IIS および WAS ホスティング インフラストラクチャは、カスタム ServiceHost 派生物について何も認識しません。

ServiceHostFactoryは、IIS または WAS 内からカスタム ServiceHostにアクセスするこの問題を解決するように設計されています。 ServiceHostから派生したカスタム ホストは動的に構成され、さまざまな種類の可能性があるため、ホスティング環境で直接インスタンス化されることはありません。 代わりに、WCF はファクトリ パターンを使用して、ホスティング環境とサービスの具象型の間に間接参照レイヤーを提供します。 特に指定しない限り、ServiceHostFactoryのインスタンスを返すServiceHostの既定の実装が使用されます。 ただし、 @ServiceHost ディレクティブでファクトリ実装の CLR 型名を指定することで、派生ホストを返す独自のファクトリを提供することもできます。

基本的なケースでは、独自のファクトリを実装することは簡単な練習にすることが意図です。 たとえば、派生ServiceHostFactoryを返すカスタム ServiceHostを次に示します。

public class DerivedFactory : ServiceHostFactory  
{  
   public override ServiceHost CreateServiceHost( Type t, Uri[] baseAddresses )  
   {  
      return new DerivedHost( t, baseAddresses )  
   }  
}  

既定のファクトリの代わりにこのファクトリを使用するには、次のように @ServiceHost ディレクティブに型名を指定します。

<% @ServiceHost Factory="DerivedFactory" Service="MyService" %>

ServiceHostから返されるCreateServiceHostに対して行う作業には技術的な制限はありませんが、ファクトリの実装は可能な限りシンプルにしておくことをお勧めします。 カスタム ロジックが多数ある場合は、そのロジックをファクトリ内ではなくホスト内に配置して、再利用可能にすることをお勧めします。

ここで説明する必要があるホスティング API には、もう 1 つのレイヤーがあります。 WCF には ServiceHostBaseServiceHostFactoryBaseもあり、そこからそれぞれ ServiceHostServiceHostFactory が派生します。 これらは、メタデータ システムの大部分を独自のカスタマイズされた作成と交換する必要がある、より高度なシナリオのために存在します。