エクスポート (0) 印刷
すべて展開

IIS で Service Bus エンドポイントを使用して WCF サービスをホストする

更新日: 2014年1月

作成者: Santosh Chandwani

校閲者: Seth Manheim

このトピックは、Windows Server 2008 R2 および Windows 7 に搭載されるインターネット インフォメーション サービス (IIS) バージョン 7.5 の Microsoft Azure の Service Bus エンドポイントを使用して WCF サービスをホストする方法について説明します。Microsoft Azure の Service Bus には プラットフォームまたはハイブリッドなシナリオで実行するアプリケーションに必要な接続機能とメッセージング機能が備わっています。このトピックでは、IIS で SDK 1.5 以降を使用して開発されたホスト サービスに必要な手順に焦点を当てて説明します。

Microsoft Azure の Service Bus によって提供されるインフラストラクチャは、広範囲な通信、大規模なイベント配布、命名、サービス公開用にホストされ、セキュリティ保護された上で幅広く利用できます。Service Bus に用意されている接続オプションを利用すると、他の方法では到達が困難または不可能な WCF およびその他のサービス エンドポイント (REST エンドポイントを含む) に接続できます。エンドポイントは、ネットワーク アドレス変換 (NAT) 境界の背後に配置するか、頻繁に変更され動的に割り当てられる IP アドレスにバインドできます。または、その両方も可能です。

Service Bus では、「リレー型」および「仲介型」メッセージング機能の両方を提供します。リレー型メッセージング パターンでは、リレー サービスは直接の一方向のメッセージ、要求/応答メッセージ、全二重メッセージ、ピア ツー ピア メッセージをサポートします。仲介型メッセージングでは、キュー、トピック、サブスクリプションなど、耐久性のある非同期メッセージング コンポーネントが、公開サブスクライブおよび一時的な切り離し機能と共に提供されます。送信側と受信側は同時にオンラインである必要はありません。受信側がメッセージを受信する準備が整うまで、メッセージ インフラストラクチャが高い信頼性でメッセージを格納します。これらのパターンは プラットフォームに移行するアプリケーションに重要です。

SDK に付属の Service Bus ツールは内部設置型 .NET アプリケーションとサービスの統合を簡易化します。SDK では Windows Communication Foundation (WCF) および他の Microsoft テクノロジとの統合がシームレスに行われ、これまでの開発者の専門知識を最大限活用します。Service Bus SDK にはさまざまな HTTP のService Bus バインド、Net.TCP リレー バインド、仲介型メッセージングのメッセージング バインドが含まれます。Service Bus「リレー」バインドの完全な一覧については「Service Bus のバインド」、メッセージング バインドについては「NetMessagingBinding」を参照してください。

これらのサービスは .NET 開発者向けの最上級のエクスペリエンスを実現するように設計されていますが、各サービスには業界標準プロトコルに基づいたインターフェイスが備わっているため、どのプラットフォームで実行されるアプリケーションでも REST、SOAP、WS-* プロトコルを介したサービスとの統合が可能です。また、Java および Ruby 用の Service Bus SDK は、こちらからダウンロードできます。

IIS で Service Bus バインドを使用して WCF サービスをホストする際の主な課題は、アクティブ化に関連します。既定では、IIS は 最初の要求を受信すると Web アプリケーションを初期化します。

しかし、Service Bus リレー バインドによる内部設置型 WCF サービスがクラウドの Service Bus からメッセージの受信を開始すると、内部設置型サービスは送信ポートを開いて双方向ソケットを通信用に作成する必要があります。Service Bus に接続し、自己認証し、クライアントが要求を送信する前にメッセージのリッスンを開始します。リレー サービスは、既に準備されている双方向ソケットを通じて内部設置型サービスにメッセージを送信します。

同様に「メッセージング」バインドによる自動メッセージ ポンプは、キューやサブスクリプションからメッセージを取得し WCF ReceiveContext メカニズムに統合します。このバインドもクラウドでの Service Bus への送信接続を開始してメッセージ ポンプがアクティブ化される前に自己認証する必要があります。

IIS と Windows プロセス アクティブ化サービス (WAS) はメッセージベースのアクティブ化に依存しているため、既定で IIS/WAS でホストされる Web アプリケーションは既定で最初の要求を受信した後に初めて初期化されます。このため、通常の IIS/WAS メッセージベースのアクティブ化は Service Bus バインドによる WCF サービスでは機能しません。メッセージを受信するには、これらのバインドは、サービスへの送信接続を最初に確立する必要があるためです。この要件は、IIS でホストする場合は、そのような WCF サービスを明示的に初期化するか、自動的にアプリケーションを初期化する代替メカニズムを必要とすることを意味します。このトピックでは ASP.NET Auto-Start メカニズムと Microsoft AppFabric Auto-Start 機能を使用してアプリケーションを自動的に初期化する 2 つの方法について説明します。または、NT サービスをホストとして使用することもできます。

HTTP を使用する Service Bus バインドはマネージ/アンマネージ HTTP パイプラインとは統合しません。このため ASP.NET との互換性は保たれず、サービスと同じアプリケーション ドメインでホストされる ASP.NET アプリケーションとの間のセッション状態の共有など、特定のシナリオが Service Bus バインドによる WCF サービスでは機能しません。

Service Bus エンドポイントで WCF サービスを構築する方法については、MSDN の「Service Bus を使用するアプリケーションの開発」を参照してください。多数の サンプル アプリケーションを入手できます。

標準 WCF webHttpBinding エンドポイントのある簡易的な WCF Echo サービスを検討してください。サービスのコード スニペットは次のように表示されます。

public class WebHttpService : IWebHttpService
{
    public string Echo(string value)
    {
        return string.Format("Echoing: ‘{0}’", value);
    }
}

次に、サービスを更新して webHttpRelayBinding バインドを使用する 2 つの Service Bus エンドポイントを使用するようにします。このサービスを IIS でホストして IIS/WAS のホスティング機能を利用できます。

次の例では、web.config ファイルの Services セクションにエンドポイントの情報を追加しています。このスニペットで、EchoService サービス名前空間、sb-test サービス名情報、発行者情報をユーザーのサービス名前空間とサービスで置き換えます。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.serviceModel>
  <services>
    <clear />
    <service behaviorConfiguration="MyServiceTypeBehavior" 
      name="Microsoft.ServiceBus.Samples.WebHttpService">
      <endpoint address="https://sb-test.servicebus.windows.net/WebHttpService/"
      behaviorConfiguration="sharedSecretClientCredentials" 
binding="webHttpRelayBinding"
      bindingConfiguration="WebHttpRelayEndpointConfig" 
name="RelayEndpoint"
      contract="Microsoft.ServiceBus.Samples.IWebHttpService" />
    </service>
  </services>

    <bindings>
      <webHttpRelayBinding>
        <binding name="WebHttpRelayEndpointConfig">
          <security relayClientAuthenticationType="None" />
        </binding>
      </webHttpRelayBinding>
    </bindings>

    <behaviors>
        <!-- Service Bus endpoint behavior-->
        <endpointBehaviors>
          <behavior name="sharedSecretClientCredentials">
            <webHttp/>
            <transportClientEndpointBehavior credentialType="SharedSecret">
              <clientCredentials>
                <sharedSecret issuerName="ISSUER_NAME" issuerSecret="ISSUER_KEY" />
              </clientCredentials>
            </transportClientEndpointBehavior>
          </behavior>
        </endpointBehaviors>
   </behaviors>
  </system.serviceModel>

既定では、Service Bus リレーに公開されるサービスは「覆い隠され」ており、サービス レジストリの ATOM フィードでは表示されません。詳細については、「Service Bus Service の検索と公開」を参照してください。サービス レジストリ フィードでサービスを表示させるこの手順は省略可能です。

探索ポリシーを「公開」に設定するには、最初に ServiceRegisterySettings のカスタム BehaviorExtensionElementWeb.config ファイルの system.serviceModel セクションに作成します。

<system.serviceModel>
  <extensions>
    <behaviorExtensions>
<add name="ServiceRegistrySettings"
type="Microsoft.ServiceBus.Samples.MyServiceRegistrySettingsElement, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
  </extensions>

次の手順では、BehaviorExtensionElement から継承された MyServiceRegistrySettingsElement というクラスを作成します。たとえば、次のような記事があります。

public class MyServiceRegistrySettingsElement : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get { return typeof(ServiceRegistrySettings); }
    }

    protected override object CreateBehavior()
    {
        return new ServiceRegistrySettings() 
{ DiscoveryMode = this.DiscoveryMode, 
  DisplayName = this.DisplayName };
    }

    [ConfigurationProperty("discoveryMode", DefaultValue = DiscoveryType.Public)]
    public DiscoveryType DiscoveryMode
    {
        get { return (DiscoveryType)this["discoveryMode"]; }
        set { this["discoveryMode"] = value; }
    }

    [ConfigurationProperty("displayName")]
    public string DisplayName
    {
        get { return (string)this["displayName"]; }
        set { this["displayName"] = value; }
    }
}

任意で WCF サービスの診断トレーシングを有効にするには、トレース リスナーを有効にします。これには、次のセクションを Web.config ファイルに追加する必要があります。

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Warning">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener" 
             initializeData="C:\Log\Traces.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

