Berichtenprotocollen

Artikel
03/02/2024

De WCF-kanaalstack (Windows Communication Foundation) maakt gebruik van coderings- en transportkanalen om de interne berichtweergave te transformeren in de draadindeling en deze te verzenden met behulp van een bepaald transport. Het meest voorkomende transport dat wordt gebruikt voor webservices-interoperabiliteit is HTTP en de meest voorkomende coderingen die door webservices worden gebruikt, zijn OP XML gebaseerde SOAP 1.1, SOAP 1.2 en Message Transmission Optimization Mechanism (MTOM).

In dit onderwerp worden de wcF-implementatiedetails behandeld voor de volgende protocollen die worden gebruikt door HttpTransportBindingElement.

Specificatie/document:

In dit onderwerp worden wcF-implementatiedetails behandeld voor de volgende protocollen die TextMessageEncodingBindingElement en MtomMessageEncodingBindingElement deze gebruiken.

Specificatie/document:

In dit onderwerp vindt u informatie over de WCF-implementatie voor de volgende protocollen die MtomMessageEncodingBindingElement worden gebruikt.

Specificatie/document:

In dit onderwerp worden de volgende XML-naamruimten en bijbehorende voorvoegsels gebruikt:

Voorvoegsel	Naamruimte Uniform Resource Identifier (URI)
s11	`http://schemas.xmlsoap.org/soap/envelope`
s12	`http://www.w3.org/2003/05/soap-envelope`
wsa	`http://www.w3.org/2004/08/addressing`
wsam	`http://www.w3.org/2007/05/addressing/metadata`
wsap	`http://schemas.xmlsoap.org/ws/2004/09/policy/addressing`
wsa10	`http://www.w3.org/2005/08/addressing`
wsaw10	`http://www.w3.org/2006/05/addressing/wsdl`
xop	`http://www.w3.org/2004/08/xop/include`
xmime	`http://www.w3.org/2004/06/xmlmime` `http://www.w3.org/2005/05/xmlmime`
Dp	`http://schemas.microsoft.com/net/2006/06/duplex`

SOAP 1.1 en SOAP 1.2

Envelop- en verwerkingsmodel

WCF implementeert SOAP 1.1-envelopverwerking na Basisprofiel 1.1 (BP11) en Basisprofiel 1.0 (SSBP10). SOAP 1.2 Envelopverwerking wordt geïmplementeerd na SOAP12-Part1.

In deze sectie worden bepaalde implementatieopties uitgelegd die door WCF worden genomen met betrekking tot BP11 en SOAP12-Part1.

Verplichte headerverwerking

WCF volgt regels voor het verwerken van headers die zijn gemarkeerd mustUnderstand in de specificaties van SOAP 1.1 en SOAP 1.2, met de volgende variaties.

Een bericht dat de WCF-kanaalstack invoert, wordt verwerkt door afzonderlijke kanalen die zijn geconfigureerd door gekoppelde bindingselementen, zoals tekstberichtcodering, beveiliging, betrouwbare berichten en transacties. Elk kanaal herkent headers uit de bijbehorende naamruimte en markeert deze als begrepen. Zodra een bericht de dispatcher binnenkomt, leest de bewerkingsopmaakster headers die worden verwacht door het bijbehorende bericht-/bewerkingscontract en markeert deze begrepen. Vervolgens controleert de dispatcher of eventuele resterende headers niet worden begrepen, maar gemarkeerd als mustUnderstand en genereert een uitzondering. Berichten die headers bevatten mustUnderstand die zijn gericht op de geadresseerde, worden niet verwerkt door de toepassingscode van de ontvanger.

Dergelijke gelaagde verwerking maakt scheiding mogelijk tussen infrastructuurlagen en toepassingslagen van het SOAP-knooppunt:

B1111: Headers die niet worden begrepen, worden gedetecteerd nadat het bericht is verwerkt door de WCF-infrastructuurkanaalstack, maar voordat het wordt verwerkt door de toepassing

De mustUnderstand headerwaarde verschilt tussen SOAP 1.1 en SOAP 1.2. Basisprofiel 1.1 vereist dat de mustUnderstand waarde 0 of 1 is voor SOAP 1.1-berichten. SOAP 1.2 staat 0, 1 en falsetrue als waarden toe, maar raadt aan om een canonieke weergave van xs:boolean waarden (false,true) te verzenden.
B1112: WCF verzendt mustUnderstand waarden 0 en 1 voor zowel SOAP 1.1- als SOAP 1.2-versies van de SOAP-envelop. WCF accepteert de volledige waarderuimte van xs:boolean de mustUnderstand header (0, 1, false, ) true

SOAP-fouten

Hier volgt een lijst met WCF-specifieke SOAP-fout-implementaties.

B2121: WCF retourneert de volgende SOAP 1.1-foutcodes: s11:mustUnderstand, s11:Clienten s11:Server.
B2122: WCF retourneert de volgende SOAP 1.2-foutcodes: s12:MustUnderstand, s12:Senderen s12:Receiver.

HTTP-binding

SOAP 1.1 HTTP-binding

WCF implementeert SOAP1.1 HTTP-binding volgens de specificatiesectie 1.1 Basic Profile 3.4 met de volgende verduidelijkingen:

