Protocolos de mensagens

Artigo
03/02/2024

A pilha de canais do Windows Communication Foundation (WCF) emprega canais de codificação e transporte para transformar a representação de mensagens internas em seu formato de conexão e enviá-las usando um transporte específico. O transporte mais comum usado para interoperabilidade de serviços da Web é HTTP, e as codificações mais comuns usadas por serviços da Web são SOAP 1.1 baseada em XML, SOAP 1.2 e MTOM (Message Transmission Optimization Mechanism).

Este tópico aborda os detalhes da implementação do WCF para os seguintes protocolos empregados pelo HttpTransportBindingElement.

Especificação/documento:

HTTP 1,1
Ligação HTTP SOAP 1.1, Secção 7
SOAP 1.2 HTTP Binding Seção 7

Este tópico aborda os detalhes da implementação do WCF para os seguintes protocolos que TextMessageEncodingBindingElement empregam MtomMessageEncodingBindingElement .

Especificação/Documento:

Este tópico aborda os detalhes da implementação do WCF para os seguintes protocolos que MtomMessageEncodingBindingElement empregam.

Especificação/documento:

Os seguintes namespaces XML e prefixos associados são usados ao longo deste tópico:

Prefixo	URI (Uniform Resource Identifier) do 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`
PD	`http://schemas.microsoft.com/net/2006/06/duplex`

SABONETE 1.1 e SABONETE 1.2

Envelope e Modelo de Processamento

WCF implementa o processamento de envelope SOAP 1.1 seguindo Basic Profile 1.1 (BP11) e Basic Profile 1.0 (SSBP10). O processamento de envelopes SOAP 1.2 é implementado seguindo SOAP12-Part1.

Esta seção explica certas opções de implementação tomadas pelo WCF em relação ao BP11 e SOAP12-Part1.

Processamento obrigatório de cabeçalhos

O WCF segue regras para processar cabeçalhos marcados mustUnderstand descritos nas especificações SOAP 1.1 e SOAP 1.2, com as seguintes variações.

Uma mensagem que entra na pilha de canais WCF é processada por canais individuais configurados por elementos de vinculação associados, por exemplo, Codificação de mensagem de texto, Segurança, Mensagens confiáveis e Transações. Cada canal reconhece cabeçalhos do namespace associado e os marca como compreendidos. Quando uma mensagem entra no dispatcher, o formatador de operação lê os cabeçalhos esperados pelo contrato de mensagem/operação correspondente e os marca como compreendidos. Em seguida, o dispatcher verifica se os cabeçalhos restantes não são compreendidos, mas marcados como mustUnderstand e lança uma exceção. As mensagens que contêm mustUnderstand cabeçalhos direcionados ao destinatário não são processadas pelo código do aplicativo do destinatário.

Esse processamento em camadas permite a separação entre as camadas de infraestrutura e as camadas de aplicação do nó SOAP:

B1111: Cabeçalhos que não são compreendidos são detetados depois que a mensagem é processada pela pilha de canais de infraestrutura WCF, mas antes de ser processada pelo aplicativo

O mustUnderstand valor do cabeçalho difere entre SOAP 1.1 e SOAP 1.2. O Perfil Básico 1.1 requer que o mustUnderstand valor seja 0 ou 1 para mensagens SOAP 1.1. SOAP 1.2 permite 0, 1, falsee true como valores, mas recomenda a emissão de uma representação canônica de xs:boolean valores (false, true).
B1112: WCF emite mustUnderstand valores 0 e 1 para ambas as versões SOAP 1.1 e SOAP 1.2 do envelope SOAP. WCF aceita todo o espaço de valor de xs:boolean para o mustUnderstand cabeçalho (0, 1, falsetrue, )

Falhas SOAP

A seguir está uma lista de implementações de falha SOAP específicas do WCF.

B2121: WCF retorna os seguintes códigos de falha SOAP 1.1: s11:mustUnderstand, s11:Cliente s11:Server.
B2122: WCF retorna os seguintes códigos de falha SOAP 1.2: s12:MustUnderstand, s12:Sendere s12:Receiver.

Vinculação HTTP

Vinculação HTTP SOAP 1.1

WCF implementa a ligação HTTP SOAP1.1 seguindo a seção 3.4 da especificação Basic Profile 1.1 com os seguintes esclarecimentos:

B2211: O serviço WCF não implementa o redirecionamento de solicitações HTTP POST.
B2212: Os clientes WCF suportam cookies HTTP de acordo com 3.4.8.

Ligação HTTP SOAP 1.2

