VB - Falando um pouco sobre a tecnologia COM


È muito importante conhecer os conceitos básicos da tecnologia - COM . Neste artigo uma pequena introdução ao Component Object Model.

 

Vamos começar falando de objetos distribuídos:

 

De forma simplificada, um sistema distribuído é aquele constituído de programas que executam simultaneamente em vários computadores interligados em rede, tentando dar ao usuário a impressão de que este é um sistema único e isolado.

 

A utilização de sistemas distribuídos tem aumentado cada vez mais em empresas e corporações, devido a diversos fatores como:

1- Desenvolvimento das redes de computadores com grande desempenho e altas capacidades de banda;
2- Disseminação do uso de computadores pessoais e de estações de trabalho em substituição aos mainframes;
3- Heterogeneidade entre plataformas de hardware e software;
4- Aumento de capacidade de processamento;
5- Necessidade de uma transparência mais efetiva na utilização dos processos computacionais.


O uso da tecnologia de objetos distribuídos está contribuindo no desenvolvimento de sistemas distribuídos, uma vez que os mesmos são implementados, na maioria das vezes, em plataformas heterogêneas. Estes objetos distribuídos permitem, além da distribuição das aplicações, a reutilização de software, evitando assim custos extras com o desenvolvimento de novos programas ou a adaptação dos mesmos na utilização no sistema distribuído.

Objetos COM - component object model

OLE (Object Linkind and Embedding) é uma tecnologia que define um procedimento padronizado em que um módulo cliente e um módulo servidor podem se comunicar através de uma determinada interface. Aqui, "módulo" indica um aplicativo ou uma biblioteca DLL (Dynamic Link Labraries). Os dois módulos podem ser executados no mesmo computador ou em computadores diferentes. Há várias interfaces possíveis dependendo do papel do cliente e do servidor e pode-se acrescentar interfaces novas com objetos específicos.

 

Essas interfaces são completadas por objetos servidores. Um objeto servidor normalmente implementa mais de uma interface e todos os objetos servidores têm serviços em comum.

Por definição, COM é a implementação do OLE. Na prática, os termos OLE e COM são freqüentemente utilizados de modo intercambiável. COM especifica os detalhes técnicos de OLE e qualquer linguagem de concordância COM pode ser utilizada para escrever objetos COM/OLE.

Inicialmente, os códigos dos objetos COM eram escritos através das linguagens de programação C e C++. Mas também é possível desenvolver novos objetos COM utilizando outras linguagens de programação. Uma linguagem muito utilizada é o Visual Basic, da Microsoft, que é totalmente compatível com esta tecnologia.

Se OLE é um conjunto de interfaces, é importante observar que essas interfaces servem para a comunicação entre dois módulos de software, dois arquivos executáveis, ou um arquivo executável e uma DLL.

Implementar objetos DLL geralmente é simples, porque no Win32 um programa e as suas DLLs residem no mesmo espaço de endereço de memória. Isso significa que, se o programa passa um endereço de memória para a DLL, o endereço permanece válido.

 

Quando são utilizados dois arquivos executáveis, torna-se muito trabalhoso para o OLE, devendo ser utilizado o conceito denominado marshaling para permitir que os dois aplicativos se comuniquem. Marshaling é o mecanismo que permite ao cliente fazer chamadas às funções da interface para objetos remotos em outro processo ou em uma máquina diferente.

Com objetos COM, a aplicação cliente não precisa conhecer onde o objeto reside, simplesmente gera chamadas para interfaces de objetos. Um objeto COM executa os passos necessários para gerar a chamada para localizar o objeto desejado. Estes passos diferem, dependendo se o objeto está no mesmo processo no cliente (Servidores in-process), em diferentes processos no cliente (Servidores ouf-of-process) ou em outras máquinas (Servidores remotos), como são descritos abaixo:

a- Servidores in-process: Uma DLL (Dynamic Link Labraries) executando no mesmo espaço da aplicação cliente. Por exemplo: um controle ActiveX embutido em uma página da WEB visualizado no Internet Explorer ou Netscape. Aqui, o controle ActiveX é "baixado" para a máquina do cliente e invocado com alguns processos do WEB Browser. O Cliente comunica in-process com servidor usando chamadas da interface COM.

b- Servidores out-of-process: Outra aplicação (EXE) executando em um espaço diferente de processo, mas na mesma máquina do cliente. Por exemplo: uma planilha eletrônica do Excel embutida em um Documento do Word; duas aplicações separadas executando na mesma máquina. O servidor local usa a interface COM para comunicar com o cliente.

c- Servidores remotos: Uma DLL (Dynamic Link Labraries) ou outra aplicação executando em uma máquina diferente da máquina do cliente, por exemplo: um Banco de Dados em VB está conectado com uma aplicação servidora em outra máquina da rede. O Servidor remoto usa a Interface DCOM (Distributed COM) para comunicar com a aplicação servidora.

Há quatro fatores básicos que ditam o projeto de objetos COM:

1) Objetos COM podem rodar entre processos ou computadores.
2) os métodos de um Objeto COM podem ser chamados através de uma rede de comunicação.
3) os nomes dos métodos devem ser únicos em um determinado processo. Nomes de objetos COM devem ser únicos.
4) servidores COM podem ser escritos em uma variedade de linguagens diferentes e em sistemas operacionais completamente diferentes.

Em COM, pode-se criar objetos em outros processos, ou em qualquer máquina da rede. Não é necessário criar um objeto COM que use a declaração normal de C++ (new). Para criar um objeto COM, alguma entidade (um EXE ou um Serviço) deve ser responsável pela alocação de memória remota e a criação de objetos. Esta é uma tarefa muito complexa. Este problema é resolvido com um conceito denominado COM Server. Este servidor deve que manter comunicação com o cliente.

MÉTODOS COM PODEM SER CHAMADOS ATRAVÉS DE UMA REDE

Tendo acesso a uma máquina na rede e se está instalado o COM Server para o objeto a ser utilizado nesta máquina, pode-se criar um objeto COM neste computador.

Considerando que um objeto COM não está necessariamente na máquina local, é necessário um método para apontar para este objeto, embora sua memória esteja em outro lugar. Tecnicamente, não há nenhum modo para fazer isto. Mas na prática, pode ser simulado introduzindo um novo nível inteiro de objetos. Um dos meios de como COM faz isto é através de um conceito chamado proxy/stub.

Outro assunto importante é a passagem de dados entre o cliente COM e o servidor COM. Quando dados são passados entre processos, threads ou rede, é chamado "marshaling". Novamente, o proxy/stub cuida do marshaling.

OBJETOS COM DEVEM SER ÚNICOS

Objetos COM devem ser únicos no mundo. Isto pode parecer em princípio, um exagero. Mas considere a Internet como a rede mundial. Até mesmo se for utilizado uma única máquina, COM tem que manipular a possibilidade. Singularidade é o assunto.

O compilador pode ver as definições da classe utilizadas em um programa e pode corresponder a todas as referências. O compilador também garante que há apenas uma classe com um determinado nome.
 

COM tem que garantir que há somente um objeto com um determinado nome, embora o número total de objetos disponível em uma rede pode ser enorme. Este problema é resolvido criando um conceito chamado GUID, que será visto posteriormente.

OBJETOS COM são INDEPENDENTES DA LINGUAGEM

Podem ser escritos servidores COM em linguagens diferentes utilizando um sistema operacional completamente diferente. Objetos COM têm a capacidade de ser remotamente acessados. Isto significa que eles podem estar em um thread, em um processo diferente ou até mesmo em um computador diferente. O outro computador pode estar rodando debaixo de um sistema operacional diferente.

Para transmissão de parâmetros pela rede é especificada uma interface entre o cliente e servidor. Também há um compilador novo chamado MIDL (Microsoft Interface Definition Language). Este compilador especifica genericamente a interface entre o servidor e cliente. MIDL define objetos COM, interfaces, métodos e parâmetros.

A INTERFACE

Em COM, interface tem um significado muito específico e interfaces COM são um conceito completamente novo. O conceito de uma interface é inicialmente difícil de entender porque uma interface é uma entidade que não tem uma existência concreta.

Uma interface nada mais é que uma coleção de funções. Os membros daquela interface são todas as funções públicas da classe. Em outras palavras, a interface é a parte visível da classe (parte pública).

Uma das regras principais de COM é que é possível acessar um objeto COM através de uma interface. O programa cliente é completamente isolado da implementação do servidor por interfaces. Este é um ponto extremamente importante.
 

Considere o seguinte exemplo: quando uma pessoa entra em um carro, esta se depara com uma variedade de interfaces de usuário. Há uma interface que permite dirigir o carro, outra que permite trabalhar os faróis, outra para controlar o rádio. E assim por diante...
 

Um objeto COM pode apoiar em uma coleção de interfaces, onde cada uma tem um nome. Para objetos COM criados, freqüentemente é definida e usada uma única interface COM. Mas muitos objetos COM existentes suportam múltiplas interfaces COM dependendo das características que eles apóiam. A interface o isola dos detalhes de implementação.

Quando se constrói um objeto COM, é necessário entender como as interfaces trabalham. O usuário da interface, porém, não precisa conhecer os detalhes de implementação. Como os freios em um carro, o usuário só se preocupa como a interface trabalha, não sobre os detalhes atrás da interface.

Este isolamento de interface e implementação é crucial para objetos COM. Isolando a interface de sua implementação, pode-se construir componentes que podem ser substituídos e reutilizados. Isto simplifica e multiplica a utilidade do objeto.

Espero que tenham gostado da teoria ; conceitos teóricos são como remédio amargo , ninguém gosta , mas faz bem para a saúde do desenvolvedor...


Até breve ...


José Carlos Macoratti