Join Point

Nuevo artículo en AOP@Work: Rompiendo mitos

  El 14 de febrero los "enamorados" de la Programación Orientada a Aspectos recibimos otro regalo de manos de Ramnivas Laddad. Laddad es un nombre bien conocido en los círculos de la AOP, autor de AspectJ in Action, un gran libro, y ponente en la mayoría de los "saraos" relacionados con Java, como muestra, su magnifica conferencia Practical AOP en JavaPolis 2005

  Y es que parece que 2006, y esta vez sí, va a ser el año de la AOP. Desgraciadamente, se lleva mucho tiempo hablando de ella y se ha convertido en tema "hype". Realidades como las de Spring, JBoss, y artículos como AOP myths and realities - Beyond hype and misunderstandings pueden ayudar a ver la AOP como una solución factible y no como un tema más de los debates sin sentido tan habituales en el mundo informático y la presa del corazón.

  El artículo, que ocupa impreso unas 15 páginas A4, trata de desmontar 15 mitos habituales de la AOP. A continuación comentaré muy brevemente mi primera impresión sobre ellos.

Mito 1: AOP es buena solamente para trazas y logs

Realidad: AOP es idónea para muchas otras preocupaciones transversales (crosscutting concers)

Como dice el artículo, son los ejemplos clásicos que aparecen siempre, son el "hola mundo" de la AOP. Ambos problemas son padecidos por cualquier programador y sirven de forma estupenda para mostrar el potencial y la problemática que intenta solucionar la AOP.

Mito 2: AOP no resuelve ningún problema nuevo

Realidad: Es cierto, no lo hace

¿Que problemas resuelve la OOP frente a la programación estructurada?. El objetivo de la AOP es mejorar la modularidad del software, y por tanto, mejorar la reutilización, la evolución y dinamicidad de los sistemas software, y un largo etcétera.

Resumiendo, se puede decir que la "revolución" que plantea la Programación Orientada a Aspectos, es en el cómo solucionar los problemas. Además, considero que con este paradigma por fin se puede tratar los requisitos no funcionales a la altura que merecen y que es necesaria para que nuestra Ingeniería de Software sea algo real.

Mito 3: Interfaces bien diseñadas no hacen necesaria la AOP

Realidad: Las buenas interfaces son estupendas, pero no reemplazan a los aspectos

Pues si, un buen diseño de las interfaces esta muy bien, pero no sustituye las ventajas/necesidad de usar aspectos.

Mito 4: Los patrones de diseño hacen innecesaria la AOP

Realidad: Los patrones de diseño pueden introducir complejidad no existente en AOP

Muchas veces he oído comentar que lo que hace la AOP podría solucionarse con un par de patrones (mediator, visitor, etc, etc). Primero, no estoy de acuerdo, y segundo, lo que sale es un churro tremendamente complejo. En el imperio de los POJO soluciones como AOP e IoC se imponen a complejos patrones que necesitan de infinitas clases auxiliares e interfaces.

El artículo hace una crítica muy bien fundamentada del abuso del patrón Chain of Responsability (CoR) para solucionar problemas propios de la AOP. Recomendable leer todo el punto de artículo con los ejemplos para comprender mejor el potencial de la AOP en los problemas cotidianos.

Mito 5: Los proxies dinámicos hacen innecesaria la AOP

Realidad: AOP proporciona una solución más simple que los proxies dinámicos

Cuando leí el título de este punto me sorprendió. Lo que Laddad trata de decir es que usar los proxies dinámicos directamente es una mala solución. Sin embargo, hay que recordar que los proxies dinámicos son utilizados por numerosos frameworks AOP y es que hasta donde yo sé es de las únicas formas de tener AOP verdaderamente en tiempo de ejecución. Si alguien conoce más alternativas me gustaría saberlas.

Mito 6: Los frameworks de aplicación (application frameworks) hacen innecesaria la AOP

Realidad: Los frameworks introducen limitaciones no existentes en AOP

Frameworks de aplicación, como EJB, tienen una curva de aprendizaje muy elevada, sin embargo, en AOP hay muy pocos conceptos y una vez que les dominas no tienes limitaciones de ningún tipo. Si bien es cierto, que los servicios los tienes que implementar tu

Mito 7: Las anotaciones hacen innecesaria la AOP

