次の方法で共有

メッセージング プロトコル

Windows Communication Foundation (WCF) チャネル スタックでは、エンコード チャネルとトランスポート チャネルを使用して内部メッセージ表現をワイヤ形式に変換し、特定のトランスポートを使用して送信します。 Web サービスの相互運用性に使用される最も一般的なトランスポートは HTTP であり、Web サービスで使用される最も一般的なエンコードは、XML ベースの SOAP 1.1、SOAP 1.2、およびメッセージ送信最適化メカニズム (MTOM) です。

このトピックでは、 HttpTransportBindingElementで使用される次のプロトコルの WCF 実装の詳細について説明します。

仕様/ドキュメント:

このトピックでは、 TextMessageEncodingBindingElement および使用 MtomMessageEncodingBindingElement 次のプロトコルの WCF 実装の詳細について説明します。

仕様/ドキュメント:

このトピックでは、が使用する次のプロトコルの WCF 実装の詳細について説明します。

仕様/ドキュメント:

このトピックでは、次の XML 名前空間と関連するプレフィックスを使用します。

接頭辞 名前空間の Uniform Resource Identifier (URI)
s11 http://schemas.xmlsoap.org/soap/envelope
s12 http://www.w3.org/2003/05/soap-envelope
wsa http://www.w3.org/2004/08/addressing
wsam http://www.w3.org/2007/05/addressing/metadata
wsap http://schemas.xmlsoap.org/ws/2004/09/policy/addressing
wsa10 http://www.w3.org/2005/08/addressing
wsaw10 http://www.w3.org/2006/05/addressing/wsdl
xop http://www.w3.org/2004/08/xop/include
xmime http://www.w3.org/2004/06/xmlmime

http://www.w3.org/2005/05/xmlmime
dp http://schemas.microsoft.com/net/2006/06/duplex

SOAP 1.1 と SOAP 1.2

エンベロープと処理モデル

WCF では、Basic Profile 1.1 (BP11) と Basic Profile 1.0 (SSBP10) に続く SOAP 1.1 エンベロープ処理が実装されています。 SOAP 1.2 エンベロープ処理は、SOAP12-Part1 に従って実装されます。

このセクションでは、BP11 と SOAP12-Part1 に関して WCF によって行われる特定の実装の選択肢について説明します。

必須ヘッダー処理

WCF は、SOAP 1.1 および SOAP 1.2 の仕様で説明されている mustUnderstand マークされたヘッダーを処理するための規則に従います。次のバリエーションがあります。

WCF チャネル スタックに入るメッセージは、関連付けられたバインド要素 (テキスト メッセージ エンコード、セキュリティ、信頼できるメッセージング、トランザクションなど) によって構成された個々のチャネルによって処理されます。 各チャネルは、関連付けられている名前空間のヘッダーを認識し、それらを理解済みとしてマークします。 メッセージがディスパッチャーに入ると、操作フォーマッタは、対応するメッセージ/操作コントラクトで予期されるヘッダーを読み取り、認識済みとしてマークします。 その後、ディスパッチャーは、残りのヘッダーが認識されず、 mustUnderstand としてマークされているかどうかを確認し、例外をスローします。 受信者を対象とする mustUnderstand ヘッダーを含むメッセージは、受信者のアプリケーション コードでは処理されません。

このような階層化処理を使用すると、SOAP ノードのインフラストラクチャ レイヤーとアプリケーション レイヤーを分離できます。

  • B1111: メッセージが WCF インフラストラクチャ チャネル スタックによって処理された後、アプリケーションによって処理される前に、認識されないヘッダーが検出されます

    mustUnderstandヘッダー値は、SOAP 1.1 と SOAP 1.2 で異なります。 基本プロファイル 1.1 では、SOAP 1.1 メッセージの mustUnderstand 値が 0 または 1 である必要があります。 SOAP 1.2 では、0、1、 false、 true を値として使用できますが、 xs:boolean 値 (false、 true) の正規表現を出力することをお勧めします。

  • B1112: WCF は、SOAP エンベロープの SOAP 1.1 バージョンと SOAP 1.2 バージョンの両方に対して、 mustUnderstand 値 0 と 1 を出力します。 WCF は、mustUnderstand ヘッダー (0、1、false、true) のxs:booleanの値空間全体を受け入れます

SOAP エラー

WCF 固有の SOAP エラー実装の一覧を次に示します。

  • B2121: WCF は、SOAP 1.1 エラー コード ( s11:mustUnderstand、 s11:Client、 s11:Server) を返します。

  • B2122: WCF は、s12:Receiver、s12:Sender、s12:Receiverの SOAP 1.2 エラー コードを返します。

HTTP バインド

SOAP 1.1 HTTP バインド

WCF では、基本プロファイル 1.1 仕様セクション 3.4 に続く SOAP1.1 HTTP バインディングが実装され、次の説明が示されています。

  • B2211: WCF サービスは、HTTP POST 要求のリダイレクトを実装していません。

  • B2212: WCF クライアントは、3.4.8 に従って HTTP Cookie をサポートします。

SOAP 1.2 HTTP バインド

WCF では、SOAP 1.2-part 2 (SOAP12Part2) 仕様で説明されているように、SOAP 1.2 HTTP バインディングが実装されています。次の説明が記載されています。