トレースを生成するフォルダ (上記のスニペットでは "C:\Log") は自動的に作成されないことに注意してください。フォルダは存在している必要があります。

初期化に ASP.NET Auto-Start 機能を利用すると、IIS で Service Bus エンドポイントを使用して WCF サービスをホストすることができます。Auto-Start 機能を使用すると、外部の要求を待つことなく Web アプリケーションを初期化できます。この機能では、データベースの接続の確立やモジュールの読み込みなど、すべての依存関係が事前に読み込まれ、初期化されます。最初の要求が到着する前に、Web サーバーの開始時にワーカー プロセスをプリロードします。また、障害復旧や、詳細な初期化を実行するカスタム コード プラグインも可能にします。

ASP.NET Auto-Start 機能の利用に必要な 3 つの変更:

  • アプリケーション プール構成

  • カスタム自動起動プロバイダーの追加

  • 障害復旧にカスタム サービス ホスト ファクトリを使用

Auto-Start 機能を利用するには、.NET ランタイム バージョン 4.0 を対象としたアプリケーション プールに関連付けられる仮想アプリケーションで WCF サービスをホストします。

HostingWCFServices1

次に、IIS アプリケーション プールを Auto-Start 用に構成する必要があります。そのためには、applicationHost.config ファイルを編集します。使用するアプリケーション プールの startMode 属性は、%windir%\System32\inetsrv\config\applicationHost.config で構成ファイルの AlwaysRunning に設定する必要があります。

この例では、アプリケーション プールは「WebHttpServicePool」です。

add name=" WebHttpServicePool" autoStart=“true” managedRuntimeVersion="v4.0" startMode="AlwaysRunning" />

IIS アプリケーション プールは複数の仮想アプリケーションをホストすることができます。この例では、アプリケーション プールは「/WebHttpService」です。これは、serviceAutoStartEnabledserviceAutoStartProvider 属性を applicationHost.config ファイルのアプリケーション エントリに追加することで構成できます。たとえば、次のような記事があります。

<sites>
    <site name="Default Web Site" id="1">
        <application path="/WebHttpService" 
                     applicationPool="WebHttpServicePool" 
                     serviceAutoStartEnabled="true" serviceAutoStartProvider="AutoStartWebHttpService">
             <virtualDirectory path="/"
                     physicalPath="C:\inetpub\WebHttpService" />
        </application>
    </site>
</sites>

IIS では、何らかの理由アプリケーション プールが明示的に停止されると、serviceAutoStartEnabled 属性は false にリセットされることに注意してください。この場合、この機能を復元するために、true に設定し直す必要がある場合があります。

前の手順で参照されている serviceAutoStartProvider 属性は、アプリケーションの起動ロジックをカプセル化するカスタム クラスを参照します。ServiceAutoStart クラスはアプリケーション プールとアプリケーションが (外部の Web 要求がアプリケーションで受信される前に) プリロードされると自動的に呼び出されます。ServiceAutoStart クラスは、Service Bus エンドポイントをクラウドに登録するサービス ホストを開始するよう自動的に呼び出されます。このクラスの Preload メソッドが呼び出されると、サービス ホストは ServiceHostingEnvironment.EnsureServiceAvailable() へのコールを介してアクティブ化されます。

この例では、ServiceAutoStart クラスは Microsoft.ServiceBus.Samples アセンブリの一部です。applicationHost.config ファイルは次のように更新する必要があります。

<system.applicationHost>

...
<serviceAutoStartProviders>
    <add name="AutoStartWebHttpService" 
         type="Microsoft.ServiceBus.Samples.AutoStartWebHttpService, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</serviceAutoStartProviders>

</system.applicationHost>

AutoStartWebHttpService クラスのコードは以下のとおりです。

public class AutoStartWebHttpService : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        bool isServceActivated = false;
        int attempts = 0;
        while (!isServceActivated && (attempts <10))
        {
            Thread.Sleep(1 * 1000);
            try
            {
                string virtualPath = "/WebHttpService/WebHttpService.svc";
                ServiceHostingEnvironment.EnsureServiceAvailable(virtualPath);
                isServceActivated = true;
            }
            catch (Exception exception)
            {
                attempts++;
                //continue on these exceptions, otherwise fail fast
                if (exception is EndpointNotFoundException
                    || exception is ServiceActivationException
                    || exception is ArgumentException)
                {
                    //log
                }
                else
                {
                    throw;
                }
            }
        }
    }
}

上記のサンプルでは、virtualPath をアプリケーション用に適切に更新する必要があります。

WCF サービス ホストが失敗すると、IIS/WAS はホスト オブジェクトを再生成できません。この場合、アプリケーション プールを手動でリサイクルできます。

