Classes et mappage dans CLI et WMI
Le concept des définitions de classe se trouve au cœur de la programmation en code managé. L'instrumentation WMI, elle aussi, repose sur le principe fondamental des définitions de classe ; toutefois, WMI possède sa propre grammaire pour décrire les classes (MOF), ainsi qu'une API permettant de définir des classes par programme.
Le principal but de l'instrumentation est de faire remonter en surface les informations susceptibles de s'avérer utiles pour les outils qui essaient de gérer une application. D'autres technologies d'instrumentation, telles que le traçage ou les fichiers journaux, se limitent à demander aux applications un bloc brut d'informations de diagnostic non structurées (par exemple une simple chaîne). L'instrumentation avec WMI permet de faire remonter en surface des informations très riches, basées sur un schéma. Pour ce faire, les applications définissent un ensemble de classes WMI qui décrivent les informations qu'elles fourniront à travers l'instrumentation. Ces définitions de classe sont publiées à travers WMI et sont accessibles aux outils de gestion. Les définitions de classe doivent être disponibles à tout instant après l'installation de l'application, et non seulement pendant que l'application s'exécute. Au moment de l'exécution, l'application fournit les données réelles décrites par les classes WMI.
Le modèle WMI de définitions de classe qu'il est possible de découvrir à tout instant est analogue au modèle CLI de classes managées et de métadonnées. L'espace de noms System.Management.Instrumentation tire parti des ressemblances entre les classes WMI et les classes CLI pour permettre aux développeurs de définir des classes WMI en écrivant des définitions de classe en code managé. En d'autres termes, un développeur de code managé possède déjà toutes les connaissances nécessaires pour définir des classes WMI.
En général, les classes de code managé correspondent à des classes WMI. Dans certains cas, toutefois, les classes WMI présentent des caractéristiques impossibles à décrire dans des classes managées. Par exemple, les types valeur Primitive de WMI peuvent être null, contrairement aux types valeur CTS (Common Type System). L'espace de noms System.Management.Instrumentation n'essaie pas de permettre aux développeurs de décrire des classes WMI représentant des entités indescriptibles dans le système CTS.
La liste suivante décrit les principales correspondances entre classes managées et classes WMI :
Seules les classes managées publiques peuvent être mappées sur des classes WMI, et seuls les membres publics peuvent être mappés sur la définition de classe WMI.
Les types valeur Primitive correspondent très précisément à des types CIM de WMI.
De plus, les types référence String, DateTime et TimeSpan correspondent aux types CIM équivalents de WMI.
Les tableaux en code managé correspondent à des tableaux dans les définitions de classe WMI.
L'interface CLI établit une distinction entre les types valeur et les types référence.
Comme WMI ne connaît pas cette distinction, ces deux types peuvent être mappés sur une définition de classe WMI.
WMI prend en charge les objets incorporés ainsi que les références à d'autres objets.
Dans la première version de System.Management.Instrumentation, seuls les objets incorporés sont pris en charge. Les classes managées qui contiennent des membres de types valeur sont, logiquement, mappées sur des classes WMI qui contiennent un objet incorporé. Les classes managées qui contiennent des membres de types référence sont elles aussi mappées sur des classes WMI contenant des objets incorporés, mais il est possible que les futures versions autorisent le développeur à spécifier les références runtime qui doivent être représentées par des références WMI.
Les hiérarchies d'héritage des classes managées sont représentées par des hiérarchies d'héritage dans WMI.
Dans la première version de System.Management.Instrumentation, les valeurs par défaut WMI ne peuvent pas être représentées en code managé.
Les initialiseurs de champ sur les champs de classe managée ne sont pas mappés sur des valeurs par défaut WMI.
WMI ne fait pas de distinction entre les champs et les propriétés.
Dans une définition de classe managée, les champs et les propriétés sont mappés sur des propriétés WMI.
L'espace de noms d'une définition de classe managée n'a aucun rapport avec l'espace de noms de la définition de classe WMI.
En d'autres termes, vous pouvez définir une classe managée dans l'espace de noms MaSociété.MonApplication et la classe d'instrumentation WMI correspondante comme espace de noms WMI root\MaSociété.
WMI prend en charge un concept voisin des attributs, les qualificateurs.
Dans System.Management.Instrumentation, il n'y a pas de mappage entre les attributs de code managé et les qualificateurs WMI. Il existe bien des attributs dans l'espace de noms System.Management.Instrumentation, mais ils ne sont pas représentés par des qualificateurs sur la définition de classe WMI. Pour mettre ces deux concepts en correspondance, l'espace de noms System.Management.Instrumentation propose plusieurs classes d'attribut permettant aux développeurs de définir le mappage dans une syntaxe déclarative, qui leur évite d'utiliser une nouvelle API. Encore une fois, cette approche permet aux développeurs de code managé d'exploiter des compétences qu'ils possèdent déjà. Comme mentionné plus haut, l'instrumentation se décompose en deux étapes principales : la définition de classe au moment du design et la fourniture de données au moment de l'exécution. L'utilisation d'attributs revêt une importance capitale pour la première étape et permet aux métadonnées de classe managée de décrire complètement le schéma d'instrumentation. Les métadonnées sont ensuite utilisées pour créer le schéma WMI qui est visible pour les outils de gestion.
Voir aussi
Instrumentation des applications .NET Framework avec System.Management | Exposition d'événements de gestion | Exposition de données de gestion | Héritage | Inscription du schéma pour une application instrumentée