Meddelandeprotokoll

Artikel
03/02/2024

WCF-kanalstacken (Windows Communication Foundation) använder kodnings- och transportkanaler för att omvandla intern meddelanderepresentation till sitt trådformat och skicka den med hjälp av en viss transport. Den vanligaste transporten som används för webbtjänsters samverkan är HTTP, och de vanligaste kodningarna som används av webbtjänster är XML-baserade SOAP 1.1, SOAP 1.2 och MTOM (Message Transmission Optimization Mechanism).

Det här avsnittet beskriver information om WCF-implementering för följande protokoll som används av HttpTransportBindingElement.

Specifikation/dokument:

Det här avsnittet beskriver information om WCF-implementering för följande protokoll som används och MtomMessageEncodingBindingElement användsTextMessageEncodingBindingElement.

Specifikation/dokument:

Det här avsnittet beskriver information om WCF-implementering för följande protokoll som MtomMessageEncodingBindingElement används.

Specifikation/dokument:

Följande XML-namnområden och associerade prefix används i det här avsnittet:

Prefix	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 och SOAP 1.2

Kuvert och bearbetningsmodell

WCF implementerar SOAP 1.1-kuvertbearbetning efter Basic Profile 1.1 (BP11) och Basic Profile 1.0 (SSBP10). SOAP 1.2 Kuvertbearbetning implementeras efter SOAP12-Part1.

I det här avsnittet beskrivs vissa implementeringsval som WCF har gjort när det gäller BP11 och SOAP12-Part1.

Obligatorisk rubrikbearbetning

WCF följer reglerna för bearbetning av rubriker som har markerats mustUnderstand i specifikationerna SOAP 1.1 och SOAP 1.2, med följande varianter.

Ett meddelande som anger WCF-kanalstacken bearbetas av enskilda kanaler som konfigurerats av associerade bindningselement, till exempel textmeddelandekodning, säkerhet, tillförlitliga meddelanden och transaktioner. Varje kanal identifierar rubriker från det associerade namnområdet och markerar dem som förstådda. När ett meddelande har angetts till avsändaren läser åtgärdsformatören rubriker som förväntas av motsvarande meddelande-/åtgärdskontrakt och markerar dem förstådda. Sedan verifierar avsändaren om några återstående huvuden inte förstås men markeras som mustUnderstand och utlöser ett undantag. Meddelanden som innehåller mustUnderstand rubriker som är riktade till mottagaren bearbetas inte av mottagarens programkod.

Sådan skiktad bearbetning möjliggör separation mellan infrastrukturlager och programskikt i SOAP-noden:

B1111: Rubriker som inte förstås identifieras när meddelandet har bearbetats av WCF-infrastrukturkanalstacken, men innan det bearbetas av programmet

Rubrikvärdet mustUnderstand skiljer sig mellan SOAP 1.1 och SOAP 1.2. Grundläggande profil 1.1 kräver att mustUnderstand värdet är 0 eller 1 för SOAP 1.1-meddelanden. SOAP 1.2 tillåter 0, 1, falseoch true som värden, men rekommenderar att du avger en kanonisk representation av xs:boolean värden (false, true).
B1112: WCF genererar mustUnderstand värdena 0 och 1 för både SOAP 1.1- och SOAP 1.2-versionerna av SOAP-kuvertet. WCF accepterar hela värdeutrymmet xs:boolean för för mustUnderstand rubriken (0, 1, false, true)

SOAP-fel

Följande är en lista över WCF-specifika SOAP-felimplementeringar.

B2121: WCF returnerar följande SOAP 1.1-felkoder: s11:mustUnderstand, s11:Clientoch s11:Server.
B2122: WCF returnerar följande SOAP 1.2-felkoder: s12:MustUnderstand, s12:Senderoch s12:Receiver.

HTTP-bindning

SOAP 1.1 HTTP-bindning

WCF implementerar SOAP1.1 HTTP-bindning efter basicprofil 1.1-specifikationen avsnitt 3.4 med följande förtydliganden:

B2211: WCF-tjänsten implementerar inte omdirigering av HTTP POST-begäranden.
B2212: WCF-klienter stöder HTTP-cookies i enlighet med 3.4.8.

SOAP 1.2 HTTP-bindning

WCF implementerar SOAP 1.2 HTTP-bindning enligt beskrivningen i SOAP 1.2-del 2 -specifikationen (SOAP12Part2) med följande förtydliganden.

