Protokoly zasílání zpráv

Zásobník kanálů WCF (Windows Communication Foundation) využívá kódovací a transportní kanály k převodu interní reprezentace zpráv na formát pro přenos a následně jej odesílá pomocí konkrétního transportu. Nejběžnější transport používaný pro interoperabilitu webových služeb je HTTP a nejběžnější kódování používané webovými službami jsou XML-based SOAP 1.1, SOAP 1.2 a Mechanismus optimalizace přenosu zpráv (MTOM).

Toto téma popisuje podrobnosti implementace WCF pro následující protokoly používané HttpTransportBindingElement.

Specifikace/dokument:

• HTTP 1.1
• Propojení HTTP SOAP 1.1, sekce 7
• Vazba HTTP protokolu SOAP 1.2 Oddíl 7

Toto téma popisuje podrobnosti implementace WCF pro následující protokoly, které TextMessageEncodingBindingElement a MtomMessageEncodingBindingElement používají.

Specifikace/dokument:

• XML
• SOAP 1.1
• SOAP 1.2 Core
• WS-Addressing 2004/08
• Adresy webových služeb W3C 1.0 – jádro
• Adresování webových služeb W3C 1.0 – vazba SOAP
• Adresování webových služeb W3C 1.0 – Vazba WSDL
• Adresování webových služeb W3C 1.0 – metadata
• WSDL SOAP1.1 vazba
• Propojení WSDL SOAP1.2

Toto téma popisuje podrobnosti implementace WCF pro následující protokoly, které MtomMessageEncodingBindingElement používají.

Specifikace/dokument:

• XOP
• Vazba MTOM + SOAP 1.2
• Vazba MTOM SOAP 1.1
• MTOM WS-Policy kontrolní výraz

V tomto tématu se používají následující obory názvů XML a přidružené předpony:

Předpona	Identifikátor URI (Namespace Uniform Resource Identifier)
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 a SOAP 1.2

Model obálky a zpracování

WCF implementuje zpracování obálky SOAP 1.1 podle základního profilu 1.1 (BP11) a základního profilu 1.0 (SSBP10). Zpracování obálky SOAP 1.2 se implementuje podle protokolu SOAP12-Part1.

Tato část vysvětluje určité volby implementace, které WCF vzala v souvislosti s BP11 a SOAP12-Part1.

Povinné zpracování hlaviček

WCF dodržuje pravidla pro zpracování hlaviček označených mustUnderstand v specifikacích SOAP 1.1 a SOAP 1.2 s následujícími variantami.

Zpráva, která vstoupí do zásobníku kanálu WCF, je zpracována jednotlivými kanály nakonfigurovanými přidruženými vazebními prvky, například kódováním textových zpráv, zabezpečením, spolehlivým zasíláním zpráv a transakcemi. Každý kanál rozpozná hlavičky z přidruženého oboru názvů a označí je jako srozumitelné. Jakmile zpráva vstoupí do dispečera, formátovač operace čte hlavičky očekávané odpovídajícím kontraktem zprávy/operace a označí, že jim rozumí. Pak dispečer ověří, jestli některé zbývající hlavičky nejsou srozumitelné a jsou označené jako mustUnderstand, a vyvolá výjimku. Zprávy, které obsahují mustUnderstand hlavičky cílené na příjemce, se nezpracovávají kódem aplikace příjemce.

Takové vrstvené zpracování umožňuje oddělení mezi vrstvami infrastruktury a aplikačními vrstvami uzlu SOAP:

• B1111: Hlavičky, které nejsou pochopeny, se detekují po zpracování zprávy zásobníkem kanálů infrastruktury WCF, ale před jejím zpracováním aplikací.

  Hodnota mustUnderstand hlavičky se liší mezi protokolem SOAP 1.1 a SOAP 1.2. Základní profil 1.1 vyžaduje, aby mustUnderstand hodnota byla 0 nebo 1 pro zprávy SOAP 1.1. PROTOKOL SOAP 1.2 umožňuje 0, 1 falsea true jako hodnoty, ale doporučuje generovat kanonickou reprezentaci xs:boolean hodnot (false, true).

• B1112: WCF generuje mustUnderstand hodnoty 0 a 1 pro obě verze SOAP 1.1 a SOAP 1.2 obálky SOAP. WCF přijímá celý rozsah hodnot xs:boolean hlavičky mustUnderstand (0, 1, false, true)

SOAP chyby

Následuje seznam implementací chyb SOAP specifických pro WCF.

• B2121: WCF vrátí následující kódy chyb SOAP 1.1: s11:mustUnderstand, s11:Clienta s11:Server.

