Consejo: Comprima archivos XML para una transmisión eficiente

¿Quién necesita XML binario cuando tenemos buena compresión?

El binario XML ha generado muchos comentarios, y uno de los motivadores es la necesidad de un formato de transferencia menos verboso, especialmente para el uso de los servicios web. Una solución actualmente disponible es la compresión de datos. Esta sugerencia le muestra cómo utilizar la compresión para preparar el XML para la transmisión a través de los servicios web.

Uche Ogbuji, Partner, Zepheira, LLC

Photo of Uche OgbujiUche Ogbuji es asociado en Zepheira donde supervisa la creación de catálogos web sofisticados y otras bases de datos considerablemente contextuales. Tiene una larga trayectoria como pionero en tecnologías web avanzadas, como XML, web semántica y servicios web, y en proyectos en fuente abierta, como Akara, una plataforma de fuente abierta para aplicaciones de datos web. Es técnico informático y escritor. Nació en Nigeria, y vive y trabaja cerca de Boulder, Colorado, EE. UU. Para obtener más información sobre el Sr. Ogbuji, visite su blog, Copia.



03-12-2012

La idea de un XML binario siempre ha estado rondando los márgenes del discurso XML. XML es muy verboso por su herencia textual y las muchas reglas que impone para la facilidad de su utilización alrededor de textos internacionalizados. La sintaxis binaria equivalente sería mucho más compacta. En un artículo reciente (2000), "XML The future of EDI?" (ver Recursos), mostré la traducción de parte de una transacción de pedido de compra ANSI EDI X12 (que es binaria) a XML. El resultado XML fue de ocho veces el tamaño del mensaje EDI original (algunos otros pilotos de XML/EDI se vieron solo alrededor de tres veces). Esta verbosidad preocupa un poco para el almacenamiento de XML, pero al menos el almacenamiento es barato en estos días. La capacidad de transmisión por lo general es más limitada y los pedidos más importantes de XML binario vienen de aquellos que utilizan XML para formatos de transporte de mensajes, lo que incluye a algunos usuarios de servicios web.

Desarrolle habilidades de este tema

Este contenido es parte de knowledge paths progresivo para avanzar en sus habilidades. Vea:

Un abordaje para lograr la compresión XML es adoptar el formato designado para formatos binarios desde el comienzo. El candidato principal es ISO/ITU ASN.1, un estándar de transmisión de datos que antecede a XML. ASN.1 se está actualizando con varias capacidades relacionadas con XML que le permiten a los formatos XML ser reformulados en formas especializadas como reglas de codificación PER (Packed Encoding Rules) de ASN.1, las cuales definen una codificación binaria muy compacta. OASIS UBL es un ejemplo de una iniciativa XML que ha llevado al abordaje de ASN.1 a la compresión de datos XML.

Compresión para codificación SOAP

Si es necesario transmitir XML a servicios web quizá encuentre que su carga útil es demasiado verbosa. De ser así, es posible utilizar una de las tantas opciones de compresión de texto en el contenido XML. El Listado 1 es el ejemplo XML/EDI que presenté en el artículo mencionado con anterioridad.

Listado 1. Ejemplo de documento XML para intercambio de servicio web
<?xml version="1.0" encoding="UTF-8"?>
<PurchaseOrder Version="4010">
<PurchaseOrderHeader>
  <TransactionSetHeader X12.ID="850">
    <TransactionSetIDCode code="850"/>
    <TransactionSetControlNumber>12345</TransactionSetControlNumber>
  </TransactionSetHeader>
  <BeginningSegment>
    <PurposeTypeCode Code="00 Original"/>
    <OrderTypeCode Code="SA Stand-alone Order"/>
    <PurchaseOrderNumber>RET8999</PurchaseOrderNumber>
    <PurchaseOrderDate>19981201</PurchaseOrderDate>
   </BeginningSegment>
  <AdminCommunicationsContact>
    <ContactFunctionCode Code="OC Order Contact"/>
    <ContactName>Obi Anozie</ContactName>
  </AdminCommunicationsContact>