Realidad: Anotaciones y AOP son altamente complementarias

Realmente las anotaciones van a incrementar el uso de AOP. Uno de los problemas que había para la adopción de la AOP es que necesitábamos un nuevo lenguaje. Las anotaciones y la definición de aspectos mediante XML dará menos miedo a la hora de apostar por la AOP. Además los programadores, en un futuro no muy lejano, nos vamos a tener que acostumbrar a tener muchas arrobas en nuestro código.

Yo personalmente prefiero las definiciones en XML, aunque luego sea un infierno, pero es la mejor forma de sacar esas definiciones fuera del código.

Mito 8: Los aspectos oscurecen el flujo del programa

Realidad: AOP aumenta el nivel de abstracción

La verdad es que este mito tiene parte de verdad y es que a medida que vamos añadiendo abstracción y alteramos el flujo normal del sistema, perdemos un poco la trazabilidad de la ejecución. Lo mismo pasa cuando usamos IoC y otras muchas cosas pero también es cierto que ganamos modularidad y otras cosas. Al final compensa.

Mito 9: Depurar con aspectos es duro

Realidad: AOP simplifica la depuración de la funcionalidad transversal

Al hilo del mito anterior, es cierto que en algún momento pueda parecer más difícil ya que añadimos capas pero es que la propia depuración es una preocupación transversal que puede ser tratada por la AOP como la tarea de realizar logs.

La AOP es en si misma una herramienta para facilitar la depuración. Incluso es el pilar para los sistemas software capaces de "autocurarse".

Mito 10: Los aspectos pueden romperse si las clases evolucionan

Realidad: Aspectos escritos pobremente puede romperse si las clases evolucionan

Pues es evidente que si la definición de aspectos no es la más adecuada, cuando modifiquemos las clases se va a ver alterada. El artículo ofrece algunas pistas para minimizar ese riesgo. Lo mejor de todo: hacer PRUEBAS!.

Mito 11: Los aspectos no pueden ser unidades testeables

Realidad: Los aspectos pueden ser unidades testeables tan fácilmente como las clases

Nada más alejado de la realidad, AOP es un mecanismo potentísimo para hacer pruebas y no tiene grandes problemas para ser sometido a ellas.

Como comentaba en una entrada anterior, existen herramientas de pruebas, al estilo JUnit, específicas para AOP como aUnit, artículos como Unit test your aspects, ...
Para más información ver http://www.csc.ncsu.edu/faculty/xie/aoptv.html

Mito 12: Las implementaciones de AOP no requieren un nuevo lenguaje

Realidad: Todas las implementaciones de AOP usan un nuevo lenguaje

Como comentaba unas líneas más arriba yo creo que el uso de anotaciones se va a terminar imponiendo aunque personalmente soy bastante más partidario de las definiciones en XML. Pero bueno, ya se verá. Lo que es cierto es que esto no puede ser utilizado como excusa.

Mito 13: AOP es simplemente demasiado compleja

Realidad: Si, pero aún más simple que las alternativas

El título lo dice todo .

Mito 14: AOP promueve diseño descuidado

Realidad: Se necesita experiencia para usar cualquier tecnología óptimamente

Ciertamente se puede hacer un mal uso de la AOP. Todavía es necesario un mayor rodaje de la AOP y sobre todo de los profesionales que la utilizan. Lo mismo sucedió en su tiempo con el paradigma de la Programación Orientada a Objetos.

Mito 15: La adopción de AOP es todo o nada

Realidad: AOP puede ser adoptado incrementalmente

Es algo que vengo comentando desde siempre. Hay muchas formas de usar AOP, lo importante es ir incorporándolo poco a poco en nuestro software y cada vez de forma más explícita. Valga esta última frase como conclusión de esta entrada.

Posted at 05:52PM feb 18, 2006 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[1]

Librería de aspectos con AspectJ 5

Hace menos de un mes se publico el interesantísimo artículo Check out library aspects with AspectJ 5 en la serie de artículos sobre AOP de developerWorks: AOP@Work. Este artículo, escrito por Wes Isberg, ofrece una visión muy clara de las distintas posibilidades que nos ofrece usar AOP.