• B2122: WCF vrátí následující kódy chyb SOAP 1.2: s12:MustUnderstand, s12:Sendera s12:Receiver.

Propojení HTTP

Vazba HTTP PROTOKOLU SOAP 1.1

WCF implementuje vazbu SOAP1.1 HTTP podle oddílu 3.4 specifikace Basic Profile 1.1 s následujícími vysvětleními:

• B2211: Služba WCF neimplementuje přesměrování požadavků HTTP POST.

• B2212: Klienti WCF podporují soubory cookie HTTP v souladu s 3.4.8.

Vazba HTTP protokolu SOAP 1.2

WCF implementuje vazbu HTTP PROTOKOLU SOAP 1.2, jak je popsáno ve specifikaci SOAP 1.2 části 2 (SOAP12Part2) s následujícími vysvětleními.

Protokol SOAP 1.2 zavedl volitelný parametr akce pro application/soap+xml typ média. Tento parametr je užitečný k optimalizaci odesílání zpráv, aniž by bylo nutné analyzovat text zprávy SOAP, pokud se WS-Addressing nepoužívá.

• R2221: Parametr application/soap+xml akce, pokud je k dispozici v požadavku SOAP 1.2, musí odpovídat soapAction atributu wsoap12:operation prvku uvnitř odpovídající vazby WSDL.

• R2222: Akční parametr application/soap+xml, pokud je přítomen ve zprávě SOAP 1.2, se musí shodovat s wsa:Action při použití WS-Addressing 2004/08 nebo WS-Addressing 1.0.

Pokud je WS-Addressing zakázána a příchozí požadavek neobsahuje parametr akce, zpráva Action se považuje za nezadanou.

WS-Addressing

WCF implementuje tři verze WS-Adresování.

• WS-Addressing 2004/08

• Webové služby W3C adresující 1.0 Core (ADDR10-CORE) a vazby SOAP (ADDR10-SOAP)

• WS-Addressing 1.0 – metadata

Odkazy na koncové body

Všechny verze WS-Addressing, které WCF implementuje, používají odkazy na koncové body k popisu koncových bodů.

Odkazy na koncové body a verze WS-Addressing

WCF implementuje řadu protokolů infrastruktury, které používají WS-Addressing a zejména EndpointReference element a W3C.WsAddressing.EndpointReferenceType třídu (například WS-ReliableMessaging, WS-SecureConversation a WS-Trust). WCF podporuje použití jedné verze WS-Addressing s jinými protokoly infrastruktury. WCF koncové body podporují jednu verzi WS-Addressing pro každý koncový bod.

Pro R3111 musí obor názvů pro prvek nebo typ EndpointReference použitý ve zprávách vyměňovaných s koncovým bodem WCF odpovídat verzi WS-Addressing, kterou tento koncový bod implementuje.

Pokud například koncový bod WCF implementuje WS-ReliableMessaging, AcksTo hlavička vrácená takovým koncovým bodem uvnitř CreateSequenceResponse používá WS-Addressing verzi, kterou EncodingBinding element určuje pro tento koncový bod.

Odkazy na koncové body a metadata

Řada scénářů vyžaduje komunikaci metadat nebo odkaz na metadata pro daný koncový bod.

B3121: WCF využívá mechanismy popsané ve specifikaci WS-MetadataExchange (MEX) oddíl 6 pro zahrnutí metadat pro odkazy na koncové body podle hodnoty nebo reference.

Představte si scénář, kdy služba WCF vyžaduje ověření pomocí tokenu SAML (Security Assertions Markup Language) vydaného vystavitelem tokenu na adrese http://sts.fabrikam123.com. Koncový bod WCF popisuje tento požadavek na ověřování pomocí sp:IssuedToken kontrolního výrazu s vnořeným sp:Issuer kontrolním výrazem odkazujícím na vystavitele tokenu. Klientské aplikace, které přistupují k kontrolnímu výrazu sp:Issuer , potřebují vědět, jak komunikovat s koncovým bodem vystavitele tokenu. Klient potřebuje znát metadata o vystaviteli tokenu. Pomocí rozšíření metadat odkazů na koncové body definovaných v MEX poskytuje WCF odkaz na metadata vystavitele 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>

Hlavičky adresování zpráv

Záhlaví zpráv

V obou verzích WS-Addressing wcf používá následující hlavičky zpráv, jak jsou předepsány specifikacemi wsa:To, , wsa:ReplyTowsa:Action, wsa:MessageIDa wsa:RelatesTo.

