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.

los lenguajes pasan, la lógica se mantiene

Robo un tiempo a la escritura de la segunda parte de serviciosy compresión para comentar en los lenguajes de programación. Esto surge porque el día de hoy recibi uchos mensajes relacionados con lenguajes, primero el anuncio de que las presentaciones de Lang.NET estan disponibles. Luego me envían el link de un artículo en el que se recomiendan los lenguajes de programación que uno debe aprender para estar a la par del mercado (el orden sigue sin convencerme pero los lenguajes me parece que son los encaminados) y finalmente leo varios comentarios respecto a IronPython.

En fin si analizo cada tema por separado cada uno me trae muchas ideas y en este momento solo comentare algunas:

1. Lang.NET: Cuando uno lee el temario de este simposio queda claro que hay mucho trabajo alrededor de los lenguajes dinámicos, Aún recuerdo que en mis primeras interacciones con JavaScript lo que más me atrajo del lenguaje fueron las características que lo hacen dinámico y con el tiempo descubrí muchas ventajas y llegué a establecer cariño con algunos lenguajes dinámicos. La principal ventaja de este tipo de lenguajes radica en la extensibilidad y capacidad de adaptación que brindan estos lenguajes a sus soluciones. Por ejemplo permiten que interfaces gráficas sean fáciles de crear y embeber en soluciones empaquetadas, otro ejemplo es la generación de objetos totalmente consistentes sobre la marcha (para ejemplo basta un botón TurboGears o Ruby on Rails.
   Sin embargo también hay que recordar que los lenguajes adolecen de una gran contra que es el impacto en rendimiento tipicamente los lenguajes dinámicos son interpretados y debido a que son dinámicos se hace un manejo muy complejo de las declaraciones y tipos.
   Bueno creo que hablaré más de esto en el punto 3, pero sigo con el simposio. Más allá de los lenguajes dinámicos es interesante ver como el CLI se vuelve objeto de todos tipo de lenguajes funcionales, dinámicos, etc. y ver que los distintos esfuerzos alrededor están demostrando que es una plataforma viable para realizar implementaciones optimizadas.
   Creo que es importante que los equipos de desarrollo involucrados con el CLI (en Microsoft y en Mono) empiecen a considerar algunas mejoras que surjan como recomendación de estas iniciativas y aseguren que la implementación de estas esten disponibles para todos los lenguajes generando una plataforma común y evitando que se dupliquen esfuerzos. Y si se puede finalmente incluirlo en el CLI. Hay que entender que muchos requerimientos de otros lenguajes pueden afectarse entre sí y allí es donde nosotros los mortales confiaremos en la sapiencia de los gurús.
2. Los lengaujes a aprender: Hace unos 8 años cualquiera que salía de la universidad había escuchado al menos una vez de Delphi y lo importante que era aprenderlo, es más yo era uno de sus defensores (lo que no quita que también usara Visual Basic). Y hoy no existe ninguna variante o descendiente que haya logrado ingresar en el top ten de e-Week. Personalmente creo que un programador debe poder adecuarse a cualquier sintaxis, pero también creo que no cualquier sintaxis se adecúa a cualquier problema. Por ello es muy importante que un buen programador conozca al menos 3 lenguajes de desarrollo, y en el caso de un arquitecto ... bueno un arquitecto tiene tiempo para leer mucho, ¿verdad?.
   Así que empecemos a hacer una revisión de como estoy yo con respecto a la lista:
   

   Lenguaje	Lectura	Escritura
   PHP	Media	Básica, ha pasado mucho tiempo
   C#	OK	OK
   AJAX	OK	OK
   JavaScript/ECMAScript	OK	OK
   Perl	Básica casi :S	:S
   C	OK	Basica - Media
   Ruby	Básica	Básica, muy básica
   Java	Media	:S
   Python	OK	Media - OK
   VB.Net	OK	Media -OK

   Primero tengo que aclarar mi escala: OK significa que siento que puedo leer/escribir una aplicación completa sin mayores sobresaltos, Media significa que podría leer/escribir una aplicación con algunas consultas a fuentes de documentación del lenguaje, Básica es mi entendido de que puedo darme una idea pero requiero de actualizar mis conocimientos o de tener la referencia del lenguaje a mi lado y finalmente :S significa que tendría que pedir ayuda a alguien que si sepa.
   No esta mal, solo tengo dos en los que no podría escribir código y en ambos casos es un tema de afinidad con el lenguaje, en este punto tengo que aclarar que nunca me han gustado ni Perl, ni Java ni su sintaxis. Es cierto que he escrito código en Java pero no fue una sensación agradable.
   Si ya se que me dirán si escribo ECMAScript y C# no debería tener problema con Java, pero esa no es la verdad.
   En fin, creo que es importante revisar al menos 5 de estos lenguajes y tenerlos en un nivel medio o superior para lectura y al menos 3 en medio o superior para escritura. Para cerrar quiero decir que en la lista falta una variante de lenguaje que para mi esta dando y dará mucho que hablar y que toca varios puntos importantes de la lista: IronPython y con esto paso al punto 3.
3. IronPython Como habrán visto de mi lista anterior Python es un lenguaje con el que me siente comodo, esto viene de hace unos años cuando necesitando una aplicación que permitiera que una aplicación cualquiera se coenctara a un sitio que autenticaba con NTLM y encontré NTLMAPS viendo la aplicación encontré muchas cosas de Python que nunca habia visto así que me involucre y estuve mucho tiempo jugando con Python y llegó a posicionarse como uno de mis lenguajes favoritos.
   Luego por razones de falta de tiempo deje de verlo y hace dos años o poco más vi en listas que había algo llamado IronPython que era un compilador de Python para .Net al ver el sitio de proyecto quede encantado porque Jim no solo estaba portando Python, sino creando un derivado que le permitiera utilizar las ventajas de Python y las ventajas de .Net.
   Durante mucho tiempo seguí el proyecto, me alegré cuando me enteré que Jim ingresaa a Microsoft y mucho más cuando supe que IronPython contaría con el apoyo de Microsoft. Bueno con esos antecedentes les contaré que hace un par de semanas Jim Hugunin anunció en su blog la liberación de la versión 1.0 de IronPython y no tarde en descargarlo. La verdad me parece un gran trabajo y el hecho de que pueda pasar  un 90% de las pruebas de la libreria estándar de Python es áun más sorprendente (el 10% que falta utiliza extensiones compiladas en C so..).
   Bueno desde la liberación estuve haciendo un par de cosas y la verdad me encanta IronPython. Me queda pendiente probar el add-in para visual studio pero Python es un lenguaje para trabajar en archivos y consola :)

