Perché dovrei scegliere Powershell su WMI per sviluppare interfacce di gestione?

Question

Stiamo discutendo dello sviluppo di una migliore infrastruttura di gestione per il nostro sistema distribuito. Utilizziamo COM, servizi Web e componenti .NET. Dal momento che siamo basati su Microsoft Windows Server XP / 2003, suppongo, abbiamo sostanzialmente due opzioni:

1. Cmdlet Powershell
2. Classi WMI utilizzando System.Management e provider WMI per codice nativo (classe, istanza, metodo, evento)

Perché dovremmo scegliere Powershell su WMI?

Answer 1

Vorrei scegliere PowerShell su WMI per i seguenti motivi:

1. La scrittura di un cmdlet sta solo aggiungendo una classe .NET.
2. Il runtime di PowerShell fornisce l'analisi della riga di comando integrata.
3. La scrittura dell'interfaccia di gestione in PowerShell consente agli amministratori di integrare la gestione dell'applicazione con quella di altre applicazioni e servizi (come Exchange, Active Directory o SQL Server).
4. L'ambiente PowerShell rende disponibile la pipeline agli amministratori, consentendo di svolgere le attività di gestione per l'applicazione in modo più efficiente.
5. Discoverability. PowerShell, tramite Get-Command, Get-Member e Get-Help, fornisce un ambiente estremamente rilevabile a cui gli amministratori possono lavorare, risultando in una curva di apprendimento più breve per mantenere l'applicazione.

Anche se segui il percorso WMI, PowerShell ha il supporto per lavorare con WMI (anche se ci sono alcuni problemi).

Per me, PowerShell è il modo migliore per far emergere un'interfaccia orientata alle attività a un'applicazione. Con il supporto fornito da Microsoft PowerShell, è e sarà un'interfaccia coerente per la gestione di applicazioni e servizi in tutta l'azienda.

Il mio lavoro quotidiano è come amministratore e sto spingendo tutti i fornitori con cui lavoro ad emergere un'API di gestione di PowerShell, in quanto ciò rende la curva di apprendimento e il cambio di contesto per la gestione delle applicazioni molto più bassi. Per quanto riguarda lo sviluppo, ho scritto (e sto ancora lavorando) una serie di cmdlet di PowerShell per un prodotto open source con cui lavoro e sto lavorando su un altro set per un'applicazione separata.

Answer 2

Jeffrey Snover risponde al "perché PowerShell" qui . Il post è nel contesto di SQL, ma molto applicabile qui.

Answer 3

Non sono sicuro di prendere la decisione. Non è esattamente né-o ... puoi scegliere di fare entrambe le cose.

WMI può essere utilizzato da una serie di cose diverse, non solo da PowerShell. Perché non scrivere la strumentazione di gestione in PowerShell e quindi avvolgere tale WMI in alcuni cmdlet orientati alle attività per semplificare le cose agli amministratori? Questo è ciò che alcuni team di prodotti MS stanno scegliendo di fare, specialmente quando hanno altri consumatori di WMI che vogliono continuare a supportare.

Se hai già ottenuto il codice .NET adatto, trasformarlo in un cmdlet potrebbe essere più veloce che trasformarlo in un provider WMI. In tal caso, e la velocità è un problema, vai con ciò che è più facile. Indipendentemente da ciò che fai, puoi sempre inserirlo in un cmdlet di PowerShell per amministratori, che è sicuramente l'approccio consigliato.

Answer 4

Non sono sicuro che si possa rispondere a questa domanda con le informazioni fornite finora. La mia sensazione è che dovresti usare PowerShell dal momento che sembra che tu abbia già del codice .Net. Ma dipende solo esattamente da cosa stai cercando di fare.