B2211: de WCF-service implementeert geen omleiding van HTTP POST-aanvragen.
B2212: WCF-clients ondersteunen HTTP-cookies in overeenstemming met 3.4.8.

SOAP 1.2 HTTP-binding

WCF implementeert SOAP 1.2 HTTP-binding zoals beschreven in de SOAP 1.2-part 2 -specificatie (SOAP12Part2) met de volgende verduidelijkingen.

SOAP 1.2 heeft een optionele actieparameter geïntroduceerd voor het application/soap+xml mediatype. Deze parameter is handig om berichtverzending te optimaliseren zonder dat de hoofdtekst van het SOAP-bericht moet worden geparseerd wanneer WS-Adressering niet wordt gebruikt.

R2221: De application/soap+xml actieparameter, die aanwezig is op een SOAP 1.2-aanvraag, moet overeenkomen met het soapAction kenmerk op het wsoap12:operation element in de bijbehorende WSDL-binding.
R2222: De application/soap+xml actieparameter, die aanwezig is op een SOAP 1.2-bericht, moet overeenkomen wsa:Action wanneer WS-Adressering 2004/08 of WS-Addressing 1.0 wordt gebruikt.

Wanneer WS-Adressering is uitgeschakeld en een binnenkomende aanvraag geen actieparameter bevat, wordt het bericht Action beschouwd als niet opgegeven.

WS-adressering

WCF implementeert 3 versies van WS-Addressing:

WS-Adressering 2004/08
W3C Web Services Adressering 1.0 Core (ADDR10-CORE) en SOAP Binding (ADDR10-SOAP)
WS-Adressering 1.0 - Metagegevens

Eindpuntverwijzingen

Alle versies van WS-Addressing die WCF implementeert, gebruiken eindpuntverwijzingen om eindpunten te beschrijven.

Eindpuntverwijzingen en WS-adresseringsversies

WCF implementeert een aantal infrastructuurprotocollen die gebruikmaken van WS-Addressing en met name het element en W3C.WsAddressing.EndpointReferenceType de EndpointReference klasse (bijvoorbeeld WS-ReliableMessaging, WS-SecureConversation en WS-Trust). WCF ondersteunt het gebruik van beide versies van WS-Addressing met andere infrastructuurprotocollen. WCF-eindpunten ondersteunen één versie van WS-Adressering per eindpunt.

Voor R3111 moet de naamruimte voor het EndpointReference element of type dat wordt gebruikt in berichten die worden uitgewisseld met een WCF-eindpunt overeenkomen met de versie van WS-Adressering die door dit eindpunt is geïmplementeerd.

Als een WCF-eindpunt bijvoorbeeld WS-ReliableMessaging implementeert, gebruikt de AcksTo header die door een dergelijk eindpunt wordt CreateSequenceResponse geretourneerd de WS-Adresseringsversie die door het EncodingBinding element voor dit eindpunt wordt opgegeven.

Eindpuntverwijzingen en metagegevens

Voor een aantal scenario's is het communiceren van metagegevens of een verwijzing naar metagegevens voor een bepaald eindpunt vereist.

B3121: WCF maakt gebruik van mechanismen die worden beschreven in de specificatie WS-MetadataExchange (MEX) sectie 6 voor het opnemen van metagegevens voor eindpuntverwijzingen op waarde of verwijzing.

Overweeg een scenario waarin een WCF-service verificatie vereist met behulp van een SAML-token (Security Assertions Markup Language) dat is uitgegeven door de tokenverlener op http://sts.fabrikam123.com. Het WCF-eindpunt beschrijft deze verificatievereiste met behulp van sp:IssuedToken een assertie met een geneste sp:Issuer assertie die verwijst naar de tokenuitgever. Clienttoepassingen die toegang hebben tot de sp:Issuer assertie, moeten weten hoe ze kunnen communiceren met het eindpunt van de tokenverlener. De client moet metagegevens van de tokenverlener weten. Met behulp van de eindpuntverwijzingsextensies voor metagegevens die zijn gedefinieerd in MEX, biedt WCF een verwijzing naar de metagegevens van de tokenverlener.

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

Berichtadresseringskoppen

Berichtkoppen

Voor beide WS-Adresseringsversies gebruikt WCF de volgende berichtkoppen zoals voorgeschreven door de specificaties , , , en wsa:RelatesTowsa:MessageID. wsa:Actionwsa:ReplyTowsa:To

B3211: Voor alle WS-Adresseringsversies wordt WCF gehonoreerd, maar produceert deze niet standaard, berichtkoppen van WS-Adressering wsa:FaultTo en wsa:From.

Toepassingen die communiceren met WCF-toepassingen kunnen deze berichtkoppen toevoegen en WCF verwerken ze dienovereenkomstig.

Referentieparameters en eigenschappen

WCF implementeert de verwerking van eindpuntreferentieparameters en referentie-eigenschappen in overeenstemming met de respectieve specificaties.

B3221: Wanneer deze is geconfigureerd voor het gebruik van WS-Addressing 2004/08, maken WCF-eindpunten geen onderscheid tussen verwerkingsreferentieeigenschappen en referentieparameters.