SOAP 1.2 では、 application/soap+xml メディアの種類に対して省略可能なアクション パラメーターが導入されました。 このパラメーターは、WS-Addressing が使用されていないときに SOAP メッセージの本文を解析する必要なく、メッセージディスパッチを最適化するのに役立ちます。

  • R2221: application/soap+xml アクション パラメーターは、SOAP 1.2 要求に存在する場合、対応する WSDL バインディング内のwsoap12:operation要素のsoapAction属性と一致する必要があります。

  • R2222: SOAP 1.2 メッセージに存在する場合、 application/soap+xml アクション パラメーターは、WS-Addressing 2004/08 または WS-Addressing 1.0 が使用されている場合、 wsa:Action と一致する必要があります。

WS-Addressing が無効で、受信要求にアクション パラメーターが含まれていない場合、メッセージ Action は指定されていないと見なされます。

WS-Addressing

WCF では、次の 3 つのバージョンの WS-Addressing が実装されています。

  • WS-Addressing 2004/08

  • 1.0 Core (ADDR10-CORE) と SOAP バインディング (ADDR10-SOAP) をアドレス指定する W3C Web サービス

  • WS-Addressing 1.0 - メタデータ

エンドポイント参照

WCF が実装するすべてのバージョンの WS-Addressing は、エンドポイント参照を使用してエンドポイントを記述します。

エンドポイント参照と WS-Addressing バージョン

WCF では、WS-Addressing、特に EndpointReference 要素と W3C.WsAddressing.EndpointReferenceType クラス (WS-ReliableMessaging、WS-SecureConversation、WS-Trustなど) を使用するインフラストラクチャ プロトコルが多数実装されています。 WCF では、いずれかのバージョンの WS-Addressing を他のインフラストラクチャ プロトコルと共に使用できます。 WCF エンドポイントでは、エンドポイントごとに 1 つのバージョンの WS-Addressing がサポートされます。

R3111 の場合、WCF エンドポイントと交換されるメッセージで使用される EndpointReference 要素または型の名前空間は、このエンドポイントによって実装される WS-Addressing のバージョンと一致する必要があります。

たとえば、WCF エンドポイントが WS-ReliableMessaging を実装している場合、CreateSequenceResponse内のこのようなエンドポイントによって返されるAcksTo ヘッダーは、EncodingBinding要素がこのエンドポイントに対して指定する WS-Addressing バージョンを使用します。

エンドポイント参照とメタデータ

多くのシナリオでは、特定のエンドポイントのメタデータまたはメタデータへの参照を通信する必要があります。

B3121: WCF では、WS-MetadataExchange (MEX) 仕様セクション 6 で説明されているメカニズムを使用して、値または参照によるエンドポイント参照のメタデータを含めます。

WCF サービスで、トークン発行者によって発行されたセキュリティ アサーション マークアップ言語 (SAML) トークンを使用した認証が http://sts.fabrikam123.com必要なシナリオについて考えます。 WCF エンドポイントは、トークン発行者を指す入れ子になったsp:Issuer アサーションを持つsp:IssuedToken アサーションを使用して、この認証要件を記述します。 sp:Issuer アサーションにアクセスするクライアント アプリケーションは、トークン発行者エンドポイントと通信する方法を知っている必要があります。 クライアントは、トークン発行者に関するメタデータを認識している必要があります。 MEX で定義されているエンドポイント参照メタデータ拡張機能を使用して、WCF はトークン発行者メタデータへの参照を提供します。

<sp:IssuedToken>
  <sp:Issuer>
    <wsa10:Address>
      http://sts.fabrikam123.com
    </wsa10:Address>
    <wsa10:Metadata>
      <mex:Metadata>
        <mex:MetadataSection>
          <mex:MetadataReference>
            <wsa10:Address>
              http://sts.fabrikam123.com/mex
            </wsa10:Address>
          </mex:MetadataReference>
        </mex:MetadataSection>
      </mex:Metadata>
    </wsa10:Metadata>
  </sp:Issuer>
</sp:IssuedToken>

メッセージ アドレス指定ヘッダー

メッセージ ヘッダー

どちらの WS-Addressing バージョンでも、WCF では、仕様 wsa:To、 wsa:ReplyTo、 wsa:Action、 wsa:MessageID、および wsa:RelatesToで規定されている次のメッセージ ヘッダーが使用されます。

B3211: すべての WS-Addressing バージョンでは、WCF は優先されますが、すぐには生成されませんが、メッセージ ヘッダー wsa:FaultTo および wsa:FromWS-Addressing。

WCF アプリケーションとやり取りするアプリケーションは、これらのメッセージ ヘッダーを追加でき、それに応じて WCF によって処理されます。

参照パラメーターとプロパティ

WCF は、それぞれの仕様に従って、エンドポイント参照パラメーターと参照プロパティの処理を実装します。

B3221: WS-Addressing 2004/08 を使用するように構成されている場合、WCF エンドポイントは参照プロパティと参照パラメーターの処理を区別しません。

メッセージ交換パターン

Web サービス操作の呼び出しに関係するメッセージのシーケンスは、 メッセージ交換パターンと呼ばれます。 WCF では、一方向、要求/応答、双方向のメッセージ交換パターンがサポートされています。 このセクションでは、使用されているメッセージ交換パターンに応じて、メッセージ処理の WS-Addressing 要件について説明します。

