Mecanismo de Load Time Weaving (LTW)

Durante la última entrada analizábamos de manera introductoria los diferentes mecanismos de tejido ofrecidos por AspectJ así como las principales características de los mismos. Durante esta entrada nos acercaremos un poquito más al mecanismo de tejido en tiempo de carga, por normal general más desconocido, desde mi punto de vista, que el mecanismo de tejido en tiempo de construcción (durante todos los ejemplos que hemos visto en anteriores entradas siempre hemos utilizado el tejido en tiempo de construcción).

Los pasos que tenemos que seguir cuando utilizamos el tejido en tiempo de carga son los siguientes:

• Iniciar nuestra aplicación con el archivo aspectjweaver.jar el actuando como un agente (hablaremos de agentes en otra entrada). Para ello podríamos utilizar una línea como la siguiente

java -javaagent:/aspectjweaver.jar

• Durante el proceso de inicialización del agente (llevado a cabo por la máquina virtual) el propio agente recupera aquellos archivos existentes en el classpath que coincidan con META-INF/aop.xml (en el caso de encontrar múltiples llevará a cabo la combinación de los mismos).

• Carga de los aspectos indicados.

• El agente se registra como un listener del evento de carga de clases de la máquina virtual. Mediante este mecanismo se tiene acceso a la definición de la clase, permitiendo incluso la modificación de la misma.

• Continua el proceso normal de carga de nuestro aplicación.

• Cada vez que una nueva clase es cargada la máquina virtual notifica al agente dicha situación. En ese momento es posible examinar la clase en cuestión y determinar si algunos de los aspectos cargados con anterioridad necesita ser tejido. En caso afirmativo, la clase será tejida con el aspecto en cuestión, retornando el bytecode resultante a la máquina virtual.

• La máquina virtual utiliza el bytecode resultante como elemento de definición de la clase.

Mediante el conjunto de pasos anteriores, aquellas clases que hayan hecho matching con las definiciones de nuestros aspectos tendrán incorporada la funcionalidad definida en éstos últimos.

El agente anterior utiliza un interfaz de la máquina virtual conocido como JVMTI (Java Virtual Machine Tools Interface) que ha sido introducido a partir de Java 5. En el caso de que utilicéis una versión anterior podréis hacer uso de este mecanismo mediante una versión basada en classloaders específicos.

Weaving en AspectJ (I)

Hace un tiempo escribí una serie de entradas relacionadas con la orientación a aspectos en general y AspectJ en particular (podéis encontrar dichas entradas aquí) que posteriormente agrupé en un documento.

Hasta este momento nos hemos centrado en la teoría de la orientación a aspectos, cómo escribir los mismos y algunas de sus posibles aplicaciones. Sin embargo, no hemos prestado especial atención al modo en el que los aspectos se combinan con las clases para componer nuestro sistema final. Durante esta entrada y las siguientes profundizaremos en diferentes aspectos del proceso de tejido (weaving).

El mecanismo de tejido es aquel que nos permite combinar la definición de nuestras clases y de nuestros aspectos en un ente ejecutable que conforma nuestro sistema final.

Podemos clasificar los diferentes modelos en base al momento en el que llevan a cabo el tejido. En este caso tendríamos:

• Build time. Las clases y los aspectos son combinados durante el proceso de construcción de nuestra aplicación.

• Load time (LTW). En este caso el tejido se realiza en el momento en el que una clase se carga en la máquina virtual, por lo que en este caso no será necesario llevar a cabo ningún proceso adicional en nuestro proceso de construcción. 

Otra posible clasificación podría establecerse en función del los tipos de entrada del proceso de weaving

• Source code weaving. La entrada al proceso son archivos de código fuente (clases y aspectos)

• Weaving binario (bytecode). La entrada al proceso es el bytecode obtenido como resultado del proceso de compilación de nuestras clases

De manera esquemática, a continuación se reflejan las diferente combinaciones ofrecidas por el weaver de AspectJ:

• Tiempo de construcción: las entradas admitidas son tanto código fuente como clases compiladas (bytecode)

• Tiempo de carga: las entradas pueden ser bytecode o un archivo xml (lo veremos más adelante)

Con esta pequeña entrada nos hemos aproximado de manera sencilla a los procesos de tejido presentes en AspectJ de una manera teórica. En futuras entradas analizaremos con un poco más de detalle los contenidos aquí presentados, haciendo especial hincapié en los mecanismos de tejido en tiempo de carga.

Hasta pronto!

Aspect Oriented Programming Intro Guide