SOAP 1.2 introducerade en valfri åtgärdsparameter för application/soap+xml medietypen. Den här parametern är användbar för att optimera meddelandesändning utan att kräva att brödtexten i SOAP-meddelandet parsas när WS-Adressering inte används.

R2221: Åtgärdsparametern application/soap+xml måste, när den soapAction finns på en SOAP 1.2-begäran, matcha attributet på elementet wsoap12:operation i motsvarande WSDL-bindning.
R2222: Åtgärdsparametern application/soap+xml , när den finns i ett SOAP 1.2-meddelande, måste matcha wsa:Action när WS-Addressing 2004/08 eller WS-Addressing 1.0 används.

När WS-Adressering är inaktiverat och en inkommande begäran inte innehåller någon åtgärdsparameter anses meddelandet Action inte ha angetts.

WS-adressering

WCF implementerar 3 versioner av WS-Addressing:

WS-adressering 2004/08
W3C-webbtjänster som adresserar 1.0 Core (ADDR10-CORE) och SOAP-bindning (ADDR10-SOAP)
WS-adressering 1.0 – metadata

Slutpunktsreferenser

Alla versioner av WS-Adressering som WCF implementerar använder slutpunktsreferenser för att beskriva slutpunkter.

Slutpunktsreferenser och WS-adresseringsversioner

WCF implementerar ett antal infrastrukturprotokoll som använder WS-Addressing och i synnerhet elementet EndpointReference och W3C.WsAddressing.EndpointReferenceType klassen (till exempel WS-ReliableMessaging, WS-SecureConversation och WS-Trust). WCF stöder användning av någon av versionerna av WS-Addressing med andra infrastrukturprotokoll. WCF-slutpunkter stöder en version av WS-Adressering per slutpunkt.

För R3111 måste namnområdet för elementet EndpointReference eller typen som används i meddelanden som utbyts med en WCF-slutpunkt matcha versionen av WS-Addressing som implementeras av den här slutpunkten.

Om en WCF-slutpunkt till exempel implementerar WS-ReliableMessaging använder AcksTo huvudet som returneras av en sådan slutpunkt inuti CreateSequenceResponse den WS-Adresseringsversion som elementet EncodingBinding anger för den här slutpunkten.

Slutpunktsreferenser och metadata

Ett antal scenarier kräver att metadata kommuniceras eller en referens till metadata för en viss slutpunkt.

B3121: WCF använder mekanismer som beskrivs i specifikationen WS-MetadataExchange (MEX) avsnitt 6 för att inkludera metadata för slutpunktsreferenser efter värde eller referens.

Tänk dig ett scenario där en WCF-tjänst kräver autentisering med hjälp av en SAML-token (Security Assertions Markup Language) som utfärdats av token utfärdaren på http://sts.fabrikam123.com. WCF-slutpunkten beskriver det här autentiseringskravet med hjälp sp:IssuedToken av en försäkran med en kapslad sp:Issuer försäkran som pekar på token utfärdaren. Klientprogram som har åtkomst till försäkran sp:Issuer måste veta hur de ska kommunicera med slutpunkten för token utfärdaren. Klienten måste känna till metadata om token utfärdaren. Med hjälp av slutpunktsreferensens metadatatillägg som definierats i MEX tillhandahåller WCF en referens till metadata för tokenutfärdaren.

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

Meddelandeadresseringshuvuden

Meddelandehuvuden

För båda WS-adresseringsversionerna använder WCF följande meddelandehuvuden enligt specifikationerna wsa:To, , wsa:ReplyTowsa:Action, wsa:MessageIDoch wsa:RelatesTo.

B3211: För alla WS-adresseringsversioner respekterar WCF, men producerar inte ur rutan, sidhuvuden för WS-adresseringsmeddelanden wsa:FaultTo och wsa:From.

Program som interagerar med WCF-program kan lägga till dessa meddelandehuvuden och WCF bearbetar dem därefter.

Referensparametrar och egenskaper

WCF implementerar bearbetning av slutpunktsreferensparametrar och referensegenskaper i enlighet med respektive specifikationer.

B3221: När WS-Adressering 2004/08 har konfigurerats för att använda WS-adressering skiljer inte WCF-slutpunkter mellan bearbetning av referensegenskaper och referensparametrar.

Exchange-mönster för meddelanden

Sekvensen med meddelanden som ingår i webbtjänståtgärdens anrop kallas för mönstret för meddelandeutbyte. WCF har stöd för mönster för enkelriktad, begärandesvar och duplex-meddelandeutbyte. I det här avsnittet beskrivs WS-adresseringskrav för meddelandebearbetning beroende på vilket mönster för meddelandeutbyte som används.

