Este es uno de los campos típicos donde se aplica la Programación Orientada a Aspectos [Laddad03], que nos proporciona los mecanismos para implementar esta funcionalidad de una manera sencilla. El objetivo es mostrar las llamadas a los métodos con sus parámetros, la finalización de estas llamadas y las excepciones que ocurren durante la ejecución.

La tecnología que mejor se adapta es AspectJ, desarrollando un aspecto que se aplique a todas las clases y que pueda deshabilitarse tras la fase de desarrollo de una forma sencilla. También debe permitirse el filtrado de los mensajes de logging a nivel de clase, paquete o tipo de mensaje (entrada de método, salida de método o lanzamiento de excepciones). Para ello este aspecto deberá utilizar un framework como Apache Commons Logging que proporciona una capa de abstracción sobre otros sistemas de logging que pueden ser configurados declarativamente, como Log4J, que será el usado normalmente por su sencillez de configuración y potencia de uso

El aspecto desarrollado LoggingAspect es totalmente genérico y aplicable a cualquier sistema. Algunas consideraciones que ha sido necesario tener en cuenta son:

La implementación de estos métodos aunque no es siempre imprescindible suele ser deseable, y supone una tarea tediosa que hay que realizar en cada clase que se implementa. Para facilitar o incluso evitar esta tarea se crea una clase que hará de raíz de la jerarquía de clases siempre que sea posible, implementando de manera genérica los métodos toString, equals, hashCode y clone haciendo uso extensivo de los metadatos que proporciona Java a través del API reflection. Para facilitar este trabajo ya existen proyectos de la ASF, principalmente los proyectos commons-lang y commons-beanutils.

Como soporte a la auditoría se creará el paquete auditing, creándose en primer lugar un interfaz Auditable que deben implementar aquellos objetos que pretendan ser auditados. Tal y como se mencionó en “Auditoría”, aquellos objetos auditables deben tener:

Junto con este interfaz se crea una implementación por defecto AbstractAuditableObject de la que pueden heredar otras clases.

Se seguirá en patrón Business Object [AlurCrupiMalks03] para reflejar el modelo conceptual del dominio. Estos objetos del dominio serán persistidos mediante Hibernate, por lo que es necesario afinar los métodos definidos en BaseObject, lo que se hará en la clase AbstractBusinessObject, debido a que Hibernate puede utilizar una caché perezosa para cargar las colecciones, con lo que los métodos toString, equals y hashCode definidos en la superclase se sobrecargarán para ignorar colecciones. El método clone debe ser también sobrecargado para evitar que una colección sea referenciada por dos objetos distintos, restricción que impone Hibernate y que se soluciona creando una nueva colección pero con los mismos objetos.

Para facilitar la implementación de los tests, principalmente en cuestiones relacionadas con la integración del framework Spring, se han realizado unas clases utilidad.

Para acceder a los datos se utilizará el patrón DAO (Data Access Object [AlurCrupiMalks03]) que ocultará la implementación utilizada por si se diera la necesidad de cambiarla en el futuro. Dado que la persistencia será gestionada en principio con Hibernate, que permite el acceso a gran cantidad de metadatos, se intentará realizar un DAO genérico que proporcione los servicios de persistencia para cualquier clase sin necesidad de escribir más líneas de código.

Se usará también el soporte que proporciona Spring para la integración con Hibernate, concretamente la clase HibernateDaoSupport. Se implementará un DAO genérico, HibernateDao, con las siguientes operaciones típicas:

Dado que el DAO será genérico es necesario pasarle la clase a la que proporcionará persistencia en el momento de su creación.

Para ocultar detalles de implementación se crearán dos interfaces:

