Compartir a través de

Protocolos de mensajería

La pila de canales de Windows Communication Foundation (WCF) emplea canales de codificación y transporte para transformar la representación interna del mensaje en su formato de línea y enviarlo utilizando un transporte específico. El transporte más común usado para la interoperabilidad de servicios web es HTTP y las codificaciones más comunes usadas por los servicios web son SOAP 1.1, SOAP 1.2 y Mecanismo de optimización de transmisión de mensajes (MTOM) basado en XML.

En este tema se tratan los detalles de implementación de WCF para los siguientes protocolos empleados por HttpTransportBindingElement.

Especificación/documento:

En este tema se tratan los detalles de implementación de WCF para los siguientes protocolos que emplean TextMessageEncodingBindingElement y MtomMessageEncodingBindingElement .

Especificación/documento:

En este tema se tratan los detalles de implementación de WCF para los siguientes protocolos que MtomMessageEncodingBindingElement emplean.

Especificación/documento:

En este tema se usan los siguientes espacios de nombres XML y prefijos asociados:

Prefijo Espacio de nombres de identificador uniforme de recursos (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 y SOAP 1.2

Modelo de procesado y envoltura

WFC implementa el procesado de envoltura SOAP 1.1 siguiendo Perfil básico 1.1 (BP11) y Perfil básico 1.0 (SSBP10). El procesamiento de envelopes SOAP 1.2 se implementa siguiendo SOAP12-Part1.

En esta sección se explican ciertas opciones de implementación tomadas por WCF con respecto a BP11 y SOAP12-Part1.

Procesamiento obligatorio de encabezados

WCF sigue las reglas para procesar encabezados marcados mustUnderstand como descritos en las especificaciones SOAP 1.1 y SOAP 1.2, con las siguientes variaciones.

Un mensaje que entra en la pila de canales WCF se procesa mediante canales individuales configurados por elementos de enlace asociados, por ejemplo, Codificación de mensajes de texto, Seguridad, Mensajería confiable y Transacciones. Cada canal reconoce los encabezados del espacio de nombres asociado y los marca como se entiende. Una vez que un mensaje entra en el distribuidor, el formateador de la operación lee los encabezados esperados por el contrato de mensaje o de operación correspondiente y los marca como comprendidos. A continuación, el manejador verifica si hay encabezados restantes que no se entienden pero están marcados como mustUnderstand, y lanza una excepción. El código de la aplicación del destinatario no procesa los mensajes que contienen mustUnderstand encabezados destinados al destinatario.

Este procesamiento en capas permite la separación entre las capas de infraestructura y las capas de aplicación del nodo SOAP:

  • B1111: los encabezados que no se entienden se detectan después de que la pila de canales de infraestructura de WCF procese el mensaje, pero antes de que la aplicación lo procese.

    El mustUnderstand valor del encabezado difiere entre SOAP 1.1 y SOAP 1.2. El perfil básico 1.1 requiere que el mustUnderstand valor sea 0 o 1 para los mensajes SOAP 1.1. SOAP 1.2 permite 0, 1, falsey true como valores, pero recomienda emitir una representación canónica de xs:boolean valores (false, true).

  • B1112: WFC emite valores 0 y 1 de mustUnderstand para las dos versiones de SOAP 1.1 y SOAP 1.2 del sobre SOAP. WCF acepta el espacio de valor completo de xs:boolean para el mustUnderstand encabezado (0, 1, false, true)

Errores de SOAP

A continuación se muestra una lista de implementaciones de errores SOAP específicas de WCF.

  • B2121: WCF devuelve los siguientes códigos de error soap 1.1: s11:mustUnderstand, s11:Clienty s11:Server.

  • B2122: WCF devuelve los siguientes códigos de error soap 1.2: s12:MustUnderstand, s12:Sendery s12:Receiver.

Enlace HTTP

Enlace HTTP de SOAP 1.1

WCF implementa el enlace HTTP SOAP1.1 siguiendo la sección 3.4 de especificación de perfil básico 1.1 con las siguientes aclaraciones:

  • B2211: el servicio WCF no implementa el redireccionamiento de solicitudes HTTP POST.

  • B2212: los clientes WCF admiten cookies HTTP de acuerdo con la versión 3.4.8.

Enlace HTTP de SOAP 1,2

WCF implementa el enlace HTTP SOAP 1.2 como se describe en la especificación SOAP 1.2-part 2 (SOAP12Part2) con las siguientes aclaraciones.

SOAP 1.2 introdujo un parámetro de acción opcional para el tipo de application/soap+xml medio. Este parámetro es útil para optimizar el envío de mensajes sin necesidad de que el cuerpo del mensaje SOAP se analice cuando no se use WS-Addressing.

  • R2221: El parámetro de acción application/soap+xml, cuando está presente en una solicitud SOAP 1.2, debe coincidir con el atributo soapAction en el elemento dentro del enlace WSDL wsoap12:operation correspondiente.

  • R2222: el application/soap+xml parámetro de acción, cuando está presente en un mensaje SOAP 1.2, debe coincidir wsa:Action cuando se usen WS-Addressing 2004/08 o WS-Addressing 1.0.

Cuando WS-Addressing está deshabilitado y una solicitud entrante no contiene un parámetro de acción, el mensaje Action se considera no especificado.

WS-Addressing

WCF implementa tres versiones de WS-Addressing:

  • WS-Addressing 2004/08

  • W3C Web Services Addressing 1.0 Core (ADDR10-CORE) y SOAP Binding (ADDR10-SOAP)

  • WS-Addressing 1.0: metadatos

Referencias de punto de conexión

Todas las versiones de WS-Addressing que WCF implementa usan referencias de punto de conexión para describir los puntos de conexión.

Referencias de punto de conexión y WS-Addressing

WCF implementa una serie de protocolos de infraestructura que utilizan WS-Addressing y, en particular, el EndpointReference elemento y la W3C.WsAddressing.EndpointReferenceType clase (por ejemplo, WS-ReliableMessaging, WS-SecureConversation y WS-Trust). WCF admite el uso de cualquiera de las versiones de WS-Addressing con otros protocolos de infraestructura. Los puntos de conexión de WCF admiten una versión de WS-Addressing por punto de conexión.

Para R3111, el espacio de nombres del elemento o tipo EndpointReference usado en los mensajes intercambiados con un punto de conexión WCF debe coincidir con la versión de WS-Addressing implementada por este.

Por ejemplo, si un punto de conexión de WCF implementa WS-ReliableMessaging, la cabecera AcksTo devuelta por dicho punto de conexión dentro de CreateSequenceResponse utiliza la versión WS-Addressing que el elemento EncodingBinding especifica para este punto de conexión.

Referencias y metadatos del punto de conexión

Varios escenarios requieren la comunicación de metadatos o una referencia a metadatos para un punto de conexión determinado.

B3121: WFC emplea mecanismos descritos en la especificación de WS-MetadataExchange (MEX), sección 6, para incluir metadatos para referencias de puntos de conexión por valor o referencia.

Considere un escenario en el que un servicio WCF requiere autenticación mediante un token de lenguaje de marcado de aserciones de seguridad (SAML) emitido por el emisor de tokens en http://sts.fabrikam123.com. El punto de conexión de WCF describe este requisito de autenticación mediante la aserción sp:IssuedToken, que incluye una aserción anidada sp:Issuer que apunta al emisor del token. Las aplicaciones cliente que acceden a la sp:Issuer aserción necesitan saber cómo comunicarse con el punto de conexión del emisor de tokens. El cliente debe conocer los metadatos sobre el emisor de tokens. Con las extensiones de metadatos de referencia de punto de conexión definidas en MEX, WCF proporciona una referencia a los metadatos del emisor de tokens.

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

Encabezados de direccionamiento de mensajes

Encabezados de mensaje

Para ambas versiones de WS-Addressing, WCF usa los siguientes encabezados de mensaje según lo indicado por las especificaciones wsa:To, wsa:ReplyTo, wsa:Action, y wsa:MessageIDwsa:RelatesTo.

B3211: para todas las versiones de WS-Addressing, WFC se ajusta a los encabezados de mensajes WS-Addressing wsa:FaultTo y wsa:From, pero no los genera inmediatamente.

Las aplicaciones que interactúan con las aplicaciones WCF pueden agregar estos encabezados de mensaje y WCF los procesará en consecuencia.

Parámetros y propiedades de referencia

WCF implementa el procesamiento de parámetros de referencia de punto de conexión y propiedades de referencia de acuerdo con las especificaciones respectivas.

B3221: cuando se configura para usar WS-Addressing 2004/08, los puntos de conexión de WCF no diferencian entre el procesamiento de propiedades de referencia y los parámetros de referencia.

Patrones de Intercambio de mensajes

La secuencia de mensajes implicados en la invocación de la operación de servicio web se conoce como patrón de intercambio de mensajes. WCF admite patrones de intercambio de mensajes unidireccionales, de solicitud-respuesta y dúplex. En esta sección se aclaran los requisitos del WS-Addressing sobre el procesamiento de mensajes dependiendo del patrón de intercambio de mensajes que se use.

En esta sección, el solicitante envía el primer mensaje y el respondedor recibe el primer mensaje.

Mensaje unidireccional

Cuando se configura un punto de conexión WCF para admitir mensajes con un determinado Action para seguir un patrón unidireccional, el punto de conexión WCF sigue los siguientes comportamientos y requisitos. A menos que se especifique lo contrario, los comportamientos y las reglas se aplican a ambas versiones de WS-Addressing compatibles con WCF:

  • R3311: El solicitante debe incluir wsa:To, wsa:Action y encabezados para todos los parámetros de referencia especificados por la referencia del punto de conexión. Cuando se usa WS-Addressing 2004/08 y [propiedades de referencia] se especifican mediante la referencia del punto de conexión, también se deben agregar los encabezados correspondientes al mensaje.

  • B3312: El solicitante puede incluir los encabezados MessageID, ReplyTo y FaultTo. La infraestructura del receptor las omitirá y se pasarán a la aplicación.

  • R3313: cuando se usa HTTP y no se envía ningún mensaje en el segmento de respuesta HTTP, el respondedor debe enviar una respuesta HTTP con un cuerpo vacío y un código de estado HTTP 202.

    Cuando el transporte HTTP está en uso y el contrato de operación declara un mensaje unidireccional, la respuesta HTTP todavía se puede usar para enviar mensajes de infraestructura; por ejemplo, la mensajería confiable puede enviar un SequenceAcknowledgement mensaje en una respuesta HTTP.

  • B3314: el respondedor WCF no envía un mensaje de error en respuesta a un mensaje unidireccional.

Solicitud-respuesta

Cuando se configura un punto de conexión WCF para un mensaje con un determinado Action para seguir el patrón de solicitud-respuesta, el punto de conexión WCF sigue los comportamientos y requisitos siguientes. A menos que se especifique lo contrario, los comportamientos y las reglas se aplican a ambas versiones de WS-Addressing compatibles con WCF:

  • R3321: El solicitante debe incluir en la solicitud los encabezados wsa:To, wsa:Action, wsa:MessageID, y todos los parámetros de referencia o propiedades de referencia (o ambos) especificados por la referencia del punto de conexión.

  • R3322: Cuando se usa WS-Addressing 2004/08, ReplyTo también debe incluirse en la solicitud.

  • R3323: cuando se usa WS-Addressing 1.0 y ReplyTo no está presente en la solicitud, se usa una referencia de punto de conexión predeterminada con la propiedad [address] igual a http://www.w3.org/2005/08/addressing/anonymous .

  • R3324: El solicitante debe incluir encabezados wsa:To, wsa:Action, y wsa:RelatesTo en el mensaje de respuesta, así como encabezados para todos los parámetros de referencia o propiedades de referencia (o ambos) especificados por la referencia de punto de conexión ReplyTo en la solicitud.

Errores de direccionamiento de servicios Web

R3411: WCF genera los siguientes errores definidos por WS-Addressing 2004/08.

Código Causa
wsa:DestinationUnreachable El mensaje llegó con un ReplyTo diferente a la dirección de respuesta establecida para este canal; no hay ningún punto de conexión que escuche en la dirección especificada en el encabezado To.
wsa:ActionNotSupported los canales de infraestructura o el distribuidor asociados al punto de conexión no reconocen la acción especificada en el encabezado Action.

R3412: WCF genera los siguientes errores definidos por WS-Addressing 1.0.

Código Causa
wsa10:InvalidAddressingHeader Duplicado de wsa:To, wsa:ReplyTo, wsa:From o wsa:MessageID. Duplica wsa:RelatesTo con el mismo RelationshipType.
wsa10:MessageAddressingHeaderRequired Falta el encabezado Addressing necesario.
wsa10:DestinationUnreachable El mensaje llegó con un ReplyTo que es diferente de la dirección de respuesta establecida para este canal. No hay ningún punto de conexión escuchando en la dirección especificada en encabezado To.
wsa10:ActionNotSupported Los canales de infraestructura o el distribuidor asociados al punto de conexión no reconocen una acción especificada en el encabezado Action.
wsa10:EndpointUnavailable El canal RM devuelve este error, indicando que el extremo no procesará la secuencia basada en el examen de los encabezados de direccionamiento del mensaje CreateSequence.

El código de las tablas anteriores se asigna a FaultCode en SOAP 1.1 y SubCode (con Code=Sender) en SOAP 1.2.

Enlace WSDL 1.1 y aserciones de WS-Policy

Indicación del uso de WS-Addressing

WCF utiliza las aserciones de directivas para indicar la compatibilidad de punto de conexión para una versión particular de WS-Addressing.

La siguiente aserción de directiva tiene Asunto de directiva de extremo [WS PA] e indica que los mensajes enviados y recibidos desde el extremo deben utilizar WS-Addressing 2004/08.

<wsap:UsingAddressing />

Esta afirmación de política amplía la especificación WS-Addressing 2004/08.

La siguiente aserción de directiva indica que los mensajes enviados o recibidos deben usar WS-Addressing 1.0.

<wsam:Addressing/>

La siguiente declaración de política tiene un tema de política de punto de conexión [WS-PA] e indica que los mensajes enviados y recibidos del punto de conexión deben utilizar WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

El wsaw10:UsingAddressing elemento se toma prestado de [WS-Addressing-WSDL] y se usa en el contexto de WS-Policy conforme a esa especificación, sección 3.1.2.

El uso de direccionamiento no modifica la semántica de los enlaces HTTP de WSDL 1.1, SOAP 1.1 y SOAP 1.2. Por ejemplo, si se espera una respuesta a una solicitud que se envía a un punto de conexión que usa direccionamiento y enlace HTTP SOAP 1.x de WSDL, la respuesta debe enviarse mediante la respuesta HTTP.

En el caso de las respuestas enviadas por http, la aserción WS-AM es:

<wsam:AnonymousResponses/>

La aserción de directiva completa podría tener este aspecto:

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

Sin embargo, hay patrones de intercambio de mensajes que se benefician de tener dos conexiones HTTP inversas independientes establecidas entre el solicitante y el respondedor, por ejemplo, mensajes unidireccionales no solicitados enviados por el respondedor.

WCF ofrece una característica por la que dos canales de transporte subyacentes pueden formar un canal dúplex compuesto, donde se usa un canal para los mensajes de entrada y el otro para los mensajes de salida. En el caso del transporte HTTP, Composite Duplex proporciona dos conexiones HTTP de ida y vuelta. El solicitante usa una conexión para enviar mensajes al respondedor y el respondedor usa el otro para devolver mensajes al solicitante.

En el caso de las respuestas enviadas a través de solicitudes HTTP independientes, la aserción de ws-am es

<wsam:NonAnonymousResponses/>

La aserción de directiva completa podría tener este aspecto:

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

El uso de la siguiente aserción que tiene un asunto de extremo de directiva [WS-PA] en los extremos que usan enlaces HTTP de SOAP 1.1x de WDSL 1.1 requiere dos conexiones HTTP inversas independientes que se utilizarán para los mensajes que fluyen del solicitante al respondedor y del respondedor al solicitante, respectivamente.

<cdp:CompositeDuplex/>

La declaración anterior conduce a los siguientes requisitos en el encabezado wsa:ReplyTo para los mensajes de solicitud:

  • R3514: Los mensajes de solicitud enviados a un punto de conexión deben tener un ReplyTo encabezado con la [address] propiedad no igual a http://www.w3.org/2005/08/addressing/anonymous si el punto de conexión usa un enlace HTTP SOAP 1.1 de WSDL 1.x y tiene una alternativa de directiva con una wsap10:UsingAddressing o wsap:UsingAddressing aserción acoplada con cdp:CompositeDuplex asociada.

  • R3515: Los mensajes de solicitud enviados a un punto de conexión deben tener un ReplyTo encabezado con la [address] propiedad igual a http://www.w3.org/2005/08/addressing/anonymous, o no tener un ReplyTo encabezado en absoluto, si el punto de conexión usa un enlace HTTP de SOAP 1.x WSDL 1.x y tiene una alternativa de directiva con wsap10:UsingAddressing aserción y ninguna cdp:CompositeDuplex aserción adjunta.

  • R3516: Los mensajes de solicitud enviados a un punto de conexión deben tener un encabezado ReplyTo cuya propiedad [address] es igual a http://www.w3.org/2005/08/addressing/anonymous si el punto de conexión utiliza un enlace HTTP SOAP 1.1 WSDL 1.x y tiene una alternativa de política con la aserción wsap:UsingAddressing y sin la aserción cdp:CompositeDuplex adjunta.

La especificación WS-addressing WSDL intenta describir enlaces de protocolo similares mediante la introducción de un elemento <wsaw:Anonymous/> con tres valores textuales (requeridos, opcionales y prohibidos) para indicar los requisitos en la cabecera wsa:ReplyTo (sección 3.2). Desafortunadamente, esta definición de elemento no se puede usar especialmente como aserción en el contexto de WS-Policy, ya que requiere extensiones específicas del dominio para admitir la intersección de alternativas mediante dicho elemento como aserción. Tal definición de elemento también indica el valor del encabezado ReplyTo frente al comportamiento del extremo en la conexión, que lo hace específico para el transporte HTTP.

Definición de acción

WS-Addressing 2004/08 define un wsa:Action atributo para los wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elementos. El enlace ESDL de WS-Addressing 1.0 (WS-ADDR10-WSDL) define un atributo similar, wsaw10:Action.

La única diferencia entre los dos es la semántica predeterminada del patrón de acción descrita en la sección 3.3.2 de WS-ADDR y la sección 4.4.4 de WS-ADDR10-WSDL, respectivamente.

Es razonable tener dos puntos de conexión que compartan el mismo portType (o contrato, en terminología de WCF), pero que usen versiones diferentes de WS-Addressing. Pero dado que Action está definido por portType y no debe cambiar entre los puntos de conexión que implementan portType, resulta imposible admitir ambos patrones de acción predeterminados.

Para resolver esta controversia, WCF admite una sola versión del Action atributo .

B3521: WCF usa el atributo wsaw10:Action en los elementos wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault], tal como se define en WS-ADDR10-WSDL, para determinar el URI Action de los mensajes correspondientes independientemente de la versión de WS-Addressing utilizada por el punto de conexión.

