jueves, 30 de octubre de 2008

Fast InfoSet, Fast Web Services & XML encoding rules (XER) for ASN.1


[Aviso para navegantes:

A diferencia del resto de temas, en los que hablo desde el conocimiento o experiencia (o al menos desde un cierto conocimiento, tampoco vamos a ponernos chulos), sobre este tema en concreto no tengo experiencia ni he podido hacer pruebas. Se trata de una línea de investigación que abrí hace algún tiempo y que no he tenido tiempo de cerrar u ocasión/excusa por concurrencia importante en accesos a Web Services de mi proyecto... ]


Curioso tema. Pongámosmos bíblicos...

Al principio era el COBOL. Las estructuras eran sencillas, fáciles y rápidas de parsear, los sistemas intercambiaban ficheros con campos de anchura fija. Y vio que era bueno...

Luego llegó el C y el C++, y empezó a requerirse optimización en los tamaños de los ficheros así como en el parseo. Y llegaron los mensajes con campos de tamaño variable en los que al comienzo de cada campo se indica la longitud del mismo. Existieron múltiples implementaciones, quizás la más estandarizada sea el ASN.1 (Abstract Syntax Notation One). Tremendamente rápidos de parsear y eficientes en espacio excepto si el contenido de los campos es de tamaño pequeño en media.

Luego llegó la era de Internet. De la interoperabilidad y de lo que mola. Y alguien inventó el XML que son mensajes estructurados donde los campos tienen delimitadores de inicio y de fin para ser parseados por aplicaciones pero legibles para el humano en base al éxito del HTML. Muy mono, muy manejable, muy entendible, pero muy ineficiente tanto en tamaño como en velocidad de parseo.
Vamos, que como el cangrejo. Vamos hacia atrás. No se "nota mucho" porque en paralelo se ha incrementado la potencia de procesamiento y la velocidad de las redes. Pero, cuando hay intercambio exhaustivo de mensajería o saturación del ancho de banda, la solución "elegante" puede no servir.

En este enlace se explica el problema de de forma más seria, pero en el fondo dicen lo mismo que yo... http://java.sun.com/developer/technicalArticles/WebServices/fastWS/:

(...)

XML-based messaging is at the heart of the current Web Services technology. XML's self-describing nature has significant advantages, but they come at the price of bandwidth and performance.

XML-based messages are larger and require more processing than existing protocols such as RMI, RMI/IIOP or CORBA/IIOP: data is represented inefficiently, and binding requires more computation. For example, an RMI service can perform an order of magnitude faster than an equivalent Web Service. Use of HTTP as the transport for Web Services messages is not a significant factor when compared to the binding of XML to programmatic objects.

Increased bandwidth usage affects both wired and wireless networks. Often the latter, e.g. mobile telephone networks, have bandwidth restrictions allotted for communication by a network device. In addition, larger messages increase the possibility of retransmission since the smaller the message, the less likely it will be corrupted when in the air.

Increased processing requirements affects network devices communicating using both types of networks (wired and wireless). A server may not be able to handle the throughput the 'network' demands of it. Mobile phone battery life may be reduced as a device uses more memory, performs more processing and spends more time transmitting information. As the scale of Web Services usage increases, these problems are likely to be exacerbated.
Y en esta línea, hace ya algunos años, se comenzaron dos iniciativas, lideró unas propuestas y especifcaciones llamadas "Fast Infoset" (trabajo conjunto entre ISO/IEC JTC 1 y ITU-T) y "Fast Web Services" (iniciativa de Sun Microsystems y también en proceso de estandarización por ambas organizaciones).

Muy resumidamente y en términos mundanos significa que los mensajes y estructuras se serializan codificados por debajo en estructuras binarias ASN.1, pero que el las partes (enviante y receptor) se tratar como si fuera XML normal y corriente. Es decir, en términos de capas OSI, los niveles de transporte y protocolo cambian, pero no cambia el nivel de aplicación.

Para los que quieran más detalles, sus números de estándar son:


  • ITU-T Rec. X.891 ISO/IEC 24824-1
  • ITU-T Rec. X.892 ISO/IEC 24824-2
Y, además de los enlaces que he incluido arriba (de Sun Microsystems), estas presentaciones son muy legibles:
Y estos dos enlaces también están muy bien escritos:
Y en este blog hay toda una catogría muy interesante al respecto...
Desde mi punto de vista el tema en si mismo es para partirse de la risa (¿por qué hemos usado ASN.1 desde el principio y nos dejamos de tontadas?) y aparte, creo que esto soluciona sólo parte del problema (el transporte, aunque si usamos compresión GZIP ya ganamos bastante) pero no tiempo de computación y tratamiento. Amén de que dos no pelean si uno no quiere, es decir, ambos partners en el diálogo tienen que ser capaces de generar y entender estos Fast Web Services; si no, estamos jodidos...

Bueno, y ahora las implementaciones... Pues la buena noticia es que todo esto no es sólo teoría o desarrollos de difícil integración, sino que Sun tiene una implementación Open Source dentro del paraguas de Glassfish:

Si tengo tiempo de probarlo, os aviso...

Pero no sólo de Sun vive el hombre... Al menos están estas tres implementaciones conocidas:


Raro, ¿verdad?

No hay comentarios: