lundi 24 juin 2013

Mod_JK : mélange de session utilisateur


J'ai travaillé il y a quelques semaines sur un bug particulièrement vicieux.

Certains utilisateurs de nos applications webs JEE expérimentaient un changement d'identité alors qu'ils étaient en train de travailler tranquillement.

Mieux ils se retrouvaient dans la session d'un autre utilisateur, positionné dans un contexte qui n'étaient pas le leur.

Notre architecture est basée sur Apache, Mod_JK et Glassfish.

Une piste


Après avoir googlé quelques minutes je suis tombé sur une piste sérieuse : un bug critique sur Mod_JK  toujours ouvert, intitulé Reponse mixed between users.

Le bug est ouvert en 1.2.28 alors que nous sommes en 1.2.19 mais il ne faut jamais oublier que la découverte d'un bug dans une version ne signifie pas que le bug n'existait pas avant.

Même si la fiche du bug ne mentionne pas Glassfish, je table sur le fait qu'il s'agit d'un bug Mod_JK.

Alors je décide de monter un environnement de test pour tenter de reproduire à volonté le bug.

Pour cela, quelques commandes systèmes et quelques coups de vi plus tard, je me retrouve avec un environnement prêt à l'emploi.


Echange de session: comment est-ce possible ?


Comment vérifier que des échanges de session se produisent ?

Si le bug est rare ce que laisse à penser les remontées des utilisateurs alors il y a peu de chance que des tests manuels permettent de reproduire le problème.

Il faut d'abord comprendre comment un échange de session se fait.

Pour cela il suffit qu'un utilisateur reçoive la réponse à une requête qui ne lui était pas destinée.

En effet, l'entête de réponse Set-Cookie est renvoyé pour chaque réponse émise par le serveur Glassfish. Il faut remarquer que Tomcat ne fonctionne pas de la même manière en émettant l'entête de réponse Set-Cookie que lors de la première réponse qui suit la création de la session.

Ainsi Glassfish est plus vulnérable à ce bug Mod_JK car toutes les réponses provenant de ce serveur contiennent cet entête quand le domaine est configuré avec une route JVM.

Si Mod_JK mélange les réponses alors les utilisateurs vont recevoir un cookie de session qui ne leur est pas destiné.

Comment vérifier cela ?

A la lecture des commentaires sur le bug, je me suis rendu compte que ce bug était du genre furtif voire très furtif.

La probabilité de reproduire à la main ce bug en jouant avec plusieurs navigateurs est quasiment nulle.

JMeter à la rescousse


JMeter est à mon sens un outil de premier ordre, à la fois simple et puissant pour celui qui sait l'exploiter.

Il va me permettre de générer un nombre conséquent de session utilisateur sur une application web JEE simple et de vérifier pour chaque requête si la réponse associée contient bien le même cookie de session.

Ensuite, il suffit d'un script BeanShell dans une assertion JMeter (testé avec la 2.9) pour vérifier le point crucial : y a t-il échange de session ?

Voici le script :


Loading ....

Ce script doit être utilisé pour chaque requête dans une assertion BeanShell.

Vous pouvez soit référencer un fichier qui contient ce code, soit coller le code dans la zone prévue dans l'assertion.

Grâce à ce script j'ai pu reproduire le problème. La fréquence s'établit à 0.8 échange de session pour 1000 requêtes.

Ceci est faible mais pour une application web qui connait un traffic soutenu sur une journée de travail, c'est suffisant pour constituer un risque majeur de sécurité.

Est-ce vraiment un bug Mod_JK ?


L'utilisation de mod_proxy a supprimé ce bug.

Cela ne venait donc pas de l'application. Cette observation est conforme à certains témoignages associés au bug.

Les enseignements

Cet expertise a été pour moi une confirmation d'un ressenti quant à l'évolution de nos architectures.

Plusieurs personnes avaient été mobilisées pendant un mois pour tenter d'isoler et reproduire le problème, sans succés.

Les architectures sont de plus en plus complexes :  il est devient quasi impossible de résoudre certains incidents sans méthode et sans une rigueur extrême.

Or certains professionnels continuent d'appréhender les problèmes techniques comme "avant" : pas de méthodologie bien établie, pas de gestion de configuration fiable sur les composants de l'architecture, pas de traçabilité lors des tentatives de reproduction, modification de plusieurs paramètres de l'architecture sans bien maîtriser la portée de ces changements, ...

Il y a quelques jours Michael Shallop a publié un article sur les 5 meilleures règles de débogage et de diagnostic à connaître.

Je vous conseille la lecture de cet article.





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

mercredi 19 juin 2013

JSF and AJAX : un mariage heureux si vous comprenez la gestion des IDs



JSF 2 apporte un support  de haut niveau pour vos cas d'usages AJAX : il faut cependant comprendre la gestion des IDs pour bien en profiter.

Les IDs


IDs, comme leur nom le laisse supposer, permettent d'identifier les composants dans la vue.

Chaque composant est à une place précise dans la vue, l'ensemble forme un arbre de composants.

Chaque ID doit être unique.

Lorsque vous utilisez la balise ajax de JSF vous utilisez des IDs pour l'attribut execute et l'attribut render.

Cas d'utilisation


Voici un exemple simple :

Loading ....



Je veux rafraîchir  3 zones lorsque ma requête AJAX est terminée :

- output à l'intérieur du formulaire principal
- output2
- output3 à l'intérieur du second formulaire


Comme un système de fichier UNIX



Tout est dans l'utilisation du caractère ":".

Qu'est ce que veut dire ":" ?

Il faut considérer ce caractère comme  le slash d'UNIX.

Les composants sont comme des fichiers, certains sont des répertoires : ils contiennent d'autres composants.

Certains répertoires sont spéciaux, ils ont une influence sur la manière dont les IDs client sont calculés.

Ces composants spéciaux sont des  naming container, ils donnent leurs IDs à leurs enfants comme un préfixe.

Si vous étudiez le XHTML vous verrez que  mainform or secondform sont des préfixes de certains IDs de composants fils.

Quand une requête AJAX est en cours alors le contexte courant pour le calcul des ID est le  naming container le plus proche dans la hiérarchie.

Tous les IDs utilisés dans la balise ajax sans ":" sont évalués depuis ce point de départ.
C'est en quelque sorte le dossier courant.

La solution


Dans l'exemple ci-dessous, ma balise AJAX doit utiliser les IDs suivants :


Loading ....

Pourquoi ?


1) Quel est le naming container le plus proche ?

C'est mainform.

2) Quelle est la relation entre output et mainform ?

output est un fils, je peux le cibler directement car je suis dans le répertoire mainform:

./output -> output

3) Quelle est la relation entre output2 et mainform ?

Il n'est pas dans mainform, je dois passer par la racine de l'arbre, comme je le ferais avec un système de fichier :

/output2 -> :output2

4) Quelle est la relation entre output3 et mainform ?

Il n'est pas dans mainform, je dois passer par la racine de l'arbre mais il est dans le "dossier" secondform :

 /secondform/output3 -> :secondform:output3

Quelques balises sont des  naming container :
- data
- form

Attention,  tous les composites sont des naming containers !

Ils ont un impact sérieux sur la manière dont vous devrez spécifier les IDs dans les balises AJAX.
Dans le doute, n'hésitez pas à inspecter le XHTML pour vérifier les clients IDs.

A vous de jouer !





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

mardi 18 juin 2013

TOGAF : une philosophie pour l'architecte



Une méthode de plus ?
Une usine à gaz pour fabriquer des tours d'ivoire pour les architectes ?

Après une semaine de formation à TOGAF 9 et une certification niveau 2 réussie, je dois dire que cela reste une des expériences les plus importantes de ma carrière.

Je vais tenter d'expliquer pourquoi.

TOGAF kesako ?


TOGAF a été créé dans les années 90 par des professionnels de terrain, de vrais gens qui travaillent dans les départements informatiques de grosses entreprises ou qui conseillent ces dernières.

Ces gens se sont mis à échanger sur leurs pratiques de l'architecture d'entreprise et ont tenté d'élaborer un socle commun de pratique pour produire de l'architecture.

