Protokoły obsługi komunikatów

2025-06-17

Stos kanałów programu Windows Communication Foundation (WCF) wykorzystuje kanały kodowania i transportu, aby przekształcić wewnętrzną reprezentację komunikatów w format przewodu i wysłać go przy użyciu określonego transportu. Najczęstszym transportem używanym do współdziałania usług sieci Web jest PROTOKÓŁ HTTP, a najczęstszym kodowaniem używanym przez usługi sieci Web są oparte na kodzie XML SOAP 1.1, SOAP 1.2 i Mechanizm optymalizacji transmisji komunikatów (MTOM).

W tym temacie opisano szczegóły realizacji WCF dla następujących protokołów używanych przez HttpTransportBindingElement.

Specyfikacja/dokument:

HTTP 1.1
Powiązanie HTTP protokołu SOAP 1.1, sekcja 7
Powiązanie HTTP protokołu SOAP 1.2 Sekcja 7

W tym temacie opisano szczegóły implementacji WCF dla następujących protokołów, które są stosowane w TextMessageEncodingBindingElement i MtomMessageEncodingBindingElement.

Specyfikacja/dokument:

Ten temat obejmuje szczegóły implementacji WCF dla następujących protokołów używanych przez MtomMessageEncodingBindingElement.

Specyfikacja/dokument:

W tym temacie są używane następujące przestrzenie nazw XML i skojarzone prefiksy:

