Empaquetado optimizado de XML binario

World Wide Web (W3C) ha estandarizado la especificación de Empaquetado optimizado de XML binario (XOP) el 25 de enero de 2005. MTOM (Message Transmission Optimization Mechanism) utiliza XOP en el contexto de SOAP y MIME sobre HTTP.

XML se utiliza ampliamente en la transferencia de datos. XML es un formato reconocido para el intercambio de documentos con el formato correcto, ya que es de texto plano, legible por las personas y estructurado. Por ejemplo, la mensajería SOAP en los servicios web se basa en XML (o en XML Infoset con SOAP 1.2). Los usuarios que deseen aprovechar los formatos de legado como PDF, GIF, JPEG y similares continuarán utilizando un modelo XML. El deseo de integrar XML con los formatos de datos preexistentes ha sido un objetivo persistente para la comunidad XML desde hace mucho tiempo. A menudo, los usuarios aprovechan los convenios de marcación ampliable y estructurada de XML sin abandonar los formatos de datos existentes que no cumplen la sintaxis XML 1.0 de legibilidad.

A medida que la mensajería SOAP en los servicios web está más difundida, el siguiente paso es cómo enviar datos no basados en texto como, por ejemplo, datos de imágenes y flujos de trabajo, con el mensaje. Por ejemplo, es posible que desee enviar un documento escaneado en formato .jpeg entre dos aplicaciones. La cuestión es si estos datos se pueden entender en ambas aplicaciones.

Gran parte del valor de XML y los servicios web reside en la posibilidad de utilizar herramientas XML para trabajar con el contenido. Muchos estándares y herramientas XML para describir y manipular XML (por ejemplo, los analizadores, XPath, XQuery, XSLT, el cifrado XML, la firma digital y el esquema XML) no están diseñadas para trabajar con datos que no sean de texto como, por ejemplo, imágenes. Estas herramientas XML no funcionan con contenido no XML y requieren texto. El reto es cómo se pueden incorporar o adjuntar datos que no son de texto (también denominados datos binarios) con XML. En otras palabras, se necesita una forma de adjuntar un archivo binario a un mensaje SOAP.

La codificación es la única forma de que los datos binarios puedan entrar directamente en el mundo XML. Normalmente, puede incorporar datos binarios en un documento XML codificándolos como texto mediante Base 64. Base 64 es una serialización que ha existido durante algún tiempo, se puede implementar directamente con facilidad y permite la interoperatividad entre plataformas. El tipo de datos xsi:base64binary da soporte a esta serialización en el esquema XML. Base 64 codifica los datos binarios en una representación textual que se puede comprimir en un documento XML. Base 64 toma los datos binarios y los convierte en una serie de caracteres ASCII codificando tres octetos a la vez. Como cada octeto está formado por ocho bits, que se representan como cuatro caracteres imprimibles en el estándar ASCII, utiliza 64 caracteres ASCII para representar la parte binaria. Todas las plataformas pueden realizar la codificación y la decodificación utilizando este convenio. ASCII de 6 bits está ampliamente soportado y no es necesario tratar con caracteres especiales. No obstante, el rendimiento disminuye en los mensajes de gran tamaño.

Para las aplicaciones que requieren operaciones a gran velocidad, puede que Base 64 no sea la solución adecuada. Si desea indexar este tipo de contenido, consultarlo, transformarlo, cifrarlo, firmarlo o describirlo, deberá utilizar otro mecanismo.

Se ha desarrollado la primera especificación de adjuntos conocida como SOAP with Attachments (SwA). La idea principal de SwA es que la parte binaria del mensaje (el adjunto) se considere un adjunto MIME (Multipurpose Internet Mail Extensions). MIME es una especificación ampliamente implementada para dar formato a adjuntos de mensajes de correo no ASCII. SwA especifica que el cuerpo SOAP puede contener una referencia a la parte del mensaje MIME (el adjunto) utilizando simplemente un URI. La parte binaria se adjunta mediante una referencia.

