Xnoccio.com

E3L son las siglas de Environmental Electronic Exchange Language y nace ante la necesidad de establecer un formato estándar de intercambio de datos ambientales entre las distintas comunidades autónomas. Se trata de un proyecto colaborativo, en el que las AA PP implicadas consensúan los flujos de información y los plasman en un lenguaje común con unas reglas definidas y aceptadas por todos. E3L proporciona no sólo las reglas para comunicar plataformas tecnológicas, sino que conforma el primer diccionario electrónico de datos ambientales (metadatos). E3L cubre por ejemplo la presentación telemática de la Memoria Anual de Gestores de residuos, la Declaración Anual de Productores de residuos, los Documentos de Control y Seguimiento de residuos, etc. Para más información sobre este proyecto se pueden visitar los portales del proyecto:

• http://www.e3l.es/
• http://www.eterproject.org/

La Consejería de Medio Ambiente de la Junta de Andalucía ha apostado fuerte por la iniciativa y como resultado de ello confió en VIAVANSI para construir Augi@s, un sistema integral de gestión de residuos pionero al hablar E3L. Augi@s permite completar el ciclo de un documento desde su creación hasta su presentación y firma. El sistema ha sido diseñado para hablar en lenguaje E3L; por ello, el equipo de proyecto, constituido por personal de la Consejería de Medio Ambiente y de VIAVANSI, ha participado en la definición del estándar durante su desarrollo. Esto supone al fin una garantía de futuro para el formato de los datos manejados por Augi@s.La aplicación está diseñada con la máxima flexibilidad posible, externalizando en un API independiente la gestión del formato E3L, permitiendo adaptarse a los cambios del mismo en poco tiempo, o integrar nuevos elementos como los servicios publicados en E3S, que ya se encuentran en fase de pruebas en Augias.Considerando la aceptación del formato E3L a nivel estatal y la posibilidad de exportar dicho formato a otros países de la UE, podemos decir que la plataforma Augi@s se encuentra en una posición privilegiada de cara al futuro y vuelve a demostrar que, en contra de lo que se supone en varios círculos de opinión, Andalucía suele liderar a nivel nacional la innovación en muchos proyectos tecnológicos.

Recientemente se ha liberado la primera versión estable de Weld, la implementación de referencia de Web Beans (Java Context and Dependenty Injection - JSR 299). Y aunque puede parecer una liberación cualquiera, en este caso estamos ante un evento realmente importante para el mundillo Java.

¿Por qué es importante esta liberación?

• Por fin tenemos un estándar Java para la inyección, publicación, localización y búsqueda de componentes.
• Promete una mejor orquestación entre componentes JEE, evitando los típicos problemas de interoperabilidad entre Beans Spring, componentes Seam, Wicket, JSF, EL, etc..)
• Un remplazo estándar a las diferentes soluciones de inyección e IoC como Spring IoC, el prometedor Google Guice o el muy utilizado por nosotros Jboss Seam annotations.
• Fin del infierno XML, definiendo un mecanismo estándar independiente de ficheros de definición XML, que junto con JSF 2.0, Servlet 3.0, JPA, Jax-ws, etc… simplifican el desarrollo JEE.

¿Consecuencias para la industria a medio plazo?

• Es demasiado pronto para saberlo, pero…
  ¿Quizás el fin de la guerra de frameworks se inyección?…. (Google Guice vs Spring vs Jboss Seam). Consiguiendo un efecto similar al que consiguió JPA/JDO estandarizando el acceso a datos.
• Por fin una especificación JEE con la que construir aplicaciones complejas de forma sencilla.
• En un momento en el que muchas organizaciones están intentando estandarizar sus desarrollos, llegando incluso a restringir o imponer las tecnologías utilizadas, la preselección de implementaciones como Spring IoC o Seam carecerá de sentido. Siendo mucho más coherente la recomendación de estándares en lugar de restringir la evolución natural de la tecnología y la sana competición entre sus diferentes implementaciones.