Uso de la referencia de extremo dentro del puerto WSDL

La sección 4.1 de WS-ADDR10-WSDL extiende el elemento wsdl:port para incluir el elemento secundario <wsa10:EndpointReference…/> para describir el punto de conexión en términos de WS-Addressing. WCF expande esta utilidad en WS-Addressing 2004/08, lo que permite <wsa:EndpointReference…/> aparecer como un elemento secundario de wsdl:port.

  • R3531: si un punto de conexión tiene una directiva alternativa adjunta con una aserción de directiva <wsaw10:UsingAddressing/>, el elemento wsdl:port correspondiente puede contener un elemento secundario <wsa10:EndpointReference …/>.

  • R3532: Si un wsdl:port contiene un elemento <wsa10:EndpointReference …/> secundario, el valor del elemento secundario wsa10:EndpointReference/wsa10:Address debe coincidir con el valor del atributo @address del elemento hermano wsdl:port/wsdl:location.

  • R3533: si un punto de conexión tiene una directiva alternativa adjunta con una aserción de directiva <wsap:UsingAddressing/>, el elemento wsdl:port correspondiente puede contener un elemento secundario <wsa:EndpointReference …/>.

  • R3534: Si un wsdl:port contiene un elemento hijo <wsa:EndpointReference …/>, el valor del elemento hijo wsa:EndpointReference/wsa:Address debe coincidir con el valor del atributo @address del elemento hermano wsdl:port/wsdl:location.