</PurchaseOrderHeader>
<PurchaseOrderDetail>
  <Name1InformationLOOP>
    <Name>
      <EntityIdentifierCode Code="BY Buying Party"/>
      <EntityName>Internet Retailer Inc.</EntityName>
      <IdentificationCodeQualifier Code="91 Assigned by Seller"/>
      <IdentificationCode>RET8999</IdentificationCode>
    </Name>
    <Name>
      <EntityIdentifierCode Code="ST Ship To"/>
      <EntityName>Internet Retailer Inc.</EntityName>
    </Name>
    <AddressInformation>123 Via Way</AddressInformation>
    <GeographicLocation>
      <CityName>Milwaukee</CityName>
      <StateProvinceCode>WI</StateProvinceCode>
      <PostalCode>53202</PostalCode>
    </GeographicLocation>
  </Name1InformationLOOP>
  <BaselineItemData>
    <QuantityOrdered>100</QuantityOrdered>
    <Unit Code="EA Each"/>
    <UnitPrice>1.23</UnitPrice>
    <PriceBasis Code="WE Wholesale Price per Each"/>
    <ProductIDQualifier Code="MG Manufacturer Part Number"/>
    <ProductID Description="Fuzzy Dice">CO633</ProductID>
  </BaselineItemData>
</PurchaseOrderDetail>
</PurchaseOrder>

El ejemplo original EDI es 200 bytes más largo y la versión XML es de 1721 bytes.

La reconocida rutina PK-ZIP comprime el archivo XML a 832 bytes.

La rutina GNU gzip comprime el archivo a 707 bytes.

La rutina de código abierto en bzip2 comprime el archivo a 748 bytes.

Ninguno de estos es tan compacto como el formato especializado EDI, lo cual es comprensible. bzip2 es famoso por comprimir muchos archivos mejor (y más lento) que gzip, pero los resultados aquí son típicos de mis observaciones, en las cuales gzip maneja XML mejor que bzip2.

La mayoría de las plataformas y los lenguajes en estos días tienen bibliotecas al menos para compresión PZ-ZIP y GNU gzip, lo cual se puede realizar de forma programática antes de que se invoque al servicio web.

Asegúrese de investigar si la canonicalización (C14N) mejorará o deteriorará la compresión en su instancia. C14N es un método estándar para generar una representación física de un documento XML, lo que se denomina forma canónica, lo que justifica las variaciones permitidas en la sintaxis XML sin cambiar el significado. Como regla general, si el XML es editado a mano con mucho potencial de variación en orden de atributos y el uso del espaciado, C14N puede mejorar el rendimiento de la compresión en documentos largos. Sin embargo, si el XML es generado por la máquina o utiliza muchos elementos vacíos, C14N puede ser dañino. Mi ejemplo se acerca a la última categoría. Yo lo canonicalicé utilizando el módulo C14N en el proyecto PyXML. El código Python es el siguiente:

>>> from xml.dom import minidom
>>> from xml.dom.ext import c14n
>>> doc = minidom.parse('listing1.xml')
>>> c14n.Canonicalize(doc)
>>> f = open('listing1-canonical.xml', 'w')
>>> c14n.Canonicalize(doc, output=f)
>>> f.close()

Es archivo resultante, listing1-canonical.xml, es de 1867 bytes y luego de que gzip lo achica a 714 bytes. La versión de texto plano es 146 bytes más larga y el resultado gzip es 7 bytes más grande. El motivo principal es que los elementos vacíos se expresan en su forma más verbosa después del C14N. Por ejemplo, la siguiente línea:

<Unit Code="EA Each"/>

se convierte en

<Unit Code="EA Each"></Unit>

Para empaquetar XML comprimido, por ejemplo, el resultado de gzip en SOAP, usted tiene dos opciones:

  • Utilice alguna forma de recurso de conexión
  • Utilice una codificación como Base64 para la inclusión en el cuerpo del mensaje

Base64 produce documentos binarios utilizando solamente caracteres textuales. Debería poder hacerlo utilizando bibliotecas de fácil acceso en cualquier plataforma. Incluso existe un esquema W3C XML para datos codificados Base64, y sus herramientas podrían automatizar la codificación y decodificación de Base64 si programa el servicio web de manera adecuada. Desafortunadamente, la codificación Base64 deshace un poco del efecto de la compresión. Una codificación Base64 es más grande que el original por una relación 4:3. Luego de la codificación Base64, el resultado gzip en el Listado 1 es de 957 bytes.


Resumen

En general, luego de que se aplica gzip a un archivo XML y el resultado comprimido es codificado con Base64 para entrega incorporada en SOAP, el resultado es por lo general de la mitad de su tamaño original. Esto podría ser suficiente para satisfacer sus necesidades de ahorro de espacio en servicios web XML. Si no lo es, observe ASN.1 con atención.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=848201
ArticleTitle=Consejo: Comprima archivos XML para una transmisión eficiente
publish-date=12032012