B3211: Pro všechny verze WS-Addressing WCF respektuje, ale nevytváří automaticky záhlaví zpráv WS-Addressing wsa:FaultTo a wsa:From.

Aplikace, které pracují s aplikacemi WCF, mohou tyto hlavičky zpráv přidat a WCF je odpovídajícím způsobem zpracuje.

Referenční parametry a vlastnosti

WCF implementuje zpracování referenčních parametrů koncového bodu a vlastností odkazu v souladu s příslušnými specifikacemi.

B3221: Při konfiguraci na použití WS-Addressing 2004/08 nerozlišují koncové body WCF mezi zpracováním vlastností odkazu a parametry odkazu.

Vzory výměny zpráv

Posloupnost zpráv zapojených do vyvolání operace webové služby se označuje jako vzor výměny zpráv. WCF podporuje jednosměrné vzory pro výměnu zpráv, vzory žádost-odpověď a duplexní vzory pro výměnu zpráv. Tato část vysvětluje WS-Addressing požadavky na zpracování zpráv v závislosti na použitém vzoru výměny zpráv.

V této části žadatel odešle první zprávu a respondent obdrží první zprávu.

zpráva One-Way

Pokud je koncový bod WCF nakonfigurovaný tak, aby podporoval zprávy s daným Action, které sledují jednosměrný vzor, řídí se následujícím chováním a požadavky. Pokud není uvedeno jinak, chování a pravidla platí pro obě verze WS-Addressing podporované ve WCF:

• R3311: Žadatel musí zahrnovat wsa:To, wsa:Action a hlavičky pro všechny referenční parametry specifikované odkazem na koncový bod. Při použití WS-Addressing 2004/08 a když jsou ty odkazové vlastnosti specifikovány odkazem na koncový bod, musí být odpovídající hlavičky také přidány do zprávy.

• B3312: Žadatel může zahrnout hlavičky MessageID, ReplyTo a FaultTo. Infrastruktura příjemce je bude ignorovat a předají se aplikaci.

• R3313: Při použití protokolu HTTP a na noze odpovědi HTTP se neodesílá žádná zpráva, musí respondér odeslat odpověď HTTP s prázdným tělem a stavovým kódem HTTP 202.

  Když se používá transport HTTP a kontrakt operace prohlásí zprávu za jednosměrnou, může být odpověď HTTP stále použita k odesílání zpráv infrastruktury – například spolehlivé posílání zpráv může odeslat zprávu SequenceAcknowledgement v odpovědi HTTP.

• B3314: Respondér WCF neodesílá v reakci na jednosměrnou zprávu chybovou zprávu.

Request-Reply

Když je koncový bod WCF nakonfigurovaný pro zprávu s danou Action, aby odpovídal vzorci žádost-odpověď, koncový bod WCF se řídí chováním a požadavky níže. Pokud není uvedeno jinak, chování a pravidla se vztahují na obě verze WS-Addressing podporované ve WCF:

• R3321: V žádosti musí být zahrnuty wsa:To, wsa:Action, wsa:MessageID, a také hlavičky pro všechny referenční parametry nebo vlastnosti odkazu (nebo oboje) určené odkazem na koncový bod.

• R3322: Při použití WS-Addressing 2004/08 musí být také ReplyTo součástí žádosti.

• R3323: Při použití WS-Addressing 1.0 a ReplyTo není k dispozici v požadavku, použije se výchozí odkaz na koncový bod s vlastností [address] rovnající se http://www.w3.org/2005/08/addressing/anonymous .

• R3324: Žadatel musí zahrnout hlavičky wsa:To, wsa:Action a wsa:RelatesTo do zprávy odpovědi, stejně jako hlavičky pro všechny referenční parametry nebo vlastnosti odkazu (nebo obojí), které jsou specifikovány odkazem ReplyTo na koncový bod v požadavku.

Chyby v adresování webových služeb

R3411: WCF vytváří následující chyby definované WS-Addressing 2004/08.

Code	Příčina
wsa:DestinationUnreachable	Zpráva dorazila s ReplyTo odlišným od adresy pro odpověď vytvořené pro tento kanál; na adrese uvedené v hlavičce 'To' nečeká žádný koncový bod.
wsa:ActionNotSupported	kanály infrastruktury nebo dispečer přidružené ke koncovému bodu nerozpoznávají akci uvedenou v Action hlavičce.

R3412: WCF vytváří následující chyby definované WS-Addressing 1.0.