Berichtuitwisselingspatronen

De volgorde van berichten die betrokken zijn bij de aanroep van de webservicebewerking wordt het patroon voor het uitwisselen van berichten genoemd. WCF ondersteunt patronen voor het uitwisselen van berichten in één richting, aanvraag-antwoord en dubbelzijdig bericht. In deze sectie worden de WS-Adresseringsvereisten voor berichtverwerking verduidelijkt, afhankelijk van het patroon voor berichtuitwisseling dat wordt gebruikt.

In deze sectie verzendt de aanvrager het eerste bericht en ontvangt de beantwoorder het eerste bericht.

Eenrichtingsbericht

Wanneer een WCF-eindpunt is geconfigureerd ter ondersteuning van berichten met een gegeven Action om een eenrichtingspatroon te volgen, volgt het WCF-eindpunt de volgende gedragingen en vereisten. Tenzij anders is opgegeven, zijn gedrag en regels van toepassing op beide versies van WS-Addressing die worden ondersteund in WCF:

R3311: De aanvrager moet headers wsa:Actionbevatten wsa:Tovoor alle referentieparameters die zijn opgegeven door de eindpuntreferentie. Wanneer WS-Addressing 2004/08 wordt gebruikt en [referentie-eigenschappen] worden opgegeven door de eindpuntverwijzing, moeten de bijbehorende headers ook aan het bericht worden toegevoegd.
B3312: De aanvrager kan headers en headers bevattenMessageIDReplyToFaultTo. De ontvangerinfrastructuur negeert deze en wordt doorgegeven aan de toepassing.
R3313: Wanneer HTTP wordt gebruikt en er geen bericht wordt verzonden op het HTTP-antwoordbeen, moet de responder een HTTP-antwoord met een lege hoofdtekst en een HTTP 202-statuscode verzenden.

Wanneer het HTTP-transport wordt gebruikt en het bewerkingscontract een bericht in één richting declareert, kan het HTTP-antwoord nog steeds worden gebruikt voor het verzenden van infrastructuurberichten, bijvoorbeeld een betrouwbare berichtenfunctie kan een SequenceAcknowledgement bericht verzenden op een HTTP-antwoord.
B3314: De WCF-responder verzendt geen foutbericht als reactie op een eenrichtingsbericht.

Aanvraag-antwoord

Wanneer een WCF-eindpunt is geconfigureerd voor een bericht met een gegeven Action om het aanvraag-antwoordpatroon te volgen, volgt het WCF-eindpunt het gedrag en de onderstaande vereisten. Tenzij anders is opgegeven, gelden gedrag en regels voor beide versies van WS-Adressering die wordt ondersteund in WCF:

R3321: De aanvrager moet in de aanvraag wsa:To, wsa:Actionen wsa:MessageIDheaders opnemen voor alle referentieparameters of referentie-eigenschappen (of beide) die zijn opgegeven door de eindpuntreferentie.
R3322: Wanneer WS-Addressing 2004/08 wordt gebruikt, ReplyTo moet ook worden opgenomen in de aanvraag.
R3323: Wanneer WS-Addressing 1.0 wordt gebruikt en ReplyTo niet aanwezig is in de aanvraag, wordt een standaardeindpuntverwijzing met de eigenschap [adres] gebruikt die gelijk is aan http://www.w3.org/2005/08/addressing/anonymous .
R3324: De aanvrager moet kopteksten wsa:Actionin het antwoordbericht opnemenwsa:To, en wsa:RelatesTo kopteksten voor alle referentieparameters of verwijzingseigenschappen (of beide) die zijn opgegeven door de ReplyTo eindpuntreferentie in de aanvraag.

Fouten oplossen in webservices

R3411: WCF produceert de volgende fouten die zijn gedefinieerd door WS-Addressing 2004/08.

Code	Oorzaak
`wsa:DestinationUnreachable`	Het bericht is aangekomen met een `ReplyTo` ander antwoordadres dan het antwoordadres dat voor dit kanaal is ingesteld. Er is geen eindpunt dat luistert naar het adres dat is opgegeven in de kop Aan.
`wsa:ActionNotSupported`	de infrastructuurkanalen of dispatcher die aan het eindpunt zijn gekoppeld, herkennen de actie die is opgegeven in de `Action` header niet.

R3412: WCF produceert de volgende fouten die zijn gedefinieerd door WS-Addressing 1.0.

Code	Oorzaak
`wsa10:InvalidAddressingHeader`	Dupliceren `wsa:To`, `wsa:ReplyTo`of `wsa:Fromwsa:MessageID`. Dupliceren `wsa:RelatesTo` met hetzelfde `RelationshipType`.
`wsa10:MessageAddressingHeaderRequired`	De vereiste adresseringsheader ontbreekt.
`wsa10:DestinationUnreachable`	Het bericht is aangekomen met een `ReplyTo` ander antwoordadres dan het antwoordadres dat voor dit kanaal is ingesteld. Er is geen eindpunt dat luistert naar het adres dat is opgegeven in de kop Aan.
`wsa10:ActionNotSupported`	Een actie die is opgegeven in de `Action` header, wordt niet herkend door de infrastructuurkanalen of dispatcher die aan het eindpunt is gekoppeld.
`wsa10:EndpointUnavailable`	Het RM-kanaal verzendt deze fout terug, wat aangeeft dat het eindpunt de volgorde niet verwerkt op basis van het onderzoek van de adresseringsheaders van het `CreateSequence` bericht.