Prefiks	Jednolity identyfikator zasobu przestrzeni nazw (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 i SOAP 1.2

Model koperty oraz model przetwarzania

Program WCF implementuje przetwarzanie kopert protokołu SOAP 1.1 zgodnie z Profilem Podstawowym 1.1 (BP11) i Profilem Podstawowym 1.0 (SSBP10). Przetwarzanie kopert protokołu SOAP 1.2 jest implementowane zgodnie z SOAP12-Part1.

W tej sekcji opisano pewne wybory implementacji podjęte przez WCF w odniesieniu do BP11 i SOAP12-Part1.

Obowiązkowe przetwarzanie nagłówka

WCF przestrzega reguł przetwarzania nagłówków oznaczonych mustUnderstand opisanych w specyfikacji SOAP 1.1 i SOAP 1.2, z następującymi wariacjami.

Komunikat wchodzący do stosu kanału WCF jest przetwarzany przez poszczególne kanały skonfigurowane przez elementy powiązania związane z, na przykład: Kodowanie wiadomości tekstowych, Zabezpieczenia, Niezawodne przesyłanie wiadomości i Transakcje. Każdy kanał rozpoznaje nagłówki ze skojarzonej przestrzeni nazw i oznacza je jako zrozumiałe. Gdy komunikat wejdzie do dyspozytora, formatator operacji odczytuje nagłówki oczekiwane przez odpowiedni kontrakt komunikatu/operacji i oznacza je zrozumiałe. Następnie dyspozytor sprawdza, czy pozostałe nagłówki nie są zrozumiałe, ale oznaczone jako mustUnderstand i zgłasza wyjątek. Komunikaty zawierające mustUnderstand nagłówki, które są przeznaczone dla adresata, nie są przetwarzane przez kod aplikacji adresata.

Takie przetwarzanie warstwowe umożliwia rozdzielenie warstw infrastruktury i warstw aplikacji węzła PROTOKOŁU SOAP:

B1111: Nagłówki, które nie są zrozumiałe, są wykrywane po przetworzeniu komunikatu przez stos kanału infrastruktury WCF, ale przed przetworzeniem przez aplikację

Wartość nagłówka mustUnderstand różni się między SOAP 1.1 oraz SOAP 1.2. Profil podstawowy 1.1 wymaga, aby mustUnderstand wartość to 0 lub 1 dla komunikatów protokołu SOAP 1.1. Protokół SOAP 1.2 zezwala na wartości, takie jak 0, 1, false i true, ale zaleca emitowanie kanonicznej reprezentacji wartości xs:boolean (false, true).
B1112: WCF emituje mustUnderstand wartości 0 i 1 dla obu wersji protokołu SOAP 1.1 i SOAP 1.2 koperty protokołu SOAP. Program WCF akceptuje całą przestrzeń wartości dla nagłówka xs:booleanmustUnderstand (0, 1, false, true)

Błędy protokołu SOAP

Poniżej znajduje się lista implementacji błędów protokołu SOAP specyficznych dla programu WCF.

B2121: Program WCF zwraca następujące kody błędów protokołu SOAP 1.1: s11:mustUnderstand, s11:Clienti s11:Server.
B2122: Program WCF zwraca następujące kody błędów protokołu SOAP 1.2: s12:MustUnderstand, s12:Senderi s12:Receiver.

Powiązanie HTTP

Powiązanie HTTP protokołu SOAP 1.1

Program WCF implementuje powiązanie HTTP z protokołem SOAP1.1 zgodnie ze specyfikacją Profilu podstawowego 1.1, sekcja 3.4, wraz z następującymi wyjaśnieniami:

B2211: Usługa WCF nie implementuje przekierowania żądań HTTP POST.
B2212: Klienci WCF obsługują pliki cookie HTTP zgodnie z 3.4.8.

Powiązanie HTTP protokołu SOAP 1.2

WCF implementuje powiązanie HTTP protokołu SOAP 1.2 zgodnie z opisem w specyfikacji SOAP 1.2-part 2 (SOAP12Part2) z następującymi wyjaśnieniami.

Protokół SOAP 1.2 wprowadził opcjonalny parametr akcji dla typu nośnika application/soap+xml . Ten parametr jest przydatny do optymalizacji wysyłania komunikatów bez konieczności analizowania treści komunikatu PROTOKOŁU SOAP, gdy WS-Addressing nie jest używany.

R2221: Parametr akcji application/soap+xml, jeśli jest obecny w żądaniu SOAP 1.2, musi być zgodny z atrybutem soapAction na elemencie wsoap12:operation wewnątrz odpowiedniego powiązania WSDL.
R2222: Parametr application/soap+xml akcji, gdy jest obecny w komunikacie protokołu SOAP 1.2, musi być zgodny z wsa:Action w przypadku użycia WS-Addressing 2004/08 lub WS-Addressing 1.0.

Jeśli WS-Addressing jest wyłączona, a żądanie przychodzące nie zawiera parametru akcji, komunikat Action jest uznawany za nieokreślony.

WS-Addressing

Program WCF implementuje 3 wersje adresowania WS:

Adresowanie WS 2004/08
Adresowanie usług sieciowych W3C 1.0 Core (ADDR10-CORE) i powiązania protokołu SOAP (ADDR10-SOAP)
WS-Addressing 1.0 — metadane

Referencje punktów końcowych

Wszystkie wersje WS-Addressing implementujące program WCF używają odwołań do punktów końcowych w celu opisania punktów końcowych.

Odnośniki do punktów końcowych i wersje WS-Addressing

WCF implementuje liczne protokoły infrastruktury, które korzystają z WS-Addressing, zwłaszcza z elementu EndpointReference i klasy W3C.WsAddressing.EndpointReferenceType (na przykład WS-ReliableMessaging, WS-SecureConversation oraz WS-Trust). Program WCF obsługuje korzystanie z jednej z wersji WS-Addressing z innymi protokołami infrastruktury. Punkty końcowe programu WCF obsługują jedną wersję WS-Addressing na punkt końcowy.

W przypadku R3111 przestrzeń nazw elementu lub typu EndpointReference, używanego w komunikatach wymienianych z punktem końcowym WCF, musi odpowiadać wersji WS-Addressing, zaimplementowanej przez ten punkt końcowy.

Jeśli na przykład punkt końcowy WCF implementuje funkcję WS-ReliableMessaging, nagłówek AcksTo zwrócony przez taki punkt końcowy używa wewnątrz CreateSequenceResponse wersję WS-Addressing, którą element EncodingBinding określa dla tego punktu końcowego.

Odwołania do punktu końcowego i metadane

Wiele scenariuszy wymaga komunikacji metadanych lub odwołania do metadanych dla danego punktu końcowego.

B3121: WCF wykorzystuje mechanizmy opisane w Sekcji 6 specyfikacji WS-MetadataExchange (MEX) w celu uwzględnienia metadanych dla odwołań do punktu końcowego przez wartość lub przez odwołanie.

Rozważmy scenariusz, w którym usługa WCF wymaga uwierzytelniania przy użyciu tokenu SAML (Security Assertions Markup Language) wystawionego przez wystawcę tokenu pod adresem http://sts.fabrikam123.com. Punkt końcowy programu WCF opisuje to wymaganie uwierzytelniania przy użyciu sp:IssuedToken asercji z zagnieżdżonym sp:Issuer asercją wskazującą wystawcę tokenu. Aplikacje klienckie, które uzyskują dostęp do sp:Issuer asercji, muszą wiedzieć, jak komunikować się z punktem końcowym wystawcy tokenu. Klient musi znać metadane wystawcy tokenu. Korzystając z rozszerzeń metadanych referencji punktu końcowego zdefiniowanych w MEX, WCF zapewnia odwołanie do metadanych wystawcy tokenu.

<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>

Nagłówki adresowania komunikatów

Nagłówki komunikatów

W przypadku obu wersji WS-Addressing program WCF używa następujących nagłówków komunikatów zgodnie ze specyfikacjami wsa:To, , wsa:ReplyTo, wsa:Action, wsa:MessageIDi wsa:RelatesTo.

B3211: Dla wszystkich wersji WS-Addressing program WCF honoruje nagłówki komunikatów WS-Addressing wsa:FaultTo i wsa:From, ale nie generuje ich automatycznie.

Aplikacje, które wchodzą w interakcję z aplikacjami WCF, mogą dodawać te nagłówki komunikatów, a program WCF odpowiednio je przetworzy.

Parametry i właściwości odwołania

Program WCF implementuje przetwarzanie parametrów referencyjnych punktu końcowego i właściwości odwołania zgodnie z odpowiednimi specyfikacjami.

B3221: Po skonfigurowaniu do używania WS-Addressing 2004/08 punkty końcowe WCF nie rozróżniają między właściwościami odwołania a parametrami referencyjnymi podczas przetwarzania.

Wzorce wymiany komunikatów

Sekwencja komunikatów zaangażowanych w wywołanie operacji usługi sieci Web jest określana jako wzorzec wymiany komunikatów. WCF obsługuje wzorce wymiany komunikatów jednokierunkowych, żądanie-odpowiedź i dupleksowe. W tej sekcji wyjaśniono WS-Addressing wymagania dotyczące przetwarzania komunikatów w zależności od używanego wzorca wymiany komunikatów.

W tej sekcji osoba żądający wysyła pierwszy komunikat, a osoba odpowiadająca otrzymuje pierwszą wiadomość.

komunikat One-Way

Jeśli punkt końcowy programu WCF jest skonfigurowany do obsługi komunikatów przy użyciu jednokierunkowego wzorca, punkt końcowy programu WCF jest zgodny z następującymi zachowaniami i wymaganiami. O ile nie określono inaczej, zachowania i reguły mają zastosowanie do obu wersji WS-Addressing obsługiwanych w programie WCF:

R3311: Obiekt żądający musi zawierać wsa:To, wsa:Action oraz nagłówki dla wszystkich parametrów referencyjnych określonych przez odwołanie do punktu końcowego. Gdy jest używana WS-Addressing 2004/08, a [właściwości odwołania] są określane przez odwołanie do punktu końcowego, należy również dodać odpowiednie nagłówki do komunikatu.
B3312: Żądający może zawierać nagłówki MessageID, ReplyTo i FaultTo. Infrastruktura odbiornika je zignoruje i zostanie przekazana do aplikacji.
R3313: Jeśli protokół HTTP jest używany i żaden komunikat nie jest wysyłany na część odpowiedzi HTTP, wysyłający odpowiedź musi wysłać odpowiedź HTTP z pustą treścią i kodem stanu HTTP 202.

Gdy transport HTTP jest używany, a kontrakt operacji deklaruje komunikat jako jednokierunkowy, odpowiedź HTTP może być nadal używana do wysyłania wiadomości infrastrukturalnych — na przykład komunikacja niezawodna może wysyłać komunikat SequenceAcknowledgement w odpowiedzi HTTP.
B3314: Odpowiednik WCF nie wysyła wiadomości o błędzie w odpowiedzi na jednokierunkową wiadomość.

Request-Reply

Po skonfigurowaniu punktu końcowego programu WCF dla komunikatu z daną Action wartością zgodnie ze wzorcem żądania-odpowiedzi punkt końcowy programu WCF jest zgodny z poniższymi zachowaniami i wymaganiami. O ile nie określono inaczej, zachowania i reguły mają zastosowanie do obu wersji WS-Addressing obsługiwanych w programie WCF:

R3321: Wnioskodawca musi zawrzeć w żądaniu wsa:To, wsa:Action, wsa:MessageID, i nagłówki dla wszystkich parametrów odniesienia lub właściwości odniesienia (lub obu) określonych przez odniesienie do punktu końcowego.
R3322: Gdy używany jest WS-Addressing 2004/08, należy również dołączyć ReplyTo do żądania.
R3323: Jeśli jest używana WS-Addressing 1.0 i ReplyTo nie występuje w żądaniu, jest używane domyślne odwołanie do punktu końcowego z właściwością [address] równą http://www.w3.org/2005/08/addressing/anonymous .
R3324: Żądający musi uwzględniać nagłówki wsa:To, wsa:Action i wsa:RelatesTo w komunikacie odpowiedzi oraz nagłówki dla wszystkich parametrów lub właściwości odwołania (lub obu), określonych przez odniesienie do punktu końcowego ReplyTo w żądaniu.

Usługi sieci Web dotyczące błędów

R3411: Program WCF generuje następujące błędy zdefiniowane przez WS-Addressing 2004/08.

Kod	Przyczyna
`wsa:DestinationUnreachable`	Wiadomość została wysłana z `ReplyTo` innym adresem niż adres odpowiedzi ustanowiony dla tego kanału; nie ma punktu końcowego nasłuchiwania pod adresem określonym w nagłówku Do.
`wsa:ActionNotSupported`	kanały infrastruktury lub dyspozytor związany z punktem końcowym nie rozpoznają działania określonego w nagłówku `Action`.

R3412: Program WCF generuje następujące błędy zdefiniowane przez WS-Addressing 1.0.

Kod	Przyczyna
`wsa10:InvalidAddressingHeader`	Zduplikowane `wsa:To`, `wsa:ReplyTo`, `wsa:From` lub `wsa:MessageID`. Zduplikuj `wsa:RelatesTo` o tym samym `RelationshipType`.
`wsa10:MessageAddressingHeaderRequired`	Brak wymaganego nagłówka adresowania.
`wsa10:DestinationUnreachable`	Wiadomość została wysłana z `ReplyTo` innym adresem niż adres odpowiedzi ustanowiony dla tego kanału. Brak punktu końcowego nasłuchiwania pod adresem określonym w nagłówku Do.
`wsa10:ActionNotSupported`	Akcja określona w nagłówku `Action` nie jest rozpoznawana przez kanały infrastruktury ani moduł zarządzający związany z punktem końcowym.
`wsa10:EndpointUnavailable`	Kanał RM zwraca ten błąd, wskazując, że punkt końcowy nie przetworzy sekwencji na podstawie analizy nagłówków adresowych wiadomości `CreateSequence`.

Kod w poprzednich tabelach mapuje na FaultCode w SOAP 1.1 i SubCode (z Code=Sender) w SOAP 1.2.

Powiązania WSDL 1.1 i Asercje WS-Policy

Wskazywanie użycia WS-Addressing

WCF używa deklaracji zasad do wskazywania obsługi dla punktu końcowego dla konkretnej wersji WS-Addressing.

Następująca asercja polityki ma temat zasad punktu końcowego [WS-PA] i wskazuje, że komunikaty wysyłane i odbierane z punktu końcowego muszą używać WS-Addressing 2004/08.

<wsap:UsingAddressing />

Ta deklaracja polityki rozszerza specyfikację WS-Addressing 2004/08.

Następujące potwierdzenie zasad oznacza, że komunikaty wysłane/odebrane muszą używać WS-Addressing 1.0.

<wsam:Addressing/>

Następujący element polityki ma temat polityki punktu końcowego [WS-PA] i wskazuje, że komunikaty wysyłane i odbierane z punktu końcowego muszą używać protokołu WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

Element wsaw10:UsingAddressing jest pożyczany z [WS-Addressing-WSDL] i jest używany w kontekście WS-Policy zgodnie ze specyfikacją, sekcja 3.1.2.

Użycie adresowania nie zmienia semantyki powiązań HTTP WSDL 1.1, SOAP 1.1 i SOAP 1.2. Jeśli na przykład oczekiwana jest odpowiedź na żądanie wysyłane do punktu końcowego korzystającego z powiązania HTTP adresowania i protokołu WSDL SOAP 1.x, odpowiedź musi zostać wysłana przy użyciu odpowiedzi HTTP.

W przypadku odpowiedzi wysyłanych w odpowiedzi HTTP asercja WS-AM:

<wsam:AnonymousResponses/>

Pełne potwierdzenie zasad może wyglądać następująco:

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

Istnieją jednak wzorce wymiany komunikatów, które korzystają z dwóch niezależnych połączeń HTTP ustanowionych między obiektem żądający i obiektem odpowiadającym, na przykład niepożądanych jednokierunkowych komunikatów wysyłanych przez obiekt odpowiadający.

Program WCF oferuje funkcję, za pomocą której dwa podstawowe kanały transportu mogą tworzyć kanał złożony dwukierunkowy, w którym jeden kanał jest używany do wprowadzania komunikatów, a drugi jest używany do obsługi komunikatów wyjściowych. W przypadku transportu HTTP, composite duplex zapewnia dwa odwrotne połączenia HTTP. Obiekt żądający używa jednego połączenia do wysyłania komunikatów do obiektu odpowiadającego, a osoba odpowiadająca używa drugiego do wysyłania komunikatów z powrotem do obiektu żądającego.

Asercja ws-am jest w przypadku odpowiedzi wysyłanych za pośrednictwem oddzielnych żądań HTTP

<wsam:NonAnonymousResponses/>

Pełne potwierdzenie zasad może wyglądać następująco:

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

Użycie następującej asercji, która ma temat zasad punktu końcowego [WS-PA], na punktach końcowych używających powiązań WSDL 1.1 SOAP 1.x HTTP wymaga dwóch oddzielnych połączeń HTTP do przesyłania komunikatów: jednego od żądającego do odpowiadającego i drugiego od odpowiadającego do żądającego.

<cdp:CompositeDuplex/>

Poprzednia instrukcja prowadzi do następujących wymagań w nagłówku wsa:ReplyTo dla komunikatów żądania:

R3514: Komunikaty żądania wysyłane do punktu końcowego muszą mieć nagłówek ReplyTo o właściwości [address] nierównej http://www.w3.org/2005/08/addressing/anonymous, jeśli punkt końcowy używa powiązania HTTP WSDL 1.1 SOAP 1.x i ma alternatywę polityki z asercją wsap10:UsingAddressing lub wsap:UsingAddressing, z dołączonym cdp:CompositeDuplex.
R3515: Żądania wiadomości wysyłane do punktu końcowego muszą mieć nagłówek ReplyTo z właściwością [address] równą http://www.w3.org/2005/08/addressing/anonymous, lub nie mieć nagłówka ReplyTo wcale, jeśli punkt końcowy używa powiązania HTTP protokołu WSDL 1.1 SOAP 1.x i ma alternatywę polityki z asercją wsap10:UsingAddressing oraz bez dołączonej asercji cdp:CompositeDuplex.
R3516: Żądania komunikatów, które są wysyłane do punktu końcowego, muszą mieć ReplyTo nagłówek z właściwością [address] równą http://www.w3.org/2005/08/addressing/anonymous, jeśli punkt końcowy używa powiązania HTTP protokołu WSDL 1.1 SOAP 1.x i ma alternatywę zasad z asercją wsap:UsingAddressing do której nie jest dołączona asercja cdp:CompositeDuplex.

Specyfikacja adresowania WS w WSDL próbuje opisać podobne powiązania protokołu, wprowadzając element <wsaw:Anonymous/>, który ma trzy wartości tekstowe (wymagana, opcjonalna i niedozwolona), aby wskazać wymagania dotyczące nagłówka wsa:ReplyTo (sekcja 3.2). Niestety, taka definicja elementu nie jest szczególnie użyteczna jako asercja w kontekście WS-Policy, ponieważ wymaga rozszerzeń specyficznych dla domeny do obsługi przecięcia się alternatyw przy użyciu takiego elementu jako asercji. Taka definicja elementu wskazuje również wartość nagłówka ReplyTo , a nie zachowanie punktu końcowego na przewodzie, co sprawia, że jest specyficzny dla transportu HTTP.

Definicja akcji

WS-Addressing 2004/08 definiuje wsa:Action atrybut dla wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementów. WS-Addressing 1.0 Powiązanie WSDL (WS-ADDR10-WSDL) definiuje podobny atrybut . wsaw10:Action

Jedyną różnicą między nimi jest domyślna semantyka wzorca akcji opisana odpowiednio w sekcji 3.3.2 WS-ADDR i sekcji 4.4.4 WS-ADDR10-WSDL.

Rozsądne jest posiadanie dwóch punktów końcowych, które dzielą ten sam portType (lub kontrakt w terminologii WCF), ale używają różnych wersji adresowania WS. Jednak biorąc pod uwagę fakt, że operacja jest zdefiniowana przez portType i nie powinna zmieniać się w punktach końcowych, które implementują portType, niemożliwe jest obsługiwanie obu domyślnych wzorców operacyjnych.

Aby rozwiązać te kontrowersje, program WCF obsługuje jedną wersję atrybutu Action .

B3521: WCF używa atrybutu wsaw10:Action na elementach wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] zgodnie z definicją w WS-ADDR10-WSDL, aby określić adres Action URI dla odpowiednich komunikatów, niezależnie od wersji WS-Addressing używanej przez punkt końcowy.

