Por que eu iria escolher Powershell sobre WMI para desenvolver interfaces de gerenciamento?

Question

Estamos discutindo desenvolvimento de uma infra-estrutura de gerenciamento melhorado para o nosso sistema distribuído. Usamos COM, serviços web e componentes .NET. Uma vez que estamos com base no Microsoft Windows Server XP / 2003, eu acho, temos basicamente duas opções:

1. cmdlets do PowerShell
2. classes WMI usando provedores System.Management e WMI para código nativo (classe, instância método, evento)

Por que nós escolhemos Powershell sobre WMI?

Answer 1

Eu escolheria PowerShell sobre WMI, pelos seguintes motivos:

1. Escrevendo um cmdlet é apenas a adição de uma classe .NET.
2. O tempo de execução PowerShell fornece linha de comando de análise integrada.
3. Escrevendo sua interface de gestão no PowerShell permite aos administradores a capacidade de integrar o gerenciamento de sua aplicação com a de outras aplicações e serviços (como o Exchange, Active Directory ou SQL Server).
4. O ambiente PowerShell faz o pipeline disponíveis para os administradores, permitindo que as tarefas de gestão para a sua aplicação deve ser feito de forma mais eficiente.
5. Descoberta. PowerShell, através de Get-Command, Get-Member, e Get-Help, proporciona um ambiente extremamente visível para administradores para trabalhar, resultando em uma curva de aprendizado mais curta para a manutenção da sua aplicação.

Mesmo se você for a rota WMI, PowerShell tem suporte para trabalhar com o WMI (embora haja algumas falhas).

Para mim, PowerShell é a melhor maneira para a superfície um tarefa orientada interface para um aplicativo. Com o apoio da Microsoft tem vindo a fornecer PowerShell, é e será uma interface consistente para gerenciar aplicativos e serviços em toda a empresa.

Meu trabalho é como um administrador e eu estou empurrando todos os fornecedores com quem trabalho em direção à tona uma API de gerenciamento PowerShell, pois isso faz com que a curva de aprendizado e troca de contexto para o gerenciamento de aplicações muito mais baixo. No lado do desenvolvimento, eu escrevi (e ainda estou trabalhando em) uma série de cmdlets PowerShell para um open source trabalho do produto I com e estou trabalhando em um outro conjunto de um aplicativo separado.

Answer 2

Jeffrey Snover responde o "porquê PowerShell" aqui . O post é no contexto de SQL, mas muito aplicável aqui.

Answer 3

Eu não estou certo que eu tomar a decisão. Não é exatamente isto ou ... você pode optar por fazer as duas coisas.

WMI pode ser consumido por uma série de coisas diferentes, não apenas PowerShell. Por que não escrever a sua instrumentação de gestão em PowerShell, e em seguida, enrole que WMI em alguns cmdlets orientados a tarefas para tornar as coisas mais fáceis para os administradores? Isso é o que algumas equipes produtos MS estão optando por fazer, especialmente quando eles têm outros consumidores do WMI eles querem continuar a apoiar.

Se você já tem o código .NET adequado, transformando isso em um cmdlet pode ser mais rápido do que transformá-lo em um provedor de WMI. Se for esse o caso, ea velocidade é uma preocupação, ir com o que é mais fácil. Mas não importa o que você faz, você sempre pode envolvê-la em um cmdlet PowerShell para administradores, que é definitivamente a abordagem recomendada.

Answer 4

Não tenho certeza de que isso pode ser respondida com a informação que você forneceu até agora. Minha intuição seria que você deve usar o PowerShell, uma vez que parece que você já pode ter algum código .Net. Mas realmente não depende apenas exatamente o que você está tentando fazer.