En entradas anteriores he comentado mi cierto escepticismo por el uso real de AOP/AOSD tal cual. Sigo pensando que la gran implantación se centrará en servidores de aplicaciones, contenedores de servicios, frameworks, etc. Mientras que a corto plazo veo muy difícil que un ingeniero desde el análisis tenga en mente los aspectos.

El artículo se posiciona en el no tan cómodo término medio. Usar aspectos de forma consciente para ciertas tareas. Si atendemos a las cifras de descargas de AspectJ Development Tools (AJDT), un interfaz gráfico para AOP que se integra perfectamente en Eclipse, como comenta Ron Bodkin en su blog, esto no es en absoluto descabellado.

Además del artículo en si, su código fuente nos ofrece una colección de ejemplos, siempre bienvenida para los que nos iniciamos en el uso de AspectJ 5.

Recomiendo encarecidamente la lectura de este articulo que intenta ser ameno, a la par que educativo y práctico. Y por supuesto, recomiendo empezar a desarrollar nuestras propias librerías (bibliotecas) de aspectos, y a compartirlas con los demás. Utilizar aspectos puede ser MUY PRÁCTICO en infinidad de casos,

Una vez más, y no me cansaré de repetirlo, animar a la gente que lea esto, a escribir algún comentario y poder intercambiar impresiones. De todas formas, amigo lector, gracias por invertir tu tiempo con esto.

Posted at 01:13PM feb 05, 2006 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]

Estrés, DesperatingException y otros compañeros

No, no voy a hablar de los test de Stress (ver tutorial en jH y proyecto JMeter). DesperatingExcepcion es una clase que instancio con demasiada frecuencia en el comportamiento de mi "sistema software", empiezo a pensar que el nombre de esa clase es erróneo, de excepción tiene poco.

Ayer me sucedió una cosa curiosa. Iba yo al trabajo tranquilamente y me disponía, como hago habitualmente, a coger mi ejemplar de 20minutos, que extraño pensé, la chica que los reparte no está, será porque es viernes. Avanzo unos metros más y pienso en la poca gente que hay por la calle, me da por mirar el móvil y...¡era una hora antes!. Se me quedo la misma cara de gilipollas que el día anterior cuando el examinador me cargo el carné de conducir. Eso si, recomiendo un paseo por Valladolid a las 6:30 un día laborable, si no te importa el frió.

Hace mucho que no escribo por aquí, mitad falta de tiempo, mitad pereza. Pero hoy intentaré hacer un resumen/reflexión de todos los fregados en los que ando metido y aprovechar para ordenar mi mente que se nota que lo necesito .

Entre otras cosas, "gasto" mi tiempo sacando el Certificado de Aptitud Pedagógica (todo el mundo lo conoce por CAP). He tenido suerte, las prácticas me han tocado en el ciclo formativo de Grado Superior de Desarrollo de Aplicaciones Informáticas (DSI) y más concretamente en el módulo/asignatura de programación.
Oooh, si, enseñar a programar en Java. La verdad es que me gusta, ojala tuviera más tiempo para dejarlo de ver como un compromiso y verlo como una experiencia. Envidio en cierta manera a los alumnos de ese modulo, a mi nunca me enseñaron a programar en Java, y es más, creo que entre todas las asignaturas de programación de la Técnica y la Superior nadie me ha enseñado a programar, pero ese es otro tema.
Por si a alguien le interesa utilizan las siguientes herramientas:

• jGRASP para programar
• JUDE para modelado con UML

Ya contaré que tal dando la clase de javadoc. Seguro que dejo la documentación por aquí.

De mi pequeña experiencia laboral hay varias cosas que tengo claras. Una de ellas es que es muy muy conveniente tener:

• Un prototipo de la interfaz de usuario
• Una arquitectura de la aplicación sólida
• Un modelo de datos CORRECTO (que la base de datos tenga sentido)
• Tener claro el workflow del proceso que estas automatizando

Los prototipos siempre son peligrosos, dan al cliente una falsa sensación de la situación del proyecto y lo que queda por hacer. Además hay que tener mucho cuidado reutilizando ese prototipo. La pregunta del millón es ¿los prototipos IU se deben reutilizar?. En mi caso, el interfaz era web y, bueno, la reutilización va bien pero esto no siempre es así. Sin embargo la información que nos aporta tener el prototipo IU tanto a desarrolladores como al cliente NO si tiene precio.

