JMX en tant que bus interne de JBossAu sein de Jboss, la mise en place de JMX se fait naturellement, puisque cette spécification est utilisée en tant que bus de communication entre les différents composants de l’application. Cette utilisation se retrouve aussi bien au lancement qu’en cours d’exécution. Au démarrage de Jboss, le seul composant qui soit directement lancé contient le MbeanServer de l’architecture JMX de Jboss, et permet ainsi de voir n’importe quelle instance de Jboss comme un agent JMX, disposant de la console d’administration HTML de manière standard. Cet agent JMX contient également une classe qui va lancer l’ensemble des services déclarés dans le fichier de configuration jboss-services.xml.
Si on édite ce fichier, on constate par ailleurs que, de manière évidente, chacun des services de Jboss (persistance, transaction, sécurité, interaction avec .net, ...) est vu comme un Mbean. Par ailleurs, cette instanciation en tant qu’agent fournit également la capacité à s’interconnecter via n’importe quel connecteur de protocole JMX. Ce qui étend d’autant les capacités d’interopérabilité de Jboss au niveau du système. On peut ainsi envisager très facilement la remontée d’informations d’un serveur Jboss via le protocole SNMP. Les différents services de Jboss sont effectivement des Mbeans, ce qui donne une grande flexibilité, et une grande adaptabilité, à la plateforme Jboss. Il est par exemple possible, en cours d’exécution de Jboss, de modifier par le biais de la console d’administration JMX, les paramètres de fonctionnement d’un service. On peut ainsi ajouter des utilisateurs authentifiés au service de sécurité durant le fonctionnement de Jboss. Mais il est également possible d’arrêter ou de redémarrer un service, même critique, sans pour autant arrêter le serveur. C’est un autre avantage majeur de la structuration de Jboss en tant qu’agent JMX intégrant des Mbeans. Puisque chaque service est un Mbean, il est indépendant non seulement fonctionnellement, mais également dans le code, des autres services de l’application. Par exemple, si un service de persistance souhaite écrire des données dans une base de données, il va devoir vérifier, auprès du service de sécurité, que l’utilisateur de l’EJB dispose des droits d’écriture dans ce service. L’appel de méthode Java consiste à demander un service de sécurité, puis à vérifier auprès de ce service si l’utilisateur dispose de ces droits. Dans ce cas, le service de persistance connaît l’implémentation du service de sécurité. Grâce à JMX, on peut se contenter de vérifier, auprès du Mbean sécurité, que l’utilisateur appelant dispose bien du droit write. Il n’y a aucun souci d’implémentation, ni même de respect d’une interface. Le Mbean sécurité doit simplement fournir la bonne propriété, ce qui est nettement plus simple, mais également beaucoup plus flexible. En effet, dans le cas d’une implémentation spécifique de ce service de sécurité, il n’y a pas à correspondre à une interface spécifique, qui fige d’une certaine manière le développement, mais simplement à exposer les bonnes propriétés, ce qui est on ne peut plus simple dans le cas des beans dynamiques, qui peuvent créer ou détruire des propriétés à volonté, voire même exposer des propriétés temporaires. Fournir les services de Jboss sous forme de Mbeans est donc la garantie d’une grande facilité d’utilisation, mais aussi d’une grande facilité de mise à jour, la seule partie réellement fondamentale étant le code de l’agent. Par ailleurs, l’isolation des fonctionnalités est également présente dans le chargement des services. Lorsqu’un service, dans sa configuration, se déclare dépendant d’un autre, cela signifie qu’il ne peut pas être utilisable sans le service dont il dépend. La force de Jboss dans ce cas est de permettre, grâce aux Mbeans, de charger cette dépendance sur la machine locale ou une machine distante, et d’assurer un accès homogène entre services du système Jboss même dans le cadre d’une utilisation distribuée type cluster... Auteur : Nicolas Delsaux
|
||