I det här avsnittet skickar beställaren det första meddelandet och svararen tar emot det första meddelandet.

Enkelriktade meddelanden

När en WCF-slutpunkt har konfigurerats för att stödja meddelanden med en given Action för att följa ett enkelriktat mönster följer WCF-slutpunkten följande beteenden och krav. Om inget annat anges gäller beteenden och regler för båda versionerna av WS-Adressering som stöds i WCF:

R3311: Beställaren måste inkludera wsa:To, wsa:Actionoch rubriker för alla referensparametrar som anges av slutpunktsreferensen. När WS-Addressing 2004/08 används och [referensegenskaper] anges av slutpunktsreferensen måste motsvarande rubriker läggas till i meddelandet också.
B3312: Beställaren kan innehålla MessageID, ReplyTooch FaultTo rubriker. Mottagarinfrastrukturen ignorerar dem och de skickas till programmet.
R3313: När HTTP används och inget meddelande skickas på HTTP-svarsbenet måste svararen skicka ett HTTP-svar med en tom brödtext och en HTTP 202-statuskod.

När HTTP-transporten används och åtgärdskontraktet deklarerar ett meddelande enkelriktad kan HTTP-svaret fortfarande användas för att skicka infrastrukturmeddelanden, till exempel kan tillförlitliga meddelanden skicka ett SequenceAcknowledgement meddelande på ett HTTP-svar.
B3314: WCF-svararen skickar inte ett felmeddelande som svar på ett enkelriktad meddelande.

Begärandesvar

När en WCF-slutpunkt har konfigurerats för ett meddelande med en angiven Action för att följa mönstret för begäran-svar följer WCF-slutpunkten beteendena och kraven nedan. Om inget annat anges gäller beteenden och regler för båda versionerna av WS-Adressering som stöds i WCF:

R3321: Beställaren måste inkludera i begäran wsa:To, wsa:Action, wsa:MessageIDoch rubriker för alla referensparametrar eller referensegenskaper (eller båda) som anges av slutpunktsreferensen.
R3322: När WS-Addressing 2004/08 används ReplyTo måste även inkluderas i begäran.
R3323: När WS-Addressing 1.0 används och ReplyTo inte finns i begäran används en standardslutpunktsreferens med egenskapen [address] lika http://www.w3.org/2005/08/addressing/anonymous med.
R3324: Beställaren måste inkludera wsa:To, wsa:Actionoch wsa:RelatesTo rubriker i svarsmeddelandet samt rubriker för alla referensparametrar eller referensegenskaper (eller båda) som anges av slutpunktsreferensen ReplyTo i begäran.

Web Services–adresseringsfel

R3411: WCF genererar följande fel som definieras av WS-Addressing 2004/08.

Kod	Orsak
`wsa:DestinationUnreachable`	Meddelandet kom med en `ReplyTo` som skiljer sig från svarsadressen som har upprättats för den här kanalen. Det finns ingen slutpunkt som lyssnar på den adress som anges i till-huvudet.
`wsa:ActionNotSupported`	infrastrukturkanalerna eller avsändaren som är associerade med slutpunkten känner inte igen åtgärden som anges i `Action` rubriken.

R3412: WCF genererar följande fel som definieras av WS-Addressing 1.0.

Kod	Orsak
`wsa10:InvalidAddressingHeader`	Duplicera `wsa:To`, `wsa:ReplyTo`eller `wsa:From` `wsa:MessageID`. Duplicera `wsa:RelatesTo` med samma `RelationshipType`.
`wsa10:MessageAddressingHeaderRequired`	Den adressrubrik som krävs saknas.
`wsa10:DestinationUnreachable`	Meddelandet kom med en `ReplyTo` som skiljer sig från svarsadressen som har upprättats för den här kanalen. Det finns ingen slutpunkt som lyssnar på den adress som anges i till-huvudet.
`wsa10:ActionNotSupported`	En åtgärd som anges i `Action` rubriken identifieras inte av infrastrukturkanalerna eller avsändaren som är associerad med slutpunkten.
`wsa10:EndpointUnavailable`	RM-kanalen skickar tillbaka det här felet, vilket indikerar att slutpunkten inte bearbetar sekvensen baserat på undersökning av meddelandets adresseringshuvuden `CreateSequence` .

Koden i föregående tabeller mappar till FaultCode i SOAP 1.1 och SubCode (med Code=Sender) i SOAP 1.2.