Code in de voorgaande tabellen wordt toegewezen aan FaultCode SOAP 1.1 en SubCode (met Code=Sender) in SOAP 1.2.

WSDL 1.1 Bindings- en WS-Policy-asserties

Het gebruik van WS-adressering aangeven

WCF gebruikt beleidsverklaringen om eindpuntondersteuning voor een bepaalde WS-Adresseringsversie aan te geven.

De volgende beleidsverklaring heeft eindpuntbeleidonderwerp [WS-PA] en geeft aan dat berichten die zijn verzonden en ontvangen van het eindpunt WS-Adressering 2004/08 moeten gebruiken.

<wsap:UsingAddressing />

Met deze beleidsverklaring wordt de specificatie WS-Addressing 2004/08 vergroot.

De volgende beleidsverklaring geeft aan dat berichten die worden verzonden/ontvangen WS-Adressering 1.0 moeten gebruiken.

<wsam:Addressing/>

De volgende beleidsverklaring heeft een onderwerp voor eindpuntbeleid [WS-PA] en geeft aan dat berichten die zijn verzonden en ontvangen van het eindpunt WS-Addressing 2004/08 moeten gebruiken.

<wsaw10:UsingAddressing />

Het wsaw10:UsingAddressing element wordt geleend van [WS-Addressing-WSDL] en wordt gebruikt in de context van WS-Policy in overeenstemming met die specificatie, sectie 3.1.2.

Het gebruik van Adressering wijzigt de semantiek van WSDL 1.1, SOAP 1.1 en SOAP 1.2 HTTP-bindingen niet. Als bijvoorbeeld wordt verwacht dat een antwoord wordt verzonden naar een eindpunt dat gebruikmaakt van adressering en WSDL SOAP 1.x HTTP-binding, moet het antwoord worden verzonden met behulp van het HTTP-antwoord.

Voor antwoorden die via het HTTP-antwoord worden verzonden, is de WS-AM-assertie:

<wsam:AnonymousResponses/>

De volledige beleidsverklaring kan er als volgt uitzien:

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

Er zijn echter berichtuitwisselingspatronen die baat hebben bij het hebben van twee onafhankelijke HTTP-verbindingen tussen de aanvrager en de responder, bijvoorbeeld ongevraagde eenzijdige berichten die door de responder worden verzonden.

WCF biedt een functie waarmee twee onderliggende transportkanalen een samengesteld duplex-kanaal kunnen vormen, waarbij één kanaal wordt gebruikt voor invoerberichten en de andere wordt gebruikt voor uitvoerberichten. In het geval van het HTTP-transport biedt Composite Duplex twee omgekeerde HTTP-verbindingen. De aanvrager gebruikt één verbinding om berichten naar de responder te verzenden en de responder gebruikt de andere om berichten terug te sturen naar de aanvrager.

Voor antwoorden die via afzonderlijke HTTP-aanvragen worden verzonden, is de ws-am-assertie

<wsam:NonAnonymousResponses/>

De volledige beleidsverklaring kan er als volgt uitzien:

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

Voor het gebruik van de volgende assertie met eindpuntbeleidonderwerp [WS-PA] op eindpunten die WSDL 1.1 SOAP 1.x HTTP-bindingen gebruiken, moeten twee afzonderlijke HTTP-verbindingen worden gebruikt voor berichten die van de aanvrager naar de aanvrager stromen en reageren op de aanvrager.

<cdp:CompositeDuplex/>

De vorige instructie leidt tot de volgende vereisten voor de wsa:ReplyTo header voor aanvraagberichten:

R3514: Aanvragen voor berichten die naar een eindpunt worden verzonden, moeten een ReplyTo header hebben met de [address] eigenschap die niet gelijk is aan http://www.w3.org/2005/08/addressing/anonymous als voor het eindpunt een WSDL 1.1 SOAP 1.x HTTP-binding wordt gebruikt en een beleids alternatief is gekoppeld aan een wsap10:UsingAddressing of wsap:UsingAddressing assertie cdp:CompositeDuplex .
R3515: Aanvragen voor berichten die naar een eindpunt worden verzonden, moeten een ReplyTo koptekst hebben die gelijk is aan http://www.w3.org/2005/08/addressing/anonymous, [address] of helemaal geen header hebbenReplyTo, als het eindpunt een WSDL 1.1 SOAP 1.x HTTP-binding gebruikt en een beleids alternatief heeft met wsap10:UsingAddressing assertie en geen cdp:CompositeDuplex bevestiging gekoppeld.
R3516: Aanvragen voor berichten die naar een eindpunt worden verzonden, moeten een header hebben met een ReplyTo[address] eigenschap die gelijk is aan http://www.w3.org/2005/08/addressing/anonymous als het eindpunt een WSDL 1.1 SOAP 1.x HTTP-binding gebruikt en een beleids alternatief heeft met wsap:UsingAddressing assertie en geen cdp:CompositeDuplex bevestiging gekoppeld.

