Formation java, formation UML, conseil - sewatech

Enrichir les logs avec LogWEx

Alexis Hassler — 2010-09-02T20:46:30Z

Plaçons nous dans le cadre d'une application développée correctement, avec des bonnes traces envoyées dans un utilitaire correct de type Log4J, éventuellement via une façade comme commons-logging ou, beaucoup mieux, SLF4J. Grâce à la configuration de Log4J, il est possible de choisir les informations qui apparaissent dans les fichiers de logs en plus du message à proprement parler : heure, niveau du log (erreur, alerte, info, debug, trace), le logger d'origine. Lorsqu'on est en développement, on peut aussi ajouter des informations plus précises sur l'origine comme la méthode et la ligne de code qui a envoyé le message.

Il nous manque souvent une information important : quel utilisateur a été à l'origine du log ? Qu'a fait ce même utilisateur avant d'en arriver là ? Voyons comment on peut avoir ces informations dans les logs...

Dans les logs des applications Web, on ajoute très souvent le nom du thread. Ceci permet de reconstituer une séquence de traces qui correspond au traitement d'une requête HTTP. En effet, dans les serveurs d'applications Web classiques, comme Tomcat, Jetty, JBoss, Weblogic,…, un thread est affecté au traitement de chaque requête, jusqu'à la production de la réponse. Par contre, plusieurs requêtes consécutives d'un même utilisateur peuvent très bien être traitées par des threads différents. L'affichage du nom du thread dans les logs est donc insuffisant pour reconstituer un historique plus important pour un utilisateur.

Il existe plusieurs techniques pour obtenir un résultat satisfaisant. La façon la plus riche est d'utiliser des outils dédié aux audits. Pour plus d'informations sur le sujet, je vous renverrais vers l'article de Cyrille Leclerc et David Galichet et aux discussions associées. Dans mon cas, je vais m'intéresser aux applications pour lesquelles un tel besoin n'a pas été pris en compte au développement. En gros, on n'a que les logs. Dans ce cas, la technique qui ne nécessite aucun développement passe par un croisement entre les logs applicatifs et les logs d'accès (cf. AccessLogValve, pour Tomcat). Ce dernier nous donne des informations comme l'Id de session, l'utilisateur authentifié, s'il l'a été par une technique standard et le nom de thread. Tout cela est réalisable puisque le nom du thread est présent dans les deux fichiers, mais fastidieux.

Donc il va falloir développer. Au minimum, il faut faire un filtre qui va intercepter les requêtes. Pour chaque requête, on peut envoyer une trace de début et une trace de fin, avec les mêmes informations que pour les logs d'accès, à la différence que dans le cas du filtre, les traces sortiront avec les logs applicatifs. En centralisant ces traces, l'exploitation est un peu plus simple.