WSDL 1.1-bindning och WS-principkontroller

Som anger användning av WS-adressering

WCF använder principkontroller för att ange slutpunktsstöd för en viss WS-adresseringsversion.

Följande principkontroll har Endpoint Policy Subject [WS-PA] och anger att meddelanden som skickas och tas emot från slutpunkten måste använda WS-Addressing 2004/08.

<wsap:UsingAddressing />

Den här princippåståendet utökar specifikationen WS-Addressing 2004/08.

Följande principkontroll anger att meddelanden som skickas/tas emot måste använda WS-Addressing 1.0.

<wsam:Addressing/>

Följande principkontroll har ett endpoint Policy Subject [WS-PA] och anger att meddelanden som skickas och tas emot från slutpunkten måste använda WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

Elementet wsaw10:UsingAddressing lånas från [WS-Addressing-WSDL] och används i samband med WS-Policy i enlighet med den specifikationen, avsnitt 3.1.2.

Användning av adresser ändrar inte semantiken för HTTP-bindningar för WSDL 1.1, SOAP 1.1 och SOAP 1.2. Om ett svar till exempel förväntas till en begäran som skickas till en slutpunkt som använder Adressering och WSDL SOAP 1.x HTTP-bindning, måste svaret skickas med hjälp av HTTP-svaret.

För svar som skickas via http-svaret är WS-AM-försäkran:

<wsam:AnonymousResponses/>

Det fullständiga princippåståendet kan se ut så här:

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

Det finns dock mönster för meddelandeutbyte som drar nytta av att ha två oberoende http-anslutningar som upprättats mellan beställaren och svararen, till exempel oönskade enkelriktade meddelanden som skickas av svararen.

WCF erbjuder en funktion med vilken två underliggande transportkanaler kan bilda en sammansatt Duplex-kanal, där en kanal används för indatameddelanden och den andra används för utdatameddelanden. När det gäller HTTP-transporten tillhandahåller sammansatt duplex två omvända HTTP-anslutningar. Beställaren använder en anslutning för att skicka meddelanden till svararen och svararen använder den andra för att skicka tillbaka meddelanden till beställaren.

För svar som skickas via separata http-begäranden är ws-am-försäkran

<wsam:NonAnonymousResponses/>

Det fullständiga princippåståendet kan se ut så här:

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

Användning av följande försäkran som har Endpoint Policy Subject [WS-PA] på slutpunkter som använder WSDL 1.1 SOAP 1.x HTTP-bindningar kräver att två separata converse HTTP-anslutningar används för meddelanden som flödar från beställaren till svararen respektive svararen till beställaren.

<cdp:CompositeDuplex/>

Föregående instruktion leder till följande krav i wsa:ReplyTo rubriken för begärandemeddelanden:

R3514: Begärandemeddelanden som skickas till en slutpunkt måste ha ett ReplyTo huvud med egenskapen som inte är lika http://www.w3.org/2005/08/addressing/anonymous med [address] om slutpunkten använder en WSDL 1.1 SOAP 1.x HTTP-bindning och har ett principalternativ med en eller wsap:UsingAddressing ett wsap10:UsingAddressing intyg kopplat till cdp:CompositeDuplex bifogad.
R3515: Begärandemeddelanden som skickas till en slutpunkt måste ha ett ReplyTo huvud med egenskapen lika http://www.w3.org/2005/08/addressing/anonymousmed [address] , eller inte ha ett ReplyTo huvud alls, om slutpunkten använder en WSDL 1.1 SOAP 1.x HTTP-bindning och har ett principalternativ med wsap10:UsingAddressing försäkran och inget cdp:CompositeDuplex intyg bifogat.
R3516: Begärandemeddelanden som skickas till en slutpunkt måste ha ett ReplyTo huvud med en [address] egenskap som är http://www.w3.org/2005/08/addressing/anonymous lika med om slutpunkten använder en WSDL 1.1 SOAP 1.x HTTP-bindning och har ett principalternativ med wsap:UsingAddressing försäkran och inget cdp:CompositeDuplex intyg bifogat.

WS-adresserande WSDL-specifikationen försöker beskriva liknande protokollbindningar genom att införa ett element <wsaw:Anonymous/> med tre textvärden (obligatoriskt, valfritt och förbjudet) för att ange krav på wsa:ReplyTo rubriken (avsnitt 3.2). Tyvärr är en sådan elementdefinition inte särskilt användbar som ett påstående i samband med WS-Policy, eftersom det kräver domänspecifika tillägg för att stödja skärningspunkten mellan alternativ med hjälp av ett sådant element som ett påstående. En sådan elementdefinition anger också värdet för ReplyTo huvudet i stället för slutpunktsbeteendet på tråden, vilket gör det specifikt för HTTP-transport.