このセクション全体を通して、要求元は最初のメッセージを送信し、レスポンダーは最初のメッセージを受信します。

One-Way メッセージ

WCF エンドポイントが一方向のパターンに従う特定の Action を持つメッセージをサポートするように構成されている場合、WCF エンドポイントは次の動作と要件に従います。 特に指定しない限り、WCF でサポートされている WS-Addressing の両方のバージョンに動作と規則が適用されます。

  • R3311: 要求元には、エンドポイント参照で指定されたすべての参照パラメーターの wsa:To、 wsa:Action、およびヘッダーを含める必要があります。 WS-Addressing 2004/08 を使用し、[参照プロパティ] をエンドポイント参照で指定する場合は、対応するヘッダーもメッセージに追加する必要があります。

  • B3312: 要求元には、 MessageID、 ReplyTo、および FaultTo ヘッダーを含めることができます。 受信側インフラストラクチャは、それらを無視し、アプリケーションに渡されます。

  • R3313: HTTP が使用され、HTTP 応答レッグでメッセージが送信されていない場合、レスポンダーは空の本文と HTTP 202 状態コードを含む HTTP 応答を送信する必要があります。

    HTTP トランスポートが使用中で、操作コントラクトがメッセージを一方向に宣言している場合でも、HTTP 応答はインフラストラクチャ メッセージの送信に使用できます。たとえば、信頼できるメッセージングは、HTTP 応答で SequenceAcknowledgement メッセージを送信できます。

  • B3314: WCF レスポンダーは、一方向メッセージに応答してエラー メッセージを送信しません。

Request-Reply

特定の Action を持つメッセージに対して WCF エンドポイントが要求/応答パターンに従って構成されている場合、WCF エンドポイントは以下の動作と要件に従います。 特に指定しない限り、動作と規則は、WCF でサポートされている WS-Addressing の両方のバージョンに適用されます。

  • R3321: 要求元は、エンドポイント参照で指定されたすべての参照パラメーターまたは参照プロパティ (またはその両方) の要求 wsa:To、 wsa:Action、 wsa:MessageID、ヘッダーに含める必要があります。

  • R3322: WS-Addressing 2004/08 を使用する場合は、 ReplyTo も要求に含まれている必要があります。

  • R3323: WS-Addressing 1.0 が使用され、 ReplyTo が要求に存在しない場合、 http://www.w3.org/2005/08/addressing/anonymous と等しい [address] プロパティを持つ既定のエンドポイント参照が使用されます。

  • R3324: 要求元は、応答メッセージに wsa:To、 wsa:Action、および wsa:RelatesTo ヘッダー、および要求の ReplyTo エンドポイント参照で指定されたすべての参照パラメーターまたは参照プロパティ (またはその両方) のヘッダーを含める必要があります。

障害に対処する Web サービス

R3411: WCF は、WS-Addressing 2004/08 で定義された次のエラーを生成します。

コード 原因
wsa:DestinationUnreachable メッセージは、このチャネルに対して確立された応答アドレスとは異なる ReplyTo で到着しました。宛先ヘッダーで指定されたアドレスをリッスンしているエンドポイントはありません。
wsa:ActionNotSupported エンドポイントに関連付けられているインフラストラクチャ チャネルまたはディスパッチャーは、 Action ヘッダーで指定されたアクションを認識しません。

R3412: WCF は、WS-Addressing 1.0 で定義された次のエラーを生成します。

コード 原因
wsa10:InvalidAddressingHeader wsa:To、wsa:ReplyTo、wsa:From、またはwsa:MessageIDを複製します。 同じRelationshipTypeでwsa:RelatesToを複製します。
wsa10:MessageAddressingHeaderRequired 必要なアドレス指定ヘッダーがありません。
wsa10:DestinationUnreachable メッセージは、このチャネルに対して確立された応答アドレスとは異なる ReplyTo で到着しました。 To ヘッダーで指定されたアドレスでリッスンしているエンドポイントはありません。
wsa10:ActionNotSupported Action ヘッダーで指定されたアクションは、エンドポイントに関連付けられているインフラストラクチャ チャネルまたはディスパッチャーによって認識されません。
wsa10:EndpointUnavailable RM チャネルは、このエラーを返します。エンドポイントは、 CreateSequence メッセージのアドレス指定ヘッダーの検査に基づいてシーケンスを処理しないことを示します。

上記の表のコードは、SOAP 1.1 の FaultCode にマップされ、SOAP 1.2 では (Code=Sender を使用して) SubCode にマップされます。

WSDL 1.1 バインディングおよび WS-Policy アサーション

WS-Addressing の使用を示す

WCF では、ポリシー アサーションを使用して、特定の WS-Addressing バージョンに対するエンドポイントのサポートを示します。

次のポリシー アサーションにはエンドポイント ポリシーサブジェクト [WS-PA] があり、エンドポイントから送受信されるメッセージは 2004/08 WS-Addressing 使用する必要があることを示します。

<wsap:UsingAddressing />

このポリシー アサーションは、WS-Addressing 2004/08 仕様を拡張します。

