Clases y asignación en CLI y WMI

El concepto de definición de clase es el núcleo de la programación en código administrado. WMI también se basa en el mismo principio básico de definición de clases, pero WMI dispone de su propia gramática para describirlas (MOF) y de una API para definirlas mediante programación.

La finalidad básica del instrumental es extraer información que podría ser útil para herramientas que intentan administrar una aplicación. Otras tecnologías de instrumental, como el seguimiento o los archivos de registro, obliga a las aplicaciones a proporcionar un bloque sin formato de información de diagnóstico sin estructurar (por ejemplo, una simple cadena). El instrumental de WMI permite extraer información muy completa basada en esquemas. Para ello, las aplicaciones definen un conjunto de clases WMI que describen la información que se proporcionará a través del instrumental. Estas definiciones de clases se publican mediante WMI y las herramientas de administración pueden tener acceso a ellas. Las definiciones de clases deben estar disponibles en todo momento una vez instalada una aplicación, no sólo cuando ésta se está ejecutando. En tiempo de ejecución, la aplicación proporciona los datos reales que describen las clases WMI.

El modelo WMI de definiciones de clase que se pueden descubrir en cualquier momento es muy parecido al modelo CLI (Call Level Interface, Interfaz de nivel de llamada) de clases y metadatos administrados. El espacio de nombres System.Management.Instrumentation aprovecha las similitudes entre las clases WMI y las clases CLI para permitir que los programadores definan clases WMI mediante la escritura de definiciones de clases en código administrado. Como consecuencia, un programador de código administrado ya sabe cómo definir clases WMI sin necesidad de aprender nada nuevo.

En general, las clases de código administrado se asignan a clases WMI. En algunos casos, las clases tienen características que no se pueden describir en clases administradas. Por ejemplo, los tipos primitivos WMI pueden ser null, a diferencia de los tipos de valor de CTS (Common Type System, Sistema de tipos común), que no pueden serlo. El espacio de nombres System.Management.Instrumentation no intenta permitir que los programadores describan clases WMI que representan algo que no se puede describir en el CTS.

En la lista siguiente se describen algunas de las formas básicas en que las clases administradas se asignan a las clases WMI:

• Sólo las clases administradas públicas se pueden asignar a clases WMI y sólo los miembros públicos se pueden asignar a la definición de clase WMI.

• Los tipos de valor primitivos se asignan fácilmente a tipos WMI CIM.

  Además, los tipos de referencia String, DateTime y TimeSpan se asignan a los tipos WMI CIM equivalentes.

• Las matrices en código administrado se asignan a matrices en las definiciones de clase WMI.

• La CLI distingue entre tipos de valor y tipos de referencia.

  WMI no establece esta distinción y ambos se pueden asignar a una definición de clase WMI.

• WMI admite objetos incrustados así como referencias a otros objetos.

  En la primera versión de System.Management.Instrumentation sólo se admitían objetos incrustados. Para clases administradas que contienen miembros de tipo de valor, es lógico que éstos se asignen a clases WMI que contienen un objeto incrustado. Las clases administradas que contienen miembros de tipo de referencia también se asignan a clases WMI con objetos incrustados, pero las futuras versiones podrían permitir que los programadores especifiquen que las referencias en tiempo de ejecución deban estar representadas por referencias WMI.

• Las jerarquías de herencia de clases administradas están representadas por jerarquías de herencia en WMI.

• En la primera versión de System.Management.Instrumentation, los valores predeterminados de WMI no se pueden representar en código administrado.

  A los inicializadores de campo en campos de clases administradas no se les asignan valores predeterminados WMI.

• WMI no distingue entre campos y propiedades.

  En una definición de clase administrada, tanto a los campos como a las propiedades se les asignan propiedades WMI.

• El espacio de nombres de una definición de clase administrada no está relacionado con el espacio de nombres de la definición de clase WMI.

  En otras palabras, una clase administrada podría estar definida en el espacio de nombres MyCompany.MyApplication y la correspondiente clase de instrumental WMI podría estar definida como el espacio de nombres WMI root\MyCompany.

• WMI admite un concepto similar al de atributo, denominado calificador.

  En System.Management.Instrumentation no hay asignación entre atributos de código administrado y calificadores WMI. En el espacio de nombres System.Management.Instrumentation hay atributos, pero no están representados por calificadores en la definición de clase WMI. Para permitir la asignación entre los dos, el espacio de nombres System.Management.Instrumentation define varias clases de atributos que permiten a los programadores definir la asignación en una sintaxis declarativa, en lugar de usar una nueva API. Esto permite aprovechar los conocimientos y la experiencia que ya tienen los programadores de código administrado. Como se ha mencionado, el instrumental consta principalmente en dos fases: definición de las clases en tiempo de diseño y provisión de datos en tiempo de ejecución. El uso de atributos es crucial en la primera fase y permite que los metadatos de clases administradas describan completamente el esquema del instrumental. Después, los metadatos se usan para crear el esquema WMI que pueden ver las herramientas de administración.

Vea también

Instrumentar aplicaciones de .NET Framework con System.Management | Exponer eventos de administración | Exponer datos de administración | Herencia | Registrar el esquema de una aplicación instrumentada