Visão geral técnica do COM

Este tópico fornece uma visão geral do Microsoft Component Object Model (COM):

Introdução ao COM

O Microsoft Component Object Model (COM) define um padrão de interoperabilidade binário para criar bibliotecas de software reutilizáveis que interagem em tempo de execução. Você pode usar bibliotecas COM sem a necessidade de compilá-las em seu aplicativo. COM é a base para uma série de produtos e tecnologias da Microsoft, como o Windows Media Player e o Windows Server.

COM define um padrão binário que se aplica a muitos sistemas operacionais e plataformas de hardware. Para computação em rede, o COM define um formato de fio padrão e um protocolo para interação entre objetos que são executados em diferentes plataformas de hardware. COM é independente da linguagem de implementação, o que significa que você pode criar bibliotecas COM usando linguagens de programação diferentes, como C++ e aquelas no .NET Framework.

A especificação COM fornece todos os conceitos fundamentais que permitem a reutilização de software multiplataforma:

  • Um padrão binário para chamadas de função entre componentes.
  • Uma provisão para agrupamentos fortemente tipados de funções em interfaces.
  • Uma interface base que fornece polimorfismo, descoberta de recursos e rastreamento do tempo de vida do objeto.
  • Um mecanismo que identifica exclusivamente os componentes e suas interfaces.
  • Um carregador de componentes que cria instâncias de componentes a partir de uma implantação.

COM tem várias partes que trabalham juntas para permitir a criação de aplicativos que são criados a partir de componentes reutilizáveis:

  • Um sistema host que fornece um ambiente de tempo de execução que está em conformidade com a especificação COM.
  • Interfaces que definem contratos de recursos e componentes que implementam interfaces.
  • Servidores que fornecem componentes para o sistema e clientes que usam os recursos fornecidos pelos componentes.
  • Um registro que controla onde os componentes são implantados em hosts locais e remotos.
  • Um Gerenciador de Controle de Serviços que localiza componentes em hosts locais e remotos e conecta servidores a clientes.
  • Um protocolo de armazenamento estruturado que define como navegar pelo conteúdo dos arquivos no sistema de arquivos do host.

Habilitar a reutilização de código entre hosts e plataformas é fundamental para o COM. Uma implementação de interface reutilizável é nomeada um componente, um objeto de componente ou um objeto COM. Um componente implementa uma ou mais interfaces COM.

Você define uma biblioteca COM personalizada projetando as interfaces que sua biblioteca implementa. Os consumidores de sua biblioteca podem descobrir e usar seus recursos sem qualquer conhecimento dos detalhes de implantação e implementação de sua biblioteca.

Objetos e Interfaces

Um objeto COM expõe seus recursos por meio de uma interface, que é uma coleção de funções de membro. Uma interface COM define o comportamento e as responsabilidades esperados de um componente e especifica um contrato fortemente tipado que fornece um pequeno conjunto de operações relacionadas. Toda a comunicação entre componentes COM ocorre através de interfaces, e todos os serviços oferecidos por um componente são expostos através de sua interface. Um chamador pode acessar apenas as funções de membro da interface. O estado interno não está disponível para um chamador, a menos que seja exposto na interface.

As interfaces são fortemente tipadas. Cada interface tem seu próprio identificador de interface exclusivo, chamado IID, que elimina colisões que poderiam ocorrer com nomes legíveis por humanos. O IID é um identificador global exclusivo (GUID), que é o mesmo que o ID Universalmente Exclusivo (UUID) definido pelo Ambiente de Computação Distribuída (DCE) da Open Software Foundation (OSF). Ao criar uma nova interface, você deve criar um novo identificador para essa interface. Quando um chamador usa uma interface, ele deve usar o identificador exclusivo. Essa identificação explícita melhora a robustez, eliminando conflitos de nomenclatura que resultariam em falha em tempo de execução.

Ao definir uma nova interface, você pode criar uma definição de interface usando a linguagem de definição de interface (IDL). A partir dessa definição de interface, o compilador IDL da Microsoft gera arquivos de cabeçalho para uso por aplicativos que usam a interface e código-fonte para manipular chamadas de procedimento remoto. O IDL fornecido pela Microsoft é baseado em extensões simples para DCE IDL, um padrão do setor para computação distribuída baseada em RPC (Remote Procedure Call). O IDL é uma ferramenta para a conveniência do designer de interface e não é central para a interoperabilidade COM. Com o IDL, você não precisa criar arquivos de cabeçalho manualmente para cada ambiente de programação. Para obter mais informações, consulte Definindo interfaces COM.

