Compresión y Servicios (Parte 2)

En el anterior post traté de explicar la necesidad de un mecanismo de compresión que pueda ser con los servicios. COn esto en mente veamos algunos de los mecanismos que se han estado utilizando.

Compresión en transporte

Este camino es el que tipicamente se ha encarado y principalmente por que Http 1.1 incluye en su especificación la posibilidad de utilizar la cabecera Content-Encoding para comprimir el contenido. Esta especificación es de mucha utilidad pues las razones que llevaron a la implementación de esta parte de la especificación son las mismas que discutí en el anterior artículo (no olvidemos que XML y HTML son substes de SGML). Es así que cuando el transporte era Http era la opción ideal para compresión.

Hablando especificamente de Windows IIS es capaz de comprimir el contenido generado por cualquier página o servicio que se ejecute en su contexto. Los pasos para habilitarlo están aquí. Y en lo que se refiere al cliente .net en la versión 1.0 y 1.1 soporte para Content-Encoding: gzip por lo cual era necesario algo de magia para que funcionara. Pero en la versión 2.0 solo es necesario hacer uso de la opción EnableDecompression.

Pero en lugar de seguir con Http Compression exclusivamente, entendamos el concepto si utilizaba Colas, SMTP, FTP o el transporte que fuera la tarea de compresión era responsabilidad del mismo y no así de la capa de manejo de SOAP y otros.

Lamentablemente WCF no provee soporte nativo para Http Compression y sus otros transportes tampoco lo implementan por defecto.

Serialización optimizada

Esta idea surge como contrapartida de la necesidad de compresión y su objetivo no es comprimir un mensaje sino generar un mejor mensaje, este enfoque en teoria evita todos las sobrecargas descritas en el anterior post. Casi todas las iniciativas se han denominado Serialización binaria o alguna otra variante. La desventaja de este tipo de escenarios es que ninguna se ha impuesto como un estándar y su nivel de compatibilidad es muy limitado.

Actualmente hay un par de ideas alrededor que han extendido este concepto. Estos conceptos se basan en que la serialización no debería modificarse y debería seguir serializandose el mensaje a XML Infoset, en cambio estos deberían codificarse (encode) en binario y no en documentos XML, WCF utiliza este concepto en su encoding binario que es, en palabras de Clemens Vasters en su blog, el nieto moderno y bajamente acoplado de NDR. Otro proyecto que esta tomando cuerpo es Fast Infoset , este proyecto impulsado por Sun y que basa su mecanismo de codificación en ASN.1  pretende ser la alternativa en escenarios Java. De nuevo estos mecanismos no aseguran interoperabilidad (aunque ya hay muchos trabajando en tener FI para WCF) y a pesar de que el tamaño del mensaje es mucho mejor no es comparable con un mensaje compreso.

Doble codificación

Este mecanismo lo han utilizado algunos en distintos transportes y consiste en que el generador del mensaje luego de serializarlo y codificarlo en XML lo vuelva a codificar esta vez utilizando un mecanismo de compresión, si queremos plantearlo así es llegar el concepto del content-encoding a la capa de codificación.

Esto no había sido utilizado mucho anteriormente pero me imagino que esta situación cambiará mucho al incluir los nuveos frameworks de servicios la facilidad de reemplazar o extender los codiicadores (encoders).

En el SDK de WCF podrán encontrar un ejemplo de un encoder que comprime utilizando GZip. Lo bueno de este encoder es que puede utilizarse en cualquier transporte. Lo malo es que no hay interoperabilidad

WS-Compression

Tengo que reconocer que no se exactamente donde surge esta especificación pero se que la primera mención de la misma se de en el proyecto PlumbOrange de Christian Weyer y cia y que fue implementado por gente de Lagash (Rodolfo y Pablo) para las distintas versiones de Web Services Enhancements y siendo la última disponible la creada para WCF RC1 por Pablo.

Bueno, esta es una especificación que siguiendo el ejemplo de XML Encryption reemplaza el contenido de un infoset XML con un elemento que contiene el binario (en base64) que cooresponde a la versión compresa. Y luego modifica el infoset para incluir información de referencia para descomprimir el elemento.

Este mecanismo tiene la ventaja de que puede ser más interoperable que la doble codificación y la codificación binaria, pero tiene la deventaja que al ser el resultado aún un documento XML no se obtiene el mejor resultado de compresión.

Conclusión

De las alternativas mencionadas casi todas ya están disponibles en WCF y/o WSE por lo cual es recomendable que se evalúe cuando puede ser beneficioso implementar estos mecanismos.