次の方法で共有

Windows Communication Foundation 4.5 の新機能

このトピックでは、Windows Communication Foundation (WCF) バージョン 4.5 の新機能について説明します。

WCF の代替としての gRPC

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

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

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

WCF の簡略化機能

WCF 4.5 アプリケーションの開発と保守が容易になるように、多くの作業が行われています。 詳細については、「 WCF 簡略化機能」を参照してください。

タスク ベースの非同期サポート

既定では、サービス参照の追加により、タスクを返す非同期サービス操作メソッドが生成されます。 これは、同期メソッドと非同期メソッドの両方に対して行われます。 これにより、新しいタスク ベースの非同期プログラミング モデルを使用して、サービス操作を非同期的に呼び出すことができます。 生成されたプロキシ メソッドを呼び出すと、WCF は非同期操作を表す Task オブジェクトを構築し、その Task を返します。 タスクは、操作が完了すると完了します。 非同期操作を実装するときは、タスク ベースの非同期操作として実装できます。 詳細については、「 同期操作と非同期操作」を参照してください。

生成された構成ファイルの簡略化

Visual Studio でサービス参照を追加するか、SvcUtil.exe ツールを使用すると、クライアント構成ファイルが生成されます。 以前のバージョンの WCF では、これらの構成ファイルには、その値が既定値であっても、すべてのバインド プロパティの値が含まれていました。 WCF 4.5 では、生成された構成ファイルには、既定値以外に設定されているバインド プロパティのみが含まれています。

詳細については、「 WCF 簡略化機能」を参照してください。

コントラクト優先の開発

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の aspNetCompatibilityEnabled セクションで<属性を true に設定する必要があります。さらに、この appDomain 内のすべてのサービスでは、>の プロパティを RequirementsMode または AspNetCompatibilityRequirementsAttribute に設定する必要があります。 既定では、 AspNetCompatibilityRequirementsAttribute は Allowed に設定されます。 詳細については、「 WCF サービスと ASP.NET」を参照してください。

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

構成を簡略化するために、トランスポート プロパティの既定値の数が変更されました。 詳細については、「 WCF 簡略化機能」を参照してください。

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas には、メッセージの作成時にエンコーダーが使用するメモリの量を制限する XML ディクショナリ リーダーの構成可能なクォータ値が含まれています。 これらのクォータは構成可能ですが、既定値は変更され、開発者が明示的に設定する必要が減ります。 詳細については、「 WCF 簡略化機能」を参照してください。

WCF 構成の検証

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

XML エディターのヒント

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

ストリーミングの機能強化

受信側が読み取りを行っていないか、読み取り速度が遅く、スケーラビリティが向上した場合に、送信側がスレッドをブロックしない真の非同期ストリーミングのサポートを追加しました。 クライアントが IIS でホストされている WCF サービスにストリーミング メッセージを送信するときのメッセージ バッファリングの制限を削除しました。 詳細については、「 WCF 簡略化機能」を参照してください。

IIS を使用した HTTPS 経由でのエンドポイントの公開の簡略化

HTTPS 経由でのエンドポイントの公開を簡略化するために、HTTPS プロトコル マッピングが追加されました。 HTTPS エンドポイントを有効にするには、Web サイトに HTTPS バインドと SSL 証明書が構成されていることを確認し、サービスをホストする仮想ディレクトリに対して HTTPS を有効にします。 サービスに対してメタデータが有効になっている場合は、HTTPS 経由でも公開されます。

単一の WSDL ドキュメントの生成

一部のサード パーティの WSDL 処理スタックでは、xsd:import を介して他のドキュメントに依存する WSDL ドキュメントを処理できません。 WCF では、すべての WSDL 情報を 1 つのドキュメントで返すように指定できるようになりました。 単一の WSDL ドキュメントを要求するには、サービスからメタデータを要求するときに URI に "?singleWSDL" を追加します。

WebSocket のサポート

WebSocket は、TCP と同様のパフォーマンス特性を備えたポート 80 と 443 を介した真の双方向通信を提供するテクノロジです。 WebSocket トランスポート経由の通信をサポートするために、2 つの新しいバインドが追加されました。 NetHttpBinding と NetHttpsBinding. 詳細については、「 System-Provided バインディング」を参照してください。

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

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

財産 オン 新しい既定値 詳細については、次を参照してください。
チャンネル初期化タイムアウト NetTcpBinding 30 秒 ChannelInitializationTimeout
バックログを監視する NetTcpBinding 12 * プロセッサの数 ListenBacklog
maxPendingAccepts コネクション指向トランスポートバインディング要素

SMSvcHost.exe		 2 * トランスポート用プロセッサの数

4 * SMSvcHost.exe のプロセッサの数		 MaxPendingAccepts Net.TCP ポート共有サービスの構成
最大待機接続数 コネクション指向トランスポートバインディング要素 12 * プロセッサの数 MaxPendingConnections
receiveTimeout SMSvcHost.exe 30 秒 Net.TCP ポート共有サービスの構成

コード内での WCF サービスの構成

