Mapeo Sencillo Con Configuración AOP De Spring Framework

Mapeo Sencillo con Configuración AOP de Spring Framework

Esta serie de documentos tiene por objetivo presentar ejemplos de tipos de mapeos que se pueden realizar con Hibernate 3 y Java Persistence API ( JPA ). La intención es cubrir paulatinamente con ejemplos desde los mapeos más sencillos, hasta los más complicados.

En este tercer documento se configura funcionalidad AOP a Spring Framework para automatizar el manejo de conexiones y transacciones en una aplicación, y de esta manera simplificar enormemente el código de persistencia de una aplicación empresarial.

Una aplicación que maneja manualmente el código de conexión a base de datos y las transacciones tiende a repetir mucho código “de plomería”. Especificaciones como EJB fueron diseñadas en principio para eliminar ese tipo de responsabilidades de los hombros del programador; pero como se muestra en este tutorial este tipo de soluciones no están limitadas a aplicaciones que son ejecutadas en un EJB container.

Código Repetido

Comencemos por analizar uno de los métodos que se ha venido utilizando hasta el momento para la inserción de un registro hacia la base de datos:

public int insertObject

( FacturaDTO factura )

{

Session session =

_sessionFactory.openSession();

try

{ insertObject( session, factura ); }

finally

{ session.close(); }

return factura.getId();

}

private void insertObject

( Session session, FacturaDTO factura )

{

boolean commit = false;

Transaction transaction =

session.beginTransaction();

try

{

session.save( factura );

commit = true;

}

finally

{

if( commit )

transaction.commit();

else

transaction.rollback();

}

}

El listado anterior contiene bloques de código que se repiten para métodos similares:

 El código de apertura y cierre de una conexión ( sesión ) siempre es el mismo para todos los métodos de la clase. Nótese que la sesión se abre al inicio del método, y se cierra en un bloque try/finally.

 El código de manejo de transacciones es el mismo para todos los métodos transaccionales de la clase. Por su parte, los métodos no transaccionales no incluyen este código.

Si se considera el efecto acumulado del código que se repite en clases de lógica de negocio, aún tan sencillas como las que se muestran en estos tutoriales, el efecto acumulado es considerable, y oscurece la lógica de negocio propia de la aplicación.

Lo ideal en este caso es poder reutilizar de alguna manera todo este código. La pregunta es ¿ cómo ?

El tipo de código repetido que se maneja en estas clases no es fácil de extraer por medio de estrategias básicas en programación orientada a objetos como son el manejo de delegación o de herencia. Esto se debe a que este tipo de código no se presta a ser separado al estar inmerso en métodos diferentes con firmas diferentes.

La aplicación de algunos patrones de diseño específicos pueden ayudar a extraer efectivamente este código, aunque en este caso se requerirá implementar arquitecturas particulares en un desarrollo. A veces la complejidad introducida por una arquitectura no justifica su aplicación; y en ocasiones sí lo justificará. Sin embargo, la pregunta sigue en el aire: ¿ existe una alternativa sencilla y práctica de reutilizar este código ?

Aspect Oriented Programming ( AOP )

La programación por aspectos es una extensión de la programación orientada a objetos ( OOP ), y buscar resolver problemas de reuso de código en situaciones en que ni la herencia ni la delegación pueden ser utilizadas de forma satisfactoria. El ejemplo de reuso de código de conexiones y transacciones es una muestra de un tipo de estas situaciones.

A este tipo de código que se repite en diferentes métodos de diferentes clases en una aplicación, cuando dichos métodos no tienen relación alguna entre sí ( en el tipo de interfase que usan, los parámetros que reciben y sus valores de retorno ) se le denomina típicamente crosscutting concerns. Además de los ejemplos que se han dado, otros ejemplos de este tipo de código es el manejo de seguridad declarativa, manejo de bitácoras, código de auditoría, manejo remoto de objetos, mecanismos transparentes de activación / pasivación de servicios, etc.

