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 はプラットフォームに依存せず、多様なプログラミング言語で使用できます。
gRPC アプリの開発または WCF アプリの gRPC への移行の詳細については、次の項目を参照してください。
WCF の単純化機能
WCF 4.5 アプリケーションの開発および保守を容易にするために多大な労力が費やされてきました。 詳細については、「WCF の単純化機能」を参照してください。
タスク ベースの非同期のサポート
既定では、サービス参照の追加によって、タスクを返す非同期サービス操作メソッドが生成されます。 この処理は、同期メソッドと非同期メソッドの両方に対して行われます。 これにより、新しいタスク ベースの非同期プログラミング モデルを使用して、サービス操作を非同期に呼び出すことができます。 生成されたプロキシ メソッドを呼び出すと、WCF によって非同期操作を表すタスク オブジェクトが構築され、そのタスクが返されます。 操作が完了すると、タスクが完了します。 非同期操作を実装する場合は、タスクベースの非同期操作として実装できます。 詳細については、「同期操作と非同期操作」を参照してください。
生成された構成ファイルの簡略化
Visual Studio でサービス参照を追加したり、SvcUtil.exe ツールを使用したりすると、クライアント構成ファイルが生成されます。 以前のバージョンの WCF では、このような構成ファイルには、各バインド プロパティの値が既定値であっても、その値が含まれていました。 WCF 4.5 では、生成された構成ファイルには、既定値以外の値に設定されているバインド プロパティのみが含まれます。
詳細については、「WCF の単純化機能」を参照してください。
コントラクト優先の開発
WCF では、コントラクト優先の開発がサポートされるようになりました。 svcutil.exe には、WSDL ドキュメントからサービスおよびデータ コントラクトを生成できるようにする /serviceContract スイッチがあります。
ポータブル サブセット プロジェクトからのサービス参照の追加
ポータブル サブセット プロジェクトにより、.NET アセンブリ プログラマは 1 つのソース ツリーを保持しつつ、システムを構築できるようになります。また、複数の .NET プラットフォーム (デスクトップ、Silverlight、Windows Phone、および Xbox) も引き続きサポートされています。 ポータブル サブセット プロジェクトは、任意の .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 サービスと 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。 詳しくは、「システム指定のバインド」をご覧ください。
トランスポートの新しい既定値
次の表は、変更された設定と追加情報の場所を示しています。
| プロパティ | On | 新しい既定値 | 詳細については、「 |
|---|---|---|---|
| channelInitializationTimeout | NetTcpBinding | 30 秒 | ChannelInitializationTimeout |
| listenBacklog | NetTcpBinding | 12 * プロセッサの数 | ListenBacklog |
| maxPendingAccepts | ConnectionOrientedTransportBindingElement SMSvcHost.exe |
2 * トランスポート用のプロセッサの数 4 * SMSvcHost.exe 用のプロセッサの数 |
MaxPendingAcceptsNet.TCP ポート共有サービスを構成する |
| maxPendingConnections | ConnectionOrientedTransportBindingElement | 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> インスタンスを作成する場合は、次の操作が必要になるため、オーバーヘッドが生じます。
ContractDescription ツリーの構築
必要なすべての CLR 型の反映
チャネル スタックの構築
リソースの破棄
このオーバーヘッドを最小限に抑えるために、WCF では、WCF クライアント プロキシの使用時にチャネル ファクトリをキャッシュできます。 詳細については、「チャネル ファクトリとキャッシュ」を参照してください。
圧縮およびバイナリ エンコーダー
WCF 4.5 以降の WCF バイナリ エンコーダーでは、圧縮がサポートされます。 圧縮の種類は CompressionFormat プロパティで構成されます。 クライアントとサービスの両方で CompressionFormat のプロパティを構成する必要があります。 圧縮は、HTTP、HTTPS、および TCP の各プロトコルに対して有効です。 クライアントが圧縮を使用するよう指定しても、サービスで圧縮がサポートされていない場合は、プロトコルの不一致を示すプロトコルの例外がスローされます。 詳細については、「メッセージ エンコーダーを選択する」を参照してください。
UDP
UDP トランスポートのサポートが追加されたため、開発者は "ファイア アンド フォーゲット (撃ち放し)" メッセージングを使用するサービスを作成できるようになります。 クライアントは、サービスにメッセージを送信しますが、サービスからの応答を期待しません。
複数認証のサポート
HTTP トランスポートとトランスポート セキュリティを使用する際に、IIS でサポートされている複数の認証モードを単一の WCF エンドポイントで使用できるようになりました。 IIS では仮想ディレクトリで複数の認証モードを有効にできます。この機能によって、単一の WCF エンドポイントでは、WCF サービスがホストされている仮想ディレクトリで有効になっている複数の認証モードをサポートできます。
IDN サポート
国際化ドメイン名を持つ WCF サービスのためのサポートが追加されました。 詳細については、「WCF と国際化ドメイン名」を参照してください。
HttpClient
HTTP 要求の処理が容易になるように HttpClient という新しいクラスが追加されました。 詳しくは、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> によって公開されます。これにより、クライアント側でのクッキーの操作がさらに容易になります。 AllowCookies がバインドで true に設定されている場合は、次のコードを使用してクッキーにアクセスできます。
IHttpCookieContainerManager cookieManager = factory.GetProperty<IHttpCookieContainerManager>();
System.Net.CookieContainer container = cookieManager.CookieContainer;
その後、CookieContainer からクッキーを取得または設定できます。 AllowCookies が false に設定されている場合は、OperationContext を使用して手動でクッキーを取得し、別の OperationContext またはメッセージ インスペクターを使用して他の要求でそのクッキーを送信できます。 IHttpCookieContainerManager インターフェイスを使用すると、サービスを使用してユーザーを認証し、そのサービスから返される認証クッキーを使用して他のサービスで認証することができます。