La configuración dentro del contexto de aplicación de Spring se puede ver en el fichero applicationContext-oness-common-model.xml, donde está centralizada para todo el sistema.

    <!-- Session Factory -->
    <bean id="sessionFactory" 
        class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
        <property name="dataSource">
            <ref bean="dataSource" />
        </property>
        <property name="mappingResources">
            <ref bean="mappingResources" />
        </property>
        <property name="hibernateProperties">
            <ref bean="hibernateProperties" />
        </property>
    </bean>

    <!-- Transaction manager for a single Hibernate SessionFactory 
         (alternative to JTA) -->
    <bean id="transactionManager" 
          class="org.springframework.orm.hibernate.HibernateTransactionManager">
        <property name="sessionFactory">
            <ref local="sessionFactory" />
        </property>
    </bean>

En este fichero se establece la configuración general de Hibernate aplicable a todos los módulos, el sessionFactory y el gestor de transacciones. Se delega en los contextos de aplicación de cada módulo para la configuración concreta, así se centraliza y se evita la replicación de estos parámetros. En concreto se espera que cada módulo defina un bean llamado mappingResources que por ejemplo podría ser algo como esto:

    <bean id="mappingResources" class="java.util.ArrayList">
        <constructor-arg>
            <list>
                <value>net/sf/oness/party/model/party/bo/Party.hbm.xml</value>
            </list>
        </constructor-arg>
    </bean>

También se evita la definición de los beans dataSource e hibernateProperties para permitir utilizar indistintamente un dataSource local usando por ejemplo commons-DBCP o uno obtenido mediante JNDI, útil en servidores de aplicaciones J2EE. Tan sólo es necesario definir en tiempo de ejecución cuál de los siguientes ficheros se añaden al contexto de aplicación:

En este apartado se implementará lo definido en “Auditoría”, creando un aspecto que intercepte las llamadas a los DAOs de la siguiente manera:

En principio este aspecto se ha implementado con AspectJ, pero posteriormente se ha implementado mediante el soporte AOP de Spring dado que la primera opción requería utilizar el compilador de AspectJ y la segunda permite una integración más fácil dado que no modifica el bytecode java, sino que utiliza proxies dinámicos.

Para dar soporte se añaden los siguientes interfaces:

Para facilitar la utilización de fechas y rangos de fechas se crean las clases:

Para poder persistir estas clases con Hibernate como componentes y poder reutilizarlas es necesario implementar unos interfaces:

La configuración del aspecto se realiza dentro del contexto de aplicación de Spring en el fichero applicationContext-oness-common-model.xml para que esté disponible para todos los módulos del sistema.

<!-- AuditingDao AOP -->
<bean id="autoProxyCreator"
  class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
</bean>
<bean id="auditingDaoAdvisor"
      class="net.sf.oness.common.model.dao.AuditableDaoAdvisor">
</bean>

Se utiliza la funcionalidad de creación automática de proxies de Spring para que el aspecto se aplique automáticamente a todos aquellos beans definidos en el contexto de aplicación que cumplan el contrato establecido por el método matches del aspecto.

/**
 * @see org.springframework.aop.MethodMatcher#matches(java.lang.reflect.Method,
 *      java.lang.Class)
 */
public boolean matches(Method m, Class targetClass) {
    return AuditableDao.class.isAssignableFrom(targetClass);
}

Detro de este paquete se puede encontrar una implementación del interfaz List del api collections de Java que proporciona una manera de tratar listas paginadas, aquellas en las que normalmente sólo se accede a una pequeña porción, tal y como se define en el patrón ValueListHandler [AlurCrupiMalks03].

También se incluye DatabasePopulator, una clase que configurada desde el contexto de aplicación de Spring permite importar datos de un fichero de DBUnit tanto en formato xml como xls (Excel) en la base de datos. Se utilizará para insertar los datos de ejemplo para las demostraciones.

El controlador constará de la clase PartyAction, que gestionará todas aquellas acciones que realice el usuario a través de la vista y las transformará en llamadas a la fachada de la capa modelo.

La vista estará formada por las páginas JSP, los mensajes de la aplicación y los ficheros de configuración.