Advice Weaving

Una de las fases mas importantes de AOP es el weaving. Una ves definido los aspectos, o sea, haber indentificado los puntos de ejecución por donde se va a ejecutar un determinado código que hace a la separación en incumbencias, se debe "tejer" o unir los aspecto al sistema. Esto significa que hay que, de alguna manera, introducir los advise al sistema.

Dependiendo de la herramienta [1] que estemos usando para escribir los aspectos variará la manera en que se haga el weaving [2]. Básicamente hay dos maneras de implementar el weaving: de manera estática (compile time) o de manera dinámica (runtime). Entonces los diferentes tipos de implementaciones de weaving son:

• Compile-time weaving
• Class load-time weaving
• Hotswap weaving
• Runtime OO methods
• Bytecode modification weaving
• Dynamic proxy weaving
• VM level AOP

Estas implementaciones tiene ventajas y desventajas [2], las cuales permitiran tener mayor o menor control sobre los aspecto en diferentes fases del desarrollo (runtime, compile-time, debugging).

Como experiencia personal, la elección de un framework de AOP, fue la actividad más importante. Es necesario tener en cuenta ciertas características que están relacionadas con el proyecto. Como por ejemplo: qué capacidad tiene el framework de interactuar con la IDE (flexibilidad, performance, etc), cuántos proyectos se necesitan manejar a la vez, cual es el impacto en el desarrollo, y cual es el impacto en producción. Además de cuál es el alcance y las necesidades particulares para mi sistema. Teniendo en cuanta todo esto resultó que, para las características del proyecto, fue necesario utilizar Javaassist [3], aplicar interceptores en class load-time, y ahí enganchar los advice.

Lamentablemte AOP tiene un impacto en la performance que puede ser mayor o menor, pero que hay que tener presente; digo que, si bien la separación en incumbencias mejora la calidad de mi sistema, esto tiene un costo.

[1] http://java-source.net/open-source/aspect-oriented-frameworks
[2] The Aspect Blog
[3] http://www.csg.is.titech.ac.jp/~chiba/javassist/

Introduction to Aspect Oriented Programming

Para resolver los problemas vistos en: What's AOP? se desarrollaron conceptos y tecnologías bajo el nombre de Aspect Oriented Programming. Para poder entender los conceptos que se manejan en AOP enumeraré las terminologías mas utilizadas:

• Point-cut: Un pointcut describe un punto de ejecución del sistema. Puede estar compuesto por otros pointcuts. Los pointcuts pueden indicar una llamada a un método, la creación de un objeto, la escritura o lecturas de variables, el flujo en estructuras de control (if, while, for, etc), excepciones, el uso de una clase en particular entre otras cosas.
• Advice: Comprende el código que se ejecuta cuando se alcanza el punto de ejecución (join-point). Una analogía posible, para el mejor entendimiento de este concepto, se da con el paradigma de Objetos donde se distinguen los menajes y los métodos, entonces en AOP el Advice es análogo al método y el pointcut es análogo al mensaje.
• Join-point: Es el punto de ejecución que esta definido en el pointcut. Es el instante de ejecución por donde esta pasando el sistema. Es el lugar donde el Aspecto (Aspect) provee su servicio.
• Aspect: Es el conjunto dado por el Poincut y el Advice. Es la definición del servicio o tarea que se debe ejecutar.
• Introduction or mixin: Es la capacidad de hacer que una clase existente extienda de otra clase independiente de su árbol de jerarquía. O sea, se modifica una clase para que tenga método, interfaces, variables de otra clase. Esta característica es muy poderosa y permite, básicamente, crear múltiple herencia.
• Cross-cutting-concerns: Cada parte de un sistema tiene un objetivo principal, pero para conseguir su objetivo necesita de tareas secundarias que son comunes a todo el sistema. Por ejemplo, que los objetos sean transaccionales es una característica transversal a la misión de cada objeto, pero es necesaria para el cumplimiento de sus objetivos.

Para concluir con esta breve introducción analicemos el caso del Productor-Cosumidor, donde se accede a un buffer, pero este acceso debe ser sincronizado. La misión principal del Productor es llenar el buffer y la del Cosumidor es vaciarlo. Pero si ambos no están sincronizados no podrán concluir con éxito su objetivo. A nivel código tendremos que lidiar con lo específico de la sincronización mezclado con el código de la misión principal. En este punto es donde se dislumbra que la sincronización es un aspecto del problema del Productor-Consumidor y ponemos el código de sincronización como Advise. Entonces tendremos separadas las tareas necesarias para ejecutar la tarea principal; hemos separado las incumbencias. Como consecuencia nos quedará un código más claro, o sea, mejoramos la calidad del código.

What's AOP?

AOP, de la sigla Aspect Oriented Programming (Programación Orientada a Aspectos), es una tecnología que intenta resolver un viejo problema que surge en el desarrollo de software [1]. Este problema está relacionado con algo que se denomina separación de incumbencias.
Las incumbencias son asuntos o temas que se deben tener en cuenta para resolver un problema. Uno de estos asuntos está dado por el comportamiento principal de una tarea dada, pero para que esta tarea se lleve a cabo con éxito hay que tener en cuenta otros asuntos, como por ejemplo: la sincronización, la persistencia, la distribución, autenticación, etc. Estos asuntos se llaman Aspectos.

Al lograr la separación en incumbencias disminuye la complejidad de la tarea y mejoran la calidad, mantenibilidad, reusabilidad, etc.

La separación en aspectos es independiente del paradigma de programación que se esté usando para desarrollar el software. En el caso del paradigma orientado a objetos se puede ver el problema de la separación de incumbencias en algunos patrones de diseño, como por ejemplo: el Observer, el Visitor o el Mediator, donde para aplicarlos hay que adaptar a las clases involucradas este comportamiento.

Un caso típico de incumbencias son las denominadas incumbencias transversales (crosscutting concerns), donde aparecen las responsabilidades atravesando diferentes partes del sistema que son disconexas. Un ejemplo típico es el logging, el cual es requerido en varios puntos de ejecución del sistema que no están relacionados.

[1]Towards a Taxonomy of Aspect-Oriented Programming