A herança é usada com moderação em interfaces COM. COM oferece suporte à herança de interface apenas para reutilizar um contrato associado a uma interface base. A OCM não suporta herança selectiva; Portanto, se uma interface herda de outra, ela inclui todas as funções que a interface base define. Além disso, as interfaces usam apenas herança única, em vez de herança múltipla, para obter funções de uma interface base.

Implementação de interface

Você não pode criar uma instância de uma interface COM por si só. Em vez disso, você cria uma instância de uma classe que implementa a interface. Em C++, uma interface COM é modelada como uma classe base abstrata, o que significa que a interface é uma classe C++ que contém apenas funções de membro virtual puras. Uma biblioteca C++ implementa objetos COM herdando as assinaturas de função de membro de uma ou mais interfaces, substituindo cada função de membro e fornecendo uma implementação para cada função.

Você pode usar qualquer linguagem de programação que ofereça suporte ao conceito de ponteiros de função para implementar uma interface COM. Por exemplo, em C, uma interface é uma estrutura que contém um ponteiro para uma tabela de ponteiros de função, um para cada método na interface.

Quando você implementa uma interface, sua classe deve fornecer uma implementação para cada função na interface. Se a classe não tiver trabalho a fazer em uma função de interface, a implementação pode ser uma única instrução de retorno.

Uma classe COM é identificada usando uma ID de classe de 128 bits (CLSID) exclusiva que associa uma classe a uma implantação específica no sistema de arquivos, que para o Windows é uma DLL ou EXE. Um CLSID é um GUID, o que significa que nenhuma outra classe tem o mesmo CLSID. O uso de identificadores de classe exclusivos evita colisões de nome entre classes. Por exemplo, dois fornecedores diferentes podem escrever uma classe chamada CStack, mas ambas as classes têm um CLSID exclusivo, portanto, qualquer possibilidade de colisão é evitada.

Você obtém um novo CLSID usando a função CoCreateGuid ou usando uma ferramenta de criação COM, como o Visual Studio, que chama essa função internamente.

A interface IUnknown

Todas as interfaces COM herdam da interface IUnknown. A interface IUnknown contém as operações COM fundamentais para polimorfismo e gerenciamento do tempo de vida da instância. A interface IUnknown tem três funções de membro, chamadas QueryInterface, AddRef e Release. Todos os objetos COM são necessários para implementar a interface IUnknown .

A função de membro QueryInterface fornece polimorfismo para COM. Chame QueryInterface para determinar em tempo de execução se um objeto COM oferece suporte a uma interface específica. O objeto COM retorna um ponteiro de interface no parâmetro se ele implementa ppvObject a interface solicitada, caso contrário, ele retorna NULL. A função de membro QueryInterface permite a navegação entre todas as interfaces que um objeto COM suporta.

O tempo de vida de uma instância de objeto COM é controlado por sua contagem de referência. As funções de membro IUnknown AddRef e Release controlam a contagem. AddRef incrementa a contagem e Release diminui a contagem. Quando a contagem de referência atinge zero, a função de membro Release pode liberar a instância, porque nenhum chamador a está usando.

O modelo cliente/servidor

Uma classe COM implementa um número de interfaces COM. A implementação consiste em binários que são executados quando um chamador interage com uma instância da classe COM. COM permite o uso de uma classe em diferentes aplicativos, incluindo aplicativos escritos sem conhecimento de uma classe específica. Em uma plataforma Windows, as classes existem em uma biblioteca de vínculo dinâmico (DLL) ou em outro aplicativo (EXE).

Em seu sistema host, o COM mantém um banco de dados de registro de todos os CLSIDs para os objetos COM instalados no sistema. O banco de dados de registro é um mapeamento entre cada CLSID e o local da DLL ou EXE que abriga a classe correspondente. COM consulta esse banco de dados sempre que um chamador deseja criar uma instância de uma classe COM. O chamador precisa saber apenas o CLSID para solicitar uma nova instância da classe.

A interação entre um objeto COM e seus chamadores é modelada como uma relação cliente/servidor. O cliente é o chamador que solicita um objeto COM do sistema e o servidor é o módulo que abriga objetos COM que fornece serviços aos clientes.

Um cliente COM é qualquer chamador que passa um CLSID para o sistema para solicitar uma instância de um objeto COM. A maneira mais simples de criar uma instância é chamar a função COM, CoCreateInstance.