次のポリシー アサーションは、送受信されたメッセージが WS-Addressing 1.0 を使用する必要があることを示しています。

<wsam:Addressing/>

次のポリシー アサーションは、エンドポイント ポリシーサブジェクト [WS-PA] を持ち、エンドポイントから送受信されたメッセージが 2004/08 WS-Addressing 使用する必要があることを示します。

<wsaw10:UsingAddressing />

wsaw10:UsingAddressing要素は [WS-Addressing-WSDL] から借用され、その仕様に準拠した WS-Policy のコンテキストで使用されます(セクション 3.1.2)。

アドレス指定を使用しても、WSDL 1.1、SOAP 1.1、および SOAP 1.2 HTTP バインディングのセマンティクスは変更されません。 たとえば、アドレス指定と WSDL SOAP 1.x HTTP バインディングを使用するエンドポイントに送信される要求に対する応答が必要な場合は、HTTP 応答を使用して応答を送信する必要があります。

http 応答経由で送信される応答の場合、WS-AM アサーションは次のようになります。

<wsam:AnonymousResponses/>

完全なポリシー アサーションは次のようになります。

<wsam:Addressing>
    <wsp:Policy>
        <wsam:AnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

ただし、要求元とレスポンダーの間に 2 つの独立した逆 HTTP 接続を確立することでメリットを得られるメッセージ交換パターンがあります。たとえば、レスポンダーによって送信された一方向メッセージが要請されていません。

WCF には、基になる 2 つのトランスポート チャネルが複合二重チャネルを形成できる機能が用意されています。このチャネルは入力メッセージに使用され、もう 1 つのチャネルは出力メッセージに使用されます。 HTTP トランスポートの場合、複合二重は 2 つの逆 HTTP 接続を提供します。 要求元は、1 つの接続を使用してレスポンダーにメッセージを送信し、レスポンダーはもう一方を使用して要求元にメッセージを送信します。

個別の http 要求経由で送信された応答の場合、ws-am アサーションは

<wsam:NonAnonymousResponses/>

完全なポリシー アサーションは次のようになります。

<wsam:Addressing>
    <wsp:Policy>
        <wsam:NonAnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

WSDL 1.1 SOAP 1.x HTTP バインディングを使用するエンドポイントでエンドポイント ポリシー サブジェクト [WS-PA] を持つ次のアサーションを使用するには、要求元からレスポンダーに送信されるメッセージと、要求者に応答するメッセージに対して、それぞれ 2 つの個別の逆 HTTP 接続を使用する必要があります。

<cdp:CompositeDuplex/>

前のステートメントでは、要求メッセージの wsa:ReplyTo ヘッダーに次の要件があります。

  • R3514: エンドポイントに送信される要求メッセージ ReplyToは、エンドポイントが WSDL 1.1 SOAP 1.x HTTP バインディングを使用し、wsap10:UsingAddressingまたはwsap:UsingAddressingアサーションと結合されたポリシーの代替手段を持つ場合、[address] プロパティがhttp://www.w3.org/2005/08/addressing/anonymousと等しくないcdp:CompositeDuplexヘッダーを持つ必要があります。

  • R3515: エンドポイントに送信される要求メッセージには、http://www.w3.org/2005/08/addressing/anonymousと等しい[address] プロパティを持つReplyTo ヘッダーが必要です。エンドポイントが WSDL 1.1 SOAP 1.x HTTP バインディングを使用し、wsap10:UsingAddressing アサーションを使用するポリシーの代替手段があり、cdp:CompositeDuplex アサーションがアタッチされていない場合は、ReplyTo ヘッダーをまったく持たない必要があります。

  • R3516: エンドポイントに送信される要求メッセージには、エンドポイントが WSDL 1.1 SOAP 1.x HTTP バインディングを使用し、wsap:UsingAddressing アサーションを使用するポリシーの代替手段があり、cdp:CompositeDuplex アサーションがアタッチされていない場合は、http://www.w3.org/2005/08/addressing/anonymousと同じ[address] プロパティを持つReplyTo ヘッダーが必要です。

WS アドレス指定 WSDL では、wsa:ReplyTo ヘッダー (セクション 3.2) の要件を示す 3 つのテキスト値 (必須、省略可能、および禁止) を持つ要素<wsaw:Anonymous/>を導入することで、同様のプロトコル バインディングを記述しようとします。 残念ながら、このような要素定義は、WS-Policy のコンテキストでアサーションとして特に使用できません。これは、このような要素をアサーションとして使用する代替手段の交差をサポートするためにドメイン固有の拡張機能が必要であるためです。 このような要素定義は、ワイヤ上のエンドポイントの動作とは対照的に、 ReplyTo ヘッダーの値も示します。これにより、HTTP トランスポートに固有になります。

アクション定義

WS-Addressing 2004/08 では、wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault]要素のwsa:Action属性が定義されています。 WS-Addressing 1.0 WSDL バインディング (WS-ADDR10-WSDL) は、同様の属性 ( wsaw10:Action) を定義します。

2 つの唯一の違いは、WS-ADDR のセクション 3.3.2 と WS-ADDR10-WSDL のセクション 4.4.4 で説明されている既定のアクション パターン セマンティクスです。