De WS-adresseringsspecificatie probeert vergelijkbare protocolbindingen te beschrijven door een element <wsaw:Anonymous/> te introduceren met drie tekstwaarden (vereist, optioneel en verboden) om vereisten voor de wsa:ReplyTo koptekst aan te geven (sectie 3.2). Helaas is deze elementdefinitie niet bijzonder bruikbaar als een verklaring in de context van WS-Policy, omdat hiervoor domeinspecifieke extensies nodig zijn om het snijpunt van alternatieven te ondersteunen die een dergelijk element als een assertie gebruiken. Deze elementdefinitie geeft ook de waarde van de ReplyTo header aan in plaats van het eindpuntgedrag op de draad, waardoor deze specifiek is voor HTTP-transport.

Actiedefinitie

WS-Addressing 2004/08 definieert een wsa:Action kenmerk voor de wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementen. WS-Addressing 1.0 WSDL Binding (WS-ADDR10-WSDL) definieert een soortgelijk kenmerk, wsaw10:Action.

Het enige verschil tussen de twee is de standaardactiepatroonsemantiek die wordt beschreven in sectie 3.3.2 van WS-ADDR en sectie 4.4.4 van respectievelijk WS-ADDR10-WSDL.

Het is redelijk om twee eindpunten te hebben die hetzelfde portType (of contract, in WCF-terminologie) delen, maar verschillende versies van WS-Addressing gebruiken. Maar gezien de definitie van de actie door de portType eindpunten die de portTypeactie implementeren, is het onmogelijk om beide standaardactiepatronen te ondersteunen.

Om deze controverse op te lossen, ondersteunt WCF één versie van het Action kenmerk.

B3521: WCF gebruikt het wsaw10:Action kenmerk op wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementen zoals gedefinieerd in WS-ADDR10-WSDL om de Action URI voor de bijbehorende berichten te bepalen, ongeacht de WS-Adresseringsversie die door het eindpunt wordt gebruikt.

Eindpuntreferentie gebruiken in WSDL-poort

WS-ADDR10-WSDL-sectie 4.1 breidt het wsdl:port element uit om het <wsa10:EndpointReference…/> onderliggende element op te nemen om het eindpunt in WS-Addressing-termen te beschrijven. WCF breidt dit hulpprogramma uit op WS-Addressing 2004/08, zodat <wsa:EndpointReference…/> deze kan worden weergegeven als een onderliggend element van wsdl:port.

R3531: Als een eindpunt een alternatief voor een gekoppeld beleid heeft met een <wsaw10:UsingAddressing/> beleidsverklaring, kan het bijbehorende element een onderliggend wsdl:port element <wsa10:EndpointReference …/>bevatten.
R3532: Als een wsdl:port element een onderliggend element <wsa10:EndpointReference …/>bevat, moet de wsa10:EndpointReference/wsa10:Address waarde van het onderliggende element overeenkomen met de waarde van het kenmerk van het @address onderliggende wsdl:port/wsdl:location element.
R3533: Als een eindpunt een alternatief voor een gekoppeld beleid heeft met <wsap:UsingAddressing/> beleidsverklaring, kan het bijbehorende element een onderliggend wsdl:port element <wsa:EndpointReference …/>bevatten.
R3534: Als een element wsdl:port een onderliggend element <wsa:EndpointReference …/>bevat, moet de wsa:EndpointReference/wsa:Address waarde van het onderliggende element overeenkomen met de waarde van het kenmerk van het @address onderliggende wsdl:port/wsdl:location element.

Samenstelling met WS-Security

Volgens beveiligingsoverwegingen in WS-ADDR en WS-ADDR10 worden alle berichtkoppen voor adressering aanbevolen om samen met de hoofdtekst van het bericht te worden ondertekend om ze aan elkaar te binden.

Wanneer WS-Security wordt gebruikt voor beveiliging van berichtintegriteit, moeten berichtkoppen en kopteksten die het gevolg zijn van verwijzingsparameters of -eigenschappen (of beide) worden ondertekend samen met de hoofdtekst van het bericht.

Voorbeelden

Eenrichtingsbericht

In dit scenario verzendt de afzender een eenrichtingsbericht naar de ontvanger. SOAP 1.2, HTTP 1.1 en W3C WS-Addressing 1.0 worden gebruikt.

De structuur van het aanvraagbericht: de berichtkoppen bevatten wsa10:To en wsa10:Action elementen. De berichttekst bevat een specifiek <app:Ping> element uit de naamruimte van de toepassing.

HTTP-headers: het doel in POST komt overeen met de URI in het wsa10:To element.

De header Content-Type heeft de waarde van application/soap+xml zoals vereist voor SOAP 1.2. Parameters charset en action zijn opgenomen. De action parameter van de header Content-Type komt overeen met de waarde van de wsa10:Action berichtkop.

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>

De ontvanger reageert met een leeg HTTP-antwoord en status 202. Een voorbeeld van het HTTP-antwoord:

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

Soap Message Transmission Optimization-mechanisme

