WCF の簡略化機能

このトピックでは、WCF アプリケーションの記述を簡単にする新機能について説明します。

WCF の代替としての gRPC

gRPC は、WCF の一般的な代替手段である最新の RPC フレームワークです。 gRPC は HTTP/2 に基づいて構築されており、WCF に比して次のような多くの利点があります。

• パフォーマンス: gRPC は、特に実行時間の長い接続の場合、WCF よりもはるかに効率的です。
• スケーラビリティ: gRPC は、多数のクライアントとサーバーにスケーリングするように設計されています。
• セキュリティ: gRPC では、TLS や認証など、さまざまなセキュリティ メカニズムがサポートされています。
• クロスプラットフォーム: gRPC はプラットフォームに依存せず、さまざまなプログラミング言語で使用できます。

WCF アプリの開発または gRPC への移行の詳細については、次を参照してください。

• WCF 開発者に gRPC をお勧めする理由
• WCF と 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 ツールには /serviceContract スイッチがあり、WSDL ドキュメントからサービス コントラクトとデータ コントラクトを生成できます。

ポータブル サブセット プロジェクトからのサービス参照の追加

移植可能なサブセット プロジェクトを使用すると、.NET アセンブリ プログラマは、複数の .NET 実装 (デスクトップ、Silverlight、Windows Phone、Xbox) をサポートしながら、単一のソース ツリーとビルド システムを維持できます。 ポータブル サブセット プロジェクトは、.NET 実装で使用できるアセンブリである .NET ポータブル ライブラリのみを参照します。 開発者エクスペリエンスは、他の WCF クライアント アプリケーション内にサービス参照を追加する場合と同じです。 詳細については、「 ポータブル サブセット プロジェクトでのサービス参照の追加」を参照してください。

ASP.NET 互換モードの既定の変更

WCF には ASP.NET 互換モードが用意されています。これにより、WCF サービスを記述するときに、ASP.NET HTTP パイプラインの機能へのフル アクセス権を開発者に付与できます。 このモードを使用するには、web.configの > セクションで属性を true に設定する必要があります。さらに、この appDomain 内のすべてのサービスでは、RequirementsModeの AspNetCompatibilityRequirementsAttribute プロパティを 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 要求の制限」を参照してください。

トランスポートの新しい既定値

次の表では、変更された設定と、追加情報を検索する場所について説明します。

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas には、メッセージの作成時にエンコーダーが使用するメモリの量を制限する XML ディクショナリ リーダーの構成可能なクォータ値が含まれています。 これらのクォータは構成可能ですが、既定値が変更され、開発者が明示的に設定する必要が減ります。 MaxReceivedMessageSize クォータは変更されていないため、メモリ使用量を制限できるため、 XmlDictionaryReaderQuotasの複雑さに対処する必要はありません。 次の表に、クォータ、新しい既定値、各クォータの使用方法の簡単な説明を示します。

WCF 構成の検証

Visual Studio 内のビルド プロセスの一環として、WCF 構成ファイルが検証されるようになりました。 検証に失敗すると、検証エラーまたは警告の一覧が Visual Studio に表示されます。

XML エディターのヒント

新規および既存の WCF サービス開発者がサービスを構成できるように、Visual Studio XML エディターには、サービス構成ファイルの一部であるすべての構成要素とそのプロパティに関するヒントが用意されています。

BasicHttpBinding の機能強化

1. 単一の WCF エンドポイントがさまざまな認証モードに応答できるようにします。

2. WCF サービスのセキュリティ設定を IIS によって制御できるようにします