Consejo

Comprima archivos XML para una transmisión eficiente

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

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Consejo

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Consejo

Manténgase en contacto por contenidos adicionales de esta serie.

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


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

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