Composición con WS-Security

Según las secciones de consideración de seguridad de WS-ADDR y WS-ADDR10, se recomienda que todos los encabezados de mensaje de direccionamiento se firmen junto con el cuerpo del mensaje para enlazarlos juntos.

Cuando se usa WS-Security para la protección de integridad de mensajes, WS-Addressing encabezados de mensaje, así como encabezados resultantes de parámetros o propiedades de referencia (o ambos) deben estar firmados junto con el cuerpo del mensaje.

Ejemplos

Mensaje unidireccional

En este escenario, el remitente envía un mensaje unidireccional al receptor. Se usan SOAP 1.2, HTTP 1.1 y W3C WS-Addressing 1.0.

Estructura del mensaje de solicitud: los encabezados del mensaje incluyen wsa10:To elementos y wsa10:Action . El cuerpo del mensaje incluye un elemento específico <app:Ping> del espacio de nombres de la aplicación.

Encabezados HTTP: el destino de POST coincide con el URI del wsa10:To elemento .

El encabezado Content-Type tiene el valor de application/soap+xml según sea necesario en SOAP 1.2. Se incluyen parámetros charset y action . El action parámetro del encabezado Content-Type coincide con el valor del encabezado del wsa10:Action mensaje.

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>

El receptor responde con una respuesta HTTP vacía y el estado 202. Ejemplo de la respuesta 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 optimización de transmisión de mensajes SOAP

En esta sección se describen los detalles de implementación de WCF para el MTOM de SOAP HTTP. La tecnología MTOM es un mecanismo de codificación de mensajes SOAP de la misma clase que la codificación de texto/XML tradicional o la codificación binaria WCF. MTOM incluye lo siguiente:

  • Un mecanismo de codificación y empaquetado XML descrito por [XOP] que optimiza los elementos de información XML que contienen datos binarios codificados en base64 en partes binarias independientes.

  • Una encapsulación MIME del paquete XOP que serializa el conjunto de información XML y cada parte binaria del paquete XOP en una parte MIME independiente.

  • Una codificación XOP MIME aplicada a la envoltura de SOAP 1.x.

  • Un enlace de transporte HTTP.

Es posible usar MTOM con transportes que no son HTTP con WCF. Sin embargo, en este tema nos centraremos en HTTP.

El formato MTOM aprovecha un gran conjunto de especificaciones que abarcan MTOM, XOP y MIME. La modularidad de este conjunto de especificaciones hace que sea algo difícil reconstruir los requisitos exactos en la semántica de formato y procesamiento. En esta sección se describen los requisitos de formato y procesamiento para el enlace HTTP MTOM.

Codificación de mensajes MTOM

Generación de mensajes MTOM

La sección [XOP] 3.1 describe el proceso de codificación XML con elementos de información de elementos que contienen valores base64 en un paquete XOP definido de forma abstracta.

