finis coronat opus

Hace unos dias Merrick Schincariol publico un post para intentar aclarar lo que realmente se encuentra tras las siglas de AOP. Quizás no sea el articulo más completo sobre AOP pero si el más *claro* que he leido al respecto. Hace hincapie en algo que normalmente suele quedar enterrado bajo el mejunge de conceptos técnologicos existentes alrededor de AOP y con lo que estoy completamente de acuerdo:

"If you remember nothing else about AOP, remember that it is fundamentally about separation of concern. Filtering, interceptors and other implementation techniques that seem to dominate the AOP discussion are simply recipes for applying the AOP methodology. They are not AOP in and of themselves".

A pesar de ello hubo algo que no me acabo de convencer : la implementación del ejemplo en AspectJ. Sí , si ya se que solo es un ejemplo y que la implementación no es lo fundamental pero me gustaria ofrecer la contrapartida a ese ejemplo en otro de los frameworks existentes para AOP: Aspectwerkz. Dejo para otro post la explicación del porque de mi inclinación por AspectWerkz y no por AspectJ. Partimos de la misma clase desligada de todo aspecto no relacionado directamente con su finalidad ultima: imprimir.

public class PrintServer {
    // private variables
    // ...
    
    // constructor
    PrintServer() {
      // ...
    }
    
    public void printDocument(Document doc) {
        // ...
    }
    
    public PrinterInfo getPrinterInfo() {
        return retrievePrinterInfo();
    }
    
    // other printing methods 
    // ...
}

Y construimos el resto de requerimientos en base a aspectos de esa clase:

// Para sincronizar el acceso
import EDU.oswego.cs.dl.util.concurrent.Mutex;

import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class SynchronizationAdvice extends AroundAdvice {

    private Mutex m_mutex = new Mutex();

    public SynchronizationAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {
        System.out.println("Acquiring mutex\t" + Thread.currentThread());
        m_mutex.acquire();
        System.out.println("Has mutex\t\t" + Thread.currentThread());
        Object result = joinPoint.proceed();
        m_mutex.release();
        System.out.println("Releasing mutex\t" + Thread.currentThread());
        return result;
    }
}

// para tracear las entradas y salidas...
import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class LoggingAdvice extends AroundAdvice {

    public LoggingAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {
        MethodJoinPoint jp = (MethodJoinPoint)joinPoint;
        System.out.println(" entering " + jp.getTargetClass().getName() + 
                           "::" + jp.getMethodName());
        final Object result = joinPoint.proceed();
        System.out.println(" exiting " + jp.getTargetClass().getName() + 
                           "::" + jp.getMethodName());
        return result;
    }
}

// Y finalmente para cachear...
import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class CachingAdvice extends AroundAdvice {

    protected static Object cachedResult =null;

    public CachingAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {

        if (cachedResult != null) {
            return cachedResult;
        }
        final Object result = joinPoint.proceed();

        cachedResult = result;
        return result;
    }
}

Como se puede observar todas los aspectos se implementan como clases Java corrientes y molientes (gran, EMHO, diferencia con respecto a AspectJ) heredando de AroundAdvice, una clase proporcionada por AspectWerkz que permite controlar el antes y el despues de la ejecucion de ciertos metodos. ¿Qué metodos?. Uuups. Se me olvidaba. Para determinar la asociación de un aspecto a un determinado punto de nuestro codigo poseemos varios metodos: uno, el que detallo a continuación por simplicidad, que permite definir en un XML estas relaciones, y dos, la utlización de los llamados atributos en tiempo de ejecución que no son sino cabeceras estilo Javadoc delante de ciertos metodos que permiten determinar, por ejemplo, que aspectos estan relacionados con el metodo en curso (de una manera muy similar a como se especifica en XDoclet). ¿Diferencias?. El segundo de los metodos implica una precompilación del codigo para generar lo que se denomina "weave model", que recopila la información de estos atributos.

Utilizando el primero de los metodos, tendriamos un XML como el siguiente:

<?xml version="1.0"?>
<aspectwerkz>

    <advice name="logging"
            class="LoggingAdvice"
            deployment-model="perJVM"
            attribute="log"/>

    <advice name="caching"
        class="CachingAdvice"
        deployment-model="perInstance">
    </advice>

    <advice name="synchronization"
        class="SynchronizationAdvice"
        deployment-model="perJVM"/>


    <aspect class="PrintServer">
        <pointcut type="method" pattern="*getPrinterInfo()">
            <advices-ref name="caching"/>
        </pointcut>
    </aspect>

    <aspect class="PrintServer">
        <pointcut type="method" pattern="*  printDocument(..)">
            <advice-ref name="synchronization"/>
        </pointcut>
    </aspect>

        <aspect class="PrintServer">
            <pointcut type="method">
                <pattern>* p*(..)</pattern>
                <advice-ref name="logging"/>
            </pointcut>
        </aspect>

</aspectwerkz>


Por ultimo resaltar la posibilidad de la utilización de *expresiones regulares* para determinar los metodos (pattern) a los que queremos aplicar el aspecto.
En fin, sigamos la implementación que sigamos, a nadie se le escapa, que aunque incipiente, AOP abre interesantes caminos en el campo del desarrollo software. Por ahora no existe una base amplia de IDEs que faciliten el desarrollo, exceptuando el proporcionado por AspectJ (aunque la gente de Eclipse ya esta trabajando en un plug-in), pero bueno todo llegará... P.D.: No , martin no se me ha olvidado lo de la conversión de patrones ;-), estoy en ello.

De todos es sabido lo ocurrido en los dos ultimos dias en el centro de JBoss Group LLC. Y creo que a nadie se le escapa que no es un evento mas dentro del mundo OpenSource. En pocas palabras: Los desarrolladores favoritos de Rickard (que merece toda mi credibilidad ;-) se han *cansado* del modo de trabajo del grupo comandado por el subcomandante Marc Fleury, y han dicho "hasta aqui hemos llegado". En algunos foros se ha hablado sobre la continuidad de estos desarrolladores en el proyecto de JBoss, algo que *EMHO* me parece fuera de toda duda, ¿podria ser de otra manera?, ¿puede Marc impedirlo moralmente?, ¿puede impedirlo *legalmente*?: sinceramente NO.
Lo que se le presenta ahora a Marc no es un problema técnico, ni de desarrollo, lo que se le presenta es un problema *COMERCIAL*. Me equivoco o ¿no es la primera vez que dos compañias se presenta como competencia directa por un proyecto opensource?. No, lo de las distribuciones linux no es lo mismo; los productos que cada compañia (SuSe, RedHat,etc...) vendia/distribuía eran claramente diferentes y poseían enfoques y configuraciones que las revelaban como productos *bastante* distintos.
Pero ahora tenemos a dos compañias ofreciendo consultoria (un nicho de negocio que se rige casi unica y exclusivamente por el prestigio de las compañias que lo intentan cubrir) sobre el servidor de aplicaciones *OPENSOURCE* mas importante del mundo. Y todos sabemos de la calidad y el prestigio de los que se han ido del JBoss Group. Y es más: Marc tambien lo sabe. Y tiene miedo. Al menos yo lo tendría. Ese aire entrañable de familiaridad, de confraternización, de buen rollo, de hermandad *casi* masónica, de al fin al cabo *grupo*, al que tanto tiempo se ha agarrado para tirar del carro del proyecto JBoss, se ha desecho, perdón, lo han desecho en 48 horas. El OpenSource madura, aunque sea por las malas relaciones Marc-Resto del Mundo.
En mi opinión Marc tiene varias alternativas abiertas a partir de hoy:
1.- Aprovecharse de la ruptura. Reconocer que efectivamente había diferencias dentro del JBoss Group sobre como orientarse en su mercado (y tambien sobre como orientarse en la vida opensource, pero bueno mejor eso que se lo calle), y sobre que modelo de negocio trabajar, y que como en todas las empresas llegado este punto, un grupo se ha decido escindir. Marc tiene una oportunidad perfecta para dar más bombo y platillo que nunca a JBoss. Es un servidor maduro que ahora no solo tiene un equipo de desarrollo brillante sino algo igual de importante : dos compañias de software que se *PEGAN* por ofrecer mejores servicios sobre él, que son al fin y al cabo, COMPETENCIA.
2.- Hacerse el loco. Seguir adelante con la idea feliz de que las nubes son de algodón y las pone Dios, y de que en JBoss Group todos viven en un estado de permanente alegría y camaradería. De igual manera estos chicos del CDN no pretenden sino pasar un ratito divertido probando lo que se siente montando una PYME.
3.- Iniciar una caza de brujas. A estos chicos prácticamente les he echado yo. Por rojos, comunistas y masonazos. Pretendían destruir la integridad de España, esto perdon, de JBoss Group. Y de eso nada, aquí estoy yo fiel baluarte de Occidente para defenderla. Así que ya sabeís: el que no piense como yo, puerta.
4.- Reconocer su fracaso en JBoss y abandonar el puesto que ocupa. Sin comentarios.
Así que no me gustaría estar en el pellejo de Marc porque sinceramente lo que haga a partir de ahora va a marcar la evolución de JBoss Group (no de JBoss) de hoy en adelante. ¿Qué vas a hacer Marc?.