L'idéal serait d'avoir toutes les informations directement dans chaque trace applicative. Dans ce cas, des outils rudimentaires comme grec ou un tableur suffiront pour exploiter les informations. Pour arriver à ce résultat, on va utiliser le MDC (Mapped Diagnostic Context) de Log4J pour que notre filtre y stocke les informations nécessaires (identifiant de session, nom d'utilisateur,...).

 MDC.put("session.id", session.getId()) ;

Une fois les informations présentes dans le MDC, il est facile de paramétrer la layout de Log4 pour qu'elles sortent dans les fichiers de logs : %Xsession.id. L'avantage de cette technique, c'est qu'on n'est plus obligé de ce contenter d'information standards, on peut très facilement ajouter des informations présentes en attributs de session et les ajouter au MDC.

Ayant eu à développer ce type de filtre pour plusieurs clients, nous avons décider de développer un tel filtre sous licence Open Source, sous le nom de LogWEx (Logging Extra for Web applications). L'objectif du projet est de vous fournir un filtre générique qui vous fournisse les informations nécessaire uniquement par configuration, sans développement.

La première version ne fournit que l'identifiant de session, le nom de l'utilisateur et les propriétés de la requête (hosto, port, pat,…). Les prochaines versions devraient s'enrichir rapidement pour atteindre l'objectif. Pour l'instant, LogWEx n'est utilisable qu'avec Log4J car c'est l'outil le plus utilisé par nos clients, mais nous évaluerons rapidement l'opportunité de supporter aussi LogBack qui est les meilleur outil de log du moment.

J'invite donc tous ceux qui veulent enrichir leurs logs à essayer LogWEx et à nous faire leurs retours sur le bug tracker du projet sur GitHub.

Pour en savoir plus : projet LogWEx

JavaSE 6 update 10, un update majeur ?

Alexis Hassler — 2008-10-21T19:37:56Z

Normalement, en Java, un update a pour seul objectif de corriger des anomalies. Depuis Java 5, la notion de mise à jour mineure n'existe plus ; pour preuve, le numéro de version ne comporte plus qu'un seul chiffre : JavaSE 6 ou JavaSE 7. Nous sommes bien loin de l'antique numérotation à rallonges qui prévalait il y a quelques années avec des J2SE 1.4.2 !

Cependant, il reste important pour Sun de corriger les bugs et de combler les failles de sécurité. C'est le rôle des updates. Normalement, une mise à jour de ce type ne devrait modifier le fonctionnement de Java que sur des aspects secondaires, et uniquement en relation avec les bugs corrigés.

A l'opposé de ces modifications mineures, l'update 10 de JavaSE 6 marque un tournant important dans la philosophie de distribution de Java. Par contre, la syntaxe, les classes et interfaces n'ont pas changé ; il faudra attendre JavaSE 7 pour cela. C'est pour cela que cette mise à jour est considérée comme mineure.

Quoi de neuf ?

La grande nouveauté apportée par cette mise à jour est l'abandon de la structure monolithique du runtime JavaSE.

Le fichier d'installation complet du Java Runtime Environment 6 (ou JRE 6), pour Windows, fait environ 15 Mo. Cela fait d'ailleurs plusieurs versions que la taille a été stabilisée à ce niveau. Le problème devient flagrant lors des mises à jour, puisque l'ensemble du JRE est téléchargé et devient vraiment pénalisant dans des environnement Web, lorsque Java veut concurrencer Adobe Flash ou Microsoft Silverlight. Or c'est justement sur ce terrain que Sun s'est engagé avec JavaFX.

JavaFX et applet

JavaFX est en effet la proposition technique de Sun pour le développement de Rich Internet Applications (RIA). Ce type de solution doit allier la souplesse du déploiement d'applications Web avec une plus grande richesse graphique et une meilleure ergonomie.

JavaFX ne fait pas partie de JavaSE 6 update 10, il ne sortira qu'en fin d'année. Mais on peut considérer que cette mise à jour prépare le terrain.

Sun a d'ailleurs été parmi les pionniers dans le domaine, avec la technique des applets. Mais les contraintes en terme de gestion des évolutions et les incompatibilités entre les versions du JRE ont eu la peau de cette technique. Depuis la fin des années 90, je conseille à mes clients de tout faire pour éviter d'utiliser les applets !

Les choses pourraient bien changer avec cette mise à jour... Elle embarque tout simplement une mise à jour du plug-in Java, le composant du JRE qui se branche sur les navigateurs pour prendre en charge l'exécution des applets. Et cette nouvelle version arrive avec son lot de nouveautés plutôt intéressante.

D'un point de vue technique, la révolution vient du nouveau modèle d'exécution des applets et de son rapprochement avec la technique JNLP de WebStart. Auparavant, une applet s'exécutait au sein du même processus que le navigateur Web. Ceci empêchait tout cohabitation entre versions de Java. Aujourd'hui, même si l'applet est ouverte depuis un navigateur, elle s'exécute dans le processus autonome d'une JRE.

Par défaut, un seul processus Java est démarré, pour toutes les applets, mais il est possible d'en démarrer plusieurs, ce qui ouvre de nombreuses possibilités, comme celle de faire coexister plusieurs versions de Java. Il est aussi possible de passer des paramètres différents, comme pour un lancement en ligne de commande, pour améliorer les performances. Dans l'exemple suivant, l'applet se lance dans une machine virtuelle autonome, avec un paramétrage mémoire spécifique :

<APPLET archive="sewapplet.jar" code="Sewatech Applet" width="800" height="300">
 <PARAM name="java_arguments" value="-Xmx256m""> 
 <PARAM name="separate_jvm" value="true">
 </APPLET>

Autre nouveauté, visuelle celle-ci, avec les applets draggables. Cette technique permet de transférer une applet, qui s'exécute dans un navigateur, vers le bureau. Un application Web devient alors une application desktop. Pour que l'applet soit draggable, il faut ajouter un élément dans sa déclaration, au niveau de la page HTML :

<APPLET archive="sewapplet.jar" code="Sewatech Applet" width="800" height="300">
 <PARAM name="draggable" value="true">
 </APPLET>

Rien que cela peut nous réconcilier avec les applets.

Déploiement

En fait, la principale évolution vient du modèle d'installation du JRE. Fini le téléchargement d'un gros fichier de 15 Mo sous Windows, ou 18 à 19 Mo sous Linux, desquels on n'utilise que 30 à 40%.

Dans le modèle d'installation classique, qui est toujours utilisable, le JRE est un ensemble monolithique qu'on installe dans sa globalité, quel que soit le type d'application qu'on veut exécuter. Même pour une application en ligne de commande, on installe les classes graphiques, et même pour un écran simple, on doit installer les API de management ou CORBA.

Dans le nouveau modèle, on installe d'abord le noyau du JRE avec le Java Kernel Installer ; ce fichier fait entre 5 et 7 Mo. Les modules supplémentaires ne sont téléchargés qu'en cas de besoin. De plus, en utilisant les possibilités de JNLP, on peut préciser des URL d'extensions nécessaires à l'applet, qui seront automatiquement téléchargées.

Et le JDK ?

Du coté du JDK, il n'y a pas de changement aussi radical. Le fichier à télécharger est toujours en un seul bloc de plusieurs dizaines de Mo (plus de 70 Mo, pour Windows). Cela reste préférable, puisque je vois mal mon éditeur de code commencer à télécharger des composants du JDK avec de me lancer continuer une classe.

Le seul impact est donc dans la façon de développer des applets et des applications WebStart.

Conclusion

La plupart des projets ne verront pas de changement significatif avec cette nouvelle mise à jour. Les applets sont, et resteront encore longtemps, marginales dans les architectures. Nous attendrons toutefois de voir comment JavaFX arrivera à s'imposer face à des concurrents bien plus avancés comme Adobe Flex.

Utilisez les types abstraits

Alexis Hassler — 2007-12-20T14:32:24Z

Les bonnes pratiques de conception imposent de concevoir toutes les classes orientées services (métier, accès aux données et services connexes) sous forme duale, une interface et une classe d'implémentation, et d'établir les dépendances vers les interfaces. Les classes ne sont utilisées que pour l'instanciation, de préférence via une factory (design pattern factory ou abstract factory).

Types abstraits et types concrets

Par exemple, dans une application de gestion de cours, la couche métier est constituée d'une interface CourseService et d'une classe CourseServiceImpl et la couche d'accès aux données est constituée d'une interface CoursDAO et d'une classe CourseDAOJdbc. Cette classe implémenente le contrat imposé par l'interface avec l'API d'accès aux bases de données JDBC.

En développement, cette pratique se traduit par l'utilisation la plus généralisée possible d'interfaces pour les déclarations (attributs, arguments de méthodes,...). Cela se traduit oar exemple par l'utilisation de classes telles que ArrayList, HashSet ou HashMap uniquement au moment du new ; les interfaces List ou Collection, Set et Map sont utilisées partout ailleurs, c'est-à-dire pour les déclarations.

Exemple :

 public class CourseDAOImpl [
 List<CourseData> findAll() {
 List<CourseData> result = new ArrayList<CourseData>();
 //...
 return result;
 }
 }

Les exemples de cette nature peuvent aussi être trouvés avec des types plus techniques comme javax.sql.DataSource et toutes les interfaces JDBC donc on ne connait normalement pas les implémentations.

Pourquoi ?

Dans le cadre de la conception, cette façon de construire l'application a essentiellement deux avantages.

Le premier est l'interchangeabilité des implémentations. Ainsi la classe CourseDAOJdbc qui implémente l'interface CourseDAO peut facilement être remplacée par CourseDAOHibernate, qui implémente la même interface. Ceci est l'application concrète du principe de substitution de Liskov (j'aime trop le nom de ce principe pour ne pas le citer).