Używanie odwołania do punktu końcowego wewnątrz portu WSDL

WS-ADDR10-WSDL sekcja 4.1 rozszerza element wsdl:port, uwzględniając element podrzędny <wsa10:EndpointReference…/>, aby opisać punkt końcowy za pomocą terminów WS-Addressing. Program WCF rozszerza to narzędzie w WS-Addressing 2004/08, umożliwiając <wsa:EndpointReference…/> pojawić się jako element podrzędny wsdl:port.

R3531: Jeśli punkt końcowy ma dołączoną alternatywę zasad, która zawiera asercję <wsaw10:UsingAddressing/>, odpowiedni element wsdl:port może zawierać element podrzędny <wsa10:EndpointReference …/>.
R3532: Jeśli element wsdl:port zawiera element <wsa10:EndpointReference …/>podrzędny, wsa10:EndpointReference/wsa10:Address wartość elementu podrzędnego musi być zgodna z wartością @address atrybutu elementu równorzędnego wsdl:port/wsdl:location .
R3533: Jeśli punkt końcowy ma dołączoną alternatywę polityki z <wsap:UsingAddressing/> asercją zasad, odpowiedni wsdl:port element może zawierać element podrzędny <wsa:EndpointReference …/>.
R3534: Jeśli element wsdl:port zawiera element <wsa:EndpointReference …/>podrzędny , wsa:EndpointReference/wsa:Address wartość elementu podrzędnego musi być zgodna z wartością @address atrybutu elementu równorzędnego wsdl:port/wsdl:location .