La arquitectura de la aplicación debe ser sólida, y la elección de tecnologías coherente (conocimiento por parte del equipo de desarrollo, entorno de producción, licencias, estabilidad, madurez...). Para mi este es uno de los puntos cruciales para tener un final feliz y a la vez uno de los mayores quebraderos de cabeza.

El modelo de datos tiene que ser correcto (no hace falta que este en la 5ª Forma Normal ) y se debe pensar en un modelo físico eficiente. Si el sistema hace uso intensivo de una base de datos no esta demás dedicar un tiempo a tareas de optimización y análisis de los planes de ejecución de las consultas más complejas. Se puede mejorar el rendimiento sin necesidad de caches que complican el sistema software.

Lo del workflow es lógico, si no sabes como funciona, el famoso KNOW HOW, como vas a automatizarlo. Aunque ojala fuera todo tan sencillo. Cuidado con clientes que no saben como funcionan las cosas. Esto es muy habitual cuando trabajas para la Administración Pública.

Otra cosa que he aprendido es que para que un equipo de trabajo funcione se deben dar las siguientes condiciones:

• Debe existir una jerarquía, preferiblemente lo más plana posible y dialogante. Además de una jerarquía es necesario definir claramente los puestos, funciones y responsabilidades de cada integrante del equipo.
• Es necesario un "jefe" que realice una supervisión de la marcha del proyecto y que tenga capacidad de decisión para dar la "última palabra". Bueno, hay muchas clases de jefe.
• La comunicación entre los integrantes del grupo debe ser fluida. No se puede ocultar información.
• Tiene que existir "buen rollo" en el equipo, esto facilitará la comunicación y el apoyo entre compañeros a la vez que hace más fácil la vida laboral.
• La documentación es vital. Debe haber un buen análisis, un buen diseño, y seguir unas buenas prácticas a la hora de codificar.
• Es necesario tener el soporte de herramientas como gestores de versiones (cvs, subversion,...).

Y no puedo callarme, tengo que hacer el siguiente comentario. ODIO que la gente haga aplicaciones web para todo. Que nadie entienda mal, pero estoy HARTO de que muchas aplicaciones se tengan que hacer web por narices. Señores, html es html, javascript apesta y el protocolo HTTP esta bien pero tiene muchas carencias (falta de estado,...).

Tan cansado estoy de eso como de RoR, AJAX y similares. Hace unos meses y al hilo de una noticia comentábamos en jH que no hay un framework definitivo para aplicaciones web. El problema no esta en los framework actuales si no en el problemón que intentan resolver para suplicar la carencia de las capas inferiores. Tal vez la respuesta sea XUL o XForms o quien sabe qué.

Supongo que es por todo esto que he comentado anteriormente, por lo que me gustaría apostar por los JavaServer Faces. Mi sueño es poder desarrollar aplicaciones web como desarrollaba las aplicaciones de escritorio con Borland C++ Builder o como parece que se pueden desarrollar hoy día en java con Matisse . Y que luego se "traduzcan" mediante renders en (x)html+javascript (con o sin AJAX) o XUL o lo que toque.

Otra cosa que me gustaría comentar, es el "nuevo mundo" de los microkernels y microcontenedores. Hace tiempo estuve investigando un poco en este mundillo debido a mi faraónico proyecto. Por cierto, la próxima vez, que no habrá próxima vez, propongo el típico proyecto de página web + BD y a correr. Como iba diciendo, esta semana ha vuelto a mi mente gracias al proyecto OCAS.

El concepto no es nuevo ya que en cierta medida es lo mismo que se ha venido haciendo con JMX en los servidores de aplicaciones. ¿Es hora de jubilar JMX para este cometido?. La verdad es que yo no lo tengo muy claro. Los microcontenedores basados en IoC están arrasando a la hora de dar soluciones a POJO, pero parece que los grandes servidores siguen apostando por JMX. Además JMX cada vez esta más integrado en el JSE. ¿JMX esta pensado para ser microkernel?. Yo creo que no, que simplemente ha cubierto un vació que existía y ahora es difícil que los grandes servidores refactoricen sus microkernels a soluciones IoC.

Si a alguien le interesa mi opinión, que hasta puede ser posible, aprovechando el cambio que se esta produciendo en EJB 3 (anotaciones,...) y la importancia y madurez de las soluciones POJO modificaría la arquitectura de los servidores por microkernels IoC + servicios proporcionados mediante aspectos.