Hace tiempo que habíamos comenzado una serie de post relativos a la programación orientada a aspectos y los tenemos dispersos a lo largo de diferentes entradas. He decido recolectar todos los post publicados junto a los que estaban por venir y hacer una sola entrega.

Espero que os guste:

Está escrito en docbook por lo que si alguien está interesado en los fuentes no tiene más que pedírmelos.

Hasta pronto!

Measuring layered architectures adherence

Software measure-slides

View more presentations from Miguel Pastor.

Groovlets

Me imagino que la gente dedicada al desarrollo web estará acostumbrada al concepto de servlet, y posiblemente, hayan escrito muchos de ellos.

Voy a mostraros una forma sencilla de escribir y configurar servlets en el lenguaje Groovy. Esta funcionalidad compilará nuestros archivos .groovy en el bytecode correspondiente, cargará la clase, y la cacheará, hasta que se produzca un cambio en el archivo groovy inicial.

El primer paso que vamos a dar es añadir el soporte para los Groovlets, para lo que necesitaremos añadir en el archivo web.xml de la aplicación web el siguiente fragmento de código:

<servlet><servlet-name>Groovy</servlet-name>

<servlet-class>groovy.servlet.GroovyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Groovy</servlet-name>
<url-pattern>*.groovy</url-pattern>
</servlet-mapping>

Ahora estamos en disposición de escribir un servlet en el lenguaje Groovy (llamemoslo hello.groovy). Veamos un ejemplo sencillito:

if (!session) {
  session = request.session(true)
}

if (!session.counter) {
      session.counter = 1
}

html.html {    // utilizamos del MarkupBuilder 
               // para construir una página tonta de respuesta
  head {
      title("Esto es un Groovy Servlet")
  }
  body {
    p("Bienvenido, ${request.remoteHost}: ${session.counter}! ${new Date()}")
  }
}


// incrementamos el contador en la sessionsession.counter = session.counter + 1

En el servlet (groovlet) anterior existen una serie de variables implícitas tales como, request, response, context, application, session, params, headers, out, sout y html.

Un paso adicional de configuración, sumamente importante, para poner nuestro groovlet en marcha, consiste en incluir las dependencias necesarias. La opción más sencilla es incluir el archivo groovy-all-XXX.jar en el directorio WEB-INF/lib de la aplicación web.

Si, por ejemplo, colocamos los archivos .groovy en el raiz de nuestra aplicación el servlet de groovy se encargará de compilar los archivos. En el caso de tomcat podríamos editar el archivo tomcat/conf/server.xml del siguiente modo:

<Context path="/groovy" docBase="c:/groovy-servlet-base"/>

Podríamos acceder al archivo creado anteriormente mediante la siguiente ur:l http://localhost:8080/groovy/hello.groovy


Hasta pronto,
Migue

JDT Weaving Service (y II)

Tal y como os había prometido en el post anterior, ahora os dejo un pequeño proyecto con un único archivo que contiene un programa de ejemplo del lenguaje que nos hemos inventado en la entrada previa.

Podeis obtener una copia de trabajo desde la siguiente URL del servidor subversion en el que está alojado:

http://reclipse.googlecode.com/svn/trunk/com.blogspot.miguelinlas3.ajdt.demoexample

Gracias al plugin cosntruido en la entrada anterior, el archivo de código fuente obtenido en el checkout anterior se visualizaría del siguiente modo:


Como veis, hemos integrado nuestro lenguaje de ejemplo en el modelo JDT de Eclipse de una manera relativamente sencilla.

Posiblemente ahora comienze a tener algo más de tiempo libre así que intentaré aumentar la frecuencia de los posts. Puede que en las siguientes entradas cambiemos un poco estas últimas entradas dedicadas a los lenguajes y sus entornos y veamos algo más "empresarial".

Hasta pronto!

Frameworks

Some weeks ago an interesting book arrives to my personal library :)

Practical API Design. Confessions of a Java.Framework Architect

Althought last weeks my enjoy time is not enought to read the whole book i have been reading the starting chapters. Anyone has read it completely?

Bye!

SpringDM,Maven y Eclipse: Introduction

No pretendo ni mucho menos dar una explicación detallada (tampoco podría) de la especificación OSGI, ni de maven ni Spring Dynamic Modules. Únicamente me gustaría dar una brevísima introducción y un pequeño ejemplo de uso de estas tecnologías para la construcción de aplicaciones distribuidas.

OSGI Service Platform determina una arquitectura común para proveedores de servicios,desarrolladores, . . . . para desarrollar, desplegar y trabajar con servicios de manera coordinada.