Kompozycja z WS-Security

Zgodnie z sekcjami dotyczących względów bezpieczeństwa w WS-ADDR i WS-ADDR10 zaleca się podpisanie wszystkich nagłówków adresowania wiadomości wraz z treścią wiadomości, aby je ze sobą powiązać.

Jeśli WS-Security jest używana do ochrony integralności komunikatów, WS-Addressing nagłówki komunikatów, a także nagłówki wynikające z parametrów referencyjnych lub właściwości (lub obu) muszą być podpisane razem z treścią komunikatu.

Przykłady

komunikat One-Way

W tym scenariuszu nadawca wysyła jednokierunkowy komunikat do odbiorcy. Używane są protokoły SOAP 1.2, HTTP 1.1 i W3C WS-Addressing 1.0.

Struktura komunikatów żądania: nagłówki komunikatów zawierają elementy wsa10:To i wsa10:Action. Treść komunikatu zawiera określony <app:Ping> element z przestrzeni nazw aplikacji.

Nagłówki HTTP: miejsce docelowe w usłudze POST pasuje do identyfikatora URI w elemecie wsa10:To .

Nagłówek Content-Type ma wartość application/soap+xml wymaganą przez protokół SOAP 1.2. Parametry charset i action są uwzględniane. Parametr action nagłówka Content-Type odpowiada wartości nagłówka komunikatu 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>

