WCF の単純化機能
ここでは、WCF アプリケーションの作成を容易にする新機能について説明します。
WCF の代替としての gRPC
gRPC は、WCF の一般的な代替手段である最新の RPC フレームワークです。 gRPC は HTTP/2 に基づいて構築されており、WCF と比べて以下のような多くの利点があります。
- パフォーマンス: gRPC は WCF よりもはるかに効率的であり、特に、実行時間の長い接続の場合に顕著です。
- スケーラビリティ: gRPC は、多数のクライアントとサーバーにスケーリングするように設計されています。
- セキュリティ: gRPC は、TLS や認証など、多様なセキュリティ メカニズムをサポートしています。
- クロスプラットフォーム: gRPC はプラットフォームに依存せず、多様なプログラミング言語で使用できます。
gRPC アプリの開発または WCF アプリの gRPC への移行の詳細については、次の項目を参照してください。
生成された構成ファイルの簡略化
Visual Studio でサービス参照を追加したり、SvcUtil.exe ツールを使用したりすると、クライアント構成ファイルが生成されます。 以前のバージョンの WCF では、このような構成ファイルには、各バインド プロパティの値が既定値であっても、その値が含まれていました。 WCF 4.5 では、生成された構成ファイルには、既定値以外の値に設定されているバインド プロパティのみが含まれます。
WCF 3.0 で生成された構成ファイルの例を次に示します。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
name="BasicHttpBinding_IService1" />
</client>
</system.serviceModel>
</configuration>
WCF 4.5 で生成された同じ構成ファイルの例を次に示します。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
name="BasicHttpBinding_IService1" />
</client>
</system.serviceModel>
</configuration>
コントラクト優先の開発
WCF では、コントラクト優先の開発がサポートされるようになりました。 svcutil.exe ツールには、WSDL ドキュメントからサービスおよびデータ コントラクトを生成できるようにする /serviceContract スイッチがあります。
ポータブル サブセット プロジェクトからのサービス参照の追加
ポータブル サブセット プロジェクトにより、複数の .NET 実装 (デスクトップ、Silverlight、Windows Phone、Xbox) をサポートしながら、.NET アセンブリのプログラマが 1 つのソース ツリーを保持しつつ、システムを構築できるようになります。 ポータブル サブセット プロジェクトでは、任意の .NET 実装上で使用できるアセンブリである .NET ポータブル ライブラリのみを参照します。 開発者から見れば、他の WCF クライアント アプリケーション内でサービス参照を追加するのと同じです。 詳細については、「ポータブル サブセット プロジェクトでサービス参照を追加する」を参照してください。
ASP.NET 互換性モードの既定値の変更
WCF には ASP.NET 互換性モードが用意されています。これにより、開発者は WCF サービスを作成する際に ASP.NET HTTP パイプラインの機能へのフル アクセスが付与されます。 このモードを使用するには、web.config の <serviceHostingEnvironment> セクションで aspNetCompatibilityEnabled 属性を true に設定する必要があります。さらに、この appDomain 内のサービスでは、AspNetCompatibilityRequirementsAttribute の RequirementsMode プロパティを Allowed または Required に設定しておく必要があります。 既定では、AspNetCompatibilityRequirementsAttribute は Allowed に設定され、既定の WCF サービス アプリケーション テンプレートでは、aspNetCompatibilityEnabled 属性が true に設定されます。 詳細については、「Windows Communication Foundation 4.5 の新機能」と「WCF サービスと ASP.NET」を参照してください。
ストリーミングの強化
非同期ストリーミングに対する新しいサポートが WCF に追加されました。 非同期ストリーミングを有効にするには、エンドポイントの DispatcherSynchronizationBehavior 動作をサービス ホストに追加し、その AsynchronousSendEnabled プロパティを
trueに設定します。 これにより、読み取りに時間のかかる複数のクライアントに対してサービスがストリーム メッセージを送信するときにスケーラビリティが得られます。 WCF では、クライアントごとに 1 つのスレッドがブロックされなくなり、別のクライアントにサービスを提供するためにスレッドを解放します。サービスが IIS でホストされるときのメッセージのバッファー処理に関する制限がなくなりました。 以前のバージョンの WCF では、ストリーム メッセージ転送を使用する IIS でホストされるサービスに対するメッセージを受信すると、ASP.NET はメッセージ全体を WCF に送信する前にバッファー処理しました。 これにより、メモリの大量消費が発生しました。 このバッファー処理が .NET Framework 4.5 では削除されており、IIS でホストされる WCF サービスでは、メッセージ全体が受信される前に着信ストリームの処理を開始できるようになったため、本当の意味でのストリーミングが可能になりました。 これにより、WCF は、メッセージにすぐに応答できるようになり、パフォーマンスは向上します。 さらに、着信要求に対する ASP.NET のサイズ制限である
maxRequestLengthの値を指定する必要がなくなりました。 このプロパティを設定した場合、このプロパティは無視されます。maxRequestLengthの詳細については、<httpRuntime> 構成要素に関するページを参照してください。 maxAllowedContentLength はまだ構成する必要があります。詳細については、IIS 要求の制限に関するページを参照してください。
トランスポートの新しい既定値
次の表は、変更された設定と追加情報の場所を示しています。
| プロパティ | On | 新しい既定値 | 説明 |
|---|---|---|---|
| channelInitializationTimeout | NetTcpBinding | 30 秒 | このプロパティは、.NET Framing プロトコルを使用して TCP 接続がそれ自体の認証にかかる時間を決定します。 クライアントは、サーバーが認証を実行するための十分な情報を得る前に初期データを送信する必要があります。 このタイムアウトは意図的に ReceiveTimeout (10 分) よりも小さい値に設定されます。これにより、悪意のある認証されていないクライアントは、長時間にわたってサーバーへの接続を保持できません。 既定値は 30 秒です。 詳細情報: ChannelInitializationTimeout |
| listenBacklog | NetTcpBinding | 16 * プロセッサの数 | このソケット レベルのプロパティは、キューに入れられる "受入保留中の" 要求の数を示します。 リッスン バックログ キューがいっぱいになると、新しいソケット要求は拒否されます。 詳細情報: ListenBacklog |
| maxPendingAccepts | ConnectionOrientedTransportBindingElement SMSvcHost.exe |
2 * トランスポート用のプロセッサの数 4 * SMSvcHost.exe 用のプロセッサの数 |
このプロパティは、サーバーがリスナーで待機できるチャネルの数を制限します。 MaxPendingAccepts が小さすぎると、待機しているすべてのチャネルが接続のサービスを開始する間隔が小さくなりますが、新しいチャネルがリッスンを開始できなくなります。 接続がこの間に到着した場合、サーバー上でこの接続を待機しているものがないため、接続は失敗します。 このプロパティは、MaxPendingConnections プロパティを大きな値に設定することで構成できます。 詳細については、MaxPendingAccepts に関するページおよび「Net.TCP ポート共有サービスを構成する」を参照してください |
| maxPendingConnections | ConnectionOrientedTransportBindingElement | 12 * プロセッサの数 | このプロパティは、トランスポートが受け入れたにもかかわらず ServiceModel ディスパッチャーによって取得されていない接続の数を制御します。 この値を設定するには、バインドの MaxConnections を使用するか、またはバインド要素の maxOutboundConnectionsPerEndpoint を使用してください。 詳細情報: MaxPendingConnections |
| receiveTimeout | SMSvcHost.exe | 30 秒 | このプロパティは、TCP フレーム データを読み取り、基になる接続からディスパッチする接続を実行するためのタイムアウトを指定します。 これは、SMSvcHost.exe サービスで受信接続からの前文データの読み取り操作を行う時間に制限を設定するために使用されます。 詳細については、「Net.TCP ポート共有サービスを構成する」を参照してください。 |
Note
これらの新しい既定値は、.NET Framework 4.5 がインストールされているコンピューターに WCF サービスを配置する場合のみ使用されます。 .NET Framework 4.0 がインストールされているコンピューターに同じサービスを配置すると、.NET Framework 4.0 の既定値が使用されます。 このような場合は、これらの設定を明示的に構成することをお勧めします。
XmlDictionaryReaderQuotas
XmlDictionaryReaderQuotas には、メッセージの作成中にエンコーダーで使用されるメモリの量を制限する XML ディクショナリ リーダーの構成可能なクォータ値が格納されます。 これらのクォータは構成可能ですが、開発者がこのクォータを明示的に設定する必要性を低くするために既定値が変更されました。 MaxReceivedMessageSize クォータは変更されていないため、メモリ使用量を引き続き制限して、XmlDictionaryReaderQuotas の複雑さを処理する必要性を回避できます。 次の表に、クォータ、クォータの新しい既定値、および各クォータの用途の簡単な説明を示します。
| クォータ名 | Default value | 説明 |
|---|---|---|
| MaxArrayLength | Int32.MaxValue | 許される最大配列長を取得または設定します。 このクォータは、XML リーダーが返すプリミティブ配列 (バイト配列など) の最大サイズを制限します。 このクォータは、XML リーダー自体のメモリ消費は制限しませんが、このリーダーを使用するコンポーネントのメモリ消費を制限します。 たとえば、 DataContractSerializer が MaxArrayLengthでセキュリティ保護されたリーダーを使用するときは、このクォータを超えるバイト配列を逆シリアル化することはありません。 |
| MaxBytesPerRead | Int32.MaxValue | 1 回の読み取りで返すことができる最大バイト数を取得または設定します。 このクォータは、要素の開始タグとその属性を読み取るときに、1 回の読み取り操作で読み取るバイト数を制限します (ストリーミングを使用しない場合、要素名自体がクォータに照らし合わせてカウントされることはありません)。 XML 属性が多すぎると、属性名は一意かどうかを確認する必要があるため、処理時間が大幅に増加する可能性があります。 MaxBytesPerRead によってこの脅威を軽減できます。 |
| MaxDepth | 128 ノードの深さ | このクォータは、XML 要素の入れ子の深さの最大値を制限します。 MaxDepth は MaxBytesPerReadと相互に関係しています。リーダーは常に、現在の要素とそのすべての先祖に関するデータをメモリ内に維持します。このため、リーダーのメモリ消費の最大値は、この 2 つの設定値の積に比例します。 深く入れ子になったオブジェクト グラフを逆シリアル化する場合、デシリアライザーはスタック全体にアクセスし、回復不可能な StackOverflowExceptionをスローするしかありません。 DataContractSerializer の場合も XmlSerializerの場合も、XML の入れ子構造とオブジェクトの入れ子構造との間に直接的な相関関係が存在します。 この脅威を軽減するには、MaxDepth を使用します。 |
| MaxNameTableCharCount | Int32.MaxValue | このクォータは、nametable で使用できる最大文字数を制限します。 nametable には、XML ドキュメントを処理するときに出現する特定の文字列 (名前空間やプレフィックスなど) が入っています。 これらの文字列はメモリ内でバッファー化されるので、ストリーミングが予想されるときは、このクォータを使用して過度のバッファーを防止します。 |
| MaxStringContentLength | Int32.MaxValue | このクォータは、XML リーダーが返す文字列の最大サイズを制限します。 このクォータは、XML リーダー自体のメモリ消費は制限しませんが、このリーダーを使用するコンポーネントのメモリ消費を制限します。 たとえば、 DataContractSerializer が MaxStringContentLengthでセキュリティ保護されたリーダーを使用するときは、このクォータを超える文字列を逆シリアル化することはありません。 |
重要
データのセキュリティ保護の詳細については、「セキュリティに関するデータの考慮事項」の「XML の安全な使用」を参照してください。
Note
これらの新しい既定値は、.NET Framework 4.5 がインストールされているコンピューターに WCF サービスを配置する場合のみ使用されます。 .NET Framework 4.0 がインストールされているコンピューターに同じサービスを配置すると、.NET Framework 4.0 の既定値が使用されます。 このような場合は、これらの設定を明示的に構成することをお勧めします。
WCF 構成検証
Visual Studio 内でのビルド プロセスの一環として、WCF 構成ファイルが検証されるようになりました。 検証に失敗すると、Visual Studio では検証エラーと警告の一覧が表示されます。
XML エディターのツールヒント
新規および既存の WCF サービスの開発者がサービスを構成するうえで役立つよう、Visual Studio の XML エディターでは、サービス構成ファイルに含まれる各構成要素とそのプロパティにツールヒントが表示されるようになりました。
BasicHttpBinding の機能強化
単一の WCF エンドポイントでさまざまな認証モードに応答できます。
WCF サービスのセキュリティ設定を IIS で制御できます。