Modelo de Joint Point (I)

El modelo de "joint point" está compuesto de dos partes claramente diferenciadas: los propios "join point", que no son más que puntos en la ejecución de un programa, y los "pointcuts", un mecanismo de selección de los puntos anteriores.

Imaginemos por un momento que nos encontramos desarrollando un sistema que necesita gestión de la seguridad, algo muy común en el mundo en el que nos movemos, y, que, debido a la naturaleza transversal del mismo, elegimos AOP como enfoque principal nuestra solución. ¿Cuáles son los pasos que deberíamos seguir?

• Identificar los puntos del sistema que necesitan ser protegidos, comprobando, antes de realizar el acceso, que el usuario que está realizando el acceso está autenticado y tiene los privilegios necesarios para hacerlo. En resumen, estamos identificando los "joint point" que requieren ser securizados.

• Construiremos un pointcut (o varios, todos los que sean necesarios), que permitan la selección de los "joint point" descritos en el punto anterior.

• Construiremos un aspecto que encapsule toda la lógica de seguridad requerida.

Los conceptos anteriores son sumamente importantes dado que componen la base de AOP. A lo largo de los siguientes postz profundizaremos en cada uno de ellos.

Para terminar esta entrada simplemente analizaremos la definición de joint point:

Un join point es un punto de ejecución en un sistema. Así por ejemplo, el acceso al campo de una clase, la ejecución de una función o una sentencia for son ejemplos claros de join points.

AspectJ solamente expone un subconjunto de todos los posibles joint points, limitando de este modo, el acceso a las construcciones más estables.

En el siguiente post analizaremos con un poco más de profundidad los pointcuts,para, posteriormente, analizar las categorías de joint points existentes.

Hasta pronto,

Migue

AOP Benefits

Muchas de las críticas sobre la metodología AOP argumenta que en muchas ocasiones es demasiado complejo.

Personalmente, creo que al igual que cuando otras metodologías dieron el salto, como por ejemplo OOP, la novedad hace de ella su principal handicap.

Algunos de los beneficios del uso de una metodología AOP:

• Responsabilidades claramente diferenciadas . Cada módulo es el responsable de su funcionalidad principal; dejando a un lado los conceptos transversales (croscutting concerns). Así por ejemplo, un módulo cuyo principal cometido es implementar la lógica de acceso a datos de un sistema de ventas por internet, no tendrá que preocuparse de realizar pooling sobre la base de datos o de la transaccionalidad. Gracias a esta clara asignación de responsabilidades conseguimos una alta trazabilidad entre los requisitos y su correspondiente implementación.

• Incremento de la modularidad . Utilizando AOP conseguimos manejar cada uno de los conceptos de manera independiente con un acoplamiento mínimo. Incluso aunque tengamos presentes conceptos transversales que afecten en todos los ámbitos del sistema, la implementación resultante es modular.

• Retraso en las decisiones de diseño . Cuando se arquitecta un nuevo sistema siempre aparece el siguiente dilema: ¿debemos realizar un diseño sumamente complejo y detallado que intente abarcar todas las funcionalidades,incluso las futuras? o, por el contrario, ¿debemos arquiectar una solución que se corresponda con la situación actual?.

  Gracias a AOP, el arquitecto de la solución, puede retrasar la toma de determinadas decisiones de diseño dado que los futuros requerimientos se implementarán en aspectos independientes.

• Mejoras/Evoluciones más sencillas . AOP permite añadir una nueva funcionalidad sin más que desarrollar un nuevo aspecto (el cual no afecta al núcleo del sistema). Gracias a ello, el tiempo de respuesta ante nuevos requerimientos disminuye notablemente puesto que la implentación y diseño de los nuevos requisitos no supondrán, idealmente, una modificación del núcleo del sistema que estamos construyendo.

• Reutilización del código .AOP establece cada uno de los aspectos es un módulo independiente, de modo que resultan independientes entre si. En general, cada uno de ellos no suelen tener conocimiento del resto de elementos que conforman el sistema final.

  El único elemento consciente del acoplamiento entre los diferentes módulos son las reglas de tejido (weaving rules) , de modo que, si cambiamos éstas, podemos componer un sistema final completamente diferente.

• Reducción de costes. Las características descritas en los puntos anteriores generan sistemás desarrollos mucho más rápidos. Asimismo, eliminando la necesidad de modificar múltiples módulos para la implementación de un nuevo concepto que afecta al sistema completo, AOP provoca que dicha implementación sea más barata.

• Areas de conocimiento. Permitiendo que los desarrolladores estén centrados en su especialidad lograremos que el coste del desarrollo disminuya puesto que estaremos concentrando los esfuerzos.

En siguientes post veremos una introducción a AspectJ para adentrarnos un poquito más en el mundo de la orientación a aspectos.

Hasta pronto!