Protocolli di messaggistica

Lo stack di canali di Windows Communication Foundation (WCF) usa canali di codifica e trasporto per trasformare la rappresentazione interna dei messaggi nel formato di trasmissione e inviarlo usando un trasporto specifico. Il trasporto più comune usato per l'interoperabilità dei servizi Web è HTTP e le codifiche più comuni usate dai servizi Web sono SOAP 1.1, SOAP 1.2 e MTOM (Message Transmission Optimization Mechanism).

In questo argomento vengono illustrati i dettagli dell'implementazione WCF per i protocolli seguenti usati da HttpTransportBindingElement.

Specifica/documento:

In questo argomento vengono illustrati i dettagli dell'implementazione WCF per i protocolli seguenti che TextMessageEncodingBindingElement e MtomMessageEncodingBindingElement usano .

Specifica/Documento:

In questo argomento vengono illustrati i dettagli dell'implementazione WCF per i protocolli seguenti che MtomMessageEncodingBindingElement usano .

Specifica/documento:

In questo argomento vengono usati i seguenti namespace XML e prefissi associati:

Prefisso	URI (Uniform Resource Identifier) del namespace
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 e SOAP 1.2

Involucro e modello di elaborazione

WCF implementa l'elaborazione dell'envelope SOAP 1.1 per il Basic Profile 1.1 (BP11) e il Basic Profile 1.0 (SSBP10). L'elaborazione della busta SOAP 1.2 viene implementata dopo SOAP12-Part1.

Questa sezione illustra alcune scelte di implementazione prese da WCF per quanto riguarda BP11 e SOAP12-Part1.

Elaborazione intestazione obbligatoria

WCF segue le regole per l'elaborazione delle intestazioni contrassegnate mustUnderstand nelle specifiche SOAP 1.1 e SOAP 1.2, con le varianti seguenti.

Un messaggio che entra nello stack di canali WCF viene elaborato da singoli canali configurati da elementi di associazione associati, ad esempio codifica messaggi di testo, sicurezza, messaggistica affidabile e transazioni. Ogni canale riconosce le intestazioni dallo spazio dei nomi associato e le contrassegna come comprese. Una volta che un messaggio entra nel dispatcher, il formattatore dell'operazione legge le intestazioni previste dal contratto di messaggio/operazione corrispondente e le contrassegna come comprese. Il dispatcher verifica quindi se le intestazioni rimanenti non sono comprese ma contrassegnate come mustUnderstand e genera un'eccezione. I messaggi che contengono mustUnderstand intestazioni indirizzate al destinatario non vengono elaborati dal codice dell'applicazione del destinatario.

Tale elaborazione a più livelli consente la separazione tra i livelli dell'infrastruttura e i livelli dell'applicazione del nodo SOAP:

B1111: le intestazioni non riconosciute vengono rilevate dopo l'elaborazione del messaggio dallo stack di canali dell'infrastruttura WCF, ma prima dell'elaborazione da parte dell'applicazione

Il valore dell'intestazione mustUnderstand è diverso tra SOAP 1.1 e SOAP 1.2. Il profilo di base 1.1 richiede che il mustUnderstand valore sia 0 o 1 per i messaggi SOAP 1.1. SOAP 1.2 consente 0, 1, falsee true come valori, ma consiglia di emettere una rappresentazione canonica dei xs:boolean valori (false, true).
B1112: WCF genera i valori 0 e 1 sia per entrambe le versioni SOAP 1.1 e SOAP 1.2 della busta SOAP. WCF accetta l'intero spazio dei valori di xs:boolean per l'intestazione mustUnderstand (0, 1, false, true)

Errori SOAP

Di seguito è riportato un elenco di implementazioni di errore SOAP specifiche di WCF.

B2121: WCF restituisce i codici di errore SOAP 1.1 seguenti: s11:mustUnderstand, s11:Cliente s11:Server.
B2122: WCF restituisce i codici di errore SOAP 1.2 seguenti: s12:MustUnderstand, s12:Sendere s12:Receiver.

Associazione HTTP

SOAP 1.1 Binding HTTP

WCF implementa l'associazione HTTP SOAP1.1 seguendo la specifica Basic Profile 1.1 sezione 3.4 con i chiarimenti seguenti:

B2211: il servizio WCF non implementa il reindirizzamento delle richieste HTTP POST.
B2212: i client WCF supportano i cookie HTTP in base alla versione 3.4.8.

Collegamento HTTP SOAP 1.2

WCF implementa l'associazione HTTP SOAP 1.2 come descritto nella specifica SOAP 1.2-part 2 (SOAP12Part2) con i chiarimenti seguenti.