En la siguiente secuencia de pasos se describe el proceso de codificación específico de MTOM:

  1. Asegúrese de que la envoltura de SOAP que se va a codificar no contiene ningún elemento de información de elemento con un [namespace name] de http://www.w3.org/2004/08/xop/include y un [local name] de Include.

  2. Cree un paquete MIME vacío.

  3. Identifique dentro del conjunto de información XML original los elementos de información del elemento que se van a optimizar. Para que los elementos se optimicen, los caracteres que componen el [children] elemento de información del elemento deben estar en la forma canónica de xs:base64Binary (vea XSD-2, 3.2.16 base64Binary) y no deben contener ningún carácter de espacio en blanco anterior, alineado con o siguiendo el contenido que no es de espacio en blanco.

  4. Cree una envoltura SOAP de XOP que sea una copia de la envoltura SOAP original, pero con los elementos secundarios de cada elemento de información de elemento identificados en el paso anterior reemplazados por un elemento de información de elemento xop:Include construido de la siguiente manera:

    1. Transforme los caracteres reemplazados en datos binarios procesandolos como datos codificados en base64.

    2. Genere un valor de encabezado Content-ID único que cumpla los requisitos R3133 y R3134.

    3. Genere un encabezado MIME de codificación de transferencia del contenido con el valor binario.

    4. Si el elemento de información que se está optimizando (el [elemento padre] del nuevo elemento de información xop:Include insertado) tiene un elemento de información de atributo xmime:contentType, genere un encabezado MIME de tipo de contenido con el valor del atributo xmime:contentType.

    5. Genere una nueva parte MIME binaria con contenido formado por datos binarios descodificados a partir de los caracteres reemplazados procesados como base64, encabezado del Content-ID de 4b, encabezado de codificación de transferencia de contenido de 4c, encabezado de tipo de contenido si se generó en el paso 4d.

    6. Agregue un href atributo al xop:Include elemento con el valor cid: URI derivado del valor del encabezado Content-ID generado en el paso 4b. Elimine los caracteres envolventes "<" and ">" , agregue caracteres de escape de URL a la cadena restante y agregue el prefijo cid:. El juego de caracteres mínimo siguiente se exige para que RFC1738 y RFC2396 puedan escapar. Se pueden escapar otros caracteres.

      Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"

  5. Cree una parte MIME de raíz con la envoltura SOAP de XOP a partir del paso 4.

  6. Escriba los encabezados HTTP, incluido el encabezado Tipo de contenido HTTP.

  7. Escriba el paquete MIME.

