Logger les performances avec l'AOP dans une application n-tiers (Java)

La perf, un sujet incontournable, il sera mis tôt ou tard sur la table. Il faudra comprendre, améliorer, supprimer les points de contentions. Pour cela il est indispensable de réaliser des mesures. Un panel de solutions permettent de réaliser des mesures avec plus ou moins de finesse, dans diverses conditions.

Du temps d'exécution d'un test unitaire à un test de charge avec SoapUi ou JMeter, à une analyse de la jvm avec VisualVM ou Java Mission Control . Enfin en combinant tout ça on est certain d'arriver à une mesure fine et à identifier les axes d'optimisation. Mais à quel prix, ces outils on un coup non négligeable de mise en œuvre, et la traque prend du temps.

Une solution simple permettant de réaliser des rapports est la mise en place d'un logger par AOP s'appuyant sur l'architecture en couche (oui votre application est architecturée en couche). L'architecture en couche permettra l'utilisation de l'AOP de façon assez simple en interceptant les interfaces de chaque couche, et cela permettra de structurer le rapport. Cette approche est assez rapide et simple à mettre en oeuvre.

Pour cela j'ai développé un mini projet Log4Tiers (https://github.com/niclange/Log4Tiers) pour réaliser ces logs de performance, oui il est très simple et probablement beaucoup l'ont déjà implémenté. Il s'appuie sur Spring pour la mise en œuvre de l'AOP. On se place dans un contexte web, on va donc réaliser un log en tentant de suivre chaque appel au travers d'un identifiant (en rapport avec le thread), puis on identifiera chaque couche appelée et chaque méthode et les temps consommées.

Le plus complexe pour la mise en oeuvre est la configuration Spring de l'AOP.

Attention le fait de logger à un coût, et aura une impacte non négligeable, surtout si on log les éléments ayant une fine granularité, il faut donc en tenir compte, configurer la configuration AOP Spring en conséquence.

Vous trouverez un exemple complet dans la partie test unitaire du projet.

Je vais finir en ajoutant comment traiter le résultat du logger avec Excel.

On ouvre le fichier csv avec excel et on ajoute les entêtes des colonnes

En suite on peut réaliser un tableau croisé dynamique pour faire ressortir par exemple chaque appel :

Ou les couches de l'application :

A partir de là on peut réaliser toutes sortes de graphiques.

Sinon j'ai mis à jour le projet pour activer/désactiver les loggers par JMX.

Application N-Tiers et Frameworks

Voyons un peu ce que certains framworks, que l'on peut qualifier de standard apportent à l'architecture N-Tiers.

     IOC : Springframwork, Guice

THE framework, limite on ne peut plus s'en passer, il permet beaucoup de choses et surtout d'intégrer et configurer d'autres frameworks... bref c'est souvent la pierre angulaire du projet. Mais c'est tout simplement un framework IoC ou d'injection de dépendances. Il permet de mieux découpler les couches.  Ainsi on code avec les interfaces et c'est Spring qui se chargera (par la configuration ou les annotations) d'injecter l'implémentation. Point de factory, de singleton à implémenter soi-même.

Il n'a pas d'impact sur le nombre de couches mais il apporte une méthode élégante pour réaliser le couplage faible (par interface) entre les couches.

JEE permet aussi de réaliser l'injection avec une facilité équivalente (annotations)

Coté .NET on trouve des frameworks équivalents mais peut-être pas aussi bien aboutis avec le ServiceLocator et/ou les frameworks Unity, SimpleIOC et Castle. Encore que springframework.net semble palier à cela (promis prochain projet .net je le tente).

     ORM : JPA, Hibernate, Entity Framework 

Aujourd'hui les ORMs sont matures et permettent de masquer l'accès aux bases de données. Là on voit deux méthodes : ceux qui tiennent à la couche de DAO traditionnelle, cette dernière est alors triviale pour tout ce qui est CRUD, mais elle permettra d'isoler le code spécifique pour réaliser des fonctionnalités non prises en charge par l'ORM (rares).

