XML no es la solución universal…

…pero es un buen comienzo (aunque, como todo, depende de para qué).


Llevo varias semanas rumiando esta idea, y la verdad es que me ganaré las iras de más de uno al expresarla en público, pero da igual. Así además podré sondear las ideas de los cracks que por aquí suelen pasar.


Después de llevar ya un buen tiempo trabajando con Web Services, hay una idea que siempre pasa por mi cabeza de manera recurrente. ¿Por qué XML para el intercambio de datos?


Sé que SOA no es lo mismo que XML/XSD, pero en el 95% de los casos suelen ir de la mano para la comunicación de datos entre diversos sistemas. Y mi pregunta es ¿por qué?. Parte de las respuestas que me vienen a la cabeza son las siguientes:



  • XML es un lenguaje extensible, y muy flexible, y XSD nos permite definir cualquier estructura de datos que necesitemos.

  • Es fácil de comprender por los desarrolladores.

  • Es fácil de manipular por parte de los desarrolladores.

  • Al ser una representación textual de los datos, podemos examinar los contenidos de los datos de forma sencilla a la hora de depurar

  • Nos independizamos de las representaciones internas de los datos de cada uno de los sistemas.

Bueno, como podéis ver, la quinta razón no es del todo cierta, ya que si por ejemplo queréis consumir un servicio web creado con otra tecnología que no sea .NET desde una aplicación .NET veremos que cuando determinados tipos de datos aparecen en escena (por ejemplo, fechas), es posible que nos encontremos con algún problema.


Y hay algo más que salta a la vista tras ver las razones expuestas (si bien es una visión algo sesgada): El foco está puesto en el desarrollador, no en los sistemas que tienen que intercambiar los datos entre sí.


La duda que se me plantea es: ¿Por qué usamos un formato de datos comprensible por los humanos cuando los que tienen que manipular esos datos son sistemas informáticos? (es decir, máquinas). Los datos en XML llevan asociados una merma de rendimiento derivada del procesamiento que hay que hacer antes de poderlos utilizar nada despreciable. Y también se usa más espacio del que se podría utilizar, incrementando el gasto de ancho de banda para las comunicaciones.


Creo que sería más interesante algo como lo siguiente: Al igual que tenemos los XSD para definir los XML, ¿no podríamos definir un lenguaje del estilo de XSD que lo que defina es un formato binario de datos de forma sencilla? Es decir, el lenguaje que define los datos a intercambiar debería ser fácil de comprender por los desarrolladores, pero las estructuras de datos que representa deberían ser mucho más compactas y eficientes. Y sin dejar huecos para las imprecisiones. Cada tipo de dato «simple» – fechas, cadenas de texto, datos numéricos – debería tener definida su representación en binario. Por ejemplo, podríamos definir que las cadenas de texto están representadas mediante Unicode, ANSI Z, etc. O si queremos que los datos utilicen big-endian o little endian…


Por supuesto, debería tener la posibilidad de hacer includes, y referencias a objetos, de manera que cada tipo de datos «complejo» pueda ser definido una única vez, y cada instancia pueda ser serializada también de manera única.


Esto requiriría un apoyo por parte de las herramientas de desarrollo, de manera que a la hora de depurar tomasen la estructura de datos a examinar, y utilizando el lenguaje de definición mostrase al desarrollador los datos de una manera sencilla de comprender y manipular.


Quizá con algo así, podríamos tener un «Biztalk» que no necesitase tanto maquinón para ejecutarse… ^_^U


¿Qué opináis al respecto?