WCF implementa a ligação HTTP SOAP 1.2 conforme descrito na especificação SOAP 1.2-part 2 (SOAP12Part2) com os seguintes esclarecimentos.

SOAP 1.2 introduziu um parâmetro de ação opcional para o application/soap+xml tipo de mídia. Esse parâmetro é útil para otimizar o envio de mensagens sem exigir que o corpo da mensagem SOAP seja analisado quando o WS-Addressing não é usado.

R2221: O application/soap+xml parâmetro action, quando presente em uma solicitação SOAP 1.2, deve corresponder ao soapAction atributo no elemento dentro da wsoap12:operation ligação WSDL correspondente.
R2222: O application/soap+xml parâmetro action, quando presente em uma mensagem SOAP 1.2, deve corresponder wsa:Action quando WS-Addressing 2004/08 ou WS-Addressing 1.0 são usados.

Quando WS-Addressing está desabilitado e uma solicitação de entrada não contém um parâmetro de ação, a mensagem Action é considerada não especificada.

WS-Endereçamento

WCF implementa 3 versões do WS-Addressing:

WS-Endereçamento 2004/08
Endereçamento de serviços Web W3C 1.0 Core (ADDR10-CORE) e ligação SOAP (ADDR10-SOAP)
WS-Addressing 1.0 - Metadados

Referências de pontos finais

Todas as versões do WS-Addressing que o WCF implementa usam referências de ponto de extremidade para descrever pontos de extremidade.

Referências de ponto de extremidade e versões WS-Addressing

O WCF implementa vários protocolos de infraestrutura que usam WS-Addressing e, em particular, o elemento e W3C.WsAddressing.EndpointReferenceType a EndpointReference classe (por exemplo, WS-ReliableMessaging, WS-SecureConversation e WS-Trust). O WCF suporta o uso de qualquer versão do WS-Addressing com outros protocolos de infraestrutura. Os pontos de extremidade WCF suportam uma versão do WS-Addressing por ponto de extremidade.

Para R3111, o namespace para o EndpointReference elemento ou tipo usado em mensagens trocadas com um ponto de extremidade WCF deve corresponder à versão do WS-Addressing implementada por esse ponto de extremidade.

Por exemplo, se um ponto de extremidade WCF implementa WS-ReliableMessaging, o AcksTo cabeçalho retornado por esse ponto de extremidade dentro CreateSequenceResponse usa a versão WS-Addressing que o EncodingBinding elemento especifica para esse ponto de extremidade.

Referências e metadados de pontos finais

Vários cenários exigem a comunicação de metadados ou uma referência a metadados para um determinado ponto de extremidade.

B3121: O WCF emprega mecanismos descritos na especificação WS-MetadataExchange (MEX) Seção 6 para incluir metadados para referências de ponto de extremidade por valor ou por referência.

Considere um cenário em que um serviço WCF requer autenticação usando um token SAML (Security Assertions Markup Language) emitido pelo emissor do token em http://sts.fabrikam123.com. O ponto de extremidade WCF descreve esse requisito de autenticação usando sp:IssuedToken asserção com uma asserção aninhada sp:Issuer apontando para o emissor de token. Os aplicativos cliente que acessam a sp:Issuer asserção precisam saber como se comunicar com o ponto de extremidade do emissor do token. O cliente precisa saber metadados sobre o emissor do token. Usando as extensões de metadados de referência de ponto de extremidade definidas no MEX, o WCF fornece uma referência aos metadados do emissor do 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>

Cabeçalhos de endereçamento de mensagens

Cabeçalhos de mensagens

Para ambas as versões WS-Addressing, o WCF usa os seguintes cabeçalhos de mensagem, conforme prescrito pelas especificações wsa:To, , , wsa:Actionwsa:MessageID,e wsa:RelatesTowsa:ReplyTo.

B3211: Para todas as versões do WS-Addressing, o WCF honra, mas não produz fora da caixa, cabeçalhos de wsa:FaultTo mensagem WS-Addressing e wsa:From.

Os aplicativos que interagem com aplicativos WCF podem adicionar esses cabeçalhos de mensagem e o WCF os processará de acordo.

Parâmetros de referência e propriedades

O WCF implementa o processamento de parâmetros de referência de ponto final e propriedades de referência de acordo com as respetivas especificações.

B3221: Quando configurado para usar o WS-Addressing 2004/08, os pontos de extremidade WCF não diferenciam entre o processamento de Propriedades de Referência e Parâmetros de Referência.

Padrões de troca de mensagens