Odbiorca odpowiada z pustą odpowiedzią HTTP i stanem 202. Przykład odpowiedzi 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

Mechanizm optymalizacji transmisji komunikatów PROTOKOŁU SOAP

W tej sekcji opisano szczegóły implementacji WCF dla protokołu HTTP SOAP MTOM. Technologia MTOM to mechanizm kodowania komunikatów SOAP tej samej klasy co tradycyjne kodowanie tekstu/XML lub kodowanie binarne WCF. MtOM obejmuje następujące elementy:

Mechanizm kodowania i pakowania XML opisany przez [XOP], który optymalizuje elementy informacji XML zawierające dane binarne zakodowane w formacie base64 na oddzielne części binarne.
Hermetyzacja MIME pakietu XOP, która serializuje zestaw informacji XML oraz każdą binarną część pakietu XOP do oddzielnej części MIME.
Kodowanie XOP MIME stosowane do koperty SOAP 1.x.
Powiązanie transportu HTTP.

Można używać modelu MTOM z transportami innych niż HTTP w programie WCF. Jednak w tym temacie skupimy się na protokole HTTP.

Format MTOM wykorzystuje duży zestaw specyfikacji obejmujących sam MTOM, XOP i MIME. Modułowość tego zestawu specyfikacji sprawia, że nieco trudno jest odtworzyć dokładne wymagania dotyczące semantyki formatu i przetwarzania. W tej sekcji opisano wymagania dotyczące formatu i przetwarzania powiązania HTTP MTOM.