SOAP 1.2 ha introdotto un parametro di azione facoltativo per il application/soap+xml tipo di supporto. Questo parametro è utile per ottimizzare l'invio dei messaggi senza richiedere l'analisi del corpo del messaggio SOAP quando non viene utilizzato WS-Addressing.

R2221: il application/soap+xml parametro di azione, se presente in una richiesta SOAP 1.2, deve corrispondere all'attributo soapAction sull'elemento wsoap12:operation all'interno dell'associazione WSDL corrispondente.
R2222: il application/soap+xml parametro di azione, se presente in un messaggio SOAP 1.2, deve corrispondere wsa:Action quando vengono usati WS-Addressing 2004/08 o WS-Addressing 1.0.

Quando WS-Addressing è disabilitato e una richiesta in ingresso non contiene un parametro di azione, il messaggio Action viene considerato non specificato.

WS-Addressing

WCF implementa 3 versioni di WS-Addressing:

WS-Addressing 2004/08
W3C Web Services Addressing 1.0 Core (ADDR10-CORE) e SOAP Binding (ADDR10-SOAP)
WS-Addressing 1.0 - Metadati

Riferimenti agli endpoint

Tutte le versioni di WS-Addressing implementate da WCF usano riferimenti endpoint per descrivere gli endpoint.

Riferimenti agli endpoint e versioni di WS-Addressing

WCF implementa diversi protocolli di infrastruttura che usano WS-Addressing e in particolare l'elemento EndpointReference e la classe W3C.WsAddressing.EndpointReferenceType (ad esempio WS-ReliableMessaging, WS-SecureConversation e WS-Trust). WCF supporta l'uso di una delle due versioni di WS-Addressing con altri protocolli di infrastruttura. Gli endpoint WCF supportano una versione di WS-Addressing per endpoint.

Per R3111, lo spazio dei nomi per l'elemento EndpointReference o il tipo utilizzato nei messaggi scambiati con un endpoint WCF deve corrispondere alla versione di WS-Addressing implementata da questo endpoint.

Ad esempio, se un endpoint WCF implementa WS-ReliableMessaging, l'intestazione AcksTo restituita da tale endpoint all'interno CreateSequenceResponse usa la versione WS-Addressing specificata dall'elemento EncodingBinding per questo endpoint.

Riferimenti agli endpoint e metadati

Alcuni scenari richiedono la comunicazione dei metadati o di un riferimento ai metadati per un determinato endpoint.

B3121: WCF impiega meccanismi descritti nella specifica WS-MetadataExchange (MEX), Sezione 6, per includere i metadati relativi ai riferimenti dell'endpoint, sia per valore che per riferimento.

Si consideri uno scenario in cui un servizio WCF richiede l'autenticazione usando un token SAML (Security Assertions Markup Language) rilasciato dall'emittente del token all'indirizzo http://sts.fabrikam123.com. L'endpoint WCF descrive questo requisito di autenticazione utilizzando l'asserzione sp:IssuedToken con un'asserzione sp:Issuer annidata che fa riferimento all'emittente del token. Le applicazioni client che accedono all'asserzione sp:Issuer devono sapere come comunicare con l'endpoint dell'autorità di certificazione del token. Il client deve conoscere i metadati relativi all'autorità emittente del token. Usando le estensioni dei metadati di riferimento dell'endpoint definite in MEX, WCF fornisce un riferimento ai metadati dell'autorità di certificazione del token.

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

Intestazioni per l'indirizzamento dei messaggi

Intestazioni dei messaggi

Per entrambe le versioni di WS-Addressing, WCF usa le intestazioni di messaggio seguenti come previsto dalle specifiche wsa:To, wsa:ReplyTo, wsa:Actionwsa:MessageID, e wsa:RelatesTo.

B3211: Per tutte le versioni di WS-Addressing, WCF rispetta, ma non genera di default le intestazioni di messaggio WS-Addressing wsa:FaultTo e wsa:From.

Le applicazioni che interagiscono con le applicazioni WCF possono aggiungere queste intestazioni di messaggio e WCF le elaborano di conseguenza.

Parametri e proprietà di riferimento

WCF implementa l'elaborazione dei parametri di riferimento dell'endpoint e delle proprietà di riferimento in base alle rispettive specifiche.

B3221: se configurato per l'uso di WS-Addressing 2004/08, gli endpoint WCF non distinguono tra le proprietà di riferimento di elaborazione e i parametri di riferimento.

Modelli di Scambio messaggi

La sequenza di messaggi coinvolti nella chiamata all'operazione del servizio Web viene definita modello di scambio di messaggi. WCF supporta modelli di scambio di messaggi unidirezionale, request-reply e duplex. Questa sezione chiarisce i requisiti di WS-Addressing per l'elaborazione dei messaggi a seconda del modello di scambio di messaggi in essere utilizzato.

