Protokoły obsługi komunikatów

Artykuł
03/02/2024

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 implementacji programu WCF dla następujących protokołów używanych przez HttpTransportBindingElementprogram .

Specyfikacja/dokument:

HTTP 1.1
Powiązanie HTTP protokołu SOAP 1.1, sekcja 7
Sekcja powiązania HTTP PROTOKOŁU SOAP 1.2 7

W tym temacie opisano szczegóły implementacji programu WCF dla następujących protokołów i TextMessageEncodingBindingElement MtomMessageEncodingBindingElement ich zastosowania.

Specyfikacja/dokument:

W tym temacie opisano szczegóły implementacji programu WCF dla następujących protokołów, które MtomMessageEncodingBindingElement są używane.

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

Program WCF implementuje przetwarzanie kopert protokołu SOAP 1.1 zgodnie z podstawowym profilem 1.1 (BP11) i profilem podstawowym 1.0 (SSBP10). Przetwarzanie kopert protokołu SOAP 1.2 jest implementowane po 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

Program WCF jest zgodny z regułami przetwarzania nagłówków oznaczonych mustUnderstand w specyfikacji SOAP 1.1 i SOAP 1.2 z następującymi odmianami.

Komunikat, który wprowadza stos kanału WCF, jest przetwarzany przez poszczególne kanały skonfigurowane przez skojarzone elementy powiązania, na przykład kodowanie komunikatów tekstowych, zabezpieczenia, niezawodne komunikaty 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 i 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 0, 1, falsei true jako, ale zaleca emitowanie kanonicznej reprezentacji xs:boolean wartości (false, true).
B1112: Program 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 PROTOKOŁU SOAP1.1 zgodnie ze specyfikacją Profilu podstawowego 1.1 sekcja 3.4 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 adresowanie WS nie jest używane.

R2221: application/soap+xml Parametr akcji, jeśli występuje w żądaniu protokołu SOAP 1.2, musi być zgodny z atrybutem soapActionwsoap12:operation elementu wewnątrz odpowiedniego powiązania WSDL.
R2222: Parametr application/soap+xml akcji, jeśli jest obecny w komunikacie PROTOKOŁU SOAP 1.2, musi być zgodny wsa:Action , gdy są używane adresowanie WS-2004/08 lub WS-Addressing 1.0.

Gdy adresowanie WS jest wyłączone i żądanie przychodzące nie zawiera parametru akcji, komunikat Action jest uznawany za nieokreślony.

Adresowanie WS

Program WCF implementuje 3 wersje adresowania WS:

Adresowanie WS 2004/08
W3C Web Services Addressing 1.0 Core (ADDR10-CORE) i SOAP Binding (ADDR10-SOAP)
Adresowanie WS 1.0 — metadane

Odwołania do punktu końcowego

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

Odwołania do punktów końcowych i wersje adresowania WS

Program WCF implementuje szereg protokołów infrastruktury, które używają adresowania WS, a w szczególności EndpointReference elementu i W3C.WsAddressing.EndpointReferenceType klasy (na przykład WS-ReliableMessaging, WS-SecureConversation i WS-Trust). Program WCF obsługuje korzystanie z jednej z wersji adresowania WS z innymi protokołami infrastruktury. Punkty końcowe programu WCF obsługują jedną wersję adresowania WS na punkt końcowy.

W przypadku języka R3111 przestrzeń nazw elementu lub typu używanego EndpointReference w komunikatach wymienianych z punktem końcowym programu WCF musi być zgodna z wersją adresowania WS zaimplementowaną przez ten punkt końcowy.

Jeśli na przykład punkt końcowy programu WCF implementuje funkcję WS-ReliableMessaging, AcksTo nagłówek zwrócony przez taki punkt końcowy wewnątrz CreateSequenceResponse używa wersji adresowania WS, którą EncodingBinding element 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 specyfikacji WS-MetadataExchange (MEX) Sekcja 6 w celu uwzględnienia metadanych odwołań do punktu końcowego według wartości lub odwołania.

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 odwołania do punktu końcowego zdefiniowanych w programie MEX, program WCF udostępnia 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 adresowania WS program WCF używa następujących nagłówków komunikatów zgodnie ze specyfikacjami wsa:To, , wsa:ReplyTo, wsa:MessageIDwsa:Action, i wsa:RelatesTo.