Åtgärdsdefinition

WS-Addressing 2004/08 definierar ett wsa:Action attribut för elementen wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] . WS-Addressing 1.0 WSDL-bindning (WS-ADDR10-WSDL) definierar ett liknande attribut, wsaw10:Action.

Den enda skillnaden mellan de två är standardsemantiken för åtgärdsmönster som beskrivs i avsnitt 3.3.2 i WS-ADDR och avsnitt 4.4.4 i WS-ADDR10-WSDL.

Det är rimligt att ha två slutpunkter som delar samma portType (eller kontrakt, i WCF-terminologi) men som använder olika versioner av WS-Addressing. Men med tanke på att Åtgärden definieras av portType och inte bör ändras mellan slutpunkterna som implementerar portTypeblir det omöjligt att stödja båda standardåtgärdsmönstren.

För att lösa den här kontroversen har WCF stöd för en enda version av attributet Action .

B3521: WCF använder wsaw10:Action attributet på wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] element enligt definitionen i WS-ADDR10-WSDL för att fastställa Action URI:n för motsvarande meddelanden oavsett vilken WS-Adresseringsversion som används av slutpunkten.

Använda slutpunktsreferens i WSDL-porten

WS-ADDR10-WSDL avsnitt 4.1 utökar elementet wsdl:port till att omfatta det <wsa10:EndpointReference…/> underordnade elementet för att beskriva slutpunkten i WS-Adresseringsvillkor. WCF expanderar det här verktyget på WS-Addressing 2004/08, så att det kan <wsa:EndpointReference…/> visas som ett underordnat element i wsdl:port.

R3531: Om en slutpunkt har ett kopplat principalternativ med en <wsaw10:UsingAddressing/> principkontroll kan motsvarande wsdl:port element innehålla ett underordnat element <wsa10:EndpointReference …/>.
R3532: Om en wsdl:port innehåller ett underordnat element <wsa10:EndpointReference …/>måste det wsa10:EndpointReference/wsa10:Address underordnade elementvärdet matcha värdet för @address attributet för syskonelementet/wsdl:portwsdl:location.
R3533: Om en slutpunkt har ett bifogat principalternativ med <wsap:UsingAddressing/> principkontroll kan motsvarande wsdl:port element innehålla ett underordnat element <wsa:EndpointReference …/>.
R3534: Om en wsdl:port innehåller ett underordnat element <wsa:EndpointReference …/>måste det wsa:EndpointReference/wsa:Address underordnade elementvärdet matcha värdet @address för attributet för syskonelementet/wsdl:portwsdl:location.

Sammansättning med WS-Security

Enligt avsnitten om säkerhetsöverväganden i WS-ADDR och WS-ADDR10 rekommenderar vi att alla adresserande meddelandehuvuden signeras tillsammans med meddelandetexten för att binda ihop dem.

När WS-Security används för skydd mot meddelandeintegritet måste sidhuvuden för WS-Adressering samt rubriker som är resultatet av referensparametrar eller egenskaper (eller båda) signeras tillsammans med meddelandets brödtext.

Exempel

Enkelriktade meddelanden

I det här scenariot skickar avsändaren ett enkelriktat meddelande till mottagaren. SOAP 1.2, HTTP 1.1 och W3C WS-Addressing 1.0 används.

Meddelandestrukturen för begäran: Meddelanderubrikerna innehåller wsa10:To och wsa10:Action element. Meddelandetexten innehåller ett specifikt <app:Ping> element från programmets namnområde.

HTTP-huvuden: Målet i POST matchar URI:n i elementet wsa10:To .

Rubriken Innehållstyp har värdet application/soap+xml som krävs av SOAP 1.2. Parametrar charset och action ingår. Parametern action för rubriken Content-Type matchar värdet för wsa10:Action meddelandehuvudet.

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>

Mottagaren svarar med ett tomt HTTP-svar och status 202. Ett exempel på HTTP-svaret:

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

Mekanism för optimering av SOAP-meddelandeöverföring

I det här avsnittet beskrivs WCF-implementeringsinformationen för HTTP SOAP MTOM. MTOM-teknik är SOAP-meddelandekodningsmekanismen i samma klass som traditionell text-/XML-kodning eller WCF-binär kodning. MTOM innehåller följande:

En XML-kodnings- och paketeringsmekanism som beskrivs av [XOP] som optimerar XML-informationsobjekt som innehåller base64-kodade binära data i separata binära delar.
En MIME-inkapsling av XOP-paketet som serialiserar XML Infoset och varje binär del av XOP-paketet till en separat MIME-del.
En MIME XOP-kodning som tillämpas på SOAP 1.x-kuvert.
En HTTP-transportbindning.

Det är möjligt att använda MTOM med icke-HTTP-transporter med WCF. I det här avsnittet fokuserar vi dock på HTTP.

MTOM-formatet använder en stor uppsättning specifikationer som täcker själva MTOM, XOP och MIME. Modularitet i den här specifikationsuppsättningen gör det något svårt att rekonstruera exakta krav på formatet och bearbetningssemantiken. I det här avsnittet beskrivs format- och bearbetningskraven för MTOM HTTP-bindning.

MTOM-meddelandekodning

Generera MTOM-meddelanden

[XOP] avsnitt 3.1 beskriver processen med att koda XML med elementinformationsobjekt som innehåller base64-värden i ett abstrakt definierat XOP-paket.

Följande stegsekvens beskriver den MTOM-specifika kodningsprocessen:

Kontrollera att SOAP-kuvertet som ska kodas inte innehåller något elementinformationsobjekt med en [namespace name] av http://www.w3.org/2004/08/xop/include och en [local name] av Include.
Skapa ett tomt MIME-paket.
Identifiera elementinformationsobjekten som ska optimeras i den ursprungliga XML-informationsuppsättningen. För att objekten ska optimeras måste tecknen som utgör [children] elementinformationsobjektet vara i kanonisk form ( xs:base64Binary se XSD-2, 3.2.16 base64Binary) och får inte innehålla några blankstegstecken före, infogat med eller efter innehållet som inte är tomt utrymme.
Skapa ett XOP SOAP-kuvert som är en kopia av det ursprungliga SOAP-kuvertet, men med underordnade elementinformationsobjekt som identifierades i föregående steg ersatt av ett xop:Include elementinformationsobjekt som skapades på följande sätt:
1. Omvandla de ersatta tecknen till binära data genom att bearbeta dem som base64-kodade data.
2. Generera ett unikt innehålls-ID-huvudvärde som uppfyller kraven R3133 och R3134.
3. Generera en MIME-rubrik för innehållsöverföring och kodning med värdet binärt.
4. Om elementinformationsobjektet som optimeras ([överordnat] för det nyligen infogade xop:Include elementinformationsobjektet) har ett xmime:contentType attributinformationsobjekt genererar du ett MIME-huvud av innehållstyp med värdet för xmime:contentType attributet.
5. Generera en ny binär MIME-del med innehåll som består av binära data som avkodas från de ersatta tecknen som bearbetas som base64, Content-ID-huvudet från 4b, Content- Transfer-Encoding-huvudet från 4c, Content-Type-huvudet om det genereras i steg 4d.
6. Lägg till ett href attribut till elementet xop:Include med värdet cid: uri som härleds från content-ID-huvudvärdet som genererades i steg 4b. Ta bort de omslutande tecknen "<" och ">", URL-escape den återstående strängen och lägg till prefixet cid:. Följande minsta teckenuppsättning måste vara undantagen av RFC1738 och RFC2396. Andra tecken kan undantagas.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Skapa en MIME-rotdel med XOP SOAP-kuvertet från steg 4.
Skriv HTTP-huvudena, inklusive rubriken HTTP Content-Type.
Skriv MIME-paketet.

Bearbeta MTOM-meddelanden

Bearbetning av ett MTOM-meddelande är den exakta omvända processen som beskrivs i avsnittet "Generera MTOM-meddelanden":

Kontrollera att MIME-rotdelen har innehållstypen application/xop+xml.
Skapa ett SOAP-kuvert genom att parsa mime-rotdelen i paketet som ett XML-dokument. Teckenkodning bestäms av parametern charset för innehållstypen för mime-rotdelen.
För varje elementinformationsobjekt i det konstruerade SOAP-kuvertet, som som enda medlem i egenskapen [underordnade] har ett xop:Include elementinformationsobjekt:
1. Ta bort prefixet cid: och ta bort alla URI-escape-sekvenser (RFC 2396) i värdet för @href elementets xop:Include attribut. Omslut resultatsträngen i "<", ">".
2. Leta upp MIME-delen med det innehålls-ID-huvudvärde som matchar strängen som härleds i steg 3a.
3. Ersätt elementinformationsobjektet xop:Include som visas i children egenskapen för varje objekt med de teckeninformationsobjekt som representerar den kanoniska base64-kodningen (se XSD-2, 3.2.16 base64Binary) för entitetstexten i MIME-delen som identifierades i steg 3b (ersätt elementinformationsobjektet xop:Include effektivt med de data som rekonstruerats från paketdelen).

