Modelo de Objeto Componente

Component Object Model (COM) é uma plataforma da Microsoft para componentes de software , introduzida em 1993 . Esta plataforma é utilizada para permitir a comunicação entre processos e a criação dinâmica de objetos, em qualquer linguagem de programação que suporte esta tecnologia. O termo COM é frequentemente usado no mundo do desenvolvimento de software como um termo abrangente para as tecnologias OLE, OLE Automation, ActiveX, COM+ e DCOM. Embora o COM tenha sido introduzido em 1993, a Microsoft não enfatizou o nome COM até 1997.

Essencialmente, COM é uma maneira de implementar objetos de linguagem neutra, para que possam ser usados ​​em ambientes diferentes daquele em que foram criados, além dos limites da máquina. Para componentes bem criados, COM permite a reutilização de objetos sem o conhecimento de sua implementação interna, pois força os implementadores de componentes a fornecer interfaces bem definidas que são separadas da implementação. Diferentes semânticas de alocação de memória são acomodadas tornando os objetos responsáveis ​​por sua própria criação e destruição por meio da contagem de referência. Você pode converter entre diferentes interfaces de um objeto usando o QueryInterface(). O método preferencial de herança em COM é a criação de subobjetos aos quais as chamadas de método são delegadas (chamadas agregação).

Embora essas tecnologias tenham sido implementadas em muitas plataformas, elas são usadas principalmente com um programa do Microsoft Windows . Espera-se que o COM seja substituído, pelo menos até certo ponto, pelo Microsoft .NET e suporte para Web Services por meio do Windows Communication Foundation (WCF). O Network DCOM usa formatos binários proprietários, enquanto o WCF usa mensagens SOAP baseadas em XML . O COM também compete com CORBA e JavaBeans como um sistema de componentes de software.

Detalhes técnicos

Os programadores COM criam software usando componentes de software compatíveis com COM. Diferentes tipos de componentes são identificados por IDs de tipo (CLSIDs), que são identificadores globalmente exclusivos ou GUIDs. Cada componente COM revela sua funcionalidade por meio de uma ou mais interfaces. As diferentes interfaces suportadas por um componente são diferenciadas umas das outras usando IDs de interface (IIDs), que também são GUIDs.

As Interfaces COM possuem implementações em diversas linguagens, como C, C++, Visual Basic, e várias das linguagens de script implementadas na plataforma Windows. Todo acesso aos componentes é feito através dos métodos das interfaces. Isso permite técnicas como interprocessamento, até mesmo programação entre computadores (esta última por meio de suporte a DCOM).

Interfaces

Todos os componentes COM devem implementar pelo menos a interface IUnknown padrão e, portanto, todas as interfaces COM são derivadas de IUnknown . A interface IUnknown consiste em três métodos: AddRef()e Release(), que implementam a contagem de referência e o controle do ciclo de vida da interface; e QueryInterface(), que ao especificar um IID permite que uma chamada recupere referências às diferentes interfaces que o componente implementa. O efeito de QueryInterface()é semelhante dynamic_cast <>em C++ ou castingem C# e Java.

As interfaces de um componente COM são necessárias para exibir as propriedades reflexivas, simétricas e transitivas. A propriedade reflexiva refere-se à capacidade da chamada para QueryInterface(), dada uma interface com o ID da interface, retornar a mesma instância da interface. A propriedade simétrica refere-se ao fato de que quando a interface B é recuperada da interface A por QueryInterface(), a interface A também pode ser recuperada da interface B. A propriedade transitiva é semelhante à propriedade simétrica, mas requer que, se a interface B puder ser recuperada de A, e C por sua vez de B, então a interface C deve estar disponível de A.

Uma interface consiste em um ponteiro de função virtual que contém uma lista de ponteiros para as funções que a função declarada na interface implementa, na mesma ordem em que foram declaradas na interface. Essa técnica de passagem de ponteiro de função de estrutura é muito semelhante àquela usada pelo OLE 1.0 para se comunicar com seu sistema de biblioteca.

COM especifica muitas outras interfaces padrão usadas para permitir a comunicação entre os componentes. Por exemplo, um deles é o IStream , destinado a componentes que possuem semântica de fluxo de dados (um componente FileStream usado para ler e gravar arquivos). Ele tem os métodos de leitura e gravação esperados para executar as leituras e gravações de fluxo. Outra interface padrão é IOleObject , destinada a componentes que esperam ser vinculados ou incorporados em um contêiner. IOleObject contém métodos que permitem que as partes interessadas determinem o tamanho dos limites de um componente retangular, se o componente oferecer suporte a operações como 'Open' , 'Save' e assim por diante.

Aulas