B3211: Dla wszystkich wersji adresowania WS, WCF honoruje, ale nie generuje gotowego do użycia nagłówków komunikatów wsa:FaultTo adresowania WS i wsa:From.

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: W przypadku skonfigurowania używania adresowania WS-Addressing 2004/08 punkty końcowe programu WCF nie rozróżniają właściwości odwołania do przetwarzania i parametrów referencyjnych.

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. Program WCF obsługuje wzorce wymiany komunikatów jednokierunkowych, żądań i dwukierunkowych. W tej sekcji wyjaśniono wymagania dotyczące adresowania WS 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ść.

Jednokierunkowa wiadomość

Jeśli punkt końcowy programu WCF jest skonfigurowany do obsługi komunikatów z danym Action wzorcem, 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 adresowania WS obsługiwanego w programie WCF:

R3311: Obiekt żądający musi zawierać wsa:Tonagłówki , wsa:Actioni dla wszystkich parametrów referencyjnych określonych przez odwołanie do punktu końcowego. Gdy jest używane adresowanie WS-2004/08 i [właściwości odwołania] są określone przez odwołanie do punktu końcowego, odpowiednie nagłówki należy również dodać do komunikatu.
B3312: Element żądający może zawierać MessageIDnagłówki , ReplyToi 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 nogę odpowiedzi HTTP, osoba odpowiadająca 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 jednokierunkowo, odpowiedź HTTP może być nadal używana do wysyłania komunikatów infrastruktury — na przykład niezawodne komunikaty mogą wysyłać SequenceAcknowledgement komunikat w odpowiedzi HTTP.
B3314: Obiekt odpowiadający WCF nie wysyła komunikatu o błędzie w odpowiedzi na jednokierunkowy komunikat.

Żądanie i odpowiedź

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 adresowania WS obsługiwanego w programie WCF:

R3321: Obiekt żądający musi zawierać w żądaniu wsa:To, wsa:Action, wsa:MessageIDi nagłówki dla wszystkich parametrów referencyjnych lub właściwości odwołania (lub obu) określonych przez odwołanie do punktu końcowego.
R3322: Jeśli jest używane adresowanie WS 2004/08, ReplyTo należy również dołączyć do żądania.
R3323: Gdy jest używane adresowanie WS-1.0 i ReplyTo nie jest obecne w żądaniu, jest używane domyślne odwołanie do punktu końcowego z właściwością [address] równej http://www.w3.org/2005/08/addressing/anonymous .
R3324: Obiekt żądający musi zawierać wsa:Tonagłówki , wsa:Actioni wsa:RelatesTo w komunikacie odpowiedzi, a także nagłówki dla wszystkich parametrów odwołania lub właściwości odwołania (lub obu) określonych przez ReplyTo odwołanie do punktu końcowego w żądaniu.

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

R3411: 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 skojarzony z punktem końcowym nie rozpoznają akcji określonej w nagłówku `Action` .

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