Windows Communication Foundation (WCF) では、開発者が構成ファイルまたはコードを使用してサービスを構成できます。 構成ファイルは、サービスを配置した後に構成する必要がある場合に便利です。 構成ファイルを使用する場合、IT 専門家は構成ファイルを更新するだけで、再コンパイルの必要はありません。 ただし、構成ファイルの管理は複雑で難しくなる場合があります。 構成ファイルのデバッグはサポートされていません。また、構成要素は名前で参照されるため、構成ファイルの作成時にエラーが発生しやすく、構成ファイルの作成が困難になります。 WCF では、コードでサービスを構成することもできます。 WCF の以前のバージョン (4.0 以前) では、自己ホストのシナリオであれば、コードで簡単にサービスを構成できました。また、ServiceHost クラスを使用すると、ServiceHost.Open を呼び出す前にエンドポイントと動作を構成できました。 ただし、Web でホストされるシナリオでは、 ServiceHost クラスにアクセスできません。 Web ホスト サービスを構成するには、System.ServiceModel.ServiceHostFactory を作成して必要な構成を実行する ServiceHostFactory を作成する必要がありました。 .NET Framework 4.5 以降では、WCF を使用すると、自己ホスト サービスと Web ホスト サービスの両方をコードで簡単に構成できます。 詳細については、「 コードでの WCF サービスの構成」を参照してください。

ChannelFactory キャッシュ

WCF クライアント アプリケーションでは、 ChannelFactory<TChannel> クラスを使用して、WCF サービスとの通信チャネルを作成します。 ChannelFactory<TChannel> インスタンスを作成すると、次の操作が伴うため、オーバーヘッドが発生します。

  1. ContractDescription ツリーの構築

  2. 必要なすべての CLR 型の反映

  3. チャネル スタックの構築

  4. リソースの破棄

このオーバーヘッドを最小限に抑えるために、WCF では、WCF クライアント プロキシを使用しているときにチャネル ファクトリをキャッシュできます。 詳細については、「 チャネル ファクトリとキャッシュ」を参照してください。

圧縮とバイナリ エンコーダー

WCF 4.5 以降、WCF バイナリ エンコーダーは圧縮のサポートを追加します。 圧縮の種類は、 CompressionFormat プロパティを使用して構成されます。 クライアントとサービスの両方で、 CompressionFormat プロパティを構成する必要があります。 圧縮は、HTTP、HTTPS、および TCP プロトコルで機能します。 クライアントが圧縮を使用するように指定したが、サービスが圧縮をサポートしていない場合は、プロトコルの不一致を示すプロトコル例外がスローされます。 詳細については、「 メッセージ エンコーダーの選択」を参照してください。

UDP

UDP トランスポートのサポートが追加されました。これにより、開発者は "ファイア アンド フォーゲット" メッセージングを使用するサービスを作成できます。 クライアントはサービスにメッセージを送信し、サービスからの応答を期待しません。

複数認証のサポート

HTTP トランスポートとトランスポートのセキュリティを使用する場合、1 つの WCF エンドポイントで、IIS でサポートされている複数の認証モードをサポートするサポートが追加されました。 IIS を使用すると、仮想ディレクトリで複数の認証モードを有効にすることができます。この機能により、1 つの WCF エンドポイントで、WCF サービスがホストされている仮想ディレクトリで有効になっている複数の認証モードをサポートできます。

IDN のサポート

国際化ドメイン名を持つ WCF サービスを許可するサポートが追加されました。 詳細については、「 WCF と国際化ドメイン名」を参照してください。

Httpクライアント

HTTP 要求の操作をはるかに簡単にするために、 HttpClient という新しいクラスが追加されました。 詳細については、「HttpClientとガイドライン」を参照してください。

構成設定 IntelliSense

プロジェクトで定義されているカスタム属性の構成ファイルの属性値が IntelliSense をサポートし、構成の迅速かつ正確な操作を容易にできるようになりました。

構成ツールヒント

WCF 要素と属性に XML エディターのヒントが追加され、要素または属性の目的をより簡単かつ正確に識別できるようになりました。

データをクラスとして貼り付ける

WCF プロジェクトでは、XML で定義されているデータ型 (サービスで公開されるデータなど) をコード ページに直接貼り付けることができます。 XML 型は CLR 型として貼り付けられます。 詳細については、「 XML からのデータ型クラスの生成 」を参照してください。

WebServiceHost と既定のエンドポイント

Visual Studio 2010 では、エンドポイントを明示的に指定したかどうかにかかわらず、WebServiceHost によって既定のエンドポイントが自動的に作成されます。 Visual Studio 2012 以降では、エンドポイントが明示的に追加されていない場合にのみ、WebServiceHost によって既定のエンドポイントが作成されます。 クライアントが既定のエンドポイントを想定している場合は、エンドポイントを明示的に追加し、クライアントを指すことができます。 または、次の設定をアプリケーションの構成ファイルに追加して、WCF に以前の動作に戻すよう指示することもできます。

<appSettings>
    <add key="wcf:webservicehost:enableautomaticendpointscompatability" value="true"/>
  </appSettings>

IHttpCookieContainerManager

このインターフェイスは、 IChannelFactory<TChannel>によって公開されるため、クライアント側での Cookie の操作がはるかに簡単になります。 バインディングで AllowCookies が true に設定されている場合は、次のコードを使用して Cookie にアクセスできます。

IHttpCookieContainerManager cookieManager = factory.GetProperty<IHttpCookieContainerManager>();
System.Net.CookieContainer container = cookieManager.CookieContainer;

その後、 CookieContainerから Cookie を取得または設定できます。 AllowCookies が false に設定されている場合は、 OperationContext を使用して Cookie を手動で取得し、別の OperationContext またはメッセージ インスペクターを使用して他の要求で送信できます。 IHttpCookieContainerManager インターフェイスを使用すると、サービスを使用してユーザーを認証し、そのサービスから返された認証 Cookie を使用して他のサービスとの認証を行えます。

  • Last updated on