9 comentarios sobre “XML no es la solución universal…”

  1. Hola Alejandro,

    Sé que SOA no tiene que ver con la implementación, sino con la idea de tener una arquitectura que facilite la colaboración entre sistemas, haciendo que los sistemas expongan servicios (no Web Services) que puedan ser consumidos por el resto de sistemas de la arquitectura.

    Sin embargo, como comento en el artículo, «SOA no es lo mismo que XML/XSD, pero en el 95% de los casos suelen ir de la mano para la comunicación de datos entre diversos sistemas». Por ejemplo, hay veces (y no pocas) que se utilizan colas MQ (o MSMQ), y los mensajes en dichas colas se envían como XML. De nuevo por la facilidad de «comprender» y utilizar dichos mensajes por parte de los desarrolladores.

    Y es que normalmente al implementar SOA se suelen generar Web Services que exponen los diversos servicios, y para la comunicación entre sistemas se suele utilizar XML. De ahí la reflexión…

    Cambiaré el título por «XML no es la solución universal» para no llevar a confusiones.

    Por cierto, muy interesante el artículo. ¡Gracias!

  2. Hola Augusto!
    No puedo estar mas de acuerdo a lo que dice Alejandro. Cuando hablamos de SOA, hablamos de servicios (otra cosa es la implementación de los mismos) que tienen que satisfacer los requerimientos de negocio en los que seguro que va a haber intervención humana…y por debajo como dices tendremos los sistemas informáticos, pero con la premisa de qe son facilitadores y apoyo de los procesos de negocio y por lo tanto tienen que facilitar el intercambio de información para que al final le llegue a un sistema o una persona…al final piensa que se usa XML como formato de intercambio sobre todo por que es un estándar de facto que es entendible por cualquier plataforma o tecnología. Lo mismo pasa con los servicios web, y en concreto con todo lo relativo a WS-* para facilitar el intecambio de información o también RSS…son estándares y por lo tanto encajan dentro de la filosofía de SOA.

    Saludos

    JC’s

  3. Hola Juan Carlos!

    Sí, es cierto que hablar de SOA en este contexto no tiene sentido, ya que en ningún momento estoy hablando del negocio, sino de cuestiones técnicas.

    Si bien es cierto que los Web Services es la herramienta más común a utilizar para intentar implementar una arquitectura SOA a partir de lo que ya existe (además de otras cosas, como por ejemplo ESBs), y los Web Services suelen ir de la mano de XML. Así que para enfocar un poco más el tema he cambiado el título para que no lleve a errores 😉

    Comentas que «se usa XML como formato de intercambio sobre todo por que es un estándar de facto que es entendible por cualquier plataforma o tecnología». El hecho de que XML es el estándar de facto es innegable, pero… ¿Eso quiere decir que ha de ser inamovible? Creo que no, y de hecho dudo que lo sea en un futuro. Con lo que no estoy de acuerdo es que sea entendible por cualquier plataforma o tecnología.

    La estructura del XML sí que lo es, pero «la chicha», el contenido, es lo que no siempre es entendible entre sistemas de tecnologías diversas, ya que con XML sigue fallando el poner de acuerdo a las diversas tecnologías en cuál es el estándar para representar algunos tipos de datos (por ejemplo, las fechas). Y ese sería otro punto a mejorar…

  4. Yo estoy totalmente de acuerdo con el artículo. Si bien es cierto que XML es cómodo para trastear y debuggear, en la práctica, cuando se trabajan en entornos que se necesita intercambiar mucha información hace aguas, por ejemplo los entornos multimedia.

    No se ha hablado de una razón muy importante, que es el sobrecoste asociado a parsear los ficheros XML y leerlos, que en ocasiones puede llegar a ser crítico.

    Para mí, lo óptimo sería poder trabajar en formato XML en modo de desarrollo, pero que internamente y de forma transparente en pruebas/producción se use un formato binario que sea compacto. Creo que con un poco de reflexión este proceso podría hacerse de forma autómatica y ser estandarizado.. y que sea un bXML (binary XML).

  5. Hola, Augusto!

    No es que yo sea un defensor a ultranza de XML ni nada por el estilo, pero en esto mi opinión es diferente:

    >> El foco está puesto en el desarrollador, no en los sistemas que tienen que intercambiar los datos entre sí.

    Precisamente creo que *ES* en el desarrollador en quien tiene que estar. Me viene a la mente este artículo de Rodrigo:

    http://geeks.ms/blogs/rcorral/archive/2007/09/03/personas-o-bits.aspx

    en el que dice «Lo importante son las personas, no los bits». Aunque él lo decía en relación con otra cosa.

    Como yo lo veo, precisamente la historia de las aplicaciones distribuidas partió de sistemas binarios propietarios por razones puramente prácticas, y cada vez se va moviendo más hacia sistemas y herramientas con los que sea más cómodo trabajar y que permitan un mayor nivel de abstracción y una mayor productividad.

    Claro, igual cuando nos falle la Ley de Moore y no aparezca ninguna tecnología nueva en el horizonte habrá que aguantarse 🙂

    Es solo mi opinión personal.

    Saludos – Octavio

  6. Un artículo muy interesante .
    Esto es serialización serializada, es decir un serializador que «serialice» XML al bXML que nos decía Diego y viceversa. O casi mejor usar el bXML total casi nadie ve XML en el notepad, con lo que para el caso mirar bXML sería lo mismo.
    ¿Pero cómo sería el bXML?
    Estaríamos hablando entonces de logitud fija de campos o en todo caso de «separadores de campo» y «separadores de registro».
    Eso es bastante engorroso. No estamos contandos con la flexibilidad que nos da XML para definir todo tipo de estructuras con un numero variable de elementos y campos de longitud variable.
    Creo que el hecho de traducir todo esto a un binario mas eficiente pero igualmente versatil produciría un «XMLLite» que sería muy similar al XML pero ahorrandonos bytes representando los datos en binario y minimizando la longitud de los nombres de etiquetas y atributos (Siempre se puede hacer una asociación nombre-símbolo).
    Esto para miles de elementos pueden ser muchos bytes.
    Como ejemplo de todo esto están las bases de datos, uff no me quiero imaginar la de deserializaciones que nos podemos ahorrar.

  7. Lo que propones es algo que creo todo el mundo ha pensado una vez u otra. Creo que gran parte del éxito en la adopción de este tipo de formatos es, por un lado, la manía actual de documentarlo absolutamente todo, y XML es quizás de lo más parecido en el mundo informático a los sistemas de almacenamiento de datos en jerarquías que utilizan los bibliotécnicos o los documentalistas, y por otra parte también hay una gran culpa de que debido a la tecnología a la que tenemos acceso en la actualidad, prima la facilidad de uso y actualización por encima de otras virtudes que antaño fueron fundamentales en los desarrollos informáticos, como la velocidad o la eficiencia.

    La verdad es que podríamos discutir bastante más ampliamente sobre esto, sobre si la banda ancha y los procesadores de chorrocientos núcleos van a crear una nueva generación de informáticos idiotas (me sorprende ver, por ejemplo, que en un gran número de universidades se programa ya únicamente en Java, o que alumnos de segundo de ingeniería ni siquiera conocen la teoría más simple de qué es un fractal).

    Saludos.

  8. A mi me parece también una idea estupenda. Dejando de lado el tema de SOA (que creo que no es de lo que va el artículo) el trabajar con XML supone un sobrecoste bastante importante.

    Las comunicaciones con XML son muy cómodas a la hora de programar (no digo ya nada a la hora de depurar) pero tener que estar parseando con los dos extremos me parece algo que se podría ahorrar o, al menos, mejorar. Simplemente tendríamos que trasladar ese parseo que se lleva a cabo nuestros sistemas a nuestros aplicaciones de desarrollo con lo que los desarrolladores seguiríamos teniendo todas las ventajas (tan simple como tener una ventana Watch que tradujese, en ambos sentidos, entre este formato y algo entendible, quizá XML).

    Sin embargo la tarea más complicada sería poner de acuerdo a todo el mundo para crear un formato estándar (o casi) para comunicación que es lo que realmente, en mi opinión, hace grande al XML. Cada día los procesadores son más potentes y los anchos de banda más grandes lo que mitiga este lastre de usar XML, a pesar de que un nuevo formato podría mejorar el rendimiento (drásticamente en algunas aplicaciones).

    Así que pienso que el XML aún nos va a acompañar mucho tiempo y que deberíamos limitar su uso a lo estrictamente necesario (a ver si algunas personas que andan por ahí se dan cuenta de que XML resulta útil pero no es, en absoluto, la panacea). Así como el alcohol: con moderación.

Responder a aruiz Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *