Issam El Fatmi

 

JEE6 – Glassfish 3.1, Clustering & Failover

Article publié par le 23 novembre 2011.

Catégorie(s) : Java / JEE

 

26 commentaires »

En Java EE, on parle souvent de clustering de serveurs d’application pour évoquer la mise en relation d’un certain nombre de serveurs.

On parle également de failover pour parler de la capacité à rendre l’indisponibilité d’un ou de plusieurs serveurs du cluster complètement transparente vis à vis du client; cela se traduit par le fait de garantir au client la reprise du même contexte d’exécution qui existait en amont de l’apparition de la panne du serveur incriminé.

Glassfish V3, l’implémentation de référence de JEE6 (JSR 316), inclut à partir de sa version 3.1 des nouvelles fonctionnalités de clustering (synchronisation lors du démarrage d’une nouvelle instance, réplication des changements dynamiques de configuration,…), et offre également un mécanisme de réplication de la session http et des EJB statefull.

Au cours de cet article nous aborderons la mise en place d’un cluster glassfish, la configuration Apache avec le plugin Glassfish Load Balancer et le test du failover à travers une application web.

Il faut noter que toutes les étapes d’installation et de configuration peuvent être réalisées en mode console ou en mode GUI (à travers la console d’administration Glassfish). L’approche console (ligne de commande) a été adoptée.

Lire la suite de cet article »

Deployer un artefact sur repo1.maven.org

Article publié par et le 22 juin 2011.

Catégorie(s) : Java / JEE

 

3 commentaires »

Vous avez peut-être eu l’obsession de voir « maven » en train de télécharger vos propres artefacts à partir de son repository central. Du moins vous vous êtes sûrement posé la question : mon projet est mavenisé, open source, sur une forge publique (github, googlecode, etc.) et il est destiné à être utilisé par le plus grand nombre ; pourquoi ne pas le publier sur le Maven Central Repository (http://repo1.maven.org) ?

Au lieu de penser à ouvrir votre Nexus sur Internet ou encore à créer votre propre repository sur Google Code ou autre, nous vous proposons de directement déployer sur le Maven Central Repository, ce qui, en plus de vous épargner l’installation d’un repository, facilitera l’utilisation de votre artefact.

Le but de ce billet est de décrire la marche à suivre pour la publication d’un artefact en passant par le repository de Sonatype. Ce dernier étant un repository approuvé pour tout projet OSS comme c’est le cas du repository Apache (pour les projets Apache) et celui du Codehaus (pour les projets Codehaus). Le fait de passer par Sonatype vous garantit d’une part, un processus de validation structurant qui impose un ensemble de points de contrôle (licence, copyright, traçabilité, etc.) augmentant ainsi la qualité des métadonnées, et d’autre part une synchronisation rapide avec le Maven Central Repository.

Il s’agit également de vous faire profiter de notre expérience sur le sujet avec le déploiement de quelques artefacts tels que mindmap-maven-plugin, xebia-management-extras, xebia-spring-security-extras et xebia-servlet-extras.

Lire la suite de cet article »

Le Mind Mapping appliqué aux dépendances des projets « mavénisés »

Article publié par le 5 mai 2011.

Catégorie(s) : Java / JEE

 

8 commentaires »

Mots-clefs :,

Comme vous l’avez peut-être constaté dans vos applications d’entreprise, les dépendances des modules sont parfois difficiles à appréhender, de par leur nombre et la complexité des relations.

Encore plus si vous vous retrouvez face à un chantier de refactoring important qui touche à votre application en sa globalité (refonte du modèle métier, éclatement de modules, restructuration des couches logicielles, migration de framework, externalisation des traitements communs en aspect, …) ; assurer la réussite d’un tel chantier s’avère généralement une tâche difficile : vous avez beau essayé de pousser l’étude d’impact au bout, les surprises sont toujours au rendez-vous.

Garder un œil sur l’application en phase de transformation implique systématiquement une prise de « snapshots » réguliers des dépendances entre modules ; cela vous permettra sans doute de savoir rapidement si vous êtes sur la bonne voie, ou si un « break – rethink to avoid worse » est nécessaire.

C’est dans cette optique que le Mind Mapping s’impose afin de fournir une vue documentaire visuelle facilement exploitable des dépendances des modules ; vous permettant ainsi de contrôler la tendance du projet et d’éviter toute apparition de dépendance cyclique directe ou indirecte (transitive), du moins la faire disparaître assez rapidement si elle est déjà là.

De ce fait, on s’aperçoit que cette approche a plus de valeur ajoutée pour le Lead technique ou encore l’architecte de l’équipe de développement que pour le développeur. Quant à ce dernier, et si besoin (on ne s’amuse pas à faire des « mvn dependency:tree » tous les jours), il pourrait rester fidèle aux outils qui viennent accompagner son IDE, que ce soit sous forme de plugin (Jdepend, byecycle, M2Eclipse avec Dependency graph view et Dependency Hierarchy view, …) ou encore en standalone (JDepend, mvn dependency:tree, …).

Dans cet article, on s’intéresse particulièrement aux projets « mavénisés ». La démarche consiste, pour un module donné, à produire un artefact pouvant être exploité par un outil open source de Mind Mapping. L’idée est donc de développer un simple plugin maven en charge de générer un fichier au format attendu pour l’outil. Il existe plusieurs logiciels open source de Mind Mapping à savoir FreeMind, FreePlane (un dérivé de FreeMind), Xmind, etc. Le choix est fait sur FreePlane qui traite des fichiers de type « .mm ».

Lire la suite de cet article »

Performance – Maîtriser son framework de test, The Grinder

Article publié par le 31 mars 2011.

Catégorie(s) : Java / JEE, Performance, Tests

 

Aucun commentaire »

La performance a été souvent considérée comme étant le parent pauvre des applications. Afin de combler ce défaut et de détecter les éventuels points de faiblesse des applications, plusieurs outils propriétaires et open source ont vu le jour sur le marché: Compuware/Qaload, LoadRunner, OpenSTA, JMeter, etc, et notamment The Grinder. L’adoption de ce dernier fut moins évidente que celle de son homologue côté Apache, du fait de l’absence de support et d’une interface GUI pour la définition, la configuration et le paramétrage des scripts ; ce manque de l’aspect « cliquodrome » a fait croire aux utilisateurs que l’outil est à mettre uniquement dans les mains d’un développeur python, et a également conduit à en dissimuler les talents.
Le but de cet article est de donner un ensemble de guidelines pour faire un meilleur usage de l’outil.

Lire la suite de cet article »