Bueno, esta entrada es extremadamente larga y densa al igual que los desvaríos de este pobre "javero" aprendiz de mucho y conocedor de poco. Por último sugerir la lectura de una novela juvenil, que releí el otro fin de semana aprovechando que mi salud no estaba en su momento álgido. Los bonsáis gigantes de Lucía Baquedano es un libro de El Barco de Vapor, si, ya he dicho que es juvenil, interesante de leer a cualquier edad y que no lleva más de dos horas y algo.

Espero que si alguien logra leer todo esto le sirva para algo. Yo por lo menos estoy más tranquilo espiritualmente . Se agradecería comentarios de cualquier tipo, siempre y cuando sean constructivos.

Posted at 10:30AM feb 05, 2006 by Ricardo Santamaría Bogónez in General  |  Comentarios[1]

¿Monitorización del host?

Hoy día, estamos muy acostumbrados a ver estadísticas sobre los recursos que utiliza nuestra máquina virtual, por ejemplo, mediante profiler como JProfiler, OptimizeIt, JProbe,.. o desde IDEs como NetBeans. Además la última moda, en gran medida gracias a Java 5, es mostrar en la propia aplicación el consumo de recursos. Un ejemplo curioso es el plugin disponible para Azureus.

Pues bien, el otro día, trabajando con el artículo "Using Aspect Oriented Programming to buils a portable load balancing service" los autores, muy razonablemente, afirman que las decisiones de balanceo deben estar dirigidas por los datos de monitorización del host como son:

• Uso de CPU
• Número de hilos/procesos ejecutándose
• Memoria virtual usada, libre
• Memoria física....
• etc.

Problema: Monitorización del host. Si por el host consideramos la máquina virtual esta entrada en el blog debería terminar . Hombre, en un entorno donde tenemos una máquina virtual en cada host y no hay ningún otro proceso "pesado" la simplificación JVM = host es muy asumible. En el caso de que tuviéramos más de una JVM en un mismo host y ningún otro proceso "pesado", se podría intentar calcular la carga del host en función de la suma de la carga de cada JVM. Pero... ¿y si nuestra máquina virtual comparte host con otros procesos no java?.

Imaginemos que tenemos un entorno académico donde se están constantemente realizando cálculos matemáticos para simulaciones. En varias máquinas hay procesos en C que calculan estructuras moleculares con grandes matrices que consumen mucha memoria. Y por supuesto, tenemos nuestro sistema distribuido que incorpora balanceo de carga. ¿Qué sucede cuando el host que esta ejecutando ese proceso en C envía sus datos de monitorización?. Pues si en ese momento en la máquina virtual solamente se está realizando la monitorización, nos dirá que el host no esta sobrecargado, y nada más alejado de la realidad.

Duda: ¿Cómo obtener información del host?, o mejor dicho, ¿seguro que eso es posible en java sin tener que recurrir a C?.

Un herramienta muy interesante que incorpora Java 5 es jconsole (Java Monitoring and Management Console). Aunque no se ha hablado mucho de ella parece ofrecer grandes posibilidades. Un ejemplo práctico de su uso puede verse en "Performance monitoring with AspectJ" (1) (2),

Sin perder de vista nuestro objetivo y siguiendo con la herramienta jconsole he encontrado un articulo "clave": "Using JConsole to Monitor Applications", del que especialmente me interesa el apartado Access OS resources-Sun's platform extension. Este artículo nos habla de la existencia de un Operating System MBean que es capaz de proporcionarnos la siguiente información:

• El tiempo de proceso de la CPU
• Memoria física libre y total
• Memoria virtual libre y total
• Memoria virtual comprometida (committed) que representa la cantidad de memoria virtual que estará disponible para el proceso de forma garantizada.
• El número de descriptores de archivo abiertos (solamente en UNIX y derivados)

Bien, parece que existe algo . Siguiendo la pista del OperatingSystemMXBean nos encontramos con lo siguiente:

• La interfaz java.lang.management.OperatingSystemMXBean
• La interfaz com.sun.management.OperatingSystemMXBean (subinterfaz de java.lang.management.OperatingSystemMXBean)
• La interfaz com.sun.management.UnixOperatingSystemMXBean (subinterfaz de com.sun.management.OperatingSystemMXBean)