L'autre avantage est la rationalisation de la gestion des dépendances : les éléments concrets dépendent d'éléments plus abstraits et les éléments instables dépendent d'éléments plus stables. [référence...].

Les interfaces ont beaucoup moins de dépendances que les classes et comme ces interfaces sont la colonne vertébrale de l'architecture en couches, cela constitue une chaîne de dépendances propres et sans cycle. Les dépendances sont plus touffues au niveau des classes.

Même pour les types numériques !

Récemment, j'ai regretté de ne pas appliquer systématiquement cette règle de programmation.

En effet, lorsque je travaille avec des types numériques, j'utilise directement les types concrets : Integer, Long,... Or ces classes hértient toutes de Number, que j'aurais pu (et dû ?) utiliser plus souvent.

Concrètement, c'est avec hibernate que j'ai rencontré un problème avec le type Number et ses sous-classes.

Hibernate supporte dans son langage HQL (Hibernate Query Language) des fonctions qui renvoient un nombre entier : count, max, min,... Pour executer ces fonctions, on exécute une query, puis on récupère le résultat.

 public int count() {
 Session session = getSessionFactory().getCurrentSession();
 Query query = session.createQuery("select count(*) from Course");
 int result = ( (Integer)query.uniqueResult() ).intValue();
 return result;
 }

L'exemple précédent fonctionne parfaitement avec Hibernate 3.1 car ces fonctions renvoient des Integer. Par contre, il ne passe pas la migration vers Hibernate 3.2 ! En effet, les fonctions ont évolué et renvoient maintenant des Long.

Si j'avais respecté le principe enoncé en introduction, je n'aurais pas du utiliser Integer car tout ce dont j'avais besoin était la méthode intValue qui est définie dans Number. J'aurais donc du écrire le code suivant :

 public int count() {
 Session session = getSessionFactory().getCurrentSession();
 Query query = session.createQuery("select count(*) from Course");
 int result = ( (Number) query.uniqueResult() ).intValue();
 return result;
 }

Ce code respecte le principe d'utilisation des types abstrait et passe sans encombre la migration vers Hibernate 3.2.

Le principe peut s'appliquer partout, même là où on l'attend le moins...

10 ans d'UML, et après...

Alexis Hassler — 2007-05-19T20:55:22Z

Après 10 ans de pratique d'UML, on commence a avoir suffisamment de recul pour connaître les forces et faiblesses du langage et de ses outils. Il est temps de se remémorer les projets sur lesquels UML nous a été utile et tous les problèmes rencontrés.

Après toutes ces années, on peut même aller jusqu'à se demander si UML est toujours d'actualité et s'il est encore vraiment utile...

Les objectifs d'UML

UML [1] a été élaboré au milieu des années 90, sur la base des principales méthodes objet de l'époque, OMT, Boosch, OOSE et quelques autres. Son objectif était d'unifier les techniques de modélisation entre les différentes méthodes.

Le premier quiproquo a été de penser que UML était un remplaçant de Merise. Or les ambitions d'UML sont bien en deçà puisque limitées à la modélisation, sans aborder la démarche.

