メッセージ エンコーダーの選択

この記事では、Windows Communication Foundation (WCF) に含まれるメッセージ エンコーダーのうち、バイナリ、テキスト、およびメッセージ送信の最適化メカニズム (MTOM) を選択するための条件について説明します。

WCF では、バインド要素のシーケンスで構成されるバインディングを使用して、エンドポイント間でネットワーク経由でデータを転送する方法を指定します。 メッセージ エンコーダーは、バインド スタック内のメッセージ エンコード バインド要素によって表されます。 バインディングには、セキュリティ バインディング要素や信頼できるメッセージング バインド要素、必要なメッセージ エンコード バインド要素、必要なトランスポート バインド要素など、オプションのプロトコル バインド要素が含まれます。

メッセージ エンコード バインド要素は、オプションのプロトコル バインド要素の下、および必要なトランスポート バインド要素の上にあります。 送信側では、メッセージ エンコーダーによって送信 Message がシリアル化され、トランスポートに渡されます。 受信側では、メッセージ エンコーダーはトランスポートから Message のシリアル化された形式を受け取り、存在する場合は上位のプロトコル 層に、そうでない場合はアプリケーションに渡します。

既存のクライアントまたはサーバーに接続する場合、メッセージを他の側が想定する方法でエンコードする必要があるため、特定のメッセージ エンコードの使用に関する選択肢がない場合があります。 ただし、WCF サービスを記述している場合は、それぞれ異なるメッセージ エンコードを使用して、複数のエンドポイントを介してサービスを公開できます。 これにより、クライアントは、最適なエンドポイント経由でサービスと通信するための最適なエンコードを選択できるだけでなく、クライアントに最適なエンコードを柔軟に選択できます。 複数のエンドポイントを使用すると、さまざまなメッセージ エンコーディングの利点を他のバインド要素と組み合わせることもできます。

System-Provided エンコーダー

WCF には、次の 3 つのクラスで表される 3 つのメッセージ エンコーダーが含まれています。

• TextMessageEncodingBindingElementテキスト メッセージ エンコーダーでは、プレーン XML エンコードと SOAP エンコードの両方がサポートされます。 テキスト メッセージ エンコーダーのプレーン XML エンコード モードは、テキスト ベースの SOAP エンコードと区別するために"plain old XML" (POX) と呼ばれます。 POX を有効にするには、 MessageVersion プロパティを None に設定します。 テキスト メッセージ エンコーダーを使用して、WCF 以外のエンドポイントと相互運用します。

• BinaryMessageEncodingBindingElementバイナリ メッセージ エンコーダーは、コンパクトなバイナリ形式を使用し、WCF から WCF への通信用に最適化されているため、相互運用できません。 これは、WCF が提供するすべてのエンコーダーの中で最もパフォーマンスの高いエンコーダーでもあります。

• MtomMessageEncodingBindingElementは、MTOM エンコードを使用したメッセージの文字エンコードとメッセージのバージョン管理を指定するバインディング要素です。 MTOM は、WCF メッセージでバイナリ データを送信するための効率的なテクノロジです。 MTOM エンコーダーは、効率と相互運用性のバランスを取ろうとします。 MTOM エンコードは、ほとんどの XML をテキスト形式で送信しますが、テキストに変換することなく、as-is送信することでバイナリ データの大きなブロックを最適化します。 効率の点では、WCF が提供するエンコーダーの中で、MTOM はテキスト (最も遅い) とバイナリ (最も高速) の間にあります。

メッセージ エンコーダーを選択する方法

次の表では、メッセージ エンコーダーの選択に使用される一般的な要因について説明します。 アプリケーションにとって重要な要素に優先順位を付け、これらの要因に最も適したメッセージ エンコーダーを選択します。 この表に記載されていないその他の要因と、アプリケーションで必要になる可能性があるカスタム メッセージ エンコーダーを必ず考慮してください。

注: バイナリ エンコーダーを使用する場合、XMLReader の作成時に IgnoreWhitespace 設定を使用しても効果はありません。 たとえば、サービス操作内で次の操作を行う場合です。

public void OperationContract(XElement input)
{
    Console.WriteLine("{0}", input.Value);
    int counter = 0;
    var xreader = input.CreateReader();
    var reader = XmlReader.Create(xreader, new XmlReaderSettings() { IgnoreWhitespace = true });
    while (reader.Read())
    {
        counter++;
    }

    Console.WriteLine("Read {0} lines with reader", counter);
}

IgnoreWhitespace 設定は無視されます。

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

WCF 4.5 以降、WCF バイナリ エンコーダーは圧縮のサポートを追加します。 これにより、WCF クライアントから圧縮されたメッセージを送信するために gzip/deflate アルゴリズムを使用したり、セルフホステッド WCF サービスからの圧縮メッセージで応答したりできます。 この機能により、HTTP トランスポートと TCP トランスポートの両方で圧縮が可能になります。 IIS ホスト サーバーを構成することで、IIS でホストされる WCF サービスが圧縮された応答を送信できるように常に有効にすることができます。 圧縮の種類は、 BinaryMessageEncodingBindingElement.CompressionFormat プロパティを使用して構成されます。 このプロパティは、次のいずれかの System.ServiceModel.Channels.CompressionFormat 列挙値に設定されます。

• Deflate
• GZip
• None

このプロパティは binaryMessageEncodingBindingElement でのみ公開されるため、この機能を使用するには、次のようなカスタム バインドを作成する必要があります。

<customBinding>
  <binding name="BinaryCompressionBinding">
    <binaryMessageEncoding compressionFormat ="GZip" />
    <httpTransport />
 </binding>
</customBinding>

クライアントとサービスの両方が圧縮メッセージの送受信に同意する必要があるため、compressionFormat プロパティはクライアントとサービスの両方の binaryMessageEncoding 要素で構成する必要があります。 サービスまたはクライアントのいずれかが圧縮用に構成されていないが、もう一方の側が圧縮用に構成されている場合、ProtocolException がスローされます。 圧縮の有効化は慎重に検討する必要があります。 圧縮は、主にネットワーク帯域幅がボトルネックである場合に便利です。 CPU がボトルネックになっている場合、圧縮によってスループットが低下します。 アプリケーションにメリットがあるかどうかを確認するには、シミュレートされた環境で適切なテストを行う必要があります

こちらも参照ください

• バインディング