La interfaz java.lang.management.OperatingSystemMXBean nos proporciona la siguiente información:

• La arquitectura del sistema (x86,...)
• Número de procesadores disponibles
• Nombre del sistema operativo
• Versión del sistema operativo

La interfaz com.sun.management.OperatingSystemMXBean nos proporciona la siguiente información:

• Memoria virtual comprometida
• Memoria física libre y total
• Memoria virtual libre y total
• Tiempo usado por nuestro proceso que esta ejecutándose en nuestra máquina virtual.

La interfaz com.sun.management.UnixOperatingSystemMXBean nos proporciona la siguiente información:

• Número máximo de descriptores de archivo
• Número de descriptores de archivo abiertos

Una vez que sabemos toda la información que podemos obtener la comparamos con lo que buscábamos y llegamos a las siguientes conclusiones: En cuanto a memoria del host tanto virtual como física tenemos el conocimiento deseado y suficiente como, por ejemplo, para alimentar el sistema de balanceo de carga. Sin embargo, en lo que respecta a consumo de CPU tenemos todos los datos relacionados con la JVM y el tiempo de procesador de nuestro proceso. Este último dato lo podríamos utilizar para hacer algún tipo de "adivinación".

Y cuando uno podría dar por perdido intentar saber la carga del procesador, aparece un Mustang y de él baja el método getSystemLoadAverage . En Java 6 a la interfaz java.lang.management.OperatingSystemMXBean se le ha añadido este nuevo método que nos devuelve la carga del sistema en el último minuto.

Por último un pequeño ejemplo.

import java.lang.management.ManagementFactory;
import com.sun.management.OperatingSystemMXBean;

public class MonitorizacionHost {

    private long memFisicaTotal;
    private long memFisicaLibre;
    private long memVirtualTotal;
    private long memVirtualLibre;

    public MonitorizacionHost() {
    }

    public static void main(String[] args) {
        MonitorizacionHost monitor = new MonitorizacionHost();
        monitor.obtenerDatos();
        monitor.imprimirDatos();
    }

    private void imprimirDatos() {
        System.out.println("Informacion del sistema...\n");
        System.out.println("Memoria fisica total: " + memFisicaTotal);
        System.out.println("Memoria fisica libre: " + memFisicaLibre);
        System.out.println("Memoria virtual total: " + memVirtualTotal);
        System.out.println("Memoria virtual libre: " + memVirtualLibre);
    }

    private void obtenerDatos() {
        OperatingSystemMXBean mxbean = (OperatingSystemMXBean) ManagementFactory
                .getOperatingSystemMXBean();
        memFisicaLibre = mxbean.getFreePhysicalMemorySize();
        memFisicaTotal = mxbean.getTotalPhysicalMemorySize();
        memVirtualTotal = mxbean.getTotalSwapSpaceSize();
        memVirtualLibre = mxbean.getFreeSwapSpaceSize();     
    }

}

Posted at 12:41PM dic 31, 2005 by Ricardo Santamaría Bogónez in Java  |  Comentarios[2]

¿Esta lista la Programación Orientada a Aspectos?

Después de haber estado durante todo este año, que ya se nos acaba, "evangelizando" sobre la AOP no tengo intención de retractarme, más aún cuando parece que los "visionarios" de M$ se están interesando por el tema . Sin embargo, considero que existen todavía algunas lagunas en este campo.

Hay diferentes formas de usar AOP pero creo que se puede distinguir dos tendencias:

1. Utilizar conjuntamente programación orientada a objetos y a aspectos para desarrollar un sistema software.
   
   
2. Utilizar programación orientada a objetos como hasta ahora junto con otros elementos como: frameworks (persistencia, loggin, pruebas) contenedores de aplicaciones (Jboss), contenedores ligeros (Spring), metaprogramación,... que actúen usando el paradigma AOP.

El enfoque con el que se parte en estas dos tendencias es tan diferente como su grado de implantación. Mientras que la informática práctica esta apostando por la segunda tendencia, los más teóricos, lógicamente, siguen con la primera, a la que nos referiremos desde ahora.