Algunos inconvenientes de SwA son:
  • SwA falla en la capacidad de uso o la interoperatividad. La infraestructura SOAP se ha creado basándose en el sobre SOAP, que no funciona bien en los adjuntos. Un adjunto que utiliza SwA significa que se han utilizado dos modelos de datos en un mensaje. Estos dos modelos de datos no operan con la tecnología XML existente.
  • SwA no funciona con el carácter agregable de SOAP. Básicamente, los estándares como WS-Security no se han escrito para trabajar con adjuntos. WS-Security debe funcionar en todos los datos que se deben cifrar o firmar digitalmente, y esto incluye también todos los datos en el adjunto. Pero si no puede acceder a ellos, no podrá trabajar y la firma no será válida.

A menudo, los usuarios desean dejar los formatos no XML existentes tal cual, para que se traten como secuencias opacas de octetos en la infraestructura y las herramientas XML. Este tipo de enfoque permite que formatos ampliamente utilizados, como .jpeg y .wav coexistan con el formato XML sin problemas. XOP hace que el uso de datos codificados en base 64 sea un poco más realista. Actualmente, XOP sólo permite optimizar datos codificados en base 64.

El uso de XOP significa que las instancias de base64Binary de tipo XML, si están habilitadas, se transportan utilizando adjuntos MIME. Si se está utilizando XOP, la implementación puede codificarlo automáticamente. XOP mantiene el modelo de datos del mensaje XML, ya que el adjunto se trata como datos codificados en base 64. Si una pila XML entiende la codificación XOP, la aplicación no debe modificarse en absoluto. Por ejemplo, cuando desea acceder a una imagen .jpeg, puede obtener el valor de tipo carácter el contenido como una serie codificada en base 64.

XOP permite a las personas considerar los mensajes MIME en un intercambio de datos con el que se sienten cómodos y utilizar al mismo tiempo muchos otros datos. El formato XOP utiliza una estructura MIME en varias partes para permitir incluir los datos binarios sin formato en un documento XML 1.0 sin tener que recurrir a la codificación en base 64.

Una especificación compañera, SOAP Message Transmission Optimization Method (MTOM) especifica cómo enlazar este formato con SOAP. Los estándares XOP y MTOM deben mejorar el rendimiento de SOAP 1.2. XOP y MTOM proporcionan ambos el enfoque preferido para combinar datos binarios con XML basado en texto. Conjuntamente, MTOM y XOP permiten seleccionar qué partes del mensaje se deben enviar a través del cable de forma binaria, a la vez que se mantiene el Infoset. Estos estándares permiten la conexión de datos binarios fuera del sobre SOAP, como una parte del mensaje. No obstante, a diferencia de SwA, los datos binarios se tratan igual que en el sobre SOAP, lo que significa un Infoset.

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. Por otro lado, XML no es un buen mecanismo de empaquetado de uso general.

Un paquete XOP se crea colocando una serialización del Infoset XML dentro de un formato de empaquetado extensible (como MIME). Tenga en cuenta que XOP reutiliza MIME para el empaquetado real en el cable. A continuación, partes seleccionadas del contenido que son datos binarios codificados en base 64 se extraen y se recodifican, lo que significa que los datos se decodifican de base 64 y se colocan en el paquete. Las ubicaciones de estas partes seleccionadas se marcan en XML con un elemento especial que enlaza con los datos empaquetados utilizando URI.

Los motores de proceso SOAP ejecutan una codificación Base 64 temporal de los datos binarios justo antes de que el mensaje llegue al cable. Esta codificación temporal permite al procesador SOAP trabajar en los datos en base 64; por ejemplo, permite tomar una WS-Signature de los datos y colocarla en la cabecera. No es necesario realizar una decodificación amplia en el otro extremo, y el proceso funciona a la inversa.

Las implementaciones de MTOM y XOP están disponibles en Java™ (JAX-WS).

Este ejemplo muestra un Infoset XML anterior al proceso de XOP (SOAP):
<soap:Envelope
      xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
      xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
      <m:sig xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>
Este ejemplo muestra un Infoset XML que está serializado como paquete XOP (SOAP)
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// octetos binarios para png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// octetos binarios para la firma

--MIME_boundary--

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_xop
File name: cwbs_xop.html