Ces échanges se sont faits sur les forums de l'OpenGroup et ont abouti à la naissance de TOGAF, qui veut dire : The Open Group Architecture Framework.  

TOGAF est donc un cadre d'architecture pour la transformation des systèmes d'information : l'idée est donc d'installer une nouvelle gouvernance par l'architecture.

Le premier point important est de comprendre que TOGAF est fait par des gens de terrain et non par des gens "hors sols" qui n'ont jamais travaillé dans ou pour une entreprise. 

TOGAF est tout sauf un modèle théorique, il est construit sur la base de pratiques qui lui pré-existent et qui fonctionnent sur le terrain, raison pour laquelle elles se trouvent dans le cadre.

Nous allons voir quelques concepts TOGAF de base pour vous donner envie d'aborder cette méthode.


Architecture, de quoi parle-t-on ?


TOGAF définit l'architecture comme une activité de management qui vise à transformer l'entreprise de manière rationnelle. Pour cela il faut faire des plans du présent et du futur. 

L'analyse de l'écart permet de connaître et donc maîtriser les travaux futurs.

Comme dans le bâtiment, de nombreux corps de métier sont impliqués pour représenter tous les aspects  de la transformation.

Une fois que les plans sont faits et validés par les donneurs d'ordre alors les travaux réels commencent.


TOGAF une méthode de plus ?


TOGAF contrairement à d'autres méthodes est pragmatique. 

A ce titre, ce cadre implique que les praticiens soient suffisamment matures pour l'adapter à leur entreprise.

Parmi les premières étapes de la mise en oeuvre d'une démarche TOGAF, il existe une étape particulièrement importante : la mise en place du cadre de capacité d'architecture d'entreprise.

Cette étape m'a ouvert les yeux sur un certain nombre de points cruciaux pour notre métier d'architecte.

D'abord, la construction de cette capacité permet d'interroger profondément sa pratique de l'architecture.

En effet, le cadre de capacité d'architecture vise à définir les moyens et les buts de l'architecture pour chaque entreprise en fonction de ses moyens.

Premier élément, chaque entreprise est différente de par sa culture, ses moyens et ses transformations. Il y a donc autant de pratique d'architecture valable que d'entreprise.

Selon TOGAF,  il faut créer son TOGAF, donc sa propre méthode.

Nous architecte, avons trop tendance à demander ou à présenter des travaux d'architecture selon notre goût , la mode du moment ou les canons esthétiques posés par une référence culturelle reconnue (tel gourou mondial) ou moins reconnue (j'ai toujours fait comme ça, dans la boîte de service on nous dit de faire comme ça, ...).

Oui très bien, mais quel est la valeur de ce travail pour l'entreprise ? 

TOGAF donne une sérieuse leçon de pragmatisme et d'humilité : un travail d'architecture produit ou commandé dont ne peut estimer ou prouver la valeur pour l'entreprise n'a aucune valeur.

Il est même dangereux parce qu'à terme l'accumulation de ce genre de travaux a tendance à se transformer en un bâtiment de forme ronde, de haute taille et  de couleur ivoire, avec des gens en colère qui tourne autour prêt à en découdre.

Je vous laisse devenir qui est dans la tour.

Premier enseignement, un travail d'architecture est correct non pas quand l'architecte est content mais quand il est conforme au cadre de capacité d'architecture lui même conforme aux aspirations et contraintes de l'entreprise.

L'architecture n'est donc pas au service de l'architecte mais de l'Entreprise. 

C'est évident me dirait vous ! Pas tant que cela, réfléchissez-y toutes les solutions que vous mettez en oeuvre ont-elles une valeur pour l'Entreprise ? Etes-vous en mesure de démontrer clairement cette valeur ?

Les plus attentifs d'entre vous auront remarqué que j'ai utilisé un E majuscule pour entreprise.

Ce n'est pas pour faire l'intéressant, vous allez voir.


Alors l'Entreprise c'est quoi ?


