Desenvolvimento SMP

Um provedor WMI

As interfaces SMP (Storage Management Provider) são baseadas em WMI. Embora você possa escrever um SMP usando WMI v1, é altamente recomendável que você escreva um provedor WMI v2 usando C/C++. Não recomendamos o uso do .NET Framework para desenvolvimento SMP porque algumas funcionalidades importantes podem não estar disponíveis por meio da plataforma .NET. Além disso:

• WMI v1 tem uma forte dependência de COM, que pode ser difícil e demorado de se aprender.
• O WMI v2 está mais alinhado com os padrões da indústria do que o WMI v1; WMI v2 usa WS-Management em vez de DCOM.
• Os provedores podem utilizar melhor o tratamento de erros/eventos no WMI v2.
• Os provedores podem utilizar extensões e integração do PowerShell no WMI v2.

Lista de verificação de recursos de desenvolvimento

Definição de MOF

O desenvolvimento inicial do SMP é feito em três etapas simples:

1. Expanda o fornecedor MOF.
2. Gere um esqueleto de provedor (ou modelos de código).
3. Implementar stubs (esboços).

Ampliando o MOF do provedor

Os MOFs SMP estão localizados na pasta include do SDK do Windows. Eles são prefixados com MSFT_*. Copie esses arquivos para o diretório de desenvolvimento, juntamente com CIM_Error.mof e qualifiers.mof. Cada MOF define uma ou mais classes abstratas que formam a base para o seu SMP.

Semelhante a outras linguagens, uma classe abstrata não pode ser implementada diretamente. Ele deve ser derivado e implementado em uma classe de implementação separada. Crie seu próprio MOF e inclua todos os MOFs de provedores relevantes. Em seguida, crie uma classe derivada para cada uma das classes base que seu provedor implementará. Certifique-se de escolher um prefixo exclusivo para suas aulas. Por exemplo, uma empresa chamada "Contoso Storage Inc." poderiam prefixar suas classes com CONTOSO_* ou CSI_*. Por exemplo, para MSFT_StorageProvider, um prefixo de "CONTOSO_" renderia CONTOSO_StorageProvider. A classe agora deve ter esta aparência:

    class CONTOSO_StorageProvider : MSFT_StorageProvider
    {
        ...
    }

Depois de criar essas classes esqueleto, você deve copiar todas as declarações de método para os métodos que você planeja implementar. Todos os métodos que não são transferidos (independentemente de serem implementados ou não) retornarão MI_RESULT_NOT_SUPPORTED. Não é necessário copiar as propriedades da classe. Para minimizar erros de compilação MOF, mantenha todos os qualificadores dos métodos e parâmetros.

Finalmente, certifique-se de incluir estas linhas no início do seu MOF:

    #pragma include("storagewmi_provider.mof")
    #pragma include("msft_qualifiers.mof")

Quando concluir a Etapa 1, você estará pronto para gerar os stubs do provedor usando Convert-MofToProvider.exe. Ao fornecer entrada para esse comando, certifique-se de especificar apenas as classes derivadas. Os cabeçalhos para as classes base são gerados implicitamente.

Consulte os MOFs de exemplo do SMP.

Geração de esqueleto de provedor

Os desenvolvedores do SMP podem usar a ferramenta Convert-MofToProvider.exe do SDK do WMI para gerar um projeto esqueleto de provedor. Este projeto inclui uma lista de ficheiros de cabeçalho e ficheiros de código-fonte C pré-configurados com métodos de provedor WMI. Ao fornecer implementações para esses métodos, os desenvolvedores podem fornecer suporte ao hardware de armazenamento.

Coloque todos os MOFs da seção "Lista de verificação de recursos de desenvolvimento" e os MOFs criados em uma pasta. Em seguida, use o seguinte comando em um prompt de comando para gerar o esqueleto do provedor (consulte o texto de ajuda para obter as opções mais atualizadas):

    Convert-MofToProvider.exe
        -MofFile <path to your provider mof>
        -ClassList <list of ALL classes listed in your mof, space separated>
        -IncludePath <path to qualifiers.mof and CIM_Error.mof>
        -SkipQualifiers
        -SkipLocalize

Finalmente, inclua o arquivo de cabeçalho mi.h em seu projeto de desenvolvimento.

Sequência de desenvolvimento recomendada

StorageProvider, StorageSubSystem e VirtualDisk são classes obrigatórias. Dependendo dos recursos do seu storage array, StoragePool, ResiliencSetting, PhysicalDisk, MaskingSet, InitiatorId, TargetPort, TargetPortal, OffloadDataTransferSetting e StorageJob são opcionais.

Para facilitar o processo de desenvolvimento e teste, segue-se uma sequência recomendada de implementação:

1. EnumerateInstances: suporta consultas básicas para as classes necessárias StorageProvider, StorageSubSystem, VirtualDisk.
2. GetInstance: GetInstance é necessário para muitas operações WMI, incluindo invocação de método.
3. Create*/DeleteObject: implemente todos os métodos de criação e exclusão para os objetos suportados pelo provedor.
4. Associações de objetos: as associações permitem uma travessia rápida e fácil entre os objetos da matriz. EnumerateInstances, AssociatorsOf e ReferencesOf na classe associator são necessários para a implementação. GetInstance no associador não é necessário, mas GetInstance nos objetos de origem e destino é.
5. Indicações: As indicações permitem que o seu fornecedor notifique as aplicações de gestão sobre uma alteração.
6. Restante dos métodos.

Registo de Fornecedor

Inicie um prompt de comando. Registe o seu fornecedor com o seguinte comando:

    Register-CimProvider.exe 
    –Namespace root\Microsoft\Windows\Storage\Providers
    –ProviderName <name of your provider>
    –Path <path to your provider’s dll file>