Code	Příčina
wsa10:InvalidAddressingHeader	Duplikovat wsa:To, wsa:ReplyTo, wsa:From nebo wsa:MessageID. Duplikovat wsa:RelatesTo se stejným RelationshipType.
wsa10:MessageAddressingHeaderRequired	Chybí požadovaná hlavička adresování.
wsa10:DestinationUnreachable	Zpráva přišla s ReplyTo lišící se od adresy pro odpověď stanovené pro tento kanál. Na adrese zadané v hlavičce To není žádný koncový bod.
wsa10:ActionNotSupported	Akce zadaná v Action hlavičce není rozpoznána komunikačními kanály infrastruktury ani dispečery přidruženými ke koncovému bodu.
wsa10:EndpointUnavailable	Kanál RM odešle tuto chybu zpět, což značí, že koncový bod po přezkoumání adresních hlaviček zprávy nebude zpracovávat sekvenci.

Kód v předchozích tabulkách se mapuje na FaultCode v SOAP 1.1 a SubCode (s kódem=Sender) v SOAP 1.2.

Vazby WSDL 1.1 a kontrolní výrazy WS-Policy

Indikace použití WS-Addressing

WCF používá zásadní tvrzení k indikaci podpory koncových bodů pro konkrétní WS-Addressing verzi.

Následující deklarace zásady obsahuje předmět zásad koncového bodu [WS-PA] a označuje, že zprávy, které jsou odesílány a přijímány z koncového bodu, musí používat WS-Addressing 2004/08.

<wsap:UsingAddressing />

Toto prohlášení zásad rozšiřuje specifikaci WS-Addressing 2004/08.

Následující výrok zásad označuje, že zprávy odeslané/přijaté musí používat WS-Addressing 1.0.

<wsam:Addressing/>

Následující prohlášení zásad má předmět zásad pro koncový bod [WS-PA] a uvádí, že zprávy odesílané a přijímané tímto koncovým bodem musí používat WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

Prvek wsaw10:UsingAddressing je vypůjčený z [WS-Addressing-WSDL] a používá se v kontextu WS-Policy v souladu s danou specifikací, oddíl 3.1.2.

Použití adresování nemění sémantiku WSDL 1.1, SOAP 1.1 a HTTP vazeb SOAP 1.2. Pokud se například očekává odpověď na požadavek odeslaný do koncového bodu, který používá vazbu HTTP adresování a WSDL SOAP 1.x, musí být odpověď odeslána pomocí odpovědi HTTP.

U odpovědí zaslaných přes HTTP odpověď je asercí WS-AM:

<wsam:AnonymousResponses/>

Úplné prohlášení zásad může vypadat takto:

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

Existují však vzory výměny zpráv, které mají výhodu, že mezi žadatelem a respondentem jsou navázána dvě nezávislá připojení HTTP, například nevyžádaná jednosměrná zpráva odeslaná respondentem.

WCF nabízí funkci, podle které můžou dva podkladové přenosové kanály tvořit složený duplexní kanál, kde se jeden kanál používá pro vstupní zprávy a druhý se používá pro výstupní zprávy. V případě použití transportu HTTP zajišťuje složitý duplex dvě protichůdná připojení HTTP. Žadatel používá jedno připojení k odesílání zpráv do respondenta a respondent používá druhé k odesílání zpráv zpět žadateli.

U odpovědí odesílaných přes samostatné požadavky HTTP je kontrolní výraz ws-am

<wsam:NonAnonymousResponses/>

Úplné prohlášení zásad může vypadat takto:

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

Použití následujícího tvrzení, které má předmět zásad koncového bodu [WS-PA] na koncových bodech, jež používají vazby WSDL 1.1, SOAP 1.x a HTTP, vyžaduje, aby se pro zprávy směrem od žadatele k respondentovi a od respondenta k žadateli používala dvě samostatná HTTP připojení.

<cdp:CompositeDuplex/>

Předchozí výrok vede k následujícím požadavkům na hlavičku wsa:ReplyTo pro požadavkové zprávy.

• R3514: Požadavkové zprávy odeslané na koncový bod musí mít hlavičku ReplyTo s vlastností [address], která není rovna http://www.w3.org/2005/08/addressing/anonymous, pokud koncový bod používá vazbu HTTP WSDL 1.1 SOAP 1.x a má alternativu zásady s připojeným tvrzením wsap10:UsingAddressing nebo wsap:UsingAddressing, spolu s cdp:CompositeDuplex.

• R3515: Pokud koncový bod používá vazbu WSDL 1.1 SOAP 1.x HTTP a má alternativu zásad s asercí ReplyTo a bez připojené aserce [address], musí být odeslané požadavky na koncový bod opatřeny hlavičkou http://www.w3.org/2005/08/addressing/anonymous s vlastností ReplyTo rovnou wsap10:UsingAddressing, nebo vůbec nesmí obsahovat hlavičku cdp:CompositeDuplex.