In questa sezione, il richiedente invia il primo messaggio e il risponditore riceve il primo messaggio.

messaggio One-Way

Quando un endpoint WCF è configurato per supportare i messaggi con un determinato Action per seguire un modello unidirezionale, l'endpoint WCF segue i comportamenti e i requisiti seguenti. Se non diversamente specificato, i comportamenti e le regole si applicano per entrambe le versioni di WS-Addressing supportate in WCF:

R3311: Il richiedente deve includere wsa:To, wsa:Action e le intestazioni per tutti i parametri di riferimento specificati dal riferimento all'endpoint. Quando WS-Addressing 2004/08 è utilizzato e le [proprietà di riferimento] vengono specificate dal riferimento dell'endpoint, le intestazioni corrispondenti devono essere aggiunte anche al messaggio.
B3312: il richiedente può includere MessageIDintestazioni , ReplyToe FaultTo . L'infrastruttura del ricevitore li ignorerà e verranno passati all'applicazione.
R3313: quando viene usato HTTP e non viene inviato alcun messaggio nella fase di risposta HTTP, il risponditore deve inviare una risposta HTTP con un corpo vuoto e un codice di stato HTTP 202.

Quando il trasporto HTTP è in uso e il contratto dell'operazione dichiara un messaggio unidirezionale, la risposta HTTP può comunque essere usata per l'invio di messaggi di infrastruttura, ad esempio la messaggistica affidabile può inviare un SequenceAcknowledgement messaggio su una risposta HTTP.
B3314: il risponditore WCF non invia un messaggio di errore in risposta a un messaggio unidirezionale.

Request-Reply

Quando un endpoint WCF è configurato per un messaggio con un dato Action per seguire il modello request-reply, l'endpoint WCF segue i comportamenti e i requisiti seguenti. Se non specificato diversamente, i comportamenti e le regole si applicano per entrambe le versioni di WS-Addressing supportate in WCF:

R3321: Il richiedente deve includere nella richiesta wsa:To, wsa:Action, wsa:MessageID, e le intestazioni per tutti i parametri o le proprietà di riferimento (o entrambi) specificati dal riferimento dell'endpoint.
R3322: Quando si usa WS-Addressing 2004/08, ReplyTo deve essere incluso anche nella richiesta.
R3323: quando si usa WS-Addressing 1.0 e ReplyTo non è presente nella richiesta, viene usato un riferimento endpoint predefinito con la proprietà [address] uguale a http://www.w3.org/2005/08/addressing/anonymous .
R3324: Il richiedente deve includere le intestazioni di wsa:To, wsa:Action e wsa:RelatesTo nel messaggio di risposta, nonché le intestazioni per tutti i parametri di riferimento o le proprietà di riferimento (o entrambe) specificati dal riferimento dell'endpoint ReplyTo nella richiesta.

Errori di indirizzamento dei servizi Web

R3411: WCF genera gli errori seguenti definiti da WS-Addressing 2004/08.

Codice	Motivo
`wsa:DestinationUnreachable`	Il messaggio è arrivato con un `ReplyTo` diverso dall'indirizzo di risposta stabilito per questo canale; non esiste alcun endpoint in ascolto all'indirizzo specificato nell'intestazione To.
`wsa:ActionNotSupported`	i canali dell'infrastruttura o dispatcher associati all'endpoint non riconoscono l'azione specificata nell'intestazione `Action` .

R3412: WCF genera gli errori seguenti definiti da WS-Addressing 1.0.

Codice	Motivo
`wsa10:InvalidAddressingHeader`	Duplicare `wsa:To`, `wsa:ReplyTo`, `wsa:From` o `wsa:MessageID`. Duplicato `wsa:RelatesTo` con lo stesso `RelationshipType`.
`wsa10:MessageAddressingHeaderRequired`	L'intestazione di indirizzamento necessaria non è presente.
`wsa10:DestinationUnreachable`	Il messaggio è arrivato con un `ReplyTo` valore diverso dall'indirizzo di risposta stabilito per questo canale. Non c'è nessun endpoint che ascolta all'indirizzo specificato nell'intestazione 'A'.
`wsa10:ActionNotSupported`	Un'azione specificata nell'intestazione non viene riconosciuta dai canali dell'infrastruttura `Action` o dal dispatcher associato all'endpoint.
`wsa10:EndpointUnavailable`	Il canale RM invia nuovamente questo errore, che indica che l'endpoint non elabora la sequenza in base all'esame delle `CreateSequence` intestazioni di indirizzamento del messaggio.

Il codice nelle tabelle precedenti mappa a FaultCode in SOAP 1.1 e SubCode con Code=Sender in SOAP 1.2.

Binding WSDL 1.1 e asserzioni WS-Policy

Indicante l'utilizzo di WS-Addressing