¿Consecuencia para nosotros?

• Ninguna…. Gracias a nuestra apuesta por Jboss Seam (desde hace ya unos años), esta especificación se encontraba ya en nuestra hoja de ruta antes incluso de que fuese un Draft, por lo que para nosotros será suficiente con una mínima adaptación al estándar.
• La implementación es estable, la especificación muy bien pensada, y en las pruebas que hemos realizado con la beta, ha demostrado que consigue simplificar los desarrollos y hacer más comprensible el “oscuro arte de la inyección de componentes”.
• En breve empezaremos a usarla en algún proyecto piloto (que pueda asumir el riesgo de I+D asociado), analizaremos en detalle los posibles problemas que puedan surgir, y si todo se comporta como promete a mediados de 2010 empezaremos a usar la nueva especificación en nuestros proyectos Java.

¿Defectos?

• Llega demasiado tarde. Otros frameworks llevan, aunque de una forma mucho menos limpia,  ofreciendo algo similar desde hace ya mucho tiempo.
• Todavía no conocemos sus defectos. Y eso es un gran problema ya que hasta que no conozcamos sus problemáticas asociadas no será seguro su uso en proyectos de envergadura.
• Esperemos que en la huida del infierno de los ficheros de configuración XML, no nos metamos en  las tinieblas del uso de inyección e IoC para todo. Ya que una aplicación con una gran cantidad de componentes, comportamientos o atributos que dependen de la inyección hace muy complicada la comprensión de su funcionamiento.

En definitiva, todo indica que estamos antes una de las piezas clave del próximo JEE 6.

Llevo unos meses atrapado en una serie de proyectos [tremendamente aburridos] en los que me estoy enfrentando a problemas de velocidad de ejecucion y, sobre todo, de carga de memoria. Uno de esos dias en los que te sientes con fuerzas para cuestionar la filosofia de tu aplicacion que tiene meses de trabajo detras, me puse a buscar por ahi, a ver si daba con alguna explicacion razonable.

Y asi llegue a la pagina de los Sorensens y concretamente a este post: http://www.thesorensens.org/?p=14

Recomiendo la lectura de dicho articulo porque es muy interesante. Yo voy a ser bastante mas breve. Y probablemente para entender completamente este articulo, si se carecen de ciertos conocimientos, haya que leerse el otro.

Al parecer los parseadores de XML hacen uso de String.intern que resulta ser mucho mas eficiente a la hora de coparar Strings que un a.equals(b) caracter a carater; con String.intern esta comparacion es canonica. Desgraciadamente, para esta optimizacion de velocidad se hace uso del espacio Pergem de memoria.

Resulta que si bien mi caso no es tan extremo como el que tenia esta gente, si que me enfrento al parseo de un XML que puede llegar a ser de hasta 10Mb y cuyo XSD tiene 8600 lineas.

Es por esto que me enfrento a esos problemas de memoria. Tambien de velocidad, ya que el String.intern es mas eficiente que la comparacion caracter a caracter cuando tienes pocos Strings guardados en el pool, pero cuando este numero es masivo, el hecho de buscar los Strings en el pool es mas costoso que las comparaciones caracter a caracter.

La solucion que emplearon los Sorensens fue finalmente no usar parseadores de XML, ya que despues de todo no estaban parseando un XML real. En su lugar usaron expresiones regulares ganando espectacularmente en velocidad y uso de memoria.

En nuestro caso si se trata de XML reales, pero resulta que hay un 40% de los tags del XSD no los usamos en absoluto, y lo que nos sobra del XML es mas variable, pero en muchos casos ronda ese mismo porcentaje… quizas, despues de todo no necesitasemos parsear.

Probablemente ya sea tarde para plantearselo, pero si algun dia hay una segunda fase, quizas nos lancemos a reescribir esta parte del codigo. Si asi lo hacemos os comentaremos los resultados.

Hala pues,