• R3516: Žádosti odeslané do koncového bodu musí mít hlavičku ReplyTo s vlastností [address] rovnou http://www.w3.org/2005/08/addressing/anonymous, pokud koncový bod používá vazbu WSDL 1.1 SOAP 1.x PROTOKOLU HTTP a má alternativu zásady s kontrolním výrazem wsap:UsingAddressing a bez připojeného kontrolního výrazu cdp:CompositeDuplex.

Specifikace WSDL adresující WSDL se pokouší popsat podobné vazby protokolu zavedením elementu <wsaw:Anonymous/> se třemi textovými hodnotami (povinné, volitelné a zakázané), které označují požadavky v wsa:ReplyTo hlavičce (oddíl 3.2). Tato definice elementu bohužel není zvlášť použitelná jako kontrolní výraz v kontextu WS-Policy, protože vyžaduje rozšíření specifická pro doménu pro podporu průniku alternativ pomocí takového prvku jako kontrolní výraz. Tato definice elementu také označuje hodnotu ReplyTo hlavičky na rozdíl od chování koncového bodu v drátě, což je specifické pro přenos HTTP.

Definice akce

WS-Addressing 2004/08 definuje atribut wsa:Action pro elementy wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault]. WS-Addressing vazba WSDL 1.0 (WS-ADDR10-WSDL) definuje podobný atribut, wsaw10:Action.

Jediným rozdílem mezi těmito dvěma je výchozí sémantika vzorce akcí, která je popsána v části 3.3.2 WS-ADDR a oddílu 4.4.4 WS-ADDR10-WSDL.

Je rozumné mít dva koncové body, které sdílejí stejný portType (nebo kontrakt v terminologii WCF), ale používají různé verze WS-Adresování. Vzhledem k tomu, že akce je definována portType a neměla by se měnit napříč koncovými body, které implementují portType, nebude možné podporovat oba výchozí vzory akcí.

K vyřešení této diskuse WCF podporuje jednu verzi atributu Action .

B3521: WCF používá wsaw10:Action atribut u wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] prvků definovaných ve WS-ADDR10-WSDL k určení identifikátoru Action URI pro odpovídající zprávy bez ohledu na verzi WS-Addressing používanou koncovým bodem.

Použití odkazu na koncový bod uvnitř portu WSDL

WS-ADDR10-WSDL oddíl 4.1 rozšiřuje prvek wsdl:port, aby zahrnoval podřízený prvek <wsa10:EndpointReference…/> pro popis koncového bodu v termínech WS-Addressing. WCF rozšiřuje tento nástroj na WS-Addressing 2004/08, což umožňuje <wsa:EndpointReference…/> zobrazit jako podřízený prvek wsdl:port.

• R3531: Pokud má koncový bod připojenou alternativu zásad s politickým výrazem <wsaw10:UsingAddressing/>, odpovídající prvek wsdl:port může obsahovat podřízený prvek <wsa10:EndpointReference …/>.

• R3532: Pokud wsdl:port obsahuje podřízený prvek<wsa10:EndpointReference …/>, wsa10:EndpointReference/wsa10:Address musí hodnota podřízeného prvku odpovídat hodnotě @address atributu elementu na stejné úrovniwsdl:port/wsdl:location.

• R3533: Pokud má koncový bod připojenou alternativu zásad s odpovídajícím tvrzením zásad <wsap:UsingAddressing/>, může odpovídající prvek wsdl:port obsahovat podřízený prvek <wsa:EndpointReference …/>.

• R3534: Pokud wsdl:port obsahuje podřízený prvek<wsa:EndpointReference …/>, wsa:EndpointReference/wsa:Address musí hodnota podřízeného prvku odpovídat hodnotě @address atributu elementu na stejné úrovniwsdl:port/wsdl:location.

Složení s WS-Security

V souladu s úvahami o zabezpečení v oddílech WS-ADDR a WS-ADDR10 se doporučuje, aby byly všechny hlavičky adresování zpráv podepsány společně s tělem zprávy pro jejich provázání.

Pokud se WS-Security používá k ochraně integrity zpráv, musí být záhlaví zpráv WS-Addressing i záhlaví výsledkem referenčních parametrů nebo vlastností (nebo obojího) podepsána společně s textem zprávy.

Příklady

zpráva One-Way

V tomto scénáři odesílatel odešle příjemci jednosměrnou zprávu. Používají se protokoly SOAP 1.2, HTTP 1.1 a W3C WS-Addressing 1.0.