Chaque interlocuteur qui lira les paragraphes précédents se dira que le mot Entreprise est une autre façon de désigner ses préoccupations. Pas tout à fait ...

TOGAF définit l'Entreprise comme l'ensemble des acteurs concernés par une transformation.

Par acteur concerné, TOGAF entend tous les acteurs concernés qu'il soit hors de l'entreprise au sens juridique (les sous traitants par exemple, le grand public, ...) ou dans l'entreprise (les salariés de l'entreprise).

Si l'on considère par exemple un transformation d'un système d'information, il faut considérer aussi bien les acteurs fonctionnels que techniques, les fournisseurs qui vont participer à la transformation, ....

Il est également important de considérer le concept de transformation comme un changement dans l'architecture de l'Entreprise : un changement peut être une augmentation des capacités de l'Entreprise  (achat d'un concurrent, migration vers une technologie plus performante, ...) ou la suppression d'une capacité (arrêt d'un produit, vente d'une partie de l'Entreprise, ...).

L'intérêt donc de l'Entreprise est donc l'ensemble des intérêts des acteurs concernés.

De facto, TOGAF est une méthode qui prend en compte dès le départ dans ses fondements même, que l'architecture est l'art de construire un compromis. L'intérêt des fournisseurs n'est pas le même que celui du client qui lui même se compose de groupes aux préoccupations diverses.

Vous aurez probablement remarqué que cet art du compromis n'est pas forcément répandu dans nos entreprises, les situations conflictuelles entre les fonctionnels, les achats et les techniques sont légions et parfois apparaissent bien tard.

TOGAF insiste aussi sur le fait qu'une transformation n'est pas toujours positive, il faut prendre en compte aussi bien les acteurs qui ont a perdre que ceux qui ont a gagné à la transformation. En effet, il ne faut pas oublier qu'un acteur touché négativement peut très bien avoir une influence importante ce qui peut être une cause d'échec ou de perturbations sévères.

Points de vue


TOGAF notamment dans l'étape de mise en place du cadre de capacité indique qu'il faut déterminer pour chaque acteur concerné, le juste point de vue.

En effet, le point de vue des achats n'est pas celui de la production qui n'est pas celui du métier.

Il est inutile et dangereux de tenter de communiquer avec les acteurs concernés sans structurer les informations avec le point de vue adapté. C'est une source de frustation et d'incompréhension pour les acteurs.

Vous n'obtiendrez pas un compromis satisfaisant en utilisant les même représentations pour tous les acteurs concernés.

L'idée est qu'une architecture de SI est comme une architecture réelle : l'architecture d'un bâtiment est composée de multiples point de vue légitimes (plomberie, électricité, équipements de sécurité, ...),  chaque corps de métier possède son langage et ses représentations.

L'architecte a la vision globale et doit résoudre les conflits et les incohérences entre les différents points de vue.

Le cadre de capacité


Ce cadre est fondamental, c'est lui qui permet de construire votre capacité d'architecture qui se traduira par une nouvelle gouvernance : commissions, dossier d'architecture, revues diverses, ...

Tout vient du cadre de capacité.

Ce cadre est une méthode dans la méthode, il vous guide dans la mise en place de tous les outils nécessaire pour produire de l'architecture.

Il fournit des profils types, des grilles de compétences, des modèles d'organisation, ....

Comme TOGAF est basé sur des retours d'expérience, il propose des outils qui fonctionnent et surtout conduit l'équipe qui va utiliser le cadre de capacité à se poser des questions fondamentales pour construire la capacité de l'Entreprise :

L'Entreprise a-t-elle moyen de supporter cette gouvernance ?
Combien ça coûte ?
Quels sont les ressources humaines nécessaires ?
Quelles sont les acteurs concernés ?
Quels sont les points de vue utiles à ces acteurs ?
Quelles sont les personnes physiques impliquées avec quels rôles ?
Etc ...

Il est illusoire de créer soit même une capacité d'architecture sans tenir compte de ces bonnes pratiques car il s'agit d'une démarche complexe.

Une capacité d'architecture qui fonctionne implique que de nombreux acteurs de l'Entreprise y compris des acteurs non techniques y participent.