Uma classe em COM é chamada de coclass , que é a forma contratada da classe Component Object . Uma coclass é a maneira do COM de definir uma classe no sentido de orientação a objetos independente de linguagem. Uma coclass fornece uma implementação concreta de uma ou mais interfaces. Em COM, tais implementações concretas podem ser escritas em qualquer linguagem de programação que suporte o desenvolvimento de componentes COM, como C++, Visual Basic, etc.

Uma das maiores contribuições do COM para o mundo do desenvolvimento Windows é a conscientização do conceito de separação da interface da implementação. Essa consciência, sem dúvida, influenciou a maneira como os programadores constroem os sistemas atuais. Uma extensão deste conceito fundamental é o conceito de uma interface, múltiplas implementações. Isso significa que em tempo de execução, um aplicativo pode optar por instanciar uma interface de uma das várias implementações concretas.

Linguagem de definição de interface e bibliotecas de tipos

As bibliotecas de tipos contêm metadados que representam tipos COM. No entanto, esses tipos devem primeiro ser descritos usando o Microsoft Interface Definition Language (MIDL). Esta é uma prática comum ao desenvolver um componente COM, por exemplo, ao iniciar com a definição de tipos usando IDL. Um arquivo IDL é o que o COM fornece que permite aos desenvolvedores definir classes orientadas a objetos, interfaces, estruturas, enumerações e outros tipos definidos pelo usuário em uma linguagem de forma independente. COM IDL é semelhante em aparência às declarações C ou C++ com a adição de palavras-chave como "interface" e "library" para a definição de interfaces e coleções de classes, respectivamente. A IDL também requer o uso de atributos entre colchetes antes das declarações para fornecer informações adicionais, como o GUID das interfaces e o relacionamento entre o ponteiro e os parâmetros de comprimento dos campos.

O arquivo IDL é compilado pelo compilador MIDL de algumas maneiras para uso em várias linguagens. Para C/C++, o compilador MIDL gera um cabeçalho independente do compilador contendo definições de estrutura que correspondem às funções virtuais à declaração de interface e um arquivo C contendo GUIDs de declaração de interface. O código-fonte C++ para um módulo Proxy também pode ser gerado pelo compilador MIDL. Este Proxy contém métodos stub para converter chamadas COM em RPC, isso é permitido pelo DCOM.

Um arquivo IDL também pode ser compilado pelo compilador MIDL em uma biblioteca de tipos (arquivo .TLB). Os metadados binários contidos na biblioteca devem ser processados ​​pelos compiladores e ambientes de tempo de execução da linguagem (VB, Delphi, .NET CLR, etc.). O resultado final de tal processamento de TLB é que são produzidas construções específicas de linguagem que representam a classe COM definida no .TLB (e, finalmente, aquela definida no arquivo de origem IDL).

Contagem de referência

A mais importante de todas as interfaces COM, ou seja, IUnknown (da qual todas as interfaces COM devem derivar), suporta dois conceitos principais: consulta de recursos (ou interfaces que um objeto implementa) via método queryInterface()e gerenciamento do ciclo de vida do objeto incluindo AddRef ()e Release (). O recurso de contagem e consulta de referência se aplica a objetos (não a cada interface) e, portanto, deve ter uma implementação centralizada.

As especificações COM exigem uma técnica chamada contagem de referência para garantir que os vários objetos estejam vivos enquanto houver clientes que tenham adquirido acesso a uma ou mais de suas interfaces e, inversamente, que o mesmo objeto seja descartado adequadamente quando todo o código for presente. que usa o objeto é feito com ele e não precisa mais dele. Um objeto COM é responsável por liberar sua própria memória uma vez que sua contagem de referência é decrementada para zero.

Para sua execução, um objeto COM geralmente mantém um valor que é usado como referência para contagem. Quando chamado AddRef ()por qualquer uma das interfaces do objeto, esse valor é incrementado. Quando é chamado Release(), esse inteiro é decrementado. AddRef ()e Release ()eles são o único meio pelo qual um cliente de um objeto COM pode influenciar seu ciclo de vida. O valor interno permanece um membro privado do objeto COM e nunca estará diretamente acessível.

Instanciação

COM padroniza o processo de instanciar (ou seja, criar) objetos COM exigindo o uso da classe Factories . Para cada objeto COM que foi criado, devem existir dois parâmetros associados:

• Uma classe de identificação .
• Uma classe de fábrica .

Cada classe COM ou CoClass deve ser associada a um ID de classe exclusivo (um GUID). Ele também deve estar associado à sua própria classe Factory (que é alcançada usando um registro centralizado). Uma classe Factory é em si um objeto COM. É um objeto que deve expor a interface IClassFactory ou IClassFactory2 (este último com as licenças de suporte). A responsabilidade de tal objeto é a criação de outros objetos.