Kodowanie komunikatów MTOM

Generowanie komunikatów MTOM

W sekcji [XOP] 3.1 opisano proces kodowania elementów informacyjnych XML o wartościach base64 do abstrakcyjnie zdefiniowanego pakietu XOP.

Poniższa sekwencja kroków opisuje proces kodowania specyficzny dla modelu MTOM:

Upewnij się, że koperta SOAP, która ma być zakodowana, nie zawiera żadnego elementu o wartości [namespace name] ustawionej na http://www.w3.org/2004/08/xop/include oraz [local name] ustawionej na Include.
Utwórz pusty pakiet MIME.
Zidentyfikuj element w oryginalnym zestawie informacji XML, które mają zostać zoptymalizowane. Aby elementy, które mają być zoptymalizowane, znaki tworzące [children] element informacji muszą mieć postać kanoniczną xs:base64Binary (zobacz XSD-2, 3.2.16 base64Binary) i nie mogą zawierać żadnych znaków odstępów poprzedzających, wbudowanych ani następujących po treści nienależącej do białych znaków.
Utwórz kopertę SOAP XOP, która jest kopią oryginalnej koperty SOAP, ale z elementami podrzędnymi każdego elementu informacyjnego określonego w poprzednim kroku zastąpionymi elementem informacyjnym xop:Include, skonstruowanym w następujący sposób:
1. Przekształć zastąpione znaki w dane binarne, przetwarzając je jako dane zakodowane w formacie base64.
2. Wygeneruj unikatową wartość nagłówka Content-ID, która spełnia wymagania R3133 i R3134.
3. Wygeneruj nagłówek MIME Content-Transfer-Encoding z wartością binarną.
4. Jeśli optymalizowany element informacyjny (element [nadrzędny] nowo wstawionego elementu xop:Include) ma element informacji o atrybucie xmime:contentType, wygeneruj nagłówek MIME Content-Type z wartością atrybutu xmime:contentType.
5. Wygeneruj nową binarną część MIME z zawartością utworzoną przez dane binarne zdekodowane z zastąpionych znaków przetworzonych jako base64, nagłówek Content-ID z 4b, nagłówek Content-Transfer-Encoding z 4c, nagłówek Content-Type, jeśli został wygenerowany w kroku 4d.
6. Dodaj atrybut href do elementu xop:Include z wartością cid: URI pochodzącą z wartości nagłówka Content-ID wygenerowanej w kroku 4b. Usuń otaczające znaki "<" i ">", zakoduj pozostały ciąg jako URL i dodaj prefiks cid:. Następujący minimalny zestaw znaków musi być zakodowany zgodnie z RFC1738 i RFC2396. Inne znaki można uniknić.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Utwórz główną część MIME z powłoką XOP SOAP z kroku 4.
Napisz nagłówki HTTP, w tym nagłówek HTTP Content-Type.
Napisz pakiet MIME.

Przetwarzanie komunikatów MTOM

Przetwarzanie komunikatu MTOM jest dokładnym odwróceniem procesu opisanego w poprzedniej sekcji "Generowanie komunikatów MTOM":

Upewnij się, że główna część MIME ma typ zawartości application/xop+xml.
Skonstruuj kopertę protokołu SOAP przez analizowanie głównej części MIME pakietu jako dokumentu XML. Kodowanie znaków jest określane przez charset parametr typu zawartości głównej części MIME.
Dla każdego elementu informacji o elemencie w skonstruowanej kopercie SOAP, która ma jako jedyny element członkowski jego właściwości xop:Include [podrzędne] element informacyjny elementu:
1. cid: Usuń prefiks i usuń wszystkie sekwencje ucieczki identyfikatora URI (RFC 2396) w wartości @href atrybutu xop:Include elementu. Ujmij ciąg wynikowy w znacznikach "<", ">".
2. Znajdź część MIME z wartością nagłówka Content-ID zgodną z ciągiem uzyskanym w kroku 3a.
3. xop:Include Zastąp jednostkę informacji o elemencie wyświetlaną we children właściwości każdego elementu jednostkami informacji o znakach, które reprezentują kanoniczne enkodowanie base64 (zobacz XSD-2, 3.2.16 base64Binary) treści jednostki części MIME zidentyfikowanej w kroku 3b, skutecznie zastępując element xop:Include danymi zrekonstruowanymi z części pakietu.

Nagłówek typu zawartości HTTP

Poniżej znajduje się lista wyjaśnień WCF dotyczących formatu nagłówka HTTP Content-Type komunikatu zakodowanego w SOAP 1.x przy użyciu kodowania MTOM, wynikającego z wymagań określonych w samej specyfikacji MTOM oraz z założeń MTOM i RFC 2387.

R4131: Nagłówek typu zawartości HTTP musi mieć wartość wieloczęściową/powiązaną (bez uwzględniania wielkości liter) i jej parametry. Nazwy parametrów są niewrażliwe na wielkość liter. Kolejność parametrów nie jest znacząca.
Pełny formularz Backus-Naur (BNF) nagłówka Content-Type dla komunikatów MIME znajduje się w RFC 2045, sekcja 5.1.
R4132: Nagłówek HTTP Content-Type musi mieć parametr typu z wartością application/xop+xml ujętą w podwójny cudzysłów.

Chociaż wymaganie używania podwójnych znaków cudzysłowu nie jest jawne w specyfikacji RFC 2387, tekst zauważa, że wszystkie parametry typu multipart/powiązanego typu nośnika najprawdopodobniej zawierają znaki zarezerwowane, takie jak "@" lub "/", a w związku z tym potrzebują podwójnych cudzysłowów.

R4133: Nagłówek typu zawartości HTTP powinien mieć parametr początkowy, którego wartość jest równa wartości nagłówka Content-ID tej części MIME, która zawiera kopertę SOAP 1.x, i powinna być ujęta w podwójny cudzysłów. Jeśli parametr początkowy zostanie pominięty, pierwsza część MIME musi zawierać kopertę PROTOKOŁU SOAP 1.x.
R4134: Nagłówek Content-Type HTTP dla zakodowanej wiadomości SOAP 1.1 MTOM musi zawierać parametr start-info z wartością "text/xml", ujętą w podwójny cudzysłów.
R4135: Nagłówek typu zawartości HTTP dla komunikatu zakodowanego w formacie MTOM protokołu SOAP 1.2 musi zawierać parametr start-info z wartością application/soap+xml, ujęty w podwójny cudzysłów.

R4136: Nagłówek HTTP Content-Type dla komunikatu zakodowanego algorytmem MTOM protokołu SOAP 1.x musi mieć parametr graniczny z wartością (ujętą w podwójne cudzysłowy), która jest zgodna z granicą MIME BNF zdefiniowaną w dokumencie RFC 2046, sekcja 5.1.1

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

Przykłady:

POPRAWNY

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"

POPRAWNY

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

BŁĘDNY

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"

Część MIME zestawu informacji (Infoset)

Koperta SOAP 1.x jest enkapsulowana jako główna część pakietu XOP MIME i często nazywana częścią infoset.

R4141: Koperta protokołu SOAP 1.x musi być enkapsulowana jako część główna pakietu XOP MIME, nazywaną częścią infoset i przywoływaną z nagłówka Content-Type HTTP.
R4142: Część PROTOKOŁU SOAP Infoset musi zawierać następujące nagłówki MIME: Content-ID, Content-Transfer-Encodingi Content-Type.

Format nagłówka Content-ID jest definiowany przez RFC 2045 jako

"Content-ID" ":" msg-id

gdzie msg-id jest zdefiniowany w RFC 2822 (który zastępuje RFC 822, przywoływane w RFC 2045) jako:

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

i jest to efektywnie adres e-mail ujęty w nawiasach "<" i ">". Prefiks [CFWS] i sufiks zostały dodane w RFC 2822 do przenoszenia komentarzy i nie powinny być używane do zachowania interoperacyjności.

R4143: Wartość nagłówka Content-ID dla części MIME zestawu informacji musi być zgodna z produkcją msg-id z RFC 2822, pomijając prefiks i sufiks [CFWS].

Wiele implementacji MIME złagodziło wymagania dotyczące wartości ujętej w "<" i ">", która miała być adresem e-mail, i użyło absoluteURI ujętego w "<", ">" oprócz adresu e-mail. Ta wersja programu WCF używa wartości nagłówka MIME Content-ID w formie:

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

R4144: Procesory MTOM powinny akceptować wartości nagłówka Content-ID zgodne z następującymi zrelaksowanymi msg-idwartościami.

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

Protokół MIME (RFC 2045) udostępnia nagłówek Content-Transfer-Encoding w celu komunikowania kodowania zawartości części MIME. Domyślnie dla Content-Transfer-Encoding określono 7-bitową, co nie jest odpowiednie dla większości wiadomości SOAP, dlatego nagłówek Content-Transfer-Encoding jest potrzebny dla lepszej interoperacyjności.