Struktura zprávy požadavku: Záhlaví zprávy zahrnují wsa10:To a wsa10:Action prvky. Text zprávy obsahuje konkrétní <app:Ping> prvek z oboru názvů aplikace.

Hlavičky HTTP: Cíl v POST odpovídá identifikátoru URI v elementu wsa10:To .

Hlavička Content-Type má hodnotu application/soap+xml podle požadavků protokolu SOAP 1.2. Parametry charset a action jsou zahrnuty. Parametr action hlavičky Content-Type odpovídá hodnotě wsa10:Action záhlaví zprávy.

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>

Příjemce odpoví prázdnou odpovědí HTTP a stavem 202. Příklad odpovědi 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

Mechanismus optimalizace přenosu zpráv SOAP

Tato část popisuje podrobnosti implementace WCF pro HTTP SOAP MTOM. Technologie MTOM je mechanismus kódování zpráv SOAP stejné třídy jako tradiční kódování textu nebo XML nebo binární kódování WCF. MTOM zahrnuje následující:

• Kódovací a balicí mechanismus XML, který popisuje [XOP], který optimalizuje položky informací XML obsahující binární data s kódováním base64 do samostatných binárních částí.

• Zapouzdření MIME balíčku XOP, který serializuje XML Infoset a každou binární část balíčku XOP do samostatné části MIME.

• Kódování MIME XOP aplikované na obálku SOAP 1.x.

• Přenosová vazba HTTP.

MTOM je možné použít s přenosy mimo PROTOKOL HTTP se službou WCF. V tomto tématu se ale zaměříme na HTTP.

Formát MTOM využívá velkou sadu specifikací, které pokrývají MTOM sám, XOP a MIME. Modularita této sady specifikací poněkud ztěžuje rekonstruovat přesné požadavky na formát a sémantiku zpracování. Tato část popisuje požadavky na formát a zpracování pro vazbu HTTP MTOM.

Kódování zpráv MTOM

Generování zpráv MTOM

Část [XOP] 3.1 popisuje proces kódování XML s položkami informací elementu, které obsahují hodnoty base64 do abstraktně definovaného balíčku XOP.

Následující posloupnost kroků popisuje proces kódování specifické pro MTOM:

1. Ujistěte se, že obálka SOAP, která má být zakódována, neobsahuje žádnou položku informací o prvku s [namespace name] jako http://www.w3.org/2004/08/xop/include a [local name] jako Include.

2. Vytvořte prázdný balíček MIME.

3. Identifikujte v rámci original XML Infoset položky informací elementu, které mají být optimalizovány. Aby bylo možné optimalizovat položky, musí být znaky, které tvoří [children] položku informací o prvku, v kanonické podobě xs:base64Binary (viz XSD-2, 3.2.16 base64Binary) a nesmí obsahovat žádné prázdné znaky předcházející, vložené nebo pod obsahem, který není prázdný.

4. Vytvořte obálku SOAP XOP, která je kopií původní obálky SOAP, ale s dětmi každé položky informačního prvku identifikované v předchozím kroku nahrazené položkou informačního prvku xop:Include, vytvořené takto:

   1. Transformujte nahrazené znaky na binární data tím, že je zpracujete jako data zakódovaná v base64.

   2. Vygenerujte jedinečnou hodnotu hlavičky Content-ID, která splňuje požadavky R3133 a R3134.

   3. Vygenerujte hlavičku CONTENT-Transfer-Encoding MIME s binární hodnotou.

   4. Pokud položka informací o prvku optimalizovaná ([nadřazená] položka informací o nově vloženém xop:Include prvku) obsahuje xmime:contentType položku informací o atributu, vygenerujte hlavičku MIME typu Content-Type s hodnotou atributu xmime:contentType .

   5. Vygenerujte novou binární část MIME, jejíž obsah bude tvořen binárními daty dekódovanými z nahrazených znaků zpracovaných jako base64. Použijte hlavičku Content-ID z kroku 4b, hlavičku Content-Transfer-Encoding z kroku 4c a hlavičku Content-Type, pokud byla vygenerována ve kroku 4d.

   6. Přidejte atribut href do elementu xop:Include s hodnotou cid: uri odvozenou z hodnoty hlavičky Content-ID vygenerované v kroku 4b. Odeberte ohraničující znaky "<" a ">", zakódujte zbývající textový řetězec pro URL a přidejte předponu cid:. Následující minimální znaková sada musí být zakódována podle standardů RFC1738 a RFC2396. Ostatní znaky mohou být escapované.

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