同じ portType (または WCF の用語ではコントラクト) を共有するが、WS-Addressing の異なるバージョンを使用する 2 つのエンドポイントを持つことは妥当です。 ただし、Action は portType によって定義されており、 portTypeを実装するエンドポイント間で変更してはならないため、両方の既定のアクション パターンをサポートできなくなります。

この問題を解決するために、WCF では単一バージョンの Action 属性がサポートされています。

B3521: WCF は、WS-ADDR10-WSDL で定義されているwsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault]要素のwsaw10:Action属性を使用して、エンドポイントによって使用される WS-Addressing バージョンに関係なく、対応するメッセージのAction URI を決定します。

WSDL ポート内でエンドポイント参照を使用する

WS-ADDR10-WSDL セクション 4.1 では、 wsdl:port 要素が拡張され、 <wsa10:EndpointReference…/> 子要素が含まれるよう WS-Addressing 用語でエンドポイントが記述されます。 WCF は、WS-Addressing 2004/08 でこのユーティリティを展開し、 <wsa:EndpointReference…/> を wsdl:portの子要素として表示できるようにします。

  • R3531: エンドポイントに、 <wsaw10:UsingAddressing/> ポリシー アサーションを使用してポリシーの代替手段がアタッチされている場合、対応する wsdl:port 要素に子要素 <wsa10:EndpointReference …/>を含めることができます。

  • R3532: wsdl:portに子要素<wsa10:EndpointReference …/>が含まれている場合、wsa10:EndpointReference/wsa10:Address子要素の値は兄弟wsdl:port/wsdl:___location要素の@address属性の値と一致する必要があります。

  • R3533: エンドポイントに <wsap:UsingAddressing/> ポリシー アサーションを使用してポリシーの代替手段がアタッチされている場合、対応する wsdl:port 要素に子要素 <wsa:EndpointReference …/>を含めることができます。

  • R3534: wsdl:portに子要素<wsa:EndpointReference …/>が含まれている場合、wsa:EndpointReference/wsa:Address子要素の値は、兄弟wsdl:port/wsdl:___location要素の@address属性の値と一致する必要があります。

WS-Security を使用したコンポジション

WS-ADDR と WS-ADDR10 のセキュリティに関する考慮事項のセクションに従って、すべてのアドレス指定メッセージ ヘッダーをメッセージ本文と共に署名してバインドすることをお勧めします。

メッセージ整合性の保護に WS-Security を使用する場合、WS-Addressing メッセージ ヘッダーと、参照パラメーターまたはプロパティ (またはその両方) から得られたヘッダーは、メッセージの本文と共に署名する必要があります。

例示

One-Way メッセージ

このシナリオでは、送信者は受信側に一方向メッセージを送信します。 SOAP 1.2、HTTP 1.1、W3C WS-Addressing 1.0 が使用されます。

要求メッセージ構造: メッセージ ヘッダーには、 wsa10:To 要素と wsa10:Action 要素が含まれます。 メッセージ本文には、アプリケーション名前空間の特定の <app:Ping> 要素が含まれています。

HTTP ヘッダー: POST の宛先は、 wsa10:To 要素内の URI と一致します。

Content-Type ヘッダーには、SOAP 1.2 で必要に応じて application/soap+xml の値があります。 パラメーター charset と action が含まれています。 Content-Type ヘッダーの action パラメーターは、 wsa10:Action メッセージ ヘッダーの値と一致します。

POST http://fabrikam123.com/Service HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8;  
              action="http://fabrikam123.com/Service/OneWay"
Host: 131.107.72.15
Content-Length: 1501
Expect: 100-continue
Proxy-Connection: Keep-Alive
<s12:Envelope>
  <s12:Header>
    <wsa10:To s12:mustUnderstand="1">
        http://fabrikam123.com/Service
    </wsa10:To>
    <wsa10:Action s12:mustUnderstand="1">
        http://fabrikam123.com/Service/OneWay
    </wsa10:Action>
  </s12:Header>
  <s12:Body>
    <Ping xmlns="http://fabrikam123.com/Service/">
      <Text>Hello World</Text>
    </Ping>
  </s12:Body>
</s12:Envelope>

受信者は、空の HTTP 応答と状態 202 で応答します。 HTTP 応答の例:

HTTP/1.1 202 Accepted
Date: Fri, 15 Jul 2005 08:56:07 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50215
Cache-Control: private
Content-Length: 0

SOAP メッセージ転送の最適化メカニズム

このセクションでは、HTTP SOAP MTOM の WCF 実装の詳細について説明します。 MTOM テクノロジは、従来のテキスト/XML エンコードまたは WCF バイナリ エンコードと同じクラスの SOAP メッセージ エンコード メカニズムです。 MTOM には次のものが含まれます。

  • base64 でエンコードされたバイナリ データを含む XML 情報項目を個別のバイナリ部分に最適化する、[XOP] によって記述される XML エンコードおよびパッケージ化メカニズム。

  • XML Infoset と XOP パッケージの各バイナリ部分を個別の MIME パーツにシリアル化する XOP パッケージの MIME カプセル化。

  • SOAP 1.x エンベロープに適用される MIME XOP エンコード。

  • HTTP トランスポート バインド。

WCF では、HTTP 以外のトランスポートで MTOM を使用できます。 ただし、このトピックでは HTTP に焦点を当てます。

