1 / 56

JMX ou Java Management Extensions

JMX ou Java Management Extensions. El Ayeb Ines & Mansour Jihene GL5-2005/2006. 1. Plan. Qu’est ce que JMX? Architecture JMX Instrumentation Les Mbeans Types MBean standard MBean dynamique Agents MBeanServer Connecteurs Adaptateur Services distribués

halle
Download Presentation

JMX ou Java Management Extensions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. JMX ou Java Management Extensions El Ayeb Ines & Mansour Jihene GL5-2005/2006 1 1

  2. Plan • Qu’est ce que JMX? • Architecture JMX • Instrumentation • Les Mbeans • Types • MBean standard • MBean dynamique • Agents • MBeanServer • Connecteurs • Adaptateur • Services distribués • Conclusion 1 2

  3. Qu’est ce que JMX? 1 3

  4. JMX: Vue d’ensemble • JMX est une couche intermédiaire entre les applications de management et les ressources gérées. • Elle assure • La transparence et l’interopérabilité entre la couche supérieure: managed application et la couche de base Managed System. • La dynamique Les ressources gérées et les fonctionnalités de management peuvent être ajoutées ou supprimées à tout moment. 1 4

  5. JMX? • JMX (Java Management Extensions) est une spécification de Sun fournie à travers le JCP (Java Community Process) qui permet d’administrer à distance des applications Java, mais également des équipements d’administration de réseau (firewall, routeur,...). • JMX définie l’architecture, les « Design Patern » , les API et les services pour les applications, l’administration et le contrôle des réseaux dans Java. 1 5

  6. Chaque console de gestion est vendor-specific • Normalement, pouvant être accessible via un navigateur web • Mais chacune a sa propre terminologie, GUI, etc. • Chacune a sa propre façon de gérer sa sécurité. • Redondant et difficile à contrôler. Avant JMX 1 6

  7. Avec JMX • Chaque ressource est administrée par l’intermédiaire d’un MBean. • Tous les Mbeans enregistrés dans un AgentJMX (ou groupe d’agents) peuvent être administrés en utilisant une seule console de management. 1 7

  8. Architecture JMX 1 8

  9. Architecture JMX • JMX est conçue autour d'une architecture à trois niveaux. Cette conception favorise une structure de développement optimisée en permettant à différentes branches de la communauté de développeurs de se focaliser sur le niveau qui correspond le mieux à leur domaine de compétences. 1 9

  10. Architecture JMX Agent Instrumentation 1 10

  11. Architecture JMX  Niveau instrumentation 1 11

  12. Niveau Instrumentation 1 12

  13. Niveau Instrumentation • Ce niveau concerne la communauté des développeurs Java en définissant un mécanisme permettant d'instrumenter les ressources, connues sous le nom de beans gérés ou MBeans (Managed Beans) . • Une ressource (classe, application patrimoniale, méthode, etc.) doit être développée en Java, ou, doit offrir une enveloppe Java. Elle doit être instrumentée sous forme d'un ou de plusieurs MBeans. Concrètement, un MBean est un objet Java qui suit une certaine sémantique. Il expose les informations de gestion sous forme d'attributs et d'opérations pour les manipuler. 1 13

  14. Les Managed Beans • Ce sont des objets Java déposés dans le cœur d’un serveur MBean et qui peuvent s’exécuter dans la plupart des dispositifs Java. • Ils représentent la brique de base et constituent en fait des interfaces de communication avec les éléments physiques (qu’ils soient locaux ou distants) ou les programmes administrables à travers JMX. Ces divers éléments sont appelés ici les ressources administrables. 1 14

  15. Composition d’un MBean • Chaque MBean peut avoir: • Zéro ou plusieurs Attributs • Read-only, write-only, or read/write • Zéro ou plusieurs Opérations • Zéro ou plusieursNotifications générées • Similaire aux événements Java • Un ou plusieurs Public Constructors  Leur Collection constitue les caractéristiques du MBean: « the MBean's features ». 1 15

  16. Types de MBeans les MBeans ouverts étendent les MBeans dynamiques pour afficher leurs attributs et opérations à l'aide de métadonnées constituées d'un ensemble prédéfini de types Java standard. les MBeans modèles étendent les MBeans dynamiques et font office de proxy pour les objets réels à gérer. Les objets gérés sont encapsulés par les MBeans modèles lors de l'exécution, lesquels délèguent ensuite tous les appels d'opérations et d'attributs aux objets gérés . les MBeans dynamiques exposent de manière dynamique les opérations et attributs administrables en appliquant des méthodes de découverte lors de l'exécution. les MBeans standard exposent leurs opérations et attributs administrables en implémentant une interface Java contenant des méthodes qui respectent les modèles de nommage JavaBeans standard pour les méthodes de réglage (setter) et d'obtention (getter). MBean (abstract notion) Dynamic MBean Standard MBean Open MBean Model MBean 1 16

  17. MBean Standard  Définition • Un MBean standard est une classe concrète Java . • Les MBeans standards constituent la plus simple forme d'instrumentation. • Ils sont les plus appropriés à la gestion des informations statiques. • Un ensemble de conventions lexicales doit être respecté lors de la mise en oeuvre des Mbeans: • Un MBean standard doit implémenter une interface nommée XMBean • "X" est le nom de la classe • X et l’interface XMBean doivent être déclarés public • Les deux doivent être définis dans le même paquetage 1 17

  18. MBean Standard  Caractéristiques • La plupart de ces caractéristiques sont obtenues en utilisant la réflexion • Similaire à des JavaBeans sans les classes BeanInfo • Le serveur utilise la réflexion dans l’interface XMBean • A l’exception des constructeurs • Donc seules les méthodes définies dans l’interface sont considérées comme des caractéristiques de MBean. • Toute autre méthode présente dans X est ignorée, même si elle est déclarée publique • public type getA() définit le readable attributeA • public void setA(type) définit le writable attributeA • Toutes les autres méthodes publiques sont des opérations. • LesConstructeurs sont ceux définis dans la classe bean. • (Les notifications seront traitées plus tard.) 1 18

  19. MBean Standard  Caractéristiques public interface SimpleStandardMBean { public String getState(); public void setState (String s); public void reset(); } public class SimpleStandard implements SimpleStandardMBean { private String state; public SimpleStandard() {….} public String getState() { return state;} public void setState(String s) {….} public void reset() {….} public String getNbChanges() { ... } } Un constructeur déclaré public Un attribut R/W appelé State Une opération Ni un attribut ni une opération 1 19

  20. MBean Standard  Concept d’héritage • Patterns d’héritage: • L’héritage Java est mis en œuvre en utilisant le mot clé « extends » • JMX a respecté ce concept à quelques différences près. • Beaucoup de scénarii d’héritage existent et sont présentés sous forme de cinq patterns. • Exemple explicatif public class Basic implements BasicMBean { // implementation of BasicMBean and other stuff. . . }  La classe Basic implémente l’interface BasicMBean. public interface WorkerMBean extends BasicMBean { // . . . }  L’interface de managent du Worker est l’union de BasicMBean et WorkerMBean. public class Worker extends Basic { // implementation of Worker here. . . }  Dans ce pattern, l’interface de management du worker est BasicMBean public class Worker extends Basic implements WorkerMBean { // implementation of WorkerMBean. . . }  Il est clair que le compilateur ne permettra pas au Worker d’hériter une interface sans l’implémenter. 1 20

  21. MBean Notifications • Un standard MBean peut être une cible de notifications • Doit implémenter l’interface NotificationBroadcaster • (Toutes les classes sont importées du paquetage javax.management) • Utilise le pattern publish/subscribe • Les méthodes de cette interface sont: • addNotificationListener(listener, filter, handback) • La classe Filter est utilisée pour filtrer les événements non désirables pour chaque listener. • L’objet handback est passé au listener avec chaque événement. • Alors s’il écoute plusieurs MBeans, il peut identifier la source. • Les deux peuvent être nuls • removeNotificationListener(listener) • getNotificationInfo() 1 21

  22. MBean Notifications (cont.) • getNotificationInfo retourne un tableau d’objets MBeanNotificationInfo • Chaque tel objet contient de l’information à propos d’un des types de notification que le MBean peut générer. • L’information inclue le type et une description • Si la classe n’a pas de super classe, elle peut simplement hériter de la classe NotificationBroadcasterSupport • Fournie une implémentation simple de l’interface NotificationBroadcaster. • Inclue une méthode de service, sendNotification • La méthode getNotificationInfo doit être réécrite. 1 22

  23. MBean Notifications (cont.) • Pour générer une notification, le MBean doit envoyer un Notification object pour tous les listeners enregistrés. • Ensuite examiner, pour chaque listener, si son filter veut accepter ce type de notification. • L’information enregistrée dans chaque notification inclue: • Type (a String; not a Java type), utilisé pour le filtrage • SequenceNumber (an integer; option utilisée pour dénombrer les notifications dans une séquence) • TimeStamp (long) • UserData (an object ref) et Message (a String) • Source (identifier les MBean générés) 1 23

  24. Notification Listeners • Pour accepter les MBean notifications, une classe doit implémenter NotificationListener • Une methode: handleNotification(notification, handback) • L’envoi de notifications est synchrone • Sinon si on veut envoyer une notification asynchrone, nous devons implémenter notre propre méthode sendNotification. 1 24

  25. Démo 1 25

  26. 2 Cas où on ne peut utiliser des Mbeans Standards • Les attributs et méthodes offertes à l’interface de gestion sont en fonction du superviseur qui les a créés (une notion de droit d’accès). Dans ce cas, l’objet crée ,à l’instanciation, l’interface en fonction d’un contexte externe. • L’objet ne peut construire son interface qu’à la vue des informations disponibles sur la ressource qu’il modélise. 1 26

  27. Les Mbeans Dynamiques • La dénomination dynamique pour ces Mbeans vient du fait que l’interface de supervision de ces objets n’est pas figée à la compilation mais est définie par les objets gérés eux-mêmes à l’exécution. • Alors que dans le MBean standard, le conteneur d’objets gérés se charge de découvrir par introspection les attributs et méthodes de l’objet, il va demander à l’objet géré dynamique de réaliser ce travail de création des méta données (description de l’interface exposée à la supervision) à sa place et de lui fournir cette interface de supervision à la demande. 1 27

  28. Les Mbeans Dynamiques • Tout comme les Mbeans standards, les Mbeans dynamiques possèdent des attributs, des opérations, des constructeurs déclarés public et des notifications. • Un MBean dynamique programme son interface de gestion, au lieu de l’appeler par des noms de méthodes statiques. • Pour ce faire, on compte sur des « descriptor classes » qui représentent les attributs et les opérations exposées au management. 1 28

  29. L’interface « Dynamic MBean » • Les Mbeans standard exposent leurs attributs et opérations statiquement dans l’interface de supervision. Les Mbeans dynamiques, par contre, partagent tous une même interface qui définie des méthodes génériques pour permettre l’accès aux attributs et aux méthodes. • Puisque l’interface de management n’est plus visible à travers l’introspection, les Mbeans dynamiques doivent alors fournir des descripteurs explicites de leurs attributs et opérations. 1 29

  30. The « Dynamic MBean » interface Les getters et les setters d’attributs sont génériques, du moment qu’ils prennent le nom de l’attribut qui a besoin d’être lu ou écrit. Ces méthodes utilisent les classes Attribute et AttributeList pour représenter les paires nom/valeur et les paires liste de noms/valeur respectivement. • La classe « DynamicMBean » est une interface java définie par JMX. Elle specifie les methodes qu’une ressource doit fournir pour exposer son interface de management. • Ce qui suit est un listing du code: Permet d’exécuter la méthode dont le nom est passé en paramètre avec les paramètres correspondants. La méthode getMBeanInfo fournie une description de l’interface de management du MBean. Elle retourne un objet MBeanInfo qui est le type qui contient les informations concernant les attributs et les opérations. 1 30

  31. The MBean Descriptor Classes • Un MBean dynamique a la charge de construire sa propre interface de management. • Les Mbeans dynamiques fournissent leur propre description retournée par la méthode getMBeanInfo. Les agents utilisent aussi ces classes pour les Mbeans standards après leur introspection. • Ces classes fournissent des informations concernant le MBean. Cette information contient non seulement les attributs et les opérations de l’interface de management mais aussi la liste des constructeurs de la classe MBean et les notifications que le MBean peut envoyer. • Un petit secret d' implémentation: lors de la manipulation des Mbeans standards,Le serveur utilise tout simplement la réflexion pour créer un objet MBeanInfo pour le MBean • Avec les Mbeans dynamiques, l’objet MBeanInfo est directement fourni. 1 31

  32. The MBean Descriptor Classes • Chaque élément est décrit par son « descriptor object » contenant son nom, une description, et ces caractéristiques. • Le tableau suivant liste toutes les classes «  MBean descriptor » 1 32

  33. Mbean modèle • Un MBean modèle est un MBean dynamique qui offre plus de flexibilité de développement. • La différence principale est que le développement de la classe d'implémentation du MBean modèle est plus simple. • Une classe nommée RequiredModelMBean, implémentant l'interface ModelMBean, qui caractérise un MBean modèle, est fournie par défaut. • Cette classe peut être étendue, et ses méthodes peuvent être surchargées, en cas de besoin, pour obtenir la classe d'implémentation du MBean modèle. • Il est également possible de créer un objet de type ModelMBeanInfo et de l'affecter à une instance de la classe par défaut. • Une alternative à la création de cet objet serait de fournir un fichier XML qui décrit les propriétés du MBean. 1 33

  34. Open MBeans • Un MBean ouvert est lui aussi un MBean dynamique. Il est par contre restreint d'accepter et de retourner un nombre limité de types de données. L'utilisation d'un nombre restreint de types, permet d'éliminer le besoin de chargement de classes. • Les types autorisés, lors du développement d'un MBean ouvert, sont : • les types primitifs (int, boolean, float, etc.), • les classes qui enveloppent les types primitifs : (Integer, Boolean, Float, etc.) • les tableaux des types précédents. • Un MBean ouvert doit implémenter la méthode getMBeanInfo(), qui retourne un objet de type OpenMBeanInfo (sous-type de MbeanInfo). Cet objet fournit des méta-données supplémentaires, décrivant le MBean ouvert. 1 34

  35. Architecture JMX  Niveau Agent 1 35

  36. Architecture  Niveau Agent 1 36

  37. Architecture  Niveau Agent • Ce niveau cible la communauté des applications de management en définissant un mécanisme permettant de créer des agents d’administration. • Ces derniers stockent, contrôlent et exposent des composants MBeans aux clients via un registre, appelé serveur Mbean . • Un agent est un composant logiciel qui négocie les requêtes et les réponses entre les composants MBeans et les clients MBean. Il est constitué d'une logique applicative spécifique, d'un serveur MBean, d'un groupe de services agents et d'au moins un connecteur ou adaptateur de protocole. 1 37

  38. Les agents JMX • Les clients MBean interagissent avec les MBeans via un agent et peuvent obtenir ou régler des valeurs d'attributs sur les MBeans ou appeler des opérations sur les MBeans. • Les clients MBean peuvent également interagir avec un agent pour recevoir des notifications transmises par un MBean. • Un serveur MBean est un composant logiciel qui agit comme un registre pour les MBeans et fournit des services aux clients MBean afin qu'ils puissent manipuler les MBeans. Toute interaction avec un MBean doit être effectuée via les interfaces du serveur. 1 38

  39. Agent  MBeanServer • Un serveur de MBeans est une base qui contient et gère un ensemble de MBeans. C'est le coeur du niveau agent. Toutes les opérations de gestion exécutées sur les MBeans sont faites à travers le serveur, dans lequel ils sont enregistrés. Le serveur est aussi responsable, à la réception d'une requête de la station d'administration, de rechercher le MBean concerné, et de lui transférer la requête. • La gestion au niveau du serveur de MBeans concerne, par exemple, l'instanciation des MBeans, l'enregistrement et le dés-enregistrement des instances créées. • Un mécanisme de notification est supporté pour envoyer des notifications, après l'enregistrement et le dés-enregistrement des instances de MBeans. 1 39

  40. Agent  MBeanServer • La destruction du MBeanServer provoquera la perte de tous les MBeans (cela sera produit, bien sur, après la mort du processus JVM). • Alors pour cette raison parmi d’autres, il est possible d’encapsuler les contrôles de l’instance du MBeanServer dans un Agent. • Afin de permettre aux applications de supervision d’accéder aux MBean , l’architecture JMX propose deux types d’accès à distance : les connecteurs et les adaptateurs de protocoles. 1 40

  41. MBeanServerMBean Names • Chaque instance MBean possède un nom représenté par la classe " ObjectName" qui est fournie par la " Reference Implementation " et qui est cruciale pour le processus d’enregistrement des MBean. • Dont le format est: domain-name:key1=value1[,key2=value2,...,keyN=valueN] • "domainName" est utilisé pour regrouper logiquement les Mbeans • Exemples: • Tools:name=Printer3 • Tools:name=ProxyServer,port=8080 • Chaque MBean instance name doit être unique au sein du serveur. 1 41

  42. MBeanServer Enregistrement d’un MBean L’agent doit ensuite définir l’ objectName pour l’instance de MBean qui va servir à le créer. Dans ce object name, le domaine est com.example.mbeans (le paquetage dans lequel les Mbeans seront contenus)et la key-property déclare que l’objet est de type Hello. L’agent JMX commence par chercher une référence à un serveur Mbean s’exécutant sur la plateforme en appelant la méthode getPlatformMBeanServer() importée de la classe java.lang.management.ManagementFactory. Si un serveur n’est pas déjà en cours d’exécution, cette méthode crée automatiquement un nouveau serveur en faisant appel à la méthode MBeanServerFactory.createMBeanServer(). L’objet Hello nomme “mbean” est enregistré ensuite dans le serveur “mbs” avec object name “name”, en passant l’objet et l’ object name dans l’appel de la méthode JMX MBeanServer.registerMBean(). 1 42

  43. MBeanServerFinding MBeans • Trouver un MBean est facile si on connaît son nom • Mais si on a besoin “ Tous les Mbeans d’un type donné"? • Ou peut être “ Tous les MBeans avec un attribut appelé 'count' >=10"? • On aura recourt à un langage de requête pour les Mbeans • "MBeans QL"? • Les requêtes sont construites en utilisant les objets QueryExp • Chaque QueryExp représente un prédicat booléen relié aux attributs du MBean • QueryExps peuvent être combinés en utilisant des opérateurs logiques. 1 43

  44. MBeanServerConstruction et exécution des MBean Queries • Les méthodes Boolean operator incluses dans la classe Query : gt (greater than), lt (less than), eq (=), geq (≥), leq (≤), match (wildcard matching), initialSubString, anySubString, finalSubString, between • Les méthodes Query peuvant être utilisées pour construire des valeurs: plus, minus, div, times, value (utilisé pour générer des constantes; surcharge pour tous les types de primitives) • Les méthodes Query peuvant être utilisées pour combiner des élements QueryExp : and, or, not • Apres la construction d’une requête, l’exécution de cette dernière dans le serveur MBean est realisée par: mbs.queryMBeans(objName, query); 1 44

  45. Agent  Les connecteurs • Les connecteurs permettent à un client de faire des appels de méthodes à distance sur un MBeanServer d’un agent. • Typiquement un connecteur peut être bâti au dessus de RMI (Remote Method Invocation) de Java. • Une implémentation particulière d’un connecteur impacte aussi bien le côté agent que le côté client/manageur. • Les connecteurs exposent la même interface à un client, autorisant ainsi l'accès transparent à un agent par des outils de gestion, quel que soit le protocole sous-jacent. • Exemples: - RMI and RMI/IIOP connectors - JMX Messaging Protocol( JMXMP) connector - SOAP/HTTP, XML/RPC, JMS … 1 45

  46. Agent  Les adaptateurs • Les adaptateurs de protocoles sont des composants qui assurent la liaison entre des protocoles spécifiques (par exemple SNMP ou http) et les services locaux d’un serveur MBean. • Ces derniers permettent à des agents JMX et les Mbeans qu’ils contiennent d’être accessibles au travers d’approches existantes. • Aussi, les adaptateurs offrent à l’architecture une capacité d’évolution et d’intégration des approches futures de supervision. Un adaptateur est un composant lié uniquement au côté agent. • Exemples: - SMTP adapter - Web (HTML/HTTP)adapter - Local GUI -CORBA Adapter, AMI Adapter for Tibco… 1 46

  47. Agent  Services • Un serveur de MBeans fournit un ensemble de services, implémentés sous forme de MBeans. • Parmi les services fournis, nous pouvons citer : • Le service Timer : envoie des notifications à des moments spécifiques, d'une manière simple ou répétitive, à des intervalles réguliers. • Le service Monitor : permet d'observer des attributs d'un type Java, et d'envoyer des événements lorsque des conditions spécifiques sont vérifiées. • Le service M-Let : permet de télécharger, d'instancier et d'enregistrer des MBeans distants, en utilisant l'URL où ils se trouvent. 1 47

  48. Architecture JMX  Niveau Services Distribués 1 48

  49. Architecture  Services distribués 1 49

  50. Architecture  Services distribués • Ce niveau vise la communauté des applications de gestion en définissant un mécanisme permettant de localiser et d'accéder à des agents et à des composants Mbeans, quel que soit leur emplacement physique. Ce niveau s'occupe des services de recherche, des protocoles de connexion, des échanges de messages, etc.; 1 50

More Related