A função CoCreateInstance cria uma instância do CLSID especificado e retorna um ponteiro de interface do tipo solicitado pelo cliente. O cliente é responsável por gerenciar o tempo de vida da instância chamando sua função Release quando o cliente terminar de usá-la. Para criar vários objetos com base em um único CLSID, chame a função CoGetClassObject. Para se conectar a um objeto que já está criado e em execução, chame a função GetActiveObject.

Um servidor COM fornece uma implementação COM para o sistema. Um servidor associa um CLSID a uma classe COM, abriga a implementação da classe, implementa uma fábrica de classes para criar instâncias da classe e fornece o descarregamento do servidor.

Observação

Um servidor COM não é o mesmo que o objeto COM que ele fornece ao sistema.

 

Para habilitar a criação de um objeto COM, um servidor COM deve fornecer uma implementação da interface IClassFactory. Os clientes podem chamar o método CreateInstance para solicitar uma nova instância de um objeto COM, mas geralmente essas solicitações são encapsuladas na função CoCreateInstance.

Você pode implantar um servidor COM como uma biblioteca compartilhada que é carregada no processo do cliente em tempo de execução (DLL em plataformas Windows) ou como um módulo executável (EXE em plataformas Windows). Para obter mais informações, consulte Registrando aplicativos COM.

Gerenciador de Controle de Serviço

O Service Control Manager (SCM) manipula a solicitação do cliente para uma instância de um objeto COM. A lista a seguir mostra a sequência de eventos:

  • Um cliente solicita um ponteiro de interface para um objeto COM da biblioteca COM chamando uma função como CoCreateInstance com o CLSID do objeto COM.
  • A Biblioteca COM consulta o SCM para localizar o servidor que corresponde ao CLSID solicitado.
  • O SCM localiza o servidor e solicita a criação do objeto COM da fábrica de classes fornecida pelo servidor.
  • Se bem-sucedida, a Biblioteca COM retornará um ponteiro de interface para o cliente.

Depois que o sistema COM conecta um objeto de servidor a um cliente, o cliente e o objeto se comunicam diretamente. Não há sobrecarga adicional de chamada por meio de um tempo de execução intermediário.

Ao registrar um servidor COM no sistema host, você pode especificar maneiras diferentes para que o servidor seja ativado. A lista a seguir mostra as três maneiras pelas quais o SCM pode ativar um servidor COM:

  • Em processo: O SCM retorna o caminho do arquivo da DLL que contém a implementação do servidor de objeto. A biblioteca COM carrega a DLL e a consulta para seu ponteiro de interface de fábrica de classe.
  • Local: O SCM inicia o executável local que registra uma fábrica de classes na inicialização e seu ponteiro de interface está disponível para o sistema e os clientes.
  • Remoto: o SCM local adquire um ponteiro de interface de fábrica de classe do SCM que está sendo executado em um computador remoto.

Quando um cliente solicita um objeto COM, a Biblioteca COM entra em contato com o SCM no host local. O SCM localiza o servidor COM apropriado, que pode ser local ou remoto, e o servidor retorna um ponteiro de interface para a fábrica de classes do servidor. Quando a fábrica de classes está disponível, a biblioteca COM ou o cliente pode usar a fábrica de classes para criar o objeto solicitado. Para obter mais informações, consulte Implementando IClassFactory.

Capacidade de reutilização

O COM oferece suporte à reutilização de caixa preta, o que significa que os detalhes de implementação de um componente reutilizável não são expostos aos clientes. Para alcançar a reutilização da caixa preta, o COM oferece suporte a dois mecanismos por meio dos quais um objeto pode reutilizar outro. As duas formas de reutilização são denominadas contenção e agregação. Por convenção, o objeto que está sendo reutilizado é chamado de objeto interno, e o objeto que está fazendo uso do objeto interno é chamado de objeto externo.

Na contenção, o objeto externo se comporta como um cliente do objeto interno. O objeto externo é um contêiner lógico para o objeto interno e, quando o objeto externo usa os serviços do objeto interno, o objeto externo delega a implementação às interfaces do objeto interno. Isso significa que o objeto externo é implementado em termos de serviços do objeto interno. O objeto externo pode não suportar as mesmas interfaces que o objeto interno, e o objeto externo pode usar a interface de um objeto interno para ajudar a implementar partes de uma interface diferente no objeto externo.

Na agregação, o objeto externo expõe interfaces do objeto interno como se fossem implementadas no objeto externo. Isso é útil quando o objeto externo sempre delega cada chamada em uma de suas interfaces para a mesma interface do objeto interno. A agregação é uma conveniência que permite que o objeto externo evite sobrecarga de implementação extra.

