Implementar a interface primária para um provedor de classe

Há duas maneiras de implementar um provedor de classe: implementar a interface como um provedor de push ou como um provedor de pull.

As seções a seguir serão abordadas neste tópico:

• Implementar a interface primária para um provedor de classe de push
• Implementar a interface primária para um provedor de classe de pull

Implementar a interface primária para um provedor de classe de push

Enquanto todos os provedores implementam IWbemProviderInit para inicialização e pelo menos uma outra interface como interface primária, um provedor de push implementa apenas IWbemProviderInit.

Verifique se a implementação executa as seguintes tarefas:

• Recupera os dados de classe apropriados.
• Coloca os dados no repositório do WMI.
• Exclui dados obsoletos.

Depois de concluir o processo de inicialização, o WMI processa todas as solicitações de aplicativo para classes pertencentes ao provedor de push sem qualquer interação adicional do provedor. Posteriormente, o provedor de push atua efetivamente como um cliente do WMI em vez de um provedor. Para obter mais informações sobre como implementar IWbemProviderInit, consulte Inicializar um provedor.

Observação

Ao chamar o WMI para criar, atualizar ou remover dados em um provedor de push, defina o parâmetro lFlags para incluir o sinalizador WBEM_FLAG_OWNER_UPDATE em todas as chamadas para métodos IWbemServices.

 

Implementar a interface primária para um provedor de classe de pull

Um provedor de classe de pull deve implementar IWbemServices como interface primária. A interface IWbemServices dá suporte à recuperação de dados, à atualização de dados, à remoção de dados, à enumeração e ao processamento de consultas. No entanto, como IWbemServices também é usado por aplicativos e provedores para solicitar serviços do WMI, IWbemServices contém muitos métodos irrelevantes para um provedor de classe. Sua implementação deve dar suporte à recuperação e enumeração de classe por meio dos métodos GetObjectAsync e CreateClassEnumAsync, respectivamente. A tabela a seguir lista os métodos IWbemServices assíncronos adicionais que você pode implementar para um provedor de classe.

Método	Recurso
PutInstanceAsync	Modification
DeleteClassAsync	Exclusão

 

Observação

Como o retorno de chamada para o coletor pode não ser retornado no mesmo nível de autenticação exigido pelo cliente, é recomendável que você use comunicação semissíncrona em vez de assíncrona. Para obter mais informações, consulte Chamar um método.

 

Seu provedor de classe deve fornecer uma implementação de stub que retorna WBEM_E_PROVIDER_NOT_CAPABLE para todos os outros métodos IWbemServices que não dão suporte ao seu conjunto de recursos. Especificamente, o WMI não dá suporte ao processamento de consultas para provedores de classe. Dessa forma, um provedor de classe deve retornar WBEM_E_PROVIDER_NOT_CAPABLE de sua implementação de IWbemServices::ExecQueryAsync, definir sua propriedade de registro QuerySupportLevels como NULL ou ambos.

As interfaces que um provedor de classe implementa são muito semelhantes às interfaces de um provedor de instância e de um provedor de método. Na verdade, um único provedor pode atuar como os três tipos de provedor implementando todos os métodos e registrando corretamente.