OSGI Framework compone el núcleo de las especificaciones, facilitando un framework Java de propósito general que permite el despliegue de aplicaciones (conocidas como bundles). De manera muy simplificada, nos facilita un entorno dinámico de ejecución de aplicaciones en que podemos instalar,actualizar o eliminar aplicaciones "en caliente". Modularidad y versionamiento son otras de las características principales de esta especificación.

La arquitectura establecida por el framework anterior es la siguiente:

Spring Dynamic Modules, de ahora en adelante SpringDM, nos permite construir aplicaciones basadas en Spring de modo que puedan ser desplegadas en un entorno OSGI (trabaja con Equinox,Felix y Knopflerfish) ya hacer uso de todoos los servicios ofrecidos por el mismo.

La combinación de estas dos tecnologías nos ofrece innumerables ventajas de las que podríamos enumerar algunas de ellas:

• Modelo de programación sencillo (y al que estamos habituados) el cual nos permitirá explotar todas las capacidades de la plataforma OSGI.
• Capacidad de desplegar múltiples versiones de un mismo módulo de manera concurrente.
• Instalación, actualización y eliminación dinámica en el entorno de ejecución.
• Búsqueda y utilización de servicios ofrecidos por otros módulos desplegados en el sistema
• . . . . . . (muchísimos más)

Como ya os supondreis, ésto no es ni una millonésima parte de las capacidades ofrecidas por estas tecnologías aunque creo que es una visión un poquito genérica que podría servir como punto intrductorio.
En la siguiente entrega construiremos un bundle que correrá bajo Equinox y ofrecerá un servicio. Asimismo construiremos otro bundle adicional, que correrá bajo el mismo entorno, y utilizará el servicio ofrecido por el primero de ellos.

En el futuro, espero que no demasiado lejano, intentaremos adentrarnos un poquito en el usode estas tecnologías para la construcción de clientes ricos distribuidos basados en Eclipse RCP.

Aspect Oriented Programming (I): Introducción

Me gustaría iniciar una serie de posts relacionados con la programación orientada a aspectos (AOP programming) y este es el primer paso (esperemos que no sea el último ;) ). Tal y como podría esperarse, los ejemplos que aquí veremos serán muy sencillos, pero nos darán una idea de las capacidades que AOP nos ofrece.

A lo largo de estas entradas (todavía no tengo claros cuántas van a ser) veremos algunas de las posibilidades que AOP nos ofrece, ejemplos sencillos de utilización, terminología, . . . Para el desarrollo de los ejemplos utilizaremos, principalmente Spring AOP, aunque puede que también en algún caso veamos algo de AspectJ.

Creo que un buen punto de partida podría ser la definición de los conceptos propios (y no demasiado comunes) de la programación orientada a aspectos (pongo el nombre del concepto en inglés para no meter la pata en la traducción ;) )

• Aspect: Representación de una funcionalidad transversal , es decir, un concepto que se utiliza en múltiples clases. Elementos como el log, la seguridad o el manejo de transacciones en aplicaciones empresariales son ejemplos de funcionalidades transversales.

• JoinPoint: lugar de ejecución de un programa tal y como puede ser la ejecución de un método o el procesamiento de una excepción.
  

• Advice: función realizada por un aspecto en un determinado joinpoint.
  

• PointCut: predicado a través del cual se asocia la ejecución de un aspecto en un determinado joinpoint.
  

• Introduction: declaración de nuevos métodos o atributos en un tipo determinado
  

• Target Object: también llamado "advised object", es el objeto al cual se le está aplicando el aspecto.
  

• AOP Proxy: objeto creado por el framework AOP tras aplicarle el advice al target object. El objetivo de este proxy es implementar los requerimientos del aspecto.

• Weaving: Proceso mediante el cual se aplica el aspecto a un target object con el fin de objetner un nuevo proxied object. El proceso de weaving puede llevarse a cabo en distintos puntos.
  
• Tiempo de compilación
• En el momento de la carga de las clases
• Tiempo de ejecución

Puede que la mayoría de los conceptos suenen extraños, y mucho más después de haberlos descrito yo :) . Las definiciones anteriores las he hecho en función de algunos de los libros que he leído (en realidad son mucho más extensas), intentando explicarme lo mejor que he podido.

De todos modos, esto únicamente pretendía ser una sencilla introducción a los conceptos generales y ,al menos eso espero, poco a poco iremos profundizando en el tema.

Hasta pronto.

PD: La programación orientada a aspectos no es exclusiva de Java, en C++ podríamos realizar una aproximación a la misma (un poco engorrosa, eso si) mediante plantillas y el concepto de plantillas de plantillas o mediante un lenguaje propio de aspectos como puede ser AspectC++.