Para obter mais informações, consulte Reutilizando objetos.

Objetos de armazenamento e fluxo

Os objetos COM salvam o estado em um arquivo usando o armazenamento estruturado, que é uma forma de armazenamento persistente que permite a navegação do conteúdo de um arquivo usando a semântica do sistema de arquivos. Tratar o conteúdo de um arquivo dessa maneira permite recursos como acesso incremental, transações e compartilhamento entre processos.

A especificação de armazenamento persistente COM fornece dois tipos de elementos de armazenamento: objetos de armazenamento e objetos de fluxo. Esses objetos são implementados pela Biblioteca COM, e os aplicativos do usuário raramente implementam esses elementos de armazenamento. Os objetos de armazenamento implementam a interface IStorage e os objetos de fluxo implementam a interface IStream.

Um objeto de fluxo contém dados e é conceitualmente semelhante a um único arquivo em um sistema de arquivos. Cada fluxo tem direitos de acesso e um único ponteiro de busca. Por meio da interface IStream , você pode ler, gravar, procurar e executar outras operações nos dados subjacentes do fluxo. Um fluxo é nomeado usando uma cadeia de caracteres de texto. Ele pode conter qualquer estrutura interna, porque é um fluxo plano de bytes. Além disso, as funções na interface IStream são semelhantes às funções padrão baseadas em identificador de arquivo, como as da biblioteca de tempo de execução ANSI C.

Um objeto de armazenamento é conceitualmente semelhante a um diretório em um sistema de arquivos. Cada armazenamento pode conter qualquer número de objetos de subarmazenamento e qualquer número de fluxos. Cada armazenamento tem seus próprios direitos de acesso. Por meio da interface IStorage , você pode executar operações como enumerar, mover, copiar, renomear, criar e excluir elementos. Um objeto de armazenamento não armazena dados definidos pelo aplicativo, mas armazena implicitamente os nomes dos elementos (armazenamentos e fluxos) que ele contém.

Os objetos de armazenamento e fluxo são compartilháveis entre os processos quando são implementados de acordo com a especificação COM em uma plataforma de host. Isso permite que os objetos que estão sendo executados em processo ou fora do processo tenham acesso incremental igual ao armazenamento de arquivos. Como o COM é carregado em cada processo separadamente, ele usa mecanismos de memória compartilhada suportados pelo sistema operacional para comunicar o estado dos elementos abertos e seus modos de acesso entre os processos.

Cada objeto de armazenamento e fluxo em um arquivo estruturado tem um nome para identificá-lo. O nome é uma cadeia de caracteres que segue uma convenção específica. Para obter mais informações, consulte Convenções de nomenclatura de objeto de armazenamento. O nome é passado para funções IStorage para especificar em qual elemento no armazenamento operar. Os nomes dos objetos de armazenamento raiz são os mesmos que os nomes de arquivo no sistema de arquivos subjacente, e esses nomes devem seguir as convenções e restrições do sistema de arquivos. Cadeias de caracteres passadas para funções relacionadas ao armazenamento que nomeiam arquivos são passados para o sistema de arquivos sem interpretação ou alterações.

Os nomes dos elementos contidos nos objetos de armazenamento são gerenciados pela implementação do objeto de armazenamento específico em questão. Todas as implementações de objetos de armazenamento devem oferecer suporte a nomes de elementos com 32 caracteres de comprimento, e algumas implementações podem oferecer suporte a nomes mais longos. Os nomes são armazenados com maiúsculas e minúsculas preservadas, mas são comparados como diferenciando maiúsculas de minúsculas. Os aplicativos que definem nomes de elementos de armazenamento devem escolher nomes que funcionem em qualquer situação.

Você acessa cada elemento em um arquivo de armazenamento estruturado usando funções e interfaces que são implementadas por COM. Isso significa que outros aplicativos podem procurar o arquivo navegando com as funções de interface IStorage que fornecem serviços semelhantes a diretórios. Além disso, outros aplicativos podem usar os dados do arquivo, sem ter que executar o aplicativo que escreveu o arquivo. Quando um aplicativo COM acessa os arquivos de armazenamento estruturado de outro aplicativo, os direitos de acesso padrão do Windows se aplicam e o aplicativo deve ter privilégios suficientes.

