Hemos sobrevivido la sobre dosis de XML's

Durante los últimos años, hemos visto XML en todas partes y a pesar que se justifica en muchas ocasiones, "too much is too much".

Uno de los abusos más fastidioso son los archivos de configuración. En Java, hubo un tiempo que todos tenian que ser XML, sino no era computación "empresarial":

• las especificaciones J2EE se llenaron de ellos: web.xml, ejb-jar.xml,.application.xml, faces-config.xml, service.xml y como los especificadores consideraron que iban a ser generados con la ayuda de IDE's, no hicieron ningún esfuerzo para simplificarlos.

• los servidores de aplicación agregaron sus propios formatos. En el caso de Resin, sus autores lograron simplificar los archivos estándares con el costo de salirse de la norma Java EE. Otros fabricantes agregaron archivos aun más complejos que los del estándar y que son absolutamente imposibles de editar en vi o notepad: allí, IBM WAS es el campeón sin lugar a duda.

• Las primera generación de API's y frameworks Open Source que llegaron a simplificar J2EE tampoco se deshicieron de la configuración en XML. Hibernate logro simplificar si se compara con ejb-jar.xml, pero no puedo opinar lo mismo de los de Spring: Spring facilita un caos de configuración y Alfresco es un ejemplo reportado del sobre uso de estos archivos.
  

Llego algo de salvación, a menudo gracias a las anotaciones de Java y algunas API's que las usan de manera inteligente:

• JPA (las entidades en EJB 3.0) necesita un archivo de configuración realmente sencillo ("persistence.xml").
  
• JAX-WS (Web Service) y JAXB (binding de XML) no requieren nada de XML (excepto configurar algo en el "web.xml" de servlet)
• Hay algunos framework Open Source como Google Guice (competidor del core de Spring) y Wicket (competidor de JSF) que tampoco requieren XML.
  

Finalmente, algunos comentarios fuera del mundo Java:

• Scala tiene un excelente soporte de XML: habríamos tenido este nivel de integración en Java, quizás los archivos de configuración no habrían sido tan insoportables.

• el mundo .Net ha abusado de los Web Service (SOAP, WSDL, UDDI, WS-* son todos basados en XML). MS recomendo incialmente usarlos para comunicaciones intra-aplicaciones, como por ejemplo, entre la BD y el servidor de aplicación. ¡Menos mal que durante este tiempo, trabajaba en Java!
  

Se acaba el petróleo y no hay nada que lo reemplaza

Es realmente impactante este cálculo.

Me pregunto que podemos hacer para enfrentar este problema desde la perspectiva de las Tecnologías de Información y Comunicación (TIC).

No veo como usarlas para generar más energía, pero si, es posible que permitan ahorrarla un poco. Por ejemplo, limitando las necesidades de viaje para ir al trabajo, a la escuela, a lugar de tramites o estar en contacto con familiares y amigos. También, es posible que una mejor automatización pueda ahorrar más: por ejemplo, una TV que detecta si alguien la esta viendo estaría bienvenida en mi casa.

No queda más que ser super optimista ya que hay contra ejemplos clásicos: la TI no redujo la necesidad de cortar arboles para imprimir papel, bien al contrario.

El fin del buzzword SOA

Estamos viendo un cambio en el uso de la palabra SOA en la prensa generalista de TI. Ya no son puras maravillas y los problemas empiezan a aparecer. Es el principio del fin del uso de SOA como palabra de moda.

En este articulo el autor nombra reportes preocupantes de especialistas SOA y luego elabora una teoría: los departamentos de TI están demasiado ocupados en mantener funcionando sus sistemas actuales para tratar de mejorar su arquitectura global. En otro articulo, otro autor argumenta que SOA es demasiado abstracto para que los usuarios de negocio puedan entender y apoyar el proyecto. ¡Si se juntan los 2 artículos, no hay a quien vender SOA entonces!


Por otra parte, hay artículos que predicen que WOA viene a salvar SOA.

http://blogs.zdnet.com/service-oriented/?p=1079
http://blogs.zdnet.com/Hinchcliffe/?p=168
http://blogs.zdnet.com/Gardner/?p=2631

Nota: WOA es el nuevo buzzword y significa Web Oriented Architecture. Engloba las tecnologías Web 2.0 (como Mashup, AJAX), jSon y REST Básicamente, la integración se hace a nivel del browser que interactúa con varios sitios (usando REST).

Algunos comentarios míos:

• SOA ya dejo de ser la palabra "mágica" que los reporteros usan para generar visitas a sus artículos y ya están buscando crear nuevos términos de moda como WOA. Este cambio ha pasado montones de veces antes: hay que recordar que antes de SOA, estaba de moda el termino "Web Service" y, antes que este dejo de ser de moda, muchos especialistas dijeron que SOA venia a salvarlos. Explicarón porque su uso "en todas partes" no era viable por problemas de rendimiento, seguridad y eficiencia del desarrollo. Luego, explicaron que SOA era distinto de los Web Service y que se podia usar REST e incluso el viejo CORBA. Finalmente, explicaron que SOA es una arquitectura y los Web Service solamente un tipo de implementación. Desde esta fecha, los Web Service desaparecieron como "moda" siendo reemplazados por SOA y veo que esta pasando lo mismo con WOA y SOA ahora.
  

• Hay que recordar que los Web Service y luego SOA son técnicas y conceptos que nacieron de proveedores de TI (IBM y MS en el primer caso, empresas de consultoría en el segundo) y no vienen de un uso comercial. Eso es importante si se compara con las tecnologías Web 2.0 que si, nacieron como un uso comercial. Un programador curioso de ver lo novedoso de www.gmail.com estudio como estaba hecho y llamo "AJAX" el conjunto de técnicas usadas por Google. El nombre de Mashup nació también después de su primer uso en internet (no recuerdo si es YouTube, Google Maps u otro).
  

• Encuentro que las practicas de SOA son perfectamente rescatables. De hecho se basan sobre ideas que ya tienen 20 años en Análisis Estructurada y que son super probadas (como cohesión, coherencia). Pero, nunca me ha gustado la idea de un proyecto "SOA" a nivel de toda la empresa. Para mi, seria como haber hecho un proyecto "Orientación a Objeto" hace 10 años atrás: lo que si se puede hacer, son proyectos de desarrollo de aplicaciones que usan la Orientacion a Objeto para el analisis/diseño (usando UML) y la implementación (usando Java,C++,C#). Pasa lo mismo con SOA, se pueden hacer proyectos que usan la arquitectura de SOA (desacoplamiento) y sus técnicas (Web Service, REST). Durante estos proyectos, se introducen lo necesario para dar soporte a la arquitectura (practicas de diseño y gobernance, herramientas de integración como ESB).

En resumen, bienvenido el fin de la moda, ahora se puede usar la arquitectura SOA para fines practicos.