Mecanismo de optimización de transmisión de mensajes

MTOM (Message Transmission Optimization Mechanism) de SOAP es un estándar desarrollado por W3C (World Wide Web Consortium). MTOM describe un mecanismo para optimizar el formato de cable o transmisión de un mensaje SOAP, recodificando de forma selectiva partes del mensaje a la vez que se representa un conjunto de información XML (Infoset) en la aplicación SOAP.

Existen varios motivos por los que puede enviar documentos adjuntos binarios como, por ejemplo, imágenes o archivos, con una solicitud de servicios web. Puede hacerlo de las siguientes formas:
  • Mediante la codificación con base64 en línea en la carga SOAP. No obstante, la codificación en línea suele aumentar el tamaño del mensaje SOAP. Tenga en cuenta que la codificación base64 puede duplicar el tamaño de los datos binarios.
  • Codificando los mensajes mediante el uso de SwA (SOAP with Attachments) y cumpliendo Web Services Interoperability Organization (WS-I) Attachments Profile. WebSphere Application Server da soporte actualmente a este método.
  • Mediante la optimización del transporte de mensajes binarios utilizando XOP (XML-binary Optimized Packaging). La optimización sólo está disponible para el contenido y los datos binarios. MTOM utiliza XOP en el contexto de SOAP y MIME sobre HTTP.

XOP define un mecanismo de serialización para el Infoset XML con contenido binario que no sólo es aplicable a los paquetes SOAP y MIME, sino a cualquier Infoset XML y cualquier mecanismo de empaquetado. Es una serialización alternativa de XML que tiene el mismo aspecto que un paquete compuesto de varias partes MIME relacionadas, con un documento XML como parte raíz. La parte raíz es muy parecida a la serialización XML del documento, excepto que los datos codificados en base64 se sustituyen por una referencia a una de las partes MIME, que no está codificada en base64. Esta referencia permite evitar la sobrecarga y el exceso de proceso que se asocia con la codificación. La codificación es la única forma de que los datos binarios puedan entrar directamente en el mundo XML.

Si la generación de correlaciones MTOM se inhabilita, se inhabilitará XOP. Si XOP está inhabilitado, los datos binarios no se envían utilizando conexiones MIME. En su lugar, los datos binarios se codifican en base64 de la forma habitual.

La especificación MTOM se define en tres partes diferentes:
  • Una característica abstracta para la transmisión optimizada o el formato de cable de mensajes SOAP. Esta característica es abstracta en el sentido de que la descripción de la técnica de optimización, así como el comportamiento de los procesadores SOAP en el remitente, el receptor y los intermediarios son genéricos y no incluyen referencias a tecnologías como MIME, HTTP etc. La técnica de optimización se centra en proteger una vista de SOAP Envelope Infoset de los procesadores SOAP, a la vez que se codifican de forma selectiva determinados contenidos de SOAP Envelope Infoset a los que se puede acceder como una representación léxica canónica del tipo de datos xs:base64Binary.

    La implementación de estas características abstractas requiere una especificación concreta de dos aspectos: el formato de cable optimizado y cómo fluye el formato de cable optimizado en un determinado transporte.

  • La segunda parte de la especificación MTOM se centra en el aspecto de serialización y depende normativamente del empaquetado MIME en varias partes/XOP relacionado. El aspecto de serialización es donde MTOM se relaciona con XOP.
  • Como característica concreta del nivel de enlace SOAP HTTP, MTOM se amplía en la serialización. En esta parte se describe cómo se puede utilizar el enlace HTTP para transportar los paquetes XOP que mantienen los mensajes SOAP MTOM. En esta parte también se añaden algunas restricciones a las serializaciones posibles de los mensajes SOAP MTOM como paquetes XOP como, por ejemplo, el uso exclusivo de XML 1.0.

JAX-WS (Java™ API for XML Web Services) añade soporte para enviar adjuntos de datos binarios utilizando MTOM. JAX-WS es la pieza central de una nueva arquitectura de pila de API para servicios web que incluye JAX-WS 2.0, JAXB 2.0 y SAAJ 1.3. La pila de API se conoce también como la pila integrada. JAX-WS está diseñada para sustituir a JAX-RPC en los servicios web y las aplicaciones web.

Enfoque de adjuntos

El adjunto por valor o por referencia ha sido la técnica más aceptada para manejar datos opacos en los mensajes con formato XML.
  • Por valor es cuando el contenido de datos opacos se incorpora como un elemento o un atributo, utilizando el enfoque de codificación de texto base64 o hexadecimal, que se codifica en el esquema XML como los tipos de datos xs:base64Binary y xs:hexBinary, respectivamente.
  • Por valor es cuando se hace referencia al contenido de datos opacos externamente como un elemento o un atributo, utilizando un URI, que se codifica en el esquema XML como un tipo de datos xs:anyURI.