Um objeto COM pode ler e gravar a si mesmo no armazenamento persistente. Um cliente consulta uma das interfaces relacionadas à persistência no objeto COM, dependendo do contexto da operação. Os objetos COM podem implementar qualquer combinação das seguintes interfaces:

  • IPersistStorage: O objeto COM lê e grava seu estado persistente em um objeto de armazenamento. O cliente fornece ao objeto um ponteiro IStorage por meio dessa interface. Esta é a única interface de persistência que inclui semântica para acesso incremental.
  • IPersistStream: O objeto COM lê e grava seu estado persistente em um objeto de fluxo. O cliente fornece ao objeto um ponteiro IStream por meio dessa interface.
  • IPersistFile: O objeto COM lê e grava seu estado persistente diretamente em um arquivo no sistema subjacente. Essa interface não envolve IStorage ou IStream, a menos que o arquivo subjacente seja acessado por meio dessas interfaces, mas a interface IPersistFile não tem semântica para armazenamentos e fluxos. O cliente fornece ao objeto um nome de arquivo e chama as funções Salvar ou Carregar.

Transferência de dados

O armazenamento estruturado fornece a base para a troca de dados entre objetos e processos COM, que é chamada de transferência uniforme de dados. Antes da implementação do COM no OLE 2, a transferência de dados no Windows era especificada por protocolos de transferência, como a área de transferência e os protocolos de arrastar e soltar. Cada protocolo de transferência tinha seu próprio conjunto de funções que vinculavam o protocolo à consulta, e um código específico era necessário para lidar com cada protocolo diferente e procedimento de troca. A transferência de dados uniforme representa todas as transferências de dados usando a interface IDataObject , que separa as operações comuns de troca de dados do protocolo de transferência.

A interface IDataObject encapsula as operações padrão get e set em dados, consultas e enumerações e notificações que detectam quando os dados são alterados em um objeto. A transferência uniforme de dados permite descrições ricas de formatos de dados, bem como o uso de diferentes mídias de armazenamento para a transferência de dados.

Durante a transferência uniforme de dados, todos os protocolos trocam um ponteiro para uma interface IDataObject. O servidor é a fonte dos dados e implementa um objeto de dados, que é utilizável em qualquer protocolo de troca de dados. O cliente consome os dados e solicita dados de um objeto de dados quando recebe um ponteiro IDataObject de qualquer protocolo. Depois que a troca de ponteiro ocorre, ambos os lados lidam com a troca de dados de forma uniforme, por meio da interface IDataObject .

COM define duas estruturas de dados que permitem a transferência uniforme de dados. A estrutura FORMATETC representa um formato de área de transferência generalizado e a estrutura STGMEDIUM representa o meio de transferência como um identificador de memória.

O cliente cria uma estrutura FORMATETC para indicar o tipo de dados que ele solicita de uma fonte de dados e é usado pela fonte de dados para descrever quais formatos ele fornece. O cliente consulta uma fonte de dados para seus formatos disponíveis solicitando sua interface IEnumFORMATETC. Para obter mais informações, consulte A estrutura FORMATETC.

O cliente cria uma estrutura STGMEDIUM e a passa para o método GetData, e o objeto de dados retorna os dados na estrutura STGMEDIUM fornecida.

A estrutura STGMEDIUM permite que clientes e fontes de dados escolham o meio de troca mais eficiente. Por exemplo, se os dados a serem trocados forem muito grandes, a fonte de dados poderá indicar uma mídia baseada em disco como seu formato preferido, em vez da memória principal. Essa flexibilidade permite trocas de dados eficientes que podem ser tão rápidas quanto passar um ponteiro para um IStorage ou um IStream. Para obter mais informações, consulte A estrutura STGMEDIUM.

Um cliente de uma fonte de dados pode exigir notificação quando os dados são alterados. COM manipula notificações de alteração de dados usando um objeto advise sink , que implementa a interface IAdviseSink . O objeto advise sink e a interface IAdviseSink são implementados pelo cliente, que passa um ponteiro IAdviseSink para a fonte de dados. Quando a fonte de dados detecta uma alteração nos dados subjacentes, ela chama um método IAdviseSink para notificar o cliente. Para obter mais informações, consulte Notificação de dados.

Comunicação remota

O COM permite computação remota e distribuída. A comunicação remota de interface permite que uma função de membro retorne um ponteiro de interface para um objeto COM que esteja em um processo diferente ou em um computador host diferente. A infraestrutura que executa a comunicação remota da interface é transparente para o cliente e o servidor de objetos. Nem o cliente nem o servidor precisam dos detalhes de implantação um do outro para se comunicar por meio de uma interface remota. Um cliente chama funções de membro na mesma interface para se comunicar com um objeto COM que está em processo, fora de processo no host local ou em um computador remoto. Chamadas locais e remotas na mesma interface são indistinguíveis para o cliente.

