Classi e mapping in CLI e WMI

Il concetto di definizioni di classe è alla base della programmazione in codice gestito. Anche WMI è basato sullo stesso principio fondamentale di definizioni di classe. Tuttavia, WMI dispone di una propria grammatica per la descrizione delle classi (MOF) e di un'API per la definizione di classi a livello di programmazione.

Lo scopo principale della strumentazione è rendere disponibili le informazioni che potrebbero essere utili agli strumenti per gestire un'applicazione. Altre tecnologie di strumentazione, ad esempio file di analisi e file log, limitano le applicazioni al recupero di un blocco non elaborato di informazioni di diagnostica non strutturate, ad esempio una semplice stringa. La strumentazione tramite WMI consente di rendere disponibili numerose informazioni basate sullo schema. Per eseguire l'operazione, le applicazioni definiscono un insieme di classi WMI che descrivono le informazioni messe a disposizione tramite la strumentazione. Queste definizioni di classe vengono pubblicate tramite WMI e rese disponibili per gli strumenti di gestione. Le definizioni di classe devono essere disponibili in qualsiasi momento dopo l'installazione dell'applicazione, non solo quando l'installazione viene eseguita. In fase di esecuzione l'applicazione fornisce i dati effettivi descritti dalle classi WMI.

Il modello di WMI delle definizioni di classe che possono essere individuate in qualsiasi momento è molto simile al modello di CLI di classi gestite e metadati. Lo spazio dei nomi System.Management.Instrumentation sfrutta le somiglianze tra le classi WMI e le classi CLI per consentire agli sviluppatori di definire le classi di WMI tramite la scrittura di definizioni di classi nel codice gestito. Questo significa che uno sviluppatore di codice gestito sa già come definire classi WMI senza dover apprendere nulla di nuovo.

In genere, delle classi di codice gestito viene eseguito il mapping sulle classi WMI. In alcuni casi le classi WMI presentano caratteristiche che non possono essere descritte nelle classi gestite. I primitivi di WMI, ad esempio, possono essere null, mentre questo non è possibile per i tipi di valore CTS (Common Type System). Lo spazio dei nomi System.Management.Instrumentation non consente agli sviluppatori di descrivere classi WMI che rappresentano elementi che non possono essere descritti in CTS.

Nell'elenco seguente sono descritti alcuni dei modi fondamentali utilizzati nelle classi gestite per eseguire il mapping su classi WMI:

• Solo le classi gestite pubblicamente possono essere mappate sulle classi WMI e solo i membri pubblici possono essere mappati sulla definizione di classe WMI.

• È possibile eseguire facilmente il mapping di tipi valore primitivo su tipi CIM WMI.

  Inoltre, i tipi riferimento String, DateTime e TimeSpan vengono mappati sui tipi CIM WMI equivalenti.

• Le matrici nel codice gestito vengono mappate sulle matrici nelle definizioni di classe WMI.

• In CLI viene operata una distinzione tra tipi valore e tipi riferimento.

  In WMI questa distinzione non esiste ed è possibile eseguire il mapping di entrambi i tipi su una definizione di classe WMI.

• In WMI sono supportati oggetti incorporati e riferimenti ad altri oggetti.

  Nella prima versione di System.Management.Instrumentation vengono supportati solo oggetti incorporati. Per quanto riguarda le classi gestite che contengono membri di tipo valore, è logico che ne venga eseguito il mapping sulle classi WMI che contengono un oggetto incorporato. Anche le classi gestite che contengono membri di tipo riferimento vengono mappate sulle classi WMI con oggetti incorporati, ma le versioni future potrebbero consentire agli sviluppatori di specificare che i riferimenti di runtime devono essere rappresentati da riferimenti di WMI.

• Le gerarchie di ereditarietà delle classi gestite vengono rappresentate da gerarchie di ereditarietà in WMI.

• Nella prima versione di System.Management.Instrumentation i valori predefiniti di WMI non possono essere rappresentati nel codice gestito.

  Gli inizializzatori di campo nei campi di classi gestite non vengono mappati su valori predefiniti di WMI.

• In WMI non viene operata la distinzione tra campi e proprietà.

  In una definizione di classe gestita sia i campi che le proprietà vengono mappati su proprietà di WMI.

• Lo spazio dei nomi di una definizione di classe gestita non ha alcuna relazione con lo spazio dei nomi della definizione di classe WMI.

  In altre parole, una classe gestita potrebbe essere definita nello spazio dei nomi MiaAzienda.MiaApplicazione e la relativa classe di strumentazione di WMI potrebbe essere definita con lo spazio dei nomi root\MiaAzienda.

• In WMI è supportato un concetto simile a quello dell'attributo, definito qualificatore.

  In System.Management.Instrumentation non viene eseguito alcun mapping tra attributi di codice gestito e qualificatori di WMI. Esistono attributi nello spazio dei nomi System.Management.Instrumentation ma questi non sono rappresentati da qualificatori nella definizione di classe WMI. Per consentire il mapping tra i due, nello spazio dei nomi System.Management.Instrumentation vengono definite diverse classi di attributi che consentono agli sviluppatori di definire il mapping su una sintassi dichiarativa anziché tramite l'utilizzo di una nuova API. Anche in questo caso viene utilizzata una funzionalità già nota agli sviluppatori di codice gestito. Come ricordato, la strumentazione si compone fondamentalmente di due livelli: definizione di classe in fase di progettazione e fornitura di dati in fase di esecuzione. L'utilizzo di attributi è fondamentale per il primo livello e consente ai metadati della classe gestita di descrivere completamente lo schema di strumentazione. I metadati vengono quindi utilizzati per creare lo schema di WMI visibile agli strumenti di gestione.

Vedere anche

Strumentazione di applicazioni .NET Framework tramite System.Management | Esposizione di eventi di gestione | Esposizione di dati di gestione | Ereditarietà | Registrazione dello schema per un'applicazione con strumentazione