Superado el razonable miedo inicial a las nuevas siglas, últimamente omnipresentes, y empezando a ver los primeros resultados, por ejemplo en Spring o en JBoss, sería interesante empezar a desarrollar software con el paradigma AOP en la cabeza. Bueno, pues... ¡todos a seguir la primera tendencia!, ¿o no?. Veamos una situación ficticia... pero podría suceder.

"Yo trabajo en la empresa X, seguro que a alguno le suena esa empresa, y quiero hacer mi aplicación usando AOP porque soy un tío que ha leído mucho, que apuesto por innovar y que quiero lo mejor para mi empresa. Además tengo en mente reutilizar gran parte de esa aplicación para otro proyecto y no quiero comerme los marrones después. Pero estoy mosqueado porque el otro día vino un compañero y me dijo que no estaba conforme con lo que plantea la AOP. Ese ca... que no sabe nada, lo más seguro es que tenga envidia o no ame tanto a la empresa como yo. Como soy persona razonable, le estuve argumentando que mejoraba la modularidad, que permitía la separación de preocupaciones (SoC) lo que nos iba a mejorar la reutilización, ese gran palabro, e incluso la reconfiguración dinámica."

Sin duda alguna, nuestro amigo y gran profesional al poco tiempo en el proyecto, lamentaría la decisión. No hay que mal interpretar esto, AOP es buena, tan buena como la SoC, la modularidad, y todas esas cosas. Y es más, me atrevería a decir que la AOP es lo suficientemente madura como para trabajar con ella pero a no ser que hagamos software artesano de momento la cosa esta verde.

Esta verde porque le falta integrarse en los métodos ingenieriles de desarrollo software. Realmente el problema viene dado en gran medida porque la AOP trata los requisitos no funcionales del sistema como elementos a modelar y que luego tendrán su reflejo en uno o más artefactos llamados aspectos. En mi opinión, a los requisitos no funcionales desde el punto de vista de la ingeniería del software no se les ha dado la importancia que merecen.

Sintentizando un poco, considero que antes de plantearnos utilizar la AOP de forma conjunta con la OOP deberían resolverse los siguientes puntos, algunos de ellos vinculados entre si:

• Delimitar perfectamente lo que es requisito funcional y no funcional (-ilities, etc). Si, ya, si todos lo sabemos, ¡pero que listos somos! .
  
  
• Adecuar los métodos de la ingeniería del software, desde la captura de requisitos hasta la codificación. Bueno, a lo que representa la AOP también se la llama AOSD por algo . Ver Survey of Aspect-Oriented Analysis and Design Approaches
  
  
• Establecer pautas de modularidad de los aspectos. La AOP hace el código funcional más modular pero hay que tener cuidado con el acoplamiento y la cohesión de los aspectos. No existe una forma más o menos formal para determinar si una preocupación (concern) se traduce en uno o varios aspectos. Los aspectos, incluso de preocupaciones distintas, pueden tener "interferencias".
  
  
• Proporcionar una visión más abstracta de la AOP. Los lenguajes de aspectos actuales como AspectJ son demasiado "de bajo nivel".
  
  
• Falta de elementos de representación y notación como en UML. Existen numerosas propuestas pero ninguna definitiva.
  
  
• Herramienta de pruebas, al estilo JUnit, específicas para AOP. Actualmente hay en desarrollo varias propuestas como aUnit. Hay un artículo bastante interesante en http://www-128.ibm.com/developerworks/java/library/j-aopwork11 y enlaces de interés en http://www.csc.ncsu.edu/faculty/xie/aoptv.html

Se habrán quedado muchas cosas en el tintero y probablemente sobrarán otras tantas pero por ahora solamente os invitaré a que disfrutéis de las nuevas posibilidades de la AOP de la mano de AspectJ 5 y AJDT.

Posted at 09:00PM dic 30, 2005 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]

AspectJ 5: Un nuevo pasito en la AOP

Algunos afirman que el día de hoy entrará en la historia de la Programación Orientada a Aspectos. Esta afirmación puede parecer un tanto excesiva sobre todo porque, aunque parece algo novedoso, este paradigma ya tiene un tiempo. Sin embargo, esta release tiene gran trascendencia.