Para se comunicar com um objeto COM, um cliente sempre chama uma implementação em processo. Se o objeto COM estiver em processo, a chamada será direta. Se o objeto COM estiver fora de processo ou remoto, o COM fornecerá uma implementação de proxy que encaminha a chamada para o objeto usando o protocolo RPC (Chamada de Procedimento Remoto).

Um objeto COM sempre recebe chamadas de um cliente por meio de uma implementação em processo. Se o chamador estiver em processo, a chamada será direta. Se o chamador estiver fora do processo ou remoto, o COM fornecerá uma implementação de stub que recebe a chamada de procedimento remoto do proxy no processo do cliente.

Marshaling é o procedimento para empacotar a pilha de chamadas para transmissão de proxy para stub. Unmarshaling é o desempacotamento que ocorre na extremidade receptora. Os valores de retorno são empacotados e desempacotados do stub para o proxy. Esse tipo de comunicação também é conhecido como envio de uma chamada pelo fio.

Cada tipo de dados diferente tem regras para empacotamento. Os ponteiros de interface também têm um protocolo marshaling, que é encapsulado na função CoMarshalInterface . Na maioria dos casos, o empacotamento de interface padrão, que é fornecido pelo sistema, é suficiente, mas um objeto COM opcionalmente pode implementar empacotamento de interface personalizado para controlar a criação de proxies de objeto remotos para si mesmo. Para obter mais informações, consulte Comunicação entre objetos.

Segurança

O COM fornece duas formas de segurança de aplicativos. Uma delas é a segurança de ativação, que especifica como novos objetos são criados, como os clientes se conectam a objetos novos e existentes e como determinados serviços públicos, como a Tabela de Classes e a Tabela de Objetos em Execução, são protegidos. A outra é a segurança de chamada, que especifica como a segurança opera em uma conexão estabelecida entre um cliente e um objeto COM.

A segurança de ativação é aplicada automaticamente pelo Service Control Manager (SCM). Quando o SCM recebe uma solicitação para recuperar um objeto COM, ele verifica a solicitação em relação às informações de segurança armazenadas no Registro.

As implementações do SCM geralmente oferecem configuração controlada pelo registro para administrar classes implantadas e para contas de usuário específicas no host. Para obter mais informações, consulte Segurança de ativação.

A segurança da chamada é aplicada automaticamente ou é imposta pelo aplicativo. Se o aplicativo fornecer informações de instalação, COM executará as verificações necessárias para proteger o aplicativo.

O mecanismo automático verifica a segurança do processo, mas não de objetos ou métodos individuais. Se um aplicativo exigir segurança mais refinada, o COM fornecerá funções que os aplicativos podem usar para fazer sua própria verificação de segurança.

Os mecanismos automáticos e personalizados podem ser usados juntos, de modo que um aplicativo pode pedir ao COM para executar a verificação de segurança automática e, em seguida, executar o seu próprio.

Os serviços de segurança de chamadas COM são divididos nas seguintes categorias:

Muitas vezes, o cliente consulta o objeto COM para a interface IClientSecurity , que é implementada localmente pela camada remota. O cliente usa essa interface para controlar a segurança de proxies de interface individuais no objeto COM antes de fazer uma chamada em uma das interfaces.

Quando uma chamada chega ao servidor, o servidor pode chamar a função CoGetCallContext para recuperar uma interface IServerSecurity, que permite que o servidor verifique a autenticação do cliente e represente o cliente, se necessário. O objeto IServerSecurity é válido para a duração da chamada.

Chame a função CoInitializeSecurity para inicializar a camada de segurança e definir os valores especificados como o padrão de segurança. Se um processo não chamar CoInitializeSecurity, COM o chamará automaticamente na primeira vez que uma interface for empacotada ou desempacotada, registrando a segurança padrão do sistema. A função CoInitializeSecurity permite que o cliente estabeleça segurança de chamada padrão para o processo, o que evita o uso de IClientSecurity em proxies individuais. A função CoInitializeSecurity permite que um servidor registre serviços de autenticação automática para o processo. Para obter mais informações, consulte Definindo a segurança em todo o processo com CoInitializeSecurity.

Clientes e servidores COM

Definição de interfaces COM

Registrando aplicativos COM

Segurança em COM

Processos, threads e apartamentos

 

 

  • Last updated on