Journée 1
Depuis hier j’ai commencé la formation JBoss for Advanced J2EE developers à Berlin, Allemagne. La formation se déroule sur 4 jours. Je vais profiter de ces 4 jours pour noter ici mes impressions et faire partager « de l’intérieur » ce que j’aurai appris.*
La formation en anglais est faite par Kabir Khan, qiu vient de Norvège, secondé par Thomas Heute, monsieur JBoss-WS en personne. Tous les deux sont des employés permanents de JBoss Inc. La formation se déroule en anglais, nous sommes 9 personnes. Il faut avoir un ordinateur portable assez puissant en prenant soin d’installer son IDE favori, un JDK, un editeur de texte qui tienne la route. Vous pouvez ajouter éventuellement Ant, Cygwin et la javadoc pour être à l’aise.
Première journée:
La formation commence par une présentation de JBoss Inc., la societé. Ensuite une « Architecture Overview » et enfin dans l’après-midi, un lab (un TP) sur le MicroKernel de JBoss. Ce lab consistera à écrire des MBeans et à les tester avec un adapteur RMI.
Kabir commence par expliquer l’histoire de JBoss, et sa place aujourd’hui sur le marché. Il aborde ensuite un argumentaire sur les avantages d’un développement Open-Source. Le principe du micro-kernel est expliqué, montrant le parrallèle entre J2EE et le micro-kernel de JBoss avec J2SE. Le micro-kernel, qui ne fait que 44kb, permet d’écrire des services. Ces services interagissent entre eux pour effectuer des fonctions métiers. Les invocations entre services ne sont pas directes. Tout est négocié par un médiateur (Pattern GOF) qui assure la résolution de nom. Ceci permet de redémarrer un des services sans devoir arrêter tout le serveur d’application. Tous les services de JBoss sont des JMX MBeans. JBoss utilise JMX en interne pour l’invocation mais aussi pour le monitoring et l’instrumentation.
Pour instancier des services, JBoss dispose de deployers. Il s’agit de class capable de reconnaître un pattern à un endroit spécifié (*.sar dans le répertoire deploy/nic) et de charger des class et des services.
Java 1.4 saît charger des class grâce au ClassLoader. Cependant il n’existe pas de fonction pour décharger une class. Il faut donc utiliser des ClassLoader pour faire la gestion du byte code. Pour cela, JBoss a un système complexe et assez génial (je trouve) de Repository. Dur d’expliquer ici comment cela fonctionne, mais c’est vraiment intéressant.
Pour ajouter des fonctions génériques aux services comme la Security, Transaction ou encore un Cache Jboss dispose d’un système de « Server Interceptor and Invokers« . Ceci permettent d’ajouter à une pile d’appel de manière transparente des fonctions. Les invokers sont les agents qui effectuent les appels de méthodes d’autres services. Si vous vous connectez via un navigateur, un Invoker adaptera votre appel (HTTP) en un appel JMX en interne. Il est possible d’utiliser pas mal d’invoker (RMI,IIOP,HTTP et HTTPS) par défaut. Les Invokers eux-même sont des MBeans (des services).
Ensuite nous avons parlé des Client proxies. Ce systeme permet depuis Java 1.3 grâce au système de l’InvocationHandler de recevoir côté client un proxy. Ainsi au lieu de devoir envoye et recevoir les appels de méthode avec JMX, vous pouvez télécharger un proxy local. En clair c’est une interface home (comme J2EE) et qui permet de valider le code et les méthodes à la compilation.
Après un bon repas, nous avons travaillé sur JMX (Java Managment Extension). JMX est une API qui permet d’administrer des composants à distance. On appelle ces composants des MBean‘s et JBoss utilise les MBeans comme implémentation de base de tout les services. D’autre part (JSR 160) depuis JMX v1.2, l’API définie aussi la partie de distribution entre le composant managé et les clients. Les protocoles supportés sont HTTP, RMI, SOAP, SNMP, JMS et d’autres…
JMX découple l’implémentation des services via un bus d’invocation. Il est donc possible de recharger un des composants MBeans de JBoss sans devoir l’arrêter. Côté client l’api est générique et il n’y a pas de prototypage fort. L’inconvénient est que les clients sont testés à l’execution et il n’y a pas de validation à la compilation. L’avantage est que l’application managé peut évoluer en interne, être redémarrer sans que les clients ne soient impactés (ce qui est différent de RMI). Il existe cependant un mécanisme propre à JBoss qui permet de recevoir un proxy local, avec cette fois-ci un typage à la compilation.
Le coeur de JBoss est le MBean Server. Les MBeans sont enregistrés dans ce serveur avec des ObjectName qui permettent aux différents MBeans (les services) de discuter entre eux. Ensuite nous avons eu une présentation des 3 types de MBeans. Les MBeans standard implémentent une interface dont le nom se termine par MBean. Les attributs et les opérations sont définis dans cette interface. Le MBean Server retrouve par introspection les méthodes disponibles sous la forme de service. L’avantage est qu’il est très simple d’écrire un MBean, l’inconvénient est que cette interface est figée, et qu’elle n’est pas très documenté car elle est générée à la volée. Pour écrire des composants plus souples, il est possible d’utiliser des Dynamic MBeans. L’interface de managment peut alors être déterminer à l’execution. L’inconvénient est qu’il faut écrire un MBeanInfo assez complexe. JBoss propose une 3ème solution: XMBean. Cela permet de définir dans un fichier XML de JBoss pour une class donnée les attributs et les méthodes. Grâce à ce système il est possible de rendre « JMX-compliant » une class existante sans réécrire du code. D’autre part, il devient possible en implémentant des interfaces de JBoss de rajouter des fonctions telles que la persistence ou des event listeners.
Ensuite on nous a présenté le MicroKernel de JBoss. Les services de JBoss sont packagés dans des fichier .SAR pour Service Application aRchive. En effaçant un fichier .sar du répertoire deploy de JBoss, le service est retiré. Evidemment ce qui est plus intéressant c’est de rajouter des services à la volée sans redémarrer JBoss. Ce que j’ai retenu et qui diffère de notre ComponentManager c’est que JBoss ne force pas un service à définir des méthodes pour la gestion du cycle de vie. Dans le cas où un MBean désire être notifié lorsqu’il démarre (pour créer des Threads) il est cependant possible d’implémenter l’interface Service de JBoss (create, start, stop et destroy).
D’autre part un MBean est démarré que lorsque les MBeans dont il a besoin sont aussi démarrés. A noter que si vous écrivez un MBean qui a besoin d’autres services de JBoss (JNDI, Transactions, Logging, Invokers…) alors il faut implémenter cette interface ou surcharger ServiceMBeanSupport.
La séquence de Boot de Jboss a ensuite été détaillée. JBoss utilise son propre système pour instancier et initialiser les services de base. Ce que j’ai surtout retenu c’est le Dependency Injection qui permet à un MBean TOTO qui utilise un MBean DBtiti, de recevoir l’instance de DBTiti lorsque celle-ci aura été instanciée. Il faut écrire un setDBTiti dans la class TOTO, et JBoss se charge de la gestion de l’instance. Oui cela remplacerait notre système de References que nous avons mis en place dans le ComponentManager. Mais là où c’est plus complexe, c’est que la class locale n’est pas une instance de DBTiti ni une class qui implémente une interface. C’est un dynamic proxy, soit une class construite à la volée côté client (dans TOTO) et qui se fait passer pour un DBTiti. Oui c’est du charabia mais ça vaut le coup de chercher sur Google pour comprendre.
Enfin le système de ClassLoading du Kernel a été présenté. JBoss a un système de Repository interne qui permet de gérer les ClassLoaders et les class chargées.
Après tout cela nous avons bossé encore 2 bonnes heures sur un TP pour nous apprendre à écrire un MBean simple et un XMLMBean, beaucoup plus sympa à écrire.
Fin de la 1ère journée
Lire la suite
*: Indicatif Futur Antérieur, vive le français… 😀
0 no like