A sequência de mensagens envolvidas na invocação da operação do serviço Web é chamada de padrão de troca de mensagens. O WCF oferece suporte a padrões de troca de mensagens unidirecionais, de solicitação-resposta e duplex. Esta seção esclarece os requisitos do WS-Addressing no processamento de mensagens, dependendo do padrão de troca de mensagens que está sendo usado.

Ao longo desta seção, o solicitante envia a primeira mensagem e o respondente recebe a primeira mensagem.

Mensagem unidirecional

Quando um ponto de extremidade WCF é configurado para suportar mensagens com um dado Action para seguir um padrão unidirecional, o ponto de extremidade WCF segue os seguintes comportamentos e requisitos. A menos que especificado de outra forma, comportamentos e regras se aplicam a ambas as versões do WS-Addressing suportadas no WCF:

R3311: O solicitante deve incluir wsa:To, wsa:Actione cabeçalhos para todos os parâmetros de referência especificados pela referência do ponto final. Quando o WS-Addressing 2004/08 é usado e [propriedades de referência] são especificadas pela referência do ponto final, os cabeçalhos correspondentes também devem ser adicionados à mensagem.
B3312: O solicitante pode incluir MessageID, ReplyToe FaultTo cabeçalhos. A infraestrutura do recetor irá ignorá-los, e eles serão passados para o aplicativo.
R3313: Quando HTTP é usado e nenhuma mensagem está sendo enviada no trecho de resposta HTTP, o respondente deve enviar uma resposta HTTP com um corpo vazio e um código de status HTTP 202.

Quando o transporte HTTP está em uso e o contrato de operação declara uma mensagem unidirecional, a resposta HTTP ainda pode ser usada para enviar mensagens de infraestrutura — por exemplo, mensagens confiáveis podem enviar uma SequenceAcknowledgement mensagem em uma resposta HTTP.
B3314: O respondente WCF não envia uma mensagem de falha em resposta a uma mensagem unidirecional.

Pedido-Resposta

Quando um ponto de extremidade WCF é configurado para uma mensagem com um dado Action para seguir o padrão solicitação-resposta, o ponto de extremidade WCF segue os comportamentos e requisitos abaixo. A menos que especificado de outra forma, comportamentos e regras se aplicam a ambas as versões do WS-Addressing suportadas no WCF:

R3321: O solicitante deve incluir na solicitação wsa:To, wsa:Action, wsa:MessageIDe cabeçalhos para todos os parâmetros de referência ou propriedades de referência (ou ambos) especificados pela referência do ponto final.
R3322: Quando WS-Addressing 2004/08 é usado, ReplyTo também deve ser incluído na solicitação.
R3323: Quando WS-Addressing 1.0 é usado e ReplyTo não está presente na solicitação, uma referência de ponto de extremidade padrão com a propriedade [address] igual a http://www.w3.org/2005/08/addressing/anonymous é usada.
R3324: O solicitante deve incluir wsa:To, wsa:Actione wsa:RelatesTo cabeçalhos na mensagem de resposta, bem como cabeçalhos para todos os parâmetros de referência ou propriedades de referência (ou ambos) especificados pela referência de ReplyTo ponto de extremidade na solicitação.

Falhas de endereçamento de serviços Web

R3411: WCF produz as seguintes falhas definidas pelo WS-Addressing 2004/08.

Código	Motivo
`wsa:DestinationUnreachable`	A mensagem chegou com um `ReplyTo` endereço diferente do endereço de resposta estabelecido para este canal, não há escuta de ponto final no endereço especificado no cabeçalho Para.
`wsa:ActionNotSupported`	Os canais de infraestrutura ou dispatcher associados ao ponto de extremidade não reconhecem a ação especificada no `Action` cabeçalho.

R3412: WCF produz as seguintes falhas definidas pelo WS-Addressing 1.0.

Código	Motivo
`wsa10:InvalidAddressingHeader`	Duplicar `wsa:To`, `wsa:ReplyTowsa:From` ou `wsa:MessageID`. Duplicar `wsa:RelatesTo` com o mesmo `RelationshipType`.
`wsa10:MessageAddressingHeaderRequired`	O cabeçalho de endereçamento necessário está ausente.
`wsa10:DestinationUnreachable`	A mensagem chegou com um `ReplyTo` endereço diferente do endereço de resposta estabelecido para este canal. Não há escuta de ponto de extremidade no endereço especificado no cabeçalho Para.
`wsa10:ActionNotSupported`	Uma ação especificada no `Action` cabeçalho não é reconhecida pelos canais de infraestrutura ou dispatcher associados ao ponto de extremidade.
`wsa10:EndpointUnavailable`	O canal RM envia essa falha de volta, indicando que o ponto de extremidade não processará a sequência com base no exame dos cabeçalhos de endereçamento da `CreateSequence` mensagem.

O código nas tabelas anteriores é mapeado para FaultCode em SOAP 1.1 e SubCode (com Code=Sender) em SOAP 1.2.

WSDL 1.1 Vinculação e asserções WS-Policy

Indicando o uso do WS-Addressing

O WCF usa asserções de política para indicar suporte de ponto de extremidade para uma versão específica do WS-Addressing.

A seguinte declaração de política tem Assunto da Política de Ponto Final [WS-PA] e indica que as mensagens enviadas e recebidas do ponto de extremidade devem usar o WS-Addressing 2004/08.

<wsap:UsingAddressing />

Esta afirmação de política aumenta a especificação WS-Addressing 2004/08.

A seguinte afirmação de política indica que as mensagens enviadas/recebidas devem usar o WS-Addressing 1.0.

<wsam:Addressing/>

A seguinte declaração de política tem um Assunto de Política de Ponto Final [WS-PA] e indica que as mensagens enviadas e recebidas do ponto de extremidade devem usar o WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

O wsaw10:UsingAddressing elemento é emprestado de [WS-Addressing-WSDL] e é usado no contexto do WS-Policy em conformidade com essa especificação, seção 3.1.2.

O uso de endereçamento não altera a semântica das ligações HTTP WSDL 1.1, SOAP 1.1 e SOAP 1.2. Por exemplo, se uma resposta for esperada para uma solicitação enviada a um ponto de extremidade que usa endereçamento e associação HTTP WSDL SOAP 1.x, a resposta deverá ser enviada usando a resposta HTTP.

Para respostas enviadas pela resposta http, a asserção WS-AM é:

<wsam:AnonymousResponses/>

A afirmação de política completa pode ter esta aparência:

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

No entanto, existem padrões de troca de mensagens que se beneficiam de ter duas conexões HTTP conversas independentes estabelecidas entre o solicitante e o respondente, por exemplo, mensagens unidirecionais não solicitadas enviadas pelo respondente.

WCF oferece um recurso pelo qual dois canais de transporte subjacentes podem formar um canal duplex composto, onde um canal é usado para mensagens de entrada e o outro é usado para mensagens de saída. No caso do Transporte HTTP, o Composite Duplex fornece duas conexões HTTP inversas. O solicitante usa uma conexão para enviar mensagens ao respondente e o respondente usa a outra para enviar mensagens de volta ao solicitante.

Para respostas enviadas por solicitações http separadas, a asserção ws-am é

<wsam:NonAnonymousResponses/>

A afirmação de política completa pode ter esta aparência:

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

O uso da seguinte asserção que tem Assunto da Política de Ponto Final [WS-PA] em pontos de extremidade que usam ligações HTTP WSDL 1.1 SOAP 1.x requer duas conexões HTTP inversas separadas para serem usadas para mensagens que fluem de solicitante para respondente e respondente para solicitante, respectivamente.

<cdp:CompositeDuplex/>

A instrução anterior leva aos seguintes requisitos no cabeçalho para wsa:ReplyTo mensagens de solicitação:

R3514: As mensagens de solicitação enviadas para um ponto de extremidade devem ter um ReplyTo cabeçalho com a [address] propriedade não igual a http://www.w3.org/2005/08/addressing/anonymous se o ponto de extremidade usar uma ligação HTTP WSDL 1.1 SOAP 1.x e tiver uma alternativa de política com uma wsap10:UsingAddressing ou wsap:UsingAddressing asserção acoplada com cdp:CompositeDuplex anexado.
R3515: As mensagens de solicitação enviadas para um ponto de extremidade devem ter um ReplyTo cabeçalho com a [address] propriedade igual a http://www.w3.org/2005/08/addressing/anonymous, ou não ter um ReplyTo cabeçalho, se o ponto de extremidade usar uma ligação HTTP WSDL 1.1 SOAP 1.x e tiver uma alternativa de política com wsap10:UsingAddressing asserção e nenhuma cdp:CompositeDuplex asserção anexada.
R3516: As mensagens de solicitação enviadas para um ponto de extremidade devem ter um ReplyTo cabeçalho com uma [address] propriedade igual a http://www.w3.org/2005/08/addressing/anonymous se o ponto de extremidade usar uma ligação HTTP WSDL 1.1 SOAP 1.x e tiver uma alternativa de política com wsap:UsingAddressing asserção e nenhuma cdp:CompositeDuplex asserção anexada.

A especificação WSDL de endereçamento WSD tenta descrever ligações de protocolo semelhantes introduzindo um elemento <wsaw:Anonymous/> com três valores textuais (obrigatório, opcional e proibido) para indicar os wsa:ReplyTo requisitos no cabeçalho (seção 3.2). Infelizmente, essa definição de elemento não é particularmente utilizável como uma asserção no contexto do WS-Policy, porque requer extensões específicas do domínio para suportar a interseção de alternativas usando tal elemento como uma asserção. Essa definição de elemento também indica o valor do cabeçalho em oposição ao comportamento do ponto de ReplyTo extremidade no fio, o que o torna específico para o transporte HTTP.

Definição de ação

WS-Addressing 2004/08 define um wsa:Action atributo para os wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementos. WS-Addressing 1.0 WSDL Binding (WS-ADDR10-WSDL) define um atributo semelhante, wsaw10:Action.

A única diferença entre os dois é a semântica padrão de ação descrita na seção 3.3.2 do WS-ADDR e na seção 4.4.4 do WS-ADDR10-WSDL, respectivamente.

É razoável ter dois pontos de extremidade que compartilham o mesmo portType (ou contrato, na terminologia WCF), mas usando versões diferentes do WS-Addressing. Mas dado que a portType Ação é definida pelo e não deve ser alterada entre os pontos finais que implementam o portType, torna-se impossível suportar ambos os padrões de ação padrão.

Para resolver essa controvérsia, o WCF oferece suporte a uma única versão do Action atributo.

B3521: WCF usa o wsaw10:Action atributo em wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementos conforme definido em WS-ADDR10-WSDL para determinar o Action URI para as mensagens correspondentes, independentemente da versão WS-Addressing usada pelo ponto de extremidade.

Usar referência de ponto de extremidade dentro da porta WSDL

A seção 4.1 do WS-ADDR10-WSDL estende o wsdl:port elemento para incluir o <wsa10:EndpointReference…/> elemento filho para descrever o ponto de extremidade nos termos do WS-Addressing. WCF expande este utilitário no WS-Addressing 2004/08, permitindo que <wsa:EndpointReference…/> apareça como um elemento filho do wsdl:port.

R3531: Se um ponto de extremidade tiver uma alternativa de política anexada com uma <wsaw10:UsingAddressing/> asserção de política, o elemento correspondente wsdl:port pode conter um elemento <wsa10:EndpointReference …/>filho .
R3532: Se um wsdl:port contém um elemento <wsa10:EndpointReference …/>filho , o wsa10:EndpointReference/wsa10:Address valor do elemento filho deve corresponder ao @address valor do atributo do elemento irmão wsdl:port/wsdl:location .
R3533: Se um ponto de extremidade tiver uma alternativa de política anexada com <wsap:UsingAddressing/> asserção de política, o elemento correspondente wsdl:port poderá conter um elemento <wsa:EndpointReference …/>filho .
R3534: Se um wsdl:port contém um elemento <wsa:EndpointReference …/>filho , o wsa:EndpointReference/wsa:Address valor do elemento filho deve corresponder ao @address valor do atributo do elemento irmão wsdl:port/wsdl:location .

Composição com WS-Security

De acordo com as seções de consideração de segurança no WS-ADDR e WS-ADDR10, recomenda-se que todos os cabeçalhos de mensagem de endereçamento sejam assinados juntamente com o corpo da mensagem para vinculá-los.

Quando o WS-Security é usado para proteção da integridade da mensagem, os cabeçalhos de mensagem WS-Addressing, bem como os cabeçalhos resultantes de parâmetros ou propriedades de referência (ou ambos) devem ser assinados juntamente com o corpo da mensagem.

Exemplos

Mensagem unidirecional

Nesse cenário, o remetente envia uma mensagem unidirecional para o recetor. SOAP 1.2, HTTP 1.1 e W3C WS-Addressing 1.0 são usados.

A Estrutura da Mensagem de Solicitação: Os cabeçalhos das mensagens incluem wsa10:To elementos e wsa10:Action . O corpo da mensagem inclui um elemento específico <app:Ping> do namespace do aplicativo.

Cabeçalhos HTTP: O destino no POST corresponde ao URI no wsa10:To elemento .

O cabeçalho Content-Type tem o valor de application/soap+xml conforme exigido pelo SOAP 1.2. Parâmetros charset e action estão incluídos. O action parâmetro do cabeçalho Content-Type corresponde ao valor do cabeçalho da wsa10:Action mensagem.

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>

O recetor responde com uma resposta HTTP vazia e status 202. Um exemplo da resposta 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

Mecanismo de otimização da transmissão de mensagens SOAP