In deze sectie worden de WCF-implementatiedetails voor de HTTP SOAP MTOM beschreven. MTOM-technologie is het SOAP-berichtcoderingsmechanisme van dezelfde klasse als traditionele tekst-/XML-codering of BINAIRE WCF-codering. MTOM bevat het volgende:

Een XML-coderings- en verpakkingsmechanisme dat wordt beschreven door [XOP] waarmee XML-informatieitems met met base64 gecodeerde binaire gegevens worden geoptimaliseerd in afzonderlijke binaire onderdelen.
Een MIME-inkapseling van het XOP-pakket waarmee de XML-infoset en elk binair deel van het XOP-pakket in een afzonderlijk MIME-onderdeel worden geserialiseerd.
Een MIME XOP-codering toegepast op SOAP 1.x Envelope.
Een HTTP-transportbinding.

Het is mogelijk om MTOM te gebruiken met niet-HTTP-transporten met WCF. In dit onderwerp richten we ons echter op HTTP.

De MTOM-indeling maakt gebruik van een grote set specificaties voor MTOM zelf, XOP en MIME. Modulariteit van deze specificatieset maakt het enigszins moeilijk om exacte vereisten voor de indeling en verwerking van semantiek te reconstrueren. In deze sectie worden de indelings- en verwerkingsvereisten voor MTOM HTTP-binding beschreven.

MTOM-berichtcodering

MTOM-berichten genereren

In de sectie [XOP] sectie 3.1 wordt het proces van codering van XML beschreven met elementinformatie-items die base64-waarden bevatten in een abstract gedefinieerd XOP-pakket.

In de volgende reeks stappen wordt het MTOM-specifieke coderingsproces beschreven:

Zorg ervoor dat de SOAP-envelop die moet worden gecodeerd geen elementinformatie-item bevat met een [namespace name] van http://www.w3.org/2004/08/xop/include en een [local name] van Include.
Maak een leeg MIME-pakket.
Identificeer in de oorspronkelijke XML-infoset de elementen die moeten worden geoptimaliseerd. Voor de items die moeten worden geoptimaliseerd, moeten de tekens waaruit het [children] elementinformatie-item bestaat, de canonieke vorm hebben van xs:base64Binary (zie XSD-2, 3.2.16 base64Binary) en mogen geen spatietekens bevatten die voorafgaan aan, inline met of na de inhoud van de niet-witruimte.
Maak een XOP SOAP-envelop die een kopie is van de oorspronkelijke SOAP-envelop, maar door de onderliggende elementen van elk elementinformatie-item dat in de vorige stap is geïdentificeerd, vervangen door een xop:Include elementinformatie-item dat als volgt is samengesteld:
1. Transformeer de vervangen tekens in binaire gegevens door ze te verwerken als base64-gecodeerde gegevens.
2. Genereer een unieke Content-ID-headerwaarde die voldoet aan de vereisten R3133 en R3134.
3. Genereer een MIME-header voor Content-Transfer-Encoding met de binaire waarde.
4. Als het elementinformatie-item dat wordt geoptimaliseerd (de [bovenliggende] van het zojuist ingevoegde xop:Include elementinformatie-item) een xmime:contentType kenmerkinformatie-item heeft, genereert u een Content-Type MIME-header met de waarde van het xmime:contentType kenmerk.
5. Genereer een nieuw binair MIME-onderdeel met inhoud die is gevormd door binaire gegevens die zijn gedecodeerd van de vervangen tekens die zijn verwerkt als base64, Content-ID-header uit 4b, Content-Transfer-Encoding header uit 4c, Content-Type header als deze is gegenereerd in stap 4d.
6. Voeg een href kenmerk toe aan het xop:Include element met de waarde cid: URI die is afgeleid van de content-id-headerwaarde die is gegenereerd in stap 4b. Verwijder de ingesloten tekens '<' en '>', url-escape de resterende tekenreeks en voeg het voorvoegsel cid:toe. De volgende minimale tekenset moet worden ontsnapt door RFC1738 en RFC2396. Andere tekens kunnen worden ontsnapt.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Maak een hoofd-MIME-onderdeel met de XOP SOAP-envelop uit stap 4.
Schrijf de HTTP-headers, inclusief de HTTP-inhoudstype-header.
Schrijf het MIME-pakket.

MTOM-berichten verwerken

Verwerking van een MTOM-bericht is het exacte omgekeerde van het proces dat wordt beschreven in de voorgaande sectie 'MTOM-berichten genereren':

Zorg ervoor dat het MIME-hoofdonderdeel het inhoudstype application/xop+xmlheeft.
Maak een SOAP-envelop door het mime-hoofdgedeelte van het pakket te parseren als een XML-document. Tekencodering wordt bepaald door de charset parameter van het inhoudstype van het mime-hoofdonderdeel.
Voor elk elementinformatie-item in de samengestelde SOAP-envelop, die, als enige lid van de eigenschap [onderliggende], een xop:Include elementinformatie-item heeft:
1. Verwijder het cid: voorvoegsel en unescape alle URI-escapereeksen (RFC 2396) in de waarde van het @href kenmerk van het xop:Include element. Plaats de resultaattekenreeks in '<', '>'.
2. Zoek het MIME-onderdeel met de content-id-headerwaarde die overeenkomt met de tekenreeks die is afgeleid in stap 3a.
3. Vervang het xop:Include elementinformatie-item dat wordt weergegeven in de children eigenschap van elk item door de tekeninformatie-items die de canonieke base64-codering vertegenwoordigen (zie XSD-2, 3.2.16 base64Binary) van de entiteitstekst van het MIME-onderdeel dat is geïdentificeerd in stap 3b (vervang het xop:Include elementinformatie-item effectief door de gegevens die zijn gereconstrueerd uit het pakketonderdeel).

