SBCD - Interceptores: AOP en clave de EJB 3

(Imagen: Pablo Picasso - Masace en Korea)

Mientras esperamos en primer post de Gero, hablemos un poco de AOP y EJB 3. La programación orientada a aspectos (Aspect Oriented Programming , espero esté bien traducido ), sostienes que los temas "tangenciales" a la aplicación deben ser separados de la lógica de negocio de modo que no la contaminen y deben existir en componentes independientes.

A ver, traduzcamos esto. Por ejemplo, seguridad. ¿Cuántas veces han visto esta sentencia?

if (usuario.estaEnSesion() && usuario.tienePrivilegios()){
realizarAccion()
}else {
solicitarAutenticacion();
}

Muchas veces,...no? (si no es así... seguramente eres cachimbo). Antes de proceder a realizar una transacción propia del negocio se debe validar que el usuario posea los privilegios para hacerlo. Y hay que comprobar esto para cada método de negocio!! Lo mismo pasa con los temas de auditoría (registrar quien y cuando modificaron tal registro), y al final terminamos con nuestra correctísima lógica de negocio salpicada con esas sentencias de negocio que nada tienen que ver. Para eso está AOP, de modo que extraigamos esa lógica y la pongamos en componentes separados... y en el caso de EJB 3 estos componentes son los interceptores (recuerdan a los filtros de Servlets?? actúan de manera similar). Existen frameworks mucho más complejos para el tema de AOP, como AspectJ, pero eso ya es otro rollo.

Entonces, la idea de un interceptor es que su lógica se ejecute antes de la invocación de los métodos de negocio de una instancia EJB. Estos interceptores pueden definirse en la misma clase del bean, o en una clase aparte llamada clase interceptora (¿original...no?). Y para un bean, podemos definir el número que queramos de clases interceptoras (Nota para el examen: Una clase interceptora debe poseer un constructor público sin argumentos).

La vida de un interceptor está bastante relacionada con la del bean al que intercepta. Son como siameses!!! . Cuando se crea la instancia bean, se crea luna instancia por cada interceptor de la clase (recordar que pueden ser muchos!). Así mismo, cuando la instancia Bean es removida se lleva a sus interceptores a la tumba. Ah..! Y esto tambien se aplica para la activación /pasivación de los stateful SB.
Básicamente, tenemos dos tipos de interceptores: Los interceptores de métodos de negocio y los interceptores de métodos del ciclo de vida . En este post, que ya está un tanto largo, vamos a ver los primeros...y ya a los otros los vemos con calma después que Gero publique su primer post.

Los interceptores de métodos de negocio son aplicables a los métodos de negocio (duh!) de los session beans y a los métodos message listener de los beans message driven (prometo un post de esto después. Palabra). Para definir un método interceptor, hacemos uso de la anotación @AroundInvoke o del correspondiente elemento del descriptor de despliegue around-invoke . Cuando se definen métodos AroundInvoke en una clase Interceptora, tener presente que sólo puede tener un método AroundInvoke. (Otra nota para el examen: Los métodos @AroundInvoke no pueden ser definidos final ni static).

Los métodos AroundInvoke tienen esta forma:

Object nombredelmetodo (InvocationContext context) throws Exception

En lo que se refiere a excepciones, los métodos AroundInvoke puede lanzar RuntimeExceptions o excepciones de aplicación definidas en la clausa throws del método de negocio que intercepta. Asimismo, los métodos AroundInvoke pueden parcar la transacción para rollback medianre EJBContext.setRollbackOnly() o lanzando una excepción Runtime.

Bueno...esto ya se hizo largo y ya me cansé. Mañana la sigo. Hasta otra..!!