Meddelandeprotokoll

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 täcker detaljer om WCF-implementering för följande protokoll som TextMessageEncodingBindingElement och MtomMessageEncodingBindingElement använder.

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 kommer in i WCF-kanalstacken bearbetas av individuella kanaler som är konfigurerade genom associerade bindningselement, till exempel textmeddelande kodning, säkerhet, tillförlitlig meddelandehantering och transaktioner. Varje kanal identifierar rubriker från det associerade namnområdet och markerar dem som förstådda. När ett meddelande har kommit in i dispatchsystemet läser funktionsformatteraren rubrikerna som förväntas enligt motsvarande meddelande- eller funktionskontrakt och bekräftar deras innehåll. Sedan verifierar distributören om några återstående headers inte förstås men markeras som mustUnderstand och kastar 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: Headers som inte kan tolkas identifieras efter att meddelandet har bearbetats av WCF-infrastrukturens kanalstack, men innan det bearbetas av applikationen.

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 SOAP 1.1 HTTP-bindning enligt Basic Profile 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ändningen utan att kräva att brödtexten i SOAP-meddelandet parsas när WS-Addressing inte används.

R2221: Åtgärdsparametern application/soap+xml måste, när den finns på en SOAP 1.2-begäran, matcha soapAction-attributet på wsoap12:operation-elementet 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-Addressing är inaktiverad och en inkommande begäran inte innehåller någon åtgärdsparameter anses meddelandet Action inte ha angetts.

WS-Addressing

WCF implementerar 3 versioner av WS-Addressing:

WS-Addressing 2004/08
W3C Web Services Adressering 1.0 Core (ADDR10-CORE) och SOAP-bindning (ADDR10-SOAP)
WS-Addressing 1.0 – Metadata

Slutpunktsreferenser

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