Esta seção descreve os detalhes de implementação do WCF para o HTTP SOAP MTOM. A tecnologia MTOM é um mecanismo de codificação de mensagens SOAP da mesma classe que a codificação text/XML tradicional ou a codificação binária WCF. O MTOM inclui o seguinte:

Um mecanismo de codificação e empacotamento XML descrito por [XOP] que otimiza itens de informações XML contendo dados binários codificados em base64 em partes binárias separadas.
Um encapsulamento MIME do pacote XOP que serializa o Infoset XML e cada parte binária do pacote XOP em uma parte MIME separada.
Uma codificação MIME XOP aplicada ao envelope SOAP 1.x.
Uma ligação de transporte HTTP.

É possível usar MTOM com transportes não-HTTP com WCF. No entanto, neste tópico vamos nos concentrar em HTTP.

O formato MTOM aproveita um grande conjunto de especificações que abrangem o próprio MTOM, XOP e MIME. A modularidade deste conjunto de especificações torna um pouco difícil reconstruir os requisitos exatos sobre o formato e a semântica de processamento. Esta seção descreve os requisitos de formato e processamento para vinculação HTTP MTOM.

Codificação de mensagens MTOM

Gerando mensagens MTOM

A seção [XOP] 3.1 descreve o processo de codificação XML com itens de informações de elementos que contêm valores base64 em um pacote XOP definido abstratamente.

A sequência de etapas a seguir descreve o processo de codificação específico do MTOM:

Certifique-se de que o envelope SOAP a ser codificado não contenha nenhum elemento de informação com a [namespace name] de http://www.w3.org/2004/08/xop/include e a [local name] de Include.
Crie um pacote MIME vazio.
Identifique no Infoset XML Original os itens de informações do elemento a serem otimizados. Para que os itens sejam otimizados, os caracteres que compõem o [children] item de informações do elemento devem estar na forma canônica de (consulte XSD-2, 3.2.16 base64Binary) e não devem conter caracteres de espaço em branco precedendo, em linha ou seguindo o conteúdo sem xs:base64Binary espaço em branco.
Crie um envelope XOP SOAP que seja uma cópia do envelope SOAP original, mas com os filhos de cada item de informação de elemento identificado na etapa anterior substituídos por um xop:Include item de informação de elemento construído da seguinte maneira:
1. Transforme os caracteres substituídos em dados binários processando-os como dados codificados em base64.
2. Gere um valor de cabeçalho Content-ID exclusivo que satisfaça os requisitos R3133 e R3134.
3. Gere um cabeçalho MIME Content-Transfer-Encoding com o valor binário.
4. Se o item de informações do elemento que está sendo otimizado (o [pai] do item de informações do elemento recém-inserido xop:Include ) tiver um xmime:contentType item de informações de atributo, gere um cabeçalho MIME Content-Type com o valor do xmime:contentType atributo.
5. Gere uma nova parte MIME binária com conteúdo formado por dados binários decodificados dos caracteres substituídos processados como base64, cabeçalho Content-ID de 4b, cabeçalho Content-Transfer-Encoding de 4c, cabeçalho Content-Type se gerado na etapa 4d.
6. Adicione um href atributo ao xop:Include elemento com o valor cid: uri derivado do valor do cabeçalho Content-ID gerado na etapa 4b. Remova os caracteres "<" e ">" que o incluam, escape de URL da cadeia de caracteres restante e adicione o prefixo cid:. O seguinte conjunto mínimo de caracteres deve ser escapado por RFC1738 e RFC2396. Outros personagens podem ser escapados.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
Crie uma parte MIME raiz com o envelope XOP SOAP da etapa 4.
Escreva os cabeçalhos HTTP, incluindo o cabeçalho HTTP Content-Type.
Escreva o pacote MIME.

Processamento de mensagens MTOM

O processamento de uma mensagem MTOM é exatamente o inverso do processo descrito na seção anterior "Gerando mensagens MTOM":

Verifique se a parte MIME raiz tem o Content-Type application/xop+xml.
Construa um envelope SOAP analisando a parte MIME raiz do pacote como um documento XML. A codificação de caracteres é determinada pelo charset parâmetro Content-Type da parte MIME raiz.
Para cada item de informação de elemento no envelope SOAP construído, que tem, como único membro de sua propriedade [filhos], um xop:Include item de informação de elemento:
1. Remova o prefixo cid: e libere todas as sequências de escape de URI (RFC 2396) no valor do @href atributo do xop:Include elemento. Coloque a cadeia de caracteres de resultado em "<", ">".
2. Localize a parte MIME com o valor do cabeçalho Content-ID que corresponde à cadeia de caracteres derivada na etapa 3a.
3. Substitua o xop:Include item de informações do elemento que aparece na children propriedade de cada item pelos itens de informações de caracteres que representam a codificação canônica base64 (consulte XSD-2, 3.2.16 base64Binary) do corpo da entidade da parte MIME identificada na etapa 3b (substitua efetivamente o item de informações do xop:Include elemento pelos dados reconstruídos a partir da parte do pacote).