HTTP-innehållstyprubrik

Följande är en lista över WCF-förtydliganden för formatet för HTTP Content-Type-huvudet för ett SOAP 1.x MTOM-kodat meddelande som härleds från kraven som anges i själva MTOM-specifikationen och härleds från MTOM och RFC 2387.

R4131: En HTTP Content-Type-rubrik måste ha värdet multipart/related (skiftlägesokänslig) och dess parametrar. Parameternamn är skiftlägeskänsliga. Parameterordningen är inte betydande.
Det fullständiga Backus-Naur-formuläret (BNF) för rubriken Innehållstyp för MIME-meddelanden visas i RFC 2045, avsnitt 5.1.
R4132: Ett HTTP Content-Type-huvud måste ha en typparameter med värdet application/xop+xml omgivet av dubbla citattecken.

Även om kravet på att använda dubbla citattecken inte är explicit i RFC 2387, observerar texten att alla parametrar för multipart/relaterad medietyp troligen innehåller reserverade tecken som "@" eller "/" och därför behöver dubbla citattecken.

R4133: Ett HTTP Content-Type-huvud ska ha en startparameter med värdet för innehålls-ID-huvudet för MIME-delen som innehåller SOAP 1.x-kuvertet, omgivet av dubbla citattecken. Om startparametern utelämnas måste den första MIME-delen innehålla SOAP 1.x-kuvertet.
R4134: Ett HTTP Content-Type-huvud för ett SOAP 1.1 MTOM-kodat meddelande måste innehålla parametern start-info med värdet text/xml, omgivet av dubbla citattecken.
R4135: Ett HTTP-innehållstyphuvud för ett SOAP 1.2 MTOM-kodat meddelande måste innehålla parametern start-info med värdet , omgiven av application/soap+xmldubbla citattecken.

R4136: HTTP Content-Type-huvudet för ett SOAP 1.x MTOM-kodat meddelande måste ha gränsparametern med värdet (omgivet av dubbla citattecken) som matchar MIME-gränsen BNF som definieras i RFC 2046, avsnitt 5.1.1

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

Exempel:

KORREKT

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"

KORREKT

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

FELAKTIG

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

Infoset MIME-del

SOAP 1.x-kuvertet är inkapslat som en rotdel i XOP MIME-paketet och kallas ofta delen infoset .

R4141: SOAP 1.x-kuvertet måste kapslas in som en rotdel av XOP MIME-paketet, som kallas infoset delen och refereras från HTTP-innehållstypen.
R4142: SOAP-delen Infoset måste innehålla följande MIME-huvuden: Content-ID, Content-Transfer-Encodingoch Content-Type.

Formatet för innehålls-ID-huvudet definieras av RFC 2045 som

"Content-ID" ":" msg-id

där msg-id definieras i RFC 2822 (som ersätter RFC 822, som anges i RFC 2045) som:

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

och är i själva verket en e-postadress som omges av "<" och ">". Prefixet [CFWS] och suffixet lades till i RFC 2822 för att ge kommentarer och bör inte användas för att bevara samverkan.

R4143: Värdet för Content-ID-huvudet för Infoset MIME-delen måste följa msg-id produktionen från RFC 2822 med prefixet och suffixdelarna [CFWS] utelämnade.

Ett antal MIME-implementeringar lättade på kraven för att värdet inom "<" och ">" ska vara en e-postadress och användas absoluteURI omgiven i "<" , ">" utöver e-postadressen. Den här versionen av WCF använder värden för MIME-rubriken för innehålls-ID i formuläret:

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

R4144: MTOM-processorer bör acceptera rubrikvärden för innehålls-ID som matchar följande avslappnade msg-id.

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

MIME (RFC 2045) tillhandahåller rubriken Content-Transfer-Encoding för att kommunicera kodning av innehållet i MIME-delen. Standardvärdet som definieras för Content-Transfer-Encoding är 7-bitars, vilket inte är lämpligt för de flesta SOAP-meddelanden, så rubriken Content-Transfer-Encoding behövs för större samverkan:

R4145: SOAP Infoset-delen måste innehålla rubriken Content-Transfer-Encoding.
R4146: Om SOAP-kuvertteckenkodningen är UTF-8 måste värdet för rubriken Content-Transfer-Encoding vara 8-bitars.
R4147: Om SOAP-kuvertets teckenkodning är UTF-16 måste värdet för rubriken Content-Transfer-Encoding vara binärt.
Enligt [XOP] avsnitt 5,
R4148: SOAP1.1 Infoset-delen måste innehålla innehållstypsrubrik med mediatypsprogram/xop+xml och parametrar type="text/xml" och teckenuppsättning
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: Soap 1.2 Infoset-delen måste innehålla rubriken Innehållstyp med medietyp application/xop+xml och parametertyp="application/soap+xml" och charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
XOP definierar parametern charset för application/xop+xml att vara valfri, men den behövs för samverkan som liknar BP 1.1-kravet på parametern charset för text/xml medietypen.
R41410: Parametrarna type och charset måste finnas i innehållstypsrubriken i SOAP 1.x Infoset-delen.

WCF-slutpunktsstöd för MTOM

Syftet med MTOM är att koda ett SOAP-meddelande för att optimera base64-kodade data. Följande är en lista över begränsningar:

R4151: Alla elementinformationsobjekt som innehåller base64-kodade data kan optimeras.
B4152: WCF optimerar elementinformationsobjekt som innehåller base64-kodade data och som är längre än 1 024 byte.

En WCF-slutpunkt som har konfigurerats för att använda MTOM skickar alltid MTOM-kodade meddelanden. Även om inga delar uppfyller de obligatoriska kriterierna är meddelandet fortfarande MTOM-kodat (serialiserat som ett MIME-paket med en enda MIME-del som innehåller SOAP-kuvertet).

WS-principkontroll för MTOM

WCF använder följande principkontroll för att ange MTOM-användning per slutpunkt:

<wsoma:OptimizedMimeSerialization />

R4211: Föregående principkontroll har ett Endpoint Policy Subject och anger att alla meddelanden som skickas till och tas emot från slutpunkten måste optimeras med hjälp av MTOM.
B4212: När den har konfigurerats för att använda MTOM-optimering lägger en WCF-slutpunkt till en MTOM-principkontroll till principen som är kopplad till motsvarande wsdl:binding.

Sammansättning med WS-Security

MTOM är en kodningsmekanism som liknar text/xml och WCF Binary XML. MTOM erbjuder naturlig komposition med WS-Security och andra WS-* protokoll: ett meddelande som skyddas med WS-Security kan optimeras med hjälp av MTOM.

Exempel

WCF SOAP 1.1-meddelande kodat med 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-meddelande kodat med MTOM

I det här exemplet kodas ett meddelande med MTOM och SOAP 1.2 som skyddas med WS-Security. De binära delar som identifieras för kodning är innehållet i BinarySecurityToken, CipherValue för motsvarande EncryptedData den krypterade signaturen och den krypterade brödtexten. Observera att CipherValue optimeringen EncryptedKey av WCF inte identifierades eftersom dess längd är mindre än 1 024 byte.

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

Dela via

Meddelandeprotokoll

SOAP 1.1 och SOAP 1.2

Kuvert och bearbetningsmodell

Obligatorisk rubrikbearbetning

SOAP-fel

HTTP-bindning

SOAP 1.1 HTTP-bindning

SOAP 1.2 HTTP-bindning

WS-adressering

Slutpunktsreferenser

Slutpunktsreferenser och WS-adresseringsversioner

Slutpunktsreferenser och metadata

Meddelandeadresseringshuvuden

Meddelandehuvuden

Referensparametrar och egenskaper

Exchange-mönster för meddelanden

Enkelriktade meddelanden

Begärandesvar

Web Services–adresseringsfel

WSDL 1.1-bindning och WS-principkontroller

Som anger användning av WS-adressering

Åtgärdsdefinition

Använda slutpunktsreferens i WSDL-porten

Sammansättning med WS-Security

Exempel

Enkelriktade meddelanden

Mekanism för optimering av SOAP-meddelandeöverföring

MTOM-meddelandekodning

Generera MTOM-meddelanden

Bearbeta MTOM-meddelanden

HTTP-innehållstyprubrik

Infoset MIME-del

WCF-slutpunktsstöd för MTOM

WS-principkontroll för MTOM

Sammansättning med WS-Security

Exempel

WCF SOAP 1.1-meddelande kodat med MTOM

WCF Secure SOAP 1.2-meddelande kodat med MTOM

Ytterligare resurser