MTOM 形式は、MTOM 自体、XOP、および MIME をカバーする多数の仕様セットを活用します。 この仕様セットのモジュール性により、形式と処理セマンティクスに関する正確な要件を再構築することはやや困難になります。 このセクションでは、MTOM HTTP バインドの形式と処理の要件について説明します。

MTOM メッセージ エンコード

MTOM メッセージの生成

[XOP] セクション 3.1 では、base64 値を含む要素情報項目を使用して XML を抽象定義 XOP パッケージにエンコードするプロセスについて説明します。

次の一連の手順では、MTOM 固有のエンコード プロセスについて説明します。

  1. エンコードする SOAP エンベロープに、http://www.w3.org/2004/08/xop/includeの[namespace name]とIncludeの[local name]を含む要素情報項目が含まれていることを確認します。

  2. 空の MIME パッケージを作成します。

  3. 最適化する要素情報項目を元の XML Infoset 内で識別します。 項目を最適化するには、要素情報項目の [children] を構成する文字は、 xs:base64Binary の正規形式である必要があり (XSD-2、3.2.16 base64Binary を参照)、空白以外のコンテンツの前、インライン、または後に空白文字を含めてはなりません。

  4. 元の SOAP エンベロープのコピーである XOP SOAP エンベロープを作成しますが、前の手順で識別された各要素情報項目の子を、次のように構築された xop:Include 要素情報項目に置き換えます。

    1. 置換された文字を base64 でエンコードされたデータとして処理して、バイナリ データに変換します。

    2. 要件 R3133 と R3134 を満たす一意の Content-ID ヘッダー値を生成します。

    3. 値バイナリを含む Content-Transfer-Encoding MIME ヘッダーを生成します。

    4. 最適化対象の要素情報項目 (新しく挿入された xop:Include 要素情報項目の [親]) に xmime:contentType 属性情報項目がある場合は、 xmime:contentType 属性の値を持つ Content-Type MIME ヘッダーを生成します。

    5. base64 として処理された置換された文字からデコードされたバイナリ データによって形成されたコンテンツを含む新しいバイナリ MIME パーツを生成し、4b から Content-ID ヘッダー、4c から Content- Transfer-Encoding ヘッダー、手順 4d で生成された場合は Content-Type ヘッダーを生成します。

    6. 手順 4b で生成された Content-ID ヘッダー値から派生した値 cid: uri を使用して、 href 属性を xop:Include 要素に追加します。 外側の "<" 文字と ">" 文字を削除し、残りの文字列を URL エスケープして、プレフィックス cid:を追加します。 次の最小文字セットは、RFC1738およびRFC2396でエスケープする必要があります。 その他の文字はエスケープできます。

      Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"

  5. 手順 4 の XOP SOAP エンベロープを使用してルート MIME パーツを作成します。

  6. HTTP Content-Type ヘッダーを含む HTTP ヘッダーを書き込みます。

  7. MIME パッケージを記述します。

MTOM メッセージの処理

MTOM メッセージの処理は、前の「MTOM メッセージの生成」セクションで説明したプロセスとまったく逆です。

  1. ルート MIME パーツに Content-Type application/xop+xmlがあることを確認します。

  2. パッケージのルート MIME 部分を XML ドキュメントとして解析して、SOAP エンベロープを構築します。 文字エンコードは、ルート MIME パーツの Content-Type の charset パラメーターによって決まります。

  3. 構築された SOAP エンベロープ内の各要素情報項目について、その [children] プロパティの唯一のメンバーとして、 xop:Include 要素情報項目があります。

    1. cid:プレフィックスを削除し、xop:Include要素の@href属性の値内のすべての URI エスケープ シーケンス (RFC 2396) をエスケープ解除します。 結果文字列を "<"、">" で囲みます。

    2. 手順 3a で派生した文字列と一致する Content-ID ヘッダー値を持つ MIME パーツを見つけます。

    3. 各項目のchildrenプロパティに表示されるxop:Include要素情報項目を、手順 3b で識別された MIME パーツのエンティティ本体の正規の base64 エンコード (XSD-2、3.2.16 base64Binary を参照) を表す文字情報項目に置き換えます (実質的に、xop:Include要素情報項目をパッケージ パーツから再構築されたデータに置き換えます)。

HTTP Content-Type ヘッダー

以下は、MTOM 仕様自体に記載され、MTOM および RFC 2387 から派生した要件から派生した SOAP 1.x MTOM でエンコードされたメッセージの HTTP Content-Type ヘッダーの形式に関する WCF の説明の一覧です。

  • R4131: HTTP Content-Type ヘッダーには、マルチパート/関連 (大文字と小文字を区別しない) とそのパラメーターの値が必要です。 パラメーター名では大文字と小文字が区別されません。 パラメーターの順序は重要ではありません。

  • MIME メッセージの Content-Type ヘッダーの完全な Backus-Naur フォーム (BNF) は、RFC 2045 セクション 5.1 に記載されています。

  • R4132: HTTP Content-Type ヘッダーには、値 application/xop+xml 二重引用符で囲まれた型パラメーターが必要です。