5. Vytvořte kořenovou část MIME s obálkou SOAP XOP z kroku 4.

6. Zapište hlavičky HTTP, včetně hlavičky HTTP Content-Type.

7. Napište balíček MIME.

Zpracování zpráv MTOM

Zpracování zprávy MTOM je přesným opakem procesu popsaného v předchozí části Generování zpráv MTOM:

1. Ujistěte se, že kořenová část MIME má typ application/xop+xmlobsahu .

2. Vytvořte obálku SOAP parsováním kořenové části MIME balíčku jako dokumentu XML. Kódování znaků je určeno parametrem charset Content-Type kořenové části MIME.

3. Pro každou informační položku prvku ve vytvořené obálce SOAP, která má jako jediný člen své vlastnosti [podřízené] prvek xop:Include informační položky:

   1. Odeberte předponu cid: a zrušte únik všech sekvencí URI (RFC 2396) v hodnotě atributu @href v prvku xop:Include. Uzavřete výsledný řetězec do "<", ">".

   2. Vyhledejte část MIME s hodnotou hlavičky Content-ID, která odpovídá řetězci odvozeného v kroku 3a.

   3. xop:Include Položku informací o prvku, která se zobrazí ve children vlastnosti každé položky, nahraďte položkami informací o znaku, které představují kanonické kódování base64 (viz XSD-2, 3.2.16 base64Binary) těla entity části MIME identifikované v kroku 3b (účinně nahraďte xop:Include položku informací o prvku daty rekonstruovanými z části balíčku).

Hlavička typu obsahu HTTP

Následuje seznam objasnění WCF pro formát hlavičky HTTP Content-Type zprávy s kódováním SOAP 1.x MTOM odvozené od požadavků uvedených v samotné specifikaci MTOM a jsou odvozeny od MTOM a RFC 2387.

• R4131: Hlavička Content-Type HTTP musí mít hodnotu multipart/related (nerozlišuje velká a malá písmena) a její parametry. Názvy parametrů jsou na velikosti písmen nezávislé. Pořadí parametrů není významné.

• Úplná Backus-Naur Forma (BNF) hlavičky Content-Type pro MIME zprávy je uvedena v dokumentu RFC 2045, sekce 5.1.

• R4132: Hlavička HTTP Content-Type musí mít parametr typu s hodnotou application/xop+xml uzavřenou v uvozovkách.

I když požadavek na použití dvojitých uvozovek není v dokumentu RFC 2387 explicitní, text sleduje, že všechny parametry vícedílného/souvisejícího typu média s největší pravděpodobností obsahují rezervované znaky jako @nebo /, a proto potřebují dvojité uvozovky.

• R4133: Hlavička HTTP Content-Type by měla mít počáteční parametr s hodnotou hlavičky Content-ID části MIME, která obsahuje obálku SOAP 1.x uzavřenou v uvozovkách. Pokud je spouštěcí parametr vynechán, musí první část MIME obsahovat obálku SOAP 1.x.

• R4134: Hlavička HTTP Content-Type pro zprávu s kódováním SOAP 1.1 MTOM musí obsahovat parametr start-info s hodnotou text/xml uzavřenou v uvozovkách.

• R4135: Hlavička HTTP typu obsahu pro zprávu s kódováním MTOM SOAP 1.2 musí obsahovat parametr start-info s hodnotou application/soap+xml, uzavřenou v dvojitých uvozovkách.

• R4136: Hlavička HTTP Content-Type pro zprávu s kódováním SOAP 1.x MTOM musí mít parametr hranice s hodnotou (uzavřenou v uvozovkách), která odpovídá hraniční hranici MIME BNF definovanou v RFC 2046, oddíl 5.1.1.

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

  Příklady:

  SPRÁVNÝ

  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"
  

  SPRÁVNÝ

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

  NESPRÁVNÝ

  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"
  

Část INFOSET MIME

Obálka SOAP 1.x je zapouzdřena jako kořenová součást balíčku XOP MIME a často se nazývá infoset část.

• R4141: Obálka SOAP 1.x musí být zapouzdřena jako kořenová část balíčku XOP MIME, která se nazývá infoset část a odkazovaná z typu obsahu HTTP.

• R4142: Část SOAP Infoset musí obsahovat následující hlavičky MIME: Content-ID, Content-Transfer-Encodinga Content-Type.

Formát hlavičky Content-ID je definován dokumentem RFC 2045 jako

"Content-ID" ":" msg-id

kde msg-id je definován v dokumentu RFC 2822 (který nahrazuje RFC 822, odkazovaný v DOKUMENTU RFC 2045) jako:

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