Tous ces acteurs sont par ailleurs impliqués dans leur métier au quotidien et "ont d'autres chats à fouetter". La mise en place d'une telle gouvernance leur apportera de nouvelles contraintes et une charge de travail accrue.

Pour éviter de décrédibiliser totalement cette démarche il est important d'éviter tout amateurisme et empirisme car l'architecture est l'affaire de tous et non de quelques architectes.

Si les conditions optimales ne sont pas réunies vaut mieux revoir ses ambitions à la baisse que de monter une gouvernance qui ne sera pas opérationnelle pour tout un tas de raison, quitte à monter en puissance au fil du temps.

Conclusion

A travers quelques exemples de concept TOGAF, j'espère vous avoir donné envie de vous plonger dans cette méthode.

Pour ma part, une des intérêts de TOGAF réside dans l'approche globale de l'architecture des SIs, elle offre des outils conceptuels très puissants pour appréhender la complexité des travaux de transformation des SIs.

Enfin, même si vous ne dites pas que vous appliquez TOGAF, l'utilisation de quelques uns des principes pourrait améliorer fortement votre pratique.

Alors n'hésitez plus !


  





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

samedi 15 juin 2013

NetBeans : configure the IDE for extra productivity


Java IDEs are memory eaters.

If your NetBeans is working fine when using default configuration it may work better if you tune JVM memory a little bit.

Indeed, if NetBeans lacks of Java Heap, it can trigger many garbage collections and slow down the whole IDE.

I use a special configuration to enhance NetBeans.

You have to edit the netbeans.conf file which lies in NETBEANS_HOME/etc/ folder.

Add extra heap like this :

netbeans_default_options="-J-client -J-Xss2m -J-Xms32m  -J-Xmx1024m -J-XX:PermSize=32m -J-XX:MaxPermSize=192m  ..."


On Mac, for DMG install only, you have to access the NetBeans package content in order to edit the file : It's in /Applications/NetBeans/NetBeans 7.3.1.app/Contents/Resources/NetBeans/etc/ for instance.


Have fun, with this wonderful IDE !






Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

JSF and AJAX : a happy wedding if you understand IDs management


JSF 2 brings AJAX support to a high level of productivity for server side development; but you have to understand some subtle mechanics to really enjoy it.

One of this mechanic is IDs management.

About IDs


IDs, like their names tell us, allow to identify components in the view.

Each component is in the view at a certain place, the whole is a tree of components.

Every ID must be unique.

When doing AJAX with JSF you have to use IDs for source of the request and target of the request.


Use case


Here is a sample page :

Loading ....



I want to refresh 3 areas when my AJAX request complete :
- output inside the  main form
- output2
- output3 inside a second form


Like an UNIX filesystem



Everything is in the ":" usage.

So what means the ":" char ?

The key is to consider it like the slah char in UNIX filesystem.


Component are like files, some are directories : they contain other components.
Some directories are special, they have an influence on client IDs computation.

These special components are  naming container, they give their IDs to their children as a prefix.

So if you inspect XHTML you can see mainform or secondform prefix on some children nodes.

When an AJAX request is running, the current context for ID computation is the nearest naming container in the hierarchy.

All IDs used in ajax tag without a ":" are evaluated from this starting point. This is the current directory.

The solution


In sample above, my AJAX tag must use the following IDs :



Loading ....

Why


1) What is the nearest naming container ?

It's mainform.

2) What is the relationship between output and mainform ?

output is a child node, I can target it directly and relatively:

./output -> output

3) What is the relationship between output2 and mainform ?

It's not in mainform, I must target it through the root of the tree, like I do with a filesystem :

/output2 -> :output2

4) What is the relationship between output3 and mainform ?

It's not in mainform, I must target it through the root of the tree but it's in secondform "directory" :

 /secondform/output3 -> :secondform:output3

Few tags are naming container :
- data
- form

But all composite components you create or use are naming containers !

Be careful when using these, they have a serious impact on how you have to write IDs in AJAX tags.

So, enjoy using both JSF and AJAX !





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.