Cabeçalho de tipo de conteúdo HTTP

A seguir está uma lista de esclarecimentos WCF para o formato do cabeçalho HTTP Content-Type de uma mensagem codificada em MTOM SOAP 1.x derivada de requisitos declarados na própria especificação MTOM e são derivadas de MTOM e RFC 2387.

R4131: Um cabeçalho HTTP Content-Type deve ter o valor de multipart/related (sem distinção entre maiúsculas e minúsculas) e seus parâmetros. Os nomes dos parâmetros não diferenciam maiúsculas de minúsculas. A ordem dos parâmetros não é significativa.
O formulário Backus-Naur (BNF) completo do cabeçalho Content-Type para mensagens MIME está listado no RFC 2045, seção 5.1.
R4132: Um cabeçalho HTTP Content-Type deve ter um parâmetro type com o valor application/xop+xml entre aspas duplas.

Embora o requisito de usar aspas duplas não esteja explícito no RFC 2387, o texto observa que todos os parâmetros de tipo de mídia com várias partes/relacionados provavelmente contêm caracteres reservados como "@" ou "/" e, portanto, precisam de aspas duplas.

R4133: Um cabeçalho HTTP Content-Type deve ter um parâmetro start com o valor do cabeçalho Content-ID da parte MIME que contém o envelope SOAP 1.x, entre aspas duplas. Se o parâmetro start for omitido, a primeira parte MIME deverá conter o envelope SOAP 1.x.
R4134: Um cabeçalho HTTP Content-Type para uma mensagem codificada MTOM SOAP 1.1 deve incluir o parâmetro start-info com o valor de text/xml, entre aspas duplas.
R4135: Um cabeçalho HTTP Content-Type para uma mensagem codificada em MTOM SOAP 1.2 deve incluir o parâmetro start-info com o valor de application/soap+xml, entre aspas duplas.

R4136: O cabeçalho HTTP Content-Type para uma mensagem codificada em MTOM SOAP 1.x deve ter o parâmetro boundary com o valor (entre aspas duplas) que corresponde ao limite MIME BNF definido no RFC 2046, seção 5.1.1

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

Exemplos:

CORRIGIR

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"

CORRIGIR

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

INCORRETO

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

O envelope SOAP 1.x é encapsulado como uma parte raiz do pacote XOP MIME e é frequentemente chamado de infoset parte.

R4141: O envelope SOAP 1.x deve ser encapsulado como uma parte raiz do pacote MIME XOP, chamado de infoset parte e referenciado a partir do HTTP Content-Type.
R4142: A parte SOAP Infoset deve incluir os seguintes cabeçalhos MIME: Content-ID, Content-Transfer-Encoding, e Content-Type.

O formato do cabeçalho Content-ID é definido pelo RFC 2045 como

"Content-ID" ":" msg-id

onde msg-id é definido no RFC 2822 (que substitui o RFC 822, referenciado no RFC 2045) como:

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

e é efetivamente um endereço de e-mail incluído em "<" e ">". O prefixo e o sufixo [CFWS] foram adicionados no RFC 2822 para transportar comentários e não devem ser usados para preservar a interoperabilidade.

R4143: O valor do cabeçalho Content-ID para a parte MIME do Infoset deve seguir msg-id a produção do RFC 2822 com as partes de prefixo e sufixo [CFWS] omitidas.

Uma série de implementações MIME flexibilizou os requisitos para que o valor incluído em "<" e ">" fosse um endereço de e-mail e usado absoluteURI em "<" , ">" além do endereço de e-mail. Esta versão do WCF usa valores do cabeçalho MIME Content-ID do formulário:

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

R4144: Os processadores MTOM devem aceitar valores de cabeçalho Content-ID que correspondam aos seguintes relaxados msg-id.

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

MIME (RFC 2045) fornece o cabeçalho Content-Transfer-Encoding para comunicar a codificação do conteúdo da parte MIME. O padrão definido para Content-Transfer-Encoding é de 7 bits, o que não é adequado para a maioria das mensagens SOAP, portanto, o cabeçalho Content-Transfer-Encoding é necessário para maior interoperabilidade:

R4145: A parte SOAP Infoset deve conter o cabeçalho Content-Transfer-Encoding .
R4146: Se a codificação de caracteres SOAP Envelope for UTF-8, o valor do cabeçalho Content-Transfer-Encoding deve ser de 8 bits.
R4147: Se a codificação de caracteres SOAP Envelope for UTF-16, o valor do cabeçalho Content-Transfer-Encoding deve ser binário.
De acordo com a secção 5 [XOP],
R4148: A parte do Infoset SOAP1.1 deve conter o cabeçalho Content-Type com o tipo de mídia application/xop+xml e os parâmetros type="text/xml" e charset
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: A parte SOAP 1.2 Infoset deve conter o cabeçalho Content-Type com tipo application/xop+xml de mídia e parâmetros type="application/soap+xml" e charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
Embora o XOP defina o charset parâmetro para application/xop+xml ser opcional, ele é necessário para interoperabilidade semelhante ao requisito BP 1.1 no charset parâmetro para o text/xml tipo de mídia.
R41410: Os type parâmetros e charset devem estar presentes no cabeçalho Content-Type da parte SOAP 1.x Infoset.

Suporte de ponto de extremidade WCF para MTOM

O objetivo do MTOM é codificar uma mensagem SOAP para otimizar dados codificados em base64. Segue-se uma lista de restrições:

R4151: Qualquer elemento de informação que contenha dados codificados em base64 pode ser otimizado.
B4152: WCF otimiza itens de informações de elemento que contêm dados codificados em base64 e excedem 1024 bytes de comprimento.

Um ponto de extremidade WCF configurado para usar MTOM sempre enviará mensagens codificadas em MTOM. Mesmo que nenhuma parte atenda aos critérios necessários, a mensagem ainda é codificada em MTOM (serializada como um pacote MIME com uma única parte MIME contendo o envelope SOAP).

WS-Policy Assertion para MTOM

O WCF usa a seguinte declaração de política para indicar o uso de MTOM por ponto de extremidade:

<wsoma:OptimizedMimeSerialization />

R4211: A declaração de política anterior tem um Assunto da Política de Ponto Final e especifica que todas as mensagens enviadas e recebidas do ponto de extremidade devem ser otimizadas usando MTOM.
B4212: Quando configurado para usar a otimização MTOM, um ponto de extremidade WCF adiciona uma asserção de Política MTOM à política anexada ao arquivo .wsdl:binding

Composição com WS-Security

MTOM é um mecanismo de codificação que é semelhante ao text/xml WCF Binary XML. O MTOM oferece composição natural com o WS-Security e outros protocolos WS-*: uma mensagem protegida usando o WS-Security pode ser otimizada usando o MTOM.

Exemplos

WCF SOAP 1.1 mensagem codificada usando 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 mensagem codificada usando MTOM

Neste exemplo, uma mensagem é codificada usando MTOM e SOAP 1.2 que é protegida usando WS-Security. As partes binárias identificadas para codificação são o conteúdo do BinarySecurityToken, CipherValue do EncryptedData correspondente à assinatura criptografada e ao corpo criptografado. Observe que o CipherValue do EncryptedKey não foi identificado para otimização pelo WCF, porque seu comprimento é inferior a 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--

Partilhar via

Protocolos de mensagens

SABONETE 1.1 e SABONETE 1.2

Envelope e Modelo de Processamento

Processamento obrigatório de cabeçalhos

Falhas SOAP

Vinculação HTTP

Vinculação HTTP SOAP 1.1

Ligação HTTP SOAP 1.2

WS-Endereçamento

Referências de pontos finais

Referências de ponto de extremidade e versões WS-Addressing

Referências e metadados de pontos finais

Cabeçalhos de endereçamento de mensagens

Cabeçalhos de mensagens

Parâmetros de referência e propriedades

Padrões de troca de mensagens

Mensagem unidirecional

Pedido-Resposta

Falhas de endereçamento de serviços Web

WSDL 1.1 Vinculação e asserções WS-Policy

Indicando o uso do WS-Addressing

Definição de ação

Usar referência de ponto de extremidade dentro da porta WSDL

Composição com WS-Security

Exemplos

Mensagem unidirecional

Mecanismo de otimização da transmissão de mensagens SOAP

Codificação de mensagens MTOM

Gerando mensagens MTOM

Processamento de mensagens MTOM

Cabeçalho de tipo de conteúdo HTTP

Infoset Parte MIME

Suporte de ponto de extremidade WCF para MTOM

WS-Policy Assertion para MTOM

Composição com WS-Security

Exemplos

WCF SOAP 1.1 mensagem codificada usando MTOM

WCF Secure SOAP 1.2 mensagem codificada usando MTOM

Recursos adicionais