Procesamiento de mensajes MTOM

El procesamiento de un mensaje MTOM es la inversa exacta del proceso descrito en la sección anterior "Generar mensajes MTOM":

  1. Asegúrese de que el elemento MIME raíz tiene el tipo application/xop+xmlde contenido .

  2. Construya un sobre SOAP mediante el análisis de la parte MIME raíz del paquete como un documento XML. La codificación de caracteres viene determinada por el charset parámetro del Content-Type del elemento MIME raíz.

  3. Para cada elemento de información de elemento en la envoltura SOAP construida, que tiene, como único miembro de su propiedad [elemento secundario], un elemento de información de elemento xop:Include:

    1. Elimine el prefijo cid: y quite los caracteres de escape de todas las secuencias de escape de URI (RFC 2396) en el valor del atributo @href del elemento xop:Include. Incluya la cadena de resultado en "<", ">".

    2. Busque el elemento MIME con el valor del encabezado Content-ID que coincida con la cadena derivada en el paso 3a.

    3. Reemplace el elemento de información xop:Include que aparece en la propiedad children de cada elemento por los elementos de información de caracteres que representan la codificación canónica base64 (vea XSD-2, 3.2.16 base64Binary) del contenido de la entidad del elemento MIME identificado en el paso 3b (efectivamente reemplace el elemento de información xop:Include por los datos reconstruidos a partir de la parte del paquete).