AspectJ es el framework-herramienta AOP estándar de facto. Sin ánimo de comparar la velocidad con el tocino , no sería descabellado decir que es el Struts de hace unos años. Pero AspectJ no esta solo, hay más jugadores compitiendo por hacerse un hueco en este mundillo. Hay dos artículos muy interesantes: AOP tools comparison (1) (2) a este respecto. Resumiendo muy brevemente podríamos decir que los jugadores son: AspectJ, AspectWerkz, JBoss AOP, Spring AOP y algunos otros como el proyecto JAC (actualmente dentro de JACQUARD).

AspectWerkz 2.0 es, o mejor dicho, era una herramienta magnífica con unas grandes capacidades, especialmente en LTW y definición de aspectos mediante XML. Este proyecto, bajo el paraguas de BEA, afortunadamente se ha fusionado con en el proyecto AspectJ. Algo parecido sucede con Spring AOP donde la integración con AspectJ es prácticamente un hecho.

Supongo que esta clara la posición de AspectJ en el mundo AOP, pero ¿qué tiene de especial esta realease?. Pues "simplemente" que es el paso de la prehistoria al presente. Algunas de las novedades son las siguientes:

• Soporte completo para Java 5 (generics, autoboxing y unboxing,...)
• Integración con anotaciones
• Definición de aspectos mediante XML
• Entretejido en tiempo de carga LTW
• Nueva API para la reflexión
• ...

Dejaré para otro día con más tiempo un análisis más detallado. Pero si me gustaría terminar con una llamada de atención. En mi muy modesta opinión, básicamente las grandes bazas de la AOP son la SoC, es decir, la mejora de la modularidad, y la posibilidad de tener sistemas dinámicos en los que los aspectos puedan añadirse, eliminar,... En esto último todavía hace falta mucho trabajo puesto que el uso de proxies dinámicos no es flexible ni satisfactorio y el uso de instrumentación del bytecode (JVMTI) tiene grandes limitaciones. Tal vez los próximos avances en la AOP deberían centrarse en la JVM como parece que se esta intentando hacer con JRockit. ¿Donará BEA JRockit a Harmony?. Nos aguarda un futuro interesante .

Posted at 09:40PM dic 20, 2005 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]

Un nuevo reto

Comienzo este blog con una gran ilusión y con la esperanza de convertirlo en un punto de encuentro con las personas que deseen pasar por aquí. Es posible que la expresión "join point" no sea la más correcta para expresar esta idea, pero es una licencia, un juego de palabras que como "aficionado" a la programación orientada a aspectos me he permitido.

Soy consciente de que mantener este blog con una periodicidad aceptable y unos contenidos que puedan interesar a alguien no es tarea sencilla y requiere tiempo libre, algo que ya no recuerdo lo que es .

Me gustaría presentarme muy brevemente porque considero que es de recibo. Mi vida discurre en la ciudad del Pisuerga y del Esgueva, en el centro de Castilla y León, en Valladolid. A falta de terminar esa pesada losa que es el proyecto, soy Ingeniero Informático e Ingeniero Técnico en Informática de Sistemas. Actualmente soy analista/programador en una empresa, de cuyo nombre no quiero acordarme, y trabajo para la administración regional.

Supongo que sobra decir que me encanta Java, simplemente diré que para mi es el lenguaje ideal para la mayoría de las situaciones, que no todas. Además siempre he considerado que "el mundo java" es lo suficienteme libre para mi, que me considero un defensor racional del Software Libre.

Actualmente estoy centrado en el mundo de la programación orientada a aspectos e intentando impregnarme del paradigma P2P con JXTA. Esto es así, porque estoy tratando de desarrollar un esbozo de middleware basado en el paradigma AOP, simplificando, un sistema distribuido de gran escalabilidad en el que los servicios los proporcionen aspectos. Un objetivo claro, además de presentar el proyecto no dentro de mucho , es proporcionar arquitecturas dinámicas descritas mediante un ADL que potencie la SoC.

Realmente me apasionan muchos más temas de este mundillo, como el desarrollo web (spring, JSF,...), la inteligencia artificial,... y otros temas más ingenieriles.

Bueno, no quiero alargarme más en esta primera entrada pero antes de despedirme invitar a todos a pasar por aquí de vez en cuando y a dejar vuestros comentarios. Espero hacer un blog útil para todos. Un saludo y nos vemos aquí...a cualquier hora .

Posted at 10:07AM dic 18, 2005 by Ricardo Santamaría Bogónez in General  |  Comentarios[0]