Uma classe Factory geralmente está contida no mesmo código executável (ou seja, o servidor de código) que o próprio objeto COM. Quando uma classe Factory é chamada para criar um objeto de destino, o destino desse objeto é o id de classe que deve ser fornecido. É assim que a classe Factory sabe qual classe de objeto instanciar.

Uma única classe de objeto Factory pode criar objetos de mais de uma classe. Ou seja, dois objetos de diferentes IDs de classe podem ser criados pela mesma classe de objeto Factory . No entanto, isso é transparente para o sistema COM.

Ao delegar a responsabilidade de criar um objeto a um objeto separado, um nível mais alto de abstração é alcançado e o desenvolvedor tem mais flexibilidade.

Para que os aplicativos cliente adquiram classes de objeto Factory , os servidores COM devem expô-los adequadamente. Uma classe Factory é exposta de forma diferente, dependendo da natureza do código do servidor. Um servidor baseado em DLLs deve exportar uma função global DllGetClassObject (). Um EXE de servidor baseado na classe Factory é registrado em tempo de execução por meio da função API do Windows do CoRegisterClassObject ().

Programação

COM é um padrão binário e pode ser desenvolvido em qualquer linguagem de programação capaz de entender e implementar seus tipos de dados binários e interfaces definidos.

As bibliotecas de tempo de execução (em situações extremas, programadores) são responsáveis ​​por entrar e sair do ambiente COM, instanciação e contagem de referência de objetos COM, objetos para consultar informações de versão, codificação para aproveitar versões avançadas de objetos.

Transparência de aplicativos e rede

Objetos COM podem ser instanciados e referenciados dentro de um processo, através dos limites do processo dentro de um computador e através de uma rede usando a tecnologia DCOM . Sair do processo e objetos remotos pode usar serialização para enviar chamadas de método e retornar valores para trás e para frente. A serialização é invisível para o objeto e o código usando o objeto.

Críticas

Mensagem de bombeamento

Quando um STA é inicializado, ele cria uma janela oculta que é usada para roteamento de mensagens entre apartamentos e entre processos. Esta janela deve ter sua fila de mensagens regularmente bombeada. Essa construção é conhecida como bomba de mensagem. Em versões anteriores do Windows, não fazer isso pode causar falhas em todo o sistema. Esse problema é especialmente desagradável porque algumas APIs do Windows inicializam COM como parte de seu aplicativo, causando vazamento de detalhes de implementação.

Contagem de referência

A contagem de referência em COM pode causar problemas se dois ou mais objetos forem referenciados circularmente. Um design de aplicativo deve levar isso em consideração para que os objetos não fiquem órfãos.

Os objetos também podem deixar a contagem de referência ativa se o "sink case" COM for o modelo usado. Como o objeto que dispara o evento precisa de uma referência de objeto para reagir ao evento, a contagem de referência de objeto nunca chega a zero.

DLL inferno

Como a localização de cada componente é armazenada em um local de todo o sistema (o registro do Windows), pode haver apenas uma versão de um determinado componente instalada. Portanto, COM sofre severamente com DLL hell , onde dois ou mais aplicativos requerem versões diferentes do mesmo componente.

O Windows XP introduz um novo modo de registro de objeto COM: "COM Free Registration". Esse serviço possibilita que aplicativos que precisam instalar objetos COM armazenem todas as informações de registro necessárias para o registro COM no diretório de solicitação, em vez de no registro global, onde estritamente falando apenas uma única solicitação é usada. DLL inferno, pode ser evitado pelo COM sem registro, a única limitação é que requer pelo menos o Windows XP ou versões posteriores do Windows e que não deve ser usado para EXE, COM ou componentes do sistema de todo o servidor, como MDAC , MSXML , DirectX ou Internet Explorer.

Referências

• Berger, Dan (2004). « COM: Uma breve introdução » . História Africana em About.com . Recuperado em 6 de fevereiro de 2006 . 
• Microsoft Corp. (2006). « Modelo de Objeto Componente » . Arquivado a partir do original em 2006-03-18 . Recuperado em 6 de fevereiro de 2006 . 
• Caixa, Don (1998). Essencial COM . Série de Tecnologia de Objetos Addison-Wesley . ISBN  0-201-63446-5 . 

Veja também

• Modelo de Objeto Componente Distribuído (DCOM)
• Troca dinâmica de dados (DDE)
• Microsoft.NET (.NET)
• Vinculação e incorporação de objetos (OLE)
• componente de software
• Engenharia de software baseada em componentes

Links externos

• Tecnologias Microsoft COM .
• O que é realmente OLE por Kraig Brockschmidt. Uma visão geral de COM e OLE. (Em inglês).
• Grupo de Aplicativos de Componentes da Microsoft Research .
• Projeto Mozilla ActiveX (em inglês).
• Introdução ao Com .
• INFO: Diferença entre controles OLE e controles ActiveX da Microsoft.