RIA para aplicaciones SIG en web, ¿sólo AJAX?

RIA= Rich Internet Applications

Todos hemos visto las interfaces de usuario de lo que se ha venido a llamar Web 2.0 (nunca me han gustado esto términos que tienen más de marketing que de fundamento técnico) tipo GMail. Utilizan técnicas que estaban disponibles, pero que sólo recientemente se han generalizado en los navegadores (el famoso HttpXmlRequest), y que alguien ha bautizado como AJAX (Asynchronous Javascript and XML).

¿Cómo se aplicaca esto a aplicaciones SIG distribuidas, y cuáles son las alternativas?.

AJAX ya se utiliza a día de hoy en aplicaciones web con funcionalidad geográfica (Ka-Map en Mapserver, ArcIMS y ArcGIS Server en la próxima versión, Google Maps, etc.). AJAX es la nueva "moda", y parece que un proyecto que no lleve esta tecnología no está a la última, y no es capaz de ofrecer una interfaz de usuario amigable, intuitiva, y lo que es más importante, con rendimientos y experiencias de usuario "adecuados".

Sin embargo, AJAX tiene varios inconvenientes, en los cuales no me voy a extender aquí (recordemos que se programa casi toda la aplicación en cliente, eso significa Javascript, eso significa código mucho más difícil de depurar, mantener y reutilizar).

¿Existen alternativas?. Siempre existen, veamos algunas.

1. SVG. "Estándar" recomendado por el W3C para dibujo vectorial 2D en la web. Es decir, parece ideal para nuestras aplicaciones, y hay cosas muy interesantes. Es parecido a Flash en cuanto a los resultados, pero basado en XML y animable y modificable mediante ECMAScript/Javascript. Sin embargo, plantea varios problemas.
NO tiene soporte nativo en los navegadores todavía. Hay un plugin de Adobe que permite visualizar estos archivos, y Mozilla se puede compilar con soporte SVG. Pero ambos procesos son agresivos desde el punto de vista del usuario (tiene que instalarse cosas), incluso muchos proyectos prohíben la necesidad de instalar nada en cliente. Hasta que tengamos soporte nativo generalizado, es una opción poco generalista, que puede no obstante ser muy buena en entornos intranet con un navegador específico.

2. Clientes pesados. Hablaré de Java (clientes SWING, no applets) pero es también aplicable a .NET u otros. Si realmente deseamos un cliente que mantenga el estado, que pueda incluso trabajar con conexiones intermitentes, con una interfaz rica de usuario y efectos de usabilidad complejos, este es el camino.

Si, nos hemos salido del navegador, y esto no es un sacrilegio, tenemos acceso a los recursos del Sistema Operativo, y podemos hacer muchas más cosas. Hay literalmente miles de efectos que podemos conseguir de una forma más precisa y sencilla sin hacer malabarismos con el código.

Impulsados por accesos remotos a servicios web, este tipo de clientes son el futuro de aplicaciones empresariales complejas, sobre todo en entornos intranet donde podemos asegurar una cierta homogeneidad (por ejemplo la necesidad de una máquina virtual determinada). El inconveniente es la necesidad de descargar el JRE (o runtime .NET) para poder funcionar. Se pueden desplegar con Java Web Start desde una página web (.NET acaba de sacar una tecnología análoga).
El escritorio ha vuelto, según dicen.

3. Macromedia Flex. La dejo para el final porque es la única con la que de momento no tengo experiencia. He visto los resultados que se pueden obtener con esta "suite" y son sorprendentes por la vistosidad. Teniendo en cuenta que el 97% de los navegadores soportan el formato Flash, y que se pueden hacer llamadas remotas a objetos Java (y próximamente a .NET también) y a servicios web SOAP/XML, parece una opción muy potente.

Conclusión: estas tres alternativas a mi juicio son más "limpias" que Javascript + DOM + XML + navegadores incompatibles y no estándares. Pero plantean un problema MUY gordo. Todas requieren instalar algo en cliente.

O sea, que tenemos AJAX para rato (a pesar de la cantidad de proyectos que se van a estrellar por su mal uso).