Para finalizar este post que se extendió un poco solo quiero recalcar que si bien como desarrolladores podemos comulgar con un lenguaje u otro y que gracias a los servicios podemos comunicarnos facilmente con soluciones en otros lenguajes, no debemos olvidar que en un mundo de desarrolladores libres siempre habrán otros lenguajes y que cada uno tendrá un lugar para ser y crecer (yo creo que ya veremos algún lenguaje tipo pascal darnos una sorpresa).
Los lenguajes van y vienen pero mientras tu lógica, deseos de aprender y capacidad de análisis se desarrollen puedes estar seguro que siempre habrá uno que te satisfaga.

Presentaciones Lang.NET

Para los que no saben Lang.Net es un simposio que se llevo a cabo en Redmond a fines de Julio. Las sesiones están orientadas exclusivamente a tem[as como ser compiladores, CLI, virtual machines, lenguajes. En fin sesiones de bajo nivel pero definitivamente muy interesantes. Recientemente se publicaron en video las presentaciones así que para quienes esten interesados este es el link

http://www.langnetsymposium.com/speakers.asp

Compresión y servicios (Parte 1)

Una de las principales dudas que tuvimos todos cuando SOAP y todos sus parientes hicieron aparición en escena fue el impacto en el rendimiento de estos protocolos tan pesados, XML era basicamente un formato de serialización muy chatty y no se comparaba con serializaciones binarias altamente optimizadas que utilizaban los protocolos de objetos distrbuidos (DCOM, CORBA).

Con el tiempo y entendiendo los conceptos que hoy conforman SOA se entendió que esto no impactaría tanto como se esperaba por el cambio en la programación de interfaces y contratos.

Sin embargo esto no quita que aún así XML sea una serialización muy cara, si hablamos de una red corporativa con LAN de 100 Mbps es manejable pero cuando se empiezan a construir soluciones que se se ejecutarán en enlaces bajos (dial-up, satelital, etc) y es en este punto donde mucha discusión se ha dado en el uso de compresión para la comunicación con servicios.

Si consideramos que las respuestas grandes de servicios serializados en XML son documentos con un conjunto de registros similares cualquier algoritmo de compresión puede hacer un muy buen trabajo para disminuir el tamaño de un archivo. Tomemos por ejemplo un servicio de búsqueda que devuelve un documento con los resultados de búsqueda. La estructura del mensaje sería la siguiente.

<resultados registros="100" inicio="0" total="1054">
<resultado>
<Titulo>Sitio 1</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio/</Url>
</resultado>
...
<resultado>
<Titulo>Sitio 100</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio34131</Url>
</resultado>
</resultados>

En este caso al existir tanto texto similar el grado de compresión puede ser muy alto, por ejemplo un archivo XML de 1.5 MB utilizando gzip como algoritmo de compresión (RFC 1952) se convierte en 120 KB es decir un 8% del archivo original. Es cierto que el archivo que utilice como ejemplo tiene otros textos repetidos pero sirve como referencia.

Obviamente nunca deberíamos retornar 1.5 MB como resultado de un servicio pero tomando la estructura de ejemplo al retornar 100 registros tenemos un archivo de 13750 bytes. la transmisión de este resultado a través de una linea de 56Kbps( aproximadamente 7KBps) sería de 1.91 segundos (tiempo ideal sin ruido y confiabilidad de 100%). Si se que suena a que no es nada pero siguamos analizando. Si este mismo archivo lo comprimimos con gzip nivel 3 se convierten en 327 bytes con un tiempo ideal de 0.04 segundos. SI se considera que este tiempo es uso de ancho de banda y red esto podría significar atender a unos cuantos cientos de usuarios más con el mismo ancho de banda.

Como siempre no todo puede ser miel y en este caso el costo es un tiempo adicional para la compresión, el uso de procesador y memoria del servidor. entonces el tiempo adicional de proceso debe sumarse para ver cual sería el tiempo real de proceso.

En nuestro caso el tiempo de compresión es de no más de 10 milisegundos (utilizando la clase GZipStream del .Net Framework 2.0), si sumamos este tiempo al tiempo de transmisión tenemos un total 0.05 segundos lo cual es aún un muy buen resultado.

Otro aspecto a considerar es el uso de procesador, tipicamente todos los algoritmos de compresión tienen niveles que permiten definir la carga en procesador y memoria de la tarea de compresión. En el ejemplo se ha utilizado gzip nivel 3 (el que provee el framework) que no tiene impacto mayor al de un proceso de servicio por lo cual es una extensión solo en tiempo

El último aspecto es el uso de memoria, dado que la mayoría de las especificaciones WS-* requieren el Infoset de respuesta completo para su proceso actualmente casi todas las soluciones de publicación y consumo de servicios manejan los mensajes en buffer por lo que el consumo de memoria adicional es el relacionado al tamaño de la versión compresa de los datos. De nuevo en nuestro ejemplo es un 2%. Este dato no es despreciable en servidores de muy alto uso porque puede llegar a convertirse en punto de contención.

Con todo lo anteriormente dicho cual sería el criterio para decidir si utilizar compresión en la publicación de servicios:

1. Si se conoce que los clientes disponen de bajo ancho de banda y el nivel de concurrencia no estima que la memoria de servidor sea saturada es recomendado utilizar compresión, el nivel de compresión será determinado por la capacidad de procesador del servidor.

2. Si en cambio tenemos mucha concurrencia y anchos de banda aceptables es mejor no utilizar mecanismos de compresión de datos.

Con este pseudo-análisis (si ya se que tiene muchos vacios y que no puede llamarse un análisis serio) veamos cuales son las alternativas que se han manejado para la compresión de datos en servicios.

Nueva distribución de contenido

Como mencioné en un post anterior ya tengo dos blogs es por eso que he tomado la decisión de utilizar cada uno de ellos para un fin distinto, el Space de Live seguirá siendo el lugar donde ponga mis pensamientos, divagues, cuando sea que ellos desean llegar, y comentarios de indole familiar y de amistad.

El relativamente simple de blogger en cambio lo utilizaré para publicar datos y comunicación de orden laboral y técnico. De esta manera cada quien podrá visitar o suscribirse al contenido que desee.

Solo por si alguien se lo preguntaba el sitio técnico estará en castellano y estará abierto a que puedan enviarme preguntas para que en aquellos casos que pueda ayudar así lo haga.

Obviamente esto no significa que estaré escribiendo más a menudo pero es solo una decisión tomada hoy.

No todo en los iPod es color de rosa

Dejenme empezar diciendo que hasta el día de hoy habia tenido la mejor de las experiencias con mi iPod. Tengo un iPod Nano de 4GB en el que tengo casi toda la música que poseo (obviamente mi colección de CDs es algo limitada)

En fin, el día de hoy cuando me disponía a ir a una reunión prendí mi IPod y me vi con la maravillosa pantalla de diagnóstico. "Bueno", me dije, "sin duda hice reset sin querer" (es raro desbloquear, bloquear y presionar acción y menu por 6 segundos sin querer y luego presionar acción y prev otros seis, pero...) es así que por los próximos 40 minutos corri una variedad de pruebas en las que afortunadamente mi iPod aprobó.

El último punto Reset. Bueno llegando a casa lo sincronizo de nuevo. Y así paso el resto del día. Sin embargo llegue a casa y cuando conecto el iPod solo obtengo el nefasto

Para los que no conocen la simbología de los IPod esto significa que necesitas reinicializar tu IPod. Bueno habramos iTunes

:S ¿qué no esta conectado mi iPod?
Si tu lo dices... probemos con el iPod Updater
"Can't mount iPod" (perdón pero no estaba de humor para sacar copia de las ventanas)

Bueno, veamos que nos dice el sitio de Apple... reintente con ITunes, Updater,  yadda, yadda, yadda. Ah, pruebe moviendose a disk mode 

Probemos... nop sigo viendo el condenado folder y aunque esta vez el iPod Updater se bloquea

Revisemos otros pasos, y encontre este artículo iPod shows up in Windows but not in iTumes.

Es decir que tengo que eliminar todo y reinstalar, bueno vamos por ello y para estar seguros descargo de nuevo iTunes y el iPod Updater. Finalizado, llego el momento cumbre conecto de nuevo mi iPod y ... nada "can't mount ipod"

Me estoy preocupando, ¿y si corro de nuevo el diagnóstico? aqui voy bloquear, desbloquear, presionar acción y menu por 6 segundos, presionar acción y prev otros seis si ya estoy en el menu corramos el diagnostico de scan (prueba del disco)..... Como diría mi amiga Paula ¡rayos!

 Este icono significa que el sistema de iPod no pudo recuperar datos del disco duro, la documentación dice que si no puedo llevarlo a disk mode esto es historia. Cruzo los dedos y hago todos los pasos Check estoy en disk mode fiu....

Esperen iPod Updater lo detecto y pudo montarlo, Restore si... esta restaurado. En este momento estoy sincronizando de nuevo toda mi música pero esta vivo. Todo producto de software es susceptible a este azares.

Contigo Avanzar en Santa Cruz

Bueno esa era la idea pero debido al problema del paro civico es probable que hayan cambios en las fechas. El día viernes estaba planificada la realización de la jornada de trabajo, sin embargo con el paro convocado esta en duda y no se exactamente cuando se realizaría.

El concierto sería el sábado 9 de septiembre a partir de las 19:00 en la casa de la cultura. Esta vez son cuatro los participantes:

• Grillo Villegas
• Entre dos aguas
• Ronaldo Vaca-Pereira
• Negro y Blanco

Como siempre la entrada será libre así que estan todos invitados

Inicio en Blogger

Por un proyecto que en un futuro próximo espero se de a conocer (proyecto.. bueno una idea) es necesario que habilite una cuenta en blogger por ello hoy debuta http://relativamentesimple.blogspot.com  . Esto no significa que dejare de user mi space en Live, esta cuenta es complementaria y esta versión del blog será una replica de la que se encuentre en spaces.

Si ya se que no he escrito mucho pero espero que esto cambie en el curso de la próxima semana.