Encabezado de tipo de contenido HTTP

A continuación se muestra una lista de aclaraciones de WCF para el formato del encabezado HTTP Content-Type de un mensaje codificado en SOAP 1.x MTOM derivado de los requisitos indicados en la propia especificación MTOM y se derivan de MTOM y RFC 2387.

  • R4131: un encabezado de tipo de contenido HTTP debe tener el valor de multiparte/relacionado (sin distinción entre mayúsculas y minúsculas) y sus parámetros. Los nombres de parámetros no distinguen mayúsculas de minúsculas. El orden de los parámetros no es significativo.

  • Se enumera la forma de Backus-Naur completa (BNF) del encabezado de tipo de contenido para los mensajes MIME en RFC 2045, sección 5.1.

  • R4132: Un encabezado HTTP Content-Type debe tener un parámetro de tipo con el valor application/xop+xml entre comillas dobles.

Aunque el requisito de usar comillas dobles no es explícito en RFC 2387, el texto observa que todos los parámetros de tipo multimedia multipart/relacionado probablemente contienen caracteres reservados como "@" o "/" y, por lo tanto, necesitan comillas dobles.

  • R4133: Un encabezado HTTP Content-Type debe tener un parámetro `start` con el valor del encabezado Content-ID de la parte MIME que contiene la envoltura SOAP 1.x, encerrado entre comillas dobles. Si se omite el parámetro start, la primera parte MIME debe contener el envelope SOAP 1.x.

  • R4134: un encabezado HTTP Content-Type para un mensaje codificado en SOAP 1.1 MTOM debe incluir el parámetro start-info con el valor de text/xml, entre comillas dobles.

  • R4135: un encabezado HTTP Content-Type para un mensaje codificado con SOAP 1.2 MTOM debe incluir el parámetro start-info con el valor de application/soap+xml, entre comillas dobles.

  • R4136: encabezado de tipo de contenido HTTP para un mensaje codificado en MTOM de SOAP 1.x debe tener el parámetro de límite con el valor (encerrado entre comillas tipográficas) que coincide con el BNF limitador de MIME definido en RFC 2046, sección 5.1.1

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

    Ejemplos:

    CORRECTO

    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"

    CORRECTO

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

    INCORRECTO

    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 del conjunto de información de MIME

La envoltura SOAP 1.x se encapsula como parte raíz del paquete MIME XOP y a menudo se denomina parte infoset.

  • R4141: El sobre SOAP 1.x se debe encapsular como parte raíz del paquete MIME XOP, denominado elemento infoset y al que se hace referencia desde el tipo de contenido HTTP.

  • R4142: La parte SOAP Infoset debe incluir los siguientes encabezados MIME: Content-ID, Content-Transfer-Encodingy Content-Type.

El formato del encabezado Content-ID se define mediante RFC 2045 como

"Content-ID" ":" msg-id

donde msg-id se define en RFC 2822 (que sustituye a RFC 822, al que se hace referencia en RFC 2045) como:

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

y es efectivamente una dirección de correo electrónico encerrada entre "<" y ">". El [CFWS] prefijo y el sufijo se agregaron en RFC 2822 para llevar comentarios y no deben usarse para conservar la interoperabilidad.