RFC 2387 では二重引用符を使用する必要はありませんが、テキストでは、マルチパート/関連メディアの種類のすべてのパラメーターに "@" や "/" などの予約文字が含まれている可能性が高いため、二重引用符が必要であることが確認されます。

  • R4133: HTTP Content-Type ヘッダーには、SOAP 1.x エンベロープを含む MIME パーツの Content-ID ヘッダーの値を二重引用符で囲んだ開始パラメーターが必要です。 start パラメーターを省略した場合、最初の MIME パーツには SOAP 1.x エンベロープが含まれている必要があります。

  • R4134: SOAP 1.1 MTOM でエンコードされたメッセージの HTTP Content-Type ヘッダーには、テキスト/xml の値を二重引用符で囲んだ start-info パラメーターを含める必要があります。

  • R4135: SOAP 1.2 MTOM でエンコードされたメッセージの HTTP Content-Type ヘッダーには、 application/soap+xmlの値を含む start-info パラメーターを二重引用符で囲む必要があります。

  • R4136: SOAP 1.x MTOM でエンコードされたメッセージの HTTP Content-Type ヘッダーには、RFC 2046 セクション 5.1.1 で定義されている MIME 境界 BNF に一致する値 (二重引用符で囲む) を持つ境界パラメーターが必要です

    boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"
                    / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

    例：

    そうです

    Content-Type: multipart/related; type="application/xop+xml";start=" <part0@tempuri.org>";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1";start-info="text/xml"

    そうです

    Content-Type: Multipart/Related; type="application/xop+xml";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"

    間違った

    Content-Type: Multipart/Related; type=application/xop+xml;start=" <part0@tempuri.org>";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"

Infoset MIME パーツ

SOAP 1.x エンベロープは、XOP MIME パッケージのルート部分としてカプセル化され、多くの場合、 infoset パーツと呼ばれます。

  • R4141: SOAP 1.x エンベロープは、XOP MIME パッケージのルート部分としてカプセル化する必要があります。これは、 infoset 部分と呼ばれ、HTTP Content-Type から参照されます。

  • R4142: SOAP Infoset パーツには、 Content-ID、 Content-Transfer-Encoding、および Content-Typeの MIME ヘッダーが含まれている必要があります。

Content-ID ヘッダーの形式は、RFC 2045 で次のように定義されています。

"Content-ID" ":" msg-id

ここで、 msg-id は RFC 2822 で定義されています (RFC 822 に置き換わり、RFC 2045 で参照されます)。

msg-id    =       [CFWS] "<" id-left "@" id-right ">" [CFWS]

は、実質的に "<" と ">" で囲まれた電子メール アドレスです。 [CFWS]プレフィックスとサフィックスは、コメントを伝達するために RFC 2822 に追加されました。相互運用性を維持するために使用しないでください。

R4143: Infoset MIME パーツの Content-ID ヘッダーの値は、RFC 2822 の msg-id 実稼働に従い、 [CFWS] プレフィックスとサフィックス部分は省略する必要があります。

多くの MIME 実装では、"<" と ">" で囲まれた値が電子メール アドレスであり、電子メール アドレスに加えて "<" 、">" で囲まれたabsoluteURI使用される要件が緩和されています。 このバージョンの WCF では、次の形式の Content-ID MIME ヘッダーの値が使用されます。

Content-ID: <http://tempuri.org/0>

R4144: MTOM プロセッサは、次の緩やかな msg-idに一致する Content-ID ヘッダー値を受け入れる必要があります。

msg-id-relaxed =     [CFWS] "<" (absoluteURI | mail-address) ">" [CFWS]
mail-address   =     id-left "@" id-right

MIME (RFC 2045) は、MIME パーツのコンテンツのエンコードを伝える Content-Transfer-Encoding ヘッダーを提供します。 Content-Transfer-Encoding に定義されている既定値は 7 ビットであり、ほとんどの SOAP メッセージには適していないため、相互運用性を高めるには Content-Transfer-Encoding ヘッダーが必要です。

  • R4145: SOAP Infoset パーツには、Content-Transfer-Encoding ヘッダーが含まれている必要があります。

  • R4146: SOAP エンベロープ文字エンコードが UTF-8 の場合、Content-Transfer-Encoding ヘッダーの値は 8 ビットである必要があります。

  • R4147: SOAP エンベロープ文字エンコードが UTF-16 の場合、Content-Transfer-Encoding ヘッダーの値はバイナリである必要があります。

  • [XOP] セクション 5 に従って、

  • R4148: SOAP1.1 Infoset パーツには、メディア タイプ application/xop+xml およびパラメーター type="text/xml" および charset を含む Content-Type ヘッダーが含まれている必要があります

    Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"

  • R4149: SOAP 1.2 Infoset パーツには、メディアタイプ application/xop+xml とパラメータ type="application/soap+xml" および charsetを持つ Content-Type ヘッダーが含まれている必要があります。

    Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"

    XOP では、application/xop+xmlのcharsetパラメーターを省略可能に定義していますが、text/xml メディアタイプのcharsetパラメータの BP 1.1 要件と同様の相互運用性が必要です。

  • R41410: soap 1.x Infoset パーツの Content-Type ヘッダーには、 type パラメーターと charset パラメーターが存在する必要があります。

MTOM の WCF エンドポイントのサポート

