Journée 4

Vendredi 28 janvier 2005 j’ai un peu de mal à me lever. La veille nous sommes allés au restaurant avec Thomas, Kabir, Mladen et un allemand. Soirée très sympa et qui m’a permis d’en savoir un peu plus sur JBoss Europe, comment les équipes travaillent, qui fait quoi, etc. Les gars sont très sympas et nous avons passés un bon moment.

Nous commençons la matinée sous la tutuelle de Thomas Diesler. Il commence par Advanced EJB destiné à présenter les techniques d’optimisation pour les applications J2EE. Tout d’abord nous avons vu où se situent en général les points de ralentissement dans une application J2EE et ce, parce que les spécifications obligent à suivre certaines règles. La Serialization est l’ennemi numéro 1 du développeur J2EE. Sans que nous nous en rendions compte, au sein même d’un conteneur J2EE il est très facile de ralentir son application sans le savoir. Pour éviter les problèmes il ne faut pas simplement apprendre à écrire des EJB. Il faut aussi investir du temps et apprendre des Patterns tels que Session Facade, Value Object, Composite Entity ou Value Object ASsembler. Ainsi accéder un Entity Bean directement à partir de la couche client est une très mauvaise idée. Cela entraîne des appels à ejbLoad et ejbStore qui sont très lents ! Il vaut mieux utiliser un SessionStatefulBean pour accéder à un EntityBean et surtout utiliser les transactions pour effectuer plusieurs appels sur un entity bean. Un conteneur comme JBoss peut alors utiliser les transactions pour regrouper les appels en un seul appel. Cela accélere grandement l’application.

Nous avons ensuite vu aussi que les clusters n’accélerent pas forcément une application. Si les données doivent être répliquées entre les différentes nodes du cluster, il n’y a pas de gain de vitesse. C’est un gain de sécurité et de redondance. Beaucoup de personnes pensent qu’un cluster accélere le traitement, ce n’est pas le cas.

Les Transactions permettent de s’assurer de l’intégrité d’une opération. Cependant il faut prendre le temps de bien examiner son architecture et faire attention à la manière où le système de transaction est implémenté. Concernant l’accès aux données et la réplication: il existe plusieurs moyens de s’assurer que des données sont répliquées sans impacter les performances. JBoss dispose dún MBean pour invalider un cache. Avec Oracle il est possible d’executer du code Java qui invaliderait via JMX le cache du conteneur CMP de JBoss. Il est aussi possible dans un object comme un MDB ou une SessionStatefulBean d’invalider le cache manuellement en utilisant JMS. La node principal publie une Topic JMS et les autres nodes rechargent alors leur contenu en retournant sur la base de données. Dans notre application nous avons un système similaire utilisant TIBCO Rendezvous (LoadManager + PDSA) mais c’est assez compliqué et une partie
du travail est fait par la base de données…

Pour les Entity Beans JBoss permet au sein de la config de marquer certains attributs comme étant « read-only » ce qui accélere et optimise les appels. Un champ qui ne change jamais n’a pas besoin d’être rechargé de la base de données. Pour améliorer les performances, l’idéal est d’utiliser l’option A du cache de JBoss. Le cache est toujours vrai et la base de données n’est pas accedée. Ensuite, nous pouvons mettre en place un cache qui s’invalide toutes les n secondes (option D). Dans le cas d’une page Web qui affiche des news, un retard maximum de 5 mn entre ce que l’utilisateur voit et la base de données est parfois acceptable (stock de produits, fiche description d’un livre…). Il faut prendre en compte la granularité et la durée de vie d’une donnée dans le cache.

Dans le cas où l’on modifie une donnée, et que le cache type A ou D est utilisé, il est possible dans les SQL Statements d’effectuer quelque chose comme dans cet exemple:

	UPDATE TOTO SET A="Nic" WHERE PKey="C" AND A="OldValue"

Ainsi si jamais la valeur a été changée par quelqu’un d’autre, ce statement va signaler qu’aucune ligne n’a été modifiée. Il faut alors effectuer côté client un appel pour recharger la valeur et éventuellement avertir l’utilisateur. Ce système permet alors d’optimiser le cache en lecture et accélere grandement les EntityBeans.