R4145: Część zestawu informacji protokołu SOAP musi zawierać nagłówek Content-Transfer-Encoding.
R4146: Jeśli kodowanie znaków koperty PROTOKOŁU SOAP ma wartość UTF-8, wartość nagłówka Content-Transfer-Encoding musi być 8-bitowa.
R4147: Jeśli kodowanie znaków koperty SOAP to UTF-16, wartość nagłówka Content-Transfer-Encoding header musi być binarną.
Zgodnie z sekcją 5 [XOP],
R4148: Część zestawu informacji SOAP1.1 musi zawierać nagłówek Content-Type z typem nośnika application/xop+xml i parametrami 'type="text/xml"' oraz 'charset'.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: Część zestawu informacji SOAP 1.2 musi zawierać nagłówek Content-Type z typem mediów application/xop+xml oraz parametrami typu="application/soap+xml" i charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
Chociaż XOP definiuje parametr charset dla application/xop+xml jako opcjonalny, jest on potrzebny do współdziałania, podobnie jak wymóg BP 1.1 dotyczący parametru charset dla typu nośnika text/xml.
R41410: Parametry type i charset muszą być obecne w nagłówku Content-Type części infoset SOAP 1.x.

Obsługa punktu końcowego programu WCF dla modelu MTOM

Celem mtOM jest kodowanie komunikatu PROTOKOŁU SOAP w celu zoptymalizowania danych zakodowanych w formacie base64. Poniżej znajduje się lista ograniczeń:

R4151: Każdy element informacji zawierający dane zakodowane w formacie base64 może być zoptymalizowany.
B4152: WCF optymalizuje elementy informacyjne elementów, które zawierają dane zakodowane w formacie base64 i przekraczają długość 1024 bajtów.

Punkt końcowy programu WCF skonfigurowany do korzystania z modelu MTOM zawsze wysyła komunikaty zakodowane w formacie MTOM. Nawet jeśli żadne części nie spełniają wymaganych kryteriów, komunikat jest nadal zakodowany w formacie MTOM (serializowany jako pakiet MIME z pojedynczą częścią MIME zawierającą kopertę protokołu SOAP).

asercji WS-Policy dla modelu MTOM

Program WCF używa następującej asercji zasad, aby wskazać użycie modelu MTOM przez punkt końcowy:

<wsoma:OptimizedMimeSerialization />

R4211: Powyższa asercja zasady ma temat polityki punktu końcowego i określa, że wszystkie komunikaty wysyłane i odbierane z punktu końcowego muszą być zoptymalizowane z użyciem optymalizacji MTOM.
B4212: Po skonfigurowaniu do korzystania z optymalizacji MTOM, punkt końcowy WCF dodaje asercję polityki MTOM do polityki związanej z odpowiednimi wsdl:binding.

Kompozycja z WS-Security

MTOM to mechanizm kodowania podobny do text/xml pliku XML binarnego WCF. MTOM oferuje naturalną kompozycję z protokołami WS-Security i innymi WS-*, komunikat zabezpieczony przy użyciu WS-Security można zoptymalizować przy użyciu MTOM.

Przykłady

Kodowany komunikat protokołu WCF SOAP 1.1 przy użyciu protokołu MTOM

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

Bezpieczna wiadomość WCF SOAP 1.2 zakodowana za pomocą MTOM

W tym przykładzie komunikat jest kodowany przy użyciu protokołu MTOM i protokołu SOAP 1.2 chronionego przy użyciu usługi WS-Security. Części binarne zidentyfikowane do kodowania to zawartości elementu BinarySecurityToken, CipherValue w EncryptedData odpowiadającego zaszyfrowanemu podpisowi i zaszyfrowanej treści. Należy pamiętać, że CipherValue elementu EncryptedKey nie został zidentyfikowany do optymalizacji przez usługę WCF, ponieważ jego długość jest mniejsza niż 1024 bajty.

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--

Udostępnij za pośrednictwem

Protokoły obsługi komunikatów

SOAP 1.1 i SOAP 1.2

Model koperty oraz model przetwarzania

Obowiązkowe przetwarzanie nagłówka

Błędy protokołu SOAP

Powiązanie HTTP

Powiązanie HTTP protokołu SOAP 1.1

Powiązanie HTTP protokołu SOAP 1.2

WS-Addressing

Referencje punktów końcowych

Odnośniki do punktów końcowych i wersje WS-Addressing

Odwołania do punktu końcowego i metadane

Nagłówki adresowania komunikatów

Nagłówki komunikatów

Parametry i właściwości odwołania

Wzorce wymiany komunikatów

komunikat One-Way

Request-Reply

Usługi sieci Web dotyczące błędów

Powiązania WSDL 1.1 i Asercje WS-Policy

Wskazywanie użycia WS-Addressing

Definicja akcji

Używanie odwołania do punktu końcowego wewnątrz portu WSDL

Kompozycja z WS-Security

Przykłady

komunikat One-Way

Mechanizm optymalizacji transmisji komunikatów PROTOKOŁU SOAP

Kodowanie komunikatów MTOM

Generowanie komunikatów MTOM

Przetwarzanie komunikatów MTOM

Nagłówek typu zawartości HTTP

Część MIME zestawu informacji (Infoset)

Obsługa punktu końcowego programu WCF dla modelu MTOM

asercji WS-Policy dla modelu MTOM

Kompozycja z WS-Security

Przykłady

Kodowany komunikat protokołu WCF SOAP 1.1 przy użyciu protokołu MTOM

Bezpieczna wiadomość WCF SOAP 1.2 zakodowana za pomocą MTOM

Dodatkowe zasoby