Ändpunktsreferenser och WS-Addressing-versioner

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-Addressing 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 implementerats 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 version WS-Addressing som EncodingBinding elementet anger för denna slutpunkt.

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 WS-MetadataExchange -specifikationen (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. Klientapplikationer som har åtkomst till påståendet sp:Issuer måste veta hur de ska kommunicera med slutpunkten för tokenutfärdaren. Klienten måste känna till metadata om token utfärdaren. Med hjälp av de metadatatillägg för slutpunktreferenser som definierats i MEX tillhandahåller WCF en referens till metadata för utfärdare av tokener.

<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-Addressing versionerna använder WCF följande meddelandehuvuden enligt specifikationerna wsa:To, , wsa:ReplyTowsa:Action, wsa:MessageIDoch wsa:RelatesTo.

B3211: För alla WS-Addressing-versioner följer WCF, men genererar inte som standard, WS-Addressing meddelandehuvuden 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 WCF-slutpunkterna har konfigurerats för att använda WS-Addressing 2004/08 skiljer de inte mellan bearbetning av referensegenskaper och referensparametrar.

Meddelandeutbytesmönster

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äran-svar och duplex meddelandeutbyte. Det här avsnittet klargör WS-Addressing krav på 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.

One-Way Meddelande

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-Addressing 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 inkludera MessageID, ReplyTo och 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 funktionskontraktet deklarerar ett enkelriktat meddelande 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.

Request-Reply

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

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

Kod	Orsak
`wsa:DestinationUnreachable`	Ett meddelande kom med en `ReplyTo` som skiljer sig från den svarsadress som 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`, `wsa:From` eller `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-headern.
`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 tyder på att slutpunkten inte kommer att bearbeta sekvensen baserat på en undersökning av `CreateSequence`-meddelandets adresseringshuvuden.

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-bindningar och WS-Policy argument

Anger användning av WS-Addressing

WCF använder policyuttryck för att indikera slutpunktsstöd för en viss WS-Addressing-version.

Följande policyutfästelse 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 />

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

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

<wsam:Addressing/>

Följande policyuttryck har ett ämne för slutpunktens policy [WS-PA] och anger att meddelanden som skickas till 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-förfrågningar är ws-am-påståendet

<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 påstående som har Endpoint Policy Subject [WS-PA] på slutpunkter som använder WSDL 1.1 SOAP 1.x HTTP-bindningar kräver två separata HTTP-uppkopplingar för meddelanden som går från beställaren till svararen och från 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 [address] egenskap som inte är lika med http://www.w3.org/2005/08/addressing/anonymous om slutpunkten använder en WSDL 1.1 SOAP 1.x HTTP-bindning och har ett policyalternativ med ett wsap10:UsingAddressing eller wsap:UsingAddressing intyg kopplat till cdp:CompositeDuplex bifogat.
R3515: Begärandemeddelanden som skickas till en slutpunkt måste ha ett ReplyTo huvud med egenskapen lika [address]med http://www.w3.org/2005/08/addressing/anonymous , 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 lika med http://www.w3.org/2005/08/addressing/anonymous om slutpunkten använder en WSDL 1.1 SOAP 1.x HTTP-bindning och har ett policyalternativ med wsap:UsingAddressing påstående och inget cdp:CompositeDuplex påstående 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 på ReplyTo-huvudet i motsats till slutpunktsbeteendet på nätet, 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 standardåtgärdsmönstersemantiken som beskrivs i avsnitt 3.3.2 i WS-ADDR respektive 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-Addressing version 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-Addressing termer. WCF utökar denna tjänst i WS-Addressing 2004/08, och tillåter <wsa:EndpointReference…/> att visas som ett underordnat element till wsdl:port.

R3531: Om en slutpunkt har ett kopplat policyalternativ med en <wsaw10:UsingAddressing/> policyuttryck 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 syskonelementetwsdl:port/wsdl:location.
R3533: Om en slutpunkt har ett bifogat policysalternativ med <wsap:UsingAddressing/> policyuttryck kan motsvarande wsdl:port element innehålla ett barnelement <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 syskonelementetwsdl:port/wsdl: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 WS-Addressing meddelandehuvuden samt rubriker som är resultatet av referensparametrar eller egenskaper (eller båda) signeras tillsammans med meddelandets brödtext.

Exempel

One-Way Meddelande

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: Destinationen 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.
HTTP-transportbindningen

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 optimera objekten måste tecknen som utgör [children] för elementinformationsobjektet vara i den kanoniska formen av xs:base64Binary (se XSD-2, 3.2.16 base64Binary) och får inte innehålla några blanksteg före, infogade med eller efter icke-blankt innehåll.
Skapa ett XOP SOAP-kuvert som är en kopia av det ursprungliga SOAP-kuvertet, men med varje elementinformationsobjekts barn som identifierades i föregående steg ersatt med ett elementinformationsobjekt xop:Include 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 Content-Transfer-Encoding MIME-rubrik 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 bildas av binära data, avkodade från de ersatta tecken som bearbetats som base64; Content-ID-huvudet från 4b, Content- Transfer-Encoding-huvudet från 4c, och Content-Type-huvudet om det genererades 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-headrarna, inklusive HTTP Content-Type-headern.
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) från värdet av attributet @href i elementet xop:Include. 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 inte 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 inkludera parametern start-info med värdet "application/soap+xml," omslutet av dubbla 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 produktionen msg-id 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 i vissa fall användes absoluteURI, omgiven av "<" och ">", 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) innehåller rubriken Content-Transfer-Encoding för att kommunicera kodning av innehållet i MIME-delen. Standardvärdet som definierats för Content-Transfer-Encoding är 7-bitars, vilket inte är lämpligt för de flesta SOAP-meddelanden, så rubriken Content-Transfer-Encoding krävs för större samverkan:

R4145: SOAP Infoset-delen måste innehålla rubriken Content-Transfer-Encoding.
R4146: Om SOAP-kuvertets teckenkodning är UTF-8 måste värdet för rubriken Content-Transfer-Encoding vara 8-bitars.
R4147: Om SOAP-kuvertteckenkodningen är UTF-16 måste värdet för rubriken Content-Transfer-Encoding vara binärt.
Enligt [XOP] avsnitt 5,
R4148: SOAP1.1-infosetdelen måste innehålla Content-Type-rubriken med mediatypen application/xop+xml och parametrar type="text/xml" och charset
```
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-Policy Utsaga 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-policyassertion till policyn 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 identifierats för kodning är innehållet i BinarySecurityToken och CipherValue tillhörande EncryptedData som motsvarar den krypterade signaturen och den krypterade brödtexten. Observera att CipherValue i EncryptedKey inte identifierades för optimering av WCF, 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--

Last updated on 2025-06-17

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

Slutpunktsreferenser

Ändpunktsreferenser och WS-Addressing-versioner

Slutpunktsreferenser och metadata

Meddelandeadresseringshuvuden

Meddelandehuvuden

Referensparametrar och egenskaper

Meddelandeutbytesmönster

One-Way Meddelande

Request-Reply

Web Services-adresseringsfelmeddelanden

WSDL 1.1-bindningar och WS-Policy argument

Anger användning av WS-Addressing

Åtgärdsdefinition

Använda slutpunktsreferens i WSDL-porten

Sammansättning med WS-Security

Exempel

One-Way Meddelande

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