バインディング要素のコレクションを表します。各バインディング要素は他のエンドポイントとの通信方法を記述しており、チャネル ファクトリ (クライアント側) およびチャネル リスナ (サービス側) に、整合性を保って組み込まれています。バインディングは、プロトコル チャネル、トランスポート チャネル、およびメッセージ エンコーダに対応するバインディング要素のコレクションを格納しています。プロトコル チャネルに対しては任意の数のバインディング要素が存在できますが、個々のトランスポートとメッセージ エンコーダに対して存在できるバインディング要素はただ 1 つだけです。バインディング内には、一般的に 6 層のバインディング要素があります。スタックの最下位のトランスポート バインディング要素とエンコーディング バインディング要素だけが必須です。エンコーディングは各バインディングに必要であるため、エンコーディングが指定されていない場合、Windows Communication Foundation (WCF) は既定のエンコーディングを自動的に追加します。既定では、HTTP および HTTPS トランスポートに対してはテキスト/XML、その他のトランスポートに対してはバイナリです。
各層のオプションの概要を次の表に示します。
各バインディング要素は、クライアントでのチャネル ファクトリの構築、およびサービスでのチャネル リスナの構築に対する仕様を提供します。たとえば、チャネル ファクトリ スタックを作成するときは、バインディング内の各バインディング要素に対し、スタック内に 1 つのチャネル ファクトリが存在します。同様のマッピングが、サービス上のスタックでのチャネル リスナにも適用されます。これらのエンドポイントの間でチャネル ベースの接続を確立するには、クライアントとサービスの間の整合性が不可欠です。その結果、各ファクトリとリスナは、両者を接続するチャネル スタック内の対応するチャネルの送信と受け入れを処理し、これらのチャネルは通信に使用するメッセージを送受信できます。
Binding の各インスタンスには、Name および Namespace があり、合わせてサービスのメタデータ内でそのインスタンスを一意に識別します。名前または名前空間が指定されていない場合は、WCF が既定値を自動的に追加します。既定の名前は nullNothingnullptrnull 参照 (Visual Basic では Nothing)、既定の名前空間は http://tempuri.org/ です。バインディングに対するこのユーザー名は、Scheme プロパティによって指定されるプロトコル名とは異なります。たとえば、HTTP バインディングをさらに追加したい場合は、それらに自由に名前を付けて、すべてのスキームを "http" に設定できます。Scheme に基づくアプリケーションまたはマシンの固有のディスパッチはありません。したがって、既知のプロトコルに対して追加のハンドラを登録できないという、よくある問題は避けられます。また、複数のバージョンのバインディングの並行使用も、各バージョンに異なる名前を付けることで、簡単に処理できます。
Binding クラスは、長時間リソースを停滞させることによるサービス拒否 (DOS) 攻撃を軽減するために、IDefaultCommunicationTimeouts インターフェイスを実装します。この実装により、接続の確立と終了や、メッセージの送受信に関連付けられている読み取りおよび書き込み操作についての通信タイムアウト値が指定されます。これらのタイムアウト値とその既定の操作を取得および設定するプロパティを、次の表に示します。
Binding を継承してバインディングを作成するときは、CreateBindingElements をオーバーライドする必要があります。
さらに、独自のバインディング要素を定義し、前の表で定義されている層の間のどこにでも挿入できます。詳細については、CustomBinding クラスを参照してください。