jedná se o e-mailovou adresu uzavřenou mezi "<" a ">". Předpona [CFWS] a přípona byly přidány do dokumentu RFC 2822 pro přenos komentářů a neměly by se používat k zachování interoperability.

R4143: Hodnota hlavičky Content-ID pro část Infoset MIME musí odpovídat produkci msg-id z RFC 2822 s vynecháním částí předpony a přípony [CFWS].

Řada implementací MIME uvolní požadavky na hodnotu uzavřenou v "<" a ">" jako e-mailovou adresu a používá absoluteURI uzavřenou v "<", ">" vedle e-mailové adresy. Tato verze WCF používá hodnoty hlavičky MIME Content-ID formuláře:

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

R4144: Procesory MTOM by měly akceptovat hodnoty hlavičky Content-ID, které odpovídají následujícímu uvolněnému msg-id.

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

MIME (RFC 2045) poskytuje hlavičku Content-Transfer-Encoding ke komunikaci kódování obsahu části MIME. Výchozí hodnota definovaná pro content-Transfer-Encoding je 7bitová, což není vhodné pro většinu zpráv SOAP, takže hlavička Content-Transfer-Encoding je potřebná pro větší interoperabilitu:

• R4145: Část SOAP Infoset musí obsahovat hlavičku Content-Transfer-Encoding.

• R4146: Pokud je kódování znaku obálky SOAP UTF-8, hodnota hlavičky Content-Transfer-Encoding musí být 8bitová.

• R4147: Pokud je kódování znaku obálky SOAP UTF-16, hodnota hlavičky Content-Transfer-Encoding musí být binární.

• Podle oddílu 5 [XOP],

• R4148: Část Infoset SOAP1.1 musí obsahovat hlavičku Content-Type s typem média application/xop+xml a parametry type="text/xml" a charset

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

• R4149: Část Infosetu SOAP 1.2 musí obsahovat hlavičku Content-Type s médiem typu application/xop+xml a parametry type="application/soap+xml" a charset.

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

  Ačkoli XOP definuje, že parametr charset pro application/xop+xml je volitelný, je nutný pro interoperabilitu podobnou požadavku BP 1.1 na parametr charset pro typ média text/xml.

• R41410: Parametry type a charset musí být přítomny v hlavičce Content-Type části SOAP 1.x Infoset.

Podpora koncových bodů WCF pro MTOM

Účelem MTOM je zakódovat zprávu PROTOKOLU SOAP za účelem optimalizace dat kódovaných pomocí base64. Následuje seznam omezení:

• R4151: Je možné optimalizovat libovolnou položku informací o prvku, která obsahuje data zakódovaná v base64.

• B4152: WCF optimalizuje položky informací o elementech, které obsahují data zakódovaná v base64, a překračuje délku 1024 bajtů.

Koncový bod WCF nakonfigurovaný tak, aby používal MTOM, vždy odesílá zprávy kódované MTOM. I když žádné části nesplňují požadovaná kritéria, zpráva je stále zakódována MTOM (serializována jako balíček MIME s jednou částí MIME obsahující obálku SOAP).

příkaz WS-Policy pro MTOM

WCF používá následující deklaraci zásad k označení využití MTOM podle koncového bodu.

<wsoma:OptimizedMimeSerialization />

• R4211: Předchozí asert zásad má politiku koncového bodu a určuje, že všechny zprávy odesílané a přijímané z tohoto koncového bodu musí být optimalizovány pomocí MTOM.

• B4212: Při konfiguraci pro použití optimalizace MTOM přidá koncový bod WCF zásadní tvrzení MTOM k zásadě připojené k odpovídajícímu wsdl:binding.

Složení s WS-Security

MTOM je mechanismus kódování, který se podobá WCF Binary XML a text/xml. MTOM nabízí přirozené složení s WS-Security a dalšími protokoly WS-*: zprávu zabezpečenou pomocí WS-Security lze optimalizovat pomocí MTOM.

Příklady

ZPRÁVA WCF SOAP 1.1 kódovaná pomocí 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

Zabezpečený protokol SOAP 1.2 WCF s kódováním zpráv pomocí MTOM

V tomto příkladu je zpráva kódována pomocí MTOM a SOAP 1.2, které jsou chráněné pomocí WS-Security. Binární části identifikované pro kódování zahrnují obsah BinarySecurityToken, CipherValue a EncryptedData, které odpovídají šifrovanému podpisu a šifrovanému tělu. Všimněte si, že CipherValue z EncryptedKey nebyl identifikován pro optimalizaci technologií WCF, protože délka je menší než 1024 bajtů.

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