エラーが発生したシナリオでホスト オブジェクトを自動的に再生成するため、WCF のカスタム サービス ホスト ファクトリ パターンを使用できます。詳細については、「Custom Service Host」を参照してください。

WCF サービスにカスタム サービス ホスト ファクトリ クラスを追加できます。たとえば、次のような記事があります。

public class ServiceHostFactoryWebHttpService : ServiceHostFactory
{
    Type incomingServiceType;
    Uri[] incomingBaseAddresses;

    private void OnServiceHostFaulted(object sender, EventArgs e)
    {
        ICommunicationObject faultedHost = (ICommunicationObject) sender;
        faultedHost.Abort();

        ServiceHost host = new ServiceHost(this.incomingServiceType, this.incomingBaseAddresses);
        host.Faulted += this.OnServiceHostFaulted;

        // Sleep to allow time for resource to come back – may require over 10s 
        // for remote services. Without wait/retry logic, process may throw
        // StackOverflow exception if resource is unavailable for an extended 
        // period of time.
        System.Threading.Thread.Sleep(TimeSpan.FromSeconds(10)); 

        host.Open();
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        this.incomingServiceType = serviceType;
        this.incomingBaseAddresses = baseAddresses;
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);
        host.Faulted += this.OnServiceHostFaulted; 
        return host;
    }
}

このスニペットの Thread.Sleep コードは実例を表しています。製品サービスには、適切な wait/retry ロジックを使用してください。

サービス ホスト ファクトリを呼び出すには、Factory 属性を WCF サービスの .svc ファイルに追加します。この場合は、WebHttpService.svc ファイルです。

<%@ServiceHost language="C#" Debug="true" 
    Service="EchoServiceMicrosoft.ServiceBus.Samples.WebHttpService" 
    Factory="Microsoft.ServiceBus.Samples.ServiceHostFactoryWebHttpService" 
    CodeBehind="WebHttpService.svc.cs" %>

Windows Server の Microsoft AppFabric 1.1 は、IIS で WCF アプリケーションと WF アプリケーションを簡単に構成、管理、監視できるようにする IIS 拡張機能セットです。Windows Server 用の Microsoft AppFabric 1.1 およびその機能の概要については、「Microsoft AppFabric 1.1 for Windows Server」を参照してください。

このセクションでは、Service Bus エンドポイントを使用した WCF サービス用の Microsoft AppFabric 機能を使用する手順を説明します。

Microsoft AppFabric は Microsoft.Web.Administration (MWA) API を使用して構成スキーマを読み書きします。MWA API は %SystemRoot%\System32\inetsrv\config\schema に格納されているスキーマを使用します。この例のサービス用 Web.config ファイルには Service Bus バインドのカスタム エンドポイント構成が含まれるため、MWA スキーマを Service Bus エンドポイント (ServiceBus_schema.xml へのリンク) に追加し、前述の MWA スキーマ フォルダに配置する必要があります。MWA は自動的にスキーマを取り出し、Service Bus 固有の構成を正しく解析します。

WCF および WF サービスの Microsoft AppFabric auto-start 機能は、ASP.NET 4 auto-start 機能に構築されます。この機能では、IIS が再起動されるか、アプリケーション プールがリサイクルされると、サービスを自動的に開始できます。

IIS マネージャーで、アプリケーション (この例では WebHttpService) を選択し、右側の [操作] ペインの [WCF サービスと WF サービスの管理] セクションの下から [構成…] をクリックします。

HostingWCFServices2

[アプリケーションの WCF と WF の構成] ダイアログが表示されます。左側のメニューから [Auto-Start] をクリックし、[Enabled (all services auto-start)] をクリックします。[はい] をクリックし、startMode をアプリケーション プールの AlwaysRunning に設定します。

HostingWCFServices3

障害が発生したシナリオでホスト オブジェクトを自動復旧させて再生成するために、障害復旧にカスタム サービス ホスト ファクトリを使用する で説明した WCF のカスタム サービス ホスト ファクトリ パターンを使用します。Microsoft AppFabric でホストされる Service Bus エンドポイントを使用した WCF サービスには、WCF のカスタム サービス ホスト ファクトリ パターンを使用する必要があります。

Microsoft Azure の Service Bus はバインディングのリレーとメッセージング機能をサポートし、クラウドで WCF サービスから Service Bus への簡単なアクセスを実現します。この記事は IIS での WCF サービスなどをホストする際に必要な構成の更新について説明します。また、障害からの自動復旧に必要なカスタム サービス ホスト ファクトリの WCF パターンの使用についても説明します。

表示:
© 2014 Microsoft