Une approche plus moderne est de faire disparaître cette couche, de s'appuyer directement sur l'ORM depuis la couche métier, et de faire porter le CRUD et les requêtes complexes par le modèle (les classes d'entités de persistance) lui même.

Ainsi si on a une utilisation standard de la persistance dans une base de données relationnelle ou non (certaines base NoSql supportent les standard JPA ou JDO), l'ORM permet de remplacer la couche de DAO et simplifie grandement la structure du projet. C'est ce que l'on voit mis en oeuvre avec les approche de type Rails de Grails par exemple.

    Web Service : CXF (java), WCF (.net)

Les web service sont générés par des framework tiers. De même que les ORM, on peut piloter la mise en forme du message du service par des annotations sur le modèle d'échange (qui peut être ou non celui de persistance). Ce qui réduit l'implémentation d'un service à son strict minimum, seule l'interface est rédigée, l'implémentation est un passe plat qui appelle la couche métier.

     AOP : Spring AOP

L'Aspect Oriented Programing est un paradigme de programmation qui se place au dessus de la programmation orientée objet.

La mise en oeuvre de l'AOP dans une architecture en couche permet d'implémenter des responsabilités transverses aux couches d'architecture ou spécifique à une couche, une classe, une méthode. Bref cette technique est très flexible et elle permet élégamment de mettre en place une fonctionnalité transverse de type :

• réalisation des logs
• sécurité
• gestion de caches

Cela permet de mettre un peu d'huile entre les différentes couche de l'application. En respectant un couplage faible par l'utilisation d'interface, grâce à ces dernières,  l'AOP se met en place avec un moindre coût.

     MVC : Struts, Spring MVC...

Les frameworks MVC our MVVM et autre permettent de réaliser la couche de présentation, mais même si eux même ont un découpage Modèle Vue Contrôleur, ou Modèle Vue VueModel, bref un découpage en 3 catégories il ne faut pas prendre ces dernières comme des couches d'architecture applicative. Peut-être qu'avec un peu de chance le Modèle du MVC correspondra au domaine de l'application. C'est typiquement ce qui arrive dans les architecture Rails ou par convention le domaine est afficher directement, le contrôleur semble être la couche métier et la vue la présentation... mais c'est du Rails. Dans les applications qui ont un peu d'historique et de complexité ce n'est pas le cas, le modèle du MVC est différent du modèle métier de l'application et appartient intégralement à la couche de présentation.

     DOZER :

Cet outil permet de recopier récursivement une grappe d'objet dans une autre grappe par réflexion et en utilisant un fichier de mapping, c'est un outil TRÈS PUISSANT... trop ? J'en parle car je l'ai vu mis en dans le but de découpler les couches logiques d'une application. OK ils disent que c'est un usage possible. Cela ne me semble pas une bonne pratique :

• surcoût en terme de mémoire et CPU
• maintenance complexe du code : une propriété doit être ajoutée à plusieurs classes et si son nom change un mapping spécifique dozer doit-être mis en place et testé.

Bref il ne faut mettre un tel outil que s'il apporte une valeur ajoutée importante sur un projet et dans le cadre d'une architecture en couche logique, je ne vois pas sa valeur ajoutée. Sauf dans des cas particuliers, avec un historique lourd... et alors c'est le dernier espoir...  

Quelles sont les pièges de l'architecture en couches logiques ?

1) le nombre

Comme je le disais c'est d'en faire trop, il en faut juste ce qu'il faut et c'est toujours un peu délicat la tentation est grande d'en ajouter. Mais il faut garder en mémoire que c'est un découpage technique et non fonctionnel du projet.

2 ) les fausses couches

Le MVC (modèle vue contrôleur), le MVVM (modèle vue vue-modèle, un truc Mircosoft) et autre font partie d'une seule couche logique, celle de présentation. 

3 ) Le découplage

Les couches doivent être découplées qu'il disait... et comment ça cause ? A grand coups de Reflexion et de Dozer (bon framework souvent mal utilisé), ça va piquer !

Non sérieux, il y  a un couplage, mais un couplage faible, réalisé par interfaces et uniquement descendant (oui il faut éviter un cycle, ça compile pas les dépendances cycliques). 

Le couplage par interface permet, de ne pas être tributaire d'une implémentation unique, on pourra réaliser une nouvelle implémentation d'une couche sans modification des autres à condition de respecter les interfaces. 

4) Le modèle

L'interface c'est bien pour le "verbe" : les méthodes exposées. Mais il faut aussi un modèle, un modèle métier, souvent le reflet de ce qui est persisté. Il véhicule l'information entre les couches, on le retrouve dans les signatures des méthodes des interface. 

Il peut provenir de l'extérieur : XSD, Modèle de données existant... il faut le partager à toutes les couches au travers de son implémentation (plus simple) ou d'interfaces (plus complexe : mise en place de factory et autre... ), si chaque couche implémente son propre modèle la communication va être complexe et couteuse, bref vous aller lorgner rapidement vers Dozer, ça fera moins de code... ça risque d'être  compliqué de conservé un couplage faible (par interface).

On peut considérer le modèle comme un couche accessible par toute les autres (la couche de plus base niveau).

5 ) le passage d'un couche à l'autre 

On a traité une partie dans le point précédent mais encore un piège ce cache, ne pas respecter les couches. Impossible vous me direz, c'est découplé, enfin disons pas trop couplé. Oui mais on peut toujours faire une méthode qui prend une requête SQL en paramètre depuis la couche présentation passée dans une chaine de caractères. Bref ce sont des couche logique, y a toujours moyen de passer à travers et une simple chaine le permet. Sans parler du problème de sécurité que ce genre de pratique que certain de mes proche, certain de mes amis...

6) Les frameworks

Les frameworks apportent beaucoup au développeur, mais il est nécessaire de bien les maitriser pour ne pas se faire envahir par un framework qui alors prendrait la main sur la conception.

Mais il faut aussi voir que bien utilisé ces derniers permette de simplifier la conception et souvent de supprimer une couche !

Voila on a fait le tour... plus on fait simple plus il y a  de chance que cela fonctionne bien.

Et avec des framework ressents ça donne quoi tout ça ? ORM, Spring, JPA, Linq...