MTOM の目的は、BASE64 でエンコードされたデータを最適化するために SOAP メッセージをエンコードすることです。 制約の一覧を次に示します。

  • R4151: base64 でエンコードされたデータを含む要素情報項目を最適化できます。

  • B4152: WCF は、base64 でエンコードされたデータを含み、長さが 1024 バイトを超える要素情報項目を最適化します。

MTOM を使用するように構成された WCF エンドポイントは、常に MTOM でエンコードされたメッセージを送信します。 必要な条件を満たすパーツがない場合でも、メッセージは MTOM でエンコードされます (SOAP エンベロープを含む 1 つの MIME パーツを含む MIME パッケージとしてシリアル化されます)。

MTOM の WS-Policy アサーション

WCF では、次のポリシー アサーションを使用して、エンドポイントによる MTOM の使用状況を示します。

<wsoma:OptimizedMimeSerialization />

  • R4211: 上記のポリシー アサーションにはエンドポイント ポリシーサブジェクトがあり、エンドポイントとの間で送受信されるすべてのメッセージを MTOM を使用して最適化する必要があることを指定します。

  • B4212: MTOM 最適化を使用するように構成されている場合、WCF エンドポイントは、対応する wsdl:bindingにアタッチされたポリシーに MTOM ポリシー アサーションを追加します。

WS-Security を使用したコンポジション

MTOM は、 text/xml および WCF バイナリ XML に似たエンコード メカニズムです。 MTOM は、WS-Security やその他の WS-* プロトコルを使用した自然な構成を提供します。WS-Security を使用してセキュリティで保護されたメッセージは、MTOM を使用して最適化できます。

例示

MTOM を使用してエンコードされた WCF SOAP 1.1 メッセージ

POST http://131.107.72.15/Mtom/svc/service.svc/Soap11MtomUTF8 HTTP/1.1
SOAPAction: "http://xmlsoap.org/echoBinaryAsString"
Content-Type: multipart/related;type="application/xop+xml";
              start="<http://tempuri.org/0>";start-info="text/xml";
       boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"
Host: 131.107.72.15
Content-Length: 1501
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <EchoBinaryAsString xmlns="http://xmlsoap.org/Ping">
      <array>
        <xop:Include
         href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206521093670"
         xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </array>
    </EchoBinaryAsString>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/1/632618206521093670>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
…Binary Content..
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1

MTOM を使用してエンコードされた WCF Secure SOAP 1.2 メッセージ

この例では、メッセージは、WS-Security を使用して保護されている MTOM と SOAP 1.2 を使用してエンコードされます。 エンコード用に識別されるバイナリ部分は、暗号化された署名と暗号化された本文に対応するEncryptedDataのCipherValue、BinarySecurityTokenの内容です。 WCF では、長さが 1024 バイト未満であるため、EncryptedKeyのCipherValueが最適化のために識別されなかったことに注意してください。

POST http://131.107.72.15/Mtom/service.svc/Soap12MtomSecureSignEncrypt HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";
              start="<http://tempuri.org/0>";
            boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3";
              start-info="application/soap+xml";
              action="http://xmlsoap.org/echoBinaryAsString"
Host: 131.107.72.15
Content-Length: 1941
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-5">
        <u:Created>2005-09-09T06:57:32.488Z</u:Created>
        <u:Expires>2005-09-09T07:02:32.488Z</u:Expires>
      </u:Timestamp>
      <o:BinarySecurityToken u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
        <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </o:BinarySecurityToken>
      <e:EncryptedKey Id="_1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">Xeg55vRyK3ZhAEhEf+YT0z986L0=</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>          <e:CipherValue>oQfpxwT8/SAGyZQzKE2b4yO6dXuQj7pwJ+5CGL3Rf7C06bQ5ttMoQ9GLJcQYkXTzin+WwHEgs5bj5ml9HKTW9QAU5JJ6lksdymmQvWP5ZtGPBVchO4sofEGoCKmBiZL/DYS/cnbzgnc/3a6NYnc10y2fWGaGLiqa00zijAw7o0Y=</e:CipherValue>
        </e:CipherData>
      </e:EncryptedKey>
      <c:DerivedKeyToken u:Id="_2" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
        <o:SecurityTokenReference>
          <o:Reference URI="#_1"/>
        </o:SecurityTokenReference>
        <c:Nonce>OrEPRX7fISIS4sXYWPMv3g==</c:Nonce>
      </c:DerivedKeyToken>
      <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:DataReference URI="#_3"/>
        <e:DataReference URI="#_4"/>
      </e:ReferenceList>
      <e:EncryptedData Id="_4" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:Reference URI="#_2"/>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>
          <e:CipherValue>
            <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F2%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
          </e:CipherValue>
        </e:CipherData>
      </e:EncryptedData>
    </o:Security>
  </s:Header>
  <s:Body u:Id="_0">
    <e:EncryptedData Id="_3" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:Reference URI="#_2"/>
        </o:SecurityTokenReference>
      </KeyInfo>
      <e:CipherData>
        <e:CipherValue>
          <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F3%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
        </e:CipherValue>
      </e:CipherData>
    </e:EncryptedData>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/1/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary content of BinarySecurityToken - X509 Certificate...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/2/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted primary signature...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/3/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted Body...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3--