En mis conferencias en los dos últimos Encuentros Internacionales de Usuarios GeneXus he insistido sobre la tendencia inevitable a una arquitectura multi-servidor y la necesidad de dos elementos nuevos: servidor de Work Flow y servidor de mensajes.
Nada de esto es nuevo: los servidores de Work Flow aparecieron hace ya bastantes años y su objetivo inicial fue tratar de poner cierto orden y cierto control a la burocracia involucrada en los trámites manuales.
Con el tiempo se les ha ido utilizando para mucho más cosas como, por ejemplo, separar los flujos de datos de los programas, permitiéndole al usuario final responsable modificar dichos flujos sin tener que modificar aquellos programas, diálogos más simples de utilizar y auto-aprendibles para transacciones muy complejas, disparador de procesos batch, etc.
En particular nuestra experiencia directa nos dice que prácticamente todos los proyectos desarrollados con participación de GeneXus Consulting en los últimos dos años utilizan Work Flow como elemento importante.
Asociados con el Work Flow existen siempre, implícita o explícitamente, mensajes. El explicitar esos mensajes y describirlos rigurosamente es esencial para enfrentar las aplicaciones más complejas que serán necesarias en el futuro.
Un asunto crítico que es necesario resolver es la coordinación de procesos asincrónicos. Unos años atrás, la industria informática entendía que las bases de datos distribuidas serían la solución a una enorme cantidad de problemas. Un elemento esencial era, de alguna manera, sincronizar ambientes para viabilizar transacciones inter base de datos. Para eso apareció la confirmación transaccional de dos fases (Two Phase Commit).
La industria trabajó mucho para implementar esta característica pero cuando se generalizó su disponibilidad, hace ya algunos años, pudimos comprobar sus limitaciones para muchas situaciones comunes: los regímenes transaccionales son cada vez más grandes, las transacciones multi empresa son cada vez más frecuentes y la contención que provoca el Two Phase Commit a menudo no es soportable.
Una pregunta razonable parece ser ¿no es el sincronismo una restricción demasiado fuerte?.
Si, lo es. Y para paliar el problema en los casos en que las transacciones multi empresa son esenciales, se ha desarrollado, hace ya algunos años, el EDI (Electronic Data Exchange). Hoy y en un futuro previsible los negocios del tipo Business to Business (B2B) son críticos y no es EDI la herramienta adecuada (y, sobre todo, no lo será en el futuro) para resolverlos: necesitamos un verdadero esquema de mensajes pre descritos de alto nivel.
La comunidad informática ha trabajado mucho en la parte "física" de los mensajes (IBM MQSeries, Microsoft Queue, etc.) pero para tener verdaderas soluciones, que funcionen de una manera simple, utilizando como portador alguno de esos sistemas o bien Internet y aún, en el extremo inferior, mensajes de correo electrónico, se necesita trabajar en la parte lógica, en tener mensajes descritos a priori.
Paralelamente se está trabajando mucho en aplicaciones Internet de una manera rápida y desordenada y, lamentablemente, observamos que algunos de los protocolos que aparecen en el mercado no llegan a ser realidad porque alguno de los navegadores ("browsers") más utilizados no llega a soportarlo en forma adecuada y oportuna.
De una manera un poco sorprendente la comunidad informática se acaba de obsequiar a si misma dos protocolos que son, a la vez, estándares de hecho y de derecho: XML y XSL.
¿Por qué sorprendente?. Porque hace muchos años ya que los únicos estándares firmes lo han sido los de hecho: alguien lanza algo, pica primero y, ante su éxito y la incapacidad de los demás para alcanzarlo, se lo acaba aceptando como un estándar.
Esta vez los estándares de derecho citados han sido acogidos entusiastamente por todos los grandes jugadores lo que los transforma también en estándares de hecho (sin perjuicio de trucos del tipo: "mi estándar es un super conjunto del de los demás" que siempre ayudan poco).
XML es un lenguaje de mensajes auto descritos. XSL es un lenguaje que permite describir con toda libertad páginas (e indicar, por ejemplo, en que lugar debe hacerse que cosa con determinado mensaje XML). La conjunción XML / XSL nos permite lo mejor de dos mundos: interactuar inteligentemente con los datos mediante mensajes XML y dejar que la cosmética sea atendida por separado por especialistas en diseño gráfico mediante XSL.
Pero XML tiene otras utilidades mayores: el permitirnos intercambiar entre diferentes computadores, generalmente de diferentes empresas, mensajes inteligentes. Seguramente XML se transformará en muy poco tiempo en la gran herramienta para las transacciones del tipo Business to Business.
Estoy convencido de que la utiliza