WCF usa asserzioni di criteri per indicare il supporto degli endpoint per una determinata versione WS-Addressing.

L'asserzione di policy seguente ha come Soggetto Criteri Endpoint [WS-PA] e indica che i messaggi inviati e ricevuti dall'endpoint devono utilizzare WS-Addressing 2004/08.

<wsap:UsingAddressing />

Questa affermazione di politica integra la specifica WS-Addressing 2004/08.

L'asserzione di criteri seguente indica che i messaggi inviati/ricevuti devono usare WS-Addressing 1.0.

<wsam:Addressing/>

L'asserzione di policy seguente ha come soggetto un Endpoint Policy [WS-PA] e indica che i messaggi inviati e ricevuti dall'endpoint devono utilizzare WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

L'elemento wsaw10:UsingAddressing viene preso in prestito da [WS-Addressing-WSDL] e viene usato nel contesto di WS-Policy in conformità a tale specifica, sezione 3.1.2.

L'uso dell'indirizzamento non modifica la semantica delle associazioni HTTP WSDL 1.1, SOAP 1.1 e SOAP 1.2. Ad esempio, se si prevede che una risposta venga inviata a una richiesta indirizzata a un endpoint che utilizza l'associazione HTTP di indirizzamento e WSDL SOAP 1.x, la risposta deve essere inviata come risposta HTTP.

Per le risposte inviate tramite la risposta http, l'asserzione WS-AM è:

<wsam:AnonymousResponses/>

L'asserzione completa dei criteri potrebbe essere simile alla seguente:

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

Esistono tuttavia modelli di scambio di messaggi che traggono vantaggio dalla presenza di due connessioni HTTP opposte indipendenti stabilite tra il richiedente e il risponditore, ad esempio messaggi unidirezionale non richiesti inviati dal risponditore.

WCF offre una funzionalità in base alla quale due canali di trasporto sottostanti possono formare un canale duplex composito, in cui viene usato un canale per i messaggi di input e l'altro viene usato per i messaggi di output. Nel caso del trasporto HTTP, Composite Duplex fornisce due connessioni HTTP opposte. Il richiedente usa una connessione per inviare messaggi al risponditore e il risponditore usa l'altro per inviare messaggi al richiedente.

Per le risposte inviate tramite richieste HTTP separate, l'asserzione ws-am è

<wsam:NonAnonymousResponses/>

L'asserzione completa dei criteri potrebbe essere simile alla seguente:

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

L'uso della seguente asserzione che ha il soggetto Politica di Endpoint [WS-PA] sugli endpoint che utilizzano associazioni HTTP WSDL 1.1 SOAP 1.x richiede due connessioni HTTP separate e opposte, da utilizzare rispettivamente per i messaggi che fluiscono dal richiedente al risponditore e dal risponditore al richiedente.

<cdp:CompositeDuplex/>

L'istruzione precedente comporta i requisiti seguenti nell'intestazione per i wsa:ReplyTo messaggi di richiesta:

R3514: i messaggi di richiesta inviati a un endpoint devono avere un'intestazione ReplyTo con la proprietà [address] non uguale a http://www.w3.org/2005/08/addressing/anonymous se l'endpoint usa un binding HTTP SOAP 1.x WSDL 1.1 e ha un'alternativa ai criteri con un'asserzione wsap10:UsingAddressing o wsap:UsingAddressing insieme a cdp:CompositeDuplex.
R3515: i messaggi di richiesta inviati a un endpoint devono avere un'intestazione ReplyTo con la proprietà [address] uguale a http://www.w3.org/2005/08/addressing/anonymous, o non avere un'intestazione ReplyTo affatto, se l'endpoint usa un'associazione HTTP SOAP 1.x WSDL 1.1 e ha un'alternativa di criteri con asserzione wsap10:UsingAddressing e nessuna asserzione cdp:CompositeDuplex associata.
R3516: i messaggi di richiesta inviati a un endpoint devono avere un'intestazione ReplyTo con una [address] proprietà uguale a http://www.w3.org/2005/08/addressing/anonymous se l'endpoint usa un'associazione HTTP SOAP 1.x WSDL 1.1 e ha un'alternativa ai criteri con wsap:UsingAddressing asserzione e nessuna cdp:CompositeDuplex asserzione associata.

La specifica di indirizzamento WSDL cerca di descrivere associazioni di protocolli simili introducendo un elemento <wsaw:Anonymous/> con tre valori testuali (richiesti, facoltativi e proibiti) per indicare i requisiti nell'intestazione wsa:ReplyTo (sezione 3.2). Sfortunatamente, tale definizione di elemento non è particolarmente utilizzabile come asserzione nel contesto di WS-Policy, perché richiede estensioni specifiche del dominio per supportare l'intersezione di alternative che usano tale elemento come asserzione. Tale definizione di elemento indica anche il valore dell'intestazione ReplyTo anziché il comportamento dell'endpoint in transito, che lo rende specifico del trasporto HTTP.

Definizione dell'azione

WS-Addressing 2004/08 definisce un wsa:Action attributo per gli wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementi. WS-Addressing 1.0 WSDL Binding (WS-ADDR10-WSDL) definisce un attributo simile, wsaw10:Action.

L'unica differenza tra i due è la semantica predefinita del modello di azione descritta nella sezione 3.3.2 di WS-ADDR e nella sezione 4.4.4 di WS-ADDR10-WSDL, rispettivamente.

È ragionevole disporre di due endpoint che condividono lo stesso portType (o contratto, nella terminologia WCF), ma usano versioni diverse di WS-Addressing. Tuttavia, considerando che Action è definito da portType e non dovrebbe cambiare tra gli endpoint che implementano portType, diventa impossibile supportare entrambi i modelli di azione predefiniti.

Per risolvere questa controversia, WCF supporta una singola versione dell'attributo Action .

B3521: WCF usa l'attributo wsaw10:Action sugli wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementi definiti in WS-ADDR10-WSDL per determinare l'URI Action per i messaggi corrispondenti indipendentemente dalla versione WS-Addressing usata dall'endpoint.

Utilizzare l'Endpoint Reference all'interno del Port WSDL

WS-ADDR10-WSDL la sezione 4.1 estende l'elemento wsdl:port per includere l'elemento figlio <wsa10:EndpointReference…/> per descrivere l'endpoint in termini di WS-Addressing. WCF espande questa utilità in WS-Addressing 2004/08, consentendo di <wsa:EndpointReference…/> apparire come elemento figlio di wsdl:port.

R3531: Se un endpoint ha un'alternativa di criteri associata a un'asserzione di criteri <wsaw10:UsingAddressing/>, l'elemento corrispondente wsdl:port può contenere un elemento figlio <wsa10:EndpointReference …/>.
R3532: Se un elemento wsdl:port contiene un elemento figlio <wsa10:EndpointReference …/>, il valore dell'elemento figlio wsa10:EndpointReference/wsa10:Address deve corrispondere al valore dell'attributo @address dell'elemento di pari livello wsdl:port/wsdl:location.
R3533: Se un endpoint ha un'alternativa di criteri associata con l'asserzione della politica <wsap:UsingAddressing/>, l'elemento corrispondente wsdl:port può contenere un elemento <wsa:EndpointReference …/> figlio.
R3534: Se un elemento wsdl:port contiene un elemento figlio <wsa:EndpointReference …/>, il valore dell'elemento figlio wsa:EndpointReference/wsa:Address deve corrispondere al valore dell'attributo dell'elemento di pari livello @addresswsdl:port/.

Composizione con WS-Security

In base alle sezioni relative alle considerazioni sulla sicurezza in WS-ADDR e WS-ADDR10, è consigliabile firmare tutte le intestazioni dei messaggi di indirizzamento insieme al corpo del messaggio per associarle.

Quando viene usato WS-Security per la protezione dell'integrità dei messaggi, le intestazioni dei messaggi WS-Addressing, così come le intestazioni risultanti da parametri di riferimento o proprietà (o entrambi), devono essere firmate insieme al corpo del messaggio.

Esempi

messaggio One-Way

In questo scenario, il mittente invia un messaggio unidirezionale al ricevitore. Vengono usati SOAP 1.2, HTTP 1.1 e W3C WS-Addressing 1.0.

Struttura del messaggio di richiesta: le intestazioni del messaggio includono gli elementi wsa10:To e wsa10:Action. Il corpo del messaggio include un elemento specifico <app:Ping> dello spazio dei nomi dell'applicazione.

Intestazioni HTTP: la destinazione di POST corrisponde all'URI nell'elemento wsa10:To.

L'intestazione Content-Type ha il valore di application/soap+xml come richiesto da SOAP 1.2. I parametri charset e action sono inclusi. Il action parametro dell'intestazione Content-Type corrisponde al valore dell'intestazione del wsa10:Action messaggio.

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>

Il ricevitore risponde con una risposta HTTP vuota e lo stato 202. Esempio di risposta HTTP:

HTTP/1.1 202 Accepted
Date: Fri, 15 Jul 2005 08:56:07 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50215
Cache-Control: private
Content-Length: 0

Meccanismo di ottimizzazione della trasmissione dei messaggi SOAP

In questa sezione vengono descritti i dettagli di implementazione WCF per HTTP SOAP MTOM. La tecnologia MTOM è un meccanismo di codifica dei messaggi SOAP della stessa classe della codifica di testo/XML tradizionale o della codifica binaria WCF. MTOM include quanto segue:

Meccanismo di codifica e creazione di pacchetti XML descritto da [XOP] che ottimizza gli elementi di informazioni XML contenenti dati binari con codifica Base64 in parti binarie separate.
Incapsulamento MIME del pacchetto XOP che serializza l'Infoset XML e ogni parte binaria del pacchetto XOP in una parte MIME separata.
Una codifica XOP MIME applicata alla busta SOAP 1.x.
Associazione di trasporto HTTP.

È possibile usare MTOM con trasporti non HTTP con WCF. Tuttavia, in questo argomento ci si concentrerà su HTTP.

Il formato MTOM sfrutta un ampio set di specifiche relative a MTOM, XOP e MIME. La modularità di questo set di specifiche rende piuttosto difficile ricostruire i requisiti esatti sulla semantica di formattazione ed elaborazione. Questa sezione descrive i requisiti di formato ed elaborazione per l'associazione HTTP MTOM.

Codifica dei messaggi MTOM

Generazione di messaggi MTOM

La sezione [XOP] 3.1 descrive il processo di codifica XML con elementi di informazioni sugli elementi che contengono valori base64 in un pacchetto XOP definito in modo astratto.

La sequenza di passaggi seguente descrive il processo di codifica specifico di MTOM:

Assicurarsi che l'Envelope SOAP da codificare non contenga alcun elemento informativo con un [namespace name] di http://www.w3.org/2004/08/xop/include e un [local name] di Include.
Creare un pacchetto MIME vuoto.
Identificare all'interno dell'Infoset XML originale gli elementi di informazioni sugli elementi da ottimizzare. Affinché gli elementi siano ottimizzati, i caratteri che costituiscono il [children] dell'elemento informativo devono essere nella forma canonica di xs:base64Binary (vedere XSD-2, 3.2.16 base64Binary) e non devono contenere spazi vuoti precedenti, allineati con o successivi al contenuto senza spazi vuoti.
Creare una Busta SOAP XOP che sia una copia della Busta SOAP originale, ma con gli elementi figli di ciascun elemento informativo identificato nel passaggio precedente sostituiti da un elemento informativo xop:Include costruito come segue:
1. Trasformare i caratteri sostituiti in dati binari elaborandoli come dati con codifica Base64.
2. Generare un valore di intestazione Content-ID univoco che soddisfi i requisiti R3133 e R3134.
3. Generare un'intestazione CONTENT-Transfer-Encoding MIME con il valore binario.
4. Se l'elemento di informazioni da ottimizzare (il [padre] dell'elemento di informazioni appena inserito xop:Include) ha un elemento di informazioni sull'attributo xmime:contentType, genera un'intestazione MIME Content-Type con il valore dell'attributo xmime:contentType.
5. Generare una nuova parte MIME binaria con contenuto formato da dati binari decodificati dai caratteri sostituiti elaborati come base64, intestazione Content-ID da 4b, Content- Transfer-Encoding intestazione da 4c, intestazione Content-Type se generata nel passaggio 4d.
6. Aggiungere un href attributo all'elemento xop:Include con il valore cid: URI derivato dal valore dell'intestazione Content-ID generato nel passaggio 4b. Rimuovere i caratteri "<" e ">" racchiusi, usare l'escape URL per la stringa rimanente e aggiungere il prefisso cid:. Il seguente set minimo di caratteri deve essere codificato con escape secondo RFC1738 e RFC2396. È possibile eseguire l'escape di altri caratteri.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Creare una parte radice MIME con l'XOP SOAP Envelope del passaggio 4.
Scrivi le intestazioni HTTP, inclusa l'intestazione HTTP Content-Type.
Scrivere il pacchetto MIME.

Elaborazione di messaggi MTOM

L'elaborazione di un messaggio MTOM è l'esatto inverso del processo descritto nella sezione precedente "Generazione di messaggi MTOM":

Verificare che la parte radice MIME abbia il Content-Type application/xop+xml.
Costruisci un SOAP Envelope analizzando la parte radice MIME del pacchetto come documento XML. La codifica dei caratteri è determinata dal charset parametro content-Type della parte MIME radice.
Per ogni oggetto informativo nell'SOAP Envelope costruito, che include, come unico membro della relativa proprietà [children], un oggetto informativo xop:Include:
1. Rimuovere il prefisso cid: e annullare l'escape di tutte le sequenze di escape URI (RFC 2396) nel valore dell'attributo @href dell'elemento xop:Include. Racchiudere la stringa di risultato in "<", ">".
2. Individuare la parte MIME con il valore dell'intestazione Content-ID corrispondente alla stringa derivata nel passaggio 3a.
3. Sostituire l'elemento informazioni sull'elemento xop:Include visualizzato nella children proprietà di ogni elemento con gli elementi di informazioni sui caratteri che rappresentano la codifica base64 canonica (vedere XSD-2, 3.2.16 base64Binary) del corpo dell'entità della parte MIME identificata nel passaggio 3b (sostituire in modo efficace l'elemento informativo dell'elemento xop:Include con i dati ricostruiti dalla parte del pacchetto).

