6.5.1 Local
Para el tejido dinámico local, el hilo demonio (daemon) previamente inyectado por el JPI es el encargado de detectar la necesidad de tejer dinámi- camente los componentes y aspectos. El demonio detecta las variaciones de los ficheros XML con las especificaciones de puntos de corte y advices. Si un nuevo fichero aparece, se inyectan estos nuevos aspectos a la aplicación; si un fichero se elimina, se destejen los aspectos referenciados por ese fichero de la aplicación.
Siguiendo con el ejemplo del pago de una tarjeta de crédito, así es có- mo la aplicación, el aspecto de profiling con tejido dinámico local y el hilo demonio trabajan juntos para adaptar en tiempo de ejecución el sistema de pago con tarjeta de crédito (ilustrado en Figura 16):
1. La aplicación, una vez procesada por el JPI, es ejecutada. En el arranque el hilo demonio, añadido durante la fase de instrumenta- ción, se activa. Este hilo demonio comprobará periódicamente los cambios en los ficheros XML de especificaciones de puntos de cor- te.
2. Cuando el desarrollador quiere realizar profiling de la aplicación en ejecución (por ejemplo, porque detecta bajo rendimiento en tiempo de ejecución) preparará un fichero XML especificando los puntos de corte y la localización del advice. También implementará el aspecto de profiling. Este fichero XML se copia al directorio don- de el hilo demonio está comprobando los cambios en los ficheros de puntos de corte (por defecto es el directorio donde se inició la aplicación).
DSAW | Diseño del Sistema
Universidad de Oviedo 55
3. El demonio detecta el nuevo fichero XML y lee la especificación de los puntos de corte, cuyo formato es similar al mostrado en la Fi- gura 14. Utilizando CodeDOM [Microsoft13], genera en tiempo de ejecución un stub encargado de hacer las llamadas a las funciones del aspecto (advices). También almacena la correlación entre el nombre del advice y su llamada a través del stub.
4. El demonio procesa el documento XML buscando los puntos de corte pasados. Los puntos de enlace descritos por estos puntos de corte son activados en la aplicación por medio del MOP inyectado por el JPI (IJoinPoint). En esos puntos de enlace se almacenan las llamadas a los advices oportunos a través del stub generado. Es- ta activación implicará la futura invocación de los aspectos tejidos dinámicamente. Ésta es la instrucción weave i, ϕ, t formalizada en Sección 4.3, donde i y t son, respectivamente, el punto de enlace y el tipo de advice descritos en el fichero XML; y ϕ es el código del aspecto.
5. Cuando la ejecución de la aplicación de la tarjeta de crédito alcanza un punto de enlace tejido (por ejemplo, la llamada al método pay- ment), llama al aspecto de profiling invocando al método Execute
del interface ICaller.IExecute. Entonces, la aplicación pasa el control al aspecto enviando información relativa al punto de enlace (en nuestro ejemplo se pasa información StaticPart, siendo posible pasar otra tal y como se describió en § 6.4). El aspecto de profiling en ese momento recibirá el flujo de la ejecución para almacenar la hora y medir el rendimiento dinámico.
6. Aunque en este ejemplo no se utiliza, el aspecto puede usar la refe- rencia a la aplicación para acceder a ella por medio de reflexión. El JPI añade el interface IReflection para este propósito. De esta forma, el aspecto puede inspeccionar o modificar los valores de cualquier campo o propiedad de la aplicación, así como invocar a cualquiera de sus métodos (no sólo el método interceptado).
7. Cuando ya no sea necesario que el aspecto se ejecute, el desarro- llador puede eliminar el fichero XML que originó el tejido. Para ello, debe suprimirlo del directorio donde el demonio está contro- lando los cambios en los ficheros de corte XML. Esta eliminación implicará el destejido del aspecto.
DSAW | Diseño del Sistema
56 Universidad de Oviedo
8. El hilo demonio, al detectar una variación en los ficheros de especi- ficaciones de puntos de corte, desactiva en la aplicación los puntos de enlace previamente activados con el aspecto. Esos puntos de en- lace podrían todavía seguir activados por otros aspectos diferentes que los hayan activado. Esta operación es la formalizada con la se- mántica de la instrucción unweave i, ϕ, t en la Sección 4.3.
Figura 16: Adaptación dinámica local de una aplicación en tiempo de ejecución.
También podría darse la necesidad de modificar los puntos de corte usados por un aspecto en tiempo de ejecución. Esta operación también es ofrecida por DSAW, tanto para el caso local como para el remoto. En este ca- so, el desarrollador debería preparar un nuevo fichero XML especificando los nuevos puntos de corte. El hilo demonio detectará el nuevo fichero y lo anali- zará, activando los nuevos puntos de enlace y desactivando los existentes en tiempo de ejecución.
El hilo demonio en el caso local (y el AS en el caso remoto) actúa como un mediador entre los aspectos y las aplicaciones [Gamma94]. Esta mediación es sólo realizada cuando los puntos de enlace son tejidos o destejidos. Una vez estas operaciones han sido realizadas, la aplicación y el aspecto interac- cionan directamente a través del stub generado. La aplicación llama al aspec- to invocando al método Execute del interface IExecute utilizando el stub cuando un punto de enlace activado es alcanzado. Entonces el aspecto puede inspeccionar la aplicación mediante la información recibida, o utilizando
IReflection si necesita una funcionalidad más versátil. Aplicación Tarjeta de Crédito Demonio Aspecto Profiling Nuevo Fichero XML 1) El demonio se ejecuta
2) El desarrollador prepara fichero de puntos de corte y aspecto 7) El desarrollador elimina fichero de puntos de corte
Stub
3) Genera Stub IJoinPoint
IExecute
Advice1 Advice2 Advice3 5) La ejecución alcanza
un punto de enlace activado
IReflection 6) El aspecto puede accedera la aplicación para adaptarla
4) Se activan los puntos de enlace
8) Se desactivan los puntos de enlace
DSAW | Diseño del Sistema
Universidad de Oviedo 57
Con este diseño, las aplicaciones no necesitan conocer los aspectos que van a ser tejidos en tiempo de ejecución. Al mismo tiempo, los aspectos pueden ser aplicados a cualquier aplicación, o incluso cualquier aspecto, sin ninguna dependencia estática. Este comportamiento reduce el acoplamiento y promueve la reutilización tanto de componentes como de aspectos.
6.5.2 Remoto
DSAW también permite el tejido y destejido de aspectos de forma dis- tribuida mediante el tejido remoto. En ese caso, la ejecución del sistema es controlada por el Servidor de Aplicaciones (Application Server, AS). El AS coordina componentes y aspectos, proporcionando la adaptación dinámica de los programas en tiempo de ejecución. El AS actúa como un sistema de registro de las aplicaciones que se encuentran en ejecución, ofreciendo a los aspectos la lista de las aplicaciones activas para facilitar su adaptación diná- mica.
Siguiendo con el ejemplo del pago de una tarjeta de crédito, la siguien- te secuencia describe los pasos de cómo la aplicación, el aspecto de profiling y el AS trabajan juntos en tiempo de ejecución para llevar a cabo un tejido y destejido dinámico y remoto (ilustrado en Figura 17):
1. La aplicación es ejecutada tras ser procesada por el JPI. En el arranque ésta se registra en el AS con un identificador único global (GUID), siguiendo la especificación OSF/DCE [Miller92]. Tanto el GUID como el código de registro fue previamente añadido a la apli- cación por el JPI. Este GUID es utilizado a lo largo de la ejecución de la aplicación para que los aspectos puedan identificarla en el sis- tema.
2. Cuando se desee adaptar la aplicación, una aplicación lanzadora (launcher), que puede ser el propio aspecto, es ejecutada. El objeti- vo del launcher es adaptar dinámicamente la aplicación (es una adaptación programática realizada por un programa, en lugar de por un humano).
3. DSAW, a petición del launcher, lee el fichero XML con la especifica- ción de los puntos de corte (Figura 14). Utilizando CodeDOM [Mi- crosoft13] se genera en tiempo de ejecución un programa stub que hace llamadas a las funciones del aspecto (advices), y almacena la relación entre el nombre del advice y su llamada a través del stub.
DSAW | Diseño del Sistema
58 Universidad de Oviedo
4. DSAW llama al AS (mediante IServer) pasándole el fichero XML, la estructura de datos generada en el punto 3, y el GUID de la apli- cación.
5. El AS procesa el documento XML buscando los puntos de corte pa- sados recibidos. Los puntos de enlace descritos por estos puntos de corte son activados en la aplicación por medio del MOP inyecta- do por el JPI (IJoinPoint). En el punto de enlace se almacenan las llamadas a los advices a través del stub generado. Esta activación implicará la eventual invocación del aspecto en tiempo de ejecu- ción. Esta acción es la operación weave i, ϕ, t formalizada en la Sec- ción 4.3.
6. Cuando la ejecución de la aplicación alcanza un punto de enlace te- jido (por ejemplo, la llamada al método payment), se invocará al aspecto de profiling a través de la llamada al método Execute del interface ICaller. Entonces, la aplicación pasa el control al aspec- to enviando información del punto de enlace (StaticPart en nuestro ejemplo).
7. Cuando ya no es necesario que el aspecto se ejecute, el launcher envía al AS una orden solicitando la desactivación de los puntos de enlace de la aplicación interceptados por el aspecto.
8. El AS desactiva los puntos de enlace de la aplicación utilizando
IJoinPoint (instrucción unweave i, ϕ, t de la Sección 4.3).
9. Finalmente, cuando la aplicación finaliza su ejecución, el código añadido por el JPI notificará al AS que la aplicación ha terminado y debe ser desregistrada.
DSAW | Diseño del Sistema
Universidad de Oviedo 59
Figura 17: Adaptación dinámica remota de una aplicación en tiempo de ejecución.
Para intercomunicar el AS, las aplicaciones y los aspectos hemos usa- do .Net Remoting [Microsoft13d] (ahora parte del framework Windows Com- munication Foundation). .Net Remoting es un servicio estándar sobre la plata- forma .NET proporcionando canales (protocolos) independientes del lenguaje
y plataforma, permitiendo la adaptación de aplicaciones sobre entornos dis- tribuidos. Puesto que toda la información es pasada por valor, su rendimiento es significativamente menor que la opción de tejido dinámico local.