Journée 3
La journée commence par la présentation de JBossCache. JBossCache est un système virtuel en mémoire destiné à stocker soit des objets simples soit des objets complexes comme des class. Ce qui est amusant c’est que JBossCache me rappelle le PropertySpace inventé par Guillaume Pelletier mais avec une architecture et des fonctions beaucoup plus complexe. JBossCache est disponible soit comme une API à intégrer dans votre code, soit comme un MBean au sein de JBoss.
Il existe 2 implémentations: TreeCache et TreeCacheAOP. TreeCache permet de stocker et répliquer vers un autre cache des valeurs. Chaque objet est référencé par un path (/toto/titi/object) sous la forme d’un arbre en mémoire. Imaginez votre disque c:\ avec la structure de répertoire et de fichiers, vous y êtes. L’autre implémentation est TreeCacheAOP. Cette implémentation permet de gérer la réplication sur des objets Java complets. Grâce à AOP il est possible de savoir que seul le champ « Address » de la class « Customer » a été modifié et donc de ne répliquer que cette modification. C’est tout simple et très performant.
JBossCache utilise JavaGroups pour fonctionner en cluster. Il est possible d’effectuer des réplications synchrones ou asynchrones. Les Transactions permettent d’assurer la contrainte d’intégrité. JBossCache enfin permet de mettre en place plusieurs polices d’évictions pour nettoyer la mémoire et effacer les objets trop vieux. Enfin il existe un cache qui permet de cacher les accès dans le cas où JBossCache utilise une base de données pour persister son contenu. Bref c’est assez complexe et puissant.
L’implémentation TreeCacheAOP est la plus intéressante. Des interceptors permettent de voir les modifications effectuées sur les champs d’un objet et donc, d’optimiser soit l’accès à la couche de persistence (la base de données) soit la propagation au sein d’un cluster des modifications. Efficace et très rapide car seul ce qui a changé est envoyé aux nodes.
JBossCache permet donc d’avoir en mémoire des données, en les classant comme dans un système de fichier. Grâce à JGroups il est possible de répliquer le contenu du cache vers une autre instance de JBossCache. Il est aussi possible d’enregistrer dans une base de données le contenu pour pouvoir le conserver.
Après JBossCache, nous avons vu JBoss Clustering and Caching. Comment assurez les fonctions de load-balancing pour la charge et de fail-over pour la sécurité des données avec JBoss ? Présentation de JBoss HA-JNDI (High Availability), de la notion de farming, de la réplication de session HTTP, de HA-JMS, du fonctionnement du côté client du clustering… Bref c’était très chargé comme présentation.
Une fois encore grâce au système de Client Proxy les fonctions de fail-over et clustering sont invisibles pour le client. Il faut simplement utiliser les class JBoss client pour bénéficier de ce support, mais il n’y a aucunes modifications côté client sur le code.
Nous avons terminé la journée par la présentation du conteneur CMP 2.0 et donc les modifications sur le code lorsque l’on écrit des EJB. J’avoue que c’était le moins intéressant. Tout d’abord tout ce qui nous a été expliqué sera remis en cause lorsque EJB 3.0 sortira. Mais c’était intéressant de voir comment écrire un Entity Bean et le gérer avec JBoss. JBoss est capable de mettre en place des relations entre Entity Bean et dispose d’un système qui permet de définir en XML dans la config la structure d’un entity. Le conteneur se chargera de charger les données venant de la base, en suivant des règles d’optimisatin que nous pouvons définir.
Nous avons terminé par des labs sur le clustering et sur CMP avec pour exemple non pas le PetStore habituel mais la gestion d’une bande de Gangster rattaché à un Boss et disposant de différentes Capacity… Ca change.
Fin de la journée 3