Kod	Przyczyna
`wsa10:InvalidAddressingHeader`	Zduplikowane `wsa:To`, `wsa:ReplyTo`lub `wsa:Fromwsa:MessageID`. Zduplikuj `wsa:RelatesTo` element z tym samym `RelationshipType`elementem .
`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 dyspozytor skojarzony z punktem końcowym.
`wsa10:EndpointUnavailable`	Kanał RM wysyła ten błąd z powrotem, wskazując, że punkt końcowy nie przetworzy sekwencji na podstawie badania `CreateSequence` nagłówków adresowania komunikatu.

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 asercji zasad WS-Policy

Wskazuje użycie adresowania WS

WCF używa asercji zasad, aby wskazać obsługę punktu końcowego dla określonej wersji adresowania WS.

Następujące asercji zasad ma temat zasad punktu końcowego [WS-PA] i wskazuje komunikaty wysyłane i odbierane z punktu końcowego muszą używać adresowania WS-2004/08.

<wsap:UsingAddressing />

Ta asercji zasad rozszerza specyfikację WS-Addressing 2004/08.

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

<wsam:Addressing/>

Poniższa aseracja zasad ma temat zasad punktu końcowego [WS-PA] i wskazuje, że komunikaty wysyłane i odbierane z punktu końcowego muszą używać adresowania WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

Element wsaw10:UsingAddressing jest pożyczany z [WS-Addressing-WSDL] i jest używany w kontekście zasad 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 za pośrednictwem odpowiedzi http asercji WS-AM jest:

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

W przypadku odpowiedzi wysyłanych za pośrednictwem oddzielnych żądań http asercji ws-am jest

<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] w punktach końcowych, które używają powiązań HTTP protokołu WSDL 1.1 SOAP 1.x, wymaga dwóch oddzielnych połączeń HTTP, które mają być używane do obsługi komunikatów przepływających od osoby żądającej do osoby odpowiadającej i odpowiadających do osoby żądającej, odpowiednio.

<cdp:CompositeDuplex/>

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

R3514: Żądanie komunikatów wysyłanych do punktu końcowego musi mieć ReplyTo nagłówek o [address] właściwości nie równejhttp://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ę zasad z wsap10:UsingAddressing dołączonym asercją cdp:CompositeDuplex lubwsap:UsingAddressing.
R3515: Żądanie komunikatów wysyłanych do punktu końcowego musi mieć ReplyTo nagłówek z [address] właściwością równą http://www.w3.org/2005/08/addressing/anonymouslub nie ma ReplyTo nagłówka, jeśli punkt końcowy używa powiązania HTTP protokołu WSDL 1.1 SOAP 1.x i ma alternatywę zasad z wsap10:UsingAddressing asercją i nie cdp:CompositeDuplex dołączono asercji.
R3516: Żądanie komunikatów wysyłanych do punktu końcowego musi mieć ReplyTo nagłówek z właściwością równą http://www.w3.org/2005/08/addressing/anonymous[address], jeśli punkt końcowy używa powiązania HTTP protokołu WSDL 1.1 SOAP 1.x i ma alternatywę zasad z wsap:UsingAddressing asercją i nie cdp:CompositeDuplex dołączono asercji.

Specyfikacja WSDL adresowania WSDL próbuje opisać podobne powiązania protokołu, wprowadzając element <wsaw:Anonymous/> z trzema wartościami tekstowymi (wymaganymi, opcjonalnymi i zabronionymi), aby wskazać wymagania nagłówka wsa:ReplyTo (sekcja 3.2). Niestety, taka definicja elementu nie jest szczególnie przydatna jako asercja w kontekście usługi WS-Policy, ponieważ wymaga rozszerzeń specyficznych dla domeny do obsługi przecięcia alternatywnych elementów 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. Powiązanie WS-Addressing 1.0 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ądnym rozwiązaniem jest posiadanie dwóch punktów końcowych, które współużytkowały ten sam portType (lub kontrakt w terminologii WCF), ale używają różnych wersji adresowania WS. Jednak biorąc pod uwagę, że akcja jest zdefiniowana przez portType element i nie powinna zmieniać się w punktach końcowych, które implementują portTypeelement , nie można obsługiwać obu domyślnych wzorców akcji.

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

B3521: WCF używa atrybutu wsaw10:Action dla wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementów zdefiniowanych w WS-ADDR10-WSDL w celu określenia identyfikatora Action URI odpowiednich komunikatów niezależnie od wersji adresowania WS używanej przez punkt końcowy.

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

Sekcja WS-ADDR10-WSDL 4.1 rozszerza wsdl:port element w celu uwzględnienia elementu podrzędnego <wsa10:EndpointReference…/> w celu opisania punktu końcowego w terminach adresowania WS. Program WCF rozszerza to narzędzie w programie WS-Addressing 2004/08, co pozwala <wsa:EndpointReference…/> na pojawienie się jako element podrzędny elementu wsdl:port.

R3531: Jeśli punkt końcowy ma dołączoną alternatywę zasad z asercją <wsaw10:UsingAddressing/> zasad, odpowiedni wsdl:port element może zawierać element <wsa10:EndpointReference …/>podrzędny .
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ę zasad z <wsap:UsingAddressing/> asercją zasad, odpowiedni wsdl:port element może zawierać element <wsa:EndpointReference …/>podrzędny .
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 zabezpieczeniami WS

Zgodnie z sekcjami zagadnień dotyczących zabezpieczeń w usługach WS-ADDR i WS-ADDR10 zaleca się podpisanie wszystkich nagłówków komunikatów adresowania wraz z treścią komunikatu w celu powiązania ich ze sobą.

Gdy zabezpieczenia WS są używane do ochrony integralności komunikatów, nagłówki komunikatów adresowania WS, 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

Jednokierunkowa wiadomość

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ą wsa10:To elementy 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 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óry serializuje zestaw informacji XML i każdą część binarną pakietu XOP w 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 XML z elementami zawierającymi wartości base64 w abstrakcyjnie zdefiniowany pakiet XOP.

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

Upewnij się, że koperta PROTOKOŁU SOAP, która ma być zakodowana, nie zawiera elementu informacji o elemencie z wartością [namespace name]http://www.w3.org/2004/08/xop/include i .[local name]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 o elemencie muszą znajdować się w postaci kanonicznej xs:base64Binary (zobacz XSD-2, 3.2.16 base64Binary) i nie mogą zawierać żadnych znaków odstępów poprzedzających, wbudowanych lub postępując zgodnie z zawartością nienależącą do białych znaków.
Utwórz kopertę XOP SOAP, która jest kopią oryginalnej koperty PROTOKOŁU SOAP, ale z elementami podrzędnymi każdego elementu informacji o elemencie określonym w poprzednim kroku zastąpionym elementem informacyjnym xop:Include elementu 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 kodowania zawartości z wartością binarną.
4. Jeśli element informacyjny elementu jest zoptymalizowany (element [nadrzędny] nowo wstawionego xop:Include elementu informacji o elemencie informacji o elemencie informacji o atrybucie) ma xmime:contentType element informacji o atrybucie, wygeneruj nagłówek MIME typu zawartości 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 nagłówka 4c, content-type, jeśli został wygenerowany w kroku 4d.
6. href Dodaj atrybut do xop:Include elementu z wartością cid: identyfikator URI pochodzący z wartości nagłówka Content-ID wygenerowanej w kroku 4b. Usuń otaczające znaki "<" i ">", adres URL ucieczki pozostałego ciągu i dodaj prefiks cid:. Następujący minimalny zestaw znaków jest wymagany do ucieczki przez RFC1738 i RFC2396. Inne znaki można uniknić.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Utwórz główną część MIME z kopertą 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 application/xop+xmlzawartości .
Konstruowanie koperty 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. Ujęć ciąg wynikowy w ciągu "<", ">".
2. Znajdź część MIME z wartością nagłówka Content-ID zgodną z ciągiem uzyskanym w kroku 3a.
3. xop:Include Zastąp element informacji o elemencie wyświetlanym we children właściwości każdego elementu elementami informacji o znakach, które reprezentują kodowanie kanoniczne base64 (zobacz kodowanie XSD-2, 3.2.16 base64Binary) jednostki części MIME zidentyfikowanej w kroku 3b (skutecznie zastąp xop:Include element informacyjny element 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 protokole SOAP 1.x MTOM pochodzącego z wymagań określonych w samej specyfikacji MTOM i pochodzi z jednostek 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 jest wymieniony 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 z wartością nagłówka Content-ID części MIME zawierającej kopertę SOAP 1.x ujętą 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 typu zawartości HTTP dla zakodowanego komunikatu PROTOKOŁU SOAP 1.1 MTOM musi zawierać parametr start-info z wartością tekstu/xml, ujęty 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 typu zawartości HTTP dla komunikatu zakodowanego algorytmem MTOM protokołu SOAP 1.x musi mieć parametr granicy z wartością (ujętą w podwójny cudzysłów), który jest zgodny z granicą PROTOKOŁU MIME BNF zdefiniowaną w dokumencie RFC 2046, sekcja 5.1.1

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

Przykłady:

POPRAWNE

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"

POPRAWNE

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

NIEPOPRAWNE

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

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

R4141: Koperta PROTOKOŁU SOAP 1.x musi być hermetyzowana jako główna część pakietu XOP MIME, nazywana infoset częścią i przywoływała się z typu zawartości 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 jest zdefiniowany w dokumencie msg-id RFC 2822 (który zastępuje RFC 822, przywoływane w dokumencie RFC 2045) jako:

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

i jest skutecznie adresem e-mail ujętym w ciągu "<" i ">". Prefiks [CFWS] i sufiks zostały dodane w RFC 2822 do przenoszenia komentarzy i nie powinny być używane do zachowania współdziałania.

R4143: wartość nagłówka Content-ID dla części MIME zestawu informacji musi być zgodna msg-id z produkcją z RFC 2822 z pominiętymi prefiksami i częściami [CFWS] sufiksu.

Wiele implementacji MIME złagodzone wymagania dotyczące wartości ujętej w ciągu "<" i ">" jako adresu e-mail i używane absoluteURI w< adresie "" , ">" oprócz adresu e-mail. Ta wersja programu WCF używa wartości nagłówka MIME content-ID formularza:

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. Wartość domyślna zdefiniowana dla kodowania Content-Transfer-Encoding to 7-bitowa, która nie jest odpowiednia dla większości komunikatów PROTOKOŁU SOAP, dlatego nagłówek Content-Transfer-Encoding jest wymagany w celu zwiększenia współdziałania:

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 PROTOKOŁU SOAP to UTF-16, wartość nagłówka Content-Transfer-Encoding musi być binarna.
Zgodnie z [XOP] sekcja 5,
R4148: Część zestawu informacji SOAP1.1 musi zawierać nagłówek Content-Type z typem nośnika application/xop+xml i typem parametrów="text/xml" i charset
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: Część zestawu informacji PROTOKOŁU SOAP 1.2 musi zawierać nagłówek Content-Type z typem nośnika i typem application/xop+xml parametrów="application/soap+xml" i charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
Chociaż XOP definiuje charset parametr, który application/xop+xml ma być opcjonalny, jest wymagany do współdziałania podobnego do wymagania BP 1.1 dla charset parametru typu nośnika text/xml .
R41410: type Parametry i charset muszą być obecne w nagłówku Content-Type części infoset protokołu 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 o elemencie zawierającym 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 zasad WS dla mtOM

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

<wsoma:OptimizedMimeSerialization />

R4211: Powyższe asercji zasad ma temat zasad punktu końcowego i określa, że wszystkie komunikaty wysyłane i odbierane z punktu końcowego muszą być zoptymalizowane przy użyciu funkcji MTOM.
B4212: Po skonfigurowaniu do korzystania z optymalizacji MTOM punkt końcowy programu WCF dodaje do zasad dołączonych do odpowiednich wsdl:bindingzasad asercji zasad MTOM.

Kompozycja z zabezpieczeniami WS

MTOM to mechanizm kodowania podobny do text/xml pliku XML binarnego WCF. MtOM oferuje naturalny skład z protokołami WS-Security i innymi protokołami WS-* : komunikat zabezpieczony przy użyciu usługi WS-Security można zoptymalizować przy użyciu rozwiązania 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

WCF Secure SOAP 1.2 Message Encoded Using 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ść BinarySecurityTokenelementu odpowiadającego CipherValueEncryptedData zaszyfrowanej podpisowi i zaszyfrowanej treści. Należy pamiętać, że parametr CipherValue nie EncryptedKey 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 i 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

Adresowanie WS

Odwołania do punktu końcowego

Odwołania do punktów końcowych i wersje adresowania WS

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

Jednokierunkowa wiadomość

Żądanie i odpowiedź

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

Powiązania WSDL 1.1 i asercji zasad WS-Policy

Wskazuje użycie adresowania WS

Definicja akcji

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

Kompozycja z zabezpieczeniami WS

Przykłady

Jednokierunkowa wiadomość

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

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

Asercji zasad WS dla mtOM

Kompozycja z zabezpieczeniami WS

Przykłady

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

WCF Secure SOAP 1.2 Message Encoded Using MTOM

Dodatkowe zasoby