Mladen Turk a fait ensuite une présentation sur le connecteur mod_jk qui permet de brancher Apache avec Tomcat. Il a expliqué tout d’abord comment établir une architecture réseau qui fonctionne en production avec un serveur web pour le contenu statique et Tomcat uniquement pour la partie dynamique. Tomcat est le conteneur de Servlets et de JSP qui assure la partie Vue dans le patterne modèle-vue-controller. Sa présentation part de son experience en tant que consultant où il est appelé souvent pour optimiser les performances d’un site internet. Comme il le dit lui-même, les clients esperent souvent que leur serveur sera capable de gérer des milliers de connexion à la seconde, et cependant ne prennent pas en compte tous les parametres. Le réseau lorsque l’on branche Apache et Tomcat ou Microsoft IIS et Tomcat est parfois négligé. Ainsi comme il l’explique, une carte réseau 100Mbits qui fait transiter des données codées sur 8 bits ne peut donc en théorie faire passer que 12.5 Moctets Mbps. Ensuite si vous prenez en compte le poids moyen de votre page internet, disons 20ko, vous ne pouvez faire passer que 625 clients différents à la seconde par ce même tuyau… L’article en ligne de Mladen est disponible sur le site Apache.org.

Après un bon repas, pour terminer la formation nous avons parlé de sécurité et de JMS.

JBoss Security Model avec JAAS. Ce que j’ai retenu: le modèle de sécurité de JBoss est surtout destiné à authentifier les utilisateurs et à ajouter un rôle à un utilisateur dans le conteneur. La partie authentification est externalisée grâce à JAAS. Il est possible d’utiliser LDAP, une base de données, des fichiers plats, Kerberos ou des certificats SSL. Cependant cette partie est effectuée par l’api JAAS et n’est pas intéressante pour JBoss. Ce que JBoss ajoute par rapport à un autre conteneur c’est la gestion de rôle. Elle permet en interne, quelque soit le composant, de retrouver qui est l’utilisateur actif pour pouvoir effectuer des traitements personnalisées. Evidemment elle permet aussi de mettre en place de la sécurité au niveau de chaque MBean et de chaque composant d’une application J2EE. La sécurité est configurée dans les fichiers de JBoss. Les Server Interceptors permettent de gérer la sécurité par composant sans surcharger le code.

J’ai surtout retenu la facilité de mise en place et le fait que le développeur peut écrire son application et s’en soucier à la fin, une fois son système mis en production.

Enfin nous avons terminé par JBossMQ et JMS. Après une présentation rapide de JMS, la différence entre une Queue et un Topic, nous avons eu une présentation détaillée de l’architecture de JBossMQ. L’avantage numéro 1 de JMS est l’échange de message asynchrone entre 2 applications. D’autre part, comme il s’agit d’échanger des données, l’implémentation ou le traitement de ces données peut changer côté client ou côté serveur sans que cela n’impacte l’un ou l’autre. Il faut s’accorder sur le contenu et le contenant mais le traitement est particulier à chaque client. C’est le paradigm Document-based opposé au modèle Remote Procedure Call (RPC) inventé par SUN.

Nous avons vu l’architecture interne du serveur et les dispositifs pour tout ce qui a trait au clustering et fail-over. Grâce à JBoss et aux transactions, il est facile de s’assurer qu’un message a été délivré. Du côté implémentation, si les messages sont envoyés sur des Queues ou des Topics persistents alors JBoss est capable de sauver sur le disque des messages lorsque la Queue est pleine. Dans le cas où des messages importants sont marqués avec livraison garantie, les mesages sont enregistrés sur un systeme de persistence avant d’être envoyé. Enfin JBoss dispose d’un système appelé DeadLetterQueue pour enregistrer les messages qui n’ont pas été délivré correctement. Encore une fois, pour notre logiciel, cela correspond au Retransmission Agent et il y aurait certainement quelque chose à faire avec JMS… Mais c’est une autre histoire 😉

Conclusion

Pour conclure sur cette formation: elle est effectuée par des développeurs de JBoss. Elle est très technique et je pense qu’elle conviendra à des développeurs, des consultants J2EE ou des architectes. Une bonne connaissance de J2EE permet de comprendre la partie sur le conteneur CMP 2.0. A l’issue de la formation je pense avoir un bon aperçu de l’architecture de JBoss AS. Il ne s’agit pas uniquement d’un serveur J2EE. C’est aussi un micro-kernel puissant basé sur JMX qui permet aux développeurs d’écrire du code qui se concentre sur la fonction métier sans perdre du temps à réécrire tout un assemblage de code.
La qualité de la formation est bonne. L’organisation et les moyens sont très bons. Les formateurs étant des développeurs, ils sont vraiment au fait et capable de répondre aux questions posées.
Alors y-a-t-il des points négatifs ?
… je n’ai même pas eu le temps de visiter Berlin !

Fin de la journée 4

Liste des articles apparentés si vous n’avez pas lu les anciens billets

4 réflexions sur « Jour 4 Formation JBoss for Advanced J2EE developers in Berlin »

Les commentaires sont fermés.