¿Roja o Azul?

P.S.: Por cierto el logo de CDN es mucho mejor que el de JBoss Group ;-).

Aunque no lo he contado nunca por estos lares una de mis pasiones ocultas es la escalada. Así que entre el numero de Mayo de National Geographic, el libro de Hire Himalaya de los de Aretxabaleta, y los documentales que dan estos dias de EiTBarretxe no he podido por menos que dedicar un pequeño y humilde post al 50 aniversario de la ¿primera? ascension al Everest.

Desde aqui mis más sinceras felicitaciones y envidias a todas las expediciones vascas que han estado/estan/estarán subiendo por nieve virgen, andando en la cresta con la cima a tiro de piedra. o pegandose con un desplomado imposible durante horas.

Saludos a los que pasan 4 meses en un campo base para subir sin oxigeno a un 8 mil y demostrar que a la cima se puede llegar de muchas maneras incluso con estilo.

Mi admiración a por lo que se rinden a 8 pasos de la cima porque viven como el espiritu de la montaña, sin que nadie los pise (gracias Felix por estas bellas palabras).

Mi apoyo incondicional para aquellos a los que la montaña les convierte en personas mas humanas, y no en malas bestias que solo ansían la cima y a la que dan más valor que a la vida de una cordada en apuros que se encuentra a 15 metros.

Y mi mas profundo respeto para aquellos que siendo así logran poner un pie donde no lo ha puesto nadie, o donde solo hombres y mujeres como ellos lo han conseguido, sabiendose valedores de la confianza y la generosidad que un 8 mil les ha dado ese dia.

Felix gogoan zaitugu.

Estos dias me gustaria poder pasarme por Santiago de Compostela. ¿Por qué?. Principalmente por dos razones:
1.- Para poder cenar por la noche en la Rua Nova (preferiblemente si acaba de llover) una de pulpo con pan gallego y una de pimientos de Padrón.
2.- Para poder asistir a e-gallaecia, una conferencia tecnologica promovida por las universidades de Santiago y de Vigo, y que congrega a personajes como Kevin Mitnick, Jose Manuel Estrada o Hugo Pinto.
En ella se va a hablar de nuevas tecnologías, de Open Source y de Java. Segun los post de Martin estan siendo bastantes interesantes y realmente lamento no tener un par de dias para pasarme por alli. Asi que ya sabeis si teneis tiempo quizas todavia llegueis para ver algo.
P.S: si no siempre podeis lee las cronicas de nuestro enviado especial ;-).

Llevaba varios dias (en concreto 8) sin publicar. La razón: me traslado.
He estado primero actualizando las plantillas para que se pueda empezar a dejar comentarios y segundo portando esa plantilla al nuevo hosting de mi weblog (a parte de algunos pequeños cambios que seguro pasaran desapercibidos :). Despues de 6 meses de posts en Freeroller me mudo a los Weblogs de javahispano. Aun cuando el hosting de freeroller ahora funciona perfectamente (de lo cual estoy muy agradecido al equipo de JavaLobby y Anthony) creo que tiene más sentido que el weblog este hospedado donde le corresponde: en la ¿mayor? comunidad java de habla hispana. Aqui tienen los links pertinentes para que puedan actualizar sus bookmarks:

Weblog: http://weblogs.javahispano.org/page/aitor

RSS: http://weblogs.javahispano.org/rss/aitor

A partir de ahora mis posts iran en la nueva dirección. Nos vemos !

P.S.: Thanks Anthony !

Ala, pues ya he empezado….