HTTP-inhoudstypeheader

Hier volgt een lijst met WCF-verduidelijkingen voor de indeling van de HTTP Content-Type-header van een SOAP 1.x MTOM-gecodeerd bericht afgeleid van vereisten die zijn vermeld in de MTOM-specificatie zelf en zijn afgeleid van MTOM en RFC 2387.

R4131: Een HTTP-inhoudstype-header moet de waarde van meerdere onderdelen/gerelateerde (hoofdlettergevoelig) en de bijbehorende parameters hebben. Parameternamen zijn niet hoofdlettergevoelig. Parametervolgorde is niet significant.
Het volledige Backus-Naur-formulier (BNF) van de header Content-Type voor MIME-berichten wordt vermeld in RFC 2045, sectie 5.1.
R4132: Een HTTP-inhoudstype-header moet een typeparameter hebben met de waarde application/xop+xml tussen dubbele aanhalingstekens.

Hoewel de vereiste voor het gebruik van dubbele aanhalingstekens niet expliciet is in RFC 2387, merkt de tekst op dat alle parameters voor meerdere onderdelen/gerelateerde mediatypen waarschijnlijk gereserveerde tekens bevatten, zoals '@' of '/', en daarom dubbele aanhalingstekens nodig hebben.

R4133: Een HTTP-inhoudstype-header moet een beginparameter hebben met de waarde van de Content-ID-header van het MIME-onderdeel dat de SOAP 1.x-envelop bevat, tussen dubbele aanhalingstekens. Als de beginparameter wordt weggelaten, moet het eerste MIME-deel de SOAP 1.x-envelop bevatten.
R4134: Een HTTP-inhoudstype-header voor een MET SOAP 1.1 MTOM gecodeerd bericht moet de parameter start-info bevatten met de waarde van tekst/xml, tussen dubbele aanhalingstekens.
R4135: Een HTTP-inhoudstype-header voor een SOAP 1.2 MTOM-gecodeerd bericht moet de parameter start-info bevatten met de waarde van application/soap+xml, tussen dubbele aanhalingstekens.

R4136: HTTP Content-Type header voor een SOAP 1.x MTOM-gecodeerd bericht moet de grensparameter hebben met de waarde (tussen dubbele aanhalingstekens) die overeenkomt met de MIME-grens BNF die is gedefinieerd in RFC 2046, sectie 5.1.1

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

Voorbeelden:

JUISTE

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"

JUISTE

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

ONJUISTE

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

De SOAP 1.x-envelop wordt ingekapseld als hoofdonderdeel van het XOP MIME-pakket en wordt vaak het infoset onderdeel genoemd.

R4141: De SOAP 1.x-envelop moet worden ingekapseld als hoofdonderdeel van het XOP MIME-pakket, het infoset onderdeel genoemd en waarnaar wordt verwezen vanuit het HTTP-inhoudstype.
R4142: Het SOAP-onderdeel Infoset moet de volgende MIME-headers bevatten: Content-ID, Content-Transfer-Encodingen Content-Type.

De indeling van de Content-ID-header wordt gedefinieerd door RFC 2045 als

"Content-ID" ":" msg-id

waarbij msg-id is gedefinieerd in RFC 2822 (dat RFC 822 vervangt, waarnaar wordt verwezen in RFC 2045) als:

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

en is effectief een e-mailadres dat binnen "<" en ">" is. Het [CFWS] voor- en achtervoegsel zijn toegevoegd in RFC 2822 voor opmerkingen en mogen niet worden gebruikt om de interoperabiliteit te behouden.

R4143: De waarde van de Content-ID-header voor het Infoset MIME-onderdeel moet de productie van RFC 2822 volgen msg-id met het [CFWS] voor- en achtervoegsel.

Een aantal MIME-implementaties versoepelt de vereisten voor de waarde die is opgenomen in '<' en '>' als een e-mailadres en wordt gebruikt absoluteURI ingesloten in '<' , '>' naast het e-mailadres. Deze versie van WCF maakt gebruik van waarden van de CONTENT-ID MIME-header van het formulier:

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

R4144: MTOM-processors moeten content-id-headerwaarden accepteren die overeenkomen met de volgende ontspannen msg-id.

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

MIME (RFC 2045) biedt de header Content-Transfer-Encoding om de codering van de inhoud van het MIME-onderdeel te communiceren. De standaardinstelling die is gedefinieerd voor Content-Transfer-Encoding is 7-bits, wat niet geschikt is voor de meeste SOAP-berichten, dus de header Content-Transfer-Encoding is nodig voor een grotere interoperabiliteit:

R4145: Het onderdeel SOAP Infoset moet de header Content-Transfer-Encoding bevatten.
R4146: Als de SOAP Envelope-tekencodering UTF-8 is, moet de waarde van de header Content-Transfer-Encoding 8-bits zijn.
R4147: Als de soap-enveloptekencodering UTF-16 is, moet de waarde van de header Content-Transfer-Encoding binair zijn.
Volgens [XOP] sectie 5,
R4148: SOAP1.1 Infoset-onderdeel moet de header Content-Type bevatten met mediatype application/xop+xml en parameters type="text/xml" en charset
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: Het onderdeel SOAP 1.2 Infoset moet de header Content-Type bevatten met het mediatype application/xop+xml en parametertype="application/soap+xml" en charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
Hoewel XOP de charset parameter definieert om application/xop+xml optioneel te zijn, is deze nodig voor interoperabiliteit die vergelijkbaar is met de vereiste BP 1.1 voor de charset parameter voor het text/xml mediatype.
R41410: De type en charset parameters moeten aanwezig zijn op de header Content-Type van het deel SOAP 1.x Infoset.

WCF-eindpuntondersteuning voor MTOM

Het doel van MTOM is het coderen van een SOAP-bericht om base64-gecodeerde gegevens te optimaliseren. Hier volgt een lijst met beperkingen:

R4151: Elk elementinformatie-item dat base64-gecodeerde gegevens bevat, kan worden geoptimaliseerd.
B4152: WCF optimaliseert elementinformatie-items die base64-gecodeerde gegevens bevatten en meer dan 1024 bytes lang zijn.

Een WCF-eindpunt dat is geconfigureerd voor het gebruik van MTOM, verzendt altijd MTOM-gecodeerde berichten. Zelfs als er geen onderdelen voldoen aan de vereiste criteria, wordt het bericht nog steeds MTOM-gecodeerd (geserialiseerd als een MIME-pakket met één MIME-onderdeel met de SOAP-envelop).

WS-Policy Assertion for MTOM

WCF gebruikt de volgende beleidsverklaring om het MTOM-gebruik per eindpunt aan te geven:

<wsoma:OptimizedMimeSerialization />

R4211: De voorgaande beleidsverklaring heeft een eindpuntbeleidsonderwerp en geeft aan dat alle berichten die vanaf het eindpunt worden verzonden en ontvangen, moeten worden geoptimaliseerd met behulp van MTOM.
B4212: Wanneer deze is geconfigureerd voor het gebruik van MTOM-optimalisatie, voegt een WCF-eindpunt een MTOM-beleidsverklaring toe aan het beleid dat is gekoppeld aan het bijbehorende wsdl:bindingbeleid.

Samenstelling met WS-Security

MTOM is een coderingsmechanisme dat vergelijkbaar is met text/xml en WCF Binaire XML. MTOM biedt natuurlijke samenstelling met WS-Security en andere WS-* protocollen: een bericht beveiligd met WS-Security kan worden geoptimaliseerd met behulp van MTOM.

Voorbeelden

WCF SOAP 1.1-bericht gecodeerd met 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-bericht gecodeerd met MTOM

In dit voorbeeld wordt een bericht gecodeerd met MTOM en SOAP 1.2 die is beveiligd met WS-Security. De binaire onderdelen die voor codering zijn geïdentificeerd, zijn de inhoud van de BinarySecurityToken, CipherValue van de EncryptedData corresponderende met de versleutelde handtekening en de versleutelde hoofdtekst. Houd er rekening mee dat de id EncryptedKey niet is geïdentificeerd voor optimalisatie door WCF, omdat de CipherValue lengte kleiner is dan 1024 bytes.

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

Delen via

Berichtenprotocollen

SOAP 1.1 en SOAP 1.2

Envelop- en verwerkingsmodel

Verplichte headerverwerking

SOAP-fouten

HTTP-binding

SOAP 1.1 HTTP-binding

SOAP 1.2 HTTP-binding

WS-adressering

Eindpuntverwijzingen

Eindpuntverwijzingen en WS-adresseringsversies

Eindpuntverwijzingen en metagegevens

Berichtadresseringskoppen

Berichtkoppen

Referentieparameters en eigenschappen

Berichtuitwisselingspatronen

Eenrichtingsbericht

Aanvraag-antwoord

Fouten oplossen in webservices

WSDL 1.1 Bindings- en WS-Policy-asserties

Het gebruik van WS-adressering aangeven

Actiedefinitie

Eindpuntreferentie gebruiken in WSDL-poort

Samenstelling met WS-Security

Voorbeelden

Eenrichtingsbericht

Soap Message Transmission Optimization-mechanisme

MTOM-berichtcodering

MTOM-berichten genereren

MTOM-berichten verwerken

HTTP-inhoudstypeheader

Infoset MIME-onderdeel

WCF-eindpuntondersteuning voor MTOM

WS-Policy Assertion for MTOM

Samenstelling met WS-Security

Voorbeelden

WCF SOAP 1.1-bericht gecodeerd met MTOM

WCF Secure SOAP 1.2-bericht gecodeerd met MTOM

Aanvullende resources