R4143: el valor del encabezado Content-ID para la parte MIME del conjunto de información debe seguir la producción msg-id de RFC 2822 con las partes de prefijo y sufijo [CFWS] omitidas.

Una serie de implementaciones de MIME reducen los requisitos para que el valor incluido en "<" y ">" sea una dirección de correo electrónico y se use absoluteURI entre "<", ">" además de la dirección de correo electrónico. Esta versión de WFC usa valores de encabezado MIME del identificador de contenido con el formato:

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

R4144: los procesadores MTOM deberían aceptar valores de encabezado de id. de contenido que coincidan con el siguiente msg-id relajado.

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

MIME (RFC 2045) proporciona el encabezado Content-Transfer-Encoding para comunicar la codificación del contenido del elemento MIME. El valor predeterminado definido para Content-Transfer-Encoding es de 7 bits, que no es adecuado para la mayoría de los mensajes SOAP, por lo que el encabezado Content-Transfer-Encoding es necesario para una mayor interoperabilidad:

  • R4145: la parte del conjunto de información de SOAP debe contener el encabezado de codificación de transferencia de contenido.

  • R4146: Si la codificación de caracteres de la envelope SOAP es UTF-8, el valor del encabezado Content-Transfer-Encoding debe ser de 8 bits.

  • R4147: Si la codificación de caracteres del sobre de SOAP es UTF-16, el valor del encabezado Content-Transfer-Encoding debe ser binario.

  • Según la sección 5 de [XOP],

  • R4148: La parte del infoset SOAP 1.1 debe contener el encabezado Content-Type con el tipo de medio application/xop+xml y los parámetros type="text/xml" y charset

    Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"

  • R4149: la parte del conjunto de información de SOAP 1.2 debe contener el encabezado de tipo de contenido con el tipo de medio application/xop+xml y los parámetros type=" application/soap+xml" y charset.

    Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"

    Aunque XOP define que el parámetro charset para application/xop+xml sea opcional, es necesario para la interoperabilidad similar al requisito de BP 1.1 en el parámetro charset para el tipo de medio text/xml.

  • R41410: Los parámetros type y charset deben estar presentes en el encabezado "Content-Type" de la parte Infoset de SOAP 1.x.

Compatibilidad de punto de conexión WCF para MTOM.

El propósito de MTOM es codificar un mensaje SOAP para optimizar los datos codificados en base64. A continuación se muestra una lista de restricciones:

  • R4151: cualquier elemento de información de elemento que contenga datos codificados en base64 se puede optimizar.

  • B4152: WCF optimiza los elementos de información que contienen datos codificados en base64 y superan los 1024 bytes de longitud.

Un punto de conexión WCF configurado para usar MTOM siempre enviará mensajes codificados con MTOM. Incluso si no hay elementos que cumplan los criterios necesarios, el mensaje todavía está codificado en MTOM (serializado como un paquete MIME con una sola parte MIME que contiene el sobre SOAP).

Aserción de la WS-Policy para MTOM

WCF usa la siguiente aserción de directiva para indicar el uso de MTOM por punto de conexión:

<wsoma:OptimizedMimeSerialization />

  • R4211: la aserción de directiva anterior tiene un asunto de directiva de punto de conexión y especifica que todos los mensajes enviados y recibidos desde el punto de conexión deben optimizarse mediante MTOM.

  • B4212: cuando se configura para utilizar la optimización de MTOM, un punto de conexión de WCF agrega una aserción de directiva MTOM a la directiva adjunta al correspondiente wsdl:binding.

Composición con WS-Security

MTOM es un mecanismo de codificación similar a text/xml y XML binario de WCF. MTOM ofrece composición natural con WS-Security y otros protocolos WS-*: un mensaje protegido mediante WS-Security se puede optimizar mediante MTOM.

Ejemplos

Mensaje SOAP 1.1 de WCF codificado mediante 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

Mensaje seguro de SOAP 1.2 de WCF codificado mediante MTOM

En este ejemplo, un mensaje se codifica mediante MTOM y SOAP 1.2 que está protegido mediante WS-Security. Las partes binarias identificadas para la codificación son los contenidos de BinarySecurityToken y CipherValue del EncryptedData correspondiente a la firma cifrada y al cuerpo cifrado. Tenga en cuenta que el CipherValue de la EncryptedKey no se identificó para la optimización por WCF, porque su longitud es 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--