Intestazione HTTP Content-Type

Di seguito è riportato un elenco di chiarimenti WCF per il formato dell'intestazione HTTP Content-Type di un messaggio con codifica MTOM SOAP 1.x derivato dai requisiti indicati nella specifica MTOM stessa e sono derivati da MTOM e RFC 2387.

R4131: L'intestazione HTTP Content-Type deve avere il valore multipart/related (senza distinzione tra maiuscole e minuscole) e includere i suoi parametri. I nomi dei parametri sono insensibili alle maiuscole. L'ordine dei parametri non è significativo.
Il modulo completo Backus-Naur (BNF) dell'intestazione Content-Type per i messaggi MIME è elencato nella sezione RFC 2045, sezione 5.1.
R4132: un'intestazione HTTP Content-Type deve avere un parametro di tipo con il valore application/xop+xml racchiuso tra virgolette doppie.

Anche se il requisito di usare virgolette doppie non è esplicito in RFC 2387, il testo osserva che tutti i parametri di tipo di supporto multipart/correlati contengono probabilmente caratteri riservati come "@" o "/" e quindi richiedono virgolette doppie.

R4133: un'intestazione HTTP Content-Type deve avere un parametro start con il valore dell'intestazione Content-ID della parte MIME che contiene SOAP 1.x Envelope, racchiusa tra virgolette doppie. Se il parametro start viene omesso, la prima parte MIME deve contenere SOAP 1.x Envelope.
R4134: un'intestazione HTTP Content-Type per un messaggio con codifica SOAP 1.1 MTOM deve includere il parametro start-info con il valore di testo/xml, racchiuso tra virgolette doppie.
R4135: un'intestazione HTTP Content-Type per un messaggio con codifica SOAP 1.2 MTOM deve includere il parametro start-info con il valore di application/soap+xml, racchiuso tra virgolette doppie.

R4136: l'intestazione HTTP Content-Type per un messaggio con codifica SOAP 1.x MTOM deve avere il parametro confine con il valore (racchiuso tra virgolette doppie) che corrisponde al BNF confine MIME definito in RFC 2046, sezione 5.1.1

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

Esempi:

CORRETTO

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"

CORRETTO

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

SCORRETTO

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"

Parte MIME di Infoset

SOAP 1.x Envelope viene incapsulato come parte radice del pacchetto MIME XOP e viene spesso chiamato parte infoset.

R4141: La busta SOAP 1.x deve essere incapsulata come parte radice del pacchetto MIME XOP, denominata parte infoset e a cui si fa riferimento dal tipo di contenuto HTTP.
R4142: la parte SOAP Infoset deve includere le intestazioni MIME seguenti: Content-ID, Content-Transfer-Encodinge Content-Type.

Il formato dell'intestazione Content-ID è definito da RFC 2045 come

"Content-ID" ":" msg-id

dove msg-id è definito in RFC 2822 (che sostituisce RFC 822, a cui si fa riferimento in RFC 2045) come:

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

ed è effettivamente un indirizzo di posta elettronica racchiuso tra "<" e ">". Il prefisso e il suffisso [CFWS] sono stati aggiunti in RFC 2822 per includere commenti e non devono essere usati per garantire l'interoperabilità.

R4143: Il valore dell'intestazione Content-ID per la parte MIME di Infoset deve seguire la produzione msg-id di RFC 2822, omettendo le parti di prefisso e suffisso [CFWS].

Un certo numero di implementazioni MIME ha limitato i requisiti per il valore racchiuso all'interno di "<" e ">" come indirizzo di posta elettronica e usato absoluteURI racchiuso in "<" , ">" oltre all'indirizzo di posta elettronica. Questa versione di WCF usa i valori dell'intestazione MIME Content-ID del modulo:

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

R4144: i processori MTOM devono accettare i valori della header Content-ID che corrispondono ai seguenti criteri meno rigidi msg-id.

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

MIME (RFC 2045) fornisce l'intestazione Content-Transfer-Encoding per comunicare la codifica del contenuto della parte MIME. Il valore predefinito definito per Content-Transfer-Encoding è a 7 bit, che non è adatto per la maggior parte dei messaggi SOAP, quindi l'intestazione Content-Transfer-Encoding è necessaria per una maggiore interoperabilità:

R4145: la parte SOAP Infoset deve contenere l'intestazione Content-Transfer-Encoding.
R4146: se la codifica dei caratteri della busta SOAP è UTF-8, il valore dell'intestazione Content-Transfer-Encoding deve essere a 8 bit.
R4147: se la codifica dei caratteri della busta SOAP è UTF-16, il valore dell'intestazione Content-Transfer-Encoding deve essere binario.
Secondo [XOP] sezione 5,
La parte Infoset di SOAP1.1 deve contenere l'intestazione Content-Type con tipo di supporto application/xop+xml e parametri type="text/xml" e charset
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: La parte Infoset SOAP 1.2 deve contenere l'intestazione Content-Type con tipo di media application/xop+xml e parametri type="application/soap+xml" e charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
Mentre XOP definisce che il parametro charset per application/xop+xml sia facoltativo, è necessario per l'interoperabilità, analogamente al requisito BP 1.1 sul parametro charset per il tipo di media text/xml.
R41410: i parametri type e charset devono essere presenti nell'intestazione Content-Type della parte Infoset SOAP 1.x.

Supporto degli endpoint WCF per MTOM

Lo scopo di MTOM è codificare un messaggio SOAP per ottimizzare i dati con codifica Base64. Di seguito è riportato un elenco di vincoli:

R4151: qualsiasi elemento di informazioni sugli elementi che contiene dati con codifica Base64 può essere ottimizzato.
B4152: WCF ottimizza gli elementi di informazioni sugli elementi che contengono dati con codifica Base64 e superano la lunghezza di 1024 byte.

Un endpoint WCF configurato per l'uso di MTOM invierà sempre messaggi con codifica MTOM. Anche se nessuna parte soddisfa i criteri richiesti, il messaggio è ancora codificato con MTOM (serializzato come pacchetto MIME con una singola parte MIME contenente la busta SOAP).

Asserzione WS-Policy per MTOM

WCF usa l'asserzione di criteri seguente per indicare l'utilizzo MTOM per endpoint:

<wsoma:OptimizedMimeSerialization />

R4211: l'asserzione di criteri precedente ha un oggetto criteri endpoint e specifica che tutti i messaggi inviati e ricevuti dall'endpoint devono essere ottimizzati tramite MTOM.
B4212: Se configurata per l'uso dell'ottimizzazione MTOM, un endpoint WCF aggiunge un'asserzione di politica MTOM alla politica associata all'oggetto corrispondente wsdl:binding.

Composizione con WS-Security

MTOM è un meccanismo di codifica simile a text/xml e XML binario WCF. MTOM offre una composizione naturale con WS-Security e altri protocolli WS-*: un messaggio protetto con WS-Security può essere ottimizzato tramite MTOM.

Esempi

MESSAGGIO WCF SOAP 1.1 codificato tramite 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

Messaggio SOAP 1.2 Sicuro di WCF Codificato Usando MTOM

In questo esempio un messaggio viene codificato usando MTOM e SOAP 1.2 protetto tramite WS-Security. Le parti binarie identificate per la codifica sono i contenuti di BinarySecurityToken e CipherValue dell'EncryptedData corrispondente alla firma crittografata e al corpo crittografato. Si noti che CipherValue di EncryptedKey non è stato identificato per l'ottimizzazione da WCF, perché la sua lunghezza è inferiore a 1024 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

Condividi tramite

Protocolli di messaggistica

SOAP 1.1 e SOAP 1.2

Involucro e modello di elaborazione

Elaborazione intestazione obbligatoria

Errori SOAP

Associazione HTTP

SOAP 1.1 Binding HTTP

Collegamento HTTP SOAP 1.2

WS-Addressing

Riferimenti agli endpoint

Riferimenti agli endpoint e versioni di WS-Addressing

Riferimenti agli endpoint e metadati

Intestazioni per l'indirizzamento dei messaggi

Intestazioni dei messaggi

Parametri e proprietà di riferimento

Modelli di Scambio messaggi

messaggio One-Way

Request-Reply

Errori di indirizzamento dei servizi Web

Binding WSDL 1.1 e asserzioni WS-Policy

Indicante l'utilizzo di WS-Addressing

Definizione dell'azione

Utilizzare l'Endpoint Reference all'interno del Port WSDL

Composizione con WS-Security

Esempi

messaggio One-Way

Meccanismo di ottimizzazione della trasmissione dei messaggi SOAP

Codifica dei messaggi MTOM

Generazione di messaggi MTOM

Elaborazione di messaggi MTOM

Intestazione HTTP Content-Type

Parte MIME di Infoset

Supporto degli endpoint WCF per MTOM

Asserzione WS-Policy per MTOM

Composizione con WS-Security

Esempi

MESSAGGIO WCF SOAP 1.1 codificato tramite MTOM

Messaggio SOAP 1.2 Sicuro di WCF Codificato Usando MTOM

Risorse aggiuntive