Java Server Faces: La siguiente generación de MVC Web

Llevaba tiempo queriendo aprender esta nueva tecnología que lleva años dando vueltas por el JCP (Java Community Proccess) pero que no terminaba de florecer. Tengo que reconocer que esta vez fuí infiel a Manning y terminé comprando el libro de O'reilly cuyo título es "Java Server Faces".
La meta de esta tecnología es abstraer lo suficiente el desarrollo de aplicaciones web, el protocolo http y sus limitaciones, para conseguir que los desarrollos que hagan al estilo de aplicaciones gui (por eventos) de toda la vida. Según parece le pidieron al mismísimo Craig R. McClanahan (creador del framework de Struts) que les ayudase con la especificación de la tecnología. Y, actualmente le han pedido unirse al proceso de especificación a Howard Lewis Ship, el creador de Tapestry, dado que este framework hace que las aplicaciones web sean todavía más parecidas al modelo de desarrollo por eventos.
La verdad es que cuando uno se enfrenta con Java Server Faces por primera vez nota unas ciertas reminiscencias con respecto a Struts. Cosas como la validación y el control de la navegación así lo demuestran, aunque el grado de sofisticación es mucho mayor.
Aunque Java Server Faces sea una tecnología reciente, es cierto que tiene un esfuerzo que demostrar, y es conseguir integrar la funcionalidad de AJAX en las propias especificaciones de la tecnología. En caso de que no sea así, dudo que JSF ocupen el lugar en el mundo del desarrollo de aplicaciones web que sus autores reclaman.
Java Server Faces dispone de un catálogo de componentes gui que facilita la vida a los desarrolladores de webs, además existen distintos catálogos por parte de todo tipo de fabricantes (open source y propietarios).
Yo solo he tenido oportunidad de trabajar con la implementación de Apache llamada MyFaces. Además de dicha implementación disponen también de más componentes gracias al proyecto Tomahawk así como el proyecto Tobago.
La curva de aprendizaje de Java Server Faces yo diría que es más pronunciada que la de Struts, quizás debido a que viniendo de Struts se tienen una serie de manias innecesarias.
En Java Server Faces el código de la aplicación va en beans que son registrados en un archivo xml en el que se configura la aplicación JSF. La manera de configurar los beans de la aplicación recuerda a Spring en el sentido de que permite la inyección de dependencias (o la Inversión de Control). Y ya que hablamos del archiconocido framework Spring, debemos dejar claro que la integración entre ambos resulta de lo más sencillo del mundo (solo hay que cambiar lo que se llama un "resolvedor de variables" para que sea spring quien se encargue de mapear e inyectar los beans en la aplicación).
Aparte de la curva de aprendizaje, con JSF se pueden hacer desarrollos más profesionales y con mejor calidad de código que con otros frameworks en menos tiempo. Gracias a todos los componentes que se pueden usar out-of-the-box así como la filosofía de orientación a eventos que supone, hacen que la aplicación resulte muy completa.

AOP: ¡Enriquece tus programas con aspectos!

Lo primero pedir disculpas por no haber escrito en el blog desde hace tanto tanto tiempo. La vida moderna de trabajador junto con las actividades extralaborales hacen complicado dedicarle tiempo a escribir artículos. La verdad es que fue una sorpresa encontrarme con un compañero recién llegado a mi antigua empresa que me contó que leía mi blog (¡hay gente que me lee!).
He decidido cambiar de aires, y cambio de trabajo y de casa (aunque no de ciudad). Aire nuevo aspecto nuevo, ¿no?
La programación orientada a aspectos no deja de ser una abstracción más a las abstracciones que se han ido realizando para crear lenguajes que cada vez son de más alto nivel. Igual que la orientación a objetos es un paso más de la programación procedural, los aspectos son el siguiente paso. No sé como se encontró el lector cuando paso de procedural a oop, pero yo recuerdo que durante un tiempo se me puso cara de no terminar de entender nada y encontrarme en un mar de dudas. Y la verdad es que en cierta manera me ha pasado lo mismo cuando he pasado de oop a aop.
¿Qué necesidad hay para la AOP? Cuando uno se pone a programar una aplicación se da cuenta de que hay una serie de cosas que se repiten en la mayor parte de los componentes de la aplicación. Por ejemplo, el traceo o logueo de mensajes, la seguridad, la caché, las transacciones... Son todos conceptos que tocan muchas partes de la aplicación que no tienen nada en común. En inglés, a este concepto se le llama crosscutting concerns (conceptos concernientes a distintas partes de la aplicación).
Para entender mejor la AOP conviene definir unos conceptos básicos: join points, point cuts, advices y aspects.

Join Point (punto de unión): lugar de la aplicación donde puede producirse una unión entre el aspecto y el programa. Son lugares que el compilador de aspectos puede reconocer y donde pueden introducirse advices. Como ejemplos podemos citar constructores, llamadas a métodos, asignaciones de variables...

Point cuts (Cortes de punto): Para definir en qué join point queremos actuar deberemos definir los point cuts. Un point cut no deja de ser una expresión regular (con sus particularidades) que indica en qué puntos de unión queremos meter los distintos advices.

Advices (avisos): Un advice en AOP se puede comparar a un método en OOP, aqui otra vez encontramos peculiaridades. Hay distintos tipos de advices: before, around y after y estos se pueden definir de manera que refinen más todavía el momento de actuación respecto al point cut asociado. Imaginemos que tenemos un point cut para un método de determinada clase pero solo queremos que nuestro advice actue cuando dicho método lance una excepción... Este tipo de refinamiento es posible en la declaración del advice.

Aspect (aspecto): Un aspecto en AOP viene a ser lo que un objeto en OOP. Un aspecto se compone de los point cuts, los advices y todo el código que se quiera. Dentro de un aspecto podemos usar objetos, de manera que dentro de un advice podemos tener la lógica de, por ejemplo, el traceo de la aplicación (haciendo las importaciones adecuadas, p.e. log4j).

¿Y todo esto como se come? Pues después de habernos hecho nuestros aspectos pasamos a usar el compilador de aspectos. Un compilador de aspectos lo que hace es tejer (weave) el código del programa con el de los aspectos, dando como resultado un código compatible con la tecnología (en caso de aspectj y java, no da un bytecode compatible).

Por supuesto, esto solo es una introducción a la programación orientada a aspectos, pero espero que sirva a alguno para introducirse en tan fantástica tecnología.