Una de las características más importantes dentro de AOP es la habilidad de definir interceptores; esto es, código que se ejecute siempre alrededor de otro de forma transparente hacia el cliente. Suponiendo que un método contiene la lógica necesaria para la inserción de datos hacia una tabla, el código que abre y cierra la conexión, y que hace el procesamiento de transacciones se puede definir en un interceptor como se muestra en la siguiente imagen:

Este mecanismo permite extraer todo el código repetido en los métodos de la claseObjectManagerImpl.

Mejor aún, el mismo interceptor puede ser aplicado a diferentes clases con diferentes métodos que requieran extraer el código repetido en todas ellas:

En pocas palabras, un mismo interceptor puede ser reusado sobre múltiples clases de lógica de negocio en una aplicación.

La clave para que el manejo de interceptores AOP sea transparente a un cliente está en el manejo de interfases para las clases que implementan el servicio. Si el cliente dependiera directamente de una implementación, sería más difícil agregar un intermediario que ejecutara la lógica para el manejo de conexiones y transacciones:

En cambio, desde tutoriales pasados se ha insistido que el cliente dependa de una interfase (ObjectManager ) y no de una implementación ( ObjectManagerImpl ):

En un escenario de este estilo, cuando aún no se han definido interceptores a un programa, lasinvocaciones se realizan directamente sobre la implementación; aunque la dependencia que se tiene en la clase cliente se realiza sobre la interfase. Entender con claridad este punto es esencial.

Podemos ver la dependencia que el cliente sobre la interfase ( y no la implementación ), si verificamos el siguiente fragmento de código asociado a la clase Test.java:

/**

* Método de ejecución de altas, bajas,

* cambios y consultas.

*/

private void execute() throws Exception

{

ObjectManager manager = getObjectManager();

...

}

De esta manera, es posible agregar un intermediario que trabaje de forma transparente al cliente.

Hay un patrón de diseño llamado “Proxy” que describe este tipo de arquitecturas. De hecho, una traducción al español de la palabra inglesa “Proxy” es “Intermediario”. El interceptor AOP del que hemos venido hablando implementa dinámicamente las interfases de negocio de los servicios que queremos extender, y por lo tanto podría describirse como un proxy dinámico ( dynamic proxy ).

Existen muchas maneras para realizar manejo de AOP en java. Algunas librerías se dedican a definir maneras de integrar esta funcionalidad a la plataforma siguiendo distintas aproximaciones . Ejemplos de ellas son:

 Aspect/J ( http://eclipse.org/aspectj/ )

 Nanning Aspects ( http://nanning.codehaus.org/ )

 Aspectwerkz ( AW - http://aspectwerkz.codehaus.org/ )

 Spring Framework ( http://www.springframework.org/

Mediante el soporte a AOP definido en Spring Framework, es posible implementar la funcionalidad para manejo de conexiones y transacciones de la que se ha hablado hasta este momento.

De hecho, no es ni siquiera necesario crearlos, ya que Spring Framework incluye todas las clases necesarias para definir funcionalidad AOP para el manejo de conexiones y transacciones en clases desarrolladas con JDBC, Hibernate, JPA, JDO y otras aproximaciones. Unicamente hay que declarar los servicios, y personalizarlos a través del uso de anotaciones sencillas.

Las siguientes secciones mostrarán cómo se hace esto.

Estructura de la Aplicación

La siguiente imagen ilustra la estructura de la aplicación que se presenta en este tutorial:

Como puede verse, es la misma estructura manejada en el tutorial básico de Spring Framework. La diferencia será en los servicios definidos, y en el código de la interfase y la implementación del servicio.

El código del DTO que se mapea hacia la base de datos no cambiará significativamente con respecto a los tutoriales anteriores, ni tampoco el código de la clase de prueba utilizada. Por lo tanto, no se hablará de estos elementos a lo largo de este documento.

Todo el código de esta aplicación puede ser obtenido a partir de aquí.

Configuración de Spring Framework: services.xml

En este caso, al archivo de configuración de Spring Framework se le agregará soporte para un servicio de transacciones, y también se le agregarán algunos servicios adicionales para el manejo de AOP.

El contenido de este archivo quedaría finalmente como sigue:

<?xml version='1.0'? >

...