Revenons à ces termes de méthode, modélisation et démarche. La modélisation, c'est juste du dessin ! On schématise ce qu'on a en tête, soit pour représenter une réalité, soit pour illustrer une conception. La démarche précise l'enchaînement des tâches qui permettent de mener à bien le projet. LA méthode est l'assemblage d'une démarche et d'une technique de modélisation.

Le second quiproquo a été de penser que RUP [2] est la seule démarche adaptée à UML. Certes les auteurs d'UML et de RUP sont les mêmes [3], mais cela ne suffit pas...

RUP est trop lourd

RUP décline toutes les possibilité d'UML dans une succession de disciplines d'ingénierie (Modélisation du métier, Expression des besoins, Analyse et conception, Réalisation), agrémentée des disciplines de support nécessaires à l'organisation du projet (planification, gestion du changement,...). Il est vrai que tout ceci s'enchaîne bien et répond bien aux exigences habituelles de suivi qualité, grâce à tous les livrables intermédiaires. Il est vrai aussi qu'en décryptant le vocabulaire spécifique à RUP et UML, on peut se rendre compte que le passage de Merise à RUP ressemble plus à une adaptation de la démarche à la logique objet qu'à la révolution annoncées un temps. Par contre, RUP est souvent présenté comme un standard alors que ce n'est qu'un produit commercial, propriété de Rational (IBM aujourd'hui). De ce point de vue, on doit le comparer à des concurrents comme 2TUP [4] de Valtech ou à EUP [5] de Ambysoft, beaucoup moins connus, mais relativement proches.

Que reproche-t-on à RUP ? Pas d'être propriétaire, c'est le jeux de l'industrie informatique. Peut-être d'être trop détaillé... C'est vrai qu'en essayant d'être exhaustif, RUP propose pléthore d'options qui laissent une trop grande liberté au projet. Certes cela permet de s'adapter à de nombreux contextes, mais impose de recourir à un consultant expérimenté. RUP n'est donc pas un produit livré clé en main.

Ce qu'on reproche plus souvent à RUP, c'est sa lourdeur. En effet, toutes les étapes et tous les livrables proposés peuvent donner l'impression qu'on passe plus de temps sur des tâches non directement productives. Rational a bien essayé de corriger le défaut en éditant des notes et livres blancs nous expliquant que RUP pouvait être agile et s'adapter aux petits projets. Tout ceci n'a guère convaincu face à des méthodes comme l'extreme programming.

UML dans les méthodes agiles

La plus connue des méthodes agiles est XP [6]. Elle détaille une série de principes rigoureux centrés sur la production de code de qualité. La principale différence avec RUP est que pour ce dernier, toute la démarche est centrée sur le modèle, alors que pour XP elle est centrée sur le code source. La première surprise pour un spécialiste UML est de constater que UML est absent de XP ! On retrouve certes des concepts similaires, comme ceux des CRC, mais sans le formalisme standard.

Vue la convergence des concepts, on peut facilement utiliser des diagrammes UML avec XP, à ceci près qu'XP étant extreme, dès qu'on s'éloigne d'un principe, on sort du cadre de la méthode.

Pour résumer, UML s'applique parfaitement aux méthodes agiles, il suffit de ne pas chercher à utiliser la totalité des diagrammes et de rechercher avant tout l'efficacité :
des cas d'utilisation pour les story boards
des classes et des états
des communications (ou collaboration en UML1) pour les aspects dynamiques

Et si MDA était la solution ?

MDA [7] est la suite logique de RUP, ou plutôt une façon d'outiller un processus centré sur le modèle, afin d'automatiser les transformations du modèle entre les étapes du projet.

Là aussi, les principes sont séduisants, mais leur mise en œuvre fastidieuse et coûteuse en investissement initial. Les paramétrages et développements des moulinettes de transformation peut prendre du temps et nécessite un bon niveau de compétence.

En complément de ces outils centrés sur le modèles, sont apparus, puis ont presque disparu, des outils visant à passer le plus rapidement possible du modèle (souvent limité aux classes) au code. Les moins jeunes retrouveront le principe des antiques outils RAD qui permettaient de mapper des écrans directement sur la base de données. Ces nouveaux outils RAD (appelés Smart RAD ou RAD architecturé) visent le même objectif, en respectant les principes d'architecture en couche. Les plus ambitieux de ces outils ont disparu, et le RAD architecturé est resté un marché de niche.

Quid d'UML dans les SOA ?

Tout d'abord, il faut constater qu'UML n'a jamais tenu compte des SOA [8], étant largement antérieur à ces architectures, même lorsqu'on prend en compte UML2. Cette version apporte plus à l'informatique industrielle qu'à la gestion.

Les services d'une SOA peuvent être modélisés sous forme de classes, d'interfaces ou de composants et leur orchestration sous forme de diagramme d'activité. Le formalisme de ce dernier reste cependant trop pauvre, en particulier pour représenter les différents niveaux de détail, du plus synthétique au plus exhaustif, permettant de comprendre les services métier attendus et concevoir les services à implémenter.

Admettons qu'on puisse s'en sortir pour représenter les aspects techniques d'une architecture SOA. Pour les aspects métier, UML s'est fait suplanté par des formalismes propriétaires spécifiquement orientés BPM [9].

Finalement, UML est-il réellement utile ?

Dans tout l'article, j'ai détaillé les déceptions et limites d'UML. Et pourtant je l'utilise sur presque tous mes projets... Et pas uniquement pour utiliser un formalisme standard, mais par soucis d'efficacité, et différemment selon le format du projet.

Sur les projets avec de grosses contraintes de suivi qualité, l'utilisation orientée RUP, ou UP [10], s'impose ; la direction de projet a besoin d'un grand nombre de livrables visibles et lisibles pour mesurer l'avancement. Le très célèbre Rational Rose était bien adapté. Aujourd'hui cet outil n'est plus maintenu, n'a pas évolué vers UML2 et se trouve en perte de vitesse ; la concurrence a eu le temps de se développer avec des prix nettement inférieurs et/ou des capacités supérieures. Pour les projets de type UP, on privilégie des outils adaptés aux disciplines amont (expression des besoins et analyse). Il faut donc que l'outil permette d'organiser et de détailler efficacement les cas d'utilisation et d'articuler les diagrammes d'interaction (séquence et communication / collaboration) avec les diagrammes de classes. La plupart des outils commerciaux répondent à ces besoins ; pour ma part, j'apprécie particulièrement Sparx Enterprise Architect, même si un outil comme Sybase PowerAMC, souvent déjà utilisé dans les entreprises, convient tout à fait.

Sur les projets orientés XP ou méthode agile, UML peut sembler a priori moins important. Cependant, les cas d'utilisation pour représenter les story boards est une bonne idée et dessiner les classes facilite leur compréhension. Ces méthodes étant centrées sur la production de code et qualité, c'est la représentation UML de celui-ci qui devient la priorité, et donc la capacité de l'outil à faire du reverse-engineering, c'est-à-dire générer un modèle à partir du code, ou, mieux encore, à faire du round-trip, soit faire des allers-retours entre code et modèle, en conservant les modifications portées de part et d'autre. Les outils les plus évolués pour ce type de projets sont ceux qui mettent à jour le modèle et le code de façon synchrone, quel que soit l'endroit où la modification est faite. Si des outils comme Rational Application Developer d'IBM supportent ces fonctionnalités, et si Together est capable de la faire depuis plusieurs années, il faut reconnaître qu'aucun outil n'est totalement satisfaisant aujourd'hui.

Enfin, j'utilise souvent UML dans les missions d'audit, plus particulièrement les fonctions de reverse-engineering des outils. cela permet d'avoir rapidement une vue d'ensemble du système et de faire ressortir quelques éléments fondamentaux d'une conception objet : l'architecture en couches et les dépendances entre packages. Dans ce cas, ls contraintes sont très différentes : l'outil doit certes supporter correctement les diagrammes UML, mais il doit en plus être compatible avec le langage de développement. Coté java, les évolutions de java 5 ont créé un fossé entre les outils. Par ailleurs, l'outil de modélisation doit être facile à installer, pour pouvoir mettre en place rapidement un poste d'audit chez le client. Ce dernier critère met hors-jeu bon nombre d'outils, en particulier toutes les solutions IBM. Enfin, et pour des raisons similaires, la licence doit être souple, et de préférence open source. Sur tous ces critères ressortent Jude, pour les projets jusqu'à java 1.4, ou BoUML, moins ergonomique, mais qui supporte java 5.

En conclusion, j'utilise UML pour la plupart de mes missions, je dois donc reconnaître que malgré tous ses défauts, il est devenu quasiment indispensable. Par contre, il faut être conscient qu'il existe une façon différente d'utiliser UML pour chaque contexte. Les 10 ans d'expérience servent à reconnaître en début de mission ce qu'on pourra en tirer...

[1] Unified Modeling Language

[2] Rational Unified Process

[3] Rumbaugh, Jacobson et Boosch, alias les amigos de Rational

[4] 2 tracks Unified Process

[5] Enterprise Unified Process

[6] eXtreme Programming

[7] Model Driven Architecture

[8] Service Oriented Architecture

[9] Business Process Modeling

[10] Unified Process

Quelles solutions open source pour java

Alexis Hassler — 2007-03-16T16:02:09Z

Les solutions open source ont le vent en poupe depuis quelques temps. Des organismes comme la fondation Apache sont reconnues depuis des années pour la qualité de leurs produits et des sociétés éditrices basent leur modèle économique sur la distribution de leurs logiciels sous licence open source. La nouveauté vient, d'une part, du fait que certains éditeurs basculent du modèle traditionnel au modèle open source et, d'autre part, du fait que la plupart des sociétés utilisatrices sont prêtes à faire confiance à des solutions open source.

Cet article ne remplace pas les catalogues, et ne recherche surtout pas l'exhaustivité. Il expose juste un avis totalement subjectif et ouvert à discussion.

Architecture et framework

Pour vos développements spécifiques, la première règle est de choisir son architecture avant de sélectionner les composants et frameworks open source qui permettront de la mettre en œuvre. Les outils que je citerai donc ici correspondent à mes choix d'architecture habituels.

Tout d'abord, le framework Spring s'adapte à la plupart des architectures, qu'on soit en Web ou en client/serveur. C'est donc devenu un incontournable qui constitue la colonne vertébrale de la plupart des nouveaux projets.

Des frameworks plus spécifiques à une couche de l'architecture se greffent ensuite sur Spring.

Pour la couche de présentation Web, JSF est devenu un classique. Dans une approche classique, on utilise habituellement Apache MyFaces. Des composants optionnels doivent souvent être ajoutés, via Apache Tomawahk, ou Ajax4Jsf. L'autre approche consiste à rechercher directement une suite de composants riches et intégrés. IceFaces constitue une offre très intéressante, en open source depuis peu.

Si la complexité des mécanismes JSF vous rebute, Apache Struts reste une très bonne alternative.

Pour la couche de présentation client riche, que l'on utilise Swing ou SWT, il est nécessaire de s'appuyer sur un framework, et dans ce domaine rien de vraiment convaincant ne s'est présenté. Par défaut, je citerai tout de même Eclipse RCP, qui fournit des services intéressants, à compléter.

Pour la couche d'accès aux données, je privilégie Hibernate, qui est devenu un standard du marché dans le domaine du mapping objet/relationnel. Cette solution commence à être concurrencée par les EJB 3.

Outil de développement

Il reste ensuite à intégrer tout cela dans un environnement de développement. En la matière, Eclipse constitue une référence indiscutable. Il est vrai que ses fonctionnalités sont d'une puissance impressionnante pour tout ce qui tourne autour de la manipulation de code java (refactoring, templates, raccourcis,...).

Par contre, je suis beaucoup plus réservé sur la qualité des assistants de développement. En effet, lorsqu'on utilise Eclipse, on dispose de peu d'assistants visuels, en même des outils aussi intéressants que WTP peuvent faire l'objet de critiques importantes (manque stabilité de certaines fonctions, lourdeur,...). Les solutions intégrées comme MyEclipse évitent de s'embêter à agréger des plug-ins d'origines diverses.

De ce point de vue, son concurrent Netbeans est mieux positionné, en particulier dans le domaine de JSF avec son plugin Visual Web Pack. Par contre, je trouve que l'outil dans son ensemble n'ai pas très pratique.

Serveur d'application

Pour le déploiement des applications JavaEE (ou J2EE), mon favori reste JBoss, même si je n'ai aucun a priori contre Jonas ou même Apache Tomcat, dans certains cas.

Évidemment, dans cet environnement, on utilisera le système de scripts ant, de traces Log4J, de tests unitaires jUnit, le système d'installateur IzPack (pour les éditeurs).

Synthèse

Pour résumer, voici une plateforme de développement que je conseillerais volontiers :
Framework : Spring, JSF avec IceFaces et Hibernate
Outil de développement : Eclipse avec MyEclipse
Serveur d'application : JBoss

Quid de l'avenir proche ?

La démarche de RedHat dans le domaine du développement java me semble assez prometteuse. Si on reproche souvent aux environnements Java de relever plus de l'artisanat que de l'industrie, si on arrive plus rapidement à une bonne productivité de développement avec les environnements .NET de Microsoft, c'est probablement à cause de la diversité des solutions et des difficultés d'assembler tout cela dans un environnement cohérent.

La réponse à ces réactions est d'apporter directement un environnement complet, issu du même fournisseur, sous la forme d'un stack. C'est ce qu'une société comme IBM a compris depuis longtemps (on remarquera la proximité de stratégie entre les suites VisualStudio 2005 et Rapid Application Developer 6). Attention, je parle bien de stratégie et pas du coté pratiques des outils !

Avant même son rachat par RedHat, JBoss avait commencé à compléter son offre, initialement limitée au serveur d'application, avec le portail, le workflow, les frameworks (hiberante puis seam). Depuis le rachat par RedHat, cette démarche orientée stack semble s'accélérer avec l'intégration des composants JSF (Ajax4jsf et Rich Faces et de l'outil de développement Red Hat Developer Studio issus du récent partenariat avec Exadel. Tout cela semble prometteur : à suivre...

http://java-source.net/
http://solutions.journaldunet.com/0301/030113_portails.shtml
http://php.developpez.com/etudes/cms-gestion-contenu-web/
http://fr.wikipedia.org/wiki/Portail:Logiciels_libres
http://portal.unesco.org/ci/fr/ev.php-URL_ID=12034&URL_DO=DO_TOPIC&URL_SECTION=201.html

_

Alexis Hassler — 2007-01-19T09:52:41Z

En complément de cette rubrique, vous trouverez d'autres articles d'Alexis Hassler sur son blog.

Les articles publiés ici sont des points de vue apportés par leur auteur sur des sujets touchant aux technologies Objet.

Retrouvez les articles en flux ou atom .

Les apports de JavaSE 6

Alexis Hassler — 2007-01-12T09:47:00Z

JavaSE 5 a été une évolution majeure pour la plateforme java avec, pour la première fois des évolutions visant à rendre le langage plus pratique. On a aussi constaté des gains importants en production avec une meilleure stabilité, des performances améliorées et, enfin, des outils de monitoring. Est-ce que JavaSE 6 continue sur la même voie, et quelles sont les améliorations apportées ?

Java 5

JavaSE

Les développeurs ont réellement apprécié le travail sur les aspects pratiques, en particulier avec la boucle "for each" et l'autoboxing. Du point de vue de la conception objet, l'avancée majeure a été l'introduction des generics : on sait enfin ce qu'on doit mettre et ce qu'on peut trouver dans une collection !

Et JavaEE ?

La spécification de JavaEE 5 est sorti environ 1 an après le Java SE de même niveau. Cependant, les serveurs d'application certifiés sur cette version tardent un peu à sortir. Vu la proportion d'applications JavaEE en entreprise, on peut se demander s'il est opportun de sortir un JavaSE 6 alors que beaucoup de projets utilisent encore un JDK 1.4, en que certaines des avancées de JavaSE 5 sont essentiellement utiles dans un environnement EE ; je pense en particulier aux annotations, qui ne sont utiles que si un framework (JavaEE ou autre) nous en propose un ensemble directement utilisable dans le code. Les nouveautés du coté du monitoring (jconsole, jstat,...) sont une évolution fondamentale pour l'exploitation des applications JavaEE, elles ne peuvent donc être utilisées qu'avec des serveurs d'application supportant les versions croisées (J2SE 1.4 avec JavaSE 5), comme Apache Tomcat, Jonas ou JBoss.

Java 6

Sun a abandonné l'idée de sortir des versions mineures de Java. Ainsi, après la version 5, vient la version 6, puis 7. JavaSE 6 (alias Mustang) est donc une version majeure de java, mais l'évolution qu'elle propose me semble bien moins importante que celle de Java 5, et, paraît-il, moins que celle de la version suivante, JavaSE 7, alias Dolphin.

On attend de cette nouvelle version qu'elle progresse encore dans les aspects pratiques pour le développement et pour l'exploitation.

Langage de script

Autant prévenir tout de suite : je ne suis, a priori, pas un grand fan des langages de script. Cependant, j'ai trouvé quelques applications intéressantes pour BeanShell pour l'administration de JBoss. Par contre, je n'ai pas encore pu cerner ce que cela pouvait apporter dans le cadre d'applications métier. J'ai donc du mal à m'enthousiasmer pour cette fonctionnalité.

Annotations

Les annotations s'installent progressivement, mais le retard sur le concurrent Microsoft .NET est encore très important, et ne se comblera que par leur utilisation intensive dans JavaEE. J'attends donc que mon environnement de développement exploite correctement ces nouvelles annotations et leur nouvelle API pour avoir un avis sur le sujet. Pour l'instant, je n'en ferais pas grand chose.

JDBC

Ce sujet n'avait pas évolué avec JavaSE 5, on attendait donc des nouveautés pratiques, et elles arrivent.

La gestion des drivers et des connexions est améliorée,lees requêtes XML ont été ajoutées et la gestion des exceptions a été revue, avec la mise en place de catégories d'exceptions, selon la gravité (SQLTransientException et SQLNonTransientException), et la possibilité d'itérer sur une SQLException (boucle "for each").

Un driver compatible JDBC4 est fourni pour la base JavaDB, directement dérivée de Apache Derby. Cette dernière est livrée directement avec le JDK.

On notera que la gestion des drivers est surtout améliorée par une technique de chargement automatique fournie par la classe java.util.ServiceLoader. Celle-ci est utilisable dans bien d'autres domaines pour lesquels on manipule des interfaces et leurs implémentations définies dynamiquement.

Si ces évolutions me plaisent, elles seront surtout utiles dans des projets qui n'utilisent ni d'outil de mapping O/R, ni de framework de persistance, ce qui, pour moi, constitue une petite proportion.

Web Service

Là encore, c'est un domaine ou le retard sur les aspects pratiques est impressionnant. Qu'est-ce qu'il est lourd de travailler avec des outils comme SOAP, malgré l'outillage qui s'est mis en place avec Ant et les outils de développement.

De ce point de vue, des API comme JAX-WS et JAXB sont fondamentales et leur intégration à JavaSE, une avancée majeur.

AWT / Swing

De ce coté-là, pas de révolution, mais des petites avancées pratique, comme les classes SystemTray , Desktop et SplashScreen, qui permettent une meilleure intégration dans l'environnement de travail.

Le système de layout a été complété et la création de look-and-feel facilitée.

L'avancée la plus importante dans le domaine des applications clientes est l'amélioration des performances apparentes.

Monitoring

C'était une des principales améliorations de JavaSE 5, et la version 6 continue l'effort. En vrac, les progrès suivants ont été faits :

Dump à la demande (outil jmap)
Rattachement dynamique de jconsole (et d'autres outils) à un processus java, sans options de démarrage spécifique (attention à la sécurité...)
Améliorations de la jconsole ; celle-ci est maintenant supportée officiellement
Gestion des OutOfMemoryError : diagnostic et notification
Portage de certains outils sur Windows (jmap, jstack)

Performances

On attend de voir avec nos propores applications, mais des gains objectifs de performances de 20 à 40% sont annoncés.

C'est peut-être la meilleure nouvelle.

Autres évolutions

L'API de collection continue de s'enrichir avec, en particulier, les Set et Map navigables dans les 2 sens. Vue l'historique et l'évolution de l'API, on devra peut-être mettre en place une formation spécifique pour les collections !

L'API d'entrées/sorties (IO) s'enrichit aussi avec une nouvelle classe java.io.Console, des progrès dans la manipulation des fichiers et en enrichissement des informations sur les adresses réseau.

Le CLASSPATH supporte enfin le caractère joker '*', ce qui nous économisera des scripts un peu répétitifs pour parcourir des répertoires lib.

Pour la liste complète des évolutions, je vous invite à consulter la note de livraison de JavaSE 6.

Conclusion

Tout cela continue d'aller dans le bon sens : faire de java un langage toujours plus puissant, mais aussi pratique à utiliser et facile à apprendre.

Je pense qu'on ne profitera de la plupart de ces évolutions pratiques que lorsque celle-ci seront directement intégrées dans notre environnement de projet. Pour celà, nous devrons attendre les mises à niveau de plusieurs produits :

Eclipse ou un autre outil environnement de développement qui arriverait à se hisser à son niveau ; ce sera peut-être NetBeans si la gains de performance de JavaSE 6 sont suffisants pour le rendre plus agile.
Serveur d'application : grâce à leur cycle de livraison plus rapide, les outils Open Source ont peut-être une opportunité d'enfoncer le clou contre les poids lourds du marché et leurs offres intégrées
Framework : en introduction, je notais le décalage en JavaSE et JavaEE ; il existe aussi avec les frameworks classiques comme Spring. Hors je ne me vois pas démarrer un projet sans spring.

Nous devrons donc ronger nos freins pour quelques temps encore.

JBoss est-il apte à la production ?

Alexis Hassler — 2006-12-06T09:19:00Z

Le question ne se pose pas pour un environnement JBoss dûment préparé, avec un sérieux travail de configuration. Il se pose par contre concrètement pour les configurations fournies par défaut.

Configurations par défaut

On peut aussi se poser la question différemment : lorsque JBoss livre son serveur d'application, à qui s'adressent-ils en priorité ?

Historiquement, JBoss s'est avant tout imposé chez les développeurs, de par sa légèreté, sa souplesse d'utilisation et sa facilité d'installation :
on télécharge,
on décompresse le fichier,
on pose le fichier à déployer dans deploy,
on lance le script run. Difficile de faire plus simple pour un serveur d'application certifié J2EE.

Le problème, c'est que dans un nombre significatif d'entreprises, la même procédure a été appliquée pour l'environnement de production. Si les performances de cette configuration par défaut peuvent être satisfaisantes pour une application peu gourmande, c'est du coté de la sécurité qu'il faut s'inquièter.

Performances

Du coté des paramètres de performances, les choses évoluent dans le bon sens au cours des versions. Ainsi, par défaut, JBoss est lancé en option Hotspot server, alors qu'en 4.0.2, il était encore lancé en client.

Du coté de la mémoire, les 128Mo maxi accordés lorsqu'on lance JBoss via le script run.sh (linux et unix) sont vraiment insuffisants. On peut demander au passage pourquoi sous windows, cette limite est placée à 512Mo alors que celle pour linux est longtemp restée aussi basse.

Dans la version 4.0.5, ces différences ont été gommée.

Sécurité

Parmi les aspects discutables dans la configuration par défaut, j'écarte les failles telles que celle citée sur le site JIRA de JBoss pour me concentrer sur des modifications considérées comme normales.

Tout d'abord, on constate que la console d'administration JMX est accessible sans aucune authentification. Lorsqu'on connaît les capacités de cette console, on se rend compte que cela revient à livrer les clés du serveur d'application.
La jmx-console permet non seulement d'arrêter une application ou le serveur, mais aussi de déployer des applications, sans avoir accès au système de fichiers ou accéder à des informations internes au serveur.

On notera aussi l'installation du http-invoker qui permet d'accéder aux composants EJB, JMX et à l'annuaire JNDI via http, sans authentification. L'accès à JNDI est évidemment autorisé en lecture !

Composants inutiles

Du coté des composants installés, cela ressemble plus à une foire ambulante qu'à un ensemble organisé et raisonnable. Certains composants semblent là uniquement pour être montrés.

Je pense par exemple à cette base de donnée HsqlDB, que JBoss conseille depuis toujours de retirer de l'environnement de production.

Je pense aussi aux différents invokers. Le http-invoker ne sert généralement à rien, de même que le pooled-invoker. A moins qu'on remplace le jrmp-invoker par ce dernier, comme c'est conseillé. Dans tous les cas, ils sont 3 pour 1 place.

Dans foire-demonstration, on peut citer aussi le HAR deployer qui sert à déployer des composants Hibernate 2 (la majorité des projets fonctionnent aujourd'hui sur Hibernate 3), le système de scheduler (utile, mais rarement utilisé) ou la panoplie de modules JAAS cités en exemple dans les application-policy.

Je ne les citerai pas tous, cela est mieux fait et plus détaillé dans l'article Tuning and Slimming JBossAS du wiki de JBoss.

Conclusion

Cette configuration par défaut est une compilation entre les fonctionnalités utiles en développement et des fonctionnalités de démonstration. On attendrait plus de simplicité et de rigueur dans une configuration de production. L'installation JEMS offre des possibilités intéressantes puisque plus de profils d'utilisation sont proposés, et les outils d'administration sont sécurisés par des simples cases à cocher.

Pourquoi JBoss ne proposerait-il pas une configuration 'prod' en plus des 3 configurations déjà proposée dans ses packages zip ou tar.gz ?

La réponse est peut-être dans le modèle économique de JBoss : vendre du service. Si la configuration fournie en standard convient, les clients n'auront plus besoin ni d'accompagnement ni de formation. Finalement, je ne devrais peut-être pas me plaindre des choix qui sont faits...