Instrumentation des applications .NET Framework avec System.Management

Le but de l'espace de noms System.Management.Instrumentation est de minimiser le travail nécessaire pour préparer une application à la gestion. Par ailleurs, cet espace de noms facilite l'exposition des événements et des données ainsi que l'utilisation de relations entre les objets de gestion.

L'un des principaux avantages de WMI est de permettre aux développeurs d'applications d'accéder à des informations de diverses sources à travers une architecture commune. La source des informations peut être un matériel, un système d'exploitation ou une application logicielle. Les informations fournies par la source de données constituent ce qu'il est convenu d'appeler une instrumentation. Le but de l'instrumentation est analogue à celui des instruments réunis sur le tableau de bord de votre voiture. Votre voiture a des jauges qui vous permettent de surveiller le niveau de divers composants (par exemple la jauge d'essence) et des indicateurs qui vous préviennent lorsque certains événements se produisent (par exemple l'alarme de porte ouverte). Tous ces instruments vous permettent de prendre des décisions quant à la manière de conduire et d'entretenir votre voiture. Les composants informatiques qui ont fourni l'instrumentation permettent au logiciel de gestion de diagnostiquer et de résoudre les problèmes dans un environnement informatique d'entreprise.

WMI est la norme d'instrumentation utilisée par des applications de gestion telles que Microsoft Operations Manager, Microsoft Application Center et de nombreux outils de gestion fournis par des tiers. Le système d'exploitation Windows est instrumenté avec WMI, mais les développeurs désireux de voir leurs produits fonctionner avec des outils de gestion doivent fournir l'instrumentation dans leur propre code. L'espace de noms System.Management.Instrumentation permet aux développeurs de code managé de faire remonter des informations à des outils exploitant les possibilités de WMI.

L'exposition des objets d'une application en vue de la gestion doit être intuitive pour les développeurs .NET Framework dans la mesure où le schéma WMI est orienté objet et possède de nombreux traits communs avec les métadonnées .NET Framework : les classes de code correspondent aux classes de schéma, les propriétés sur les objets code correspondent aux propriétés sur les objets WMI, et ainsi de suite. Par conséquent, il est facile d'instrumenter les applications à code managé pour les rendre gérables. Les développeurs habitués à écrire du code managé possèdent déjà les compétences nécessaires pour fournir une instrumentation à travers WMI. L'apprentissage est quasiment instantané et, en particulier, il n'est pas nécessaire de comprendre l'API de client WMI.

Les informations d'application pour la gestion sont pour la plupart exposées au moyen de déclarations : ces opérations ne requièrent pas de gros volumes de code supplémentaires. Le développeur marque les objets comme gérables en utilisant les possibilités offertes par les attributs dans le .NET Framework et définit les éléments auxquels ils correspondent dans le schéma System.Management.Instrumentation. Le développeur peut aussi dériver la classe d'une classe de schéma System.Management.Instrumentation commune ; dans ce cas, la définition des attributs et le mappage sont déjà effectués.

Une fois l'application instrumentée, il est possible de découvrir, de surveiller et de configurer des objets et des événements à travers WMI et les applications de gestion développées par la large base de clients WMI (tels que Computer Associates, Tivoli Systems, Inc., BMC Software, Hewlett-Packard, etc.). Les événements de code managé marqués à des fins de gestion sont déclenchés automatiquement en tant qu'événements WMI.

La prise en charge de la sécurité dans System.Management est étroitement liée à la sécurité dans WMI. Pour contrôler l'accès des clients aux informations, WMI emploie une sécurité basée sur l'espace de noms.

Pour faciliter le développement, les données d'instrumentation sont publiées vers l'espace de noms root\default, sauf spécification contraire par l'attribut Instrumented sur l'assembly. Toutefois, il est recommandé que les développeurs substituent cet emplacement par défaut et définissent un espace de noms spécifique pour leur application afin de pouvoir la gérer en toute indépendance.

La méthode conseillée est la suivante :

• Créez pour votre assembly (ou groupe d'assemblys ou application) spécifique un espace de noms séparé présentant des exigences analogues en matière de sécurité. Utilisez le nom de la société et le nom du produit logiciel dans votre définition d'espace de noms, afin d'assurer l'unicité des noms. Par exemple, l'instrumentation de votre application peut être publiée dans l'espace de noms « racine\<nom de votre société>\<nom de votre produit> ». La hiérarchie de l'espace de noms peut éventuellement contenir aussi des informations de version (pour plus d'informations sur le versioning, consultez la section consacrée à l'inscription du schéma).
• Les administrateurs peuvent spécifier des contraintes de sécurité pour un espace de noms spécifique à l'aide du Contrôle WMI. Pour appeler le Contrôle WMI, cliquez avec le bouton droit sur "Poste de travail", sélectionnez "Gérer" pour démarrer la console MMC "Gestion de l'ordinateur", puis développez le nœud "Services et applications", sélectionnez "Contrôle WMI", cliquez avec le bouton droit et sélectionnez "Propriétés". Ensuite, cliquez sur l'onglet "Sécurité" pour afficher ou modifier les paramètres de sécurité de l'espace de noms de votre application.

Voir aussi

Gestion des applications avec WMI | Classes et mappage dans CLI et WMI | Exposition d'événements de gestion | Exposition de données de gestion | Héritage | Inscription du schéma pour une application instrumentée