El uso de una de estas dos técnicas tiene sus ventajas e inconvenientes. MTOM es la especificación que se encarga de resolver estos problemas de adjuntos inherentes.

World Wide Web Consortium (W3C) define un estándar diferente denominado SOAP with Attachments (SwA). SwA se ha desarrollado como una forma de empaquetar mensajes SOAP con adjuntos. Como algunos proveedores no dan soporte a SwA, SwA puede sustituirse por los mecanismos MTOM y XOP más potentes. SwA y MTOM son similares en concepto, y ambos codifican datos binarios como un adjunto MIME en un documento MIME. El uso de adjuntos MIME aumenta el rendimiento del transporte de cargas binarias de gran tamaño.

Las diferencias adicionales entre SwA y MTOM son:
  • MTOM utiliza un estándar denominado XOP, que define una referencia XOP que existe en la carga SOAP. Esta referencia apunta al adjunto MIME que contiene los datos binarios.
  • Con MTOM, la referencia XOP incluye lógicamente los datos binarios en XML Information Set (Infoset). Con SwA, la href apunta a datos que no están físicamente fuera del documento XML, pero que no se incluyen lógicamente en el Infoset.
  • Con MTOM, los adjuntos binarios se pueden firmar lógicamente como si formaran parte del documento XML de SOAP.
  • Además de IBM®, Microsoft .NET da soporte a MTOM, lo que elimina algunos de los problemas de interoperatividad con SwA. La interoperatividad se trató como el principal objetivo cuando los co-emisores analizaron las modificaciones sugeridas.
El enfoque de adjuntos MTOM aprovecha la infraestructura SOAP a la vez que disfruta de las ventajas de transporte que proporciona la solución SOAP with Attachment (SwA).

SOAP 1.2 y SOAP 1.1

SOAP 1.1 está basado en la especificación XML. De la misma forma, la implementación de SOAP 1.1 continuará existiendo varios años. Para aquellos que todavía ejecuten SOAP 1.1, existe ahora una forma interoperativa de utilizar MTOM para el soporte de adjuntos. SAP, Oracle, Microsoft e IBM han sometido un enlace SOAP 1.1 para la especificación MTOM 1.0 a W3C, que define cómo se puede utilizar MTOM con las cargas de SOAP 1.1. La especificación detalla las modificaciones necesarias en las especificaciones SOAP MTOM y XOP que se necesitan para utilizar de forma satisfactoria estas tecnologías con SOAP 1.1. Consulte la especificación para obtener más detalles.

MTOM es una característica de SOAP Versión 1.2, que se basa en el Infoset. Consulte la documentación del conjunto de información XML para obtener más información.

Sin MTOM, los datos se codifican en el formato descrito en el esquema (base 64 o hexadecimal) y, a continuación, quedan contenidos en el documento XML. En el siguiente ejemplo se muestra un mensaje SOAP con un elemento <xsd:base64Binary>:

... other transport headers ... 
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <sendImage xmlns="http://org/apache/axis2/jaxws/sample/mtom">
      <input>
        <imageData>R0lGODl  ... more base64 encoded data ...  KTJk8giAAA7</imageData>
      </input>
    </sendImage>
  </soapenv:Body>
</soapenv:Envelope>

Cuando MTOM está habilitada, los datos binarios que representan el adjunto se incluyen como un adjunto MIME en el mensaje SOAP. En el siguiente ejemplo se muestra un mensaje SOAP habilitado para MTOM con datos adjuntos:

... other transport headers ... 
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812; 
type="application/xop+xml"; start="<0.urn:uuid:0FE43E4D025F0BF3DC11582467646813@apache.org>"; 
start-info="text/xml"; charset=UTF-8

--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812
content-type: application/xop+xml; charset=UTF-8; type="text/xml";
content-transfer-encoding: binary
content-id: 
   <0.urn:uuid:0FE43E4D025F0BF3DC11582467646813@apache.org>

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <sendImage xmlns="http://org/apache/axis2/jaxws/sample/mtom">
      <input>
        <imageData>
          <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" 
               href="cid:1.urn:uuid:0FE43E4D025F0BF3DC11582467646811@apache.org"/>
        </imageData>
      </input>
    </sendImage>
   </soapenv:Body>
</soapenv:Envelope>
--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812
content-type: text/plain
content-transfer-encoding: binary
content-id: 
         <1.urn:uuid:0FE43E4D025F0BF3DC11582467646811@apache.org>

... binary data goes here ...
--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812--

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_soapmtom
File name: cwbs_soapmtom.html